From leonard at den.ottolander.nl Sun Feb 1 00:35:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 01 Feb 2004 01:35:50 +0100 Subject: gaim security In-Reply-To: <1075578272.13707.3.camel@localhost.localdomain> References: <1075578272.13707.3.camel@localhost.localdomain> Message-ID: <1075595750.4785.4.camel@athlon.localdomain> Hallo Bart, > Shouldn't gaim 0.75 be released as a security update, the way it was > done for Red Hat 9 ? It probably should be moved to the main tree as it has been in testing for over 2 weeks, but in contrast to the latest mc vulnerability this update was announced: http://www.redhat.com/archives/fedora-test-list/2004-January/msg00153.html Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pri.rhl1 at iadonisi.to Sun Feb 1 01:19:03 2004 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: Sat, 31 Jan 2004 20:19:03 -0500 Subject: Evolution 1.5.3 (was: Re: Evolution 1.5.2) In-Reply-To: <1074557012.14797.11.camel@va.local.linuxlobbyist.org> References: <1074511758.2988.2.camel@bart.netlyncs.com> <1074546885.25243.3.camel@ws.1sttier.net> <1074557012.14797.11.camel@va.local.linuxlobbyist.org> Message-ID: <1075598343.2711.5.camel@va.local.linuxlobbyist.org> On Mon, 2004-01-19 at 19:03, Paul Iadonisi wrote: > ... I *really* miss the fact that when switch from folder to > folder reading various messages, evo 1.4.5 remembered what message you > were on in each folder. Now 1.5.2 it forgets all but the last message > you clicked on, instead of the last one in each folder. Wow. Sweet. As an FYI, 1.5.3 not only fixes this, but now it remembers what message you were on in each folder *between sessions*. Nice. -- -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 smoogen at lanl.gov Sun Feb 1 02:15:11 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sat, 31 Jan 2004 19:15:11 -0700 (MST) Subject: Upgrade of unmaintained packages In-Reply-To: <1075478191.25735.14.camel@chip.laiskiainen.org> References: <1075478191.25735.14.camel@chip.laiskiainen.org> Message-ID: I am guessing what people are looking for is something like: rpm-showme orphans which would show files that are orphaned or maybe a list of RPMS that did not get upgraded (how to determine that is a quandry left to the student :P) On Fri, 30 Jan 2004, Panu Matilainen wrote: >On Fri, 2004-01-30 at 17:43, Aurelien Bompard wrote: >> Hi all, >> >> I have a question about distribution upgrade : how should we deal with >> unmaintained packages which don't work in the new distribution ? Let's say >> we have included a program in Extras (or main) and the project stops for >> some reason. At some point in the future, the program will stop working >> (API change, glibc upgrade, ...). How should we deal with such a package >> (except not including it in the first place of course ;) ) ? >> We could tell Anaconda to remove it (well I don't know much about Anaconda, >> but I suppose it is possible), but what about online upgrades using yum or >> apt ? > >Anaconda, up2date and yum never remove packages unless they are >explicitly obsoleted by something else, AFAIK. (well, anaconda has some >special remove-this-crap blacklist items like linuxconf :) Apt on the >other hand does remove packages for which dependencies can no longer be >satisfied (and occasionally gets itself and you into trouble just >because of that :) > > > - Panu - > > > -- 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 salimma1 at yahoo.co.uk Sun Feb 1 02:20:47 2004 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Sun, 01 Feb 2004 09:20:47 +0700 Subject: Nautilus toolbars In-Reply-To: <1075592741.3699.3.camel@aurora.localdomain> References: <1075592741.3699.3.camel@aurora.localdomain> Message-ID: <1075602047.2379.2.camel@localhost.localdomain> On Sat, 2004-01-31 at 18:45 -0500, Trever L. Adams wrote: > I am not sure whether or not to post this as a bug, but in the devel > series of Fedora, the location bar and tool bars in Nautilus seem to be > gone. > On my PC, even the icons are gone. But I probably miss a library or two while upgrading - the version dependency should be made more strict, perhaps - on account of my Yum connectivity problems leading me to perform selective upgrades. Will wait for FC2test1 before I submit -devel bugs, just in case. Incidentally, would Red Hat consider apt-enabling their tree? I know yum is the anointed solution for now, but for some people with decent bandwith but horrible latency, yum is not suitable (yet). Thanks, - 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 cornette at insight.rr.com Sun Feb 1 02:46:44 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Sat, 31 Jan 2004 21:46:44 -0500 Subject: Menus back, but where is... Message-ID: <401C6894.4020601@insight.rr.com> I just did the upgrade and found that there was no help choice on the menu. Has help been removed, relocated or overlooked? It is great to have the menu options returned for the test. Also, is the XBD error that has come up since the last upgrade a problem that should be filed upstream with xfree86 or is this unique to Fedora and needs filed for xfree86. The error message is below: Error activating XKB configuration. Probably internal X server problem. X server version data: The XFree86 Project, Inc 40300000 You are using XFree 4.3.0. There are known problems with complex XKB configurations. Try using simpler configuration or taking more fresh version of XFree software. I don't want to change the configuration and end up not having X working. Is this error message worth messing with X? Jim From ghenriks at rogers.com Sun Feb 1 02:54:17 2004 From: ghenriks at rogers.com (Gerald Henriksen) Date: Sat, 31 Jan 2004 21:54:17 -0500 Subject: Nautilus toolbars In-Reply-To: <1075592741.3699.3.camel@aurora.localdomain> References: <1075592741.3699.3.camel@aurora.localdomain> Message-ID: On Sat, 31 Jan 2004 18:45:41 -0500, you wrote: >I am not sure whether or not to post this as a bug, but in the devel >series of Fedora, the location bar and tool bars in Nautilus seem to be >gone. This is now correct behaviour. Nautilus is no longer going to mimic a web browser but instead to return to the old way where each directory opens a new window. From warren at togami.com Sun Feb 1 03:00:17 2004 From: warren at togami.com (Warren Togami) Date: Sat, 31 Jan 2004 17:00:17 -1000 Subject: mplayer vs. xine In-Reply-To: <20040131152547.GC5507@thyrsus.com> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> Message-ID: <401C6BC1.8040600@togami.com> Eric S. Raymond wrote: > > I think libdcvss is already in livna's xine set. Carrying > flash-plugin would be a good idea, though. Redistribution of flash-plugin is completely illegal under Macromedia's EULA, and also and unneeded since Macromedia has given me special permission to maintain RPM packages and apt/yum/urpmi repositories for the plugin. http://macromedia.mplug.org Warren Togami warren at togami.com From icon at linux.duke.edu Sun Feb 1 03:23:04 2004 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: Sat, 31 Jan 2004 22:23:04 -0500 Subject: mplayer vs. xine In-Reply-To: <20040131212544.GB10087@thyrsus.com> References: <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> Message-ID: <401C7118.50306@linux.duke.edu> On 31.01.2004 16:25, Eric S. Raymond wrote: > If livna.org is willing to run afoul of patents and the DMCA to > distribute libdvdcss, it's hard to believe they'd balk at > violating these. But I'll ask. I think we need to distinguish between ignoring US laws and patents outside of the US, and violating international copyrights. Livna may distribute libdvdcss and US-patent-infringing software because they are outside the jurisdiction of the US, and DMCA/patents don't have any power over them (at least at the moment). The "infringing" software is still Free in terms of license: there is an explicit permission to distribute it where legal. However, distributing proprietary packages without having a license to distribute them would be a violation of international copyrights, which is a criminal offense in most of the civilized world. As long as livna.org remains outside the US, they are legal in their locality because all of their software is free. If they start distributing unlicensed stuff, they would quickly lose their legal status, be shut down, fined, and likely thrown in jail, because that would be no different than running a warez site. So, I wouldn't suggest putting pressure on them to distribute proprietary packages without the permission of copyright owners. Regards, -- Konstantin ("Icon") Riabitsev Duke Physics Systems Admin, RHCE I am looking for a job in Canada! http://linux.duke.edu/~icon/cajob.ptml From bill at noreboots.com Sun Feb 1 07:14:29 2004 From: bill at noreboots.com (Bill Anderson) Date: Sun, 01 Feb 2004 00:14:29 -0700 Subject: include much needed antivirus products in FC2 In-Reply-To: <1073326238.6652.55.camel@opus> References: <9811.212.93.39.38.1073307684.squirrel@www.tmus.dk> <20040105161105.1428506b.ms-nospam-0306@arcor.de> <3FF99B3B.6060300@get2net.dk> <1073324256.6652.45.camel@opus> <015a01c3d3b3$815f77b0$e2e8b1d8@adam12> <1073324763.6652.51.camel@opus> <016801c3d3b5$49c8bee0$e2e8b1d8@adam12> <1073326238.6652.55.camel@opus> Message-ID: <1075619669.1870.37.camel@locutus> On Mon, 2004-01-05 at 11:10, seth vidal wrote: > On Mon, 2004-01-05 at 12:55, Adam Debus wrote: > > > Then you're inappropriately increasing the load on a central machine > > > rather than decentralizing scanning to the desktop windows machine, > > > where it belongs. > > > > > > > Perhaps...but in 4 years of working at an ISP, I've discovered that most > > users do not install it no matter how many times you tell them that it's a > > good idea. I've got users I end up disconnecting and blocking from the 'net > > about once a week. Corporate LAN support wasn't much better. > > > > It doesn't add that much more load, and the benifits of having the mail > > scanned before it hits an end users machine greatly outweighs the cost of > > purchasing an additional processor, or a faster processor. That is, of > > course, assuming you're using the mail server for more then 10 people. If > > you're not, or you just don't want it, don't use the AV software. > > Try this sometime - process 100000+ pieces of mail a day and see if AV > scanning doesn't add much load? AV scanning centrally does NOT scale. Only 100K/day?? I've got "central" AV and spam scanning running on moderately sized (AKA powerful a few years ago) RH7.3 powered machines that are handling over a quarter million emails per day. No problems with load (other than the crap software we are currently purging from the system). I have this on four separate machines. Yes, it's a very busy domain. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From mharris at redhat.com Sun Feb 1 08:35:46 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 1 Feb 2004 03:35:46 -0500 (EST) Subject: rawhide report: 20040128 changes In-Reply-To: <1075369463.3199.59.camel@roque> References: <200401281632.i0SGWnl16833@porkchop.devel.redhat.com> <1075308747.8560.21.camel@skilletinfopleasecom.nh.pearsoned.com> <40180CFB.4000507@togami.com> <1075318240.8696.63.camel@roque> <1075318990.24709.1.camel@localhost.localdomain> <1075319222.8696.70.camel@roque> <1075369463.3199.59.camel@roque> Message-ID: On Thu, 29 Jan 2004, Rui Miguel Seabra wrote: >> Mike A. Harris ftp://people.redhat.com/mharris >> OS Systems Engineer - XFree86 maintainer - Red Hat > >One thing I'm willing to test is 3D support for Radeon IGM cards (like >the one on my laptop). Since you're an XFree maintainer at RH, could you >help me test it without seriously breaking FC? Radeon IGP 3D support is not present in XFree86, including the upcoming 4.4.0 release. It is present only in DRI-CVS as experimental support which is in a developmental state. I do not have Radeon IGP hardware and do not generally use DRI-CVS except to cvs rdiff out bug fixes occasionally, and to occasionally check in bug fixes. The DRI project website has a lot of both developer and end user documentation on using DRI-CVS as well as binary driver snapshots. I can't help you directly to get it working, but if you follow the documentation and/or ask for help on the DRI mailing lists, someone might be able to help you to get it to work. Also, since I often get asked - I have no plans of including this into our XFree86 until it is considered stable and mainstream. With the current flux going on over at XFree86.org right now, it isn't even clear wether XFree86 will exist in a few months or not, so it could be a while before this is supported. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Feb 1 08:40:24 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 1 Feb 2004 03:40:24 -0500 (EST) Subject: Fedora Core 2 XFree86 plans, and XFree86 4.4.0 plans, etc. In-Reply-To: <20040129173100.GA1828@ee.oulu.fi> References: <1075273071.7060.39.camel@localhost.localdomain> <20040128231721.GB20622@redhat.com> <20040129173100.GA1828@ee.oulu.fi> Message-ID: On Thu, 29 Jan 2004, Pekka Pietikainen wrote: >> >RHL9 ok, on the proviso that someone checks that codebase out and makes >> >sure its safe. >> >> Alan's the only one I know with VIA EPIA hardware off the top of >> my mind. ;o) Oh, also, even if the kernel doesn't have the >> support, the driver should work 2D only, so X isn't dependant on >> the kernel support being there for driver operation, just for >> DRI. (I suspect you know that, but others reading are likely not >> to.) > >And asking people to just run a FC1 kernel on their RH9 box if they >absolutely must have 3D on their EPIA isn't completely unreasonable either. >Apart from the gcc32 dependancy (--nodeps or a fake package providing a >handy symlink :-) ) they work just fine (I do this to get aironets that have >visited a windows box and thus have received an updated firmware that >doesn't work with older linux drivers to work) Since the driver functions even when DRI isn't available, while I would prefer the kernel would be released beforehand with via support, it wouldn't hold me up. However, the likelyhood of a new kernel coming out with via DRM support sooner than a new XFree86 coming out with the driver is much higher. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From warren at togami.com Sun Feb 1 08:46:34 2004 From: warren at togami.com (Warren Togami) Date: Sat, 31 Jan 2004 22:46:34 -1000 Subject: rawhide report: 20040128 changes In-Reply-To: References: <200401281632.i0SGWnl16833@porkchop.devel.redhat.com> <1075308747.8560.21.camel@skilletinfopleasecom.nh.pearsoned.com> <40180CFB.4000507@togami.com> <1075318240.8696.63.camel@roque> <1075318990.24709.1.camel@localhost.localdomain> <1075319222.8696.70.camel@roque> <1075369463.3199.59.camel@roque> Message-ID: <401CBCEA.8080408@togami.com> Mike A. Harris wrote: > On Thu, 29 Jan 2004, Rui Miguel Seabra wrote: > > >>>Mike A. Harris ftp://people.redhat.com/mharris >>>OS Systems Engineer - XFree86 maintainer - Red Hat >> >>One thing I'm willing to test is 3D support for Radeon IGM cards (like >>the one on my laptop). Since you're an XFree maintainer at RH, could you >>help me test it without seriously breaking FC? > > > Radeon IGP 3D support is not present in XFree86, including the > upcoming 4.4.0 release. It is present only in DRI-CVS as > experimental support which is in a developmental state. > > I do not have Radeon IGP hardware and do not generally use > DRI-CVS except to cvs rdiff out bug fixes occasionally, and to > occasionally check in bug fixes. > > The DRI project website has a lot of both developer and end user > documentation on using DRI-CVS as well as binary driver > snapshots. I can't help you directly to get it working, but if > you follow the documentation and/or ask for help on the DRI > mailing lists, someone might be able to help you to get it to > work. > > Also, since I often get asked - I have no plans of including this > into our XFree86 until it is considered stable and mainstream. > With the current flux going on over at XFree86.org right now, it > isn't even clear wether XFree86 will exist in a few months or > not, so it could be a while before this is supported. > > May I also point out that this kind of non-canon package is exactly what we intended to exist in "Fedora Alternatives". I am thinking now that Alternatives will contain sub-projects like this, specifically packaged for Fedora Core by volunteers who actually use it, and either experimental in nature or conflicting in nature. Alternatives would be available in many non-canon apt/yum/up2date channels that you can add to your configurations and aside from being distributed from download.fedora.redhat.com you must rely entirely on the community developers for support. Warren From mharris at redhat.com Sun Feb 1 08:58:14 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 1 Feb 2004 03:58:14 -0500 (EST) Subject: 3Dfx DRI support, Glide3, and you In-Reply-To: <20040130204606.GC18301@devserv.devel.redhat.com> References: <20040130204606.GC18301@devserv.devel.redhat.com> Message-ID: On Fri, 30 Jan 2004, Alan Cox wrote: >> Essentially, Glide3 source code is rather insane, compiler picky, >> and gcc barfs on it nowadays. It was unmaintained upstream for 2 >> years, but we kept it because "it worked". Now, "it doesn't >> work", and is a zero-priority level package basically. > >It is maintained upstream curently. Daniel Borca and a few others rekindled Glide3, and eliminated the h3 lib. Supposedly all hardware works on the h5 lib now, and they've worked on it for quite a while, however it seems to have gone stale again now. I orignally planned on updating to the new sources however the build instructions included with the source no longer work as written. Couldn't find an alternate document present and so moved on. I really do not have a lot of time to dedicate to obsolete hardware support, even if I'd like to actually do it. Playing with the new Glide3 has been on my TODO list for over 6 months. Only now I'm realizing that it isn't going to happen as that list isn't getting shorter, and higher priority things are going on it at least once a week. That's why I decided to post here to see if anyone else is personally interested in getting their own fingers dirty. It's not that I'm not interested, but rather that it isn't a priority to me when stacked up against all other priorities, and so it isn't likely to happen anytime soon. >> not interested in becoming the upstream maintainer. That said, >> there are upstream people still working on Glide, however there >> are some "issues" with switching to the new code, including the >> fact it's never been widely deployed or tested yet. > >I have voodoo setups but I use the Mandrake X servers on them because >of RH limitations and lack of Glide2 packages. I can maybe take a look >at the Glide3 bits during FC2 at least I can test them If you're volunteering to put together a Glide2 rpm and maintain it in the distribution now, just notting to add the component in beehive, and dkl to add it in bugzilla. ;o) Let me know when it's built in rawhide and I will toggle the BuildVoodoo define in the XFree86.spec file to 1, and you wont need to use Mandrake's X server anymore. ;o) I recommend making the package "Exclusivearch: %{ix86}" or else you'll have to wait 3 hours for it to compile on s390. ;o) Adding Glide2 was another one of those low priority TODO list items that never made it up the priority list. However the more people willing to volunteer for stuff like this, the better we are able to support older/obsolete hardware if people really want it to be present, so I'm totally in favour of other people's contributions. Back to the Glide3 thing though... The time and effort required to update to the new Glide3 and get it going is probably not much different from the time needed to get the old one we have now compiling once again. Since the old one hasn't had bug reports in ages, and the new one is not widely used, I favoured keeping th old one until I had time to allocate to actually using the new one. Since that time never seems to come, my request for someone interested to come forward and get Glide3 working again can be extended to be either Glide3 - the old one or the new one. They needn't own the package, I'll still own it for now, but I wont have time to look into it with the pile of stuff I have on my plate right now, and with everything that is occuring in the XFree86 community right now. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From makgab at freemail.hu Sun Feb 1 09:03:01 2004 From: makgab at freemail.hu (MG) Date: Sun, 01 Feb 2004 10:03:01 +0100 Subject: umount filesystems crash... In-Reply-To: <20040130140600.7614.4475.Mailman@listman.back-rdu.redhat.com> References: <20040130140600.7614.4475.Mailman@listman.back-rdu.redhat.com> Message-ID: <401CC0C5.5070402@freemail.hu> fedora-devel-list-request at redhat.com wrote: > From: =?ISO-8859-1?Q?"Nils O." Sel=E5sdal?= > > >> Another P4 machine works! :o > > Did it crash or hang ? If it hangs, could it possibly be some nfs > I think it hang at "Unmounting filesystems...". But not allways! > server troubles ? Try the soft and intr mount options on nfs > filesystems.. > With RH9 it worked! The nfs is set for novell server (in /etc/fstab). Bye! Gabor From mrpenguin_2 at hotmail.com Sun Feb 1 09:27:23 2004 From: mrpenguin_2 at hotmail.com (James Wiecks) Date: Sun, 01 Feb 2004 09:27:23 +0000 Subject: Multiple OS Message-ID: Hi, I know this is dumb but, could I possible have this OS and XP on my system by repartitioning my hard drive? I dont want VMware because my computer is a piece of crap by standards of technology now but I love it... My computer is a Compaq Armada 175 series with 64 meg of RAM thanks for any help you can offer :) _________________________________________________________________ Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From mharris at redhat.com Sun Feb 1 09:34:47 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 1 Feb 2004 04:34:47 -0500 (EST) Subject: Upgrade of unmaintained packages In-Reply-To: References: Message-ID: On Fri, 30 Jan 2004, Aurelien Bompard wrote: >I have a question about distribution upgrade : how should we deal with >unmaintained packages which don't work in the new distribution ? Let's say >we have included a program in Extras (or main) and the project stops for >some reason. At some point in the future, the program will stop working >(API change, glibc upgrade, ...). How should we deal with such a package >(except not including it in the first place of course ;) ) ? >We could tell Anaconda to remove it (well I don't know much about Anaconda, >but I suppose it is possible), but what about online upgrades using yum or >apt ? If the package becomes unmaintained, as in "unmaintained rpm package that used to be maintained in the Fedora Project", then it makes the most sense to do what has been done for years in the OS itself. For a package which has had it's functionality replaced by another, sometimes we use Obsoletes in the new package. An example where that is good, is where 2 packages provide similar functionality, but you wouldn't want or need both installed at the same time. console-tools vs. kbd for example. For a package which has had it's functionality replaced by a new package but which someone might want to use the old one still, we should do absolutely nothing at all. An example of this would be "UW imap". We now have cyrus-imapd and dovecot imap servers. All 3 servers should easily co-exist should one desire to do so, and it's possible that one might want to leave UW imap installed and keep using it on an upgrade. For example, if someone uses UW imap and upgrades, they don't want some new imap server obsoleting their old one and uninstalling it, and then not allowing them to install the old one again. That would be very wrong and would upset people very badly. Don't do that. Even if we KNEW that the old package would break because of something, it is not right to Obsolete or remove it. Someone might fix it and recompile it, and be unable to update the new package. Trying to be too smart has concequences of the form of upset users. There is no perfect solution all around to the problem you propose. I think the solution we have used all along for years in the OS works good enough. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From warren at togami.com Sun Feb 1 09:49:17 2004 From: warren at togami.com (Warren Togami) Date: Sat, 31 Jan 2004 23:49:17 -1000 Subject: Multiple OS In-Reply-To: References: Message-ID: <401CCB9D.90809@togami.com> James Wiecks wrote: > Hi, > > I know this is dumb but, could I possible have this OS and XP on my > system by repartitioning my hard drive? I dont want VMware because my > computer is a piece of crap by standards of technology now but I love it... > > My computer is a Compaq Armada 175 series with 64 meg of RAM thanks for > any help you can offer :) > What you want is called "dual booting". The details of which are well documented in many places on the Internet. However, you have asked this on fedora-devel-list, which is for development discussion only. Please use fedora-list for user support issues like this. Other members of that list will help you if you phrase your question in the right way. Warren From wtogami at redhat.com Sun Feb 1 10:06:02 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 Feb 2004 00:06:02 -1000 Subject: Trouble with Cisco Airo MPI350 and kernel-2.6.1+ In-Reply-To: <20040127164031.GA13174@bellet.info> References: <4014AA49.8050800@redhat.com> <20040127164031.GA13174@bellet.info> Message-ID: <401CCF8A.2010406@redhat.com> Fabrice Bellet wrote: > Hi Warren, > > On Sun, Jan 25, 2004 at 07:48:57PM -1000, Warren Togami wrote: > >>IBM Thinkpad T41 >>Cisco Airo MPI350 802.11b Wireless >>PCIID: 0x14b9 0xa504 >>Kernel: Fedora rawhide 2.6.1-1.57 (Based on 2.6.2-rc1) >> >>http://bellet.info/~bellet/laptop/t40.html#wireless >>http://bellet.info/~bellet/laptop/airo.c-2.6.1-mm2.diff >>airo.ko does not support this Airo device, but with the addition of this >>patch it recognizes the device. > > > What is the firmware version (in /proc/driver/aironet/eth0/Status) ? 5.20.17 > Currently, only versions 5[b].00.xx are supported by this patch. More recent > firmwares changed the card's behaviour in a way that prevents it to > associate to the access point. But, I'm a bit surprised by this kind of > error, because, even with an unsupported firmware, I can set the WEP key > without error with iwconfig. I tested the following firmware versions and all failed identically to set the WEP key in Linux. 5.30.17 5.20.17 5.02.20 > > You may want to downgrade the firmware, if needed, with the ACU tool under > Windows _only_. You also can try to set the WEP key with ACU too. A linux > version of this tool is available for linux, from : > http://www.cisco.com/pcgi-bin/tablebuild.pl/aironet-utils-linux > This version works with the linux cisco driver, and also with airo. > Used the ACU tool under Windows XP for flashing the firmware. The newest firmware version that operates with your driver is: 5.00.03 Perhaps mention within a comment and/or config Help of your patch that the newest supported firmware is 5.00.03? That would save people like me a lot of time in the future... > Maybe this error occurs because no wep key has ever been stored in > the card's non-volatile memory. The cisco card has two locations to > store the wep keys : a volatile, and a non-volatile memory. The linux > driver sets the key in both places in writeWepKeyRid(), when perm=1. > You seem to have a problem to store the key in the non-volatile > location (WEP_PERM). The ACU program gives the possibility to choose > this location. > Tested this theory. It seems that airo is unable to set the WEP key after ACU has done so. So your airo driver is working with the 5.00.03 firmware, but there is this one remaining issue. notting at redhat.com mentioned it is failing to "rename" something but I cannot remember the details. During bootup it fails to recognize the airo device exists. iwconfig shows some weird "devXXXXX" device that is not associated with an ethX name. rmmod airo gets rid of it, and afterward ifup works. The "Set Mode" error is harmless. It subsequently works. Any ideas? Bringing up interface eth1: airo device eth1 does not seem to be present, delaying initialization [root at ibmlaptop root]# iwconfig eth1 Warning: Driver for device dev13905 has been compiled with version 16 of Wireless Extension, while this program is using version 15. Some things may be broken... dev13905 IEEE 802.11-DS ESSID:"tsunami" Mode:Managed Frequency:2.442GHz Access Point: FF:FF:FF:FF:FF:FF Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/0 Retry limit:16 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:176/0 Signal level:-105 dBm Noise level:-105 dBm Rx invalid nwid:154 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:171 Missed beacon:0 [root at ibmlaptop root]# rmmod airo airo: Unregistering dev13905 divert: freeing divert_blk for dev13905 [root at ibmlaptop root]# ifup eth1 Error for wireless request "Set Mode" (8B06) : SET failed on device eth1 ; Invalid argument. [root at ibmlaptop root]# iwconfig eth1 Warning: Driver for device eth1 has been compiled with version 16 of Wireless Extension, while this program is using version 15. Some things may be broken... eth1 IEEE 802.11-DS ESSID:"apophis" Nickname:"blah" Mode:Managed Frequency:2.412GHz Access Point: 00:0C:41:75:D4:02 Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/0 Retry limit:16 RTS thr:off Fragment thr:off Encryption key:****-****-** Security mode:open Power Management:off Link Quality:49/0 Signal level:-84 dBm Noise level:-98 dBm Rx invalid nwid:5 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:253 Missed beacon:0 Warren Togami wtogami at redhat.com From hvdkooij at vanderkooij.org Sun Feb 1 10:07:25 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Sun, 1 Feb 2004 11:07:25 +0100 (CET) Subject: Self-Introduction: Hugo van der Kooij Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Full legal name Hugo van der Kooij Country, City Maasland, the Netherlands Profession or Student status (Network) Support Engineer Company or School Q&I My goals in the Fedora Project 1. Publish sword and gnomesword packages. 2. Help out with some documentation if I find gaps that needs to be filled. (Working on RPM building at the moment.) 3. Test bugs and proposed solutions when possible and where needed. Historical qualifications * Done some documentation as shown on: http://hvdkooij.xs4all.nl/docs.nl.cms and othe parts of the website. * Done a good number of Alpha recompile actions and reported bugs (and possible soulutions if I happened to find them) upstream. * Worked out the bugs in sword and gnomesword SPEC files. * Needs encouragement every now and again. GPG: pub 1024R/E5270E09 1997-08-02 Hugo van der Kooij (Linux User Groups World Wide) Key fingerprint = 95 EC 31 DC A4 B5 98 98 87 41 99 73 28 FE CA 8B uid Hugo van der Kooij uid Hugo van der Kooij uid Hugo van der Kooij Regards, Hugo. - -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUBQBzP4aYKnAPlJw4JAQHbPQP/boYPJDo4toc1boklsYkXtMV6XKkD717l YaoF5/I5XxNPqiMFAhirCxL5fPxQ9gcmHe8HToe+dU0IflxnD2uF1gVx1w5tbTNT 9sjAcEFWnyZGoL7hJC7fdWyanOvPxhysvjca7rzB8+yJVWEdKyKdvy3icijej1e4 P8t5yDqdyY0= =OtDG -----END PGP SIGNATURE----- From buildsys at redhat.com Sun Feb 1 11:43:07 2004 From: buildsys at redhat.com (Build System) Date: Sun, 1 Feb 2004 06:43:07 -0500 Subject: rawhide report: 20040201 changes Message-ID: <200402011143.i11Bh7R03122@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20040201 ---------------------------- From lars at sm6rpz.se Sun Feb 1 12:40:31 2004 From: lars at sm6rpz.se (Lars E. Pettersson) Date: Sun, 01 Feb 2004 13:40:31 +0100 Subject: Nautilus toolbars In-Reply-To: References: <1075592741.3699.3.camel@aurora.localdomain> Message-ID: <1075639231.1104.23.camel@tux.home.rpz> On Sun, 2004-02-01 at 03:54, Gerald Henriksen wrote: > This is now correct behaviour. Nautilus is no longer going to mimic a > web browser but instead to return to the old way where each directory > opens a new window. How annoying, reminds me of old MS-Windows versions... Is it possible to revert this to the original behavior where it is opened in the same window? As far as I can tell there is nothing in the preferences menu to get the old way, sadly. Anyone who can tell me the idea behind open directories in new windows? Personally I think opening new directories in the same window is superior, just like tabbed browsing in web browsers. Is there a gconf key or something? /Lars -- Lars E. Pettersson From ms-nospam-0306 at arcor.de Sun Feb 1 12:53:53 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 1 Feb 2004 13:53:53 +0100 Subject: mplayer vs. xine In-Reply-To: <401C6BC1.8040600@togami.com> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> Message-ID: <20040201135353.2b243d48.ms-nospam-0306@arcor.de> On Sat, 31 Jan 2004 17:00:17 -1000, Warren Togami wrote: > Eric S. Raymond wrote: > > > > I think libdcvss is already in livna's xine set. Carrying > > flash-plugin would be a good idea, though. > > Redistribution of flash-plugin is completely illegal under Macromedia's > EULA, and also and unneeded since Macromedia has given me special > permission to maintain RPM packages and apt/yum/urpmi repositories for > the plugin. > > http://macromedia.mplug.org It would be *much* better if the same packages could be included within a repository like rpm.livna.org, so the user doesn't need to maintain an increasing list of repositories for individual packages. -- From julo at altern.org Sun Feb 1 13:00:39 2004 From: julo at altern.org (Julien Olivier) Date: Sun, 01 Feb 2004 13:00:39 +0000 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <20040201135353.2b243d48.ms-nospam-0306@arcor.de> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> Message-ID: <1075640439.11711.5.camel@localhost.localdomain> > It would be *much* better if the same packages could be included within a > repository like rpm.livna.org, so the user doesn't need to maintain an > increasing list of repositories for individual packages. Maybe something even better: isn't it possible for a repository to automatically include another repository. For example, it would be great if one repository could "depend" on more repositories (rpm.livna.org, macromedia.mplug.org, jpackage.org etc...) so that end-users would only have to add 1 line in there yum.conf and still get packages from many repositories. It would be a kind of meta-repository. Is it already do-able in apt/yum or should I file a request for enhancement ? -- Julien Olivier From mharris at redhat.com Sun Feb 1 13:18:39 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 1 Feb 2004 08:18:39 -0500 (EST) Subject: Nautilus toolbars In-Reply-To: <1075639231.1104.23.camel@tux.home.rpz> References: <1075592741.3699.3.camel@aurora.localdomain> <1075639231.1104.23.camel@tux.home.rpz> Message-ID: On Sun, 1 Feb 2004, Lars E. Pettersson wrote: >> This is now correct behaviour. Nautilus is no longer going to mimic a >> web browser but instead to return to the old way where each directory >> opens a new window. > >How annoying, reminds me of old MS-Windows versions... Is it possible to >revert this to the original behavior where it is opened in the same >window? As far as I can tell there is nothing in the preferences menu to >get the old way, sadly. > >Anyone who can tell me the idea behind open directories in new windows? >Personally I think opening new directories in the same window is >superior, just like tabbed browsing in web browsers. Is there a gconf >key or something? I agree, that would be incredibly annoying. I'm not a tonnes-of-windows kind of guy myself. I'm probably not the target user of nautilus either though, but then I don't use it at all because I can't do what I need to do in it. It's nice for beginners though. I recommend using Midnight Commander (mc) in a konsole shell instead for more advanced functionality. Works great, plus if it's your regular filemanager, you can use it over a network easily also as a one-size-fits-all solution. Not sure what running nautilus over CIPE over the internet would be like, but I don't think it'd be fun. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From fastlanwan at yahoo.com Sun Feb 1 13:33:44 2004 From: fastlanwan at yahoo.com (fastlanwan) Date: Sun, 1 Feb 2004 05:33:44 -0800 (PST) Subject: Broadcom wireless 11g chipset Message-ID: <20040201133344.42024.qmail@web9604.mail.yahoo.com> Is there any plan on including a drv (via the 2.6.x kernel or other means) for the Broadcom wireless line of products, specifically the wireless 802.11g chipset in the Core 2 release? I ask for two reasons: 1. That's whats on my system board so I can't get linux online until my wireless adapter works. The 3rd party solutions just don't seem to work. 2. Broadcom is the largest producer of wireless chipsets for SOHO devices. I would think there would be some level of support and that it would be ongoing. Thanks for your time, Dan --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvdkooij at vanderkooij.org Sun Feb 1 13:39:44 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Sun, 1 Feb 2004 14:39:44 +0100 (CET) Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075640439.11711.5.camel@localhost.localdomain> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> Message-ID: On Sun, 1 Feb 2004, Julien Olivier wrote: > > It would be *much* better if the same packages could be included within a > > repository like rpm.livna.org, so the user doesn't need to maintain an > > increasing list of repositories for individual packages. > > Maybe something even better: isn't it possible for a repository to > automatically include another repository. For example, it would be great > if one repository could "depend" on more repositories (rpm.livna.org, > macromedia.mplug.org, jpackage.org etc...) so that end-users would only > have to add 1 line in there yum.conf and still get packages from many > repositories. It would be a kind of meta-repository. Preferably with a an option to do this on a package by package basis. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From arvindn at meenakshi.cs.iitm.ernet.in Sun Feb 1 13:25:21 2004 From: arvindn at meenakshi.cs.iitm.ernet.in (Arvind Narayanan) Date: Sun, 1 Feb 2004 18:55:21 +0530 Subject: mplayer vs. xine In-Reply-To: <401C7118.50306@linux.duke.edu>; from icon@linux.duke.edu on Sat, Jan 31, 2004 at 10:23:04PM -0500 References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> <401C7118.50306@linux.duke.edu> Message-ID: <20040201185521.A14991@meenakshi.cs.iitm.ernet.in> On Sat, Jan 31, 2004 at 10:23:04PM -0500, Konstantin Riabitsev wrote: [snip] > However, distributing proprietary packages without having a license > to distribute them would be a violation of international copyrights, > which is a criminal offense in most of the civilized world. As long ^^^^^^^^^ Is the implication intentional? Just curious. Arvind -- Its all GNU to me From hetz at softier.com Sun Feb 1 13:37:09 2004 From: hetz at softier.com (Hetz Ben Hamo) Date: Sun, 01 Feb 2004 15:37:09 +0200 Subject: Broadcom wireless 11g chipset In-Reply-To: <20040201133344.42024.qmail@web9604.mail.yahoo.com> References: <20040201133344.42024.qmail@web9604.mail.yahoo.com> Message-ID: <200402011537.09844.hetz@softier.com> And do you have such a driver as open source handy? I'm sure I'm not the only person who would love to have it ;) Thanks, Hetz On Sunday 01 February 2004 15:33, fastlanwan wrote: > Is there any plan on including a drv (via the 2.6.x kernel or other means) > for the Broadcom wireless line of products, specifically the wireless > 802.11g chipset in the Core 2 release? > > I ask for two reasons: > > 1. That's whats on my system board so I can't get linux online until my > wireless adapter works. The 3rd party solutions just don't seem to work. > > 2. Broadcom is the largest producer of wireless chipsets for SOHO devices. > I would think there would be some level of support and that it would be > ongoing. > > Thanks for your time, > > Dan > > > --------------------------------- > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! From jspaleta at princeton.edu Sun Feb 1 14:36:16 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Sun, 01 Feb 2004 09:36:16 -0500 Subject: gaim security Message-ID: <1075646176.29529.3.camel@goober.localdomain> Leonard den Ottolander wrote: > It probably should be moved to the main tree as it has been in testing > for over 2 weeks Looking at the changelog of the gaim in fedora core 1 updates testing and looking at the changelog for the rhl9 errata. It seems naively to me that the gaim in testing doesn't have the security patch applied. So I don't think it's just a matter of moving the one in testing to released. I think there needs to be a new package build for fedora. -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 steve at rueb.com Sun Feb 1 15:06:03 2004 From: steve at rueb.com (Steve Bergman) Date: Sun, 01 Feb 2004 09:06:03 -0600 Subject: Prelink hosed my binaries? Message-ID: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> Anyone else wake up to a totally hosed system this morning? A substantial portion of my binaries (including bash) are wrecked and show up as "data" when I use the "file" command on them. No ELF header at all. Everything was fine last night. I'm assuming prelink was the culprit. However, last time prelink was updated was 2 days ago, not 1, so last night would have been the second time it was run, not the first. Weird... From alan at redhat.com Sun Feb 1 15:07:36 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Feb 2004 10:07:36 -0500 Subject: mplayer vs. xine In-Reply-To: <1075546815.8421.2.camel@localhost.localdomain> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130140021.A14192@meenakshi.cs.iitm.ernet.in> <1075466753.5020.101.camel@localhost.localdomain> <20040130205222.GE18301@devserv.devel.redhat.com> <1075546815.8421.2.camel@localhost.localdomain> Message-ID: <20040201150736.GC30540@devserv.devel.redhat.com> On Sat, Jan 31, 2004 at 12:00:16PM +0100, Tony Grant wrote: > > xine has a variant that already does. Just needs the reverse engineered > > libddmpeg work and my surfaces rewrite for via and some oddments to > > make it work open source > > You mean ViacripplEdXinePlayer a.k.a VeXP=:-p > > Been there, tried that. When it doesn't crash and burn and when it > allows DVB-S playback I'll look again. Well its up to someone like you who cares to port the fixes into a current Xine. From rms at 1407.org Sun Feb 1 15:08:58 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 01 Feb 2004 15:08:58 +0000 Subject: rawhide report: 20040128 changes In-Reply-To: References: <200401281632.i0SGWnl16833@porkchop.devel.redhat.com> <1075308747.8560.21.camel@skilletinfopleasecom.nh.pearsoned.com> <40180CFB.4000507@togami.com> <1075318240.8696.63.camel@roque> <1075318990.24709.1.camel@localhost.localdomain> <1075319222.8696.70.camel@roque> <1075369463.3199.59.camel@roque> Message-ID: <1075648137.3483.3.camel@roque> Thank you for the indications, Mike. On Sun, 2004-02-01 at 08:35, Mike A. Harris wrote: > With the current flux going on over at XFree86.org right now, it > isn't even clear wether XFree86 will exist in a few months or > not, so it could be a while before this is supported. Oh, it is not essential for me, since it would only be used for Celestia or playing games in the laptop. But all this I can still do on the "old" desktop anyway. Thanks, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Sun Feb 1 15:25:21 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Feb 2004 10:25:21 -0500 Subject: mplayer vs. xine In-Reply-To: <20040131212544.GB10087@thyrsus.com> References: <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> Message-ID: <20040201152521.GF30540@devserv.devel.redhat.com> On Sat, Jan 31, 2004 at 04:25:45PM -0500, Eric S. Raymond wrote: > These are what I called technical restrictions on redistribution. If > livna.org is willing to run afoul of patents and the DMCA to distribute > libdvdcss, it's hard to believe they'd balk at violating these. But I'll ask. DMCA is a US disease as are most of the patents. Ignoring stupid US regulation outside the USA is *NOT* the same kind of thing as violating contracts or copyrights. > > 4. About the codecs, I find it _very_ hard to believe that Microsoft for > > one would be OK with redistributing Windows Media binary dlls? > > Do the terms on their site say you can't pass around copies of the > zipfile? I don't think so... Do they say you can ? You need permission for the act of copying when you duplicate the copy. You may be able to download 50,000 copies from microsoft.com and give them to 50000 people but thats different From alan at redhat.com Sun Feb 1 15:29:41 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Feb 2004 10:29:41 -0500 Subject: Nautilus toolbars In-Reply-To: References: <1075592741.3699.3.camel@aurora.localdomain> Message-ID: <20040201152941.GG30540@devserv.devel.redhat.com> On Sat, Jan 31, 2004 at 09:54:17PM -0500, Gerald Henriksen wrote: > >I am not sure whether or not to post this as a bug, but in the devel > >series of Fedora, the location bar and tool bars in Nautilus seem to be > >gone. > > This is now correct behaviour. Nautilus is no longer going to mimic a > web browser but instead to return to the old way where each directory > opens a new window. Is anyone maintaining a fork of Nautilus that behaves like well.. nautilus ? or is there a configuration option to get sanity back From alan at redhat.com Sun Feb 1 15:33:20 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Feb 2004 10:33:20 -0500 Subject: 3Dfx DRI support, Glide3, and you In-Reply-To: References: <20040130204606.GC18301@devserv.devel.redhat.com> Message-ID: <20040201153320.GH30540@devserv.devel.redhat.com> On Sun, Feb 01, 2004 at 03:58:14AM -0500, Mike A. Harris wrote: > If you're volunteering to put together a Glide2 rpm and maintain > it in the distribution now, just notting to add the component in > beehive, and dkl to add it in bugzilla. ;o) Let me know when > it's built in rawhide and I will toggle the BuildVoodoo define in > the XFree86.spec file to 1, and you wont need to use Mandrake's X > server anymore. ;o) Glide2 is extras material I think, but since I just regenerate the Mandrake one each time its not too hard to maintain unless they drop support > Adding Glide2 was another one of those low priority TODO list > items that never made it up the priority list. However the more I'm hoping to eliminate the need for glide2 fairly soon > to update to the new Glide3 and get it going is probably not much > different from the time needed to get the old one we have now > compiling once again. Since the old one hasn't had bug reports I'll take a look if I get time. I've got 4500 test hardware and the like for Glide3 and also hardware docs to some of the chips From leonard at den.ottolander.nl Sun Feb 1 15:53:28 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 01 Feb 2004 16:53:28 +0100 Subject: Open security issues [was: gaim security] In-Reply-To: <1075646176.29529.3.camel@goober.localdomain> References: <1075646176.29529.3.camel@goober.localdomain> Message-ID: <1075650808.4782.133.camel@athlon.localdomain> Hi Jef, > Looking at the changelog of the gaim in fedora core 1 updates testing > and looking at the changelog for the rhl9 errata. It seems naively to me > that the gaim in testing doesn't have the security patch applied. So > I don't think it's just a matter of moving the one in testing to > released. I think there needs to be a new package build for fedora. I must have misread this. I thought the "large memory leak" was the issue, and solved in 0.75, but the RH9 changelog suggests that there are other issues with 0.75 as well. It seems like the Security Response Team is busy elsewhere. Is anybody else aware of security issues that are still pending? (mc seems to be rolling.) Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From esr at thyrsus.com Sun Feb 1 15:51:42 2004 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 1 Feb 2004 10:51:42 -0500 Subject: mplayer vs. xine In-Reply-To: <20040201135353.2b243d48.ms-nospam-0306@arcor.de> References: <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> Message-ID: <20040201155142.GC9717@thyrsus.com> Michael Schwendt : > On Sat, 31 Jan 2004 17:00:17 -1000, Warren Togami wrote: > > > Eric S. Raymond wrote: > > > > > > I think libdcvss is already in livna's xine set. Carrying > > > flash-plugin would be a good idea, though. > > > > Redistribution of flash-plugin is completely illegal under Macromedia's > > EULA, and also and unneeded since Macromedia has given me special > > permission to maintain RPM packages and apt/yum/urpmi repositories for > > the plugin. > > > > http://macromedia.mplug.org > > It would be *much* better if the same packages could be included within a > repository like rpm.livna.org, so the user doesn't need to maintain an > increasing list of repositories for individual packages. Indeed. Warren, can you move thiose RPMs into livna or Fedora? -- Eric S. Raymond From alan at redhat.com Sun Feb 1 15:55:56 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Feb 2004 10:55:56 -0500 Subject: mplayer vs. xine In-Reply-To: <20040201155142.GC9717@thyrsus.com> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <20040201155142.GC9717@thyrsus.com> Message-ID: <20040201155556.GA13995@devserv.devel.redhat.com> On Sun, Feb 01, 2004 at 10:51:42AM -0500, Eric S. Raymond wrote: > > It would be *much* better if the same packages could be included within a > > repository like rpm.livna.org, so the user doesn't need to maintain an > > increasing list of repositories for individual packages. > > Indeed. Warren, can you move thiose RPMs into livna or Fedora? It is better IMHO to keep proprietary software seperate. From g.magnini at tiscali.it Sun Feb 1 16:05:04 2004 From: g.magnini at tiscali.it (Giacomo Magnini) Date: Sun, 01 Feb 2004 17:05:04 +0100 Subject: bug 84014 (sonet.h) Message-ID: <401D23B0.5000409@tiscali.it> Any chance this will be fixed for FC2? TIA, Giacomo. From ms-nospam-0306 at arcor.de Sun Feb 1 16:28:29 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 1 Feb 2004 17:28:29 +0100 Subject: mplayer vs. xine In-Reply-To: <20040201155556.GA13995@devserv.devel.redhat.com> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <20040201155142.GC9717@thyrsus.com> <20040201155556.GA13995@devserv.devel.redhat.com> Message-ID: <20040201172829.61664532.ms-nospam-0306@arcor.de> On Sun, 1 Feb 2004 10:55:56 -0500, Alan Cox wrote: > On Sun, Feb 01, 2004 at 10:51:42AM -0500, Eric S. Raymond wrote: > > > It would be *much* better if the same packages could be included within a > > > repository like rpm.livna.org, so the user doesn't need to maintain an > > > increasing list of repositories for individual packages. > > > > Indeed. Warren, can you move thiose RPMs into livna or Fedora? > > It is better IMHO to keep proprietary software seperate. Which is the reason why fedora.us doesn't contain such software. rpm.livna.org, however, is a place which contains some proprietary software, too, and not just software with patenting or licencing concerns. -- From ByteEnable at austin.rr.com Sun Feb 1 16:40:05 2004 From: ByteEnable at austin.rr.com (ByteEnable) Date: Sun, 01 Feb 2004 10:40:05 -0600 Subject: kernel 2.6.1-1.65 and VIA Apollo Pro266T AGP In-Reply-To: <20040201172829.61664532.ms-nospam-0306@arcor.de> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <20040201155142.GC9717@thyrsus.com> <20040201155556.GA13995@devserv.devel.redhat.com> <20040201172829.61664532.ms-nospam-0306@arcor.de> Message-ID: <1075653605.3083.5.camel@ByteEnable> Hi All, I get random ascii characters on the screen and the system freezes when using the newest NVIDIA driver (5536) and kernel 2.6.1-1.65. The error happens when X tries to load. I checked kernel.org and did not see any bugs in bugzilla. However, I did find this: http://minion.de/ "Linux 2.6 AGPGART seems to be broken on some chipsets. If you find that your system hangs upon starting X, potentially with ASCII garbage all over the screen, try the built-in NVIDIA AGP GART driver (Option "NvAgp" "1", AGPGART not loaded) instead." Has anyone else see this problem? Byte From ByteEnable at austin.rr.com Sun Feb 1 16:43:32 2004 From: ByteEnable at austin.rr.com (ByteEnable) Date: Sun, 01 Feb 2004 10:43:32 -0600 Subject: Broadcom wireless 11g chipset In-Reply-To: <200402011537.09844.hetz@softier.com> References: <20040201133344.42024.qmail@web9604.mail.yahoo.com> <200402011537.09844.hetz@softier.com> Message-ID: <1075653812.3083.8.camel@ByteEnable> I know of a driver at www.linuxant.com. They want $20.00 for it though. It works. You can get a 30 day free trial. Byte On Sun, 2004-02-01 at 07:37, Hetz Ben Hamo wrote: > And do you have such a driver as open source handy? I'm sure I'm not the only > person who would love to have it ;) > > Thanks, > Hetz > > On Sunday 01 February 2004 15:33, fastlanwan wrote: > > Is there any plan on including a drv (via the 2.6.x kernel or other means) > > for the Broadcom wireless line of products, specifically the wireless > > 802.11g chipset in the Core 2 release? > > > > I ask for two reasons: > > > > 1. That's whats on my system board so I can't get linux online until my > > wireless adapter works. The 3rd party solutions just don't seem to work. > > > > 2. Broadcom is the largest producer of wireless chipsets for SOHO devices. > > I would think there would be some level of support and that it would be > > ongoing. > > > > Thanks for your time, > > > > Dan > > > > > > --------------------------------- > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free web site building tool. Try it! > From julo at altern.org Sun Feb 1 17:52:44 2004 From: julo at altern.org (Julien Olivier) Date: Sun, 01 Feb 2004 17:52:44 +0000 Subject: Nautilus toolbars In-Reply-To: <20040201152941.GG30540@devserv.devel.redhat.com> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> Message-ID: <1075657964.4377.3.camel@localhost.localdomain> > Is anyone maintaining a fork of Nautilus that behaves like well.. nautilus ? > or is there a configuration option to get sanity back Actually, Nautilus now has 2 modes: navigational or spatial. If you double-click on a folder on the desktop, it will open it in spatial mode (one window == one folder). But you can also launch Nautilus from the apps menu in navigational mode (mostly the same behavior as Nautilus 2.4). And I'm pretty sure that you can also switch from spatial to navigational mode when browsing a folder (right click -> browse ?). -- Julien Olivier From salimma at fastmail.fm Sun Feb 1 18:01:45 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Mon, 02 Feb 2004 01:01:45 +0700 Subject: Nautilus toolbars In-Reply-To: <1075657964.4377.3.camel@localhost.localdomain> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> <1075657964.4377.3.camel@localhost.localdomain> Message-ID: <1075658505.4033.4.camel@localhost.localdomain> On Sun, 2004-02-01 at 17:52 +0000, Julien Olivier wrote: [snip] > 2.4). And I'm pretty sure that you can also switch from spatial to > navigational mode when browsing a folder (right click -> browse ?). > AFAICS 'browse' is only available when right-clicking on desktop icons. It would be nice to have the following: - 'browse' option for folders everywhere - an option to open folders in the same Nautilus window but with the feature freeze it's probably too late. Ah well. Is it me, or does the 2.5.x Nautilus resemble ROX-Filer quite a bit? - 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 pmatilai at welho.com Sun Feb 1 18:10:26 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sun, 01 Feb 2004 20:10:26 +0200 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075640439.11711.5.camel@localhost.localdomain> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> Message-ID: <1075659026.28936.2.camel@chip.laiskiainen.org> On Sun, 2004-02-01 at 15:00, Julien Olivier wrote: > > It would be *much* better if the same packages could be included within a > > repository like rpm.livna.org, so the user doesn't need to maintain an > > increasing list of repositories for individual packages. > > Maybe something even better: isn't it possible for a repository to > automatically include another repository. For example, it would be great > if one repository could "depend" on more repositories (rpm.livna.org, > macromedia.mplug.org, jpackage.org etc...) so that end-users would only > have to add 1 line in there yum.conf and still get packages from many > repositories. It would be a kind of meta-repository. > > Is it already do-able in apt/yum or should I file a request for > enhancement ? Apt supports "meta-repositories" but only within a single server so it's not really what you're asking for. Something like this could be done in the mirror-selector (in fedora.us apt) but more generally support for this could be included in the common repository metadata system. - Panu - From lars at sm6rpz.se Sun Feb 1 18:19:26 2004 From: lars at sm6rpz.se (Lars E. Pettersson) Date: Sun, 01 Feb 2004 19:19:26 +0100 Subject: Nautilus toolbars In-Reply-To: <1075658505.4033.4.camel@localhost.localdomain> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> <1075657964.4377.3.camel@localhost.localdomain> <1075658505.4033.4.camel@localhost.localdomain> Message-ID: <1075659566.1104.39.camel@tux.home.rpz> On Sun, 2004-02-01 at 19:01, Michel Alexandre Salim wrote: > AFAICS 'browse' is only available when right-clicking on desktop icons. Just noticed that one can get the 2.4-behavior by starting it with "nautilus --browser" The question now is how to make this the default... /Lars -- Lars E. Pettersson From zaitcev at redhat.com Sun Feb 1 18:27:47 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sun, 1 Feb 2004 10:27:47 -0800 Subject: bug 84014 (sonet.h) In-Reply-To: References: Message-ID: <20040201102747.0989eb6c.zaitcev@redhat.com> On Sun, 01 Feb 2004 17:05:04 +0100 Giacomo Magnini wrote: > Any chance this will be fixed for FC2? Did you try glibc-kernelheaders from Rawhide? It seems fixed in glibc-kernheaders-2.4-8.43.i386.rpm which I downloaded a minute ago. -- Pete From salimma at fastmail.fm Sun Feb 1 18:40:02 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Mon, 02 Feb 2004 01:40:02 +0700 Subject: Nautilus toolbars In-Reply-To: <1075659566.1104.39.camel@tux.home.rpz> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> <1075657964.4377.3.camel@localhost.localdomain> <1075658505.4033.4.camel@localhost.localdomain> <1075659566.1104.39.camel@tux.home.rpz> Message-ID: <1075660802.4430.2.camel@localhost.localdomain> On Sun, 2004-02-01 at 19:19 +0100, Lars E. Pettersson wrote: > On Sun, 2004-02-01 at 19:01, Michel Alexandre Salim wrote: > > AFAICS 'browse' is only available when right-clicking on desktop icons. > > Just noticed that one can get the 2.4-behavior by starting it with > "nautilus --browser" The question now is how to make this the > default... > - Preferences->More Preferences->Sessions->Current Session - Highlight nautilus, Remove, Apply, Close - Run nautilus --browser from Foot->Run - Go back to Current Session, make sure nautilus --browser is set to automatically restart itself That *should* work. I'd like to play with the new mode for a while though - it seems much less cluttered. - 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 g.magnini at tiscali.it Sun Feb 1 18:38:49 2004 From: g.magnini at tiscali.it (Giacomo Magnini) Date: Sun, 01 Feb 2004 19:38:49 +0100 Subject: bug 84014 (sonet.h) In-Reply-To: <20040201102747.0989eb6c.zaitcev@redhat.com> References: <20040201102747.0989eb6c.zaitcev@redhat.com> Message-ID: <401D47B9.3080603@tiscali.it> Pete Zaitcev wrote: >Did you try glibc-kernelheaders from Rawhide? It seems fixed in >glibc-kernheaders-2.4-8.43.i386.rpm which I downloaded a minute ago. > > I'll check, thanks for the infos. Cheers, Giacomo. From robert at marcanoonline.com Sun Feb 1 18:46:26 2004 From: robert at marcanoonline.com (Robert Marcano) Date: Sun, 01 Feb 2004 14:46:26 -0400 Subject: Nautilus toolbars In-Reply-To: <1075659566.1104.39.camel@tux.home.rpz> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> <1075657964.4377.3.camel@localhost.localdomain> <1075658505.4033.4.camel@localhost.localdomain> <1075659566.1104.39.camel@tux.home.rpz> Message-ID: <1075661186.4675.4.camel@pcrobert.intranet.promca.com> On Sun, 2004-02-01 at 14:19, Lars E. Pettersson wrote: > On Sun, 2004-02-01 at 19:01, Michel Alexandre Salim wrote: > > AFAICS 'browse' is only available when right-clicking on desktop icons. > > Just noticed that one can get the 2.4-behavior by starting it with > "nautilus --browser" The question now is how to make this the > default... > > /Lars try editing the file /usr/share/gnome/default.session or ~/.gnome2/session > -- > Lars E. Pettersson _____________________________ Robert Marcano Programaci?n Mecanizada, C.A. email: robmv at promca.com web: http://www.promca.com _____________________________ From alan at redhat.com Sun Feb 1 19:38:27 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Feb 2004 14:38:27 -0500 Subject: Nautilus toolbars In-Reply-To: <1075658505.4033.4.camel@localhost.localdomain> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> <1075657964.4377.3.camel@localhost.localdomain> <1075658505.4033.4.camel@localhost.localdomain> Message-ID: <20040201193827.GA17792@devserv.devel.redhat.com> On Mon, Feb 02, 2004 at 01:01:45AM +0700, Michel Alexandre Salim wrote: > but with the feature freeze it's probably too late. Ah well. > > Is it me, or does the 2.5.x Nautilus resemble ROX-Filer net> quite a bit? It does - its now much like the Acorn filer, which I didn't like 8). Rox has switches to turn off the spacial type mode however. (In fact Rox has been getting more and more nautilus like, now they seem to have crossed 8)) I use rox on things with low memory. Tis great From skvidal at phy.duke.edu Sun Feb 1 19:39:00 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 01 Feb 2004 14:39:00 -0500 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075659026.28936.2.camel@chip.laiskiainen.org> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> Message-ID: <1075664339.24061.6.camel@binkley> > Apt supports "meta-repositories" but only within a single server so it's > not really what you're asking for. Something like this could be done in > the mirror-selector (in fedora.us apt) but more generally support for > this could be included in the common repository metadata system. Maybe we should start taking some of the things I've heard and compiling ideas for a ver 2. of the metadata stuff? things I've heard so far: - common format for repository information - meta-repositories (or repository groups) - common group format -sv From ee21rh at eim.surrey.ac.uk Sun Feb 1 19:47:38 2004 From: ee21rh at eim.surrey.ac.uk (Richard) Date: Sun, 01 Feb 2004 19:47:38 +0000 Subject: session setup error with cifs In-Reply-To: <20040201164004.24671.34751.Mailman@listman.back-rdu.redhat.com> References: <20040201164004.24671.34751.Mailman@listman.back-rdu.redhat.com> Message-ID: <1075664858.4118.2.camel@hughsie-laptop> Since smbfs has been removed from the 2.6.1 kernel, I could no longer use smbfs and am forced to change to cifs. None of my shares on different machines will mount. I've changed my fstab to read "user=" from "username=" and "smbfs" to "cifs" - but still no mounting. I'm all upgraded against development since today. #mount /mnt/hughsie/albums/ Message displayed on screen: mount: block device //hughsie/albums is write-protected, mounting read- only mount: cannot mount block device //hughsie/albums read-only Messages in /var/log/messages Feb 1 19:32:02 hughsie-laptop kernel: CIFS VFS: Send error in SessSetup = -13 Feb 1 19:32:02 hughsie-laptop kernel: CIFS VFS: cifs_mount failed w/ return code = -13 Feb 1 19:32:03 hughsie-laptop kernel: CIFS VFS: Send error in SessSetup = -13 Feb 1 19:32:03 hughsie-laptop kernel: CIFS VFS: cifs_mount failed w/ return code = -13 Entry in /etc/fstab on laptop: //hughsie/albums /mnt/hughsie/albums cifs noauto,rw,user=lan, password=secret 0 0 Entry in /etc/samba/smb.conf on server: [albums] comment = Albums path = /mnt/data/albums writeable = yes I need to use this share - and I the only way I can mount it is to use 2.6.1-1.47 with smbfs. Return code = -13 is hardly usefull! Google didn't seem to help, but the samba website suggested I should have a mount.cifs in /sbin - and an associated manpage. Any ideas - thanks for any input. Hughsie From pmatilai at welho.com Sun Feb 1 20:04:16 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sun, 01 Feb 2004 22:04:16 +0200 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075664339.24061.6.camel@binkley> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> Message-ID: <1075665856.28936.14.camel@chip.laiskiainen.org> On Sun, 2004-02-01 at 21:39, seth vidal wrote: > > Apt supports "meta-repositories" but only within a single server so it's > > not really what you're asking for. Something like this could be done in > > the mirror-selector (in fedora.us apt) but more generally support for > > this could be included in the common repository metadata system. > > Maybe we should start taking some of the things I've heard and compiling > ideas for a ver 2. of the metadata stuff? Sure. If the items aren't collected as they come up they get forgotten and we need to reinvite them sometime later :) > > things I've heard so far: > - common format for repository information I suppose this covers things like mirror information? If not that should be added separately. > > - meta-repositories (or repository groups) > - common group format Yep.. hmm.. I think I had some other ideas as well but can't remember now/anymore :-/ - Panu - From salimma at fastmail.fm Sun Feb 1 20:12:24 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Mon, 02 Feb 2004 03:12:24 +0700 Subject: Nautilus toolbars In-Reply-To: <20040201193827.GA17792@devserv.devel.redhat.com> References: <1075592741.3699.3.camel@aurora.localdomain> <20040201152941.GG30540@devserv.devel.redhat.com> <1075657964.4377.3.camel@localhost.localdomain> <1075658505.4033.4.camel@localhost.localdomain> <20040201193827.GA17792@devserv.devel.redhat.com> Message-ID: <1075666344.6257.0.camel@localhost.localdomain> On Sun, 2004-02-01 at 14:38 -0500, Alan Cox wrote: > On Mon, Feb 02, 2004 at 01:01:45AM +0700, Michel Alexandre Salim wrote: > > but with the feature freeze it's probably too late. Ah well. > > > > Is it me, or does the 2.5.x Nautilus resemble ROX-Filer > net> quite a bit? > > It does - its now much like the Acorn filer, which I didn't like 8). Rox > has switches to turn off the spacial type mode however. (In fact Rox has > been getting more and more nautilus like, now they seem to have crossed 8)) > > I use rox on things with low memory. Tis great > And let's not forget App bundles :) - 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 salimma at fastmail.fm Sun Feb 1 20:14:32 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Mon, 02 Feb 2004 03:14:32 +0700 Subject: Nautilus toolbars In-Reply-To: <1075639231.1104.23.camel@tux.home.rpz> References: <1075592741.3699.3.camel@aurora.localdomain> <1075639231.1104.23.camel@tux.home.rpz> Message-ID: <1075666472.6257.3.camel@localhost.localdomain> On Sun, 2004-02-01 at 13:40 +0100, Lars E. Pettersson wrote: [snip] > Anyone who can tell me the idea behind open directories in new windows? > Personally I think opening new directories in the same window is > superior, just like tabbed browsing in web browsers. Is there a gconf > key or something? > I do hope there is one. Meanwhile, Shift+Ctrl+W (Close Parent Windows) is your friend. - 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 skvidal at phy.duke.edu Sun Feb 1 20:15:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 01 Feb 2004 15:15:35 -0500 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075665856.28936.14.camel@chip.laiskiainen.org> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> Message-ID: <1075666535.24061.15.camel@binkley> > I suppose this covers things like mirror information? If not that should > be added separately. > > > > > - meta-repositories (or repository groups) a thought here - what about having repository-wide-provides and repository-wide-dependencies? It'd be interesting to have: rpm.livna.org depends on fedora-core, fedora-extras would be hard to control, but potentially interesting. -sv From warren at togami.com Sun Feb 1 20:21:34 2004 From: warren at togami.com (Warren Togami) Date: Sun, 01 Feb 2004 10:21:34 -1000 Subject: mplayer vs. xine In-Reply-To: <20040201135353.2b243d48.ms-nospam-0306@arcor.de> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> Message-ID: <401D5FCE.4080605@togami.com> Michael Schwendt wrote: > On Sat, 31 Jan 2004 17:00:17 -1000, Warren Togami wrote: > > >>Eric S. Raymond wrote: >> >>>I think libdcvss is already in livna's xine set. Carrying >>>flash-plugin would be a good idea, though. >> >>Redistribution of flash-plugin is completely illegal under Macromedia's >>EULA, and also and unneeded since Macromedia has given me special >>permission to maintain RPM packages and apt/yum/urpmi repositories for >>the plugin. >> >>http://macromedia.mplug.org > > > It would be *much* better if the same packages could be included within a > repository like rpm.livna.org, so the user doesn't need to maintain an > increasing list of repositories for individual packages. > Their lawyers wouldn't like this... it took me 3 months of harassing the company in order for them to agree to even this much. Warren From warren at togami.com Sun Feb 1 20:24:16 2004 From: warren at togami.com (Warren Togami) Date: Sun, 01 Feb 2004 10:24:16 -1000 Subject: mplayer vs. xine In-Reply-To: <20040201155142.GC9717@thyrsus.com> References: <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <20040201155142.GC9717@thyrsus.com> Message-ID: <401D6070.6050605@togami.com> Eric S. Raymond wrote: > Michael Schwendt : > >>On Sat, 31 Jan 2004 17:00:17 -1000, Warren Togami wrote: >> >> >>>Eric S. Raymond wrote: >>> >>>>I think libdcvss is already in livna's xine set. Carrying >>>>flash-plugin would be a good idea, though. >>> >>>Redistribution of flash-plugin is completely illegal under Macromedia's >>>EULA, and also and unneeded since Macromedia has given me special >>>permission to maintain RPM packages and apt/yum/urpmi repositories for >>>the plugin. >>> >>>http://macromedia.mplug.org >> >>It would be *much* better if the same packages could be included within a >>repository like rpm.livna.org, so the user doesn't need to maintain an >>increasing list of repositories for individual packages. > > > Indeed. Warren, can you move thiose RPMs into livna or Fedora? I absolutely cannot and will not, due to legal reasons. Warren From anvil at livna.org Sun Feb 1 20:51:22 2004 From: anvil at livna.org (Dams) Date: Sun, 01 Feb 2004 21:51:22 +0100 Subject: mplayer vs. xine In-Reply-To: <20040131212544.GB10087@thyrsus.com> References: <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> Message-ID: <1075668682.12687.4509.camel@gruyere> DMCA doesnt apply here. Neither software patents does (so far). So we just get rid of those two "details". rpm.livna.org is not, i repeat, is NOT a warez site : we wont provide any mame rom, win32 non distributable dll, or Britney Spears mp3^WOgg Vorbis as rpm as long as they are _copyrighted_. And if you're just wondering, "here" is France. D Le sam 31/01/2004 ? 22:25, Eric S. Raymond a ?crit : > These are what I called technical restrictions on redistribution. If > livna.org is willing to run afoul of patents and the DMCA to distribute > libdvdcss, it's hard to believe they'd balk at violating these. But I'll ask. -- 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 wtogami at redhat.com Sun Feb 1 21:30:00 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 Feb 2004 11:30:00 -1000 Subject: Trouble with Cisco Airo MPI350 and kernel-2.6.1+ In-Reply-To: <401CCF8A.2010406@redhat.com> References: <4014AA49.8050800@redhat.com> <20040127164031.GA13174@bellet.info> <401CCF8A.2010406@redhat.com> Message-ID: <401D6FD8.2040406@redhat.com> Warren Togami wrote: > Fabrice Bellet wrote: > >> Hi Warren, >> >> On Sun, Jan 25, 2004 at 07:48:57PM -1000, Warren Togami wrote: >> >>> IBM Thinkpad T41 >>> Cisco Airo MPI350 802.11b Wireless >>> PCIID: 0x14b9 0xa504 >>> Kernel: Fedora rawhide 2.6.1-1.57 (Based on 2.6.2-rc1) >>> >>> http://bellet.info/~bellet/laptop/t40.html#wireless >>> http://bellet.info/~bellet/laptop/airo.c-2.6.1-mm2.diff >>> airo.ko does not support this Airo device, but with the addition of >>> this patch it recognizes the device. >> >> >> > [SNIP] > Used the ACU tool under Windows XP for flashing the firmware. The > newest firmware version that operates with your driver is: > 5.00.03 > > Perhaps mention within a comment and/or config Help of your patch that > the newest supported firmware is 5.00.03? That would save people like > me a lot of time in the future... > Are these many errors normal? [root at ibmlaptop etc]# iwconfig eth1 Warning: Driver for device eth1 has been compiled with version 16 of Wireless Extension, while this program is using version 15. Some things may be broken... eth1 IEEE 802.11-DS ESSID:"apophis" Nickname:"ibmlaptop" Mode:Managed Frequency:2.412GHz Access Point: 00:0C:41:75:D4:02 Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/0 Retry limit:16 RTS thr:off Fragment thr:off Encryption key:****-****-** Security mode:open Power Management:off Link Quality:30/0 Signal level:-70 dBm Noise level:-98 dBm Rx invalid nwid:59 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:1 Invalid misc:4900 Missed beacon:3 [root at ibmlaptop etc]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:02:8A:DF:50:FC inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::202:8aff:fedf:50fc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:905 errors:655 dropped:0 overruns:0 frame:655 TX packets:699 errors:33 dropped:0 overruns:0 carrier:0 collisions:30 txqueuelen:1000 RX bytes:439321 (429.0 Kb) TX bytes:118979 (116.1 Kb) Interrupt:11 Base address:0x8000 From esr at thyrsus.com Sun Feb 1 22:11:38 2004 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 1 Feb 2004 17:11:38 -0500 Subject: Package redirects as a solution In-Reply-To: <1075668682.12687.4509.camel@gruyere> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> <1075668682.12687.4509.camel@gruyere> Message-ID: <20040201221138.GA12452@thyrsus.com> Dams : > DMCA doesnt apply here. Neither software patents does (so far). So we > just get rid of those two "details". rpm.livna.org is not, i repeat, is > NOT a warez site : we wont provide any mame rom, win32 non distributable > dll, or Britney Spears mp3^WOgg Vorbis as rpm as long as they are > _copyrighted_. Fine, I think nobody wants you to commit acts that would be substantively piracy. I though the tar archives of dlls were redistributable but apparently I'm wrong. I agree with the earlier suggestion that package-level redirects would be a good solution for some of this sort of thing. So, for example, the Fedora yum repository could carry a redirect that would send queries for flash-plugin to the macromedia site. -- Eric S. Raymond -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ByteEnable at austin.rr.com Sun Feb 1 22:52:44 2004 From: ByteEnable at austin.rr.com (ByteEnable) Date: Sun, 01 Feb 2004 16:52:44 -0600 Subject: kernel 2.6.1-1.65 and VIA Apollo Pro266T AGP In-Reply-To: <1075653605.3083.5.camel@ByteEnable> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <20040201155142.GC9717@thyrsus.com> <20040201155556.GA13995@devserv.devel.redhat.com> <20040201172829.61664532.ms-nospam-0306@arcor.de> <1075653605.3083.5.camel@ByteEnable> Message-ID: <1075675963.3046.9.camel@ByteEnable> Okay, I've gotten further now. By comparing the .99 driver to the 1.0, I found that in the .99 driver there was a specific via_mask_memory function. In the 1.0 driver this was moved to agp_generic_mask_memory(). I changed the function to behave the way the old driver did by always: return addr | agp_bridge->driver->masks[0].mask; . This actually allows XFree to load and the log states that AGP 4X is initialized. However, GDM now states that it cannot start the XServer and I get some printk's, then GDM asks if I want to configure the XServer, blah, blah. Its better than a hang. Any got any idea's? Byte On Sun, 2004-02-01 at 10:40, ByteEnable wrote: > Hi All, > > I get random ascii characters on the screen and the system freezes when > using the newest NVIDIA driver (5536) and kernel 2.6.1-1.65. The error > happens when X tries to load. I checked kernel.org and did not see any > bugs in bugzilla. However, I did find this: > > http://minion.de/ > > "Linux 2.6 AGPGART seems to be broken on some chipsets. If you find that > your system hangs upon starting X, potentially with ASCII garbage all > over the screen, try the built-in NVIDIA AGP GART driver (Option "NvAgp" > "1", AGPGART not loaded) instead." > > Has anyone else see this problem? > > Byte > From xose at wanadoo.es Mon Feb 2 00:51:33 2004 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 02 Feb 2004 01:51:33 +0100 Subject: Fedora is not Red Hat ;-) Message-ID: <401D9F15.4030502@wanadoo.es> hi, can anyone replace "Red Hat, Inc." string with "The Fedora Project" in the RPM builder system ? "Vendor" and "Packager" bring a RH tag in all packages: Vendor: Red Hat, Inc. Packager : Red Hat, Inc. And still there are some packages with RH name: redhat-artwork redhat-menus redhat-rpm-config redhat-lsb could 'redhat' be replaced by 'fedora' ? -thanks- -- Software is like sex, it's better when it's bug free. From xose at wanadoo.es Mon Feb 2 01:04:07 2004 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 02 Feb 2004 02:04:07 +0100 Subject: Version Control System Comparison (was Re: not SVN?) Message-ID: <401DA207.2020302@wanadoo.es> Cristian Gafton wrote: > There is going to be plenty of time to play with alternative solutions > once we have in place at least one. Every solution has its supporters and > opposition, and we're not going to get unanimity no matter what. > > I happen to know CVS and I think that most people are familiar with CVS. > It is not perfect, it has its faults, but its faults are widely known. I > can take few days to put out the CVS server or I can take few weeks to > review other solutions that I'm not that familiar with. I'd rather have > the CVS out. Better SCM Initiative [1] has a very nice "Version Control System Comparison": http://better-scm.berlios.de/comparison/ [1] http://better-scm.berlios.de -- Software is like sex, it's better when it's bug free. From llch at redhat.com Mon Feb 2 01:38:01 2004 From: llch at redhat.com (Leon Ho) Date: Mon, 02 Feb 2004 11:38:01 +1000 Subject: gettext vs automake In-Reply-To: References: <20040129155641.GL28127@redhat.com> <1075408058.6108.24.camel@localhost.localdomain> Message-ID: <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> There are still requirement on mkinstalldirs on 0.14.1. I will probe upstream later regarding this. But since I was planning to upgrade gettext in FC2, I will upgrdae to 0.14.1 soon. Regards, Leon On Fri, 2004-01-30 at 18:14, Jens Petersen wrote: > >>>>> "Owen" == Owen Taylor writes: > > Owen> On Thu, 2004-01-29 at 10:56, Tim Waugh wrote: > >> The automake we have in Fedora development no longer > >> provides mkinstalldirs, but the gettext m4 macros and > >> Makefile.in.in still want to use it. The same goes > >> for glib-gettext.m4. > > Well at least gettext still includes "/usr/share/gettext/mkinstalldirs". > > >From Automake 1.8 entry in the NEWS file: > > - Because `mkdir -p' is available on most platforms, and we can use > `install-sh -d' when it is not, the use of the mkinstalldirs > script is being phased out. `automake --add-missing' no longer > installs it, and if you remove mkinstalldirs from your package, > automake will define $(mkinstalldirs) as an alias for $(mkdir_p). > > Gettext 0.12.1 still requires mkinstalldirs. Fortunately > gettextize and autopoint will install it when needed. Automake > will continue to define the $(mkinstalldirs) and to distribute > mkinstalldirs when this script is in the source tree. > > So I think you can run "gettextize -f -c" in your bootstrap > script or just copy over /usr/share/gettext/mkinstalldirs > directly if you're using glib-gettext as a "workaround". > > (Fwiw gettext-0.14.1 still seems to require mkinstalldirs too.) > > >> Are these things that we need to fix before release? > >> I guess they'll prevent maintainers from being able > >> to release packages using Fedora Core 2.. > > Owen> Well, you can always just use automake-1.7. We are > Owen> (I assume, since it's what GNOME-2.6 will require) > Owen> still shipping it. > > We don't have an automake17 package yet, but since there > have been requests for it, I will probably be adding one soon. > > Owen> http://bugzilla.gnome.org/show_bug.cgi?id=132858 > > In the long term I guess the requirement for mkinstalldirs > will go away from gettext and the glib wrapper. > > Jens > From wtogami at redhat.com Mon Feb 2 03:22:13 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 Feb 2004 17:22:13 -1000 Subject: Please verify: GDM miscounts current sessions Message-ID: <401DC265.1070907@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110315 GDM miscounts current sessions * Sun Feb 01 2004 Warren Togami 1:2.4.4.5-8 - patch30 xdmcp_session counter fix from gdm-2.5.90.0 #110315 - automake14 really needed, not automake - BR libcroco-devel, libcroco-devel, libattr-devel, gettext - conditionally BR libselinux-devel - explicit epoch in all deps gdm-2.x from FC1 and FC2 rawhide fail to properly count the number of concurrent XDMCP sessions. Rather than a maximum simultaneous sessions counter, MaxSessions parameter became a maximum number of sessions forever counter. The original code LOOKS correct, but gdm-2.5.90.0 hints to a race condition that could be causing this behavior. I copied the code from gdm-2.5.90.0 into rawhide's gdm and it seems to work. The spec patch also contains explicit BuildRequires fixes and versioned-dep-epochs. Please verify that the patch solves the problem without introducing any regressions. A redone package will need to go into FC1 updates/testing soon too, especially for the K12LTSP folks. If these changes look good, I ask that Havoc check them into rawhide ASAP. It should not be too late to make FC2 test1 (I hope especially since changeloop is still broken.) Warren Togami wtogami at redhat.com From salimma at fastmail.fm Mon Feb 2 03:22:35 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Mon, 02 Feb 2004 10:22:35 +0700 Subject: Package redirects as a solution In-Reply-To: <20040201221138.GA12452@thyrsus.com> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> <1075668682.12687.4509.camel@gruyere> <20040201221138.GA12452@thyrsus.com> Message-ID: <1075692155.3038.2.camel@localhost.localdomain> On Sun, 2004-02-01 at 17:11 -0500, Eric S. Raymond wrote: [snip] > I agree with the earlier suggestion that package-level redirects would > be a good solution for some of this sort of thing. So, for example, > the Fedora yum repository could carry a redirect that would send > queries for flash-plugin to the macromedia site. Is it absolutely certain that that is permissible? IMHO this is analogous to displaying a copyrighted image on your website that is streamed off someone else's website. You would be claiming to host the file while actually leeching someone's bandwith. - 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 warren at togami.com Mon Feb 2 03:28:32 2004 From: warren at togami.com (Warren Togami) Date: Sun, 01 Feb 2004 17:28:32 -1000 Subject: Package redirects as a solution In-Reply-To: <1075692155.3038.2.camel@localhost.localdomain> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> <1075668682.12687.4509.camel@gruyere> <20040201221138.GA12452@thyrsus.com> <1075692155.3038.2.camel@localhost.localdomain> Message-ID: <401DC3E0.9030304@togami.com> Michel Alexandre Salim wrote: > On Sun, 2004-02-01 at 17:11 -0500, Eric S. Raymond wrote: > [snip] > >>I agree with the earlier suggestion that package-level redirects would >>be a good solution for some of this sort of thing. So, for example, >>the Fedora yum repository could carry a redirect that would send >>queries for flash-plugin to the macromedia site. > > > Is it absolutely certain that that is permissible? IMHO this is > analogous to displaying a copyrighted image on your website that is > streamed off someone else's website. You would be claiming to host the > file while actually leeching someone's bandwith. > > - Michel I personally don't see a problem in the case of flash-plugin. Macromedia is mainly concerned about getting download statistics for every download in order to gauge marketshare. I would suggest that it is also within our interests to allow them to do so. We can show that we do exist and use their plugin. I personally don't care if anyone implements this as long as it requires zero of my time. Don't expect anything dynamic on the mirrors either, because we are using static pages for security reasons. If anyone actually implements this, don't point at macromedia.mplug.org and use the other mirrors. Also please choose the right package for the right distribution so the distribution breakdown statistics remain correct. (Scroll to the bottom of the macromedia.mplug.org main page to see the download statistics.) Warren From abel at vallinor4.com Mon Feb 2 04:19:47 2004 From: abel at vallinor4.com (Alexander L. Belikoff) Date: Sun, 1 Feb 2004 23:19:47 -0500 Subject: rawhide: install from ISO image segfaults Message-ID: <200402012319.47362.abel@vallinor4.com> Got a segfault while trying to install from boot.iso (dated 02/01/04 10:31). I used 'linux askmethod'. The installer crashes after I select the language (English) with the message: install exited abnormally -- received signal 11 Oh, just checked - this happens when using the default boot method as well. -- Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9 Bloomberg L.P. 424B A86E CD0D 8424 2701 abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key) From abel at vallinor4.com Mon Feb 2 04:35:52 2004 From: abel at vallinor4.com (Alexander L. Belikoff) Date: Sun, 1 Feb 2004 23:35:52 -0500 Subject: strange TCP problems w/ RawHide Message-ID: <200402012335.52746.abel@vallinor4.com> I wonder if anyone observed the same weirdness I have. I've installed RawHide over FC1 through constant yum'ming. Currently, I'm running kernel 2.6.1-1.63. Unfortunately, TCP doesn't seem to work: - ICMP does work (I can ping yahoo.com) - TCP does reach the router (I can access it's web interface) - And that's it - TCP doesn't go beyond that point. Dumps show that my SYN packet never gets answered. This is all on a laptop w/ PCMCIA cards - I've tried it both with wired and wireless ones. As I have two partitions, one w/ FC1, one w/ RawHide, I made sure that it is not the router or any other issue. It seems to be specific to RawHide. So could anyone shed some light to this problem? I'm willing to help w/ trace and dumps and add'l troubleshooting if it is required. Thanks, -- Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9 Bloomberg L.P. 424B A86E CD0D 8424 2701 abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key) From notting at redhat.com Mon Feb 2 04:49:25 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 1 Feb 2004 23:49:25 -0500 Subject: rawhide: install from ISO image segfaults In-Reply-To: <200402012319.47362.abel@vallinor4.com> References: <200402012319.47362.abel@vallinor4.com> Message-ID: <20040202044925.GA17504@devserv.devel.redhat.com> Alexander L. Belikoff (abel at vallinor4.com) said: > Got a segfault while trying to install from boot.iso (dated 02/01/04 10:31). I > used 'linux askmethod'. The installer crashes after I select the language > (English) with the message: > > install exited abnormally -- received signal 11 > > Oh, just checked - this happens when using the default boot method as well. Do you have an inserted PCMCIA card? Bill From mharris at redhat.com Mon Feb 2 05:09:40 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 2 Feb 2004 00:09:40 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. Message-ID: This is a Request For Comments intended to help determine the best /long term/ solution over time for a problem developers and rpm packagers will face with multiple alternative X11 implementations being available in RPM packaged format in the future. This is not intended to be a short term or rushed solution, but one in which developers will be able to migrate rpm packages to using over time. It is my hope that the time period would be short, but it can theoretically be as long as is necessary, as this is just a discussion for now. Problem scenario: Currently, the XFree86 implementation of X11 has all of the libraries present in the package XFree86-libs, and all of the necessary development headers are included in XFree86-devel. All rpm packages containing applications/libs which link to the standard X11 libraries, currently have hard coded dependancies such as: Requires: XFree86-libs Buildrequires: XFree86-devel This is suboptimal for packaging however, as it makes a bad assumption that there is only a single implementation of X11 APIs, and that only this implementation can be used to satisfy the dependancies of applications needing to link to X libraries. In order to facilitate alternate X11 implementations, these hard coded dependancies in RPM spec files need to be changed to be more generic, rather than implementation specific. This does pose a rather large problem however, as the entire base of OSS software rpms out there which link to X libraries pretty much all assume there is one and only one implementation of X11 which will be in rpm format with longevity. The problems of course only arise when considering an actual alternative implementation of these APIs, such as the freedesktop.org X libraries. (xlibs CVS module). When these libraries are packaged up, they could be packaged in individual rpm packages (my current plan for now), or they could be put in one bigger package. Either way, this causes large changes to various assumptions on dependancies. While there is no easy one-stop-shopping solution which can work around all of the possible problems and annoyances that will occur when alternate implementations of X11 are rpm packaged and made available, there are probably different ways to achieve the end goal, which is to: 1) Allow multiple X11 implemenations to be available in rpm packaging, and be substituted with each other easily. 2) Allow X11 software to compile, link, build and produce packages irrespective of which implemenation is present. This is important, because X11 is a standard, and so any compliant implementation should be substitutable, at least for the bits that are actually official standards. 3) Allow X11 software binary rpm packages which were compiled with any X11 implementation, to install cleanly on a system which has any X11 implementation installed. Of course, in this particular case, only "official standard" parts of the given X11 implementation should be interchangeable 100%, however implementation specific features may require additional dependancies. I've thought of various approaches to solving this problem, and there are rather large tradeoffs no matter which path is chosen. I personally believe that the best solution is the one that gives the greatest long-term benefits, and is "future proof". A best long-term solution however may have additional short term growing pains which are necessary in order to get to the long term gains. Here are some example problems: Package "Requires: XFree86-libs" to get libX11 and libXaw. It currently "BuildRequires: XFree86-devel" to meet dependancies. We now want this package to build and work with the alternative X library implementation "freedesktop-libX11" and "freedesktop-libXaw". Since only one implementation could be installed at a given time in a clean manner (we'll make that assumption anyway), by changing every rpm to use: Requires: freedesktop-libXaw BuildRequires: freedesktop-libXaw-devel That just substitutes one poor assumption problem for another equally bad problem. It doesn't solve the real problem, which is that multiple X11 implementations can exist, and any particular one could be present on the system theoretically. Another possibility, would be to have something do a virtual provide for XFree86-libs and XFree86-devel. For example, we could have a fake XFree86-libs package which does nothing more than "Requires: freedesktop-libX11" etc. and same for the -devel package Problem with that is, that would allow a real quick short term solution which is quite an ugly hack, and it still makes bad assumptions and isn't really IMHO "future proof", which as stated earlier is one of the main goals I wish to achieve from this. Proposed Solution: After much thought, my own proposed solution, is to do the following: - Create a number of new "virtual Provides:" in the XFree86 rpm spec file in the XFree86-libs and XFree86-devel packages respectively. Essentially there would be one new virtual provide for each library, and perhaps for developmental utilities necessary for X development also, which are presently in XFree86-devel. After testing this and working out any quirks by experimenting with some out-of-tree packages, by changing their Requires and BuildRequires to point to the new virtual provides instead, any major issues could be worked out before anything were to be developer-visible. Example for the package freedesktop-libX11 would be: Provides: libX11 = %{version} for freedesktop-libX11-devel: Provides: libX11-devel = %{version} Requires: freedesktop-libX11 = %{version} At this point, rpm packagers could begin to change their packages at will to use the new virtual provides instead of relying on the implementation specific XFree86-libs and XFree86-devel packages explicitly. Since both XFree86-libs and XFree86-devel would continue to exist for some period of time at least, no packages should break right away, and developers would have plenty of time to fix the packages to use the virtual provides. Announcements would be sent out to as many forums deemed necessary to try to reach rpm packagers who would be affected and need to modify their rpms. This would amount to determining exactly _which_ X11 libraries an rpm package is really dependant on at build time, and then listing their virtual requires: Xawtv: Requires: libX11 BuildRequires: libX11-devel Packages in the distribution itself could be modified over time by their respective maintainers, or en-masse by a few people trying to "solve the problem all at once" with minimal impact on others internally. Likewise a similar process could occur with external packages such as Fedora Extras/fedora.us, freshrpms.net, and other rpm factories. This could very largely be scripted to find the rpms needing changes, and most of the short-term problems would be solveable IMHO without much difficulty, especially since the existing XFree86-devel and XFree86-libs packages existing still and also containing the right collection of virtual provides. This way, if a system has an alternative X11 implementation installed in the future, it should be harmonious. Of course there would likely be packages found which never got updated over time, but that's impossible to avoid 100%. Those remaining packages could be updated at that point, and it would still be possible to provide a fake XFree86-devel and/or XFree86-libs package if there was any significant problem caused by this solution. One could then also for example, drop in rpm packages from X.org, to use their implementation, and have Xorg-libX11 providing the virtual libX11 package. I believe that this solution has a lot of merits, although as stated above, there would be some growing pains in some cases, however that could be mitigated by continuing to provide the faked XFree86-foo packages over time, and trying to find and fix problematic packages as time and whatnot permits, rather than being forced to do it right away. I look forward to hearing developmental comments and feedback, both from other developers at Red Hat, as well as community developers working on/with Fedora project, Freshrpms.net, rpmfind.net, and other rpm repositories out there, as well as feedback from individual project developers who maintain rpm packages that have dependancies on X11. Alternative ideas, and/or modifications to my proposal above are also encouraged. Please try to look at the long term aspects and benefits and not focus on short term drawbacks/problems, and please make suggestions that try to remain as X11 implementation neutral as possible, as I believe that is an important goal. I look forward to hearing everyone's feedback and comments. Thanks in advance. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From drepper at redhat.com Mon Feb 2 05:10:41 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 01 Feb 2004 21:10:41 -0800 Subject: Prelink hosed my binaries? In-Reply-To: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> References: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <401DDBD1.6010405@redhat.com> Steve Bergman wrote: > Anyone else wake up to a totally hosed system this morning? A > substantial portion of my binaries (including bash) are wrecked and show > up as "data" when I use the "file" command on them. No ELF header at > all. Haven't seen this nor heard from it. When updating your system, please keep the old prelink and elfutils binaries around and try to reproduce the problem. Jakub isn't available this week so this data would need to be preserved. Compare the prelink binary itself, has it changed? prelink itself shouldn't have this effect but if prelink itself is corrupted... -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From mharris at redhat.com Mon Feb 2 05:12:59 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 2 Feb 2004 00:12:59 -0500 (EST) Subject: Version Control System Comparison (was Re: not SVN?) In-Reply-To: <401DA207.2020302@wanadoo.es> References: <401DA207.2020302@wanadoo.es> Message-ID: On Mon, 2 Feb 2004, Xose Vazquez Perez wrote: >> There is going to be plenty of time to play with alternative solutions >> once we have in place at least one. Every solution has its supporters and >> opposition, and we're not going to get unanimity no matter what. >> >> I happen to know CVS and I think that most people are familiar with CVS. >> It is not perfect, it has its faults, but its faults are widely known. I >> can take few days to put out the CVS server or I can take few weeks to >> review other solutions that I'm not that familiar with. I'd rather have >> the CVS out. > >Better SCM Initiative [1] has a very nice "Version Control System Comparison": >http://better-scm.berlios.de/comparison/ GNU cssc is the best SCM solution hands down. We should switch to cssc sometime in the future and leave CVS in the dust. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mrsam at courier-mta.com Mon Feb 2 05:37:03 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 02 Feb 2004 00:37:03 -0500 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. References: Message-ID: Mike A. Harris writes: > All rpm packages containing applications/libs which link to the > standard X11 libraries, currently have hard coded dependancies > such as: > > Requires: XFree86-libs > Buildrequires: XFree86-devel At least the first part should not be necessary. find-requires.pl will automatically add dependencies on every shared library loaded by any binary in the package. pan, for example, automatically gets a dependency on libgdk-x11-2.0.so.0, by the virtue of linking with it. This dependency is provided by the gtk2 RPM which, in turn, automatically has a dependency on libX11.so.6, libXext.so.6, and others, by the virtue of linking against those libraries. This is sufficient to require XFree86-libs. I don't think you need anything special to correctly resolve runtime dependency of X applications. If you use a substitute X11 server+libraries, as long as the substitute installs libX11.so.6, et al, everything will work correctly. find-provides.pl automatically declares a provides for all matching shared libraries installed by the package, so you do not need to do anything explicit with the substitute X11 servers/runtime libraries. As long as they install shared libraries that have the same names (even if they are installed in different directories!), all runtime dependencies will be satisfied. As far as development libraries go, it does look like an explicit Requires: may be necessary. You might be able to get away with adding "Provides: XFree86-devel" to substitute X development libraries. It shouldn't prevent them from co-habiting with the real XFree86-devel, or other substitutes, and RPMs that explicitly require XFree86-devel should still be buildable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Mon Feb 2 05:48:40 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 2 Feb 2004 00:48:40 -0500 Subject: strange TCP problems w/ RawHide In-Reply-To: <200402012335.52746.abel@vallinor4.com> References: <200402012335.52746.abel@vallinor4.com> Message-ID: <20040202054840.GA630@angus.ind.WPI.EDU> On Sun, Feb 01, 2004 at 11:35:52PM -0500, Alexander L. Belikoff wrote: > I wonder if anyone observed the same weirdness I have. I've installed RawHide > over FC1 through constant yum'ming. Currently, I'm running kernel 2.6.1-1.63. > Unfortunately, TCP doesn't seem to work: Sounds like ECN. Try: echo 0 > /proc/sys/net/ipv4/tcp_ecn From tony at tgds.net Mon Feb 2 06:53:17 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 02 Feb 2004 07:53:17 +0100 Subject: mplayer vs. xine In-Reply-To: <20040201150736.GC30540@devserv.devel.redhat.com> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130140021.A14192@meenakshi.cs.iitm.ernet.in> <1075466753.5020.101.camel@localhost.localdomain> <20040130205222.GE18301@devserv.devel.redhat.com> <1075546815.8421.2.camel@localhost.localdomain> <20040201150736.GC30540@devserv.devel.redhat.com> Message-ID: <1075704796.9750.11.camel@localhost.localdomain> Le dim 01/02/2004 ? 16:07, Alan Cox a ?crit : > > > xine has a variant that already does. Just needs the reverse engineered > > > libddmpeg work and my surfaces rewrite for via and some oddments to > > > make it work open source > > > > You mean ViacripplEdXinePlayer a.k.a VeXP=:-p > > > > Been there, tried that. When it doesn't crash and burn and when it > > allows DVB-S playback I'll look again. > > Well its up to someone like you who cares to port the fixes into a current > Xine. I did look. This is way over my head, I'm a tinkerer with no formal programming experience. I don't call finding and correcting a couple of bugs in USB storage back in my Vaio C days "experience". Nor is compiling pgaccess for Mac OS X. Those are my two claims to fame, period. The reverse engineering guys are doing a good job but they aren't very organised - there a bits and pieces all over and it is difficult to know what is needed. I guess I could figure out what goes where with a couple of pointers hint hint... Cheers Tony Grant -- www.tgds.net Library management software toolkit From notting at redhat.com Mon Feb 2 07:19:33 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2004 02:19:33 -0500 Subject: Fedora Core 2 Test 1... delayed Message-ID: <20040202071933.GA21870@devserv.devel.redhat.com> Since the schedule says it's coming out tomorrow, I figued I'd push the heads-up that it's delayed. In short, it's not working quite well enough to push out yet. We're currently working on it, and will update the schedule page when we have a better idea when it's going to be usable. Best guess right now is mid-to-late this week. Bill From nos at utel.no Mon Feb 2 08:05:07 2004 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Mon, 02 Feb 2004 09:05:07 +0100 Subject: bootsplash.org In-Reply-To: <0000068c050a5407d4@[192.168.170.10]> References: <0000068c050a5407d4@[192.168.170.10]> Message-ID: <0000000b0103e607d4@[192.168.170.10]> On Fri, 2004-01-30 at 23:51, Louis Garcia wrote: > Any chance something like this can go into fc2? > http://www.bootsplash.org Whats wrong with the current one we have in FC1 ? (Except NOT beeing an evil kernel hack..) -- 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 twaugh at redhat.com Mon Feb 2 09:41:47 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 2 Feb 2004 09:41:47 +0000 Subject: gettext vs automake In-Reply-To: <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> References: <20040129155641.GL28127@redhat.com> <1075408058.6108.24.camel@localhost.localdomain> <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> Message-ID: <20040202094147.GE25654@redhat.com> On Mon, Feb 02, 2004 at 11:38:01AM +1000, Leon Ho wrote: > There are still requirement on mkinstalldirs on 0.14.1. I will probe > upstream later regarding this. But since I was planning to upgrade > gettext in FC2, I will upgrdae to 0.14.1 soon. Using 'autopoint' (whose existence was new to me) fixed the problem I was having myself, and an automake17 package would probably avoid any other problems developers might run into, such as the glib-gettext.m4 macros requiring automake<1.8. Tim. */ -------------- 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 redhat.com Mon Feb 2 11:44:35 2004 From: buildsys at redhat.com (Build System) Date: Mon, 2 Feb 2004 06:44:35 -0500 Subject: rawhide report: 20040202 changes Message-ID: <200402021144.i12BiZH00537@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20040202 ---------------------------- From chadley at pinteq.co.za Mon Feb 2 11:53:39 2004 From: chadley at pinteq.co.za (Chadley Wilson) Date: Mon, 02 Feb 2004 13:53:39 +0200 Subject: mplayer vs. xine In-Reply-To: <1075704796.9750.11.camel@localhost.localdomain> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130140021.A14192@meenakshi.cs.iitm.ernet.in> <1075466753.5020.101.camel@localhost.localdomain> <20040130205222.GE18301@devserv.devel.redhat.com> <1075546815.8421.2.camel@localhost.localdomain> <20040201150736.GC30540@devserv.devel.redhat.com> <1075704796.9750.11.camel@localhost.localdomain> Message-ID: <1075722819.7710.87.camel@chad.workgroup> Just a bit off the topic here, Xine does funny things with certain older dvds on of them is it adjusts the screen area and doesnt restore it so you find your screen pans when you push the mouse pointer to the edges. So I tried installing mplayer via download [I cant get yum to work because of the companies firewall] and there were too many dependancy threads so I gave up downloading mplayer. So I download Gxine instead and problem solved one file one install, Pretty cool. Chad On Mon, 2004-02-02 at 08:53, Tony Grant wrote: > Le dim 01/02/2004 ? 16:07, Alan Cox a ?crit : > > > > > xine has a variant that already does. Just needs the reverse engineered > > > > libddmpeg work and my surfaces rewrite for via and some oddments to > > > > make it work open source > > > > > > You mean ViacripplEdXinePlayer a.k.a VeXP=:-p > > > > > > Been there, tried that. When it doesn't crash and burn and when it > > > allows DVB-S playback I'll look again. > > > > Well its up to someone like you who cares to port the fixes into a current > > Xine. > > I did look. This is way over my head, I'm a tinkerer with no formal > programming experience. > > I don't call finding and correcting a couple of bugs in USB storage back > in my Vaio C days "experience". Nor is compiling pgaccess for Mac OS X. > Those are my two claims to fame, period. > > The reverse engineering guys are doing a good job but they aren't very > organised - there a bits and pieces all over and it is difficult to know > what is needed. I guess I could figure out what goes where with a couple > of pointers hint hint... > > Cheers > > Tony Grant > > -- > www.tgds.net Library management software toolkit > > From alan at redhat.com Mon Feb 2 12:09:33 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Feb 2004 07:09:33 -0500 Subject: Prelink hosed my binaries? In-Reply-To: <401DDBD1.6010405@redhat.com> References: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> <401DDBD1.6010405@redhat.com> Message-ID: <20040202120933.GC27643@devserv.devel.redhat.com> On Sun, Feb 01, 2004 at 09:10:41PM -0800, Ulrich Drepper wrote: > keep the old prelink and elfutils binaries around and try to reproduce > the problem. Jakub isn't available this week so this data would need to > be preserved. Compare the prelink binary itself, has it changed? > prelink itself shouldn't have this effect but if prelink itself is > corrupted... I've had a one case where each new glibc makes sendmail crash and each prelink fixes it, but Jakub knows about that. Talking about corruption however does prelink create a new file it rewrites into, and if not what happens when prelink prelinks itself ? From peter.backlund at home.se Mon Feb 2 12:52:30 2004 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 02 Feb 2004 13:52:30 +0100 Subject: Corporate pressure Message-ID: <401E480E.1060307@home.se> Hi. On the subject of distributing free-as-in-beer proprietary software, I think that the approach Warren has taken towards Macromedia (and that I tried on Real and Adobe) could be successful. However, if the project were to be represented by someone more knowledgeable and more experienced in PR relations etc, we might get a few more (positive) answers. Two names come immediately into mind: ESR and Alan Cox. What we want, is of course to have certain pieces of software such as RealPlayer/HelixPlayer and Acrobat Reader are made available in a sensibly packaged way, accesible via the standard software management tools. The community could handle this through the usual fedora.us/livna.org QA process, and come up with packages that fit into FC the way they should (menu entries, mime types, stripped bloat, plugins that work, etc etc). This will increase the number of satisfied users of both FC and the Real/Adobe products, to _zero cost_ for the companies in question. So, a few possible scenarios would be: 1. Company X allows free redistribution, similar to the Nvidia driver. 2. X allows limited redistribution, but through yum/apt/up2date, like Macromedia does. 3. X does not allow redistribution, but can host the community developed package on their own site. I think it's worth a shot at least. So, any big name takers? ESR? Alan? someone at redhat.com? /Peter From david.paeme at belbone.net Mon Feb 2 13:03:19 2004 From: david.paeme at belbone.net (david paeme) Date: Mon, 02 Feb 2004 14:03:19 +0100 Subject: Corporate pressure In-Reply-To: <401E480E.1060307@home.se> References: <401E480E.1060307@home.se> Message-ID: <1075726999.8854.12.camel@owsdavid> wouldn't it be a good idea to include some kind of license acceptance mechanism into apt/yum/rpm? for example, to get adobe acrobat to install, the user would get a prompt to accept the adobe license, which he can (and the software installs), or not (so, it doesn't install...). software vendors will probably like this, because they can the user to accept their license, and not having people install the software without doing that. and this could work for just about anything (java, flash, binary drivers like those from nvidia, etc...) also,the corporate weight of redhat -- or even some high-profile people like ESR or AC -- could help persuade the companies. bye, d. **by the way, doesn rpm contain a mechanism like this? maybe something in the specfile? On Mon, 2004-02-02 at 13:52, Peter Backlund wrote: > Hi. > > On the subject of distributing free-as-in-beer proprietary software, I > think that the approach Warren has taken towards Macromedia (and that I > tried on Real and Adobe) could be successful. However, if the project > were to be represented by someone more knowledgeable and more > experienced in PR relations etc, we might get a few more (positive) > answers. Two names come immediately into mind: ESR and Alan Cox. > > What we want, is of course to have certain pieces of software such as > RealPlayer/HelixPlayer and Acrobat Reader are made available in a > sensibly packaged way, accesible via the standard software management > tools. The community could handle this through the usual > fedora.us/livna.org QA process, and come up with packages that fit into > FC the way they should (menu entries, mime types, stripped bloat, > plugins that work, etc etc). This will increase the number of satisfied > users of both FC and the Real/Adobe products, to _zero cost_ for the > companies in question. So, a few possible scenarios would be: > > 1. Company X allows free redistribution, similar to the Nvidia driver. > 2. X allows limited redistribution, but through yum/apt/up2date, like > Macromedia does. > 3. X does not allow redistribution, but can host the community developed > package on their own site. > > I think it's worth a shot at least. So, any big name takers? ESR? Alan? > someone at redhat.com? > > /Peter > > From jean-rene.cormier at cipanb.ca Mon Feb 2 13:46:27 2004 From: jean-rene.cormier at cipanb.ca (Jean-Rene Cormier) Date: Mon, 02 Feb 2004 09:46:27 -0400 Subject: HD spinning is making the computer freeze Message-ID: <1075729586.29974.26.camel@forbidden.cipanb.ca> Hi, I was doing some graphic editing yesterday with The Gimp and from time to time the HD would start spinning and the computer would freeze for like 4-5 minutes, I can't do anything during that time, the cursor doesn't even move, all that's happening is the HD spinning. Last night I checked how long it took to come back and it took over 10 minutes, the clock was stuck at 11:51 and when it stopped spinning the clock changed to 12:03. What could be causing this? I'm thinking that it's because I don't have much RAM and it has to use the swap file a lot. The computer is a Dell Inspiron 300m laptop, with a 1.2GHz CPU, 256MB of RAM and 40Gb 5400RPM HD. Here's what top gave me yesterday right after it did it for the last time yesterday: Mem: 245948k av, 241596k used, 4352k free, 0k shrd, 3736k buff 139152k active, 65000k inactive Swap: 522104k av, 274964k used, 247140k free 34336k cached Also I noticed that X use an aweful lot of RAM, is this normal? I'm running KDE btw. PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 3750 root 15 0 413M 131M 67704 S 0.5 54.9 5:48 0 X Jean-Rene Cormier From fs111 at web.de Mon Feb 2 13:58:40 2004 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Mon, 02 Feb 2004 14:58:40 +0100 Subject: Corporate pressure In-Reply-To: <1075726999.8854.12.camel@owsdavid> References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> Message-ID: <1075730320.5228.6.camel@localhost> Am Mo, den 02.02.2004 schrieb david paeme um 14:03: > wouldn't it be a good idea to include some kind of license acceptance > mechanism into apt/yum/rpm? > > for example, to get adobe acrobat to install, the user would get a > prompt to accept the adobe license, which he can (and the software > installs), or not (so, it doesn't install...). > > software vendors will probably like this, because they can the user to > accept their license, and not having people install the software without > doing that. Well it is not a good idea to remove the possibility of using yum/apt/rpm in batch mode. Let me give you an example: Maybe there is an critical Bug in Adobe's Acrobat Reader or Macromedia's flash and you keep your System up 2 date via a cron job every night. This job will always fail and no updates will be installed because no one clicked on "I Agree", "OK" etc. I think it would be better to prompt for OK the first time a programm is started, so that you could install, and update it without any problems and agree to their terms before you can use it. Adobe uses this techinque in their SVG-Plugin for Mozilla an I think it is a good way to manage it. 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 hhoffman at ip-solutions.net Mon Feb 2 13:59:02 2004 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Mon, 2 Feb 2004 08:59:02 -0500 Subject: Version Control System Comparison (was Re: not SVN?) In-Reply-To: References: <401DA207.2020302@wanadoo.es> Message-ID: <1075730342.89e3b7c8262b6@secure.ip-solutions.net> Mike, Are you serious about GNU cssc? Even in their FAQ they recommend using CVS or RCS. I've never used cssc so I can't say either way. What are you thoughts? Cheers, Harry Quoting "Mike A. Harris" : *> *> GNU cssc is the best SCM solution hands down. We should switch *> to cssc sometime in the future and leave CVS in the dust. *> *> *> -- *> Mike A. Harris ftp://people.redhat.com/mharris *> OS Systems Engineer - XFree86 maintainer - Red Hat -- Harry Hoffman hhoffman at ip-solutions.net ------------------------------------------------- This mail sent through IpSolutions: http://www.ip-solutions.net/ From toshio at tiki-lounge.com Mon Feb 2 14:37:15 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 02 Feb 2004 09:37:15 -0500 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: Message-ID: <1075732633.12957.1392.camel@Madison.badger.com> On Mon, 2004-02-02 at 00:09, Mike A. Harris wrote: > 1) Allow multiple X11 implemenations to be available in rpm > packaging, and be substituted with each other easily. > If you are going to package freedesktop-X11 as separate packages for each library, then the XFree86 libraries also should be split into separate binary packages so people can actually play with alternative implementations of a subset of the X libraries. (May have been implied, but it wasn't actually mentioned as being part of the plan.) > 2) Allow X11 software to compile, link, build and produce > packages irrespective of which implemenation is present. This > is important, because X11 is a standard, and so any compliant > implementation should be substitutable, at least for the bits > that are actually official standards. > Are we going to be troubleshooting this or upstream? Or is it "upstream cares about this and when we find it doesn't work as expected we'll point it out to them"? > 3) Allow X11 software binary rpm packages which were compiled > with any X11 implementation, to install cleanly on a system > which has any X11 implementation installed. Of course, in > this particular case, only "official standard" parts of the > given X11 implementation should be interchangeable 100%, > however implementation specific features may require > additional dependancies. > So we'll have to break apart X11 providing packages into standard's providing pieces and extras providing pieces wherever possible. Regarding the new Requires: Is it really necessary to Require: XFree86-libs right now? Shouldn't rpm's automatic dependencies drag in libX11.so which is found in XFree86-libs. Couldn't we get rid of dependency on XFree86-libs and not replace it? Separate problem: we have to identify packages which can simply depend on finding any /usr/lib/{X11/}libX11.so in the filesystem and those which need a specific implementation of libX11. So I think we need the capability to Provide/Require: XFree86-libX11 and freedesktop-libX11. This will be something of a headache as we really need finer grained tracking than rpm provides. Maybe we'll need extra web infrastructure that tells us XFree86-libX11 provides (standards, X11_nonstandard_gizmo) while freedesktop-libX11 provides (standards, X11_nonstandard_whizzo) and developers can check if those things are ever reconciled/build separate packages for the different xlibs, etc (ugh). Hopefully most API/ABI enhancements will be done in true add-ons rather than entangled with standard pieces like this.... -Toshio -- Toshio From JROYSE at SYGMAnetwork.com Mon Feb 2 14:49:03 2004 From: JROYSE at SYGMAnetwork.com (Josiah Royse) Date: Mon, 2 Feb 2004 09:49:03 -0500 Subject: Corporate pressure Message-ID: <7BD2F41CA1F3794CA68340972DEB03B704AA6D42@webmail.sygmanetwork.com> > "I Agree", "OK" etc. I think it would be better to prompt for OK the > first time a programm is started, so that you could install, and update > it without any problems and agree to their terms before you can use it. > Adobe uses this techinque in their SVG-Plugin for Mozilla an I think it > is a good way to manage it. Yes, "click wrapping" sounds like a great compromise to programs that seek user licenses. Would wrapping proprietary plugins/applications with a click-license that checks the user's ~/.dotfile for license acceptance be a semi-legal way to "redistribute" these types of proprietary software? Could this be also be interpreted as a peace offering- having a simple way of respecting legal acceptance documents without having an interactive installation? In doing so, the open source software movement may motivate companies to change alter license agreements to allow redistribution, if there was a standard or easy way of prompting for user license acceptance. --Josiah, RHCE From jeffrin_jose at rajagiritech.ac.in Mon Feb 2 14:35:28 2004 From: jeffrin_jose at rajagiritech.ac.in (jeffrin_jose at rajagiritech.ac.in) Date: Mon, 2 Feb 2004 20:05:28 +0530 (IST) Subject: Developer related Message-ID: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> Hello all Is it possible to become a official Fedora developer by working in a Organisation.If yes, Please tell me the procedures to become a developer. ----------------------------------------- Rajagiri School of Engineering and Technology Kakkanad, Ernakulam http://rajagiritech.ac.in/ From skvidal at phy.duke.edu Mon Feb 2 15:07:45 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 02 Feb 2004 10:07:45 -0500 Subject: Developer related In-Reply-To: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> Message-ID: <1075734465.15564.2.camel@opus> On Mon, 2004-02-02 at 09:35, jeffrin_jose at rajagiritech.ac.in wrote: > Hello all > > Is it possible to become a official Fedora developer by > working in a Organisation.If yes, Please tell me the > procedures to become a developer. > > There are official fedora developers? -sv From jeffrin_jose at rajagiritech.ac.in Mon Feb 2 14:48:10 2004 From: jeffrin_jose at rajagiritech.ac.in (jeffrin_jose at rajagiritech.ac.in) Date: Mon, 2 Feb 2004 20:18:10 +0530 (IST) Subject: Developer related In-Reply-To: <1075734465.15564.2.camel@opus> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> Message-ID: <1584.202.88.226.177.1075733290.mailer@mail.rajagiritech.ac.in> hello , Are you asking me if official fedora developers are present ? ----------------------------------------- Rajagiri School of Engineering and Technology Kakkanad, Ernakulam http://rajagiritech.ac.in/ From robert at marcanoonline.com Mon Feb 2 15:14:49 2004 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 02 Feb 2004 11:14:49 -0400 Subject: Developer related In-Reply-To: <1075734465.15564.2.camel@opus> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> Message-ID: <1075734889.4589.1.camel@pcrobert.intranet.promca.com> On Mon, 2004-02-02 at 11:07, seth vidal wrote: > On Mon, 2004-02-02 at 09:35, jeffrin_jose at rajagiritech.ac.in wrote: > > Hello all > > > > Is it possible to become a official Fedora developer by > > working in a Organisation.If yes, Please tell me the > > procedures to become a developer. > > > > > > There are official fedora developers? > those with @redhat.com email addresses :-D ;-P > > -sv From jeffrin_jose at rajagiritech.ac.in Mon Feb 2 14:57:52 2004 From: jeffrin_jose at rajagiritech.ac.in (jeffrin_jose at rajagiritech.ac.in) Date: Mon, 2 Feb 2004 20:27:52 +0530 (IST) Subject: Developer related In-Reply-To: <1075734889.4589.1.camel@pcrobert.intranet.promca.com> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> <1075734889.4589.1.camel@pcrobert.intranet.promca.com> Message-ID: <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> hello , Do you know the procedure to become a developer ? ----------------------------------------- Rajagiri School of Engineering and Technology Kakkanad, Ernakulam http://rajagiritech.ac.in/ From fabrice at bellet.info Mon Feb 2 15:22:34 2004 From: fabrice at bellet.info (Fabrice Bellet) Date: Mon, 2 Feb 2004 16:22:34 +0100 Subject: Trouble with Cisco Airo MPI350 and kernel-2.6.1+ In-Reply-To: <401D6FD8.2040406@redhat.com> References: <4014AA49.8050800@redhat.com> <20040127164031.GA13174@bellet.info> <401CCF8A.2010406@redhat.com> <401D6FD8.2040406@redhat.com> Message-ID: <20040202152234.GA5710@bellet.info> Hi, On Sun, Feb 01, 2004 at 11:30:00AM -1000, Warren Togami wrote: > >>On Sun, Jan 25, 2004 at 07:48:57PM -1000, Warren Togami wrote: > >> > >>>IBM Thinkpad T41 > >>>Cisco Airo MPI350 802.11b Wireless > >>>PCIID: 0x14b9 0xa504 > >>>Kernel: Fedora rawhide 2.6.1-1.57 (Based on 2.6.2-rc1) > >>> > >>>http://bellet.info/~bellet/laptop/t40.html#wireless > >>>http://bellet.info/~bellet/laptop/airo.c-2.6.1-mm2.diff > >>>airo.ko does not support this Airo device, but with the addition of > >>>this patch it recognizes the device. > >> > >> > >> > >[SNIP] > >Used the ACU tool under Windows XP for flashing the firmware. The > >newest firmware version that operates with your driver is: > >5.00.03 > > > >Perhaps mention within a comment and/or config Help of your patch that > >the newest supported firmware is 5.00.03? That would save people like > >me a lot of time in the future... > > > > Are these many errors normal? > [snip] > > [root at ibmlaptop etc]# ifconfig eth1 > eth1 Link encap:Ethernet HWaddr 00:02:8A:DF:50:FC > inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: fe80::202:8aff:fedf:50fc/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:905 errors:655 dropped:0 overruns:0 frame:655 > TX packets:699 errors:33 dropped:0 overruns:0 carrier:0 > collisions:30 txqueuelen:1000 > RX bytes:439321 (429.0 Kb) TX bytes:118979 (116.1 Kb) > Interrupt:11 Base address:0x8000 The "rx errors" value is generated by summing 4 error counters from the card internal stats structure in airo_read_stats() : RxOverrun, RxPlcpFormatErr, RxPlcpLengthErr and RxMacCrcErr. Altough my connection is up and running, I also observe a high rate of RxMacCrcErr errors : % grep MacCrc /proc/driver/aironet/eth1/Stats RxMacCrcErr: 7688 RxMacCrcOk: 11399 I think that these errors are probably just related to the quality of the radio link, and do not reflect something bad, that would occur in the driver itself. Best wishes, -- fabrice From david.paeme at belbone.net Mon Feb 2 15:23:27 2004 From: david.paeme at belbone.net (david paeme) Date: Mon, 02 Feb 2004 16:23:27 +0100 Subject: Developer related In-Reply-To: <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> <1075734889.4589.1.camel@pcrobert.intranet.promca.com> <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> Message-ID: <1075735407.8854.19.camel@owsdavid> get a job at redhat? On Mon, 2004-02-02 at 15:57, jeffrin_jose at rajagiritech.ac.in wrote: > hello , > > Do you know the procedure to become a developer ? > > > ----------------------------------------- > Rajagiri School of Engineering and Technology > Kakkanad, Ernakulam > http://rajagiritech.ac.in/ > > From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 2 17:09:38 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 2 Feb 2004 18:09:38 +0100 Subject: mplayer vs. xine In-Reply-To: <1075561530.4878.4.camel@localhost.localdomain> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> Message-ID: <20040202180938.641bff34@python.freshrpms.net> Julien Olivier wrote : > XMame is totally free and legal, isn't it ? Mame ROMS are illegal > though, and not only in the US (this is not a software patent problem). (X)MAME can't really be considered free, as there are some limitations as to how it or any derivative work can be (re)distributed. Basically, you can't charge for MAME in any shape or form. This is mainly to avoid having companies selling some kind of "arcade game console" which would be running MAME. Please check out the full license at http://www.mame.net/ for more precise information. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.64 1.09 1.01 From esr at thyrsus.com Mon Feb 2 17:43:50 2004 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 2 Feb 2004 12:43:50 -0500 Subject: Corporate pressure In-Reply-To: <401E480E.1060307@home.se> References: <401E480E.1060307@home.se> Message-ID: <20040202174350.GA30711@thyrsus.com> Peter Backlund : > I think it's worth a shot at least. So, any big name takers? ESR? Alan? > someone at redhat.com? Actually, I was thinking yesterday that I probably have enough zorch with the key people at RealPlayer to get this done. The question is whether the result would be worth the time taken from doing other things. -- Eric S. Raymond From zaitcev at redhat.com Mon Feb 2 18:06:59 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 2 Feb 2004 10:06:59 -0800 Subject: strange TCP problems w/ RawHide In-Reply-To: References: Message-ID: <20040202100659.49a2b86a.zaitcev@redhat.com> On Sun, 1 Feb 2004 23:35:52 -0500 "Alexander L. Belikoff" wrote: > I wonder if anyone observed the same weirdness I have. I've installed RawHide > over FC1 through constant yum'ming. Currently, I'm running kernel 2.6.1-1.63. 99% of these are upstream firewall problems. Does "echo 0 > /proc/sys/net/ipv4/tcp_ecn" fix the problem? -- Pete From strange at nsk.no-ip.org Mon Feb 2 18:12:15 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 2 Feb 2004 18:12:15 +0000 Subject: [A-Z]* oddities Message-ID: <20040202181215.GA5411@nsk.no-ip.org> Hi, On fedora devel I get the following unexpected behaviour: -------------------------------------------------------------------------- $ echo [A-Z]* cd3 irate kernel-2.4.22-1.2166.nptl.i686.rpm list Mail mine opt selUpgrade sistema tmp uf work xtools_1.1.zip $ echo [a-z]* advsh asus cd3 irate kernel-2.4.22-1.2166.nptl.i686.rpm list Mail mine opt selUpgrade sistema tmp uf work xtools_1.1.zip $ ls | egrep '^[A-Z]' cd3 irate kernel-2.4.22-1.2166.nptl.i686.rpm list Mail mine opt selUpgrade sistema tmp uf work xtools_1.1.zip $ ls | egrep '^[a-z]' advsh asus cd3 irate kernel-2.4.22-1.2166.nptl.i686.rpm list Mail mine opt selUpgrade sistema tmp $ echo [ABCDEFGHIJKLMNOPQRSTUVWXYZ]* Mail uf work xtools_1.1.zip -------------------------------------------------------------------------- Regards, Luciano Rocha From notting at redhat.com Mon Feb 2 18:14:16 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2004 13:14:16 -0500 Subject: Fedora Core 2 Test 1... delayed In-Reply-To: <600B91D5E4B8D211A58C00902724252C01BC04E0@piramida.hermes.si> References: <600B91D5E4B8D211A58C00902724252C01BC04E0@piramida.hermes.si> Message-ID: <20040202181416.GE31633@devserv.devel.redhat.com> David Balazic (david.balazic at hermes.si) said: > Isn't it better to update the page right now to say "delayed for unknown > days", Working on that... Bill From steve at rueb.com Mon Feb 2 18:15:15 2004 From: steve at rueb.com (Steve Bergman) Date: Mon, 02 Feb 2004 12:15:15 -0600 Subject: Corporate pressure In-Reply-To: <20040202174350.GA30711@thyrsus.com> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> Message-ID: <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> On Mon, 2004-02-02 at 11:43, Eric S. Raymond wrote: > Peter Backlund : > > I think it's worth a shot at least. So, any big name takers? ESR? Alan? > > someone at redhat.com? > > Actually, I was thinking yesterday that I probably have enough zorch with > the key people at RealPlayer to get this done. The question is whether > the result would be worth the time taken from doing other things. > -- > Eric S. Raymond > Eric, If you *can* do it just *do* it. Don't just *talk* about doing it... Frankly, I don't think you can. From mitr at volny.cz Mon Feb 2 18:17:58 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 2 Feb 2004 19:17:58 +0100 Subject: [A-Z]* oddities In-Reply-To: <20040202181215.GA5411@nsk.no-ip.org> References: <20040202181215.GA5411@nsk.no-ip.org> Message-ID: <20040202181758.GA13907@popelka.ms.mff.cuni.cz> On Mon, Feb 02, 2004 at 06:12:15PM +0000, Luciano Miguel Ferreira Rocha wrote: > On fedora devel I get the following unexpected behaviour: > > $ echo [A-Z]* [ABCDEFGHIJKLMNOPQRSTUVWXYZ] or [[:upper:]] probably does what you want. Or set LC_COLLATE to C or POSIX. Mirek "not this flamewar again" Trmac From behdad at cs.toronto.edu Mon Feb 2 18:15:01 2004 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 2 Feb 2004 13:15:01 -0500 Subject: [A-Z]* oddities In-Reply-To: <20040202181215.GA5411@nsk.no-ip.org> References: <20040202181215.GA5411@nsk.no-ip.org> Message-ID: This is totally expected :). For what you want try LANG=C echo [A-Z]* ... In LANG=en_US.UTF-8 which is the default, both 'A' and 'a' sort before 'B' and 'b'. behdad On Mon, 2 Feb 2004, Luciano Miguel Ferreira Rocha wrote: > > Hi, > > On fedora devel I get the following unexpected behaviour: > > -------------------------------------------------------------------------- > > $ echo [A-Z]* > cd3 irate kernel-2.4.22-1.2166.nptl.i686.rpm list Mail mine opt selUpgrade > sistema tmp uf work xtools_1.1.zip > $ echo [a-z]* > advsh asus cd3 irate kernel-2.4.22-1.2166.nptl.i686.rpm list Mail mine opt > selUpgrade sistema tmp uf work xtools_1.1.zip > $ ls | egrep '^[A-Z]' > cd3 > irate > kernel-2.4.22-1.2166.nptl.i686.rpm > list > Mail > mine > opt > selUpgrade > sistema > tmp > uf > work > xtools_1.1.zip > $ ls | egrep '^[a-z]' > advsh > asus > cd3 > irate > kernel-2.4.22-1.2166.nptl.i686.rpm > list > Mail > mine > opt > selUpgrade > sistema > tmp > $ echo [ABCDEFGHIJKLMNOPQRSTUVWXYZ]* > Mail > > uf > work > xtools_1.1.zip > > -------------------------------------------------------------------------- > > Regards, > Luciano Rocha > > > From esr at thyrsus.com Mon Feb 2 18:23:20 2004 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 2 Feb 2004 13:23:20 -0500 Subject: Corporate pressure In-Reply-To: <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <20040202182320.GG30711@thyrsus.com> Steve Bergman : > If you *can* do it just *do* it. > > Don't just *talk* about doing it... > > Frankly, I don't think you can. I can, however, notice and discard crude attempts to manipulate me. Congratulations, you just pushed this task lower on my priority list. -- Eric S. Raymond From tack at auc.ca Mon Feb 2 18:34:37 2004 From: tack at auc.ca (Jason Tackaberry) Date: Mon, 02 Feb 2004 13:34:37 -0500 Subject: Developer related In-Reply-To: <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> <1075734889.4589.1.camel@pcrobert.intranet.promca.com> <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> Message-ID: <1075746877.7920.79.camel@somewhere> On Mon, 2004-02-02 at 09:57, jeffrin_jose at rajagiritech.ac.in wrote: > Do you know the procedure to become a developer ? People are replying to your question in humour and without any real answers because there is no procedure to become an official Fedora developer (except, as people mentioned, possibly getting a job at Red Hat). The Fedora project is not unlike most other OSS projects. Your status as a developer is based on your reputation, and little else. So, if you're asking about a procedure to become a developer, it might look like this: 1. Lurk on the project mailing lists for a few weeks to assess the tone of the list, observe the key developers and coordinators of the project, and practiced list etiquette (this varies from list to list). 2. Start putting your name out by answering questions on the list. It's especially important that you put research behind your posts to the list. If you come across as clueless, your reputation will be immediately tarnished. 3. See what areas of the project need development. Start off with small, low impact areas, such as documentation or small bug fixes. Or, if relevant, you might want to scratch your own itch with a certain feature, but make sure you keep the scope of impact to the project as low as possible. 4. Read all relevant documentation on contributing to the project and follow it closely. For example, some projects may detail the process of submitting patches. Deviate from that process and not only might you be flamed, but future contributions will be seen in a biased way. 5. Once you've established a name for yourself in the community, you might consider volunteering for larger responsibilities that few people like to do, such as webmaster, release coordinator, documentation grammar nazi, etc. What's available depends on the project. 6. With a good name and reputation, your opinions will weigh much more in discussions. This is important, and is key in being recognized in any OSS project. If you want to get involved in Fedora, read and follow all the docs at http://fedora.redhat.com/participate/. Cheers, Jason. -- Jason Tackaberry :: tack at auc.ca :: 705-949-2301 x330 Academic Computing Support Specialist Information Technology Services Algoma University College :: www.auc.ca From hhoffman at ip-solutions.net Mon Feb 2 18:36:17 2004 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Mon, 2 Feb 2004 13:36:17 -0500 Subject: diff Fedora Redhat 9 (or perhaps a stupid ?) Message-ID: <1075746977.7a9f9d73f2dc7@secure.ip-solutions.net> Hi, Please don't flame me too bad if this is a really stupid question, I'm still new to switching to Fedora. :-) I'm going over the ML looking for some docs that point out the differences between Fedora and RH 9. Does such a doc exist? Are Fedora and RH 9 that similar? Thanks, Harry -- Harry Hoffman hhoffman at ip-solutions.net ------------------------------------------------- This mail sent through IpSolutions: http://www.ip-solutions.net/ From skvidal at phy.duke.edu Mon Feb 2 18:39:17 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 02 Feb 2004 13:39:17 -0500 Subject: diff Fedora Redhat 9 (or perhaps a stupid ?) In-Reply-To: <1075746977.7a9f9d73f2dc7@secure.ip-solutions.net> References: <1075746977.7a9f9d73f2dc7@secure.ip-solutions.net> Message-ID: <1075747156.879.3.camel@binkley> On Mon, 2004-02-02 at 13:36, Harry Hoffman wrote: > Hi, > > Please don't flame me too bad if this is a really stupid question, I'm still new > to switching to Fedora. :-) > > I'm going over the ML looking for some docs that point out the differences > between Fedora and RH 9. Does such a doc exist? > > Are Fedora and RH 9 that similar? read the release notes. Also this question is better asked to the fedora-list - not fedora-devel-list. Thanks -sv From drepper at redhat.com Mon Feb 2 18:46:41 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 02 Feb 2004 10:46:41 -0800 Subject: Prelink hosed my binaries? In-Reply-To: <20040202120933.GC27643@devserv.devel.redhat.com> References: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> <401DDBD1.6010405@redhat.com> <20040202120933.GC27643@devserv.devel.redhat.com> Message-ID: <401E9B11.3020107@redhat.com> Alan Cox wrote: > Talking about corruption however does prelink create a new file it rewrites > into, It creates new files. > and if not what happens when prelink prelinks itself ? % file /usr/sbin/prelink /usr/sbin/prelink: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, for GNU/Linux 2.2.5, statically linked, stripped -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From mark at mark.mielke.cc Mon Feb 2 18:53:35 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 2 Feb 2004 13:53:35 -0500 Subject: [A-Z]* oddities In-Reply-To: References: <20040202181215.GA5411@nsk.no-ip.org> Message-ID: <20040202185335.GA15028@mark.mielke.cc> On Mon, Feb 02, 2004 at 01:15:01PM -0500, Behdad Esfahbod wrote: > This is totally expected :). > For what you want try LANG=C echo [A-Z]* ... > In LANG=en_US.UTF-8 which is the default, both 'A' and 'a' sort > before 'B' and 'b'. The messed up part, in my mind, is that they actually implemented it correctly. Last time I checked, the Perl authors had given up on ever getting it to work correctly... (probably scared to hurt efficiency and/or break existing programs) 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 strange at nsk.no-ip.org Mon Feb 2 19:04:22 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 2 Feb 2004 19:04:22 +0000 Subject: [A-Z]* oddities In-Reply-To: References: <20040202181215.GA5411@nsk.no-ip.org> Message-ID: <20040202190422.GA5683@nsk.no-ip.org> On Mon, Feb 02, 2004 at 01:15:01PM -0500, Behdad Esfahbod wrote: > This is totally expected :). > > For what you want try LANG=C echo [A-Z]* ... > > In LANG=en_US.UTF-8 which is the default, both 'A' and 'a' sort > before 'B' and 'b'. But 'A' is *after* 'a'? And I thought utf-8 was supposed to be compatible with ascii... Well, if that's the standard, then it isn't broken... Regards, Luciano Rocha From alan at redhat.com Mon Feb 2 20:11:00 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Feb 2004 15:11:00 -0500 Subject: Corporate pressure In-Reply-To: <1075726999.8854.12.camel@owsdavid> References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> Message-ID: <20040202201100.GA30700@devserv.devel.redhat.com> On Mon, Feb 02, 2004 at 02:03:19PM +0100, david paeme wrote: > software vendors will probably like this, because they can the user to > accept their license, and not having people install the software without > doing that. netscape did that for years, the installed binary required you register and agree to the license to use it. > also,the corporate weight of redhat -- or even some high-profile people > like ESR or AC -- could help persuade the companies. On reason for recognizing in the original Fedora proposal that there would be many other repositories was that there would be people releasing all kinds of add on stuff under all kinds of licenses, and that developers have very different relations to such things than say enterprise customers From mark at mark.mielke.cc Mon Feb 2 20:23:05 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 2 Feb 2004 15:23:05 -0500 Subject: [A-Z]* oddities In-Reply-To: <20040202190422.GA5683@nsk.no-ip.org> References: <20040202181215.GA5411@nsk.no-ip.org> <20040202190422.GA5683@nsk.no-ip.org> Message-ID: <20040202202305.GA15725@mark.mielke.cc> On Mon, Feb 02, 2004 at 07:04:22PM +0000, Luciano Miguel Ferreira Rocha wrote: > On Mon, Feb 02, 2004 at 01:15:01PM -0500, Behdad Esfahbod wrote: > > This is totally expected :). > > For what you want try LANG=C echo [A-Z]* ... > > In LANG=en_US.UTF-8 which is the default, both 'A' and 'a' sort > > before 'B' and 'b'. > But 'A' is *after* 'a'? > And I thought utf-8 was supposed to be compatible with ascii... > Well, if that's the standard, then it isn't broken... UTF-8 is an encoding scheme that allows multi-byte characters to be packed in fewer characters. ASCII is compatible with UNICODE, not UTF-8. UTF-8 can be used to encode all ASCII characters (except 0x00) without using multiple bytes. LANG really sets the locale information, which is a different beast, although a related beast. The locale information defines characters classes, and the relationship between the characters. For example, should e with an accent be outside the range a-z, just because its UNICODE value is outside the range 97-122? With LANG=C, e with an accent is outside the range a-z, just as people have been forced to live with for years. With LANG=en_US.UTF-8, e with an accent may be defined within the range a-z. As an added benefit, the sort order is more pleasing to an English user - case doesn't matter. This is far better than what we lived with in the previous decades, where one had to look in both places if one didn't know what case the filename was specified with... I've never played with this stuff in-depth, so my terminology may be inaccurate. 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 toshio at tiki-lounge.com Mon Feb 2 20:59:34 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 02 Feb 2004 15:59:34 -0500 Subject: Python package packaging question Message-ID: <1075755569.12957.1432.camel@Madison.badger.com> Hi all, What is the standard for including byte-compiled python scripts in packages? Say I have /usr/lib/python2.2/site-packages/foo.py which can byte-compile to foo.pyc (byte compiled) and foo.pyo (optimized byte-compiled. At the moment "optimized" vs normal byte-compiled just removes assert statements.) I want to include the foo.py script so everyone can see how it works. Do I also want to include the byte compiled versions to reduce startup time? Do I want to include the pyc or pyo file? I figure that if I don't include one, I still have to %ghost it in case root happens to byte-compile it later, the package will know to own the generated file. I notice that the FC1 python2.2 seems to install all three files which seems a waste of space.... -Toshio -- Toshio From misa at redhat.com Mon Feb 2 21:18:09 2004 From: misa at redhat.com (Mihai Ibanescu) Date: Mon, 2 Feb 2004 16:18:09 -0500 (EST) Subject: Python package packaging question In-Reply-To: <1075755569.12957.1432.camel@Madison.badger.com> Message-ID: On Mon, 2 Feb 2004, Toshio wrote: > Hi all, > > What is the standard for including byte-compiled python scripts in > packages? Say I have > /usr/lib/python2.2/site-packages/foo.py > which can byte-compile to foo.pyc (byte compiled) and foo.pyo (optimized > byte-compiled. At the moment "optimized" vs normal byte-compiled just > removes assert statements.) > > I want to include the foo.py script so everyone can see how it works. > Do I also want to include the byte compiled versions to reduce startup > time? Do I want to include the pyc or pyo file? Definitely. > I notice that the FC1 python2.2 seems to install all three files which > seems a waste of space.... It may seem like it. .pyc and .pyo files are there for performance reasons. .py files are there, because debugging would be a nightmare otherwise. Cheers, Misa From alan at redhat.com Mon Feb 2 21:46:42 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Feb 2004 16:46:42 -0500 Subject: [A-Z]* oddities In-Reply-To: <20040202190422.GA5683@nsk.no-ip.org> References: <20040202181215.GA5411@nsk.no-ip.org> <20040202190422.GA5683@nsk.no-ip.org> Message-ID: <20040202214642.GF30700@devserv.devel.redhat.com> On Mon, Feb 02, 2004 at 07:04:22PM +0000, Luciano Miguel Ferreira Rocha wrote: > On Mon, Feb 02, 2004 at 01:15:01PM -0500, Behdad Esfahbod wrote: > > This is totally expected :). > > > > For what you want try LANG=C echo [A-Z]* ... > > > > In LANG=en_US.UTF-8 which is the default, both 'A' and 'a' sort > > before 'B' and 'b'. > > But 'A' is *after* 'a'? > > And I thought utf-8 was supposed to be compatible with ascii... utf-8 is a character encoding. It doesn't relate to sort (or more properly "collation") order. > Well, if that's the standard, then it isn't broken... The standard depends on the actual language/location. Some sort AaBbCc others have more complex rules (a b c ch d dd e f ff g ng ...) etc Alan From alan at redhat.com Mon Feb 2 21:49:54 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Feb 2004 16:49:54 -0500 Subject: Developer related In-Reply-To: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> Message-ID: <20040202214954.GG30700@devserv.devel.redhat.com> On Mon, Feb 02, 2004 at 08:05:28PM +0530, jeffrin_jose at rajagiritech.ac.in wrote: > Hello all > > Is it possible to become a official Fedora developer by > working in a Organisation.If yes, Please tell me the > procedures to become a developer. At the moment anyone can contribute to the extras to be by following the guidelines at fedora.us. Once Cristian has finished burying various remaining problems there will be actual official paperwork for fedora extras and core contributors proper (probably closely akin to the apache contributor agreement). That is something we have to do for obvious reasons. Obviously anyone with issues about that can run their own or contribute to other repositories From nalin at redhat.com Mon Feb 2 21:55:58 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 2 Feb 2004 16:55:58 -0500 Subject: Python package packaging question In-Reply-To: References: <1075755569.12957.1432.camel@Madison.badger.com> Message-ID: <20040202215557.GA29375@redhat.com> On Mon, Feb 02, 2004 at 04:18:09PM -0500, Mihai Ibanescu wrote: > It may seem like it. .pyc and .pyo files are there for performance > reasons. .py files are there, because debugging would be a nightmare > otherwise. The byte-compiled versions will always be generated if you have write access to the directory. (This is almost always the case if you happen to run a script as root.) If you run a script as root and then attempt to uninstall the package which includes that script, some directories which are unique to the package can't be removed because the .pyc and .pyo files are still there (even though the .py files are now gone). Some packages include the byte-compiled versions of their scripts to avoid this. Personally I think all packages which include python scripts should include both the .pyc and .pyo files (and that the default RPM configuration should automate this), but I don't think there's ever been a consensus on that. Nalin From toshio at tiki-lounge.com Mon Feb 2 22:23:50 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 02 Feb 2004 17:23:50 -0500 Subject: Python package packaging question In-Reply-To: <20040202215557.GA29375@redhat.com> References: <1075755569.12957.1432.camel@Madison.badger.com> <20040202215557.GA29375@redhat.com> Message-ID: <1075760628.12957.1443.camel@Madison.badger.com> n Mon, 2004-02-02 at 16:55, Nalin Dahyabhai wrote: > On Mon, Feb 02, 2004 at 04:18:09PM -0500, Mihai Ibanescu wrote: > > It may seem like it. .pyc and .pyo files are there for performance > > reasons. .py files are there, because debugging would be a nightmare > > otherwise. > > The byte-compiled versions will always be generated if you have write > access to the directory. (This is almost always the case if you happen > to run a script as root.) If you run a script as root and then attempt > to uninstall the package which includes that script, some directories > which are unique to the package can't be removed because the .pyc and > .pyo files are still there (even though the .py files are now gone). > Right. I think the .py files are important. I think one of the pyc or pyo files would be nice (pyc because python creates those by default?) But I'm very tempted to %ghost the pyo files rather than install them because they take up more space, aren't going to be used most of the time, and don't seem to provide much of a performance change. (I believe %ghost also autoremoves the files on package de-install, if I'm wrong, would someone correct me?) > Some packages include the byte-compiled versions of their scripts to > avoid this. Personally I think all packages which include python > scripts should include both the .pyc and .pyo files (and that the > default RPM configuration should automate this), but I don't think > there's ever been a consensus on that. > I'd like to see consensus because I see a potential to generate some boilerplate code for python packaging if we can agree on what the standard should be. -Toshio -- Toshio From csm at redhat.com Mon Feb 2 22:36:37 2004 From: csm at redhat.com (Chuck Mead) Date: Mon, 02 Feb 2004 17:36:37 -0500 Subject: Developer related In-Reply-To: <1075734889.4589.1.camel@pcrobert.intranet.promca.com> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> <1075734889.4589.1.camel@pcrobert.intranet.promca.com> Message-ID: <401ED0F5.5030408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Marcano wrote: | On Mon, 2004-02-02 at 11:07, seth vidal wrote: | |>On Mon, 2004-02-02 at 09:35, jeffrin_jose at rajagiritech.ac.in wrote: |> |>>Hello all |>> |>> Is it possible to become a official Fedora developer by |>> working in a Organisation.If yes, Please tell me the |>> procedures to become a developer. |>> |>> |> |>There are official fedora developers? |> | | | those with @redhat.com email addresses :-D ;-P Crap! I have one of those addresses... now ask some of the others if I can come even *close* to accessing the build system! Pppppppfffffftttt! :-) - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAHtD1Zfy0juH51WsRAojCAJ0QaT12pnf41P3FUbOg7lWVDBRy0ACgg6Bb Toli1qsnQj0Z0990d1xB6Xo= =S60v -----END PGP SIGNATURE----- From mrsam at courier-mta.com Mon Feb 2 23:27:00 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 02 Feb 2004 18:27:00 -0500 Subject: Developer related References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> <1075734889.4589.1.camel@pcrobert.intranet.promca.com> <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> Message-ID: jeffrin_jose at rajagiritech.ac.in writes: > hello , > > Do you know the procedure to become a developer ? It's just like the procedure for getting to Carnegie Hall. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From russell at coker.com.au Tue Feb 3 00:41:23 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 3 Feb 2004 11:41:23 +1100 Subject: HD spinning is making the computer freeze In-Reply-To: <1075729586.29974.26.camel@forbidden.cipanb.ca> References: <1075729586.29974.26.camel@forbidden.cipanb.ca> Message-ID: <200402031141.23832.russell@coker.com.au> On Tue, 3 Feb 2004 00:46, Jean-Rene Cormier wrote: > Hi, I was doing some graphic editing yesterday with The Gimp and from > time to time the HD would start spinning and the computer would freeze > for like 4-5 minutes, I can't do anything during that time, the cursor > doesn't even move, all that's happening is the HD spinning. Last night I > checked how long it took to come back and it took over 10 minutes, the > clock was stuck at 11:51 and when it stopped spinning the clock changed > to 12:03. > > What could be causing this? I'm thinking that it's because I don't have > much RAM and it has to use the swap file a lot. Yes, it could be "thrashing" because of lack of RAM. Even another 128M should make it a lot faster. > Also I noticed that X use an aweful lot of RAM, is this normal? I'm > running KDE btw. > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU > COMMAND > 3750 root 15 0 413M 131M 67704 S 0.5 54.9 5:48 0 X Applications can do things that make the X server take a lot of RAM. KDE programs that display large (resolution 10,000x10,000 or more) PNG or JPG files do this. If the size of your X server is larger than physical RAM then performance will suck. Get 512M of RAM and things should be fine. Also fedora-list is the correct place for such questions. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From gerhard.prade at uni-bielefeld.de Tue Feb 3 01:38:47 2004 From: gerhard.prade at uni-bielefeld.de (Gerhard Prade) Date: Tue, 03 Feb 2004 02:38:47 +0100 Subject: Pentium 4 Message-ID: <401EFBA7.1000408@uni-bielefeld.de> Hello, i am not a developer, but have a question. I tried last time Gentoo-Linux and i think it is great to optimize a hole distribution of linux for a CPU-Achitcture (like Pentium 4 and not only for 386). But Gentoo is for me not easy to use. So i want to use in future fedora, like i do now. Now my question. It is posible to optimize one of the next releases of fedora for 686 CPU or greater like Pentium 4? Thanks all, Gerhard PS: Sorry for my bad english. From russell at coker.com.au Tue Feb 3 03:14:05 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 3 Feb 2004 14:14:05 +1100 Subject: Pentium 4 In-Reply-To: <401EFBA7.1000408@uni-bielefeld.de> References: <401EFBA7.1000408@uni-bielefeld.de> Message-ID: <200402031414.05224.russell@coker.com.au> On Tue, 3 Feb 2004 12:38, Gerhard Prade wrote: > i am not a developer, but have a question. I tried last time > Gentoo-Linux and i think it is great to optimize a hole distribution of > linux for a CPU-Achitcture (like Pentium 4 and not only for 386). > But Gentoo is for me not easy to use. So i want to use in future fedora, > like i do now. > Now my question. It is posible to optimize one of the next releases of > fedora for 686 CPU or greater like Pentium 4? The level of optimisation that Gentoo does is not desirable (IMHO). It means that every possible compiler bug related to CPU optimisation will be tickled, and that not all combinations will receive good testing which means that the chances of trying a random program on a random CPU is more likely to give bad results. When reporting a bug it may be that you have an uncommon CPU and the maintainer of the package may find it difficult to get access to the same CPU. This makes it more difficult to reproduce bugs. Distributing RPMs for all the different CPUs takes significant archive space and significant numbers of CDs. There have been many discussions of various ways of optimising programs. The conclusion of the last discussion I saw was that there is no set of optimisation options that will be best for every program on a given CPU. The question of when to use -Os and when to use -O2 is not an easy one to answer! Finally, in most cases of compiler optimisation the payoff is small. Changing the algorithms used by programs can deliver much more significant results, here are a few examples: KDE performs poorly when large amounts of text are in a window, EG when kmail displays a message with a few megs of text. I've seen the same operations run faster on other GUI software on 386 machines than kmail runs on P3 machines! kview and konqueror cause the X server to take up large amounts (600M or more) of memory when displaying 10,000 x 10,000 PNG files. Mozilla and xv display the same files without requiring any significant resource usage from the X server and the entire system runs a lot faster. As of my last test OpenLDAP was CPU bound for most of the process of importing an LDIF file and used only a single thread. So for a medium size directory 40M of CPU time would take 45M of clock time on a 2 CPU hyper-threaded machine, while ideally the work could have been done in 25M of clock time or less. GPG will in some situations take ages to update the trustdb. When I regenerated some of it's caches to try and track down another bug the update-trustdb time went from 23M to 1.5M! This should be fixed so that it will always run fast for everyone. If you make such an optimisation to one of the programs that is important to you then the results will be better than anything you could achieve through compiler optimisations. Maybe we should create a list of programs who's performance is an issue for Fedora so that interested people can start investigating them? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From salimma at fastmail.fm Tue Feb 3 03:38:17 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 10:38:17 +0700 Subject: Python package packaging question In-Reply-To: <1075755569.12957.1432.camel@Madison.badger.com> References: <1075755569.12957.1432.camel@Madison.badger.com> Message-ID: <1075779497.3752.2.camel@localhost.localdomain> On Mon, 2004-02-02 at 15:59 -0500, Toshio wrote: [snip] > I want to include the foo.py script so everyone can see how it works. > Do I also want to include the byte compiled versions to reduce startup > time? Do I want to include the pyc or pyo file? > I figure that if I don't include one, I still have to %ghost it in case > root happens to byte-compile it later, the package will know to own the > generated file. > The way Fedora.us Python packages are done, following the example of id3-py, is to include pyc and ghost the pyo. HTH, 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 salimma at fastmail.fm Tue Feb 3 04:04:45 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 11:04:45 +0700 Subject: Python package packaging question In-Reply-To: <1075760628.12957.1443.camel@Madison.badger.com> References: <1075755569.12957.1432.camel@Madison.badger.com> <20040202215557.GA29375@redhat.com> <1075760628.12957.1443.camel@Madison.badger.com> Message-ID: <1075781085.3752.6.camel@localhost.localdomain> On Mon, 2004-02-02 at 17:23 -0500, Toshio wrote: [snip] > > Some packages include the byte-compiled versions of their scripts to > > avoid this. Personally I think all packages which include python > > scripts should include both the .pyc and .pyo files (and that the > > default RPM configuration should automate this), but I don't think > > there's ever been a consensus on that. > > > I'd like to see consensus because I see a potential to generate some > boilerplate code for python packaging if we can agree on what the > standard should be. > A good idea that I have been musing about - thanks for the reminder. See attachment to the Fedora.us bugzilla entry for fedora-rpmdevtools: https://bugzilla.fedora.us/show_bug.cgi?id=1167 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 salimma at fastmail.fm Tue Feb 3 04:13:15 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 11:13:15 +0700 Subject: Developer related In-Reply-To: <1075735407.8854.19.camel@owsdavid> References: <1567.202.88.226.177.1075732528.mailer@mail.rajagiritech.ac.in> <1075734465.15564.2.camel@opus> <1075734889.4589.1.camel@pcrobert.intranet.promca.com> <1604.202.88.226.177.1075733872.mailer@mail.rajagiritech.ac.in> <1075735407.8854.19.camel@owsdavid> Message-ID: <1075781595.3752.13.camel@localhost.localdomain> On Mon, 2004-02-02 at 16:23 +0100, david paeme wrote: > > > get a job at redhat? > > > Propose a unified apt/yum-enabled third-party repository for Red Hat distros... oh wait, Warren did that, and he did get a job at RedHat :) - 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 naoki at valuecommerce.com Tue Feb 3 04:36:56 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 03 Feb 2004 13:36:56 +0900 Subject: User Linux Message-ID: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> Just been reading this : http://userlinux.com/cgi-bin/wiki.pl?White_Paper What do you guys think? Especially about the "RedHat's Proposal" section? -------------- next part -------------- An HTML attachment was scrubbed... URL: From salimma at fastmail.fm Tue Feb 3 04:57:45 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 11:57:45 +0700 Subject: Corporate pressure In-Reply-To: <20040202182320.GG30711@thyrsus.com> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> <20040202182320.GG30711@thyrsus.com> Message-ID: <1075784265.5047.10.camel@localhost.localdomain> On Mon, 2004-02-02 at 13:23 -0500, Eric S. Raymond wrote: > Steve Bergman : > > If you *can* do it just *do* it. > > > > Don't just *talk* about doing it... > > > > Frankly, I don't think you can. > > I can, however, notice and discard crude attempts to manipulate me. > Congratulations, you just pushed this task lower on my priority list. Please do not let scathing remarks by one poster from discouraging you. Having more support by commercial multimedia vendor is a good thingTM, and personal politics should have nothing to do with it. I, for one, would love to see a tested Helix Player being part of Fedora and other distributions. Especially since it's a pain to get the snapshots to work on my FC1/2-devel hybrid... Will have to give it a go again after a clean install of the upcoming FC2t1 - 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 zaitcev at redhat.com Tue Feb 3 05:29:58 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 2 Feb 2004 21:29:58 -0800 Subject: User Linux In-Reply-To: References: Message-ID: <20040202212958.3933ac3c.zaitcev@redhat.com> On Tue, 03 Feb 2004 13:36:56 +0900 Naoki wrote: > What do you guys think? Especially about the "RedHat's Proposal" > section? We think this discussion does not belong to fedora-devel-list. Please troll elsewhere. -- Pete From wtogami at redhat.com Tue Feb 3 07:06:30 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Feb 2004 21:06:30 -1000 Subject: Synaptics driver in Fedora Message-ID: <401F4876.7060200@redhat.com> Mike Harris said that he would integrate the Synaptics touchpad driver into the Fedora RPM if somebody does the necessary work to integrate it cleanly, test, and submit the patches. It is an extremely low priority for him so it is highly unlikely that it wont happen unless somebody does this necessary work. I would suggest posting your suggested patches for the .spec and discuss driver setup procedure on this list, if you prepare this. Warren Togami wtogami at redhat.com From mharris at redhat.com Tue Feb 3 07:09:27 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 02:09:27 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: Message-ID: On Mon, 2 Feb 2004, Sam Varshavchik wrote: >> All rpm packages containing applications/libs which link to the >> standard X11 libraries, currently have hard coded dependancies >> such as: >> >> Requires: XFree86-libs >> Buildrequires: XFree86-devel > >At least the first part should not be necessary. > >find-requires.pl will automatically add dependencies on every shared library >loaded by any binary in the package. pan, for example, automatically gets a >dependency on libgdk-x11-2.0.so.0, by the virtue of linking with it. Correct, but I don't want to assume that there are no packages out there that don't explicitly list that. Or for non-native-English readers, to eliminate the triple negative I just used without thinking... I want to assume that there are packages out there that do list that. >This dependency is provided by the gtk2 RPM which, in turn, >automatically has a dependency on libX11.so.6, libXext.so.6, and >others, by the virtue of linking against those libraries. This >is sufficient to require XFree86-libs. Sure... >I don't think you need anything special to correctly resolve >runtime dependency of X applications. If you use a substitute >X11 server+libraries, as long as the substitute installs >libX11.so.6, et al, everything will work correctly. The problem being solved is if something already _does_ require that package. I would not be willing to state "zero rpm packages in the distribution, and zero rpm packages outside of the distribution have a hard coded dependancy on XFree86-libs". In fact it's possible some package might have: Requires: XFree86-libs >= 4.3.0 in order to meet some bugfix dependancy that occured over time or something. In short, I assume nothing, plan for the worst and hope for the best. >find-provides.pl automatically declares a provides for all matching shared >libraries installed by the package, so you do not need to do anything >explicit with the substitute X11 servers/runtime libraries. As long as they >install shared libraries that have the same names (even if they are >installed in different directories!), all runtime dependencies will be >satisfied. But find-provides can only handle automatic dependancies on a library or whatnot, it can't know things like "that version of the library was broken, force the requirement of a newer version". >As far as development libraries go, it does look like an >explicit Requires: may be necessary. Yep. >You might be able to get away with adding "Provides: >XFree86-devel" to substitute X development libraries. It >shouldn't prevent them from co-habiting with the real >XFree86-devel, or other substitutes, and RPMs that explicitly >require XFree86-devel should still be buildable. That is not an option unless the package containing the XFree86-devel virtual provides either contains all of the things that the current XFree86-devel has in it, or it has itself dependancies on every other package that contains those things. Here is the list of non-header, non lib .so files from XFree86-devel: /usr/X11R6/bin/cxpm /usr/X11R6/bin/gccmakedep /usr/X11R6/bin/imake /usr/X11R6/bin/makedepend /usr/X11R6/bin/makeg /usr/X11R6/bin/pswrap /usr/X11R6/bin/rman /usr/X11R6/bin/sxpm /usr/X11R6/bin/xmkmf /usr/X11R6/lib/X11/config/* (lots and lots of stuff) /usr/X11R6/man* (manpages for all included apps and lib functions) The manpages, .so, and .a files, would move into the foo-lib-devel packages of course, however the above apps above would be moved to some other package, probably foo-X11-devel-utils or some other package name (need more thought on that still). Manpages could either be in foo-X11-devel-docs or just foo-X11-docs or something, or they could be in each individual library's -devel package (which would be simplest as they reside along with the libraries themselves rather than all in one place). The config/* stuff is the difficult part, which is a problem I don't want to remotely think about quite yet and I'm pretending it doesn't exist for now. Keith Packard has a great idea for how to solve that, but it isn't a "done deal" yet. It only affects things that are outside of XFree86/X11 that also compile with Imake mostly. A problem to solve, but that's a problem for another rainy day in the future. ;o) For now I just want to focus on solving the genericization of X11 API implementations in rpm context. Imake and whatnot files above will probably be next on the list though, and perhaps even part of that fun ride. ;o) One other thing to consider, which I hadn't mentioned previously, is that there is a strong push to make /usr/X11R6 disappear in the future at some point, and many libs already are in /usr/lib such as fontconfig, and others. If they move into /usr/lib, they still meet dependancies for being there, but the file names and paths to the libs probably wont be the same. Not sure yet if we will be doing this sooner or later, but it's something to keep in mind also, even though it's not the problem being solved yet. Thanks for the feedback, it's given some brain food think upon. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From petersen at redhat.com Tue Feb 3 07:11:03 2004 From: petersen at redhat.com (Jens Petersen) Date: Tue, 03 Feb 2004 16:11:03 +0900 Subject: release candidate zsh configs In-Reply-To: <401A28E6.3010403@imapmail.org> References: <401A28E6.3010403@imapmail.org> Message-ID: Hi Eric, >>>>> "EH" == Eric Hattemer writes: EH> The zsh config files in EH> http://isd.usc.edu/~ehatteme/zsh/zshetc.tar.bz2 EH> (link of ./zsh-etc-1-30-01PST.tar.bz2) are ready for EH> submission. Thanks. :) Actually it would be good if you could put this rfe into bugzilla. That way I won't forgot about it: though I hope to take a look at it before too long, it would be very good to have a record of the changes there. EH> I would like to remove /etc/skel/.zshrc EH> because it is not expected that someone will install EH> zsh before adding users. All it does is source EH> /etc/profile, which I moved into /etc/zshrc. Well, no there is a reason for that, see: . Jens From petersen at redhat.com Tue Feb 3 07:30:15 2004 From: petersen at redhat.com (Jens Petersen) Date: Tue, 03 Feb 2004 16:30:15 +0900 Subject: gettext vs automake In-Reply-To: <20040202094147.GE25654@redhat.com> References: <20040129155641.GL28127@redhat.com> <1075408058.6108.24.camel@localhost.localdomain> <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> <20040202094147.GE25654@redhat.com> Message-ID: >>>>> "TW" == Tim Waugh writes: TW> an automake17 package would probably avoid any other TW> problems developers might run into, such as the TW> glib-gettext.m4 macros requiring automake<1.8. Apart from the mkinstalldirs issue, are there other problems with glib-gettext.m4 and Automake 1.8? Jens From mharris at redhat.com Tue Feb 3 07:50:07 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 02:50:07 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <1075732633.12957.1392.camel@Madison.badger.com> References: <1075732633.12957.1392.camel@Madison.badger.com> Message-ID: On Mon, 2 Feb 2004, Toshio wrote: >> 1) Allow multiple X11 implemenations to be available in rpm >> packaging, and be substituted with each other easily. >> >If you are going to package freedesktop-X11 as separate packages for >each library, then the XFree86 libraries also should be split into >separate binary packages so people can actually play with alternative >implementations of a subset of the X libraries. (May have been implied, >but it wasn't actually mentioned as being part of the plan.) No, I have no intention of repackaging XFree86 libraries into individual rpm packages. There is no useful reason to do so, and it would just increase the complexity of the XFree86 package rather signficantly. I don't want people having one lib from one implementation and another from a different implementation for example. That serves no useful purpose to my goals at least. However, it is entirely possible that someone else out there might want to whip up their own rpms with things split out like that. I wont stop them, however if they do so, they're on their own, and can likely expect massive problems. ;o) >> 2) Allow X11 software to compile, link, build and produce >> packages irrespective of which implemenation is present. This >> is important, because X11 is a standard, and so any compliant >> implementation should be substitutable, at least for the bits >> that are actually official standards. > >Are we going to be troubleshooting this or upstream? Or is it "upstream >cares about this and when we find it doesn't work as expected we'll >point it out to them"? That depends on the nature of the hypothetical problem that you haven't stated, and where it would lay in the mix of things. Obviously if someone finds an implementation bug in some library, in any implementation, both the authors of the upstream library, as well as Red Hat will be concerned. In comment #2 above however, I'm more concerned about API and linkage time problems than runtime ABI problems. ABI issues are an important thing also, but unrelated to coming up with universal and generic distribution packaging for various X11 implementations. ABI problems would be best handled via upstream bug reports, but would be useful in Red Hat bugzilla also (for implementations we ship that is). Again that's a problem unrelated, and not covered by this proposal however. >> 3) Allow X11 software binary rpm packages which were compiled >> with any X11 implementation, to install cleanly on a system >> which has any X11 implementation installed. Of course, in >> this particular case, only "official standard" parts of the >> given X11 implementation should be interchangeable 100%, >> however implementation specific features may require >> additional dependancies. > >So we'll have to break apart X11 providing packages into standard's >providing pieces and extras providing pieces wherever possible. Not sure what you mean by that, but perhaps my #3 above wasn't clear either. Let me expand upon it. What I mean above is that "libX11" is a standard API, which should be compatible at the source and binary level between implementations. libXinerama however is not standard at all. It is an XFree86 specific custom extension. X.org has an "official" Xinerama extension proposed which is not yet "standard" so to speak, and not included in any implementation out there yet. The two APIs are not compatible with each other, however X.org's API is in libExt aparently instead of a separate lib, so they should co-reside if needbe I am told. Another example is "XFIXES". That extension is experimental and only present in kdrive currently. It is very likely to be included in future X implementations in some form or another, however if it is included in one implementation and some application gets built to require it, there needs to be a way to specify that dependancy. As these issues get discovered, I'll handle them one at a time, however it's at least partially a different problem to solve at least for future stuff like XFIXES. There are other extensions present in XFree86 which are present in some other implementations, such as RENDER and RANDR. If an app requires those to compile, then you need an implementation that provides those APIs installed to develop with, and a way of specifying those dependancies. My proposed method should handle this, as an implementation that doesn't provide these "not-yet-standard" APIs just wont Provide: them anywhere. That makes sense, as apps that use these non-standard implementations - depend on them. Any implementation that doesn't supply them, is well.... useless, and thus not in the scope of the problem being solved. ;o) In other words, GNOME, KDE, and large numbers of other software components out there, _require_ things like Xft, RENDER, RandR now (although some or all of that is likely compile time configurable, but you'd have to ask GNOME developers to be sure). So gnome needs a way of building that says "I need RandR-devel at compile time, or there is no Gnome resolution switcher applet to change res on the fly", etc. Build GNOME against rpmified X.org's X11R5 and you wont get RENDER or RANDR. ;o) >Regarding the new Requires: Is it really necessary to Require: >XFree86-libs right now? Yes. $ rpm -q --whatrequires XFree86-libs kdenetwork-2.2.2-0.71.0 XFree86-xfs-4.1.0-50 XFree86-4.1.0-50 XFree86-devel-4.1.0-50 XFree86-twm-4.1.0-50 $ rpm -q --whatrequires XFree86-libs XFree86-4.3.0-15.1 XFree86-devel-4.3.0-15.1 XFree86-twm-4.3.0-15.1 XFree86-xfs-4.3.0-15.1 The question then becomes "are those above dependancies necessary?" The answer depends on the package of course. I've no idea why kdenetwork requires it, but that OS release is rather old, so it might not be valid anymore. XFree86-devel requires it because the .so libs in -devel require the .so.* files to be present in order to function correctly. The XFree86-xfs and XFree86-twm packages would drag in XFree86-libs on their own via autodependancies, however *any* -libs package would satisfy it. I explicitly want the ver-rel of twm, xfs installed to explicitly require the exact ver-rel of XFree86-libs to be installed, due to some problem from ages ago which I don't remember. Of course, those dependancies would have to change in the future to work with the new proposal. ;o) However, the general answer aside from certain specific exceptions is "no, autodeps handle almost everything". For the cases which they don't handle, I believe Conflicts: lines might suffice. >Shouldn't rpm's automatic dependencies drag in libX11.so which >is found in XFree86-libs. Couldn't we get rid of dependency on >XFree86-libs and not replace it? Yes and no. Right now I have intentional dependancies present explicitly, such as: Requires: XFree86-xfs = %{version}-%{release}, XFree86-libs = %{version}-%{release} That is intended to FORCE people who upgrade XFree86-xfs to also upgrade XFree86-libs. I don't remember the original reason it was added, but I don't add such dependancies usually unless some ugly problem occured in which I dropped a shotgun in to fix it. Some people want to save 2 minutes download time for example so might only upgrade -xfs if they have a problem, but the fix might be in XFree86-libs current package. This way, when a new XFree86 release is released, and someone upgrades one component, they are forced to upgrade them all, so I don't get bug reports coming in due to long since fixed problems. That sledgehammer "upgrade your system please" approach might not work with the new proposal, and so I will probably have to revisit these individual special cases again. Other packages probably have similar sledgehammers in place here and there. I'm sure there's another solution though. >Separate problem: we have to identify packages which can simply depend >on finding any /usr/lib/{X11/}libX11.so in the filesystem and those >which need a specific implementation of libX11. So I think we need the >capability to Provide/Require: XFree86-libX11 and freedesktop-libX11. >This will be something of a headache as we really need finer grained >tracking than rpm provides. Virtual provides can handle that problem well enough I believe. >Maybe we'll need extra web infrastructure that tells us XFree86-libX11 >provides (standards, X11_nonstandard_gizmo) while freedesktop-libX11 >provides (standards, X11_nonstandard_whizzo) and developers can check if >those things are ever reconciled/build separate packages for the >different xlibs, etc (ugh). I'd prefer to not get that complicated if possible, but if it turns out to be something universally required, it's not outside the realm of possibility. I think if some app requires a specific implementation's lib and no other implementation provides it, a quick hack would be to Require: freedesktop-libXfixes for example. In other words, there are some apps that WILL still require specific implementation present most likely. The only way to avoid that, is to completely disallow anything as an X extension that isn't approved by X.org directly. However reality is that developers working on new standards don't always have 10 years to wait for X.org to gather interest in a proposed new API and then to standardize it. Look at Xinerama for example. It's been implemented in XFree86 forever more or less now. X.org is just now planning on coming out with a totally incompatible Xinerama standard with a different API. Would everyone who has used Xinerama for the last 3-4 years have preferred to wait for X.org to release Xinerama? ;o) So there will definitely be APIs that are unique to an implementation out there, and a properly coded app should check both at compile time, *and* at runtime, and if the extension isn't available at runtime, the app should fallback to not using it. Most apps do this already of course. >Hopefully most API/ABI enhancements will be done in true add-ons rather >than entangled with standard pieces like this.... They generally are on the client side. Client side stuff is in things like libXinerama, libXrender, libXrandr, etc. Whereas standardized stuff tends to go into libXext. The difference is more on the server side, where the X server may or may not support a given extension, however it is up to all applications to test at runtime for nonstandard extensions, as they are non-standard by definition. They should provide fallbacks in that case. Implementation defined stuff will appear in implementation defined libraries. There are some "issues" with this, such as the XFree86 "MISC" extension, which provides special things specific to XFree86's server, however apps should be properly querying for that stuff anyway. Apps that *require* it, should by definition: Require: XFree86-libs or whatever as they're implementation specific. You do bring up some interesting complexities of course, and they'll need to be explored also once the immediate issues are dealt with. I forsee an "ok, let's try this and see what all breaks" day coming up in the future. Should be fun. ;) Thanks for feedback! TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 3 08:01:53 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:01:53 -0500 (EST) Subject: Corporate pressure In-Reply-To: <1075726999.8854.12.camel@owsdavid> References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> Message-ID: On Mon, 2 Feb 2004, david paeme wrote: >wouldn't it be a good idea to include some kind of license acceptance >mechanism into apt/yum/rpm? It is an explicit goal and requirement of RPM that all RPM packages must be installable without user input of any kind, in order to facilitate automatic unattended installation, or installation/upgrade from cronjob/script, etc. I don't know apt or yum's policies or goals in this regard so I'll let their respective authors, etc. answer for them though. >for example, to get adobe acrobat to install, the user would get a >prompt to accept the adobe license, which he can (and the software >installs), or not (so, it doesn't install...). Again, unacceptable to rpm. That belongs in some frontend, either yum/apt/up2date or some Installshield type of rpm package wrapper install tool. >software vendors will probably like this, because they can the user to >accept their license, and not having people install the software without >doing that. They can do that already if they want, by supplying a wrapper application with the rpm payload inside of it. >and this could work for just about anything (java, flash, binary drivers >like those from nvidia, etc...) > >also,the corporate weight of redhat -- or even some high-profile people >like ESR or AC -- could help persuade the companies. For the case of yum or apt, Red Hat has no say whatsoever in what those project's respective developers put in their applications as features. While I personally am indifferent, many other people would be likely to oppose such changes as they would help to promote the usage of proprietary software and make it easier to use. Outside of yum/apt, it would be entirely in the domain of some wrapper application that pops up a text and/or GUI dialog to handle the installation, get the user to accept a EULA, and then either calls rpm directly after the user has accepted, or uses rpmlib to do the dirty work. In both cases, it's up to the application vendor to write their own custom installation app to do this, or to look for a pre-existing framework out there that does it already. I believe Loki games OSS'd something like this, but I don't remember for sure. There's little benefit for free software community for us to develop some proprietary software installer frontend, so it's unlikely IMHO that anyone here would write something like that and try to peddle it to 3rd party proprietary vendors (for free or for $$$). If proprietary vendors aren't interested in doing such though, but certain people in the OSS community are, they should approach those vendors to either politely try to convince them to do so, or to volunteer to do the work themselves if the vendor allows it, as was the case for Nvidia. I'm not sure where someone like ESR or AC fit into the picture. They would both be good candidates for trying to convince a given vendor of the merits of OSS and trying to get them to OSS their software of course. But I'm not sure a vendor is likely to care about how their stuff is packaged and wether or not it meets some "easy to install and use in Linux" thing that they have to implement themselves. At least not until they see some "critical mass" form that makes their radars blip. Just my personal opinion on this anyway. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 3 08:06:36 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:06:36 -0500 (EST) Subject: Corporate pressure In-Reply-To: <20040202182320.GG30711@thyrsus.com> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> <20040202182320.GG30711@thyrsus.com> Message-ID: On Mon, 2 Feb 2004, Eric S. Raymond wrote: >> If you *can* do it just *do* it. >> >> Don't just *talk* about doing it... >> >> Frankly, I don't think you can. > >I can, however, notice and discard crude attempts to manipulate me. >Congratulations, you just pushed this task lower on my priority list. Eric, you're too polite to such people. I would have removed it totally from my priority list personally. ;o) I don't take end user demands like the above anywhere near as nicely as you have just now. ;o) The above rudeness you just endured, makes me want to add "Conflicts: acroread" to XFree86-libs just for fun. ;o) I wont of course, as I use acroread myself in rpm format. ;o) TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From pmatilai at welho.com Tue Feb 3 08:10:35 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 3 Feb 2004 10:10:35 +0200 (EET) Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075666535.24061.15.camel@binkley> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> Message-ID: On Sun, 1 Feb 2004, seth vidal wrote: > > > I suppose this covers things like mirror information? If not that should > > be added separately. > > > > > > > > - meta-repositories (or repository groups) > > a thought here - what about having repository-wide-provides and > repository-wide-dependencies? > > It'd be interesting to have: rpm.livna.org depends on fedora-core, > fedora-extras > > would be hard to control, but potentially interesting. Mmm, interesting idea indeed. I like it. While on the subject of common metadata (like I suspected the ideas/issues start coming up once you start actually looking into implementing it :) - don't worry, no showstoppers so far, just a couple of things to (re)consider: - Do we really want users to download all the src.rpm data each time? Most users don't do anything with that information so it sucks up bandwidth for no purpose. Maybe the src.rpm file information should be separated to different files? - Any particular reason for using gzip instead of bzip2? The difference can be huge, especially for other.xml: -rw-rw-r-- 1 pmatilai pmatilai 3399842 Feb 3 09:58 filelists.xml.bz2 -rw-rw-r-- 1 pmatilai pmatilai 4267044 Feb 3 09:56 filelists.xml.gz -rw-rw-r-- 1 pmatilai pmatilai 6297754 Feb 3 10:00 other.xml.bz2 -rw-rw-r-- 1 pmatilai pmatilai 13301830 Feb 3 09:56 other.xml.gz -rw-rw-r-- 1 pmatilai pmatilai 1011254 Feb 3 09:57 primary.xml.bz2 -rw-rw-r-- 1 pmatilai pmatilai 1443432 Feb 3 09:56 primary.xml.gz -rw-rw-r-- 1 pmatilai pmatilai 666 Feb 3 09:56 repomd.xml - Panu - From mharris at redhat.com Tue Feb 3 08:12:02 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:12:02 -0500 (EST) Subject: Corporate pressure In-Reply-To: <1075784265.5047.10.camel@localhost.localdomain> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> <20040202182320.GG30711@thyrsus.com> <1075784265.5047.10.camel@localhost.localdomain> Message-ID: On Tue, 3 Feb 2004, Michel Alexandre Salim wrote: >> > If you *can* do it just *do* it. >> > >> > Don't just *talk* about doing it... >> > >> > Frankly, I don't think you can. >> >> I can, however, notice and discard crude attempts to manipulate me. >> Congratulations, you just pushed this task lower on my priority list. > >Please do not let scathing remarks by one poster from discouraging you. >Having more support by commercial multimedia vendor is a good thingTM, >and personal politics should have nothing to do with it. I disagree. Eric has done quite a large number of things for the OSS community over the years, and he very much owes NOBODY *ANYTHING*. Like the majority of developers and OSS advocates out there, he no doubt has a TODO/priority list that is 10 times longer than can be humanly accomplished in a lifetime. In such cases, one must prioritize them based on various factors, and one of those factors that a volunteer will consider is "what's in it for me?". For some, it's "personal satisfaction", for others it might be "scratch an itch", or "fame", or some other motivation. For a complete list, buy Eric's book and read it. One of the things notably missing from the list of "motivating factors for volunteers to do stuff for free" is "rude people making obnoxious demands". That particular item is on the "ways to get someone to never listen to you again, and purposefully do the opposite of what you want" list. Well, it's not in the book, but it's what I practice anyway. Perhaps Eric will add it to future revisions of The Cathedral & the Bazaar. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 3 08:14:35 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:14:35 -0500 (EST) Subject: HD spinning is making the computer freeze In-Reply-To: <1075729586.29974.26.camel@forbidden.cipanb.ca> References: <1075729586.29974.26.camel@forbidden.cipanb.ca> Message-ID: On Mon, 2 Feb 2004, Jean-Rene Cormier wrote: >Also I noticed that X use an aweful lot of RAM, is this normal? I'm >running KDE btw. > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU >COMMAND > 3750 root 15 0 413M 131M 67704 S 0.5 54.9 5:48 0 X "X is using an enormous amount of RAM, is it broken? Is it memory leaking?" is a very frequently asked question that comes up way too often. Rather than get into the detailed answer, which is preserved all over google, and on mailing list archives for years, the short answer is: No. The longer answer is: Download a copy of "xrestop", findable with google, and use it to find the broken applications which are leaking pixmaps or other X resources. More of a fedora-list question than a development related one though. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From hattenator at imapmail.org Tue Feb 3 08:18:08 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:18:08 -0800 Subject: release candidate zsh configs In-Reply-To: References: <401A28E6.3010403@imapmail.org> Message-ID: <401F5940.5080401@imapmail.org> >Thanks. :) > >Actually it would be good if you could put this rfe into >bugzilla. That way I won't forgot about it: though I hope >to take a look at it before too long, it would be very good >to have a record of the changes there. > I will file it two days from now. Sorry that I don't have time at the moment. > > EH> I would like to remove /etc/skel/.zshrc > EH> because it is not expected that someone will install > EH> zsh before adding users. All it does is source > EH> /etc/profile, which I moved into /etc/zshrc. > >Well, no there is a reason for that, see: > . > There is some good discussion there, but I am considering reopening that bug to get some more ideas about the situation. I suppose the situation is that redhat wants to give people the ability not to source in bash /etc/bashrc, or /etc/profile, and allow them to not source in zsh /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc can allow them to decide on whether to source the /etc/profile. But the reason bash can get away with putting things in skel is that its automatically installed before adduser root, right? zsh is likely to be added after users are added, and therefore would not copy over the skel .zshrc, right? Unless the rpm checks to see if each user has a ~/.zshrc, this may be a problem. This is why I thought sourcing /etc/profile should be done in /etc/z*, but I suppose that doesn't give the user a choice to not source /etc/profile. Maybe there is a solution that would allow all of this to work together. -Eric Hattemer From pmatilai at welho.com Tue Feb 3 08:18:52 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 3 Feb 2004 10:18:52 +0200 (EET) Subject: Corporate pressure In-Reply-To: References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> Message-ID: On Tue, 3 Feb 2004, Mike A. Harris wrote: > On Mon, 2 Feb 2004, david paeme wrote: > > >wouldn't it be a good idea to include some kind of license acceptance > >mechanism into apt/yum/rpm? > > It is an explicit goal and requirement of RPM that all RPM > packages must be installable without user input of any kind, in > order to facilitate automatic unattended installation, or > installation/upgrade from cronjob/script, etc. > > I don't know apt or yum's policies or goals in this regard so > I'll let their respective authors, etc. answer for them though. > > > >for example, to get adobe acrobat to install, the user would get a > >prompt to accept the adobe license, which he can (and the software > >installs), or not (so, it doesn't install...). > > Again, unacceptable to rpm. That belongs in some frontend, > either yum/apt/up2date or some Installshield type of rpm package > wrapper install tool. And just as unacceptable for apt-rpm. In Debian packages can ask questions but that's another story. If vendors want popup EULA's they can show them on first launch of the software, we don't that mess into package managers/frontends. - Panu - From mharris at redhat.com Tue Feb 3 08:21:00 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:21:00 -0500 (EST) Subject: [A-Z]* oddities In-Reply-To: <20040202181215.GA5411@nsk.no-ip.org> References: <20040202181215.GA5411@nsk.no-ip.org> Message-ID: On Mon, 2 Feb 2004, Luciano Miguel Ferreira Rocha wrote: >Date: Mon, 2 Feb 2004 18:12:15 +0000 >From: Luciano Miguel Ferreira Rocha >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: Development discussions related to Fedora Core > >Subject: [A-Z]* oddities > > >Hi, > >On fedora devel I get the following unexpected behaviour: Welcome to internationalization (I hate saying i18n, it just seems so non-internationalized an abbreviation). Different locales have different language sorting rules depending on the locale in question. My assumption is that you're expecting a specific collation order such as the legacy "C" or "POSIX" sorting rules, however you're not using that locale and instead are getting sorting which is locale dependant? If so, decide which collation you want, and set LC_COLLATE to that. For example, in my .bashrc I have: # Get rid of UTF-8 performance loss. export LANG=en_US # Sort stuff the sane oldschool UNIX way export LC_COLLATE=C If none of this advice changes anything or helps your problem, then it is probably some other issue, and perhaps someone can help you on fedora-list. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From david.paeme at belbone.net Tue Feb 3 08:21:27 2004 From: david.paeme at belbone.net (david paeme) Date: Tue, 03 Feb 2004 09:21:27 +0100 Subject: Corporate pressure In-Reply-To: References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> Message-ID: <1075796486.11811.1.camel@owsdavid> popup on first run... i think that that's a better idea that the apt/yum/rpm thing. but imagine the scared look on joe average's face when his favorite website doesn't display ;-) (and how about drivers?) On Tue, 2004-02-03 at 09:18, Panu Matilainen wrote: > On Tue, 3 Feb 2004, Mike A. Harris wrote: > > > On Mon, 2 Feb 2004, david paeme wrote: > > > > >wouldn't it be a good idea to include some kind of license acceptance > > >mechanism into apt/yum/rpm? > > > > It is an explicit goal and requirement of RPM that all RPM > > packages must be installable without user input of any kind, in > > order to facilitate automatic unattended installation, or > > installation/upgrade from cronjob/script, etc. > > > > I don't know apt or yum's policies or goals in this regard so > > I'll let their respective authors, etc. answer for them though. > > > > > > >for example, to get adobe acrobat to install, the user would get a > > >prompt to accept the adobe license, which he can (and the software > > >installs), or not (so, it doesn't install...). > > > > Again, unacceptable to rpm. That belongs in some frontend, > > either yum/apt/up2date or some Installshield type of rpm package > > wrapper install tool. > > And just as unacceptable for apt-rpm. In Debian packages can ask questions > but that's another story. > > If vendors want popup EULA's they can show them on first launch of the > software, we don't that mess into package managers/frontends. > > - Panu - > From mharris at redhat.com Tue Feb 3 08:26:20 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:26:20 -0500 (EST) Subject: Synaptics driver in Fedora In-Reply-To: <401F4876.7060200@redhat.com> References: <401F4876.7060200@redhat.com> Message-ID: On Mon, 2 Feb 2004, Warren Togami wrote: >Mike Harris said that he would integrate the Synaptics touchpad driver >into the Fedora RPM if somebody does the necessary work to integrate it >cleanly, test, and submit the patches. It is an extremely low priority >for him so it is highly unlikely that it wont happen unless somebody >does this necessary work. > >I would suggest posting your suggested patches for the .spec and discuss >driver setup procedure on this list, if you prepare this. To clarify.... The synaptics package wont compile with the XFree86-SDK. Paul Nasrat has worked on this but never sent me a patch that cleanly applies to the current Fedora rpm, and cleanly compiles. (the last patch applied but didn't compile). It's not a priority to me, so I haven't looked into fixing it, however if Paul or someone else wants to fix it and send me via bugzilla, the proper patch that allows the synaptics rpm to compile using the XFree86-SDK, having *tested* the patch with XFree86 src.rpm first, and compiled the synaptics driver against it, I'd be glad to add it to FC2. I might also then add the synaptics package also, but that's something I'd need to review first before commiting to it. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From pmatilai at welho.com Tue Feb 3 08:37:35 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 3 Feb 2004 10:37:35 +0200 (EET) Subject: Corporate pressure In-Reply-To: <1075796486.11811.1.camel@owsdavid> References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> <1075796486.11811.1.camel@owsdavid> Message-ID: On Tue, 3 Feb 2004, david paeme wrote: > popup on first run... > > i think that that's a better idea that the apt/yum/rpm thing. > > > but imagine the scared look on joe average's face when his favorite > website doesn't display ;-) Netscape always did that (at least for 4.x, dunno about newer ones) and got away with it, can't be that bad. > > (and how about drivers?) Drivers typically come with some kind of configuration software which can do the "popup on first run" thingy (even if it's just terminal based like vmware for example has). - Panu - From hattenator at imapmail.org Tue Feb 3 08:38:48 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:38:48 -0800 Subject: release candidate zsh configs In-Reply-To: References: <401A28E6.3010403@imapmail.org> Message-ID: <401F5E18.1030408@imapmail.org> >Thanks. :) > >Actually it would be good if you could put this rfe into >bugzilla. That way I won't forgot about it: though I hope >to take a look at it before too long, it would be very good >to have a record of the changes there. > I will file it two days from now. Sorry that I don't have time at the moment. > > EH> I would like to remove /etc/skel/.zshrc > EH> because it is not expected that someone will install > EH> zsh before adding users. All it does is source > EH> /etc/profile, which I moved into /etc/zshrc. > >Well, no there is a reason for that, see: > . > There is some good discussion there, but I am considering reopening that bug to get some more ideas about the situation. I suppose the situation is that redhat wants to give people the ability not to source in bash /etc/bashrc, or /etc/profile, and allow them to not source in zsh /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc can allow them to decide on whether to source the /etc/profile. But the reason bash can get away with putting things in skel is that its automatically installed before adduser root, right? zsh is likely to be added after users are added, and therefore would not copy over the skel .zshrc, right? Unless the rpm checks to see if each user has a ~/.zshrc, this may be a problem. This is why I thought sourcing /etc/profile should be done in /etc/z*, but I suppose that doesn't give the user a choice to not source /etc/profile. I installed zsh after my root and eric users. Does the fedora installer copy over /etc/skel/.zshrc after it adds users? Maybe there is a solution that would allow all of this to work together. -Eric Hattemer From mharris at redhat.com Tue Feb 3 08:41:45 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 03:41:45 -0500 (EST) Subject: Python package packaging question In-Reply-To: <20040202215557.GA29375@redhat.com> References: <1075755569.12957.1432.camel@Madison.badger.com> <20040202215557.GA29375@redhat.com> Message-ID: On Mon, 2 Feb 2004, Nalin Dahyabhai wrote: >Date: Mon, 2 Feb 2004 16:55:58 -0500 >From: Nalin Dahyabhai >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: Development discussions related to Fedora Core > >Subject: Re: Python package packaging question > >On Mon, Feb 02, 2004 at 04:18:09PM -0500, Mihai Ibanescu wrote: >> It may seem like it. .pyc and .pyo files are there for performance >> reasons. .py files are there, because debugging would be a nightmare >> otherwise. > >The byte-compiled versions will always be generated if you have write >access to the directory. (This is almost always the case if you happen >to run a script as root.) If you run a script as root and then attempt >to uninstall the package which includes that script, some directories >which are unique to the package can't be removed because the .pyc and >.pyo files are still there (even though the .py files are now gone). > >Some packages include the byte-compiled versions of their scripts to >avoid this. Personally I think all packages which include python >scripts should include both the .pyc and .pyo files (and that the >default RPM configuration should automate this), but I don't think >there's ever been a consensus on that. For the case in which the .pyc and .pyo files are not included in the rpm package, the best solution IMHO, is to have the rpm package do the following for those files: %ghost %verify(not md5 size mtime) /path/to/foo.py[co] Of course, the end of %install section of spec file needs to 'touch' all of those files so they exist in the buildroot for packaging. When the package is uninstalled, if I recall correctly, rpm will delete those files even though they weren't included with the installation to begin with. The %ghost makes the package own them. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From hattenator at imapmail.org Tue Feb 3 08:44:21 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:44:21 -0800 Subject: release candidate zsh configs In-Reply-To: References: <401A28E6.3010403@imapmail.org> Message-ID: <401F5F65.5070608@imapmail.org> >Thanks. :) > >Actually it would be good if you could put this rfe into >bugzilla. That way I won't forgot about it: though I hope >to take a look at it before too long, it would be very good >to have a record of the changes there. > I will file it two days from now. Sorry that I don't have time at the moment. > > EH> I would like to remove /etc/skel/.zshrc > EH> because it is not expected that someone will install > EH> zsh before adding users. All it does is source > EH> /etc/profile, which I moved into /etc/zshrc. > >Well, no there is a reason for that, see: > . > There is some good discussion there, but I am considering reopening that bug to get some more ideas about the situation. I suppose the situation is that redhat wants to give people the ability not to source in bash /etc/bashrc, or /etc/profile, and allow them to not source in zsh /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc can allow them to decide on whether to source the /etc/profile. But the reason bash can get away with putting things in skel is that its automatically installed before adduser root, right? zsh is likely to be added after users are added, and therefore would not copy over the skel .zshrc, right? Unless the rpm checks to see if each user has a ~/.zshrc, this may be a problem. This is why I thought sourcing /etc/profile should be done in /etc/z*, but I suppose that doesn't give the user a choice to not source /etc/profile. I installed zsh after my root and eric users. Does the fedora installer copy over /etc/skel/.zshrc after it adds users? Maybe there is a solution that would allow all of this to work together. -Eric Hattemer From hattenator at imapmail.org Tue Feb 3 08:46:27 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:46:27 -0800 Subject: release candidate zsh configs In-Reply-To: References: <401A28E6.3010403@imapmail.org> Message-ID: <401F5FE3.3020909@imapmail.org> >Thanks. :) > >Actually it would be good if you could put this rfe into >bugzilla. That way I won't forgot about it: though I hope >to take a look at it before too long, it would be very good >to have a record of the changes there. > I will file it two days from now. Sorry that I don't have time at the moment. > > EH> I would like to remove /etc/skel/.zshrc > EH> because it is not expected that someone will install > EH> zsh before adding users. All it does is source > EH> /etc/profile, which I moved into /etc/zshrc. > >Well, no there is a reason for that, see: > . > There is some good discussion there, but I am considering reopening that bug to get some more ideas about the situation. I suppose the situation is that redhat wants to give people the ability not to source in bash /etc/bashrc, or /etc/profile, and allow them to not source in zsh /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc can allow them to decide on whether to source the /etc/profile. But the reason bash can get away with putting things in skel is that its automatically installed before adduser root, right? zsh is likely to be added after users are added, and therefore would not copy over the skel .zshrc, right? Unless the rpm checks to see if each user has a ~/.zshrc, this may be a problem. This is why I thought sourcing /etc/profile should be done in /etc/z*, but I suppose that doesn't give the user a choice to not source /etc/profile. I installed zsh after my root and eric users. Does the fedora installer copy over /etc/skel/.zshrc after it adds users? Maybe there is a solution that would allow all of this to work together. -Eric Hattemer From hattenator at imapmail.org Tue Feb 3 08:46:57 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:46:57 -0800 Subject: release candidate zsh configs In-Reply-To: References: <401A28E6.3010403@imapmail.org> Message-ID: <401F6001.5000408@imapmail.org> >Thanks. :) > >Actually it would be good if you could put this rfe into >bugzilla. That way I won't forgot about it: though I hope >to take a look at it before too long, it would be very good >to have a record of the changes there. > I will file it two days from now. Sorry that I don't have time at the moment. > > EH> I would like to remove /etc/skel/.zshrc > EH> because it is not expected that someone will install > EH> zsh before adding users. All it does is source > EH> /etc/profile, which I moved into /etc/zshrc. > >Well, no there is a reason for that, see: > . > There is some good discussion there, but I am considering reopening that bug to get some more ideas about the situation. I suppose the situation is that redhat wants to give people the ability not to source in bash /etc/bashrc, or /etc/profile, and allow them to not source in zsh /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc can allow them to decide on whether to source the /etc/profile. But the reason bash can get away with putting things in skel is that its automatically installed before adduser root, right? zsh is likely to be added after users are added, and therefore would not copy over the skel .zshrc, right? Unless the rpm checks to see if each user has a ~/.zshrc, this may be a problem. This is why I thought sourcing /etc/profile should be done in /etc/z*, but I suppose that doesn't give the user a choice to not source /etc/profile. I installed zsh after my root and eric users. Does the fedora installer copy over /etc/skel/.zshrc after it adds users? Maybe there is a solution that would allow all of this to work together. -Eric Hattemer From hattenator at imapmail.org Tue Feb 3 08:47:39 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:47:39 -0800 Subject: release candidate zsh configs In-Reply-To: References: <401A28E6.3010403@imapmail.org> Message-ID: <401F602B.2020301@imapmail.org> >Thanks. :) > >Actually it would be good if you could put this rfe into >bugzilla. That way I won't forgot about it: though I hope >to take a look at it before too long, it would be very good >to have a record of the changes there. > I will file it two days from now. Sorry that I don't have time at the moment. > > EH> I would like to remove /etc/skel/.zshrc > EH> because it is not expected that someone will install > EH> zsh before adding users. All it does is source > EH> /etc/profile, which I moved into /etc/zshrc. > >Well, no there is a reason for that, see: > . > There is some good discussion there, but I am considering reopening that bug to get some more ideas about the situation. I suppose the situation is that redhat wants to give people the ability not to source in bash /etc/bashrc, or /etc/profile, and allow them to not source in zsh /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc can allow them to decide on whether to source the /etc/profile. But the reason bash can get away with putting things in skel is that its automatically installed before adduser root, right? zsh is likely to be added after users are added, and therefore would not copy over the skel .zshrc, right? Unless the rpm checks to see if each user has a ~/.zshrc, this may be a problem. This is why I thought sourcing /etc/profile should be done in /etc/z*, but I suppose that doesn't give the user a choice to not source /etc/profile. I installed zsh after my root and eric users. Does the fedora installer copy over /etc/skel/.zshrc after it adds users? Maybe there is a solution that would allow all of this to work together. -Eric Hattemer From hattenator at imapmail.org Tue Feb 3 08:49:30 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 03 Feb 2004 00:49:30 -0800 Subject: release candidate zsh configs In-Reply-To: <401F602B.2020301@imapmail.org> References: <401A28E6.3010403@imapmail.org> <401F602B.2020301@imapmail.org> Message-ID: <401F609A.2050709@imapmail.org> sorry everyone, my smtp server was broken. This will never happen again. -Eric Hattemer From salimma at fastmail.fm Tue Feb 3 08:55:13 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 15:55:13 +0700 Subject: HD spinning is making the computer freeze In-Reply-To: References: <1075729586.29974.26.camel@forbidden.cipanb.ca> Message-ID: <1075798513.5047.50.camel@localhost.localdomain> On Tue, 2004-02-03 at 03:14 -0500, Mike A. Harris wrote: [snip] > The longer answer is: Download a copy of "xrestop", findable > with google, and use it to find the broken applications which are > leaking pixmaps or other X resources. > > More of a fedora-list question than a development related one > though. > The development related question is, should xrestop be included in Fedora? - 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 salimma at fastmail.fm Tue Feb 3 09:07:40 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 16:07:40 +0700 Subject: Corporate pressure In-Reply-To: References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> <20040202182320.GG30711@thyrsus.com> <1075784265.5047.10.camel@localhost.localdomain> Message-ID: <1075799259.13524.3.camel@localhost.localdomain> On Tue, 2004-02-03 at 03:12 -0500, Mike A. Harris wrote: > For some, it's "personal satisfaction", for others it might be > "scratch an itch", or "fame", or some other motivation. For a > complete list, buy Eric's book and read it. One of the things > notably missing from the list of "motivating factors for > volunteers to do stuff for free" is "rude people making obnoxious > demands". > > That particular item is on the "ways to get someone to never > listen to you again, and purposefully do the opposite of what > you want" list. > Precisely why I was trying to show that there are people who appreciate what Eric offered to do, and hope that while it could not erase the damage of that insult, at least mitigates its effect a bit. I wonder what's happening with Fedora-devel. Not only do we get newbies nowadays asking configuration questions, we also get Slashdot/Usenet- style flame wars... - 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 behdad at cs.toronto.edu Tue Feb 3 09:07:45 2004 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 3 Feb 2004 04:07:45 -0500 Subject: HD spinning is making the computer freeze In-Reply-To: <1075798513.5047.50.camel@localhost.localdomain> References: <1075729586.29974.26.camel@forbidden.cipanb.ca> <1075798513.5047.50.camel@localhost.localdomain> Message-ID: On Tue, 3 Feb 2004, Michel Alexandre Salim wrote: > On Tue, 2004-02-03 at 03:14 -0500, Mike A. Harris wrote: > [snip] > > The longer answer is: Download a copy of "xrestop", findable > > with google, and use it to find the broken applications which are > > leaking pixmaps or other X resources. > > > > More of a fedora-list question than a development related one > > though. > > > The development related question is, should xrestop be included in > Fedora? IIRC Havoc has patched GNOME System Monitor to show X memory usage per process too. So should come in with GNOME 2.6. behdad > - Michel From salimma at fastmail.fm Tue Feb 3 09:10:09 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 16:10:09 +0700 Subject: Nautilus toolbars In-Reply-To: <1075733327.13051.1.camel@support02.civic.twp.ypsilanti.mi.us> References: <1075733327.13051.1.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1075799409.13524.6.camel@localhost.localdomain> On Mon, 2004-02-02 at 09:48 -0500, Sean Middleditch wrote: > Do note that middle-clicking on a folder will close the current window > when opening the new. > Yes, but unfortunately it is done by closing the current window, then opening a new window somewhere else, which could be... rather distracting. - 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 pmatilai at welho.com Tue Feb 3 09:12:16 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 3 Feb 2004 11:12:16 +0200 (EET) Subject: Corporate pressure In-Reply-To: <1075799259.13524.3.camel@localhost.localdomain> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> <20040202182320.GG30711@thyrsus.com> <1075784265.5047.10.camel@localhost.localdomain> <1075799259.13524.3.camel@localhost.localdomain> Message-ID: On Tue, 3 Feb 2004, Michel Alexandre Salim wrote: > On Tue, 2004-02-03 at 03:12 -0500, Mike A. Harris wrote: > > > For some, it's "personal satisfaction", for others it might be > > "scratch an itch", or "fame", or some other motivation. For a > > complete list, buy Eric's book and read it. One of the things > > notably missing from the list of "motivating factors for > > volunteers to do stuff for free" is "rude people making obnoxious > > demands". > > > > That particular item is on the "ways to get someone to never > > listen to you again, and purposefully do the opposite of what > > you want" list. > > > Precisely why I was trying to show that there are people who appreciate > what Eric offered to do, and hope that while it could not erase the > damage of that insult, at least mitigates its effect a bit. > > I wonder what's happening with Fedora-devel. Not only do we get newbies > nowadays asking configuration questions, we also get Slashdot/Usenet- > style flame wars... If you think the flamewars on fedora-devel are bad, go look at debian-devel someday :) - Panu - From behdad at cs.toronto.edu Tue Feb 3 09:11:35 2004 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 3 Feb 2004 04:11:35 -0500 Subject: Corporate pressure In-Reply-To: <1075799259.13524.3.camel@localhost.localdomain> References: <401E480E.1060307@home.se> <20040202174350.GA30711@thyrsus.com> <1075745714.4434.1.camel@ip68-12-228-23.ok.ok.cox.net> <20040202182320.GG30711@thyrsus.com> <1075784265.5047.10.camel@localhost.localdomain> <1075799259.13524.3.camel@localhost.localdomain> Message-ID: On Tue, 3 Feb 2004, Michel Alexandre Salim wrote: > On Tue, 2004-02-03 at 03:12 -0500, Mike A. Harris wrote: > > > For some, it's "personal satisfaction", for others it might be > > "scratch an itch", or "fame", or some other motivation. For a > > complete list, buy Eric's book and read it. One of the things > > notably missing from the list of "motivating factors for > > volunteers to do stuff for free" is "rude people making obnoxious > > demands". > > > > That particular item is on the "ways to get someone to never > > listen to you again, and purposefully do the opposite of what > > you want" list. > > > Precisely why I was trying to show that there are people who appreciate > what Eric offered to do, and hope that while it could not erase the > damage of that insult, at least mitigates its effect a bit. > > I wonder what's happening with Fedora-devel. Not only do we get newbies > nowadays asking configuration questions, we also get Slashdot/Usenet- > style flame wars... May it be that fedoranews.org sends newbies this way? > - Michel From salimma at fastmail.fm Tue Feb 3 09:19:30 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 16:19:30 +0700 Subject: sylpheed (and inclusions) In-Reply-To: <1075372492.15868.21.camel@angua.localnet> References: <20040123215240.GD4918@devserv.devel.redhat.com> <20040123230934.625c1105.ms-nospam-0306@arcor.de> <20040128083209.GA23316@devserv.devel.redhat.com> <20040128212152.75b2e8b7.pros-n-cons@bak.rr.com> <1075372492.15868.21.camel@angua.localnet> Message-ID: <1075799969.13524.12.camel@localhost.localdomain> On Thu, 2004-01-29 at 10:34 +0000, Nigel Metheringham wrote: > Evo is nice and snappy for me. However that probably depends on what > you use for your mail store - if mbox is the answer than it was a damn > stupid question. > That could pose a problem for test1, as Evo 1.5.3 uses mbox by default and does not seem to offer a way to create maildirs. - 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 salimma at fastmail.fm Tue Feb 3 09:29:31 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 16:29:31 +0700 Subject: HD spinning is making the computer freeze In-Reply-To: References: <1075729586.29974.26.camel@forbidden.cipanb.ca> <1075798513.5047.50.camel@localhost.localdomain> Message-ID: <1075800570.13524.16.camel@localhost.localdomain> On Tue, 2004-02-03 at 04:07 -0500, Behdad Esfahbod wrote: > IIRC Havoc has patched GNOME System Monitor to show X memory > usage per process too. So should come in with GNOME 2.6. Just checked it out ... it currently shows 0 byte X memory usage for all tasks. Time for a visit to Bugzilla.. Having a backup command-line tool would be useful too. Not everyone runs GNOME. - 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 pauln at truemesh.com Tue Feb 3 09:26:12 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 3 Feb 2004 09:26:12 +0000 Subject: Synaptics driver in Fedora In-Reply-To: References: <401F4876.7060200@redhat.com> Message-ID: <20040203092611.GX20512@ensim.rackshack.net> On Tue, Feb 03, 2004 at 03:26:20AM -0500, Mike A. Harris wrote: > On Mon, 2 Feb 2004, Warren Togami wrote: > > >Mike Harris said that he would integrate the Synaptics touchpad driver > >into the Fedora RPM if somebody does the necessary work to integrate it I was going to mail about this this morning anyway. > >cleanly, test, and submit the patches. It is an extremely low priority > >for him so it is highly unlikely that it wont happen unless somebody > >does this necessary work. OK there are some other things which I'll list at the bottom here > The synaptics package wont compile with the XFree86-SDK. Paul > Nasrat has worked on this but never sent me a patch that cleanly > applies to the current Fedora rpm, and cleanly compiles. (the > last patch applied but didn't compile). Apologies once more. OK you need to drop the patches currently in the spec: 9133/9134 I'm going to spend time on SDK for 4.4 and HEAD but https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99351#c35 I will resync with rawhide src.rpm now and I'll ensure the patch that has gone into HEAD will 1) Cleanly apply 2) Cleanly compile (apologies for braindead typo). > I might also then add the synaptics package also, but that's > something I'd need to review first before commiting to it. Indeed. Other things that need to be done for fc2 test2 timescale *if* synaptics gets in: 1) autoload evdev 2) generate appropriate config Other solution is to ensure that the mouse driver only probes up to imps. My bandwidth out of work is limited atm and will be so for at least two weeks - so I'll try and co-ordinate. Paul From rms at 1407.org Tue Feb 3 09:31:33 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 03 Feb 2004 09:31:33 +0000 Subject: Synaptics driver in Fedora In-Reply-To: References: <401F4876.7060200@redhat.com> Message-ID: <1075800693.3227.75.camel@roque> On Tue, 2004-02-03 at 08:26, Mike A. Harris wrote: > The synaptics package wont compile with the XFree86-SDK. Paul > Nasrat has worked on this but never sent me a patch that cleanly > applies to the current Fedora rpm, and cleanly compiles. (the > last patch applied but didn't compile). > > It's not a priority to me, so I haven't looked into fixing it, > however if Paul or someone else wants to fix it and send me via > bugzilla, the proper patch that allows the synaptics rpm to > compile using the XFree86-SDK, having *tested* the patch with > XFree86 src.rpm first, and compiled the synaptics driver against > it, I'd be glad to add it to FC2. But it _is_ a priority for me. FC2 will be quite a pain to use if that driver isn't working. I suspect many laptops will suffer from the same problem. I hope to be able to try merging this patch this weekend. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Tue Feb 3 09:40:07 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Feb 2004 23:40:07 -1000 Subject: gdm XDMCP and file descriptor fixing Message-ID: <401F6C77.6090607@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110315 GDM miscounts current sessions I was looking at this problem for a while, and yesterday copied George Lebl's solution in gdm-2.5.90.0 of recounting. I did not test it fully, but it also seems to avoid the file descriptor leak described in this below bug. This patch is a bit of a hack and inefficient, but copied it anyway since it seems to work and it was from upstream. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113154 GDM leaking file descriptors The link to GNOME bugzilla indicates a similar problem to #110315 above. Then today Bart Martens posted a much simpler patch that should fix both the file descriptor and XDMCP session counter issue. I did not yet test this patch. Please help me to verify which patch is more correct. Warren Togami wtogami at redhat.com From rms at 1407.org Tue Feb 3 09:39:09 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 03 Feb 2004 09:39:09 +0000 Subject: Synaptics driver in Fedora In-Reply-To: <1075800693.3227.75.camel@roque> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> Message-ID: <1075801149.3227.80.camel@roque> On Tue, 2004-02-03 at 09:31, Rui Miguel Seabra wrote: > On Tue, 2004-02-03 at 08:26, Mike A. Harris wrote: > > The synaptics package wont compile with the XFree86-SDK. Paul > > Nasrat has worked on this but never sent me a patch that cleanly > > applies to the current Fedora rpm, and cleanly compiles. (the > > last patch applied but didn't compile). > > > > It's not a priority to me, so I haven't looked into fixing it, > > however if Paul or someone else wants to fix it and send me via > > bugzilla, the proper patch that allows the synaptics rpm to > > compile using the XFree86-SDK, having *tested* the patch with > > XFree86 src.rpm first, and compiled the synaptics driver against > > it, I'd be glad to add it to FC2. > > But it _is_ a priority for me. FC2 will be quite a pain to use if that > driver isn't working. I suspect many laptops will suffer from the same > problem. I actually tried upgrading to rawhide's Linux 2.6.1 because I miss software suspend terribly (I have none ATM because this laptop only does ACPI and swsusp is really hard to merge with FC's 2.4.22), but as soon as I upgraded XFree86 (hoping it had the synaptics updated driver) I had to roll back to FC1's Linux since the mouse was very close to unusable. Hugs, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pauln at truemesh.com Tue Feb 3 09:39:48 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 3 Feb 2004 09:39:48 +0000 Subject: Synaptics driver in Fedora In-Reply-To: <1075800693.3227.75.camel@roque> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> Message-ID: <20040203093947.GY20512@ensim.rackshack.net> On Tue, Feb 03, 2004 at 09:31:33AM +0000, Rui Miguel Seabra wrote: > On Tue, 2004-02-03 at 08:26, Mike A. Harris wrote: > > The synaptics package wont compile with the XFree86-SDK. Paul > But it _is_ a priority for me. FC2 will be quite a pain to use if that > driver isn't working. I suspect many laptops will suffer from the same > problem. The driver does work using imps IIRC, the additional driver provides extra functionality based on the new input layer and evdev. See: http://w1.894.telia.com/~u89404340/touchpad/ Worst case is tap only support with imps using psmouse.proto Input FAQ here http://lwn.net/Articles/69107/ > I hope to be able to try merging this patch this weekend. I think it's best to co-ordinate efforts - particularly as I'm fairly comfortable with what has to be done - but have LifeStuff(TM) and bandwidth issues atm. I'm around between 09:30-18:00 UTC on #fedora-devel as nasrat - feel free to ping me. We can hammer out some stuff and then report back to list. Cheers Paul From twaugh at redhat.com Tue Feb 3 09:49:53 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 3 Feb 2004 09:49:53 +0000 Subject: gettext vs automake In-Reply-To: References: <20040129155641.GL28127@redhat.com> <1075408058.6108.24.camel@localhost.localdomain> <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> <20040202094147.GE25654@redhat.com> Message-ID: <20040203094953.GK25654@redhat.com> On Tue, Feb 03, 2004 at 04:30:15PM +0900, Jens Petersen wrote: > Apart from the mkinstalldirs issue, are there other problems > with glib-gettext.m4 and Automake 1.8? I don't know of any. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rms at 1407.org Tue Feb 3 09:51:05 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 03 Feb 2004 09:51:05 +0000 Subject: Synaptics driver in Fedora In-Reply-To: <20040203093947.GY20512@ensim.rackshack.net> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> <20040203093947.GY20512@ensim.rackshack.net> Message-ID: <1075801865.3227.88.camel@roque> On Tue, 2004-02-03 at 09:39, Paul Nasrat wrote: > On Tue, Feb 03, 2004 at 09:31:33AM +0000, Rui Miguel Seabra wrote: > > On Tue, 2004-02-03 at 08:26, Mike A. Harris wrote: > > > The synaptics package wont compile with the XFree86-SDK. Paul > > > But it _is_ a priority for me. FC2 will be quite a pain to use if that > > driver isn't working. I suspect many laptops will suffer from the same > > problem. > > The driver does work using imps IIRC, the additional driver provides extra > functionality based on the new input layer and evdev. See: Ok, I will see what I can get from those pointers, thanks. > > I hope to be able to try merging this patch this weekend. > I think it's best to co-ordinate efforts - particularly as I'm fairly > comfortable with what has to be done - but have LifeStuff(TM) and bandwidth > issues atm. > I'm around between 09:30-18:00 UTC on #fedora-devel as nasrat - feel free to > ping me. I'm not too comfortable, but I need it working and I have a "slow" weekend at the mountains, so I could take the laptop and try to work on it. > We can hammer out some stuff and then report back to list. I will try to be at #fedora-devel but I'm not sure if I can make it, I've got a bad deadline at my job right now. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From julo at altern.org Tue Feb 3 10:28:10 2004 From: julo at altern.org (Julien Olivier) Date: Tue, 03 Feb 2004 10:28:10 +0000 Subject: mplayer vs. xine In-Reply-To: <20040202180938.641bff34@python.freshrpms.net> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040202180938.641bff34@python.freshrpms.net> Message-ID: <1075804089.4878.12.camel@localhost.localdomain> > (X)MAME can't really be considered free, as there are some limitations as > to how it or any derivative work can be (re)distributed. Basically, you > can't charge for MAME in any shape or form. This is mainly to avoid having > companies selling some kind of "arcade game console" which would be running > MAME. Please check out the full license at http://www.mame.net/ for more > precise information. You're right. From the FAQ, it says that's it's free to re-distribute but that you can't sell it. That said, I think it's free _enough_ to have it in anvil's repository. -- Julien Olivier From laroche at redhat.com Tue Feb 3 10:34:58 2004 From: laroche at redhat.com (Florian La Roche) Date: Tue, 3 Feb 2004 11:34:58 +0100 Subject: Synaptics driver in Fedora In-Reply-To: <1075800693.3227.75.camel@roque> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> Message-ID: <20040203103458.GB12684@dudweiler.stuttgart.redhat.com> > But it _is_ a priority for me. FC2 will be quite a pain to use if that > driver isn't working. I suspect many laptops will suffer from the same > problem. I heard this is one of the main reasons some people still haven't updated to the current development release and/or a 2.6 kernel. greetings, Florian La Roche From pros-n-cons at bak.rr.com Tue Feb 3 10:44:36 2004 From: pros-n-cons at bak.rr.com (Vincent) Date: Tue, 3 Feb 2004 02:44:36 -0800 Subject: Pentium 4 In-Reply-To: <401EFBA7.1000408@uni-bielefeld.de> References: <401EFBA7.1000408@uni-bielefeld.de> Message-ID: <20040203024436.0f2dc483.pros-n-cons@bak.rr.com> On Tue, 03 Feb 2004 02:38:47 +0100 Gerhard Prade wrote: > Hello, > > i am not a developer, but have a question. I tried last time > Gentoo-Linux and i think it is great to optimize a hole distribution of > linux for a CPU-Achitcture (like Pentium 4 and not only for 386). > But Gentoo is for me not easy to use. So i want to use in future fedora, > like i do now. > Now my question. It is posible to optimize one of the next releases of > fedora for 686 CPU or greater like Pentium 4? > > Thanks all, Gerhard > > PS: Sorry for my bad english. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list This has been discussed several times, A quick search pulls up: https://listman.redhat.com/archives/shrike-list/2003-June/msg00686.html In short it says the benifit is slight or unnoticable with the exception of a few packages. kernel, glibc and SSL. If it is that big of a deal to you options can be set in ~/.rpmrc and you can rebuild those 1 or two packages yourself with little problem. From alan at redhat.com Tue Feb 3 11:11:56 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Feb 2004 06:11:56 -0500 Subject: Pentium 4 In-Reply-To: <401EFBA7.1000408@uni-bielefeld.de> References: <401EFBA7.1000408@uni-bielefeld.de> Message-ID: <20040203111156.GB32001@devserv.devel.redhat.com> On Tue, Feb 03, 2004 at 02:38:47AM +0100, Gerhard Prade wrote: > Now my question. It is posible to optimize one of the next releases of > fedora for 686 CPU or greater like Pentium 4? It wouldn't run on other systems if the full optimisations were used. Gentoo can do this as each user compiles the code and ends up with binaries for their own CPU/setup that hopefully work. Fedora does ship 686 optimised kernel, glibc and openssl, that seems to be the key bits it helps. You can however rebuild any rpm source package with other options (eg -Os for size optimisation or CPU specific optimisations) From alan at redhat.com Tue Feb 3 11:16:28 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Feb 2004 06:16:28 -0500 Subject: Pentium 4 In-Reply-To: <200402031414.05224.russell@coker.com.au> References: <401EFBA7.1000408@uni-bielefeld.de> <200402031414.05224.russell@coker.com.au> Message-ID: <20040203111628.GC32001@devserv.devel.redhat.com> On Tue, Feb 03, 2004 at 02:14:05PM +1100, Russell Coker wrote: > KDE performs poorly when large amounts of text are in a window, EG when kmail > displays a message with a few megs of text. I've seen the same operations > run faster on other GUI software on 386 machines than kmail runs on P3 > machines! This is an X server problem in part. You also need to be sure to compare what the apps are doing - there is a cost to rendering antialiased text for zillions of languages for example. If you switch your X server to unaccelerated and turn on shadowfb your fonts probably go a lot quicker at the moment btw. (Software render implementation has some design issues, XFree86 DDX lacks DMA 'get rectangle', and most servers still lack hardware render acceleration) > Maybe we should create a list of programs who's performance is an issue for > Fedora so that interested people can start investigating them? Like "why does glibc's internationalisation post install script use 120Mb ?" I think that is my favourite right now. From alan at redhat.com Tue Feb 3 11:31:33 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Feb 2004 06:31:33 -0500 Subject: User Linux In-Reply-To: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> References: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> Message-ID: <20040203113133.GD32001@devserv.devel.redhat.com> On Tue, Feb 03, 2004 at 01:36:56PM +0900, Naoki wrote: > http://userlinux.com/cgi-bin/wiki.pl?White_Paper > > What do you guys think? Especially about the "RedHat's Proposal" > section? When we kicked Fedora around early on one question was "should we just work with Debian". We decided not to because the users of Fedora wanted regularly releases and leading edge code. Also because a lot of them wanted something leading the project they trusted. There are still some things that have taken far too long to get sorted I'll freely admit - like the external CVS. As to unequal partnerships well 1. Last time I checked RH employees got told to do things like fix packages they hate and turn up in the office, or actually do work. Fedora.us contributors don't seem to. So I fail to see the connection. 2. Anyone who likes Fedora and doesn't like the control of it can simply create a copy of it with a new name and go do their own thing. Same with RHEL - white box linux for example. The free software licenses grant that not some magic Debian or other property. We didn't set out to achieve what Debian has, we set out to build something cool, current and with regular releases. Something that was at its heart like the old Red Hat releases with regular updates, and people making CD's as they wanted. Our first release was on time and up to date, which illustrates two reasons why using Debian wouldn't have achieved the Fedora goals. UserLinux might well be a useful project, its just unfortunate that Bruce has no better ways to attempt to raise interest than to rubbish unrelated projects. Alan From norm at turing.une.edu.au Tue Feb 3 11:37:36 2004 From: norm at turing.une.edu.au (Norman Gaywood) Date: Tue, 3 Feb 2004 22:37:36 +1100 Subject: SMP kernel lockups Message-ID: <20040203113736.GA3971@turing.une.edu.au> I'm wondering if there is any progress on the smp kernel hangs reported in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109962 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109497 Is anyone working on these? Or should I just downgrade to the RH9 kernel and wait for 2.6 in FC2? Anything I can do to help? I've got 4 types of systems I can lock up on demand. Need sysrq output? Patches tried? -- Norman Gaywood, Systems Administrator School of Mathematics, Statistics and Computer Science University of New England, Armidale, NSW 2351, Australia norm at turing.une.edu.au Phone: +61 (0)2 6773 2412 http://turing.une.edu.au/~norm Fax: +61 (0)2 6773 3312 Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From rezso at rdsor.ro Tue Feb 3 11:44:01 2004 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 3 Feb 2004 13:44:01 +0200 Subject: dot allowed adduser/useradd Message-ID: <200402031344.01563.rezso@rdsor.ro> Hi ! I already digged maillist, i understand why cannot be dot in the username while i "adduser", my Q is that if there is some workaround or some patch, i really need to allow dot in usernames it is to ugly to modify /etc/pass entry's. I looket too at src.rpms i coud not figure out where to touch, i see no redhatish patch wich remove the dot feauture and in tarball is difficult to find out. Any sugestion ? cristian From mharris at redhat.com Tue Feb 3 11:44:34 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 06:44:34 -0500 (EST) Subject: Synaptics driver in Fedora In-Reply-To: <1075800693.3227.75.camel@roque> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> Message-ID: On Tue, 3 Feb 2004, Rui Miguel Seabra wrote: >> It's not a priority to me, so I haven't looked into fixing it, >> however if Paul or someone else wants to fix it and send me via >> bugzilla, the proper patch that allows the synaptics rpm to >> compile using the XFree86-SDK, having *tested* the patch with >> XFree86 src.rpm first, and compiled the synaptics driver against >> it, I'd be glad to add it to FC2. > >But it _is_ a priority for me. FC2 will be quite a pain to use if that >driver isn't working. I suspect many laptops will suffer from the same >problem. > >I hope to be able to try merging this patch this weekend. To be clear, what I meant was more along the lines of "I have my own high priority tasks on my plate for the forseeable future, and unfortunately this isn't one of them." It doesn't mean it's not worthy, but rather that it is dwarfed by more worthy tasks of higher priority. For perspective, let's classify this as "Super Duper Important High Priority". That said, I have weeks worth of "Ultra Mega Super Duper Extreme High Priority" items. Sorry if I made it sound unimportant, but hope this is clearer. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From esr at snark.thyrsus.com Tue Feb 3 11:44:28 2004 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Tue, 3 Feb 2004 06:44:28 -0500 Subject: groff-1.18 is broken Message-ID: <200402031144.i13BiSdp003173@snark.thyrsus.com> Who do I bug about getting a groff-1.19 RPM dropped in the repository? 1.18 has some odd bug that clips off the top couple of inches of a PIC image. -- >>esr>> From abel at vallinor4.com Tue Feb 3 11:49:16 2004 From: abel at vallinor4.com (Alexander L. Belikoff) Date: Tue, 3 Feb 2004 06:49:16 -0500 Subject: rawhide: install from ISO image segfaults In-Reply-To: <20040202044925.GA17504@devserv.devel.redhat.com> References: <200402012319.47362.abel@vallinor4.com> <20040202044925.GA17504@devserv.devel.redhat.com> Message-ID: <200402030649.16765.abel@vallinor4.com> On Sunday 01 February 2004 23:49, Bill Nottingham wrote: > Alexander L. Belikoff (abel at vallinor4.com) said: > > Got a segfault while trying to install from boot.iso (dated 02/01/04 > > 10:31). I used 'linux askmethod'. The installer crashes after I select > > the language (English) with the message: > > > > install exited abnormally -- received signal 11 > > > > Oh, just checked - this happens when using the default boot method as > > well. > > Do you have an inserted PCMCIA card? Yes. I was trying to install from the net on my laptop. -- Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9 Bloomberg L.P. 424B A86E CD0D 8424 2701 abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key) From abel at vallinor4.com Tue Feb 3 11:53:30 2004 From: abel at vallinor4.com (Alexander L. Belikoff) Date: Tue, 3 Feb 2004 06:53:30 -0500 Subject: strange TCP problems w/ RawHide In-Reply-To: <20040202054840.GA630@angus.ind.WPI.EDU> References: <200402012335.52746.abel@vallinor4.com> <20040202054840.GA630@angus.ind.WPI.EDU> Message-ID: <200402030653.30271.abel@vallinor4.com> On Monday 02 February 2004 00:48, Charles R. Anderson wrote: > On Sun, Feb 01, 2004 at 11:35:52PM -0500, Alexander L. Belikoff wrote: > > I wonder if anyone observed the same weirdness I have. I've installed > > RawHide over FC1 through constant yum'ming. Currently, I'm running kernel > > 2.6.1-1.63. Unfortunately, TCP doesn't seem to work: > > Sounds like ECN. Try: > > echo 0 > /proc/sys/net/ipv4/tcp_ecn It is ECN indeed. Doing the above fixes the problem. Thank you! I would've never figured it out myself (Google is only helpful in this case when you know what you are looking for). Would it be worthwhile to add it to rc.sysinit, given that it is better to get things work by default? -- Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9 Bloomberg L.P. 424B A86E CD0D 8424 2701 abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key) From dhennessy at valista.com Tue Feb 3 11:54:44 2004 From: dhennessy at valista.com (Denis Hennessy) Date: Tue, 03 Feb 2004 11:54:44 +0000 Subject: How to debug crash on laptop with no serial port Message-ID: <401F8C04.6040902@valista.com> I'm trying fedora on an IBM X31 laptop which has no native serial port*. I've tried various kernels including 2.4.22-1.2135.nptl, 2.4.22-1.2149.nptl and 2.6.1-1.53. After running for somewhere between 3 hours and 2 days, the machine will lock up hard. X will freeze and nothing short of a power cycle will get any response. Sometime, the caps lock light will be flashing. The only other wierdness (I'm not sure it's related) is that applications will occasionally exit for no reason. This frequently happens with mozilla although it may be mozilla bug for just because I spend a lot of time using it. When this happened on different computers, I was able to set up a serial console to capture the crash details but I'm at a loss for what to do with this machine. Any ideas? Thanks, Denis * The laptop itself has no serial port but the docking station does. I don't know how the docking station port should appear in linux (I'm pretty sure it's not /dev/ttyS0). [root at lemming root]# lspci 00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 01) 00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 01) 00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 01) 00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev 01) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) 00:1f.1 IDE interface: Intel Corp. 82801DBM Ultra ATA Storage Controller (rev 01) 00:1f.3 SMBus: Intel Corp. 82801DB/DBM SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corp. 82801DB AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY 02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) 02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) 02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02) 02:02.0 Network controller: Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04) 02:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet Controller (rev 81) [root at lemming root]# From buildsys at redhat.com Tue Feb 3 11:58:37 2004 From: buildsys at redhat.com (Build System) Date: Tue, 3 Feb 2004 06:58:37 -0500 Subject: rawhide report: 20040203 changes Message-ID: <200402031158.i13BwbX10962@porkchop.devel.redhat.com> Removed package run Removed package bonobo-conf Updated Packages: anaconda-9.90-5 --------------- * Mon Feb 02 2004 Anaconda team - built new version from CVS * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 control-center-2.5.2-3 ---------------------- * Mon Feb 02 2004 Jonathan Blandford 1:2.5.2-2 - temporary fix to get rid of error dialog. Need to fix properly later fedora-release-1.90-6 --------------------- indexhtml-1.90-1 ---------------- * Mon Feb 02 2004 Bill Nottingham 1.90-1 - FC2 test 1 initscripts-7.46-1 ------------------ * Mon Feb 02 2004 Bill Nottingham 7.46-1 - some more rc.sysinit tweaks and refactoring rpmdb-fedora-1.90-0.20040203 ---------------------------- From alexander.dalloz at uni-bielefeld.de Tue Feb 3 12:13:39 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Tue, 03 Feb 2004 13:13:39 +0100 Subject: Pentium 4 In-Reply-To: <401EFBA7.1000408@uni-bielefeld.de> References: <401EFBA7.1000408@uni-bielefeld.de> Message-ID: <1075810419.5016.282.camel@sirendipity.dogma.lan> Am Di, den 03.02.2004 schrieb Gerhard Prade um 02:38: > Hello, > > i am not a developer, but have a question. I tried last time > Gentoo-Linux and i think it is great to optimize a hole distribution of > linux for a CPU-Achitcture (like Pentium 4 and not only for 386). > But Gentoo is for me not easy to use. So i want to use in future fedora, > like i do now. > Now my question. It is posible to optimize one of the next releases of > fedora for 686 CPU or greater like Pentium 4? > > Thanks all, Gerhard > > PS: Sorry for my bad english. Hi Gerhard! One of the main reasons Gentoo users claim for their system is the performance boost by optimized compilations for their platform. But if you look at the official Gentoo benchmark page - first official attempt to make the subjective user's impression of performance gains countable, other comparison charts are to be found using google - you will see that the most significant improvement comes from prelinking. That is my impression from the data on http://www.gentoo.org/main/en/performance.xml See yourself. The other speed values are on a level where I suspect you will not feel any difference in general. Fedora uses prelinking. Regards Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2149.nptl Sirendipity 13:04:50 up 3 days, 12:05, load average: 0.12, 0.24, 0.20 [ ????? ?'????? - gnothi seauton ] From hobbit at aloss.ukuu.org.uk Tue Feb 3 12:19:34 2004 From: hobbit at aloss.ukuu.org.uk (Telsa Gwynne) Date: Tue, 3 Feb 2004 12:19:34 +0000 Subject: User Linux (quick clarification) In-Reply-To: <20040203113133.GD32001@devserv.devel.redhat.com> References: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> <20040203113133.GD32001@devserv.devel.redhat.com> Message-ID: <20040203121934.GA4498@aloss.ukuu.org.uk> On Tue, Feb 03, 2004 at 06:31:33AM -0500 or thereabouts, Alan Cox wrote: > > As to unequal partnerships well > 1. Last time I checked RH employees got told to do things like fix > packages they hate and turn up in the office, or actually do > work. Fedora.us contributors don't seem to. So I fail to see > the connection. Before anyone thinks he meant "Fedora.us contributors don't actually do work or fix packages", I shall clarify. He meant "don't get told to". (ie they do do stuff, they just don't get told to do this one first or that one now) He would post this himself, but is late for a lecture, so said I should clarify before it looked like he was saying rude things about fedora.us people. Telsa From davej at redhat.com Tue Feb 3 12:38:33 2004 From: davej at redhat.com (Dave Jones) Date: Tue, 03 Feb 2004 12:38:33 +0000 Subject: SMP kernel lockups In-Reply-To: <20040203113736.GA3971@turing.une.edu.au> References: <20040203113736.GA3971@turing.une.edu.au> Message-ID: <1075811913.17690.1.camel@delerium.codemonkey.org.uk> On Tue, 2004-02-03 at 11:37, Norman Gaywood wrote: > I'm wondering if there is any progress on the smp kernel hangs reported > in: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109962 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109497 > > Is anyone working on these? Yes. > Or should I just downgrade to the RH9 kernel and wait for 2.6 in FC2? They are alternatives, but it doesn't get the problem solved. > Anything I can do to help? I've got 4 types of systems I can lock up on > demand. Need sysrq output? Patches tried? At various points in those bugs I've asked for things like sysrq traces, so read the bugs, and if you have something that isn't mentioned in the reports, feel free to add. I don't think I need to see another report of "its spinning on the inode lock" again though. Dave From davej at redhat.com Tue Feb 3 12:39:22 2004 From: davej at redhat.com (Dave Jones) Date: Tue, 03 Feb 2004 12:39:22 +0000 Subject: strange TCP problems w/ RawHide In-Reply-To: <200402030653.30271.abel@vallinor4.com> References: <200402012335.52746.abel@vallinor4.com> <20040202054840.GA630@angus.ind.WPI.EDU> <200402030653.30271.abel@vallinor4.com> Message-ID: <1075811962.17690.3.camel@delerium.codemonkey.org.uk> On Tue, 2004-02-03 at 11:53, Alexander L. Belikoff wrote: > It is ECN indeed. Doing the above fixes the problem. Thank you! I would've > never figured it out myself (Google is only helpful in this case when you > know what you are looking for). > > Would it be worthwhile to add it to rc.sysinit, given that it is better to get > things work by default? You can just add net.ipv4.tcp_ecn = 0 to /etc/sysctl.conf Dave From skvidal at phy.duke.edu Tue Feb 3 12:39:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 03 Feb 2004 07:39:40 -0500 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> Message-ID: <1075811980.5382.17.camel@binkley> > - Do we really want users to download all the src.rpm data each time? Most > users don't do anything with that information so it sucks up bandwidth for > no purpose. Maybe the src.rpm file information should be separated to > different files? the src rpms stuff are more of a . I got a bunch of complaints about yum's src.rpm header.info file being separate from the primary header.info so I figured that might help resolve it. > - Any particular reason for using gzip instead of bzip2? The difference > can be huge, especially for other.xml: Yah - bzip2 isn't everywhere - gzip is. Specifically bzip2 isn't in python 2.2 - you need an external module that's not in fedora core 1. I thought DV had a complaint about bzip2 as well, but I'm not positive of that. -sv From salimma at fastmail.fm Tue Feb 3 12:49:47 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 19:49:47 +0700 Subject: From release notes: Anaconda not ejecting CDROM Message-ID: <1075812587.15275.4.camel@localhost.localdomain> indexhtml-1.90-1 , /usr/share/doc/HTML/index.html has this to say: Note Anaconda currently does not eject CD-ROMs (both when switching from one CD-ROM to another, and when the installation is complete); this will be fixed in a future test release of Fedora Core. How would this pan out with notebook users: Does this mean we can still go to a console and run eject /dev/cdrom or does it mean I have to get ready a long needle to prick the emergency eject button? I can imagine the look on the face of an eager beaver testing an install on a secluded beach when he realized he's stuck with a half-installed system :) - 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 salimma at fastmail.fm Tue Feb 3 12:51:15 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 19:51:15 +0700 Subject: User Linux (quick clarification) In-Reply-To: <20040203121934.GA4498@aloss.ukuu.org.uk> References: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> <20040203113133.GD32001@devserv.devel.redhat.com> <20040203121934.GA4498@aloss.ukuu.org.uk> Message-ID: <1075812674.15275.7.camel@localhost.localdomain> On Tue, 2004-02-03 at 12:19 +0000, Telsa Gwynne wrote: > On Tue, Feb 03, 2004 at 06:31:33AM -0500 or thereabouts, Alan Cox wrote: > > > > As to unequal partnerships well > > 1. Last time I checked RH employees got told to do things like fix > > packages they hate and turn up in the office, or actually do > > work. Fedora.us contributors don't seem to. So I fail to see > > the connection. > > Before anyone thinks he meant "Fedora.us contributors don't actually > do work or fix packages", I shall clarify. > > He meant "don't get told to". (ie they do do stuff, they just don't > get told to do this one first or that one now) > Precisely why I think Fedora is a great idea. More community input but with enough wage earners to fix things that volunteers cannot be bothered to do :) - 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 salimma at fastmail.fm Tue Feb 3 12:53:10 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 03 Feb 2004 19:53:10 +0700 Subject: How to debug crash on laptop with no serial port In-Reply-To: <401F8C04.6040902@valista.com> References: <401F8C04.6040902@valista.com> Message-ID: <1075812790.15275.8.camel@localhost.localdomain> On Tue, 2004-02-03 at 11:54 +0000, Denis Hennessy wrote: > I'm trying fedora on an IBM X31 laptop which has no native serial > port*. I've tried various kernels including 2.4.22-1.2135.nptl, > 2.4.22-1.2149.nptl and 2.6.1-1.53. After running for somewhere between 3 > hours and 2 days, the machine will lock up hard. X will freeze and > nothing short of a power cycle will get any response. Sometime, the caps > lock light will be flashing. > Tried booting with rhgb turned off already, I presume? I had problems with it on my Centrino notebook; haven't tried it with a 2.6 kernel though. - 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 ms-nospam-0306 at arcor.de Tue Feb 3 12:57:56 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 3 Feb 2004 13:57:56 +0100 Subject: Pentium 4 In-Reply-To: <1075810419.5016.282.camel@sirendipity.dogma.lan> References: <401EFBA7.1000408@uni-bielefeld.de> <1075810419.5016.282.camel@sirendipity.dogma.lan> Message-ID: <20040203135756.613d0f54.ms-nospam-0306@arcor.de> On Tue, 03 Feb 2004 13:13:39 +0100, Alexander Dalloz wrote: > One of the main reasons Gentoo users claim for their system is the > performance boost by optimized compilations for their platform. But if > you look at the official Gentoo benchmark page - first official attempt > to make the subjective user's impression of performance gains countable, > other comparison charts are to be found using google - you will see that > the most significant improvement comes from prelinking. That is my > impression from the data on > > http://www.gentoo.org/main/en/performance.xml > > See yourself. The other speed values are on a level where I suspect you > will not feel any difference in general. Fedora uses prelinking. There are Gentoo users who are honest enough to admit that they don't see any noticeable performance increase compared with Fedora Core 1. Some even think that FC1 feels "snappier", and they assume it's due to NPTL and/or kernel patches. -- From pmatilai at welho.com Tue Feb 3 13:03:28 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 3 Feb 2004 15:03:28 +0200 (EET) Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075811980.5382.17.camel@binkley> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> <1075811980.5382.17.camel@binkley> Message-ID: On Tue, 3 Feb 2004, seth vidal wrote: > > - Do we really want users to download all the src.rpm data each time? Most > > users don't do anything with that information so it sucks up bandwidth for > > no purpose. Maybe the src.rpm file information should be separated to > > different files? > > the src rpms stuff are more of a . I got a bunch of complaints > about yum's src.rpm header.info file being separate from the primary > header.info so I figured that might help resolve it. Dunno, nobody ever complained apt having separate files for binary and source indexes :) Not that I personally care about it either, I've enough plenty enough bandwidth and would download the src.rpm stuff anyway. Just a bit of wasted bandwidth for everybody to download those but no big deal. > > - Any particular reason for using gzip instead of bzip2? The difference > > can be huge, especially for other.xml: > > Yah - bzip2 isn't everywhere - gzip is. > Specifically bzip2 isn't in python 2.2 - you need an external module > that's not in fedora core 1. Ok, I thought it might have to do with that. OTOH there's a bz2 python module in python 2.3 which is in FC2, which I think is the "target" for this stuff anyway. - Panu - From ms-nospam-0306 at arcor.de Tue Feb 3 13:16:28 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 3 Feb 2004 14:16:28 +0100 Subject: epic IRC package question Message-ID: <20040203141628.7e0d820d.ms-nospam-0306@arcor.de> Inside the spec file for the "epic" package one can read # wserv is just not very useful rm -f $RPM_BUILD_ROOT/%{_libexecdir}/wserv in the %install section. However, that binary seems to be required by the "/WINDOW create" command, which spits out an error about not being able to exec /usr/libexec/wserv. So, how is above spec file comment to be understood correctly? -- From mharris at redhat.com Tue Feb 3 13:27:06 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 3 Feb 2004 08:27:06 -0500 (EST) Subject: User Linux (quick clarification) In-Reply-To: <1075812674.15275.7.camel@localhost.localdomain> References: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> <20040203113133.GD32001@devserv.devel.redhat.com> <20040203121934.GA4498@aloss.ukuu.org.uk> <1075812674.15275.7.camel@localhost.localdomain> Message-ID: On Tue, 3 Feb 2004, Michel Alexandre Salim wrote: >> > >> > As to unequal partnerships well >> > 1. Last time I checked RH employees got told to do things like fix >> > packages they hate and turn up in the office, or actually do >> > work. Fedora.us contributors don't seem to. So I fail to see >> > the connection. >> >> Before anyone thinks he meant "Fedora.us contributors don't actually >> do work or fix packages", I shall clarify. >> >> He meant "don't get told to". (ie they do do stuff, they just don't >> get told to do this one first or that one now) >> >Precisely why I think Fedora is a great idea. More community input but >with enough wage earners to fix things that volunteers cannot be >bothered to do :) And volunteers to do things wage earners couldn't be bothered to do. A good balance of that is a sure win. ;o) /me looks around for Glide3 volunteers .... ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From hvdkooij at vanderkooij.org Tue Feb 3 13:40:50 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Tue, 3 Feb 2004 14:40:50 +0100 (CET) Subject: mplayer vs. xine In-Reply-To: <401C6BC1.8040600@togami.com> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> Message-ID: <58121.194.151.25.67.1075815650.squirrel@hvdkooij.xs4all.nl> Warren Togami zei: > Eric S. Raymond wrote: >> >> I think libdcvss is already in livna's xine set. Carrying >> flash-plugin would be a good idea, though. > > Redistribution of flash-plugin is completely illegal under Macromedia's > EULA, and also and unneeded since Macromedia has given me special > permission to maintain RPM packages and apt/yum/urpmi repositories for > the plugin. Could you share the YUM info with us? Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From skvidal at phy.duke.edu Tue Feb 3 14:04:22 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 03 Feb 2004 09:04:22 -0500 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> <1075811980.5382.17.camel@binkley> Message-ID: <1075817061.5382.20.camel@binkley> > Dunno, nobody ever complained apt having separate files for binary and > source indexes :) Not that I personally care about it either, I've enough > plenty enough bandwidth and would download the src.rpm stuff > anyway. Just a bit of wasted bandwidth for everybody to download those but > no big deal. What does the difference work out to? Have you compared them? like fc1 with srpms vs w/o. > Ok, I thought it might have to do with that. OTOH there's a bz2 python > module in python 2.3 which is in FC2, which I think is the "target" for > this stuff anyway. but if you're running createrepo on a mirror you won't necessarily have that mirror running fc2 or python 2.3. Hell, I was reaching to think people would have python 2.2, rpm and libxml2 -sv From strange at nsk.no-ip.org Tue Feb 3 14:07:21 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Tue, 3 Feb 2004 14:07:21 +0000 Subject: [A-Z]* oddities In-Reply-To: <20040202214642.GF30700@devserv.devel.redhat.com> References: <20040202181215.GA5411@nsk.no-ip.org> <20040202190422.GA5683@nsk.no-ip.org> <20040202214642.GF30700@devserv.devel.redhat.com> Message-ID: <20040203140721.GA3074@nsk.no-ip.org> On Mon, Feb 02, 2004 at 04:46:42PM -0500, Alan Cox wrote: > utf-8 is a character encoding. It doesn't relate to sort (or more properly > "collation") order. Yes, I've realized that. > > Well, if that's the standard, then it isn't broken... > > The standard depends on the actual language/location. Some sort AaBbCc others > have more complex rules (a b c ch d dd e f ff g ng ...) etc I understand. It's different from what I would choose, but that is a matter of opinion or, most likely, habit. But I still find it odd that in en_GB they would put 'a' before 'A' (aAbB...). Regards, Luciano Rocha From strange at nsk.no-ip.org Tue Feb 3 14:13:07 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Tue, 3 Feb 2004 14:13:07 +0000 Subject: [A-Z]* oddities In-Reply-To: References: <20040202181215.GA5411@nsk.no-ip.org> Message-ID: <20040203141307.GB3074@nsk.no-ip.org> On Tue, Feb 03, 2004 at 03:21:00AM -0500, Mike A. Harris wrote: > My assumption is that you're expecting a specific collation order > such as the legacy "C" or "POSIX" sorting rules, however you're > not using that locale and instead are getting sorting which is > locale dependant? Yes, I've been throughly educated about the wrongness of my setup and my expectations. :) > If so, decide which collation you want, and set LC_COLLATE to > that. For example, in my .bashrc I have: > > # Get rid of UTF-8 performance loss. > export LANG=en_US I like Unicode. > # Sort stuff the sane oldschool UNIX way > export LC_COLLATE=C That ignores accented chars. Oh well, I can't have everything. I'll try to get used to [[:class:]] as Miloslav suggested. Regards, Luciano Rocha From jspaleta at princeton.edu Tue Feb 3 14:15:44 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Tue, 03 Feb 2004 09:15:44 -0500 Subject: what fedora volunteers can do right now [User Linux (quick clarification)] Message-ID: <1075817744.4820.19.camel@spatula.pppl.gov> Mike A. Harris wrote: > And volunteers to do things wage earners couldn't be bothered to > do. A good balance of that is a sure win. ;o) And volunteers do things that wage earners don't necessarily have time to do, or enough time to do well.... like bugzilla triage. Speaking of triage... I'm looking at the FC2 schedule and thinking feb 13's string change deadline is getting a little close. It would be a good idea for volunteers to comb through bugzilla and find bug reports that could have the StringChange keyword: https://bugzilla.redhat.com/bugzilla/describekeywords.cgi StringChange: A string change that would break translations is required to fix this bug. i.e. fix the bug before the string freeze. Basically that means finding bugreports that talk about bugs in user visible text that would need to be retranslated if fixed. Simple typos don't count. More like a change in meaning. If you are interested in helping out marking existing bug reports, follow this recipe for action: 1) search through old bugzilla bug reports, you might even want to search through red hat 8 and 9 reports as well as fedora core reports 2) find a bug number you think could use the StringChange keyword 3) *try to flag me down in #fedora-bugs channel on freenode irc network *or drop a note into the triage mailinglist https://lists.dulug.duke.edu/mailman/listinfo/fedora-triage-list *or write a comment of the form your_irc_nick|triage->stringchange -jef"luckily for me..I do have 28 hour days..."spaleta From toshio at tiki-lounge.com Tue Feb 3 14:31:18 2004 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 03 Feb 2004 09:31:18 -0500 Subject: HD spinning is making the computer freeze In-Reply-To: References: <1075729586.29974.26.camel@forbidden.cipanb.ca> Message-ID: <1075818676.27925.2.camel@Madison.badger.com> On Tue, 2004-02-03 at 03:14, Mike A. Harris wrote: > The longer answer is: Download a copy of "xrestop", findable > with google, and use it to find the broken applications which are > leaking pixmaps or other X resources. I see that Nils Sel?sdal has uploaded xrestop to the fedora.us QA queue. https://bugzilla.fedora.us/show_bug.cgi?id=1255 Thanks Nils! I guess I'll do some QA'ing today. -Toshio -- Toshio From mitr at volny.cz Tue Feb 3 14:34:05 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 3 Feb 2004 15:34:05 +0100 Subject: gettext vs automake In-Reply-To: References: <20040129155641.GL28127@redhat.com> <1075408058.6108.24.camel@localhost.localdomain> <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> <20040202094147.GE25654@redhat.com> Message-ID: <20040203143405.GA14923@popelka.ms.mff.cuni.cz> On Tue, Feb 03, 2004 at 04:30:15PM +0900, Jens Petersen wrote: > Apart from the mkinstalldirs issue, are there other problems > with glib-gettext.m4 and Automake 1.8? I don't know about glib-gettext.m4, but aclocal-1.8 is now very noisy about improperly quoted macros; about a third of cvs.gnome.org from start of January did not build with automake-1.8 for that reason. Mirek From rms at 1407.org Tue Feb 3 14:36:56 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 03 Feb 2004 14:36:56 +0000 Subject: Synaptics driver in Fedora In-Reply-To: References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> Message-ID: <1075819016.3227.101.camel@roque> On Tue, 2004-02-03 at 11:44, Mike A. Harris wrote: > For perspective, let's classify this as "Super Duper Important > High Priority". That said, I have weeks worth of "Ultra Mega > Super Duper Extreme High Priority" items. Oh, but I yell really loud <>, inflate like hell and turn instantly long blond hair :) > Sorry if I made it sound unimportant, but hope this is clearer. I understood it, and still I will do what I can to try to help :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pauln at truemesh.com Tue Feb 3 14:38:41 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 3 Feb 2004 14:38:41 +0000 Subject: Synaptics driver in Fedora In-Reply-To: <1075819016.3227.101.camel@roque> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> <1075819016.3227.101.camel@roque> Message-ID: <20040203143840.GB20512@ensim.rackshack.net> On Tue, Feb 03, 2004 at 02:36:56PM +0000, Rui Miguel Seabra wrote: > On Tue, 2004-02-03 at 11:44, Mike A. Harris wrote: > > Sorry if I made it sound unimportant, but hope this is clearer. > > I understood it, and still I will do what I can to try to help :) FYI I'm building XFree86 with patch rediffed (as the srpm already patches one of the Imakefiles I touch. Further updates as events warrant. Paul From rms at 1407.org Tue Feb 3 14:45:14 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 03 Feb 2004 14:45:14 +0000 Subject: Synaptics driver in Fedora In-Reply-To: <20040203143840.GB20512@ensim.rackshack.net> References: <401F4876.7060200@redhat.com> <1075800693.3227.75.camel@roque> <1075819016.3227.101.camel@roque> <20040203143840.GB20512@ensim.rackshack.net> Message-ID: <1075819514.3227.103.camel@roque> On Tue, 2004-02-03 at 14:38, Paul Nasrat wrote: > FYI I'm building XFree86 with patch rediffed (as the srpm already patches one > of the Imakefiles I touch. I'm sorry for net coming up in IRC yet, but load here is above average :| Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From brugolsky at telemetry-investments.com Tue Feb 3 14:58:39 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 3 Feb 2004 09:58:39 -0500 Subject: How to debug crash on laptop with no serial port In-Reply-To: <401F8C04.6040902@valista.com> References: <401F8C04.6040902@valista.com> Message-ID: <20040203145839.GB22843@ti19.telemetry-investments.com> On Tue, Feb 03, 2004 at 11:54:44AM +0000, Denis Hennessy wrote: > I'm trying fedora on an IBM X31 laptop which has no native serial > port*. I've tried various kernels including 2.4.22-1.2135.nptl, > 2.4.22-1.2149.nptl and 2.6.1-1.53. After running for somewhere between 3 > hours and 2 days, the machine will lock up hard. X will freeze and > nothing short of a power cycle will get any response. Sometime, the caps > lock light will be flashing. If your laptop is generally sitting on a network, you can try netconsole, assuming that the NIC is in the supported list. See this document for info: http://www.redhat.com/support/wpapers/redhat/netdump/ Also note that RHEL3 comes with a crash dump analyzer; you can find the source RPM here: ftp://people.redhat.com/anderson/crash-3.7-5.2.src.rpm Name : crash Relocations: (not relocateable) Version : 3.7 Vendor: Red Hat, Inc. Release : 5.2 Build Date: Fri 09 Jan 2004 09:36:15 AM EST Install Date: (not installed) Build Host: anderson Group : Development/Debuggers Source RPM: (none) Size : 15991483 License: GPL Signature : (none) Packager : Dave Anderson URL : ftp://people.redhat.com/anderson/crash-3.7-5.2.tar.gz Summary : crash utility for live systems and netdump, LKCD or mcore dumpfiles Description : The core analysis suite is a self-contained tool that can be used to investigate either live systems, kernel core dumps created from the netdump package from Red Hat Linux, the mcore kernel patch offered by Mission Critical Linux, or the LKCD kernel patch. Regards, Bill Rugolsky From pmatilai at welho.com Tue Feb 3 15:13:52 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 3 Feb 2004 17:13:52 +0200 (EET) Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075817061.5382.20.camel@binkley> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> <1075811980.5382.17.camel@binkley> <1075817061.5382.20.camel@binkley> Message-ID: On Tue, 3 Feb 2004, seth vidal wrote: > > > Dunno, nobody ever complained apt having separate files for binary and > > source indexes :) Not that I personally care about it either, I've enough > > plenty enough bandwidth and would download the src.rpm stuff > > anyway. Just a bit of wasted bandwidth for everybody to download those but > > no big deal. > > What does the difference work out to? Have you compared them? > > like fc1 with srpms vs w/o. For an RHL 9 based distro: RPMS: 1579532 Feb 3 16:59 filelists.xml.gz 3245800 Feb 3 16:59 other.xml.gz 512172 Feb 3 16:59 primary.xml.gz 666 Feb 3 16:59 repomd.xml SRPMS: 77725 Feb 3 17:00 filelists.xml.gz 1083911 Feb 3 17:00 other.xml.gz 213598 Feb 3 17:00 primary.xml.gz 666 Feb 3 17:00 repomd.xml Whether the SRPMS part is big enough for "junk most users dont need" to matter I don't know. > > > Ok, I thought it might have to do with that. OTOH there's a bz2 python > > module in python 2.3 which is in FC2, which I think is the "target" for > > this stuff anyway. > > but if you're running createrepo on a mirror you won't necessarily have > that mirror running fc2 or python 2.3. > > Hell, I was reaching to think people would have python 2.2, rpm and > libxml2 Oh I know.. having compiled rpm + apt-rpm on a Debian box just to be able to put a repository there :) - Panu - From dhennessy at valista.com Tue Feb 3 15:33:25 2004 From: dhennessy at valista.com (Denis Hennessy) Date: Tue, 03 Feb 2004 15:33:25 +0000 Subject: How to debug crash on laptop with no serial port In-Reply-To: <20040203145839.GB22843@ti19.telemetry-investments.com> References: <401F8C04.6040902@valista.com> <20040203145839.GB22843@ti19.telemetry-investments.com> Message-ID: <401FBF45.7020100@valista.com> That looked promising but when I try to insmod the netconsole module I get this in the log: Feb 3 15:26:58 lemming kernel: netlog: using network device Feb 3 15:26:58 lemming kernel: netlog: eth0's network driver does not implement netlogging yet, aborting. eth0 is a Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet Controller (rev 81) handled by the e100 driver. I guess I could try to find a pcmcia network card that's supported. /dh Bill Rugolsky Jr. wrote: >On Tue, Feb 03, 2004 at 11:54:44AM +0000, Denis Hennessy wrote: > > >>I'm trying fedora on an IBM X31 laptop which has no native serial >>port*. I've tried various kernels including 2.4.22-1.2135.nptl, >>2.4.22-1.2149.nptl and 2.6.1-1.53. After running for somewhere between 3 >>hours and 2 days, the machine will lock up hard. X will freeze and >>nothing short of a power cycle will get any response. Sometime, the caps >>lock light will be flashing. >> >> > >If your laptop is generally sitting on a network, you can try netconsole, >assuming that the NIC is in the supported list. > >See this document for info: > >http://www.redhat.com/support/wpapers/redhat/netdump/ > >Also note that RHEL3 comes with a crash dump analyzer; you can find the >source RPM here: > >ftp://people.redhat.com/anderson/crash-3.7-5.2.src.rpm > >Name : crash Relocations: (not relocateable) >Version : 3.7 Vendor: Red Hat, Inc. >Release : 5.2 Build Date: Fri 09 Jan 2004 09:36:15 AM EST >Install Date: (not installed) Build Host: anderson >Group : Development/Debuggers Source RPM: (none) >Size : 15991483 License: GPL >Signature : (none) >Packager : Dave Anderson >URL : ftp://people.redhat.com/anderson/crash-3.7-5.2.tar.gz >Summary : crash utility for live systems and netdump, LKCD or mcore dumpfiles >Description : >The core analysis suite is a self-contained tool that can be used to >investigate either live systems, kernel core dumps created from the >netdump package from Red Hat Linux, the mcore kernel patch offered by >Mission Critical Linux, or the LKCD kernel patch. > >Regards, > > Bill Rugolsky > > > > From mitr at volny.cz Tue Feb 3 15:40:29 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 3 Feb 2004 16:40:29 +0100 Subject: what fedora volunteers can do right now [User Linux (quick clarification)] In-Reply-To: <1075817744.4820.19.camel@spatula.pppl.gov> References: <1075817744.4820.19.camel@spatula.pppl.gov> Message-ID: <20040203154028.GA23101@popelka.ms.mff.cuni.cz> Hello, a few corrections... On Tue, Feb 03, 2004 at 09:15:44AM -0500, Jef Spaleta wrote: > StringChange: A string change that would break translations is required > to fix this bug. i.e. fix the bug before the string freeze. > Basically that means finding bugreports that talk about bugs in user > visible text that would need to be retranslated if fixed. Simple typos > don't count. Simple typos _do_ count, because the mapping from English to translation is using the exact string. > 1) > search through old bugzilla bug reports, you might even want to search > through red hat 8 and 9 reports as well as fedora core reports Restrict your search only to packages that are translated by the RH/FC translation teams, that is (listing by .src.rpm): anaconda, anaconda-online-help, authconfig, autorun, chkconfig, comps-po, firstboot, hwbrowser, initscripts (and any messages from the /etc/rc.d/init.d/* scripts), kudzu, libuser, redhat-artwork, redhat-menus, rhgb, setuptool, sndconfig, specspo, switchdesk, system-config-*, system-logviewer, system-switch-mail, up2date, usermode Mirek From katzj at redhat.com Tue Feb 3 15:41:11 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 03 Feb 2004 10:41:11 -0500 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> Message-ID: <1075822871.5232.11.camel@edoras.local.net> On Tue, 2004-02-03 at 10:10 +0200, Panu Matilainen wrote: > - Any particular reason for using gzip instead of bzip2? The difference > can be huge, especially for other.xml: The difference in memory usage can be huge too -- bzip's memory footprint is far larger than gzip's and not really worth the compression savings in the vast majority of cases. Cheers, Jeremy From katzj at redhat.com Tue Feb 3 15:51:19 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 03 Feb 2004 10:51:19 -0500 Subject: From release notes: Anaconda not ejecting CDROM In-Reply-To: <1075812587.15275.4.camel@localhost.localdomain> References: <1075812587.15275.4.camel@localhost.localdomain> Message-ID: <1075823479.5232.14.camel@edoras.local.net> On Tue, 2004-02-03 at 19:49 +0700, Michel Alexandre Salim wrote: [snip] > How would this pan out with notebook users: Does this mean we can still > go to a console and run eject /dev/cdrom or does it mean I have to get > ready a long needle to prick the emergency eject button? You should be able to go to a console. Also, the normal (non-emergency) eject button on the CD-ROM drive should work fine as well. Jeremy From brugolsky at telemetry-investments.com Tue Feb 3 16:02:13 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 3 Feb 2004 11:02:13 -0500 Subject: How to debug crash on laptop with no serial port In-Reply-To: <401FBF45.7020100@valista.com> References: <401F8C04.6040902@valista.com> <20040203145839.GB22843@ti19.telemetry-investments.com> <401FBF45.7020100@valista.com> Message-ID: <20040203160213.GC22843@ti19.telemetry-investments.com> On Tue, Feb 03, 2004 at 03:33:25PM +0000, Denis Hennessy wrote: > That looked promising but when I try to insmod the netconsole module I > get this in the log: > > Feb 3 15:26:58 lemming kernel: netlog: using network device > Feb 3 15:26:58 lemming kernel: netlog: eth0's network driver does not > implement netlogging yet, aborting. > > eth0 is a Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet Controller (rev > 81) handled by the e100 driver. I guess I could try to find a pcmcia > network card that's supported. Try the eepro100 driver (which has support in the FC1 kernels) or try the attached patch to the e100 driver (from the RHEL3 kernel SRPM linux-2.4.18-netdump-drivers.patch); it still applies without rejects to 2.4.22-1.2166. Dave, any chance you could toss this into the next FC1 kernel, as the eepro100 driver is deprecated? The other drivers from RHEL3 are already there. Regards, Bill Rugolsky -------------- next part -------------- --- linux-5790/drivers/net/e100/e100_main.c +++ linux-5800/drivers/net/e100/e100_main.c @@ -228,6 +228,9 @@ static void e100_set_bool_option(struct unsigned char e100_wait_exec_cmplx(struct e100_private *, u32, u8, u8); void e100_exec_cmplx(struct e100_private *, u32, u8); +/* for netdump / net console */ +static void e100_netpoll (struct net_device *dev); + /** * e100_get_rx_struct - retrieve cell to hold skb buff from the pool * @bdp: atapter's private data struct @@ -653,6 +656,10 @@ e100_found1(struct pci_dev *pcid, const if (bdp->flags & USE_IPCB) dev->features = NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX; + +#ifdef HAVE_POLL_CONTROLLER + dev->poll_controller = e100_netpoll; +#endif if ((rc = register_netdev(dev)) != 0) { goto err_pci; @@ -4355,3 +4362,19 @@ e100_cu_unknown_state(struct e100_privat } #endif +#ifdef HAVE_POLL_CONTROLLER +/* + * Polling 'interrupt' - used by things like netconsole to send skbs + * without having to re-enable interrupts. It's not called while + * the interrupt routine is executing. + */ + +static void e100_netpoll (struct net_device *dev) +{ + if (!netdump_mode) disable_irq(dev->irq); + e100intr (dev->irq, dev, NULL); + if (!netdump_mode) enable_irq(dev->irq); +} + +#endif + From zaitcev at redhat.com Tue Feb 3 16:20:59 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 3 Feb 2004 08:20:59 -0800 Subject: How to debug crash on laptop with no serial port In-Reply-To: References: Message-ID: <20040203082059.0970a53f.zaitcev@redhat.com> On Tue, 03 Feb 2004 11:54:44 +0000 Denis Hennessy wrote: > I'm trying fedora on an IBM X31 laptop which has no native serial > port*. I've tried various kernels including 2.4.22-1.2135.nptl, > 2.4.22-1.2149.nptl and 2.6.1-1.53. After running for somewhere between 3 > hours and 2 days, the machine will lock up hard. X will freeze and > nothing short of a power cycle will get any response. Sometime, the caps > lock light will be flashing. > The only other wierdness (I'm not sure it's related) is that > applications will occasionally exit for no reason. [...] First I should say I'm not too optimistic about it, because applications dying randomly usually point to a bad SODIMM. So, in the end, it's not likely a console can help a lot. Both 2.4 and 2.6 crashing tells us something too. That said, try to set up Ingo's netconsole. At least you should be able to see the oops when LEDs flash. I do not remember if netconsole is enabled in Fedora. It might need some rebuilding, but this is what I would do. Start here: http://oss.sgi.com/projects/netdev/archive/2001-09/msg00107.html Do not go for USB serial console, it's pretty much useless for cases like this. Good luck, -- Pete From pmatilai at welho.com Tue Feb 3 16:54:15 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 03 Feb 2004 18:54:15 +0200 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075822871.5232.11.camel@edoras.local.net> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> <1075822871.5232.11.camel@edoras.local.net> Message-ID: <1075827254.1328.6.camel@chip.laiskiainen.org> On Tue, 2004-02-03 at 17:41, Jeremy Katz wrote: > On Tue, 2004-02-03 at 10:10 +0200, Panu Matilainen wrote: > > - Any particular reason for using gzip instead of bzip2? The difference > > can be huge, especially for other.xml: > > The difference in memory usage can be huge too -- bzip's memory > footprint is far larger than gzip's and not really worth the compression > savings in the vast majority of cases. Sure bzip2 uses more memory but a box which can comfortably run FC 1 or 2 can afford whatever memory bzip2 uses. Heck my firewall box with 32MB memory has no problems running apt and using bzip2 as package index compression. In embedded space, and ok from installer point of view (since it's you who mentions the memory usage :) things can be different. - Panu - From eharrison at mail.mesd.k12.or.us Tue Feb 3 16:51:25 2004 From: eharrison at mail.mesd.k12.or.us (Eric Harrison) Date: Tue, 03 Feb 2004 08:51:25 -0800 Subject: [K12OSN] gdm XDMCP and file descriptor fixing In-Reply-To: <401F6C77.6090607@redhat.com> References: <401F6C77.6090607@redhat.com> Message-ID: <1075827084.923.327.camel@ltsp.mesd.k12.or.us> On Tue, 2004-02-03 at 01:40, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110315 > GDM miscounts current sessions > I was looking at this problem for a while, and yesterday copied George > Lebl's solution in gdm-2.5.90.0 of recounting. I did not test it fully, > but it also seems to avoid the file descriptor leak described in this > below bug. This patch is a bit of a hack and inefficient, but copied it > anyway since it seems to work and it was from upstream. > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113154 > GDM leaking file descriptors > The link to GNOME bugzilla indicates a similar problem to #110315 above. > Then today Bart Martens posted a much simpler patch that should fix > both the file descriptor and XDMCP session counter issue. I did not yet > test this patch. > > Please help me to verify which patch is more correct. My first test shows that Bart Marten's patch fixed the descriptor leak, but DID NOT fix the session count bug. I see neither the file descriptor leak nor the session count bug with George Lebl's patch. -Eric -------------- 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 Tue Feb 3 17:50:55 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Feb 2004 12:50:55 -0500 Subject: rawhide: install from ISO image segfaults In-Reply-To: <200402030649.16765.abel@vallinor4.com> References: <200402012319.47362.abel@vallinor4.com> <20040202044925.GA17504@devserv.devel.redhat.com> <200402030649.16765.abel@vallinor4.com> Message-ID: <20040203175055.GA24868@devserv.devel.redhat.com> Alexander L. Belikoff (abel at vallinor4.com) said: > > > install exited abnormally -- received signal 11 > > > > > > Oh, just checked - this happens when using the default boot method as > > > well. > > > > Do you have an inserted PCMCIA card? > > Yes. I was trying to install from the net on my laptop. Known bug, no fix yet. Bill From abisain at qualcomm.com Tue Feb 3 18:20:08 2004 From: abisain at qualcomm.com (Abhijeet Bisain) Date: Tue, 03 Feb 2004 10:20:08 -0800 Subject: Possible bug in NPTL in handling pthread_attr Message-ID: <6.0.0.22.2.20040203100931.02153e48@mage.qualcomm.com> Hi, I just installed fedora core 1 and all the updates and am running the kernel 2.4.22-1.2149.nptl. In order to compare context switch times in Linuxthreads vs NPTL, I wrote a small program to create a thread at a certain real time priority by setting the schedpolicy and sched_param in the pthread_attr that I pass to the pthread_create. In the created thread, i check the sched_param to make sure its priority and schedpolicy are set correctly. To my surprise, the policy and priority were both set to 0, even though I had set them to SCHED_FIFO and 20 respectively. Has anyone else seen this? Can somebody please explain if I am doing something wrong? I used LD_ASSUME_KERNEL to switch between linuxthreads and NPTL. Linuxthreads seems to pass this test. Here's the code. This code when compiled prints that the policy and priority are both 0. _____________________________________________________________________________________ #include #include #include #define HI_PRI 20 // // Wrapper function to initialize pthread_attr, set the priority and create a thread // int taskSpawn( int prio, void *(*start_routine)(void *)) { pthread_t spawner_id; pthread_attr_t spawner_attr; struct sched_param spawner_sched_param; if ( pthread_attr_init(&spawner_attr) != 0 ) { perror("attr_init:"); return -1; } if(pthread_attr_setschedpolicy( &spawner_attr, SCHED_RR) != 0) { perror("setschedpolicy:"); return -1; } if(pthread_attr_getschedparam(&spawner_attr, & spawner_sched_param) != 0) { perror("getschedparam:"); return -1; } spawner_sched_param.sched_priority = prio; if(pthread_attr_setschedparam(&spawner_attr, &spawner_sched_param) != 0) { perror("setschedparam "); return -1; } if (pthread_create(&spawner_id, &spawner_attr, start_routine, NULL) != 0) { perror("pthread_create locker"); return -1; } return spawner_id; } // // This is the thread routine which checks the schedparam for the sched policy and priority // void * high(void *tmp) { struct sched_param hisched_param; int policy; if ( pthread_getschedparam(pthread_self(), &policy, &hisched_param) != 0 ) { perror("pthreadschedparamhi:"); return NULL; } printf("Thread's priority = %d, policy = %d\n", hisched_param.sched_priority, policy); } int main() { pthread_t spawner_id; spawner_id = taskSpawn(HI_PRI , high); if( pthread_join(spawner_id, NULL) != 0 ) { perror("pthreadjoin:"); } } ___________________________________________________________________ Thanks, Abhijeet From rich+rhl at lafferty.ca Tue Feb 3 18:27:21 2004 From: rich+rhl at lafferty.ca (Rich Lafferty) Date: Tue, 3 Feb 2004 13:27:21 -0500 Subject: epic IRC package question In-Reply-To: <20040203141628.7e0d820d.ms-nospam-0306@arcor.de> References: <20040203141628.7e0d820d.ms-nospam-0306@arcor.de> Message-ID: <20040203182721.GB952@lafferty.ca> On Tue, Feb 03, 2004 at 02:16:28PM +0100, Michael Schwendt wrote: > Inside the spec file for the "epic" package one can read > > # wserv is just not very useful > rm -f $RPM_BUILD_ROOT/%{_libexecdir}/wserv > > in the %install section. However, that binary seems to be required by the > "/WINDOW create" command, which spits out an error about not being able to > exec /usr/libexec/wserv. > > So, how is above spec file comment to be understood correctly? /window create in X or in screen has always been flaky at best; it's probably understood to be the package author's opinion that it's not very useful, and that people ought to just /window new instead. (That might be my opinion and not the package author's, though. :-) -Rich -- Rich Lafferty --------------+----------------------------------------------- Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html rich at lafferty.ca -----------+----------------------------------------------- From ms-nospam-0306 at arcor.de Tue Feb 3 18:48:58 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 3 Feb 2004 19:48:58 +0100 Subject: epic IRC package question In-Reply-To: <20040203182721.GB952@lafferty.ca> References: <20040203141628.7e0d820d.ms-nospam-0306@arcor.de> <20040203182721.GB952@lafferty.ca> Message-ID: <20040203194858.73836d36.ms-nospam-0306@arcor.de> On Tue, 3 Feb 2004 13:27:21 -0500, Rich Lafferty wrote: > > Inside the spec file for the "epic" package one can read > > > > # wserv is just not very useful > > rm -f $RPM_BUILD_ROOT/%{_libexecdir}/wserv > > > > in the %install section. However, that binary seems to be required by the > > "/WINDOW create" command, which spits out an error about not being able to > > exec /usr/libexec/wserv. > > > > So, how is above spec file comment to be understood correctly? > > /window create in X or in screen has always been flaky at best; it's > probably understood to be the package author's opinion that it's > not very useful, and that people ought to just /window new instead. > > (That might be my opinion and not the package author's, though. :-) "/window new" just splits the main window. "/window create" in xterm opens a separate xterm. Well, it tries to, but fails because wserv is not available. Saying wserv is "not very useful" because maybe it "does not work", that would make a difference in explaining why it isn't included. [...] xterm: Can't execvp /usr/libexec/wserv: No such file or directory *** Opening new window... *** The screen is now dead. child signaled with 0 Errno is 4 *** Cannot create new screen! -- From lowen at pari.edu Tue Feb 3 19:14:45 2004 From: lowen at pari.edu (Lamar Owen) Date: Tue, 3 Feb 2004 14:14:45 -0500 Subject: Corporate pressure In-Reply-To: References: <401E480E.1060307@home.se> <1075799259.13524.3.camel@localhost.localdomain> Message-ID: <200402031414.45712.lowen@pari.edu> On Tuesday 03 February 2004 04:11 am, Behdad Esfahbod wrote: > On Tue, 3 Feb 2004, Michel Alexandre Salim wrote: > > I wonder what's happening with Fedora-devel. Not only do we get newbies > > nowadays asking configuration questions, we also get Slashdot/Usenet- > > style flame wars... > May it be that fedoranews.org sends newbies this way? Most flamewars are not started nor fueled by newbies. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From katzj at redhat.com Tue Feb 3 19:16:35 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 03 Feb 2004 14:16:35 -0500 Subject: meta-repository idea (was Re: mplayer vs. xine) In-Reply-To: <1075827254.1328.6.camel@chip.laiskiainen.org> References: <1075440688.3821.4.camel@oveja.graze.net> <20040130074006.GA24166@thyrsus.com> <1075448551.2343.26.camel@binkley> <20040130082121.GA24569@thyrsus.com> <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <1075561530.4878.4.camel@localhost.localdomain> <20040131152547.GC5507@thyrsus.com> <401C6BC1.8040600@togami.com> <20040201135353.2b243d48.ms-nospam-0306@arcor.de> <1075640439.11711.5.camel@localhost.localdomain> <1075659026.28936.2.camel@chip.laiskiainen.org> <1075664339.24061.6.camel@binkley> <1075665856.28936.14.camel@chip.laiskiainen.org> <1075666535.24061.15.camel@binkley> <1075822871.5232.11.camel@edoras.local.net> <1075827254.1328.6.camel@chip.laiskiainen.org> Message-ID: <1075835795.8620.13.camel@mirkwood.boston.redhat.com> On Tue, 2004-02-03 at 18:54 +0200, Panu Matilainen wrote: > On Tue, 2004-02-03 at 17:41, Jeremy Katz wrote: > > On Tue, 2004-02-03 at 10:10 +0200, Panu Matilainen wrote: > > > - Any particular reason for using gzip instead of bzip2? The difference > > > can be huge, especially for other.xml: > > > > The difference in memory usage can be huge too -- bzip's memory > > footprint is far larger than gzip's and not really worth the compression > > savings in the vast majority of cases. > > Sure bzip2 uses more memory but a box which can comfortably run FC 1 or > 2 can afford whatever memory bzip2 uses. Heck my firewall box with 32MB > memory has no problems running apt and using bzip2 as package index > compression. In embedded space, and ok from installer point of view > (since it's you who mentions the memory usage :) things can be > different. Right, but we want one metadata format to rule them all which means that you want to care about this case. And even if it can be comfortably run, that doesn't mean that you want all of the extra overhead. If it were the case, then we'd all be going with bzip2 payloads in rpm now :-) Jeremy From alan at redhat.com Tue Feb 3 20:00:03 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Feb 2004 15:00:03 -0500 Subject: User Linux (quick clarification) In-Reply-To: References: <1075783015.5104.15.camel@dragon.valuecommerce.ne.jp> <20040203113133.GD32001@devserv.devel.redhat.com> <20040203121934.GA4498@aloss.ukuu.org.uk> <1075812674.15275.7.camel@localhost.localdomain> Message-ID: <20040203200003.GD31748@devserv.devel.redhat.com> On Tue, Feb 03, 2004 at 08:27:06AM -0500, Mike A. Harris wrote: > /me looks around for Glide3 volunteers .... ;o) C preprocessor catastrophe fixed. Could do with some more eyes on how to fix the asm and autoconf From mark at mark.mielke.cc Tue Feb 3 20:30:23 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Tue, 3 Feb 2004 15:30:23 -0500 Subject: rpm persistent WARNING: Multiple same specifications for /var/lib/dhcp(3)?. In-Reply-To: <20040129012817.GA1727@mark.mielke.cc> References: <20040129012817.GA1727@mark.mielke.cc> Message-ID: <20040203203022.GA28260@mark.mielke.cc> It doesn't seem to hurt anything, but somebody should squash this. Example: [root at mark]/part/storage/fedora/devel# rpm -Uvh rpms/initscripts-7.46-1.i386.rpm WARNING: Multiple same specifications for /var/lib/dhcp(3)?. warning: rpms/initscripts-7.46-1.i386.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 Preparing... ########################################### [100%] 1:initscripts ########################################### [100%] I've seen it on every rpm install or upgrade for the last two weeks or os. 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 twaugh at redhat.com Tue Feb 3 21:00:30 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 3 Feb 2004 21:00:30 +0000 Subject: rawhide: install from ISO image segfaults In-Reply-To: <20040203175055.GA24868@devserv.devel.redhat.com> References: <200402012319.47362.abel@vallinor4.com> <20040202044925.GA17504@devserv.devel.redhat.com> <200402030649.16765.abel@vallinor4.com> <20040203175055.GA24868@devserv.devel.redhat.com> Message-ID: <20040203210030.GQ25654@redhat.com> On Tue, Feb 03, 2004 at 12:50:55PM -0500, Bill Nottingham wrote: > > > Do you have an inserted PCMCIA card? > > > > Yes. I was trying to install from the net on my laptop. > > Known bug, no fix yet. FWIW, it's bug #114299. Tim. */ -------------- 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 Tue Feb 3 21:29:02 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 03 Feb 2004 22:29:02 +0100 Subject: Corporate pressure In-Reply-To: <401E480E.1060307@home.se> References: <401E480E.1060307@home.se> Message-ID: <4020129E.8060300@home.se> > What we want, is of course to have certain pieces of software such as > RealPlayer/HelixPlayer and Acrobat Reader are made available in a > sensibly packaged way, accesible via the standard software management > tools. I've talked to some of the Real Inc. developers on IRC, and they expressed their desire to see Helix Player included in the Fedora distribution! The player breaks down into 3 parts: 1. The main player and browser plugin. This is covered by the RPSL (Real Public Source License) and is OSS-approved. This part can be included in Fedora Core/Extras. 2. MP3 playback capabilities. This is freely redistributable as well, but will have to go into livna.org. 3. Real Audio/Video playback codecs. These are under a binary license agreement, and not freely redistributable. However, Real were interested a setting up an arangement with Fedora in order to solve this. Inclusion into the livna repository looks like the best solution to me. A few IRC quotes: <_duncan> in general, we would like very much to have the helix player distributed with fedora <_duncan> if anyone at fedora wants to talk to us, send them to myself or robla (duncanh at real.com, robla at real.com) and we'll be happy to engage with them So, someone at Red Hat should contact robla at real.com (_duncan in #helix, irc.helixcommunity.org) for further investigation. Meanwhile, I'm going to start working on, and submit to QA, a specfile for the package. There are no source tarballs yet, so the source has to be checked out from CVS, a cumbersome procedure tha involves ssh tunneling and an obscure build system written in Python :-). It won't build with the standard RPM_OPT_FLAGS (Real uses -march=pentium -mcpu=pentium) due to missing 386 code in a header: http://www.educ.umu.se/~peter/atomicbase.h (starting at line 521) (I hope I didn't break any law when putting that there...) I have no idea how to fix this, but someone else might. Otherwise, the i386 arch package will have to excluded. /Peter Backlund From kir at darnet.ru Tue Feb 3 23:10:59 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Wed, 04 Feb 2004 02:10:59 +0300 Subject: strange TCP problems w/ RawHide In-Reply-To: <200402030653.30271.abel@vallinor4.com> References: <200402012335.52746.abel@vallinor4.com> <20040202054840.GA630@angus.ind.WPI.EDU> <200402030653.30271.abel@vallinor4.com> Message-ID: <40202A83.9020307@darnet.ru> Alexander L. Belikoff wrote: >It is ECN indeed. Doing the above fixes the problem. Thank you! I would've never figured it out myself (Google is only helpful in this case when you know what you are looking for). > >Would it be worthwhile to add it to rc.sysinit, given that it is better to get things work by default? > This is actually not a linux kernel problem, but the problem with bad/broken router/server TCP/IP stack implementation, which violates RFC793. For more info, see Q/A #2 at http://lkml.org/faq/lkmlfaq-14.html As a side note, I think such questions belongs to fedora-list. From cornette at insight.rr.com Wed Feb 4 03:15:14 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Tue, 03 Feb 2004 22:15:14 -0500 Subject: yelp not on menu ... .xmms directory not created Message-ID: <402063C2.90709@insight.rr.com> When searching the menus for help, I decided to try and run yelp at the command prompt. I got this output in the terminal. Yelp came up and is usable. yelp Use of deprecated SAXv1 function endElement /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input is not pr oper UTF-8, indicate encoding ! Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ /usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 0x6E 0x20 0 x4C Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ I also tried out xmms without a directory and one was not created yet. The error message disappeared from displaying when GNOME is started. (This is good!) When clicking on the menu, it took a little while to move up. (but it works, Great!) This looks like a good start. I hope the CD installations are working and the test1 release gets out soon. I'll use yelp to figure out the rest of my questions. I noticed that it was missing when someone asked about the show-orphans option for rpm. Done, Jim From salimma at fastmail.fm Wed Feb 4 03:50:04 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 04 Feb 2004 10:50:04 +0700 Subject: Corporate pressure In-Reply-To: <4020129E.8060300@home.se> References: <401E480E.1060307@home.se> <4020129E.8060300@home.se> Message-ID: <1075866604.3090.4.camel@localhost.localdomain> On Tue, 2004-02-03 at 22:29 +0100, Peter Backlund wrote: > There are no source tarballs yet, so the source has to be checked out > from CVS, a cumbersome procedure tha involves ssh tunneling and an > obscure build system written in Python :-). It won't build with the > standard RPM_OPT_FLAGS (Real uses -march=pentium -mcpu=pentium) due to > missing 386 code in a header: > No source tarball.. for the source URL just give the tarball name, and above it comment out the instructions on how to get it from CVS? As to RPM_OPT_FLAGS... not too sure if the Fedora.us build system allows for --target, but a simple way to prevent hardcoding -mcpu=pentium - march=pentium is to build with --target i686. That will set both to i686. IIRC Pentium optimization is supposed to actually slow down execution on non-Pentium systems, but I could be wrong. Looking forward to the spec, - 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 felipe_alfaro at linuxmail.org Wed Feb 4 07:20:32 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 04 Feb 2004 08:20:32 +0100 Subject: rpm persistent WARNING: Multiple same specifications for /var/lib/dhcp(3)?. In-Reply-To: <20040203203022.GA28260@mark.mielke.cc> References: <20040129012817.GA1727@mark.mielke.cc> <20040203203022.GA28260@mark.mielke.cc> Message-ID: <1075879231.986.0.camel@teapot.felipe-alfaro.com> On Tue, 2004-02-03 at 21:30, Mark Mielke wrote: > It doesn't seem to hurt anything, but somebody should squash this. > > Example: > > [root at mark]/part/storage/fedora/devel# rpm -Uvh rpms/initscripts-7.46-1.i386.rpm > WARNING: Multiple same specifications for /var/lib/dhcp(3)?. > warning: rpms/initscripts-7.46-1.i386.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 > Preparing... ########################################### [100%] > 1:initscripts ########################################### [100%] > > I've seen it on every rpm install or upgrade for the last two weeks or os. I agree... I filled a bug report some time ago, but haven't seen any activity on it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114394 From petersen at redhat.com Wed Feb 4 07:30:58 2004 From: petersen at redhat.com (Jens Petersen) Date: Wed, 04 Feb 2004 16:30:58 +0900 Subject: gettext vs automake In-Reply-To: <20040203143405.GA14923@popelka.ms.mff.cuni.cz> References: <20040129155641.GL28127@redhat.com> <1075408058.6108.24.camel@localhost.localdomain> <1075685880.1697.21.camel@dhcp-101.brisbane.redhat.com> <20040202094147.GE25654@redhat.com> <20040203143405.GA14923@popelka.ms.mff.cuni.cz> Message-ID: >>>>> "MT" == Miloslav Trmac writes: MT> On Tue, Feb 03, 2004 at 04:30:15PM +0900, Jens Petersen wrote: >> Apart from the mkinstalldirs issue, are there other >> problems with glib-gettext.m4 and Automake 1.8? MT> I don't know about glib-gettext.m4, but aclocal-1.8 MT> is now very noisy about improperly quoted macros; MT> about a third of cvs.gnome.org from start of January MT> did not build with automake-1.8 for that reason. Thank you. That seems enough reason to have automake17 then. :) Cheers, Jens From yusufg at outblaze.com Wed Feb 4 09:32:05 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Wed, 4 Feb 2004 17:32:05 +0800 Subject: Will FC2 move towards mdadm for all software raid config Message-ID: <20040204093205.GE27591@outblaze.com> Considering that 2.6.2 has been released with RAID6 support which is only supported by mdadm, will FC2 use mdadm exclusively and deprecate raidtools In case you are not aware of mdadm http://www.cse.unsw.edu.au/~neilb/source/mdadm/ Regards, Yusuf -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/ From dhennessy at valista.com Wed Feb 4 09:49:06 2004 From: dhennessy at valista.com (Denis Hennessy) Date: Wed, 04 Feb 2004 09:49:06 +0000 Subject: How to debug crash on laptop with no serial port In-Reply-To: <20040203082059.0970a53f.zaitcev@redhat.com> References: <20040203082059.0970a53f.zaitcev@redhat.com> Message-ID: <4020C012.7010209@valista.com> Good call. After running memtest86 overnight, I find that I do have faulty memory (I had replaced the standard IBM memory with 1GB from Crucial). Thanks to all for the help. /dh Pete Zaitcev wrote: > > >First I should say I'm not too optimistic about it, because >applications dying randomly usually point to a bad SODIMM. So, in the >end, it's not likely a console can help a lot. Both 2.4 and 2.6 >crashing tells us something too. > >That said, try to set up Ingo's netconsole. At least you should be >able to see the oops when LEDs flash. I do not remember if netconsole >is enabled in Fedora. It might need some rebuilding, but this is what >I would do. Start here: > http://oss.sgi.com/projects/netdev/archive/2001-09/msg00107.html > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Wed Feb 4 11:40:15 2004 From: buildsys at redhat.com (Build System) Date: Wed, 4 Feb 2004 06:40:15 -0500 Subject: rawhide report: 20040204 changes Message-ID: <200402041140.i14BeFO31899@porkchop.devel.redhat.com> Updated Packages: fedora-release-1.90-10 ---------------------- fedora-release-1.90-9 --------------------- indexhtml-1.90-2 ---------------- pam-0.77-30 ----------- * Mon Feb 02 2004 Dan Walsh 0.77-30 - fix is_selinux_enabled call for pam_rootok rpmdb-fedora-1.90-0.20040204 ---------------------------- From damiano at orange.fr Wed Feb 4 12:07:18 2004 From: damiano at orange.fr (Damiano Albani) Date: Wed, 4 Feb 2004 13:07:18 +0100 Subject: APT-enabled *development* repository Message-ID: Hello, I can't find any APT repository which provides development/RawHide branch for Fedora. I know there's Yum, but, up to me, it's unusable (long downloads for the bunch of tiny headers, triggered every time yum is used, etc). So, do you know one ? Thanks, Damiano From pmatilai at welho.com Wed Feb 4 12:16:28 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 4 Feb 2004 14:16:28 +0200 (EET) Subject: APT-enabled *development* repository In-Reply-To: References: Message-ID: On Wed, 4 Feb 2004, Damiano Albani wrote: > Hello, > > I can't find any APT repository which provides > development/RawHide branch for Fedora. > I know there's Yum, but, up to me, it's unusable (long > downloads for the bunch of tiny headers, triggered every > time yum is used, etc). > > So, do you know one ? The only apt-enabled rawhide repository I know of is on freshrpms: rpm http://ayo.freshrpms.net/fedora/linux development/i386 core - Panu - From damiano at orange.fr Wed Feb 4 12:28:21 2004 From: damiano at orange.fr (Damiano Albani) Date: Wed, 4 Feb 2004 13:28:21 +0100 Subject: APT-enabled *development* repository Message-ID: >The only apt-enabled rawhide repository I know of is on freshrpms: > >rpm http://ayo.freshrpms.net/fedora/linux development/i386 core > > - Panu - Cheers, that's exactly what I was looking for ! Damiano From iago.rubio at hispalinux.es Wed Feb 4 12:26:06 2004 From: iago.rubio at hispalinux.es (Iago Rubio) Date: 04 Feb 2004 13:26:06 +0100 Subject: APT-enabled *development* repository In-Reply-To: References: Message-ID: <1075897565.26682.3.camel@speedy.iagorubio.net> El mi?, 04 de 02 de 2004 a las 13:07, Damiano Albani escribi?: > I can't find any APT repository which provides > development/RawHide branch for Fedora. Sorry, I can't help you > I know there's Yum, but, up to me, it's unusable (long > downloads for the bunch of tiny headers, triggered every > time yum is used, etc). If this is the reason that made yum unusable for you, you can try the -C option - "yum -C" - to run yum from cache, and avoid to download the headers each time you use it. regards - iago rubio - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From sopwith at redhat.com Wed Feb 4 13:34:25 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 4 Feb 2004 08:34:25 -0500 (EST) Subject: Will FC2 move towards mdadm for all software raid config In-Reply-To: <20040204093205.GE27591@outblaze.com> References: <20040204093205.GE27591@outblaze.com> Message-ID: On Wed, 4 Feb 2004, Yusuf Goolamabbas wrote: > Considering that 2.6.2 has been released with RAID6 support which is > only supported by mdadm, will FC2 use mdadm exclusively and deprecate > raidtools mdadm is already included. raidtools will be eventually deprecated, but I believe the installer still needs it at this point. It's a matter of time :) -- Elliot Friends help you move. Real friends help you move bodies. From nphilipp at redhat.com Wed Feb 4 14:24:45 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 04 Feb 2004 15:24:45 +0100 Subject: Corporate pressure In-Reply-To: <1075726999.8854.12.camel@owsdavid> References: <401E480E.1060307@home.se> <1075726999.8854.12.camel@owsdavid> Message-ID: <1075904685.29250.10.camel@wombat.tiptoe.de> On Mon, 2004-02-02 at 14:03, david paeme wrote: > wouldn't it be a good idea to include some kind of license acceptance > mechanism into apt/yum/rpm? No (see comments about unattended installs etc.). > for example, to get adobe acrobat to install, the user would get a > prompt to accept the adobe license, which he can (and the software > installs), or not (so, it doesn't install...). One could do it like Netscape did (already mentioned) and/or have the administrator append something like "I accept this license" to some EULA file. The app can check for that at startup and if neither the user accepted the license "by clicking" nor the admin by "signing" the EULA accepted the license, bring up the EULA dialog -- mentioning something like "you can accept this license for yourself or for all of your users by appending the line 'I accept this license' (without quotes) to the end of /var/lib/myproprietaryapp/eula". The app could then verify the integrity of the eula file and the existence of the confirmation blurb. There is absolutely no need to change packaging tools for 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 salimma at fastmail.fm Wed Feb 4 14:43:08 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 04 Feb 2004 21:43:08 +0700 Subject: APT-enabled *development* repository In-Reply-To: References: Message-ID: <1075905787.4587.3.camel@localhost.localdomain> On Wed, 2004-02-04 at 13:07 +0100, Damiano Albani wrote: > Hello, > > I can't find any APT repository which provides > development/RawHide branch for Fedora. > I know there's Yum, but, up to me, it's unusable (long > downloads for the bunch of tiny headers, triggered every > time yum is used, etc). > > So, do you know one ? > FreshRPMS, URL already posted by someone else, although you might want to know that up2date seems to work fine using yum (i.e. no stalls getting headers). up2date-gui even refreshes within a second or so after another window has been moved over it, or after a virtual desktop switch, which is a nice surprise. HTH, 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 raphael at endian.it Wed Feb 4 15:38:32 2004 From: raphael at endian.it (Raphael Vallazza) Date: Wed, 4 Feb 2004 16:38:32 +0100 Subject: Problems compiling nss_pgsql on FC1 Message-ID: <30427363-5728-11D8-A143-000A95CEF456@endian.it> Hi, i'm trying to compile libnss-pgsql 1.0 on Fedora Core 1 (http://sourceforge.net/projects/sysauth-pgsql) but i always get the following error: Making all in src make[1]: Entering directory `/tmp/libnss-pgsql-1.0.0/src' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -DLIBDIR=\"/usr/local/lib\" -DSYSCONFDIR=\"/usr/local/etc\" -D_GNU_SOURCE -O2 -Wall -Wstrict-prototypes -c interface.c gcc -DHAVE_CONFIG_H -I. -I. -I. -DLIBDIR=\"/usr/local/lib\" -DSYSCONFDIR=\"/usr/local/etc\" -D_GNU_SOURCE -O2 -Wall -Wstrict-prototypes -c interface.c -fPIC -DPIC -o interface.lo In file included from interface.c:15: /usr/include/bits/libc-lock.h:27:36: linuxthreads/internals.h: No such file or directory make[1]: *** [interface.lo] Error 1 make[1]: Leaving directory `/tmp/libnss-pgsql-1.0.0/src' make: *** [all-recursive] Error 1 Is this a problem of the FC1 glibc package or maybe a problem with NPTL? I've tried to copy linuxthreads/internals.h from the glibc source, but it caused even more problems :) Thanks for your help! Ciao, Raphael :: e n d i a n :: open source - open minds :: raphael vallazza :: i-39057 eppan/appiano, bergweg 41 via monte :: mobile +39 339 5620338 :: fax +39 0471 665468 :: http://www.endian.it :: raphael at endian.it From jeffrin_jose at rajagiritech.ac.in Wed Feb 4 15:59:29 2004 From: jeffrin_jose at rajagiritech.ac.in (jeffrin_jose at rajagiritech.ac.in) Date: Wed, 4 Feb 2004 21:29:29 +0530 (IST) Subject: Xfree86 bug related. Message-ID: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> hello , I have Fedora Core 1 one in my home PC. It' reports a bug like this ... atkbd.c : This is an XFree86 bug .It should not access hardware directly. atkbd.c: unknown key released (translated set 2,code 0x7a on isa0060/serio0). Please tell me if possible what the error message indicates. ----------------------------------------- Rajagiri School of Engineering and Technology Kakkanad, Ernakulam http://rajagiritech.ac.in/ From salimma at fastmail.fm Wed Feb 4 16:26:44 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 04 Feb 2004 23:26:44 +0700 Subject: mplayer vs. xine In-Reply-To: <20040201185521.A14991@meenakshi.cs.iitm.ernet.in> References: <20040130185843.GA29987@thyrsus.com> <1075492813.14038.35.camel@island.ite.gmu.edu> <20040131122428.4223b154.ms-nospam-0306@arcor.de> <20040131145130.GB5507@thyrsus.com> <401BCE58.9010602@home.se> <20040131162228.GF5507@thyrsus.com> <401C155D.3050101@home.se> <20040131212544.GB10087@thyrsus.com> <401C7118.50306@linux.duke.edu> <20040201185521.A14991@meenakshi.cs.iitm.ernet.in> Message-ID: <1075912003.7464.1.camel@localhost.localdomain> On Sun, 2004-02-01 at 18:55 +0530, Arvind Narayanan wrote: > On Sat, Jan 31, 2004 at 10:23:04PM -0500, Konstantin Riabitsev wrote: > [snip] > > However, distributing proprietary packages without having a license > > to distribute them would be a violation of international copyrights, > > which is a criminal offense in most of the civilized world. As long > ^^^^^^^^^ > Is the implication intentional? > Just curious. > Well, that statement is not offensive. Even in backwater Indonesia we have copyright laws, so it's a criminal offense to distribute without a license. It's just .. ahem.. the implementation of those laws that leave much to be desired. - Michel * looking over his shoulder * -------------- 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 yusufg at outblaze.com Wed Feb 4 16:41:38 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Thu, 5 Feb 2004 00:41:38 +0800 Subject: Will FC2 move towards mdadm for all software raid config In-Reply-To: References: <20040204093205.GE27591@outblaze.com> Message-ID: <20040204164138.GA32762@outblaze.com> > > Considering that 2.6.2 has been released with RAID6 support which is > > only supported by mdadm, will FC2 use mdadm exclusively and deprecate > > raidtools > > mdadm is already included. raidtools will be eventually deprecated, but I > believe the installer still needs it at this point. So FC2 will still use /etc/raidtab to configure software-raid ? Would FC2 boot-up sequence (post-install) ever understand /etc/mdadm.conf ? Regards, Yusuf From twaugh at redhat.com Wed Feb 4 16:53:57 2004 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 4 Feb 2004 16:53:57 +0000 Subject: FHS 2.3? Message-ID: <20040204165357.GW25654@redhat.com> Do we intend to implement the new bits of FHS for Fedora Core 2? For instance, there is now wording about /usr/share/xml. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mark at mitre.org Wed Feb 4 17:04:54 2004 From: mark at mitre.org (guest) Date: Wed, 04 Feb 2004 12:04:54 -0500 Subject: APT-enabled *development* repository In-Reply-To: References: Message-ID: <40212636.4000007@mitre.org> Panu Matilainen wrote: >On Wed, 4 Feb 2004, Damiano Albani wrote: > > > >>Hello, >> >>I can't find any APT repository which provides >>development/RawHide branch for Fedora. >>I know there's Yum, but, up to me, it's unusable (long >>downloads for the bunch of tiny headers, triggered every >>time yum is used, etc). >> >>So, do you know one ? >> >> > >The only apt-enabled rawhide repository I know of is on freshrpms: > >rpm http://ayo.freshrpms.net/fedora/linux development/i386 core > > - Panu - > > > > Yep Ive been using apt freshrpms - development for a long time but: -as of a couple days ago most of the headers were out of sync with the packages, ie, the headers were advanced one version beyond the packages. This caused ~ %80 of apt-get upgrade to fail. -the most recent version of apt was not built against the new version 3 of rpm causing rpm, yum and all of its cousins to be held back -Mark From fedora at leemhuis.info Wed Feb 4 17:12:28 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Feb 2004 18:12:28 +0100 Subject: Xfree86 bug related. In-Reply-To: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> References: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> Message-ID: <1075914748.1787.1.camel@work.thl.home> Am Mi, den 04.02.2004 schrieb jeffrin_jose at rajagiritech.ac.in um 16:59: > hello , > > I have Fedora Core 1 one in my home PC. > It' reports a bug like this ... > > atkbd.c : This is an XFree86 bug .It should not access hardware directly. > atkbd.c: unknown key released (translated set 2,code 0x7a on isa0060/serio0). > > Please tell me if possible what the error message indicates. Quoting http://lwn.net/Articles/69107/ > Problem: > ~~~~~~~~ > > Kernel reports: > atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). > atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. > > Solution: > ~~~~~~~~~ > > Well, the kernel means what it says. XFree86 boldly goes and accesses the > keyboard controller registers when it starts up. This is a bad thing to do, > as it can conflict with the kernel using these registers at the same time. > The kernel spots this and complains, and in most cases is not affected by > the problem. > > So, unless you are an XFree86 developer and can fix X, ignore this message. HTH CU thl From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 4 17:28:16 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 Feb 2004 18:28:16 +0100 Subject: APT-enabled *development* repository In-Reply-To: <40212636.4000007@mitre.org> References: <40212636.4000007@mitre.org> Message-ID: <20040204182816.1fbeb85a@localhost> guest wrote : > Panu Matilainen wrote: > > > The only apt-enabled rawhide repository I know of is on freshrpms: > > > > rpm http://ayo.freshrpms.net/fedora/linux development/i386 core > > > Yep Ive been using apt freshrpms - development for a long time but: > -as of a couple days ago most of the headers were out of sync with the > packages, ie, the headers were advanced one version beyond the > packages. This caused ~ %80 of apt-get upgrade to fail. > -the most recent version of apt was not built against the new version 3 > of rpm causing rpm, yum and all of its cousins to be held back For the out-of-sync problem, you can temporarily use ayo.us.freshrpms.net where there won't be any problem with the development tree (please don't point to there for anything else, thanks!). As for the new rpm breaking apps linked against rpm... I really should play around more with the devel tree... but expect some goodies and fixes (IIRC ImageMagick dependent stuff like transcode is also broken now) once test1 is out, at least to bring the "apt-get dist-upgrade" possibility to the daring :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.1-1.61 Load : 0.96 1.06 0.76 From drepper at redhat.com Wed Feb 4 17:34:23 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 04 Feb 2004 09:34:23 -0800 Subject: Problems compiling nss_pgsql on FC1 In-Reply-To: <30427363-5728-11D8-A143-000A95CEF456@endian.it> References: <30427363-5728-11D8-A143-000A95CEF456@endian.it> Message-ID: <40212D1F.8090701@redhat.com> Raphael Vallazza wrote: > Is this a problem of the FC1 glibc package or maybe a problem with NPTL? > I've tried to copy linuxthreads/internals.h from the glibc source, but > it caused even more problems :) Update your libc to the current version in testing. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From laroche at redhat.com Wed Feb 4 17:47:58 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 4 Feb 2004 18:47:58 +0100 Subject: Dell laptop C640 and suspend Message-ID: <20040204174757.GE14977@dudweiler.stuttgart.redhat.com> My Dell C640 has problems after suspend. I currently run the newest upstream driver copied into a Fedora Core 1 install and that works without any problems. Does anyone know what change has to be applied ontop of the RH src.rpm to fix this? greetings, Florian La Roche From laroche at redhat.com Wed Feb 4 17:55:57 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 4 Feb 2004 18:55:57 +0100 Subject: Dell laptop C640 and suspend In-Reply-To: <20040204174757.GE14977@dudweiler.stuttgart.redhat.com> References: <20040204174757.GE14977@dudweiler.stuttgart.redhat.com> Message-ID: <20040204175557.GA17276@dudweiler.stuttgart.redhat.com> On Wed, Feb 04, 2004 at 06:47:58PM +0100, Florian La Roche wrote: > My Dell C640 has problems after suspend. I currently run the newest > upstream driver copied into a Fedora Core 1 install and that works > without any problems. Does anyone know what change has to be applied > ontop of the RH src.rpm to fix this? Ewwp. This is with the radeon driver of course. Florian La Roche From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 4 18:06:19 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 Feb 2004 19:06:19 +0100 Subject: Dell laptop C640 and suspend In-Reply-To: <20040204175557.GA17276@dudweiler.stuttgart.redhat.com> References: <20040204174757.GE14977@dudweiler.stuttgart.redhat.com> <20040204175557.GA17276@dudweiler.stuttgart.redhat.com> Message-ID: <20040204190619.2e05d131@localhost> Florian La Roche wrote : > On Wed, Feb 04, 2004 at 06:47:58PM +0100, Florian La Roche wrote: > > My Dell C640 has problems after suspend. I currently run the newest > > upstream driver copied into a Fedora Core 1 install and that works > > without any problems. Does anyone know what change has to be applied > > ontop of the RH src.rpm to fix this? > > Ewwp. This is with the radeon driver of course. I've just switched my good old Inspiron 8000 (3 years old!) for a 8600 which has an ATI Radeon Mobility 8600 card. With the latest 2.6 kernel from FC development, I can actually get the system to go into suspend (3) mode, but when restoring, the display does something nasty and unrecoverable when in X, or stays completely off when in console mode. I can actually "use" the system once resumed, i.e. type "reboot", but can't see anything on the screen and don't know of any way to get the display back :-( This is with XFree86 4.4RC2 as 4.3 doesn't recognize the card, and the binary ATI drivers have broken Xv output and killed the graphic card last week (I had to have it replaced yeasterday...). ACPI is great, but soooooo flaky. Too bad, but it should keep on getting better. Sorry if this hadn't much to do with your initial question, but I'm not even sure I actually understood it :-) Mine is, "what can I do to have my display switch back on after a suspend to ram"? Can it be a BIOS problem, kernel problem? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.1-1.61 Load : 0.90 0.57 0.52 From mark at mark.mielke.cc Wed Feb 4 18:41:29 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed, 4 Feb 2004 13:41:29 -0500 Subject: /etc/fedora-release still shows "Yarrow Test 1" Message-ID: <20040204184129.GA12702@mark.mielke.cc> $ cat /etc/fedora-release Fedora Core release 1.90 (Yarrow Test 1) Perhaps it should read "Cambridge Test 1"? 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 steve at silug.org Wed Feb 4 18:53:23 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 4 Feb 2004 12:53:23 -0600 Subject: APT-enabled *development* repository In-Reply-To: References: Message-ID: <20040204185323.GA31186@osiris.silug.org> On Wed, Feb 04, 2004 at 01:07:18PM +0100, Damiano Albani wrote: > I can't find any APT repository which provides > development/RawHide branch for Fedora. rpm http://apt.kspei.com fedora/development/i386 os I don't have a lot of bandwidth, so be gentle. ;-) (But it's there if you need it...) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From notting at redhat.com Wed Feb 4 19:28:34 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Feb 2004 14:28:34 -0500 Subject: /etc/fedora-release still shows "Yarrow Test 1" In-Reply-To: <20040204184129.GA12702@mark.mielke.cc> References: <20040204184129.GA12702@mark.mielke.cc> Message-ID: <20040204192834.GE29146@devserv.devel.redhat.com> Mark Mielke (mark at mark.mielke.cc) said: > $ cat /etc/fedora-release > Fedora Core release 1.90 (Yarrow Test 1) > > Perhaps it should read "Cambridge Test 1"? Cambridge was the last release. :) Yes, we know about it, we're fixing it. Bill From felipe_alfaro at linuxmail.org Wed Feb 4 19:46:24 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 04 Feb 2004 20:46:24 +0100 Subject: /etc/fedora-release still shows "Yarrow Test 1" In-Reply-To: <20040204184129.GA12702@mark.mielke.cc> References: <20040204184129.GA12702@mark.mielke.cc> Message-ID: <1075923983.846.0.camel@teapot.felipe-alfaro.com> On Wed, 2004-02-04 at 19:41, Mark Mielke wrote: > $ cat /etc/fedora-release > Fedora Core release 1.90 (Yarrow Test 1) > > Perhaps it should read "Cambridge Test 1"? # cat /etc/redhat-release Fedora Core release 1 (Yarrow) (machine is updated from devel tree)... Am I missing something? From mark at mark.mielke.cc Wed Feb 4 20:43:53 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed, 4 Feb 2004 15:43:53 -0500 Subject: /etc/fedora-release still shows "Yarrow Test 1" In-Reply-To: <1075923983.846.0.camel@teapot.felipe-alfaro.com> References: <20040204184129.GA12702@mark.mielke.cc> <1075923983.846.0.camel@teapot.felipe-alfaro.com> Message-ID: <20040204204353.GB13831@mark.mielke.cc> On Wed, Feb 04, 2004 at 08:46:24PM +0100, Felipe Alfaro Solana wrote: > On Wed, 2004-02-04 at 19:41, Mark Mielke wrote: > > $ cat /etc/fedora-release > > Fedora Core release 1.90 (Yarrow Test 1) > > Perhaps it should read "Cambridge Test 1"? > # cat /etc/redhat-release > Fedora Core release 1 (Yarrow) > (machine is updated from devel tree)... Am I missing something? Update again. 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 fedora at warmcat.com Wed Feb 4 20:58:59 2004 From: fedora at warmcat.com (Andy Green) Date: Wed, 4 Feb 2004 20:58:59 +0000 Subject: Dell laptop C640 and suspend In-Reply-To: <20040204190619.2e05d131@localhost> References: <20040204174757.GE14977@dudweiler.stuttgart.redhat.com> <20040204175557.GA17276@dudweiler.stuttgart.redhat.com> <20040204190619.2e05d131@localhost> Message-ID: <200402042058.59978.fedora@warmcat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 February 2004 18:06, Matthias Saou wrote: > ACPI is great, but soooooo flaky. Too bad, but it should keep on getting > better. Sorry if this hadn't much to do with your initial question, but I'm > not even sure I actually understood it :-) Mine is, "what can I do to have > my display switch back on after a suspend to ram"? Can it be a BIOS > problem, kernel problem? Probably a BIOS or video driver problem I would think. Try using the Fn-F8 combination (it is that on my 5150) to switch between CRT and LCD, this may manage to do something. Also have a look at the display at an oblique angle to external lighting... its possible the LCD is up but the backlight is off. In this case you can just see the image on the LCD if you get it at the right angle. I have the nVidia card for my Inspiron and it has its own issues, the recent nVidia binary drivers stop sending data to the LCD panel if you enter one of the text consoles after being in X. So don't feel bad about choosing ATI :-) - -Andy - -- Find your answer without waiting for replies.... Searchable list archives at http://marc.theaimsgroup.com/?l=fedora-list&r=1&w=2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIV0TjKeDCxMJCTIRAqOEAJ4iUQYX52RXgOlDYzjLZyRpXXqNlgCfX7Gn F6rKo/hUMA/poIZomDrg4GA= =yb9i -----END PGP SIGNATURE----- From jrb at redhat.com Wed Feb 4 21:04:48 2004 From: jrb at redhat.com (Jonathan Blandford) Date: 04 Feb 2004 16:04:48 -0500 Subject: yelp not on menu ... .xmms directory not created In-Reply-To: <402063C2.90709@insight.rr.com> References: <402063C2.90709@insight.rr.com> Message-ID: Jim Cornette writes: > When searching the menus for help, I decided to try and run yelp at > the command prompt. I got this output in the terminal. Yelp came up > and is usable. > > yelp > Use of deprecated SAXv1 function endElement > /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input > is not pr oper UTF-8, indicate encoding ! > Manual de la miniaplicaic?n Lista de ventanas V2.6 > ^ > /usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 > 0x6E 0x20 0 x4C > Manual de la miniaplicaic?n Lista de ventanas V2.6 This is fixed upstream, and is harmless. It should be fixed next time we rev gnome-panel. -Jonathan From raphael at endian.it Wed Feb 4 21:29:11 2004 From: raphael at endian.it (Raphael Vallazza) Date: Wed, 4 Feb 2004 22:29:11 +0100 Subject: Problems compiling nss_pgsql on FC1 In-Reply-To: <40212D1F.8090701@redhat.com> References: <30427363-5728-11D8-A143-000A95CEF456@endian.it> <40212D1F.8090701@redhat.com> Message-ID: <2C2F01DA-5759-11D8-A143-000A95CEF456@endian.it> >> Is this a problem of the FC1 glibc package or maybe a problem with >> NPTL? >> I've tried to copy linuxthreads/internals.h from the glibc source, but >> it caused even more problems :) > > Update your libc to the current version in testing. Thanks for your answer. What do you mean with testing? The development tree? Right now i have the following packages installed: [root at stormcrawl glibc]# rpm -qa | grep glibc glibc-headers-2.3.2-101.4 glibc-common-2.3.2-101.4 glibc-kernheaders-2.4-8.36 glibc-devel-2.3.2-101.4 glibc-2.3.2-101.4 :: e n d i a n :: open source - open minds :: raphael vallazza :: i-39057 eppan/appiano, bergweg 41 via monte :: mobile +39 339 5620338 :: fax +39 0471 665468 :: http://www.endian.it :: raphael at endian.it From ronny-vlug at vlugnet.org Wed Feb 4 21:44:24 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Wed, 4 Feb 2004 22:44:24 +0100 Subject: FHS 2.3? In-Reply-To: <20040204165357.GW25654@redhat.com> References: <20040204165357.GW25654@redhat.com> Message-ID: <200402042244.24575.ronny-vlug@vlugnet.org> On Wednesday 04 February 2004 17:53, Tim Waugh wrote: > Do we intend to implement the new bits of FHS for Fedora Core 2? For > instance, there is now wording about /usr/share/xml. > I would really like it, especially the /media, /mnt, /srv and /usr/src stuff. -- http://LinuxWiki.org/RonnyBuchmann From mharris at redhat.com Wed Feb 4 21:48:16 2004 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 4 Feb 2004 16:48:16 -0500 (EST) Subject: Xfree86 bug related. In-Reply-To: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> References: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> Message-ID: On Wed, 4 Feb 2004 jeffrin_jose at rajagiritech.ac.in wrote: >I have Fedora Core 1 one in my home PC. >It' reports a bug like this ... > >atkbd.c : This is an XFree86 bug .It should not access hardware directly. >atkbd.c: unknown key released (translated set 2,code 0x7a on isa0060/serio0). > >Please tell me if possible what the error message indicates. $ locate atkbd.c linux-2.6.0/drivers/input/keyboard/atkbd.c Looks like a kernel warning. XFree86 accesses a lot of hardware directly, by design. I'm not sure it's fair for the kernel to say that is a bug, however I would certainly agree that it isn't the best possible design for the Linux usage case. >From the message above alone though, having never seen it before, it's hard to conclude what the real problem is. Perhaps the kernel keyboard driver maintainer, or another kernel hacker could extrapolate more on what this problem is. If it's a small bug or issue of some kind in XFree86 that's easily fixable, then there's no reason I can see not to fix it. If the kernel error above implies half of XFree86's keyboard support should be thrown out and rewritten though to please the Linux kernel, then I welcome patches from kernel people (or anyone) to implement that. ;o) In the mean time, lets see what google says. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From xose at wanadoo.es Wed Feb 4 21:48:54 2004 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 04 Feb 2004 22:48:54 +0100 Subject: FHS 2.3? In-Reply-To: <200402042244.24575.ronny-vlug@vlugnet.org> References: <20040204165357.GW25654@redhat.com> <200402042244.24575.ronny-vlug@vlugnet.org> Message-ID: <402168C6.4070908@wanadoo.es> Ronny Buchmann wrote: > I would really like it, especially the /media, /mnt, /srv and /usr/src stuff. Red Hat gurus did not like /media and /srv changes. -- Software is like sex, it's better when it's bug free. From mharris at redhat.com Wed Feb 4 22:13:27 2004 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 4 Feb 2004 17:13:27 -0500 (EST) Subject: FHS 2.3? In-Reply-To: <20040204165357.GW25654@redhat.com> References: <20040204165357.GW25654@redhat.com> Message-ID: On Wed, 4 Feb 2004, Tim Waugh wrote: >Date: Wed, 4 Feb 2004 16:53:57 +0000 >From: Tim Waugh >To: fedora-devel-list at redhat.com >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="GFPlsJ7YtLjXgs8j" >List-Id: Development discussions related to Fedora Core > >Subject: FHS 2.3? > >Do we intend to implement the new bits of FHS for Fedora Core 2? For >instance, there is now wording about /usr/share/xml. Many people have objections to things in the new FHS 2.3, and I'm no exception. Nonetheless, the new FHS exists, and I'm curious also what our official plans (if any yet) are with respect to the FHS 2.3. Since many of us will have packages that are affected, there are a few questions that would be good to know the answers to sooner rather than later, however these questions might not yet have solid answers, and may require some deliberation. Here are a few questions on my mind at least: - Are we going to support the FHS 2.3 or not? - Are we going to wait until FHS 2.3 is adopted by LSB? - If we are adopting FHS 2.3, what distribution will it be targeting - FC2 / FC3 / RHEL4? beyond that? Of course it may be too early for an answer to these questions to be available yet, so Pentagon briefing style answers are sufficient if necessary. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Feb 4 22:21:18 2004 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 4 Feb 2004 17:21:18 -0500 (EST) Subject: Xfree86 bug related. In-Reply-To: <1075914748.1787.1.camel@work.thl.home> References: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> <1075914748.1787.1.camel@work.thl.home> Message-ID: On Wed, 4 Feb 2004, Thorsten Leemhuis wrote: >Date: Wed, 04 Feb 2004 18:12:28 +0100 >From: Thorsten Leemhuis >To: "fedora-devel-list at redhat.com" >Content-Type: text/plain >List-Id: Development discussions related to Fedora Core > >Subject: Re: Xfree86 bug related. > >Am Mi, den 04.02.2004 schrieb jeffrin_jose at rajagiritech.ac.in um 16:59: >> hello , >> >> I have Fedora Core 1 one in my home PC. >> It' reports a bug like this ... >> >> atkbd.c : This is an XFree86 bug .It should not access hardware directly. >> atkbd.c: unknown key released (translated set 2,code 0x7a on isa0060/serio0). >> >> Please tell me if possible what the error message indicates. > >Quoting >http://lwn.net/Articles/69107/ Ah good, that's a start. It's more or less what I figured though. Wether the "fix" is simple or not depends on why X exactly is accessing the keyboard controller, which I may have known at one point but don't recall. The FAQ seems to state that the kernel detects this *cough* problem *cough* and handles it properly however, so there's no problem actually occuring (at least that I can see). Wouldn't be a high priority to look into, but low priority bugs such as this are good low hanging fruit for interested volunteers to help out OSS development by tracking the problem down and trying to fix it. If anyone is interested in looking at this and needs any assistance figuring out X, etc. feel free to ping me in #freedesktop, or #xfree86 on irc.freenode.net. Might want to drop it in bugzilla also as a low priority tracker bug perhaps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jkeating at j2solutions.net Wed Feb 4 22:27:07 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 4 Feb 2004 14:27:07 -0800 Subject: Will FC2 move towards mdadm for all software raid config In-Reply-To: <20040204164138.GA32762@outblaze.com> References: <20040204093205.GE27591@outblaze.com> <20040204164138.GA32762@outblaze.com> Message-ID: <200402041427.07634.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 February 2004 08:41, Yusuf Goolamabbas wrote: > So FC2 will still use /etc/raidtab to configure software-raid ? > Would FC2 boot-up sequence (post-install) ever understand > /etc/mdadm.conf ? Seth Vidal and a few other people are doing the work necessary to get FC2 mdadm ready. As mentioned the big blocker currently is modifying anaconda to use mdadm instead of raidtools. The userland changes are minimal. If you know python, ping Jeremy Katz. - -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAIXG74v2HLvE71NURAtMaAJwO4vnZhvcu+3b6Ch1AM83wPpfg+ACbB5T9 y8fARu0kMqbMpH4/hYPjdbw= =BpTJ -----END PGP SIGNATURE----- From jkeating at j2solutions.net Wed Feb 4 22:28:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 4 Feb 2004 14:28:22 -0800 Subject: FHS 2.3? In-Reply-To: <200402042244.24575.ronny-vlug@vlugnet.org> References: <20040204165357.GW25654@redhat.com> <200402042244.24575.ronny-vlug@vlugnet.org> Message-ID: <200402041428.22081.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 February 2004 13:44, Ronny Buchmann wrote: > I would really like it, especially the /media, /mnt, /srv and > /usr/src stuff. These are some of the things many of us specifically do NOT like about FHS 2.3. - -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAIXIG4v2HLvE71NURAmBfAJ4qggCtOr5D0RxLX8ZFBhLAYC8VUQCgqzsN dh14S3NvxfTTu9wTmTO+bQU= =ltwl -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Wed Feb 4 22:42:19 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 04 Feb 2004 23:42:19 +0100 Subject: FHS 2.3? In-Reply-To: <200402041428.22081.jkeating@j2solutions.net> References: <20040204165357.GW25654@redhat.com> <200402042244.24575.ronny-vlug@vlugnet.org> <200402041428.22081.jkeating@j2solutions.net> Message-ID: <1075934538.16800.12.camel@m222.net81-64-248.noos.fr> Le mer, 04/02/2004 ? 14:28 -0800, Jesse Keating a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 04 February 2004 13:44, Ronny Buchmann wrote: > > I would really like it, especially the /media, /mnt, /srv and > > /usr/src stuff. > > These are some of the things many of us specifically do NOT like about > FHS 2.3. How about merging the uncontroversial bits, then and let LSB people fight over the parts some people do not like ? I don't think anyone will object to /usr/share/xml or /usr/src, and this will impact a lot more packages than /srv/ or /media. 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 cornette at insight.rr.com Thu Feb 5 02:52:22 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Wed, 04 Feb 2004 21:52:22 -0500 Subject: yelp not on menu ... .xmms directory not created In-Reply-To: References: <402063C2.90709@insight.rr.com> Message-ID: <4021AFE6.3020403@insight.rr.com> Jonathan Blandford wrote: >Jim Cornette writes: > > > >>When searching the menus for help, I decided to try and run yelp at >>the command prompt. I got this output in the terminal. Yelp came up >>and is usable. >> >>yelp >>Use of deprecated SAXv1 function endElement >>/usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input >>is not pr oper UTF-8, indicate encoding ! >>Manual de la miniaplicaic?n Lista de ventanas V2.6 >>^ >>/usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 >>0x6E 0x20 0 x4C >>Manual de la miniaplicaic?n Lista de ventanas V2.6 >> >> > >This is fixed upstream, and is harmless. It should be fixed next time >we rev gnome-panel. > >-Jonathan > > > > Thanks for the info. I noticed a similar output when using either up2date or yum to retrieve later rpms also. I didn't notice anything loss of program functionality though. Some comments regarding the synaptic touch pad issue. This not being supported yet with the 2.6 kernel (or Xfree86) has deterred me from trying the development or even the 2.6 kernel out on the laptop. Though my touch pad will work as a standard mouse without the support. It is a loss of convenience that a lot of laptop users will stay with the 2.4 kernel on these machines. -- You have the body of a 19 year old. Please return it before it gets wrinkled. From cornette at insight.rr.com Thu Feb 5 04:02:08 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Wed, 04 Feb 2004 23:02:08 -0500 Subject: nautilus does not stop after X closed Message-ID: <4021C040.40505@insight.rr.com> Since I just upgraded and a lot of changes have effected the state of GNOME, when logging in. after it was closed down. I logged out of X (runlevel 3) and when I logged back into GNOME, I had no desktop ICONs (completely black and no launchers). Logging out of GNOME was also very slow. (a minute or so) I suspected the updates, but none of them seemed related to X performance. fedora-release-1.90-9 indexhtml-1.90-2 mod_python-3.0.4-0.1 pam-0.77-30 pam-devel-0.77-30 Nautilus was running twice without X being loaded. After 'killall nautilus' was run, logging into GNOME allowed all ICONS, background, etc to be normal. I don't usually log out of GNOME and back in, so I do not know how long this behavior has been there. Also, when does discussion about beta issues resume on the beta list? Are we in test1 yet? Jim PS - I figured out the noarch problem on my end for yum and up2date. I was using the headers outside of i386, (just to the development directory) which worked, except for nodeps. Then it would try to pull noarch.rpms from ppc64, s390, etc. (These weren't carried by the mirror I was using, as Seth referred to. What is the purpose of the headers directory within the development directory? From jeffrin_jose at rajagiritech.ac.in Thu Feb 5 05:52:23 2004 From: jeffrin_jose at rajagiritech.ac.in (jeffrin_jose at rajagiritech.ac.in) Date: Thu, 5 Feb 2004 11:22:23 +0530 (IST) Subject: Fedora related Message-ID: <4898.203.197.151.51.1075960343.mailer@mail.rajagiritech.ac.in> Hello all Do Fedora have any policy to take software into it ? If yes, please tell me if possible that,do they include only Free software according to the definition of FSF for free software. ----------------------------------------- Rajagiri School of Engineering and Technology Kakkanad, Ernakulam http://rajagiritech.ac.in/ From wtogami at redhat.com Thu Feb 5 06:49:29 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 04 Feb 2004 20:49:29 -1000 Subject: Test Update Tracking proposal Message-ID: <4021E779.4010307@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114986 This is the first test of the "Tracking" report concept, where users report only definite findings for Fedora Test Updates while discussion remains on the mailing lists. This helps to organize information about the update away from the chaos of the mailing lists so it is easy to find. I also envision this as being a method of fostering multiple communities/lists to get involved. In the case of gdm above, the K12LTSP community is very much involved with production testing along with the regular fedora-test-list. In other cases we may have upstream project lists involved in testing. This may also get the attention of upstream developers who are more likely to see the discussions. Fedora has a chance to remain better in sync with upstream with improved communication, rather than Fedora-specific patches sit in our SRPM for years. While discussions may be scattered on multiple lists, definite findings are sent to these tracking reports at Fedora. The best part of what these tracking reports is something like this: http://www.fedora.us/NEEDSWORK http://www.fedora.us/PUBLISH http://www.fedora.us/LEGACY At any time, a site visitor can quickly use pre-set queries like these and immediately see the status of all Test Updates. If they run into a bug, they can quickly see if the package is already fixed and only needing functionality testing. All without sifting through the heavy traffic of mailing lists. One thing that would need to be enforced for this to work is strong discouragement of discussion within the Tracking reports. Only definite findings should be posted within there. Discussions on lists only. For this easy-and-quick query ability, we could use the Developer Whiteboard, but I am requesting a permanent keyword like "UPDATE". The pre-set query can search for "Fedora Core", "1", and keyword "UPDATE" and display everything. Thoughts? Warren Togami wtogami at redhat.com From ghenry at suretecsystems.com Thu Feb 5 07:48:42 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 5 Feb 2004 07:48:42 +0000 Subject: Fedora related In-Reply-To: <4898.203.197.151.51.1075960343.mailer@mail.rajagiritech.ac.in> References: <4898.203.197.151.51.1075960343.mailer@mail.rajagiritech.ac.in> Message-ID: <200402050748.48776.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 05 February 2004 05:52, jeffrin_jose at rajagiritech.ac.in wrote: > Hello all > > > Do Fedora have any policy to take software into it ? > If yes, please tell me if possible that,do they include > only Free software according to the definition of FSF > for free software. http://www.fedora.us/wiki/PackageSubmissionQAPolicy if they still accept this way. > ----------------------------------------- > Rajagiri School of Engineering and Technology > Kakkanad, Ernakulam > http://rajagiritech.ac.in/ - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIfVeeWseh9tzvqgRAivSAKCdNdY19pkaTZIUk3yEpu+UtxVZ1ACffUPn qpy+j7uLw9MpG3GD99QHkAg= =RkE0 -----END PGP SIGNATURE----- From alexl at redhat.com Thu Feb 5 07:49:54 2004 From: alexl at redhat.com (Alexander Larsson) Date: 05 Feb 2004 08:49:54 +0100 Subject: Nautilus toolbars In-Reply-To: <1075799409.13524.6.camel@localhost.localdomain> References: <1075733327.13051.1.camel@support02.civic.twp.ypsilanti.mi.us> <1075799409.13524.6.camel@localhost.localdomain> Message-ID: <1075967393.4965.33.camel@localhost.localdomain> On Tue, 2004-02-03 at 10:10, Michel Alexandre Salim wrote: > On Mon, 2004-02-02 at 09:48 -0500, Sean Middleditch wrote: > > Do note that middle-clicking on a folder will close the current window > > when opening the new. > > > Yes, but unfortunately it is done by closing the current window, then > opening a new window somewhere else, which could be... rather > distracting. This is not unfortunate, but rather a core property of a spatial file manager[1]. If you want to use a navigational one, start nautilus in browser mode. [1] See e.g. http://www.arstechnica.com/paedia/f/finder/finder-1.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a Nobel prize-winning amnesiac romance novelist who hides his scarred face behind a mask. She's a plucky tempestuous bounty hunter who can talk to animals. They fight crime! From ghenry at suretecsystems.com Thu Feb 5 11:40:11 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 5 Feb 2004 11:40:11 +0000 Subject: rpm --addsign problems Message-ID: <200402051140.18408.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I am trying to sign a SRPM, but issuing rpm --addsign (according to http://www.fedora.us/wiki/PackageSubmissionQAPolicy) comes up blank. I setup a ~/.rpmrc for GPG details and issuing a rpm --showrc shows GPG is setup correctly. There's seems to be conflicting info about all this, and somewhat out of date. Anyone have any tips on this? - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIiugeWseh9tzvqgRAnOIAJwPqDtAE/tIPOjPTYSeukfd3zd6AwCeMm5z 8RLC6gnwOr6QlK6hqQZ5dq8= =ThHS -----END PGP SIGNATURE----- From buildsys at redhat.com Thu Feb 5 11:55:35 2004 From: buildsys at redhat.com (Build System) Date: Thu, 5 Feb 2004 06:55:35 -0500 Subject: rawhide report: 20040205 changes Message-ID: <200402051155.i15BtZx02116@porkchop.devel.redhat.com> Updated Packages: fedora-release-1.90-11 ---------------------- fedora-release-1.90-12 ---------------------- rpmdb-fedora-1.90-0.20040205 ---------------------------- From bill at noreboots.com Thu Feb 5 11:57:45 2004 From: bill at noreboots.com (Bill Anderson) Date: Thu, 05 Feb 2004 04:57:45 -0700 Subject: Will FC2 move towards mdadm for all software raid config In-Reply-To: <200402041427.07634.jkeating@j2solutions.net> References: <20040204093205.GE27591@outblaze.com> <20040204164138.GA32762@outblaze.com> <200402041427.07634.jkeating@j2solutions.net> Message-ID: <1075982265.7026.569.camel@locutus> On Wed, 2004-02-04 at 15:27, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 04 February 2004 08:41, Yusuf Goolamabbas wrote: > > So FC2 will still use /etc/raidtab to configure software-raid ? > > Would FC2 boot-up sequence (post-install) ever understand > > /etc/mdadm.conf ? > > Seth Vidal and a few other people are doing the work necessary to get > FC2 mdadm ready. As mentioned the big blocker currently is modifying > anaconda to use mdadm instead of raidtools. The userland changes are > minimal. If you know python, ping Jeremy Katz. Is he on the list? If so .. PING. :) I'm pretty good with Python, but have yet to dig into Anaconda. Jeremy, if this isn't something you need to know Anaconda source very well for (or something a non-Anaconda source Python guy could deal with), let me know, I'll do what I can. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From alan at redhat.com Thu Feb 5 12:28:23 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 5 Feb 2004 07:28:23 -0500 Subject: Xfree86 bug related. In-Reply-To: References: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> Message-ID: <20040205122823.GB26514@devserv.devel.redhat.com> On Wed, Feb 04, 2004 at 04:48:16PM -0500, Mike A. Harris wrote: > Looks like a kernel warning. XFree86 accesses a lot of hardware > directly, by design. I'm not sure it's fair for the kernel to > say that is a bug, however I would certainly agree that it isn't > the best possible design for the Linux usage case. Its a bug in XFree86 or maybe even the build > If the kernel error above implies half of XFree86's keyboard > support should be thrown out and rewritten though to please the > Linux kernel, then I welcome patches from kernel people (or > anyone) to implement that. ;o) If you build XFree86 properly then it should use the stuff already present for keyboard control via ioctl. X has the stuff, and since Linux 2.4.x added the keyboard rate reprogramming ioctl shouldnt be touching the ports directly. The ports X touches may not even exist or may be reassigned on legacy free systems (thankfully nobody has reassigned them on production boards) Alan From alan at redhat.com Thu Feb 5 12:31:15 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 5 Feb 2004 07:31:15 -0500 Subject: Xfree86 bug related. In-Reply-To: References: <1048.202.88.226.177.1075910369.mailer@mail.rajagiritech.ac.in> <1075914748.1787.1.camel@work.thl.home> Message-ID: <20040205123115.GC26514@devserv.devel.redhat.com> On Wed, Feb 04, 2004 at 05:21:18PM -0500, Mike A. Harris wrote: > The FAQ seems to state that the kernel detects this *cough* > problem *cough* and handles it properly however, so there's no > problem actually occuring (at least that I can see). Wouldn't be *MOST* of the time. There is a finite possibility every time X touches the keyboard controller that the timing rules are violated and some machines hang or lose the keyboard until power cycle. Alan From leonard at den.ottolander.nl Thu Feb 5 13:42:33 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 14:42:33 +0100 Subject: Funny bugzilla error when adding myself to CC: list Message-ID: <1075988553.4747.57.camel@athlon.localdomain> Hi, I tried to add myself to the CC: list of bug #53003, as I want to file a bug report and patch that should close #53003 as duplicate, but I get the error: You tried to change the component field from AfterStep-APPS to initscripts, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field. What's funny about this is that the component is already set to initscripts. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Feb 5 14:13:39 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 15:13:39 +0100 Subject: fsck (or initlog) result codes Message-ID: <1075990419.4747.66.camel@athlon.localdomain> Hi, After an unclean shutdown and an apparently succesful fsck (no errors are reported during the fsck after the reboot) I am still forced to reboot the system. I suspect this might have to do with the fsck return codes being wrongly interpreted. Any value larger than 1 is considered a failure by the script. With an fsck result code of 3 however the system passes the next fsck with no errors whatsoever. Could it be that fsck's result code on failure actually is -1? Or any other value? Or does initlog (via which fsck is called) somehow change the result value? Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From salimma at fastmail.fm Thu Feb 5 15:11:55 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Thu, 05 Feb 2004 22:11:55 +0700 Subject: rpm --addsign problems In-Reply-To: <200402051140.18408.ghenry@suretecsystems.com> References: <200402051140.18408.ghenry@suretecsystems.com> Message-ID: <1075993915.6773.2.camel@localhost.localdomain> On Thu, 2004-02-05 at 11:40 +0000, Gavin Henry wrote: [snip] > I am trying to sign a SRPM, but issuing rpm --addsign (according to > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) > comes up blank. > If you followed that document and built the package as a different user from the user that is signing the source RPM, have you chown the file? You can't sign a package you don't have write access to, naturally. HTH, 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 notting at redhat.com Thu Feb 5 15:30:13 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Feb 2004 10:30:13 -0500 Subject: fsck (or initlog) result codes In-Reply-To: <1075990419.4747.66.camel@athlon.localdomain> References: <1075990419.4747.66.camel@athlon.localdomain> Message-ID: <20040205153013.GC31385@devserv.devel.redhat.com> Leonard den Ottolander (leonard at den.ottolander.nl) said: > I suspect this might have to do with the fsck return codes being wrongly > interpreted. Any value larger than 1 is considered a failure by the > script. > > With an fsck result code of 3 however the system passes the next fsck > with no errors whatsoever. Could it be that fsck's result code on > failure actually is -1? Or any other value? Or does initlog (via which > fsck is called) somehow change the result value? It shouldn't change it, no. Bill From leonard at den.ottolander.nl Thu Feb 5 15:46:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 16:46:44 +0100 Subject: fsck (or initlog) result codes In-Reply-To: <20040205153013.GC31385@devserv.devel.redhat.com> References: <1075990419.4747.66.camel@athlon.localdomain> <20040205153013.GC31385@devserv.devel.redhat.com> Message-ID: <1075996003.4747.70.camel@athlon.localdomain> Hello Bill, > > With an fsck result code of 3 however the system passes the next fsck > > with no errors whatsoever. Could it be that fsck's result code on > > failure actually is -1? Or any other value? Or does initlog (via which > > fsck is called) somehow change the result value? > > It shouldn't change it, no. So any idea why the fsck fails although no errors are left on the file system? Is the fsck failure code -1 instead of any positive integer larger than 1? You might understand that I am not willing to fsck up this file system as much that it "really" fails (ie still contains errors after the initial fsck). Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From notting at redhat.com Thu Feb 5 15:53:40 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Feb 2004 10:53:40 -0500 Subject: fsck (or initlog) result codes In-Reply-To: <1075996003.4747.70.camel@athlon.localdomain> References: <20040205153013.GC31385@devserv.devel.redhat.com> <1075996003.4747.70.camel@athlon.localdomain> Message-ID: <20040205155339.GF31385@devserv.devel.redhat.com> Leonard den Ottolander (leonard at den.ottolander.nl) said: > > > With an fsck result code of 3 however the system passes the next fsck > > > with no errors whatsoever. Could it be that fsck's result code on > > > failure actually is -1? Or any other value? Or does initlog (via which > > > fsck is called) somehow change the result value? > > > > It shouldn't change it, no. > > So any idea why the fsck fails although no errors are left on the file > system? Not off the top of my head without looking at the source code. Bill From leonard at den.ottolander.nl Thu Feb 5 15:59:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 16:59:41 +0100 Subject: fsck (or initlog) result codes In-Reply-To: <20040205155339.GF31385@devserv.devel.redhat.com> References: <20040205153013.GC31385@devserv.devel.redhat.com> <1075996003.4747.70.camel@athlon.localdomain> <20040205155339.GF31385@devserv.devel.redhat.com> Message-ID: <1075996781.4747.76.camel@athlon.localdomain> Hi Bill, > > > > Could it be that fsck's result code on > > > > failure actually is -1? Or any other value? > > Not off the top of my head without looking at the source code. Does anybody else can answer this to save me the time to look it up? TIA, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From tdiehl at rogueind.com Thu Feb 5 16:09:04 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 5 Feb 2004 11:09:04 -0500 (EST) Subject: Sound in rawhide Message-ID: Hi, Can anyone tell me if soundcard support in rawhide is supposed to be working? I have a machine that the soundcard worked under FC1 but on rawhide I get unable to load driver snd-via82_xx when I try to test the soundcard using the config-soundcard thing. FWIW, The kernel modules appear to be loaded. If this is something I should bugzilla what component should I list it against? I tried searching bugzilla but found nothing. TIA, ...Tom From leonard at den.ottolander.nl Thu Feb 5 16:15:12 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 17:15:12 +0100 Subject: fsck (or initlog) result codes In-Reply-To: <20040205155339.GF31385@devserv.devel.redhat.com> References: <20040205153013.GC31385@devserv.devel.redhat.com> <1075996003.4747.70.camel@athlon.localdomain> <20040205155339.GF31385@devserv.devel.redhat.com> Message-ID: <1075997711.4747.87.camel@athlon.localdomain> Hello Bill, > Not off the top of my head without looking at the source code. fsck.h reads: #define EXIT_OK 0 #define EXIT_NONDESTRUCT 1 #define EXIT_DESTRUCT 2 #define EXIT_UNCORRECTED 4 #define EXIT_ERROR 8 #define EXIT_USAGE 16 #define EXIT_LIBRARY 128 but a grep -lr EXIT_DESTRUCT in the root of the build tree renders misc/fsck.h as the only result. Now how can the exit status be 3 in that case? This obviously needs further investigation unless somebody can give me some answers. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From alan at redhat.com Thu Feb 5 16:14:57 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 5 Feb 2004 11:14:57 -0500 Subject: Fedora related In-Reply-To: <4898.203.197.151.51.1075960343.mailer@mail.rajagiritech.ac.in> References: <4898.203.197.151.51.1075960343.mailer@mail.rajagiritech.ac.in> Message-ID: <20040205161457.GA4790@devserv.devel.redhat.com> On Thu, Feb 05, 2004 at 11:22:23AM +0530, jeffrin_jose at rajagiritech.ac.in wrote: > Do Fedora have any policy to take software into it ? > If yes, please tell me if possible that,do they include > only Free software according to the definition of FSF > for free software. See About on the fedora.redhat.com website From jkeating at j2solutions.net Thu Feb 5 16:19:31 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 5 Feb 2004 08:19:31 -0800 Subject: Test Update Tracking proposal In-Reply-To: <4021E779.4010307@redhat.com> References: <4021E779.4010307@redhat.com> Message-ID: <200402050819.32431.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 February 2004 22:49, Warren Togami wrote: > The best part of what these tracking reports is something like this: > http://www.fedora.us/NEEDSWORK > http://www.fedora.us/PUBLISH > http://www.fedora.us/LEGACY > > At any time, a site visitor can quickly use pre-set queries like these > and immediately see the status of all Test Updates. If they run into a > bug, they can quickly see if the package is already fixed and only > needing functionality testing. All without sifting through the heavy > traffic of mailing lists. One thing that would need to be enforced for > this to work is strong discouragement of discussion within the Tracking > reports. Only definite findings should be posted within there. > Discussions on lists only. > > For this easy-and-quick query ability, we could use the Developer > Whiteboard, but I am requesting a permanent keyword like "UPDATE". The > pre-set query can search for "Fedora Core", "1", and keyword "UPDATE" > and display everything. > > Thoughts? As somebody who uses the LEGACY tracker very heavily, it's invaluable to me and to the fedora legacy group. I very +1 this idea. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) 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.3 (GNU/Linux) iD8DBQFAIm0T4v2HLvE71NURAh1DAKCvLb6OJ7whAS67T6hurS87ra4knwCfRCAj YUOoUacxf84/RNXQI+wkaCQ= =zWon -----END PGP SIGNATURE----- From leonard at den.ottolander.nl Thu Feb 5 16:21:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 17:21:14 +0100 Subject: fsck (or initlog) result codes In-Reply-To: <1075996781.4747.76.camel@athlon.localdomain> References: <20040205153013.GC31385@devserv.devel.redhat.com> <1075996003.4747.70.camel@athlon.localdomain> <20040205155339.GF31385@devserv.devel.redhat.com> <1075996781.4747.76.camel@athlon.localdomain> Message-ID: <1075998074.4747.91.camel@athlon.localdomain> Hi, > > > > > Could it be that fsck's result code on > > > > > failure actually is -1? Or any other value? > > > > Not off the top of my head without looking at the source code. > > Does anybody else can answer this to save me the time to look it up? Duh. Looking at the man page often helps ;) : 1: file system errors corrected 2: needs rebooting Still wonder where that "needs rebooting" is set, since EXIT_DESTRUCT is not used in the code. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From notting at redhat.com Thu Feb 5 16:27:37 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Feb 2004 11:27:37 -0500 Subject: Sound in rawhide In-Reply-To: References: Message-ID: <20040205162737.GC4443@devserv.devel.redhat.com> Tom Diehl (tdiehl at rogueind.com) said: > Can anyone tell me if soundcard support in rawhide is supposed > to be working? yes. > I have a machine that the soundcard worked under FC1 but > on rawhide I get unable to load driver snd-via82_xx when I try to test > the soundcard using the config-soundcard thing. What's the specific error? Bill From leonard at den.ottolander.nl Thu Feb 5 16:39:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 05 Feb 2004 17:39:36 +0100 Subject: fsck (or initlog) result codes In-Reply-To: <1075998074.4747.91.camel@athlon.localdomain> References: <20040205153013.GC31385@devserv.devel.redhat.com> <1075996003.4747.70.camel@athlon.localdomain> <20040205155339.GF31385@devserv.devel.redhat.com> <1075996781.4747.76.camel@athlon.localdomain> <1075998074.4747.91.camel@athlon.localdomain> Message-ID: <1075999176.4747.100.camel@athlon.localdomain> Hi, I figured it out. > Still wonder where that "needs rebooting" is set, since EXIT_DESTRUCT is > not used in the code. In e2fsck/e2fsck.h FSCK_REBOOT is defined (also in lib/evms/fsimext2.h), also with value 2. Look like redundant defines, but maybe there is a reason not to include e2fsck.h in fsimext2.h. Now in e2fsck/unix.c the exit status always gets or-ed with FSCK_REBOOT when the changed file system is the root file system. Why is this necessary? Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From katzj at redhat.com Thu Feb 5 17:19:12 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 05 Feb 2004 12:19:12 -0500 Subject: Will FC2 move towards mdadm for all software raid config In-Reply-To: <1075982265.7026.569.camel@locutus> References: <20040204093205.GE27591@outblaze.com> <20040204164138.GA32762@outblaze.com> <200402041427.07634.jkeating@j2solutions.net> <1075982265.7026.569.camel@locutus> Message-ID: <1076001551.11840.3.camel@mirkwood.boston.redhat.com> On Thu, 2004-02-05 at 04:57 -0700, Bill Anderson wrote: > > On Wednesday 04 February 2004 08:41, Yusuf Goolamabbas wrote: > > > So FC2 will still use /etc/raidtab to configure software-raid ? > > > Would FC2 boot-up sequence (post-install) ever understand > > > /etc/mdadm.conf ? > > > > Seth Vidal and a few other people are doing the work necessary to get > > FC2 mdadm ready. As mentioned the big blocker currently is modifying > > anaconda to use mdadm instead of raidtools. The userland changes are > > minimal. If you know python, ping Jeremy Katz. > > Is he on the list? If so .. PING. > :) Of course I am. > I'm pretty good with Python, but have yet to dig into Anaconda. Jeremy, > if this isn't something you need to know Anaconda source very well for > (or something a non-Anaconda source Python guy could deal with), let me > know, I'll do what I can. It shouldn't be too terribly difficult, although the hard part is testing it and making sure it all works :-) anaconda-devel-list has a couple of posts from me describing how to use an updates.img for easier testing (basic summary: make an ext2 image, drop it as Fedora/base/ updates.img, mount via loopback, copy updated python files there). The basic idea of what needs changing is to look at the RAID stuff in fsset.py and convert it over from using the various raid-tools commands to using mdadm based ones. Also, there might be some changes needed in raid.py, but I doubt it (since raid.py mostly just works with the underlying ioctls) Cheers, Jeremy From ghenry at suretecsystems.com Thu Feb 5 17:34:24 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 5 Feb 2004 17:34:24 +0000 Subject: rpm --addsign problems In-Reply-To: <1075993915.6773.2.camel@localhost.localdomain> References: <200402051140.18408.ghenry@suretecsystems.com> <1075993915.6773.2.camel@localhost.localdomain> Message-ID: <200402051734.25877.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 05 February 2004 15:11, Michel Alexandre Salim wrote: > On Thu, 2004-02-05 at 11:40 +0000, Gavin Henry wrote: > [snip] > > > I am trying to sign a SRPM, but issuing rpm --addsign (according to > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) > > comes up blank. > > If you followed that document and built the package as a different user > from the user that is signing the source RPM, have you chown the file? > You can't sign a package you don't have write access to, naturally. > > HTH, > > Michel I used Mach to build it and also did it with fedora-develtools and the rpms are owned by (chown) It must be a ~/.rpmrc your /etc/rpm/macro* thing? - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIn6geWseh9tzvqgRAlyrAJ9SIpZTV/hJ+igDkbKovL2HAeg49ACcCYfu Y8SRDHu91XI7Ns3lj6EaRvs= =V7V/ -----END PGP SIGNATURE----- From jspaleta at princeton.edu Thu Feb 5 17:40:02 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Thu, 05 Feb 2004 12:40:02 -0500 Subject: Test Update Tracking proposal Message-ID: <1076002802.13198.88.camel@spatula.pppl.gov> Jesse Keating wrote: > As somebody who uses the LEGACY tracker very heavily, it's > invaluable to me and to the fedora legacy group. I very +1 this > idea. Hmmm....I want to broaden the discussion at some point...soon about the best way to use trackers for the larger triage effort. But I think I'm going to have to wait till this weekend before I launch into a long article on the topic. Ugh...and how Core triage and Legacy are going to interact if/when Core triage looks at older rhl bugreports. -jef"pretty sure im going to break my personal 2 post limit per thread rule on this thread since its directly triage related"spaleta From mark at harddata.com Thu Feb 5 17:44:24 2004 From: mark at harddata.com (Mark) Date: Thu, 5 Feb 2004 10:44:24 -0700 Subject: 32 Bit Mozilla issue Message-ID: <200402051044.02171.mark@harddata.com> I am running x86_64 from Rawhide. I did some upgrading to the rawhide packages and Mozilla-1.6 worked for a day and then stopped. I guess one of older libs must have been still in memory or something. here's my strace of mozilla-bin [mark at skip mark]$ strace /usr/lib/mozilla-1.6/mozilla-bin execve("/usr/lib/mozilla-1.6/mozilla-bin", ["/usr/lib/mozilla-1.6/mozilla-bin"], [/* 41 vars */]) = 0 [ Process PID=6600 runs in 32 bit mode. ] (mozilla-bin:6600): Gtk-WARNING **: Unable to locate theme engine in module_path: "bluecurve", /usr/lib/mozilla-1.6/mozilla-bin: relocation error: /usr/lib/mozilla-1.6/components/libnecko.so: undefined symbol: PR_GetAddrInfoByName Any ideas? I don't even know what lib should be exporting PR_GetAddrInfoByName -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From tdiehl at rogueind.com Thu Feb 5 20:32:27 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 5 Feb 2004 15:32:27 -0500 (EST) Subject: Sound in rawhide In-Reply-To: <20040205162737.GC4443@devserv.devel.redhat.com> References: <20040205162737.GC4443@devserv.devel.redhat.com> Message-ID: On Thu, 5 Feb 2004, Bill Nottingham wrote: > Tom Diehl (tdiehl at rogueind.com) said: > > > I have a machine that the soundcard worked under FC1 but > > on rawhide I get unable to load driver snd-via82_xx when I try to test > > the soundcard using the config-soundcard thing. > > What's the specific error? When I goto system settings -> soundcard detection -> play test sound. I get "The snd-via82xx driver could not be loaded. This soundcard may not be compatible with Red Hat Linux". Come to think of it looks like someone missed editing an error message. ;) FWIW this is a fresh install of rawhide yesterday and the partitions were formatted. I do not get any sound and an lsmod shows the modules are loaded: [root at fc root]# lsmod Module Size Used by snd_pcm_oss 52900 0 ide_cd 39428 0 cdrom 37020 1 ide_cd snd_mixer_oss 18304 2 snd_pcm_oss snd_via82xx 27104 1 snd_pcm 111880 2 snd_pcm_oss,snd_via82xx snd_timer 32388 1 snd_pcm snd_ac97_codec 52612 1 snd_via82xx snd_page_alloc 11652 2 snd_via82xx,snd_pcm snd_mpu401_uart 9984 1 snd_via82xx snd_rawmidi 28832 1 snd_mpu401_uart snd_seq_device 8328 1 snd_rawmidi snd 55012 9 snd_pcm_oss,snd_mixer_oss,snd_via82xx,snd_pcm,snd_timer,snd_ac97_codec,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 10720 2 snd md5 4224 1 ipv6 263552 8 lp 12652 0 autofs 16512 0 3c59x 39848 0 8139too 30208 0 mii 5120 1 8139too ohci1394 41860 0 ieee1394 284464 1 ohci1394 floppy 65712 0 sg 36120 0 scsi_mod 124600 1 sg parport_pc 39724 1 parport 47336 2 lp,parport_pc uhci_hcd 42896 0 usbcore 119388 3 uhci_hcd thermal 13200 0 processor 13988 1 thermal fan 4108 0 button 6168 0 battery 8972 0 asus_acpi 9368 0 ac 4876 0 ext3 128424 7 jbd 86040 1 ext3 [root at fc root]# Do you want this in bugzilla and if so under which component?? Tom From mattdm at mattdm.org Thu Feb 5 21:53:26 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 5 Feb 2004 16:53:26 -0500 Subject: FHS 2.3? In-Reply-To: <200402042244.24575.ronny-vlug@vlugnet.org> References: <20040204165357.GW25654@redhat.com> <200402042244.24575.ronny-vlug@vlugnet.org> Message-ID: <20040205215326.GA25780@jadzia.bu.edu> On Wed, Feb 04, 2004 at 10:44:24PM +0100, Ronny Buchmann wrote: > I would really like it, especially the /media, /mnt, /srv and /usr/src stuff. Hey!!! /srv! I hadn't looked at the new FHS release, but that pretty much makes my day. Cool -- /var/www has always grated on me. I'm not so sure I agree about the /media vs. /mnt/subdir thing, but I don't care so much. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dax at gurulabs.com Thu Feb 5 22:40:58 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 05 Feb 2004 15:40:58 -0700 Subject: Sound in rawhide In-Reply-To: References: <20040205162737.GC4443@devserv.devel.redhat.com> Message-ID: <1076020858.2825.7.camel@mentor.gurulabs.com> On Thu, 2004-02-05 at 13:32, Tom Diehl wrote: > I do not get any sound and an lsmod shows the modules are loaded: ALSA defaults to muted. Run alsamixer and see if you have "MM" at the top of the "Master" or "PCM" channel. Using alsamixer the "m" key can toggle muted or not and up/down arrow keys change the volume. Dax Kelson From dax at gurulabs.com Thu Feb 5 23:08:53 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 05 Feb 2004 16:08:53 -0700 Subject: FHS 2.3? In-Reply-To: <20040204165357.GW25654@redhat.com> References: <20040204165357.GW25654@redhat.com> Message-ID: <1076022533.2825.35.camel@mentor.gurulabs.com> On Wed, 2004-02-04 at 09:53, Tim Waugh wrote: > Do we intend to implement the new bits of FHS for Fedora Core 2? For > instance, there is now wording about /usr/share/xml. FWIW, I noticed that SUSE9 uses /srv for Apache and . Other than the major pain in changing to /srv, it seems like a good idea. Better for backup, sizing, and LVM than: /var/www/ /var/ftp/ /var/lib/mysql/ /var/lib/pgsql/ blah blah Dax From pri.rhl1 at iadonisi.to Thu Feb 5 23:19:07 2004 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: Thu, 05 Feb 2004 18:19:07 -0500 Subject: Sound in rawhide In-Reply-To: <1076020858.2825.7.camel@mentor.gurulabs.com> References: <20040205162737.GC4443@devserv.devel.redhat.com> <1076020858.2825.7.camel@mentor.gurulabs.com> Message-ID: <1076023146.13238.27.camel@va.local.linuxlobbyist.org> On Thu, 2004-02-05 at 17:40, Dax Kelson wrote: > ALSA defaults to muted. > > Run alsamixer and see if you have "MM" at the top of the "Master" or No dice. I'm having the same problem and running alsamixer yields the following message: alsamixer: function snd_ctl_open failed for default: No such file or directory FWIW, clicking on the volume applet in my gnome panel gives a "Couldn't open mixer device /dev/sound/mixer" and sure enough, there is no /dev/sound/mixer device file. Do I need an updated dev package? Need to create the node manually? Are my modprobe.conf settings correct? Relevant lines of /etc/modprobe.conf: alias sound-slot-0 snd-ymfpci install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : -- -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 mark at harddata.com Thu Feb 5 23:36:30 2004 From: mark at harddata.com (Mark) Date: Thu, 5 Feb 2004 16:36:30 -0700 Subject: Sound in rawhide In-Reply-To: <1076023146.13238.27.camel@va.local.linuxlobbyist.org> References: <1076020858.2825.7.camel@mentor.gurulabs.com> <1076023146.13238.27.camel@va.local.linuxlobbyist.org> Message-ID: <200402051636.30048.mark@harddata.com> On February 05, 2004 04:19 pm, Paul Iadonisi wrote: > On Thu, 2004-02-05 at 17:40, Dax Kelson wrote: > > ALSA defaults to muted. > > > > Run alsamixer and see if you have "MM" at the top of the "Master" or > > No dice. I'm having the same problem and running alsamixer yields the > following message: > I am having some problems with my Athlon64 box as well. But since I am not running the Rawhide kernel but a custom one, it may be a problem with the alsa libs or something. It was working and stopped. Interestly enough that's not the first time I have seen alsa do that. -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From leonard at den.ottolander.nl Fri Feb 6 00:25:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 06 Feb 2004 01:25:46 +0100 Subject: Test Update Tracking proposal In-Reply-To: <1076002802.13198.88.camel@spatula.pppl.gov> References: <1076002802.13198.88.camel@spatula.pppl.gov> Message-ID: <1076027146.4870.36.camel@athlon.localdomain> Hello Jef, > Ugh...and how Core triage and Legacy > are going to interact if/when Core triage looks > at older rhl bugreports. Looking at older RHL bug reports is not as silly as it might look at first (although I must say I started from the bottom as I expected 10 people to be working from the top :). Some of those issues still have a bearing on the current state of affairs. See fe https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115028 in relation to #53003. Maybe not a very strong example, but I do agree with the original poster that the used phrasing can be somewhat confusing. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dax at gurulabs.com Fri Feb 6 00:57:39 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 05 Feb 2004 17:57:39 -0700 Subject: Sound in rawhide In-Reply-To: <1076023146.13238.27.camel@va.local.linuxlobbyist.org> References: <20040205162737.GC4443@devserv.devel.redhat.com> <1076020858.2825.7.camel@mentor.gurulabs.com> <1076023146.13238.27.camel@va.local.linuxlobbyist.org> Message-ID: <1076029059.2825.45.camel@mentor.gurulabs.com> On Thu, 2004-02-05 at 16:19, Paul Iadonisi wrote: > On Thu, 2004-02-05 at 17:40, Dax Kelson wrote: > > > ALSA defaults to muted. > > > > Run alsamixer and see if you have "MM" at the top of the "Master" or > > No dice. I'm having the same problem and running alsamixer yields the > following message: > > alsamixer: function snd_ctl_open failed for default: No such file or > directory > > FWIW, clicking on the volume applet in my gnome panel gives a "Couldn't > open mixer device /dev/sound/mixer" and sure enough, there is no > /dev/sound/mixer device file. Do I need an updated dev package? Need > to create the node manually? Are my modprobe.conf settings correct? What output do you get with the following commands? cat /proc/asound/version cat /proc/asound/cards cat /proc/asound/devices cat /proc/asound/oss-devices cat /proc/asound/timers cat /proc/asound/pcm BTW, I'm running a 2.6 kernel on FC1 (not rawhide), and here is what I put in my /etc/modprobe.conf: # ALSA portion alias char-major-116 snd alias snd-card-0 snd-intel8x0 # OSS/Free portion alias char-major-14 soundcore alias sound-slot-0 snd-card-0 # card #1 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss Here is my /etc/asound.conf # # ALSA voodoo # pcm.!default { type plug slave.pcm "dmixer" } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.dmixer { type hw card 0 } pcm.intel8x0 { type hw card 0 } ctl.intel8x0 { type hw card 0 } From salimma at fastmail.fm Fri Feb 6 01:48:59 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Fri, 06 Feb 2004 08:48:59 +0700 Subject: rpm --addsign problems In-Reply-To: <200402051734.25877.ghenry@suretecsystems.com> References: <200402051140.18408.ghenry@suretecsystems.com> <1075993915.6773.2.camel@localhost.localdomain> <200402051734.25877.ghenry@suretecsystems.com> Message-ID: <1076032139.2931.1.camel@localhost.localdomain> On Thu, 2004-02-05 at 17:34 +0000, Gavin Henry wrote: [snip] > > > I am trying to sign a SRPM, but issuing rpm --addsign (according to > > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) > > > comes up blank. [snip] > I used Mach to build it and also did it with fedora-develtools and the rpms > are owned by (chown) > > It must be a ~/.rpmrc your /etc/rpm/macro* thing? > Ah, did not notice that. I think ~/.rpmrc is deprecated; try renaming it to ~/.rpmmacros ? Here's mine: [michel at bushido michel]$ cat .rpmmacros %packager Michel Alexandre Salim %_signature gpg %_gpg_name salimma at users.sourceforge.net HTH, 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 surak at surak.eti.br Fri Feb 6 02:06:06 2004 From: surak at surak.eti.br (Alexandre Strube) Date: Thu, 05 Feb 2004 23:06:06 -0300 Subject: fsck (or initlog) result codes In-Reply-To: <1075990419.4747.66.camel@athlon.localdomain> References: <1075990419.4747.66.camel@athlon.localdomain> Message-ID: <1076033165.4548.18.camel@casa> Em Qui, 2004-02-05 ?s 11:13, Leonard den Ottolander escreveu: > After an unclean shutdown and an apparently succesful fsck (no errors > are reported during the fsck after the reboot) I am still forced to > reboot the system. This is preety annoying - happens here when my mother thinks this computer is locked and she presses the reset button. Most of the time the /etc/fstab file disappears, and fsck can't repair filesystem by itself (not /etc/fstab, I'm talking about inconcistencies) -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From dax at gurulabs.com Fri Feb 6 02:31:50 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 05 Feb 2004 19:31:50 -0700 Subject: Prelink hosed my binaries? In-Reply-To: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> References: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <1076034710.6543.2.camel@mentor.gurulabs.com> On Sun, 2004-02-01 at 08:06, Steve Bergman wrote: > Anyone else wake up to a totally hosed system this morning? A > substantial portion of my binaries (including bash) are wrecked and show > up as "data" when I use the "file" command on them. No ELF header at > all. > > Everything was fine last night. I'm assuming prelink was the culprit. > However, last time prelink was updated was 2 days ago, not 1, so last > night would have been the second time it was run, not the first. > Weird... Interesting.... A couple days ago my co-worker was telling me that he turned on his previously fine FCv1 laptop and most of his binaries were hosed. On examination the binaries had log files (/var/log/*) contents interspersed through them. He reinstalled. It could be complete unrelated of course. Dax Kelson From tdiehl at rogueind.com Fri Feb 6 02:30:07 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 5 Feb 2004 21:30:07 -0500 (EST) Subject: Sound in rawhide In-Reply-To: <1076020858.2825.7.camel@mentor.gurulabs.com> References: <20040205162737.GC4443@devserv.devel.redhat.com> <1076020858.2825.7.camel@mentor.gurulabs.com> Message-ID: On Thu, 5 Feb 2004, Dax Kelson wrote: > On Thu, 2004-02-05 at 13:32, Tom Diehl wrote: > > I do not get any sound and an lsmod shows the modules are loaded: > > ALSA defaults to muted. > > Run alsamixer and see if you have "MM" at the top of the "Master" or > "PCM" channel. Using alsamixer the "m" key can toggle muted or not and > up/down arrow keys change the volume. I checked that before I posted. It was indeed muted but unmuting it and turning it all the way up did not help. Seems like kind of a weird default but none the less that is not the problem in my case. Tom From lbudai at ms.sapientia.ro Fri Feb 6 07:56:12 2004 From: lbudai at ms.sapientia.ro (Budai Laszlo) Date: Fri, 06 Feb 2004 09:56:12 +0200 Subject: fedora and kernel 2.6.1 Message-ID: <4023489C.6070609@ms.sapientia.ro> Hello, I'm trying to compile the 2.6.1 kernel on Cedora Core 1. I've downloaded the source from kernel.org, and try to follow the readme for installing. a did make menuconfig, select the things I need (ex3 extended attributes and posix ACL among them), then make, make bzImage, make modules make modules_install, make install. Before make install I've loaded the loop kernel module. When I try to boot the new kernel it hangs with the folloving error: VFS: cannot open root device "LABEL=/" or unknown-block (0,0) Please append a correct "root=" boot option Kernel panic: VFS: unable to mount root fs on unknown-block (0,0) I did try to specify root=0803 in grub.conf but the message now is: VFS: cannot open root device "0803" or unknown-block (8,3) Please append a correct "root=" boot option Kernel panic: VFS: unable to mount root fs on unknown-block (8,3) What can be done? thank you, Laszlo From teg at pvv.org Fri Feb 6 08:43:28 2004 From: teg at pvv.org (Trond Eivind =?ISO-8859-1?Q?Glomsr=F8d?=) Date: Fri, 06 Feb 2004 09:43:28 +0100 Subject: FHS 2.3? In-Reply-To: <1076022533.2825.35.camel@mentor.gurulabs.com> References: <20040204165357.GW25654@redhat.com> <1076022533.2825.35.camel@mentor.gurulabs.com> Message-ID: <1076057008.10738.0.camel@pc-32.office.scali.no> On Fri, 2004-02-06 at 00:08, Dax Kelson wrote: > On Wed, 2004-02-04 at 09:53, Tim Waugh wrote: > > Do we intend to implement the new bits of FHS for Fedora Core 2? For > > instance, there is now wording about /usr/share/xml. > > FWIW, I noticed that SUSE9 uses /srv for Apache and . It's been used by some distributions in violation of FHS for a while (it stated not to add extra dirs to /) From mharris at redhat.com Fri Feb 6 09:24:57 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 6 Feb 2004 04:24:57 -0500 (EST) Subject: FHS 2.3? In-Reply-To: <1076057008.10738.0.camel@pc-32.office.scali.no> References: <20040204165357.GW25654@redhat.com> <1076022533.2825.35.camel@mentor.gurulabs.com> <1076057008.10738.0.camel@pc-32.office.scali.no> Message-ID: On Fri, 6 Feb 2004, Trond Eivind [ISO-8859-1] Glomsr?d wrote: >> > Do we intend to implement the new bits of FHS for Fedora Core 2? For >> > instance, there is now wording about /usr/share/xml. >> >> FWIW, I noticed that SUSE9 uses /srv for Apache and . > >It's been used by some distributions in violation of FHS for a while (it >stated not to add extra dirs to /) And if those distributions were LSB compliant, then one is to assume that distros that do not switch to using /srv must be LSB compliant also. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ghenry at suretecsystems.com Fri Feb 6 09:59:18 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 09:59:18 -0000 (GMT) Subject: rpm --addsign problems In-Reply-To: <1076032139.2931.1.camel@localhost.localdomain> References: <200402051140.18408.ghenry@suretecsystems.com><1075993915.6773.2.camel@localhost.localdomain><200402051734.25877.ghenry@suretecsystems.com> <1076032139.2931.1.camel@localhost.localdomain> Message-ID: <44606.193.195.148.66.1076061558.squirrel@www.suretecsystems.com> > On Thu, 2004-02-05 at 17:34 +0000, Gavin Henry wrote: > [snip] >> > > I am trying to sign a SRPM, but issuing rpm --addsign (according to >> > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) >> > > comes up blank. > [snip] >> I used Mach to build it and also did it with fedora-develtools and the >> rpms >> are owned by (chown) >> >> It must be a ~/.rpmrc your /etc/rpm/macro* thing? >> > Ah, did not notice that. I think ~/.rpmrc is deprecated; try renaming it > to ~/.rpmmacros ? > > Here's mine: > [michel at bushido michel]$ cat .rpmmacros > %packager Michel Alexandre Salim > > %_signature gpg > %_gpg_name salimma at users.sourceforge.net > > HTH, > > Michel > Great, thank you, that was it. I might update the fedora.us wiki with this info and a wee howto on FedoraNEWS.org?? Gavin. -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com From makgab at freemail.hu Fri Feb 6 10:25:51 2004 From: makgab at freemail.hu (MG) Date: Fri, 06 Feb 2004 11:25:51 +0100 (CET) Subject: umount filesystems crash... In-Reply-To: <20040129132506.19486.77472.Mailman@listman.back-rdu.redhat.com> Message-ID: On 29-Jan-2004 fedora-devel-list-request at redhat.com wrote: > From: "Gene C." > Subject: Re: umount filesystems crach... > I have seen umount hangs (but not so far with the latest kernel). See: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109962 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112861 > -- > Gene > Sometimes umount crashes. It occurs at floppy, hdd, nfs. Is it BUG? :(( Bye! Gabor From salimma at fastmail.fm Fri Feb 6 08:10:31 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Fri, 06 Feb 2004 15:10:31 +0700 Subject: fedora and kernel 2.6.1 In-Reply-To: <4023489C.6070609@ms.sapientia.ro> References: <4023489C.6070609@ms.sapientia.ro> Message-ID: <1076055031.9939.2.camel@localhost.localdomain> On Fri, 2004-02-06 at 09:56 +0200, Budai Laszlo wrote: > Hello, > > I'm trying to compile the 2.6.1 kernel on Cedora Core 1. I've downloaded > the source from kernel.org, and try to follow the readme for installing From nphilipp at redhat.com Fri Feb 6 11:05:36 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 06 Feb 2004 12:05:36 +0100 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: Message-ID: <1076065536.6676.7.camel@wombat.tiptoe.de> Having been nudged politely, I'll respond now (albeit a bit late). On Mon, 2004-02-02 at 06:09, Mike A. Harris wrote: > Proposed Solution: > > After much thought, my own proposed solution, is to do the > following: > > - Create a number of new "virtual Provides:" in the XFree86 rpm > spec file in the XFree86-libs and XFree86-devel packages > respectively. Essentially there would be one new virtual > provide for each library, and perhaps for developmental > utilities necessary for X development also, which are presently > in XFree86-devel. Full ACK, this could be even extended into adjacent areas, e.g. Mesa libs which once were in their own package and now are in XFree86-libs-GL or whatever -- and who knows where they will be when having fd.o libs becomes en vogue? There might even be more packages where this could be applied to: e.g. GLUT <-> freeglut, ImageMagick <-> GraphicsMagick, ... whereever there are alternative libraries that can be used. Sorry for not having found any quirks in your proposal ;-). "Me too", 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 ghenry at suretecsystems.com Fri Feb 6 11:07:13 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 11:07:13 -0000 (GMT) Subject: rpm --addsign problems In-Reply-To: <1076032139.2931.1.camel@localhost.localdomain> References: <200402051140.18408.ghenry@suretecsystems.com><1075993915.6773.2.camel@localhost.localdomain><200402051734.25877.ghenry@suretecsystems.com> <1076032139.2931.1.camel@localhost.localdomain> Message-ID: <49191.193.195.148.66.1076065633.squirrel@www.suretecsystems.com> > On Thu, 2004-02-05 at 17:34 +0000, Gavin Henry wrote: > [snip] >> > > I am trying to sign a SRPM, but issuing rpm --addsign (according to >> > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) >> > > comes up blank. > [snip] >> I used Mach to build it and also did it with fedora-develtools and the >> rpms >> are owned by (chown) >> >> It must be a ~/.rpmrc your /etc/rpm/macro* thing? >> > Ah, did not notice that. I think ~/.rpmrc is deprecated; try renaming it > to ~/.rpmmacros ? > > Here's mine: > [michel at bushido michel]$ cat .rpmmacros > %packager Michel Alexandre Salim > > %_signature gpg > %_gpg_name salimma at users.sourceforge.net > > HTH, > > Michel > Thanks that was it. I think I might update the fedora.us wiki with this info and maybe a wee howto on fedoranews.org for rpm siging etc. Gavin. -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com From buildsys at redhat.com Fri Feb 6 11:48:08 2004 From: buildsys at redhat.com (Build System) Date: Fri, 6 Feb 2004 06:48:08 -0500 Subject: rawhide report: 20040206 changes Message-ID: <200402061148.i16Bm8x19404@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20040206 ---------------------------- From chiodr at kscems.ksc.nasa.gov Fri Feb 6 12:10:40 2004 From: chiodr at kscems.ksc.nasa.gov (Bob Chiodini) Date: Fri, 06 Feb 2004 07:10:40 -0500 Subject: fedora and kernel 2.6.1 In-Reply-To: <4023489C.6070609@ms.sapientia.ro> References: <4023489C.6070609@ms.sapientia.ro> Message-ID: <1076069440.23538.35.camel@tweedy.ksc.nasa.gov> On Fri, 2004-02-06 at 02:56, Budai Laszlo wrote: > Hello, > > I'm trying to compile the 2.6.1 kernel on Cedora Core 1. I've downloaded > the source from kernel.org, and try to follow the readme for installing. > a did make menuconfig, select the things I need (ex3 extended > attributes and posix ACL among them), then make, make bzImage, make > modules make modules_install, make install. > Before make install I've loaded the loop kernel module. > When I try to boot the new kernel it hangs with the folloving error: > > VFS: cannot open root device "LABEL=/" or unknown-block (0,0) > Please append a correct "root=" boot option > Kernel panic: VFS: unable to mount root fs on unknown-block (0,0) > > I did try to specify root=0803 in grub.conf but the message now is: VFS: > cannot open root device "0803" or unknown-block (8,3) > Please append a correct "root=" boot option > Kernel panic: VFS: unable to mount root fs on unknown-block (8,3) > > What can be done? > > > thank you, > Laszlo In grub.conf, try changing LABEL=/ to the real device name (e.g. /dev/hda1) of your / partition. Something like: kernel /vmlinuz-2.6.2 ro root=/dev/hda1 However labels work okay for me with the 2.6.2 kernel. Bob... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbudai at ms.sapientia.ro Fri Feb 6 12:20:48 2004 From: lbudai at ms.sapientia.ro (Budai Laszlo) Date: Fri, 06 Feb 2004 14:20:48 +0200 Subject: fedora and kernel 2.6.1 In-Reply-To: <1076069440.23538.35.camel@tweedy.ksc.nasa.gov> References: <4023489C.6070609@ms.sapientia.ro> <1076069440.23538.35.camel@tweedy.ksc.nasa.gov> Message-ID: <402386A0.1060705@ms.sapientia.ro> > > In grub.conf, try changing LABEL=/ to the real device name (e.g. > /dev/hda1) of your / partition. Something like: > > kernel /vmlinuz-2.6.2 ro root=/dev/hda1 > > > However labels work okay for me with the 2.6.2 kernel. > > Bob... I did try: kernel /vmlinuz-2.6.1 ro root=/dev/sda3 but still the same ... :( I don't know maybe something else is wrong. I keep digging. Laszlo From Nigel.Metheringham at dev.InTechnology.co.uk Fri Feb 6 12:28:24 2004 From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham) Date: Fri, 06 Feb 2004 12:28:24 +0000 Subject: fedora and kernel 2.6.1 In-Reply-To: <4023489C.6070609@ms.sapientia.ro> References: <4023489C.6070609@ms.sapientia.ro> Message-ID: <1076070504.20777.47.camel@angua.localnet> I'm not clear on whether you have things built into the kernel or built as modules. However recently when I have seen that sort of problem its often been down to a broken mkinitrd. It might be worth checking you have a recent version. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jkt at redhat.com Fri Feb 6 12:44:53 2004 From: jkt at redhat.com (Jay Turner) Date: Fri, 6 Feb 2004 07:44:53 -0500 Subject: fedora and kernel 2.6.1 In-Reply-To: <4023489C.6070609@ms.sapientia.ro> References: <4023489C.6070609@ms.sapientia.ro> Message-ID: <20040206124453.GC32455@redhat.com> On Fri, Feb 06, 2004 at 09:56:12AM +0200, Budai Laszlo wrote: > Hello, > > I'm trying to compile the 2.6.1 kernel on Cedora Core 1. I've downloaded > the source from kernel.org, and try to follow the readme for installing. > a did make menuconfig, select the things I need (ex3 extended > attributes and posix ACL among them), then make, make bzImage, make > modules make modules_install, make install. > Before make install I've loaded the loop kernel module. > When I try to boot the new kernel it hangs with the folloving error: > > VFS: cannot open root device "LABEL=/" or unknown-block (0,0) > Please append a correct "root=" boot option > Kernel panic: VFS: unable to mount root fs on unknown-block (0,0) This is taking a complete stab in the dark, but by any chance does your machine need an initrd in order to boot? Boot back into a kernel which is working, and check out the /boot directory and see if you see a file there of the form "initrd-" If you don't have an initrd for the version of 2.6 that you compiled from kernel.org, and you didn't compile support for all the modules you need into the kernel, you'll probably want to create an initrd. Just run "mkinitrd" as root at a prompt and it will return showing you an example which should help. Basically you'll run something like this: mkinitrd /boot/initrd-.img - 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 lbudai at ms.sapientia.ro Fri Feb 6 12:43:37 2004 From: lbudai at ms.sapientia.ro (Budai Laszlo) Date: Fri, 06 Feb 2004 14:43:37 +0200 Subject: fedora and kernel 2.6.1 In-Reply-To: <1076070504.20777.47.camel@angua.localnet> References: <4023489C.6070609@ms.sapientia.ro> <1076070504.20777.47.camel@angua.localnet> Message-ID: <40238BF9.4030004@ms.sapientia.ro> Nigel Metheringham wrote: > I'm not clear on whether you have things built into the kernel or built > as modules. However recently when I have seen that sort of problem its > often been down to a broken mkinitrd. It might be worth checking you > have a recent version. > > Nigel. > > I have: mkinitrd: version 3.5.14 Laszlo From surak at surak.eti.br Fri Feb 6 12:49:15 2004 From: surak at surak.eti.br (Alexandre Strube) Date: Fri, 06 Feb 2004 09:49:15 -0300 Subject: fedora and kernel 2.6.1 In-Reply-To: <1076069440.23538.35.camel@tweedy.ksc.nasa.gov> References: <4023489C.6070609@ms.sapientia.ro> <1076069440.23538.35.camel@tweedy.ksc.nasa.gov> Message-ID: <1076071755.7250.0.camel@casa> Em Sex, 2004-02-06 ?s 09:10, Bob Chiodini escreveu: > > VFS: cannot open root device "LABEL=/" or unknown-block (0,0) > > Please append a correct "root=" boot option > > Kernel panic: VFS: unable to mount root fs on unknown-block (0,0) > > I did try to specify root=0803 in grub.conf but the message now is: VFS: > > cannot open root device "0803" or unknown-block (8,3) > > Please append a correct "root=" boot option > > Kernel panic: VFS: unable to mount root fs on unknown-block (8,3) > > > > What can be done? > In grub.conf, try changing LABEL=/ to the real device name (e.g. > /dev/hda1) of your / partition. Something like: > kernel /vmlinuz-2.6.2 ro root=/dev/hda1 > However labels work okay for me with the 2.6.2 kernel. This was posted at fedora-users some time ago by me. Not 2.6-related, here it happens with ANY kernel. souns more like mkinitrd stuff -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From surak at surak.eti.br Fri Feb 6 12:50:26 2004 From: surak at surak.eti.br (Alexandre Strube) Date: Fri, 06 Feb 2004 09:50:26 -0300 Subject: fedora and kernel 2.6.1 In-Reply-To: <402386A0.1060705@ms.sapientia.ro> References: <4023489C.6070609@ms.sapientia.ro> <1076069440.23538.35.camel@tweedy.ksc.nasa.gov> <402386A0.1060705@ms.sapientia.ro> Message-ID: <1076071826.7250.2.camel@casa> Em Sex, 2004-02-06 ?s 09:20, Budai Laszlo escreveu: > I did try: > kernel /vmlinuz-2.6.1 ro root=/dev/sda3 > but still the same ... :( > I don't know maybe something else is wrong. I keep digging. My one just got working if I put this: title Fedora Core (2.4.22-1.2140.nptl) root (hd0,0) kernel /vmlinuz-2.4.22-1.2140.nptl ro root=/dev/hda2 hdc=ide-scsi rhgb vga=791 initrd /initrd-2.4.22-1.2140.nptl.img title Fedora Core (2.6.1-1.126) root (hd0,0) kernel /vmlinuz-2.6.1-1.126 ro root=/dev/hda2 hdc=ide-scsi rhgb vga=791 initrd /initrd-2.6.1-1.126.img -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From peter.backlund at home.se Fri Feb 6 12:53:49 2004 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 06 Feb 2004 13:53:49 +0100 Subject: fedora and kernel 2.6.1 In-Reply-To: <4023489C.6070609@ms.sapientia.ro> References: <4023489C.6070609@ms.sapientia.ro> Message-ID: <40238E5D.4010609@home.se> Budai Laszlo wrote: > Hello, > > I'm trying to compile the 2.6.1 kernel on Cedora Core 1. I've downloaded > the source from kernel.org, and try to follow the readme for installing. [snip] > What can be done? This is _completely_ off topic for this list. If you want to run 2.6, get the rawhide rpm or wait for FC2. If you absolutely, positively want to compile your own kernel, start with the FC config, found in the configs/ subdir of the kernel-source rpm. /Peter From surak at surak.eti.br Fri Feb 6 12:56:21 2004 From: surak at surak.eti.br (Alexandre Strube) Date: Fri, 06 Feb 2004 09:56:21 -0300 Subject: rawhide report: 20040115 changes In-Reply-To: References: <200401151312.i0FDCne07613@porkchop.devel.redhat.com> <4006944B.6030305@wanadoo.es> <1074206922.2156.12.camel@smoogen2.lanl.gov> <1074392461.20139.72.camel@casa> <20040118004332.16bf2b6d.pros-n-cons@bak.rr.com> <20040118022340.57671e37.pros-n-cons@bak.rr.com> Message-ID: <1076072180.7250.6.camel@casa> Em Dom, 2004-01-18 ?s 10:01, Hugo van der Kooij escreveu: (I'm the original poster) > I never saw the original posting untill I check my garbage can. And there > it was due the fact that the brasilian ISP of Alexander is blacklisted > with ORBS, spamcop, .... including open proxies and all. > A full report has been send to Alexander directly. But if you want to be > paranoid you should have walked away from such an ISP long ago and not > bother if some backdoor is present in code everyone can read and audit. It's a shame. There's only one broadband provider here - and I'm using it. They don't care about spammers, and as the ip changes every time, I'm a bit limited of what I can do for it. -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From lbudai at ms.sapientia.ro Fri Feb 6 13:39:25 2004 From: lbudai at ms.sapientia.ro (Budai Laszlo) Date: Fri, 06 Feb 2004 15:39:25 +0200 Subject: fedora and kernel 2.6.1 In-Reply-To: <40238E5D.4010609@home.se> References: <4023489C.6070609@ms.sapientia.ro> <40238E5D.4010609@home.se> Message-ID: <4023990D.8020504@ms.sapientia.ro> Peter Backlund wrote: > Budai Laszlo wrote: > >> Hello, >> >> I'm trying to compile the 2.6.1 kernel on Cedora Core 1. I've >> downloaded the source from kernel.org, and try to follow the readme >> for installing. > > [snip] > >> What can be done? > > > This is _completely_ off topic for this list. If you want to run 2.6, > get the rawhide rpm or wait for FC2. If you absolutely, positively want > to compile your own kernel, start with the FC config, found in the > configs/ subdir of the kernel-source rpm. > > /Peter > Sorry for being off topic. I did try to install the rawhide rpm but the result was the same ... :( Anyway I'll try with the kernel source rpm. Tahnks, Laszlo From jrzagar at cactus.org Fri Feb 6 15:50:49 2004 From: jrzagar at cactus.org (Randy Zagar) Date: 06 Feb 2004 09:50:49 -0600 Subject: rpm --addsign problems In-Reply-To: <20040206124502.19448.3420.Mailman@listman.back-rdu.redhat.com> References: <20040206124502.19448.3420.Mailman@listman.back-rdu.redhat.com> Message-ID: <1076082649.4418.59.camel@bofh.arlut.utexas.edu> In addition to having a proper .rpmrc, I also found that I had to re-sign my keys with --force-v3-sigs flag. You seem to need a v3 self-signature for rpm to be able to deal with it properly... -RZ On Fri, 2004-02-06 at 06:45, fedora-devel-list-request at redhat.com wrote: > Message: 2 > From: Gavin Henry > Organization: Suretec Systems > To: fedora-devel-list at redhat.com > Subject: Re: rpm --addsign problems > Date: Thu, 5 Feb 2004 17:34:24 +0000 > Reply-To: fedora-devel-list at redhat.com > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 05 February 2004 15:11, Michel Alexandre Salim wrote: > > On Thu, 2004-02-05 at 11:40 +0000, Gavin Henry wrote: > > [snip] > > > > > I am trying to sign a SRPM, but issuing rpm --addsign (according to > > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) > > > comes up blank. > > > > If you followed that document and built the package as a different user > > from the user that is signing the source RPM, have you chown the file? > > You can't sign a package you don't have write access to, naturally. > > > > HTH, > > > > Michel > > I used Mach to build it and also did it with fedora-develtools and the rpms > are owned by (chown) > > It must be a ~/.rpmrc your /etc/rpm/macro* thing? > > - -- > Regards, > > Gavin Henry. > Director. > > Open Source. Open Solutions. > http://www.suretecsystems.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAIn6geWseh9tzvqgRAlyrAJ9SIpZTV/hJ+igDkbKovL2HAeg49ACcCYfu > Y8SRDHu91XI7Ns3lj6EaRvs= > =V7V/ > -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Fri Feb 6 01:52:13 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Feb 2004 23:52:13 -0200 Subject: rawhide report: 20040128 changes In-Reply-To: <40181930.3090307@togami.com> References: <200401281632.i0SGWnl16833@porkchop.devel.redhat.com> <1075308747.8560.21.camel@skilletinfopleasecom.nh.pearsoned.com> <40180CFB.4000507@togami.com> <1075318240.8696.63.camel@roque> <1075318990.24709.1.camel@localhost.localdomain> <1075319222.8696.70.camel@roque> <40181416.3010902@wanadoo.es> <1075319780.8696.79.camel@roque> <40181930.3090307@togami.com> Message-ID: On Jan 28, 2004, Warren Togami wrote: > fedora.us IS EXTRAS, and it is already a given that those packages > will be moved to Fedora Extras at fedora.redhat.com when the time > comes. Won't this mean that (i) such packages will only show up weeks after the ISOs of the main project are available, and (ii) you won't be able to install them from CDs, without having to download the same packages over and over for installation in a collection of machines, or for CD burning in a network-connected location followed by installation in a disconnected location? Not everybody is on-line all the time. I think if we're to move important packages to Fedora Extras, Fedora Extras releases should be coordinated with Fedora Core, and should be available as ISOs that, ideally, anaconda and/or system-config-packages could use. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From aoliva at redhat.com Fri Feb 6 01:37:56 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Feb 2004 23:37:56 -0200 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Jan 31, 2004, Paul Jakma wrote: > On Tue, 27 Jan 2004, Alexandre Oliva wrote: >> It just works, with some help from device-mapper. > Any plans for FC1? I tried to upgrade an FC1 box to 2.6 + LVM2 using > Arjan's sources, but it was impossible. For a start his lvm2 packages > conflict with the regular lvm package. Only the man-pages do conflict. Installing with say --replacefiles works around this problem. Booting with LVM for the first time, if you have your root filesystem in LVM, is a bit tricky. I no longer remember exactly what I had to do, but it took some hacking in mkinitrd to get it to set things up for lvm2 for a 2.6 kernel even when the currently-booted kernel was still 2.4, and then, on the first boot into 2.6 (that would fail to remount the root filesystem), remounting it rw, moving the lvm device files aside in /dev and running lvm vgmknodes and lvm vgscan --mknodes (sp?) to get lvm2 to create the devices using device mapper. I vaguely remember having had to run some command from nash to create the device-mapper controlling block device, but it's been a while, so I no longer remember the exact detail. Have a look at the linuxrc script generated by mkinitrd and you'll find the command there. That said, since it was such a pain to switch back and forth between 2.4 and 2.6 in the same tree, I ended up removing 2.6 from my FC1 installs, and only using 2.6 in rawhide installs. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From shahms at shahms.com Fri Feb 6 16:59:00 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 06 Feb 2004 08:59:00 -0800 Subject: /etc/rc and potential startup improvements Message-ID: <1076086739.3341.38.camel@shahms.mesd.k12.or.us> Some of you may remember Seth Nickell talking about a replacement for init called SystemServices. When I first read about it I saw a few problems with it. First and foremost is developer buy-in. In order for it to be successful, it requires that the application developers themselves provide a services API using that (potentially distribution or Linux specific) interface. That can be a significant barrier to entry for an application that aims to be portable and providing startup services are done so differently on so many platforms (some of which will never adopt DBUS) that, in my opinion, makes it almost a non-starter. Additionally, I see nothing wrong with runlevels or most of the current rc system. The most glaring lack in the current system is a specification of something more meaningful than a simple numeric order. The other solutions I've seen usually provide service configuration and dependency information in a single, flat, file which has the same problems as the BSD-style init scripts. It should be possible to start programs which have no dependency on each other in parallel. And it should be possible to remain backwards-compatible with projects that haven't updated their initscripts. And it should be possible to do this without changing the current initscripts structure or "API". Using FC1 as a base, and chkconfig for ideas, I'm currently working on a small python-based "rc" replacement that should be able to manage all of that with a small addition to the headers already present at the top of an initscript. By adding a 'depends:' line to the top of an initscript, it should be possible to create a backwards-compatible system (installed side-by-side with the current bash-based one) with a few extra "smarts" that can ensure all services with explicit dependency information have their dependencies started before they are and all services without the 'depends:' header started after all services with a lower number. Installing the python 'rc.py' and helper 'rc-helper' shell script (for initscripts that don't use action, killproc, daemon, etc.) will allow the bash-based rc script to be used in the absence of a python binary. Given that the goal is to write the rc.py in such a way as to use the current runlevel information as a "guide" to dependency information only overriding those dependencies where explicitly specified it should be possible to gain a small measure of parallel-startup without changing the headers at all (any services with the same number after the 'S' have a non-deterministic order -- well,it's lexicographic, but the 'rules' of rc say that only the numeric value counts -- and so cannot depend on each other and may be started in parallel). Of course, there are certain situations that will negatively impact this proposal. Some services sometimes require the network to be up and sometimes don't, most databases fall into this category, X terminals, etc. At the moment I have it working well enough to start programs in the specified order (whooo ;-P) essentially a python port of the rc file, actually adding some dependency information to my initscripts is the next step, I'm just posting to ask the question: would anyone be interested in this purely-optional add-on if I manage to get it working to my satisfaction? Are there other people out there working on another solution to the initscript problem? -- Shahms King From brugolsky at telemetry-investments.com Fri Feb 6 17:26:51 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 6 Feb 2004 12:26:51 -0500 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: <20040206172651.GA26683@ti19.telemetry-investments.com> On Thu, Feb 05, 2004 at 11:37:56PM -0200, Alexandre Oliva wrote: > On Jan 31, 2004, Paul Jakma wrote: > > > On Tue, 27 Jan 2004, Alexandre Oliva wrote: > >> It just works, with some help from device-mapper. > > > Any plans for FC1? I tried to upgrade an FC1 box to 2.6 + LVM2 using > > Arjan's sources, but it was impossible. For a start his lvm2 packages > > conflict with the regular lvm package. > > Only the man-pages do conflict. Installing with say --replacefiles > works around this problem. The updated lvm package at Arjan's site has the man pages omitted, hence no conflict if one upgrades to that version. http://people.redhat.com/arjanv/2.6/RPMS.kernel/lvm-1.0.3-17.i386.rpm See: http://www.redhat.com/archives/fedora-list/2004-January/msg00158.html I think I covered the required steps in the first half of that email. There are one or two small thinkos (namely dm-mod.o -> dm-mod.ko, and lvm.c should not be included in file glob in the discussion of patching in device-mapper.) If you want to boot back and forth between 2.4 and 2.5, you'll have to hack up rc.sysinit or use device-mapper on 2.4. Rather than rc.sysinit trying to find the device file for the root filesystem on the root filesystem, it would seem to make more sense to defer unmounting /initrd, and use the device file there instead to do the fsck. I haven't bothered to create that patch, but it should be is pretty straightforward. Regards, Bill Rugolsky From katzj at redhat.com Fri Feb 6 17:31:02 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 06 Feb 2004 12:31:02 -0500 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: <20040206172651.GA26683@ti19.telemetry-investments.com> References: <20040206172651.GA26683@ti19.telemetry-investments.com> Message-ID: <1076088662.3212.1.camel@edoras.local.net> On Fri, 2004-02-06 at 12:26 -0500, Bill Rugolsky Jr. wrote: > If you want to boot back and forth between 2.4 and 2.5, you'll have to > hack up rc.sysinit or use device-mapper on 2.4. Rather than rc.sysinit > trying to find the device file for the root filesystem on the root > filesystem, it would seem to make more sense to defer unmounting /initrd, > and use the device file there instead to do the fsck. I haven't bothered > to create that patch, but it should be is pretty straightforward. This is the main piece missing right now that I know of (note that Arjan's site may not have all of the current stuff, rawhide really is the more canonical place right now). I've discussed a little with Bill moving to fscking the devnode from the initrd, but we haven't reached any full conclusions yet Jeremy From notting at redhat.com Fri Feb 6 17:32:53 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 6 Feb 2004 12:32:53 -0500 Subject: /etc/rc and potential startup improvements In-Reply-To: <1076086739.3341.38.camel@shahms.mesd.k12.or.us> References: <1076086739.3341.38.camel@shahms.mesd.k12.or.us> Message-ID: <20040206173253.GB29445@devserv.devel.redhat.com> Shahms King (shahms at shahms.com) said: > At the moment I have it working well enough to start programs in the > specified order (whooo ;-P) essentially a python port of the rc file, > actually adding some dependency information to my initscripts is the > next step, I'm just posting to ask the question: would anyone be > interested in this purely-optional add-on if I manage to get it working > to my satisfaction? Are there other people out there working on another > solution to the initscript problem? Sure, various implementations of this already exist. Not to discourage you, but you may want to look at: http://www.fefe.de/minit/ http://smarden.org/runit/ http://john.fremlin.de/programs/linux/jinit/ http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/ http://www.fastboot.org/ Some discussion points: - python is somewhat heavyweight. Moreover, you'd need to rearchitect other things to make sure /usr is there before rc starts. :) - Dependency headers are already specified in the LSB, might as well use those tags - We've done testing with some of these alternatives. It *really doesn't* provide that much of a speedup just by paralellizing things. At most we saw 10-15%. IMO, the way to faster boot is simple, yet hard: Do Less. Bill From ghenry at suretecsystems.com Fri Feb 6 17:44:15 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 17:44:15 +0000 Subject: rpm --addsign problems In-Reply-To: <1076082649.4418.59.camel@bofh.arlut.utexas.edu> References: <20040206124502.19448.3420.Mailman@listman.back-rdu.redhat.com> <1076082649.4418.59.camel@bofh.arlut.utexas.edu> Message-ID: <200402061744.15603.ghenry@suretecsystems.com> On Friday 06 February 2004 15:50, Randy Zagar wrote: > In addition to having a proper .rpmrc, I also found that I had to > re-sign my keys with --force-v3-sigs flag. You seem to need a v3 > self-signature for rpm to be able to deal with it properly... Cheers. To install it, all I did was rpm --import my_key and rpm took it fine. > -RZ > > On Fri, 2004-02-06 at 06:45, fedora-devel-list-request at redhat.com wrote: > > Message: 2 > > From: Gavin Henry > > Organization: Suretec Systems > > To: fedora-devel-list at redhat.com > > Subject: Re: rpm --addsign problems > > Date: Thu, 5 Feb 2004 17:34:24 +0000 > > Reply-To: fedora-devel-list at redhat.com > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thursday 05 February 2004 15:11, Michel Alexandre Salim wrote: > > > On Thu, 2004-02-05 at 11:40 +0000, Gavin Henry wrote: > > > [snip] > > > > > > > I am trying to sign a SRPM, but issuing rpm --addsign (according to > > > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) > > > > comes up blank. > > > > > > If you followed that document and built the package as a different user > > > from the user that is signing the source RPM, have you chown the file? > > > You can't sign a package you don't have write access to, naturally. > > > > > > HTH, > > > > > > Michel > > > > I used Mach to build it and also did it with fedora-develtools and the > > rpms are owned by (chown) > > > > It must be a ~/.rpmrc your /etc/rpm/macro* thing? > > > > - -- > > Regards, > > > > Gavin Henry. > > Director. > > > > Open Source. Open Solutions. > > http://www.suretecsystems.com > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.3 (GNU/Linux) > > > > iD8DBQFAIn6geWseh9tzvqgRAlyrAJ9SIpZTV/hJ+igDkbKovL2HAeg49ACcCYfu > > Y8SRDHu91XI7Ns3lj6EaRvs= > > =V7V/ > > -----END PGP SIGNATURE----- -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com From toshio at tiki-lounge.com Fri Feb 6 18:12:30 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 06 Feb 2004 13:12:30 -0500 Subject: rawhide report: 20040128 changes In-Reply-To: References: <200401281632.i0SGWnl16833@porkchop.devel.redhat.com> <1075308747.8560.21.camel@skilletinfopleasecom.nh.pearsoned.com> <40180CFB.4000507@togami.com> <1075318240.8696.63.camel@roque> <1075318990.24709.1.camel@localhost.localdomain> <1075319222.8696.70.camel@roque> <40181416.3010902@wanadoo.es> <1075319780.8696.79.camel@roque> <40181930.3090307@togami.com> Message-ID: <1076091148.20482.41.camel@Madison.badger.com> On Thu, 2004-02-05 at 20:52, Alexandre Oliva wrote: > Not everybody is on-line all the time. I think if we're to move > important packages to Fedora Extras, Fedora Extras releases should be > coordinated with Fedora Core, and should be available as ISOs that, > ideally, anaconda and/or system-config-packages could use. Something similar to Gnome's Fifth Toe would be nice. Fedora Core has a release schedule and Fedora Extras (Or some subset thereof) has a separate release schedule that comes out shortly afterwards. Releasing them on ISOs would be nice because they could be effectively pushed out through BitTorrent.... -Toshio -- Toshio From shahms at shahms.com Fri Feb 6 18:11:42 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 06 Feb 2004 10:11:42 -0800 Subject: /etc/rc and potential startup improvements In-Reply-To: <20040206173253.GB29445@devserv.devel.redhat.com> References: <1076086739.3341.38.camel@shahms.mesd.k12.or.us> <20040206173253.GB29445@devserv.devel.redhat.com> Message-ID: <1076091101.3341.55.camel@shahms.mesd.k12.or.us> On Fri, 2004-02-06 at 09:32, Bill Nottingham wrote: > Shahms King (shahms at shahms.com) said: > > Some discussion points: > > - python is somewhat heavyweight. Moreover, you'd need to rearchitect > other things to make sure /usr is there before rc starts. :) > - Dependency headers are already specified in the LSB, might as well > use those tags > - We've done testing with some of these alternatives. It *really doesn't* > provide that much of a speedup just by paralellizing things. At > most we saw 10-15%. > > IMO, the way to faster boot is simple, yet hard: Do Less. > > Bill Thanks for that, by the way. Of course, all of the systems you pointed out suffer from the fact that they are replacing init, or require major changes to existing initscripts. I'm just replacing rc (I happen to *like* SysV initscripts -- for the most part). Additionally, the lack of /usr was an integral concern of mine, which is why the "proposed" way to start this is from the traditional rc: if [ -x /usr/bin/python ]; then exec /usr/bin/python /etc/rc.py fi Again, my primary motivation is making what improvements I can while maintaining complete backwards-compatibility for situations where the "new-fangled" approach can't work and to ensure a deterministic startup order for scripts without the appropriate headers. Of course, rewriting it as a statically (or minimally) linked C program is also possible, the python is mostly proof-of-concept. Man, that's a lot of headers to support, fortunately I really only care about "Required-Start" ;-) I should have a non-parallel version finished pretty soon and I will put it up somewhere for anyone who is interested. If I can get 10-15% "for free" (i.e. an optional component that will be used if available) I'd say it's worth it. -- Shahms King From daly at rio.sci.ccny.cuny.edu Fri Feb 6 18:44:29 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Fri, 6 Feb 2004 13:44:29 -0500 Subject: rawhide report: 20040128 changes In-Reply-To: (message from Alexandre Oliva on 05 Feb 2004 23:52:13 -0200) References: <200401281632.i0SGWnl16833@porkchop.devel.redhat.com> <1075308747.8560.21.camel@skilletinfopleasecom.nh.pearsoned.com> <40180CFB.4000507@togami.com> <1075318240.8696.63.camel@roque> <1075318990.24709.1.camel@localhost.localdomain> <1075319222.8696.70.camel@roque> <40181416.3010902@wanadoo.es> <1075319780.8696.79.camel@roque> <40181930.3090307@togami.com> Message-ID: <200402061844.NAA08288@springbok.sci.ccny.cuny.edu> >Alexandre Oliva wrote: > >> fedora.us IS EXTRAS, and it is already a given that those packages >> will be moved to Fedora Extras at fedora.redhat.com when the time >> comes. > >Won't this mean that (i) such packages will only show up weeks after >the ISOs of the main project are available, and (ii) you won't be able >to install them from CDs, without having to download the same packages >over and over for installation in a collection of machines, or for >CD burning in a network-connected location followed by installation in >a disconnected location? > >Not everybody is on-line all the time. I think if we're to move >important packages to Fedora Extras, Fedora Extras releases should be >coordinated with Fedora Core, and should be available as ISOs that, >ideally, anaconda and/or system-config-packages could use. The KEY reason I use RedHat is that it is packaged as ISOs. Almost all of the distros assume you have net access. I have a compile farm with many distros installed and only RedHat is painless. I can't use apt-get from the farm. Plus I give RedHats to others easily which is why everyone around me runs it as they get it from me. From ghenry at suretecsystems.com Fri Feb 6 21:27:23 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 21:27:23 +0000 Subject: Spec file help Message-ID: <200402062127.27512.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I know everyone is extremely busy, but if someone has time to check over my first spec file and give me some feedback/pointers, it would be greatly appreciated. It was made with Mach and installs on FC1 and RH9 fine. Thanks, Gavin. url: http://www.suretecsystems.com/docs/netmon_applet.spec - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJAa9eWseh9tzvqgRApciAJ4pOqShZ/xppGhp7MFD43PoityQQACglds6 ZoJM2xFaQp6dKRsjljHZpPM= =qr9f -----END PGP SIGNATURE----- From karsten at redhat.com Fri Feb 6 21:39:46 2004 From: karsten at redhat.com (Karsten Hopp) Date: Fri, 6 Feb 2004 22:39:46 +0100 Subject: Spec file help In-Reply-To: <200402062127.27512.ghenry@suretecsystems.com> References: <200402062127.27512.ghenry@suretecsystems.com> Message-ID: <20040206213946.GB30430@redhat.com> On Fri, Feb 06, 2004 at 09:27:23PM +0000, Gavin Henry wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > I know everyone is extremely busy, but if someone has time to check over my > first spec file and give me some feedback/pointers, it would be greatly > appreciated. > > It was made with Mach and installs on FC1 and RH9 fine. > > Thanks, > > Gavin. > > url: http://www.suretecsystems.com/docs/netmon_applet.spec > > A few comments: > Source0 : http://www.demonseed.net/~jp/code/netmon_applet/netmon_applet-0.4.tar.gz It's better to use %{version} here. Otherwise you'd have to change the version at two places when you update to p.e. 0.5 >BuildRoot : %{_tmppath}/%{name}-{buildroot} Missing % ? ^ >./configure \ > --libdir=%{_libdir} \ > --bindir=%{_bindir} \ > --datadir=%{_datadir} \ > --sysconfdir=%{_sysconfdir} Use %configure, this sets those parameters automatically. Check /usr/lib/rpm/macros so see the complete %configure macro. Karsten -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-96437-111 D-70178 Stuttgart | http://www.redhat.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hhoffman at ip-solutions.net Fri Feb 6 21:43:32 2004 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 6 Feb 2004 16:43:32 -0500 Subject: Spec file help In-Reply-To: <20040206213946.GB30430@redhat.com> References: <200402062127.27512.ghenry@suretecsystems.com> <20040206213946.GB30430@redhat.com> Message-ID: <1076103812.88db9f6ad4945@secure.ip-solutions.net> I can't remember where I found this but the attached template.spec is what I use to create RPMS. I think it works very well :-) HTH, Harry Quoting Karsten Hopp : *> > *> *> A few comments: *> *> > Source0 : *> http://www.demonseed.net/~jp/code/netmon_applet/netmon_applet-0.4.tar.gz *> It's better to use %{version} here. Otherwise you'd have to change the *> version *> at two places when you update to p.e. 0.5 *> *> >BuildRoot : %{_tmppath}/%{name}-{buildroot} *> Missing % ? ^ *> *> >./configure \ *> > --libdir=%{_libdir} \ *> > --bindir=%{_bindir} \ *> > --datadir=%{_datadir} \ *> > --sysconfdir=%{_sysconfdir} *> Use %configure, this sets those parameters automatically. Check *> /usr/lib/rpm/macros so see the complete %configure macro. *> *> Karsten *> -- *> Karsten Hopp | Mail: karsten at redhat.de *> Red Hat Deutschland | Tel: +49-711-96437-0 *> Hauptstaetterstr.58 | Fax: +49-711-96437-111 *> D-70178 Stuttgart | http://www.redhat.de *> -- Harry Hoffman hhoffman at ip-solutions.net ------------------------------------------------- This mail sent through IpSolutions: http://www.ip-solutions.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: template.spec Type: application/octet-stream Size: 971 bytes Desc: not available URL: From ghenry at suretecsystems.com Fri Feb 6 22:09:23 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 22:09:23 +0000 Subject: Spec file help In-Reply-To: <20040206213946.GB30430@redhat.com> References: <200402062127.27512.ghenry@suretecsystems.com> <20040206213946.GB30430@redhat.com> Message-ID: <200402062209.25927.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 06 February 2004 21:39, Karsten Hopp wrote: > On Fri, Feb 06, 2004 at 09:27:23PM +0000, Gavin Henry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Dear all, > > > > I know everyone is extremely busy, but if someone has time to check over > > my first spec file and give me some feedback/pointers, it would be > > greatly appreciated. > > > > It was made with Mach and installs on FC1 and RH9 fine. > > > > Thanks, > > > > Gavin. > > > > url: http://www.suretecsystems.com/docs/netmon_applet.spec > > A few comments: > > Source0 : > > http://www.demonseed.net/~jp/code/netmon_applet/netmon_applet-0.4.tar.gz > > It's better to use %{version} here. Otherwise you'd have to change the > version at two places when you update to p.e. 0.5 > > >BuildRoot : %{_tmppath}/%{name}-{buildroot} > > Missing % ? ^ > > >./configure \ > > --libdir=%{_libdir} \ > > --bindir=%{_bindir} \ > > --datadir=%{_datadir} \ > > --sysconfdir=%{_sysconfdir} > > Use %configure, this sets those parameters automatically. Check > /usr/lib/rpm/macros so see the complete %configure macro. So I added %{buildroot} and do I just take out all the --libdir=%{_libdir} stuff and put %configure instead yeah? Thanks for the quick responses though. - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJBCTeWseh9tzvqgRApFoAJ97Veb2HF6nXXsJb6cRSxyI32a7uACff5j2 /mH7lWhNbIMhlOcvfhcfplo= =tK+q -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Fri Feb 6 22:12:31 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 6 Feb 2004 23:12:31 +0100 Subject: Spec file help In-Reply-To: <200402062127.27512.ghenry@suretecsystems.com> References: <200402062127.27512.ghenry@suretecsystems.com> Message-ID: <20040206231231.09399e76.ms-nospam-0306@arcor.de> On Fri, 6 Feb 2004 21:27:23 +0000, Gavin Henry wrote: > url: http://www.suretecsystems.com/docs/netmon_applet.spec Only skimmed over the spec without knowing the applet. A few errors in there in addition to what Karsten Hopp has mentioned already: > %prep > rm -rf $RPM_BUILD_ROOT Move the rm -rf line at the beginning of %install. It's there where you want the buildroot to be cleared (e.g. so consecutive short-circuit installs would work). > make make %{?_smp_mflags} E.g. to make the fedora.us build people happy. > %post -p /sbin/ldconfig > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` This won't work and will not execute the script, because "-p /sbin/ldconfig" makes ldconfig the script interpreter. %post /sbin/ldconfig export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` After seeing the %files list, I would say you don't run ldconfig at all, since your package doesn't add any libraries to directories mentioned in ld.so.conf. > %postun -p /sbin/ldconfig Same here. Not needed. Instead, with Fedora Core 1, gconftool-2 has a --makefile-uninstall-rule, too. With regard to the explicit dependencies, > Requires : gnome-panel >= 0:2.0.0 > Requires : gtk2 >= 0:2.0.0 > Requires : libgnomeui >= 0:2.0.0 are any these not covered automatically already in "rpm -qR package"? > BuildRequires : pkgconfig >= 0:0.10.0 First version of pkgconfig included within Red Hat Linux 7.1 is Epoch 1 already. -- From ms-nospam-0306 at arcor.de Fri Feb 6 22:14:47 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 6 Feb 2004 23:14:47 +0100 Subject: Spec file help In-Reply-To: <20040206213946.GB30430@redhat.com> References: <200402062127.27512.ghenry@suretecsystems.com> <20040206213946.GB30430@redhat.com> Message-ID: <20040206231447.328b5c82.ms-nospam-0306@arcor.de> On Fri, 6 Feb 2004 22:39:46 +0100, Karsten Hopp wrote: > A few comments: > > > Source0 : http://www.demonseed.net/~jp/code/netmon_applet/netmon_applet-0.4.tar.gz > It's better to use %{version} here. Otherwise you'd have to change the version > at two places when you update to p.e. 0.5 ... which shouldn't be a problem, because else the package would not build. ;) As long as just %{version} is used, fine. But if more download path components are replaced with macros, e.g. http://www.demonseed.net/~jp/code/%{name}/%{name}-%{version}.tar.gz package reviewers will need extra time to reconstruct the URL before they could download the upstream tarball. So, it's not generally "better" to use %{version} here, it's just another option for the packager. I consider it better to let URLs stay URLs which can be copied and passed on to e.g. wget or curl. -- From ghenry at suretecsystems.com Fri Feb 6 22:23:55 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 22:23:55 +0000 Subject: Spec file help In-Reply-To: <20040206231231.09399e76.ms-nospam-0306@arcor.de> References: <200402062127.27512.ghenry@suretecsystems.com> <20040206231231.09399e76.ms-nospam-0306@arcor.de> Message-ID: <200402062223.58044.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 06 February 2004 22:12, Michael Schwendt wrote: > On Fri, 6 Feb 2004 21:27:23 +0000, Gavin Henry wrote: > > url: http://www.suretecsystems.com/docs/netmon_applet.spec > > Only skimmed over the spec without knowing the applet. A few errors in Thanks, great to get help form experts. I will leave the url as is. > there in addition to what Karsten Hopp has mentioned already: > > %prep > > rm -rf $RPM_BUILD_ROOT OK > > Move the rm -rf line at the beginning of %install. It's there where you > want the buildroot to be cleared (e.g. so consecutive short-circuit > installs would work). > > > make > > make %{?_smp_mflags} > > E.g. to make the fedora.us build people happy. OK, that was in first time. > > %post -p /sbin/ldconfig > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > This won't work and will not execute the script, because "-p > /sbin/ldconfig" makes ldconfig the script interpreter. > > %post > /sbin/ldconfig > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > After seeing the %files list, I would say you don't run ldconfig at all, > since your package doesn't add any libraries to directories mentioned in > ld.so.conf. > > > %postun -p /sbin/ldconfig I will take out both ldconfigs > Same here. Not needed. Instead, with Fedora Core 1, gconftool-2 > has a --makefile-uninstall-rule, too. Do I need to do anything with the --makefile-uninstall-rule ?? > > With regard to the explicit dependencies, > > > Requires : gnome-panel >= 0:2.0.0 > > Requires : gtk2 >= 0:2.0.0 > > Requires : libgnomeui >= 0:2.0.0 > > are any these not covered automatically already in "rpm -qR package"? Not sure. Should I just leave BuildRequires in then? > > > BuildRequires : pkgconfig >= 0:0.10.0 > > First version of pkgconfig included within Red Hat Linux 7.1 is > Epoch 1 already. > I just made that version up :-( . I will get a more accurate version. Thanks again. - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJBP7eWseh9tzvqgRAldAAJwJEjco0xeOL6qJ7CFucsUrEZHjvgCfQmA0 WKPM6bjvppaLQ2cYvuzSN84= =zSeU -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Fri Feb 6 23:01:33 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 7 Feb 2004 00:01:33 +0100 Subject: Spec file help In-Reply-To: <200402062223.58044.ghenry@suretecsystems.com> References: <200402062127.27512.ghenry@suretecsystems.com> <20040206231231.09399e76.ms-nospam-0306@arcor.de> <200402062223.58044.ghenry@suretecsystems.com> Message-ID: <20040207000133.33834b82.ms-nospam-0306@arcor.de> On Fri, 6 Feb 2004 22:23:55 +0000, Gavin Henry wrote: > > Instead, with Fedora Core 1, gconftool-2 > > has a --makefile-uninstall-rule, too. > > Do I need to do anything with the --makefile-uninstall-rule ?? Undo in the %postun script what you install in the %post script? > > With regard to the explicit dependencies, > > > > > Requires : gnome-panel >= 0:2.0.0 > > > Requires : gtk2 >= 0:2.0.0 > > > Requires : libgnomeui >= 0:2.0.0 > > > > are any these not covered automatically already in "rpm -qR package"? > > Not sure. Query the binary package: rpm -qR netmon_applet* All the libraries, which are listed as package dependencies, belong to packages. Package tools find out in what package to find a file (even rpm does that with the help of the RPM database in the rpmdb-fedora package). E.g. libgtk-x11-2.0.so.0 is part of "gtk2", so you would not need an explicit dependency on "gtk2" if your applet is linked against that library. The dependency is determined automatically by rpmbuild. Or do you want to maintain such manually set dependencies and check them regularly? For instance, what happens if you use gtk2 2.2.4 and the next version of the applet no longer works with gtk2 >= 2.0.0 without mentioning that in the documentation? > Should I just leave BuildRequires in then? Of course, if that stuff is _required_ to build the package. > > > BuildRequires : pkgconfig >= 0:0.10.0 > > > > First version of pkgconfig included within Red Hat Linux 7.1 is > > Epoch 1 already. > > > > I just made that version up :-( . I will get a more accurate version. Or omit the version altogether. Do you target a specific distribution? Or do you aim at providing a generic package for arbitrary distributions? gnome-panel, gtk2 and libgnomeui > 2.0.0 were available in Red Hat Linux 8.0 already. If there's a specific reason why an explicit dependency [and even a versioned one] is needed, that should be documented in the spec file. -- From ghenry at suretecsystems.com Fri Feb 6 23:33:36 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 6 Feb 2004 23:33:36 +0000 Subject: Spec file help In-Reply-To: <20040207000133.33834b82.ms-nospam-0306@arcor.de> References: <200402062127.27512.ghenry@suretecsystems.com> <200402062223.58044.ghenry@suretecsystems.com> <20040207000133.33834b82.ms-nospam-0306@arcor.de> Message-ID: <200402062333.41628.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 06 February 2004 23:01, Michael Schwendt wrote: > On Fri, 6 Feb 2004 22:23:55 +0000, Gavin Henry wrote: > > > Instead, with Fedora Core 1, gconftool-2 > > > has a --makefile-uninstall-rule, too. > > > > Do I need to do anything with the --makefile-uninstall-rule ?? > > Undo in the %postun script what you install in the %post script? done that. All amendments are done on the previous spec on http://suretecsystem.com/docs/netmon_applet.spec > > > > With regard to the explicit dependencies, > > > > > > > Requires : gnome-panel >= 0:2.0.0 > > > > Requires : gtk2 >= 0:2.0.0 > > > > Requires : libgnomeui >= 0:2.0.0 > > > > > > are any these not covered automatically already in "rpm -qR package"? > > > > Not sure. > > Query the binary package: rpm -qR netmon_applet* I can't this as I originally install from source and now the rpm won't build. I get loads of: Recursion depth(17) greater than max(16) File not found: /var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/usr/lib/debug/usr/bin/netmon_applet.debug (sorry for the length) I think the rm -rf in %install is causing this?? > All the libraries, which are listed as package dependencies, belong to > packages. Package tools find out in what package to find a file (even rpm > does that with the help of the RPM database in the rpmdb-fedora > package). E.g. libgtk-x11-2.0.so.0 is part of "gtk2", so you would not > need an explicit dependency on "gtk2" if your applet is linked against > that library. The dependency is determined automatically by rpmbuild. > > Or do you want to maintain such manually set dependencies and check them > regularly? For instance, what happens if you use gtk2 2.2.4 and the next > version of the applet no longer works with gtk2 >= 2.0.0 without > mentioning that in the documentation? This applet is for 2.x of gtk2. I need to read up more on the spec file as this IS the rpm.... I am beginning to fell a little out of my depth here, but your help is very appreciated. > > Should I just leave BuildRequires in then? > > Of course, if that stuff is _required_ to build the package. > > > > > BuildRequires : pkgconfig >= 0:0.10.0 > > > > > > First version of pkgconfig included within Red Hat Linux 7.1 is > > > Epoch 1 already. > > > > I just made that version up :-( . I will get a more accurate version. > > Or omit the version altogether. > > Do you target a specific distribution? Or do you aim at providing a > generic package for arbitrary distributions? This is just for fedora. > > gnome-panel, gtk2 and libgnomeui > 2.0.0 were available in Red Hat Linux > 8.0 already. If there's a specific reason why an explicit dependency [and > even a versioned one] is needed, that should be documented in the spec > file. I have documented this with a # should be a %description type thing or can I just use the # for comments? Gavin. - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJCRQeWseh9tzvqgRAsJ+AKCMAX3avECJOHzdToZb98Kn7rPNvwCfQTAg yJ3g0Qsjd+/+69oADe7Pc94= =r+6e -----END PGP SIGNATURE----- From hattenator at imapmail.org Sat Feb 7 00:25:05 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Fri, 06 Feb 2004 16:25:05 -0800 Subject: fedora and kernel 2.6.1 In-Reply-To: <40238E5D.4010609@home.se> References: <4023489C.6070609@ms.sapientia.ro> <40238E5D.4010609@home.se> Message-ID: <40243061.8000703@imapmail.org> I hate to disagree, but I had this same problem, and it does seem relevant to this list. When I first saw the email I said, "What is this doing on the list?" But then when I thought about it and realized it may be a legitimate grub/grub.conf bug, I think it does deserve some discussion. As far as I know RedHat has historically used the root=LABEL=/ tag for a very long time. Now I went through too much to narrow it down to a bug report, and I don't remember all of it, but here goes: I used to run RH9+fedora.us, then I bought a new HD controller (promise) and a new HD. I started using that drive as a boot drive. I set the bios to boot it first, but it still shows up as hde. I installed RH9 and had to teach lilo.conf: disk=/dev/hde bios=0x80 Because grub wouldn't boot, I used lilo. Perhaps I have a weird configuration, but I needed to do this by hand. Recently I decided to move back to grub. I manged it by considering hde to be hd0. I'm alright with doing all this by hand, but it may be a problem for other people. When I turned grub to hd0, it could find the kernel. However, the kernel gave the same root not found message. It required changing root=LABEL=/ to root=/dev/hde1. However, lilo.conf uses root=LABEL=/ and works fine. I modified /boot/grub/device.map to say (fd0) /dev/fd0 (hd0) /dev/hde (hd1) /dev/hda (hd2) /dev/hdb with no success. Now when I get a chance in the next couple of months I will probably format and install from an FC2 CD. I will probably file a bug report if the CD doesn't set up my computer to boot, and it seems fixable. But the reason I bring this up for the list is because I think all future kernel rpms should instead of setting in grub.conf root=LABEL=/, it should set something like root=/dev/xxx where xxx is something like `mount |awk '/ \/ / {print $1}'`. Now like I said, I wish I could narrow down where the problems are. Maybe its just a bug in grub that they could fix easily. Maybe I have two partitions labeled /. But I just thought I'd bring this up as an issue. -Eric Hattemer Peter Backlund wrote: > > This is _completely_ off topic for this list. If you want to run 2.6, > get the rawhide rpm or wait for FC2. If you absolutely, positively want > to compile your own kernel, start with the FC config, found in the > configs/ subdir of the kernel-source rpm. > > /Peter > > > > From ms-nospam-0306 at arcor.de Sat Feb 7 00:28:30 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 7 Feb 2004 01:28:30 +0100 Subject: Spec file help In-Reply-To: <200402062333.41628.ghenry@suretecsystems.com> References: <200402062127.27512.ghenry@suretecsystems.com> <200402062223.58044.ghenry@suretecsystems.com> <20040207000133.33834b82.ms-nospam-0306@arcor.de> <200402062333.41628.ghenry@suretecsystems.com> Message-ID: <20040207012830.45fc9691.ms-nospam-0306@arcor.de> On Fri, 6 Feb 2004 23:33:36 +0000, Gavin Henry wrote: > done that. All amendments are done on the previous spec on > http://suretecsystem.com/docs/netmon_applet.spec $ host suretecsystem.com Host suretecsystem.com not found: 3(NXDOMAIN) => http://www.suretecsystems.com/docs/netmon_applet.spec > I get loads of: > > Recursion depth(17) greater than max(16) > File not > found: /var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/usr/lib/debug/usr/bin/netmon_applet.debug > (sorry for the length) > > I think the rm -rf in %install is causing this?? Nah. Someone else made a wrong suggestion leading to recursion here: > BuildRoot : %{_tmppath}/%{name}-%{buildroot} You want: BuildRoot : %{_tmppath}/%{name}-buildroot > This is just for fedora. > > > > > gnome-panel, gtk2 and libgnomeui > 2.0.0 were available in Red Hat Linux > > 8.0 already. If there's a specific reason why an explicit dependency [and > > even a versioned one] is needed, that should be documented in the spec > > file. > > I have documented this with a # should be a %description type thing or can I > just use the # for comments? It doesn't really belong into the package description. gtk2 is part of the distribution anyway. -- From steve at rueb.com Sat Feb 7 02:07:03 2004 From: steve at rueb.com (Steve Bergman) Date: Fri, 06 Feb 2004 20:07:03 -0600 Subject: Prelink hosed my binaries? In-Reply-To: <1076034710.6543.2.camel@mentor.gurulabs.com> References: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> <1076034710.6543.2.camel@mentor.gurulabs.com> Message-ID: <1076119623.15391.23.camel@ip68-12-228-23.ok.ok.cox.net> On Thu, 2004-02-05 at 20:31, Dax Kelson wrote: > A couple days ago my co-worker was telling me that he turned on his > previously fine FCv1 laptop and most of his binaries were hosed. On > examination the binaries had log files (/var/log/*) contents > interspersed through them. Some of my binaries were OK. Others still had ELF headers buried inside. For example, /usr/bin/ipcs has exactly 8k of garbage prepended to it. But if I strip off the 8k bytes, it's still quite corrupted. Others show no signs of ever having been a binary at all. Others have an ELF header buried inside at some other point, e.g. 0x5620. It does seem to be binaries only that are corrupt. reiserfsck /dev/hdc2 finds absolutely no filesystem corruption. I have not even tried to salvage my rawhide partition and am back to FC1, however the rawhide partition still exists. -Steve From mharris at redhat.com Sat Feb 7 08:27:52 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 7 Feb 2004 03:27:52 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <1076065536.6676.7.camel@wombat.tiptoe.de> References: <1076065536.6676.7.camel@wombat.tiptoe.de> Message-ID: On Fri, 6 Feb 2004, Nils Philippsen wrote: >Having been nudged politely, I'll respond now (albeit a bit late). Late is always better than never. ;o) >On Mon, 2004-02-02 at 06:09, Mike A. Harris wrote: > >> Proposed Solution: >> >> After much thought, my own proposed solution, is to do the >> following: >> >> - Create a number of new "virtual Provides:" in the XFree86 rpm >> spec file in the XFree86-libs and XFree86-devel packages >> respectively. Essentially there would be one new virtual >> provide for each library, and perhaps for developmental >> utilities necessary for X development also, which are presently >> in XFree86-devel. > >Full ACK, this could be even extended into adjacent areas, e.g. Mesa >libs which once were in their own package and now are in XFree86-libs-GL >or whatever -- and who knows where they will be when having fd.o libs >becomes en vogue? There might even be more packages where this could be >applied to: e.g. GLUT <-> freeglut, ImageMagick <-> GraphicsMagick, ... >whereever there are alternative libraries that can be used. Agreed. Mesa will be split out into it's own rpms once again in the future as well, but without the pains that that once entailed (at least I hope not ). freeglut needs an update to the buggy placeholder package in FC1 soon, and I plan on putting virtual provides for glut in there also, along with the proper compat libs, headers, etc. Seems to me like a good idea for the other packages as well. >Sorry for not having found any quirks in your proposal ;-). No problem, so far there have been mostly ACK responses, and more are always good. ;o) Someone brought up a concern over having every single X library in it's own src.rpm, and the dependancy domino effect that would result, perhaps being a bit of a PITA to bootstrap, and perhaps a problem for other packages even. That problem on it's own is a different issue entirely from the virtual provides issue itself, so doesn't completely fit into the proposal I requested feedback on, however it was nonetheless another issue that needs to be taken into consideration when actually doing the new packaging. I'm going to experiment privately with one src.rpm per lib, but I have a feeling it might make more sense to group all of the common standard X libraries that rarely if ever change into one single foo-xlibs-common.src.rpm to avoid the interdependancies, some of which are kindof ugly (Xau depends on Xlib, Xlib depends on Xau). If this is done, then the only libs that would be separate are ones that either: 1) Are fairly new, and under active development, such as everything Keith Packard works on. 2) Frequently change to fix bugs and other issues 3) Are a common source of new security headaches being discovered which need to be updated. None of this should really be a problem for anyone other than myself however, and perhaps releng. It would more or less be a self-solving problem though if everyone uses the new virtual requires I suggested in the proposal, as the packages would pick up the right lib deps without caring which rpm they are actually present in. I'll probably post another message about the granularity of library modularization in the future when it's closer to something useable. Thanks again for the feedback! -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sat Feb 7 08:38:20 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 7 Feb 2004 03:38:20 -0500 (EST) Subject: Corporate pressure In-Reply-To: <4020129E.8060300@home.se> References: <401E480E.1060307@home.se> <4020129E.8060300@home.se> Message-ID: On Tue, 3 Feb 2004, Peter Backlund wrote: >So, someone at Red Hat should contact robla at real.com (_duncan in #helix, >irc.helixcommunity.org) for further investigation. Meanwhile, I'm going >to start working on, and submit to QA, a specfile for the package. http://fedora.redhat.com/about "The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system exclusively from open source software." Therefore, shipping any proprietary or binary only software in Fedora Core or Fedora Extras is right out totally. Shipping software which is open source but which enables the use of proprietary plugins easily and is not very useful without those proprietary plugins, does not exactly promote "a general purpose operating system exclusively from open source software", and so that idea would completely go against the stated goals of the Fedora Project. By keeping Fedora Project clear both of proprietary software *and* of dependancies on proprietary software for useful features, helps to grow interest and motivation in others to design, develop, implement open source solutions, so that there are open source alternatives tomorrow for the proprietary software solutions that exist today that don't have 100% open source replacements. I for one would oppose the inclusion of any proprietary software into the Fedora Core or Extras, or any software (open source or otherwise) which exists purely to enable layering of proprietary software or plugins on top of that. That doesn't stop people from going and downloading the stuff anyway if they want to use it. Please don't try to change the project's mandated goals. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From kir at darnet.ru Sat Feb 7 09:28:29 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Sat, 07 Feb 2004 12:28:29 +0300 Subject: Spec file help In-Reply-To: <200402062333.41628.ghenry@suretecsystems.com> References: <200402062127.27512.ghenry@suretecsystems.com> <200402062223.58044.ghenry@suretecsystems.com> <20040207000133.33834b82.ms-nospam-0306@arcor.de> <200402062333.41628.ghenry@suretecsystems.com> Message-ID: <4024AFBD.1040204@darnet.ru> This is because you have %{buildroot} in BuildRoot: definition (because originally you had curly braces around 'buildroot', so someone from this list suggests that you are missing %). So you have recursive BuildRoot definition (much like GNU == GNU's Not Unix;). The correct buildroot statement would be: BuildRoot: %{_tmppath}/%{name}-%{version}-root or, if you prefer (that really doesn't matter BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot Gavin Henry wrote: >I can't this as I originally install from source and now the rpm won't build. >I get loads of: > >Recursion depth(17) greater than max(16) > File not >found: /var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/usr/lib/debug/usr/bin/netmon_applet.debug >(sorry for the length) > > From kir at darnet.ru Sat Feb 7 09:32:51 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Sat, 07 Feb 2004 12:32:51 +0300 Subject: Prelink hosed my binaries? In-Reply-To: <1076119623.15391.23.camel@ip68-12-228-23.ok.ok.cox.net> References: <1075647963.4434.7.camel@ip68-12-228-23.ok.ok.cox.net> <1076034710.6543.2.camel@mentor.gurulabs.com> <1076119623.15391.23.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <4024B0C3.5090709@darnet.ru> Steve Bergman wrote: >It does seem to be binaries only that are corrupt. reiserfsck /dev/hdc2 >finds absolutely no filesystem corruption. > Oh, the filesystem time you use explains everything. You were hit by the wide-known reiserfs bug. Reiserfs have a tendency to intermix two files' contents under some circumstances (high load, power loss, etc.). And probably it has nothing to do with prelink. Solution is to not use reiserfs, at least for vital partitions such as root and /usr. From ggw at wolves.durham.nc.us Sat Feb 7 09:37:28 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Sat, 7 Feb 2004 04:37:28 -0500 Subject: boot.iso problem Message-ID: <20040207093728.GA4774@wolves.durham.nc.us> Hi, I've got a problem with the boot.iso file from FC development. On a K6-2, Verbatim CD-RW on ide1 master, the CD loads and then simply resets the system and cycles back to POST. I've seen reports from others that they have used boot.iso successfully, but I can't get it to run properly on that particular machine. FC/1 i386 disc 1 boots properly on the machine. Has anyone seen this? Should this question go to fedora-test-list? -- Gregory G. "Wolfe" Woodbury `-_-' Owner/Admin: wolves.durham.nc.us ggw at wolves.durham.nc.us U RHCT August 2003 "The Line Eater is a boojum snark." Hug your wolf. From peter.backlund at home.se Sat Feb 7 10:43:07 2004 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 07 Feb 2004 11:43:07 +0100 Subject: Corporate pressure In-Reply-To: References: <401E480E.1060307@home.se> <4020129E.8060300@home.se> Message-ID: <4024C13B.2020006@home.se> Mike A. Harris wrote: > On Tue, 3 Feb 2004, Peter Backlund wrote: > > >>So, someone at Red Hat should contact robla at real.com (_duncan in #helix, >>irc.helixcommunity.org) for further investigation. Meanwhile, I'm going >>to start working on, and submit to QA, a specfile for the package. > > > http://fedora.redhat.com/about > > "The goal of The Fedora Project is to work with the Linux > community to build a complete, general purpose operating system > exclusively from open source software." > > Therefore, shipping any proprietary or binary only software in > Fedora Core or Fedora Extras is right out totally. That was never the intention. > Shipping software which is open source but which enables the use > of proprietary plugins easily and is not very useful without > those proprietary plugins, does not exactly promote "a general > purpose operating system exclusively from open source software", > and so that idea would completely go against the stated goals of > the Fedora Project. The Helix Player has the capabilities to play MP3, MPEG-4, AMR (narrowband codec), Ogg Vorbis and H.263 in the OSI-approved parts of the code base. So I wouldn't exactly call it useless without the RA/RV plugins. But sure, the thing that distinguishes it from other media players is of course RA/RV. > By keeping Fedora Project clear both of proprietary software > *and* of dependancies on proprietary software for useful > features, helps to grow interest and motivation in others to > design, develop, implement open source solutions, so that there > are open source alternatives tomorrow for the proprietary > software solutions that exist today that don't have 100% open > source replacements. > > I for one would oppose the inclusion of any proprietary software > into the Fedora Core or Extras, or any software (open source or > otherwise) which exists purely to enable layering of proprietary > software or plugins on top of that. > > That doesn't stop people from going and downloading the stuff > anyway if they want to use it. Please don't try to change the > project's mandated goals. Point taken. Perhaps the Helix Player should go entirely into a repository outside of Fedora Core/Extras. It might be a bit more difficult to get permission to host RA/RV, but certainly not impossible. /Peter From mharris at redhat.com Sat Feb 7 11:03:38 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 7 Feb 2004 06:03:38 -0500 (EST) Subject: Corporate pressure In-Reply-To: <4024C13B.2020006@home.se> References: <401E480E.1060307@home.se> <4020129E.8060300@home.se> <4024C13B.2020006@home.se> Message-ID: On Sat, 7 Feb 2004, Peter Backlund wrote: >> Shipping software which is open source but which enables the use >> of proprietary plugins easily and is not very useful without >> those proprietary plugins, does not exactly promote "a general >> purpose operating system exclusively from open source software", >> and so that idea would completely go against the stated goals of >> the Fedora Project. > >The Helix Player has the capabilities to play MP3, MPEG-4, AMR >(narrowband codec), Ogg Vorbis and H.263 in the OSI-approved parts of >the code base. So I wouldn't exactly call it useless without the RA/RV >plugins. But sure, the thing that distinguishes it from other media >players is of course RA/RV. The majority of the codecs to play the above formats, are either proprietary, or are IP encumbered, including MP3, MPEG-4 and others. Ogg Vorbis is the only one I recognize above which is truely free. We don't need Helix player to play Ogg vorbis, I've been using ogg for a few years now and have never installed Helix player personally. I've also used several of the other formats without using Helix. >> I for one would oppose the inclusion of any proprietary software >> into the Fedora Core or Extras, or any software (open source or >> otherwise) which exists purely to enable layering of proprietary >> software or plugins on top of that. >> >> That doesn't stop people from going and downloading the stuff >> anyway if they want to use it. Please don't try to change the >> project's mandated goals. > >Point taken. Perhaps the Helix Player should go entirely into a >repository outside of Fedora Core/Extras. It might be a bit more >difficult to get permission to host RA/RV, but certainly not >impossible. www.livna.org perhaps would be best. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alan at redhat.com Sat Feb 7 11:53:27 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 7 Feb 2004 06:53:27 -0500 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: <1076065536.6676.7.camel@wombat.tiptoe.de> Message-ID: <20040207115327.GC21830@devserv.devel.redhat.com> On Sat, Feb 07, 2004 at 03:27:52AM -0500, Mike A. Harris wrote: > Thanks again for the feedback! Sounds good to me. I'd love per chipset packaging so that for example XFree86-ati-radeon-blah contained the radeon driver, dri .so and related bits, but that I can see is a good deal harder to get right From mharris at redhat.com Sat Feb 7 12:17:22 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 7 Feb 2004 07:17:22 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <20040207115327.GC21830@devserv.devel.redhat.com> References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> Message-ID: On Sat, 7 Feb 2004, Alan Cox wrote: >On Sat, Feb 07, 2004 at 03:27:52AM -0500, Mike A. Harris wrote: >> Thanks again for the feedback! > >Sounds good to me. I'd love per chipset packaging so that for >example XFree86-ati-radeon-blah contained the radeon driver, dri .so and >related bits, but that I can see is a good deal harder to get right That is something I definitely want to do in the future also. The XFree86-sdk subpackage was created with the intent to enable experimentation on splitting out drivers in the future. Paul Nasrat made some proof-of-concept rpms of the ati driver, vga driver, and a few others a while back. The biggest problem with split out drivers is our config tools need to be modified to deal with multiple packages, and I need a way of knowing wether someone is using an official driver we supplied or not easily. If someone uses a self built driver, I need a way of knowing that, so I don't waste a bunch of time on a bogus bug report. Of course that can and does happen now already, but it's rarer because it's not as simple as just upgrading an rpm from the command line. XFree86 needs something akin to the kernel's tainting flags, and having Red Hat signed modules. Also, the driver rpms should have a metadata file included with them which is essentially like a Windows .INF file, which drops into a predefined /usr/share/something dir and informs our config tools what hardware this new driver supports, etc. Basically a modularized replacement for the ancient Cards database, and pcitable, where that information is now stored in a metadata file accompanying the driver. That way, a user could install/upgrade a driver, and the config tool would know right away what is supported, without having to force us to go edit hwdata database files, and update that package too, etc. It's been on my mind for quite some time and I wrote up a functional spec on a design a while back, but haven't worked on it for a while. I'll need to revive that, and post it somewhere for feedback in the future. Thanks, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From buildsys at redhat.com Sat Feb 7 12:54:37 2004 From: buildsys at redhat.com (Build System) Date: Sat, 7 Feb 2004 07:54:37 -0500 Subject: rawhide report: 20040207 changes Message-ID: <200402071254.i17Csb623355@porkchop.devel.redhat.com> Updated Packages: kudzu-1.1.43-1 -------------- * Fri Feb 06 2004 Bill Nottingham 1.1.43-1 - add patch for smartarray/dac960 devices () * Wed Feb 04 2004 Bill Nottingham 1.1.42-1 - fix segfault on CLASS_NETWORK devices with no device set (#106332) - fix various network device naming snafus (#114611, #113418) rpmdb-fedora-1.90-0.20040207 ---------------------------- From ghenry at suretecsystems.com Sat Feb 7 18:25:05 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 7 Feb 2004 18:25:05 +0000 Subject: Spec file help In-Reply-To: <20040207012830.45fc9691.ms-nospam-0306@arcor.de> References: <200402062127.27512.ghenry@suretecsystems.com> <200402062333.41628.ghenry@suretecsystems.com> <20040207012830.45fc9691.ms-nospam-0306@arcor.de> Message-ID: <200402071825.13043.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 07 February 2004 00:28, Michael Schwendt wrote: > On Fri, 6 Feb 2004 23:33:36 +0000, Gavin Henry wrote: > > done that. All amendments are done on the previous spec on > > http://suretecsystem.com/docs/netmon_applet.spec > > $ host suretecsystem.com > Host suretecsystem.com not found: 3(NXDOMAIN) > > => http://www.suretecsystems.com/docs/netmon_applet.spec Oops. > > > I get loads of: > > > > Recursion depth(17) greater than max(16) > > ? ? File not > > found: > > /var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var > >/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/ > >netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmo > >n_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_app > >let-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/var/tmp/netmon_applet-/ > >usr/lib/debug/usr/bin/netmon_applet.debug (sorry for the length) > > > > I think the rm -rf in %install is causing this?? > > Nah. Someone else made a wrong suggestion leading to recursion here: > > BuildRoot ? ? ?: %{_tmppath}/%{name}-%{buildroot} > > You want: > > BuildRoot ? ? ?: %{_tmppath}/%{name}-buildroot Thanks. > > > This is just for fedora. > > > > > gnome-panel, gtk2 and libgnomeui > 2.0.0 were available in Red Hat > > > Linux 8.0 already. If there's a specific reason why an explicit > > > dependency [and even a versioned one] is needed, that should be > > > documented in the spec file. > > > > I have documented this with a # should be a %description type thing or > > can I just use the # for comments? > > It doesn't really belong into the package description. gtk2 is part > of the distribution anyway. Thanks. I will update and leave the spec up for anyone else that wants to look. http://www.suretecsystems.com/docs/netmon_applet.spec > > -- - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJS2FeWseh9tzvqgRAhZHAJ48BXd6pAwsVnIK1hlxS3dp3OZqSACeI6q7 nAiC9/6wM2FIwjBOSIvk4po= =TglH -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Sat Feb 7 18:25:40 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 7 Feb 2004 18:25:40 +0000 Subject: Spec file help In-Reply-To: <4024AFBD.1040204@darnet.ru> References: <200402062127.27512.ghenry@suretecsystems.com> <200402062333.41628.ghenry@suretecsystems.com> <4024AFBD.1040204@darnet.ru> Message-ID: <200402071825.42568.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 07 February 2004 00:28, Michael Schwendt wrote: + ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu - --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr - --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc - --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib - --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com - --mandir=/usr/share/man --infodir=/usr/share/info /var/tmp/rpm-tmp.88089: line 33: ./configure: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.88089 (%build) Why is there no ./configure ???? - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJS2keWseh9tzvqgRAmvhAJ4/dAaUUFvs1QFmMN7pZndWGJbYYACggyKG 5bhYuAszLpLFI5JGDhfnp6U= =fGLb -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Sat Feb 7 19:05:34 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 7 Feb 2004 20:05:34 +0100 Subject: Spec file help In-Reply-To: <200402071825.42568.ghenry@suretecsystems.com> References: <200402062127.27512.ghenry@suretecsystems.com> <200402062333.41628.ghenry@suretecsystems.com> <4024AFBD.1040204@darnet.ru> <200402071825.42568.ghenry@suretecsystems.com> Message-ID: <20040207200534.104ba4f4.ms-nospam-0306@arcor.de> On Sat, 7 Feb 2004 18:25:40 +0000, Gavin Henry wrote: > /var/tmp/rpm-tmp.88089: line 33: ./configure: No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.88089 (%build) > > Why is there no ./configure ???? What did you try to compile? Not every source tarball includes a "configure" script. And with some tarballs (e.g. CVS snapshots) you need to recreate the configure script with autoconf (and other files with other autotools, e.g. aclocal ; automake). -- From mattdm at mattdm.org Sat Feb 7 20:12:54 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 7 Feb 2004 15:12:54 -0500 Subject: FHS 2.3? In-Reply-To: References: <20040204165357.GW25654@redhat.com> <1076022533.2825.35.camel@mentor.gurulabs.com> <1076057008.10738.0.camel@pc-32.office.scali.no> Message-ID: <20040207201254.GA1485@jadzia.bu.edu> On Fri, Feb 06, 2004 at 04:24:57AM -0500, Mike A. Harris wrote: > And if those distributions were LSB compliant, then one is to > assume that distros that do not switch to using /srv must be LSB > compliant also. ;o) To be fair, SuSE started doing that as a result of discussion on the LSB list long ago. In any case, I think it's a mistake to make /srv not-optional -- not all systems have data that should go there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jgardner at jonathangardner.net Sat Feb 7 20:14:54 2004 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Sat, 7 Feb 2004 12:14:54 -0800 Subject: Self-Introduction: Jonathan Gardner Message-ID: <200402071214.57165.jgardner@jonathangardner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Full legal name Jonathan Mosiah Gardner 2. Country, City Federal Way, Washington, USA 3. Profession or Student status Web Developer / Software Engineer 4. Company or School Amazon.com (full-time) Redweek.com (part-time) 5. Your goals in the Fedora Project * Which packages do you want to see published? PyKDE QScintilla eric (the PyQt debugger) spread (along with perl, java, python, etc interfaces) Postgres-R (needs spread) Exim * Do you want to do QA? I will do it from time to time. I'm interested in the above packages, so if you want me to test something related to them, email me. * Anything else special? I think fedora has a lot of potential. Debian lacks /focus/, but Fedora has a real leader who is going to try and herd the engineers towards specific, profit-oriented (and thus customer-satisfying) goals. I've seen enough of what happens when you let engineers take over a problem and I appreciate having a manager point to his watch and emphasize the needs of the customers. 6. Historical qualifications * What other projects have you worked on in the past? I've never contributed significant amounts of code to any project, but I have done some work with the following projects: PyQt, ViM, PostgreSQL, python, Text::Forge, HTML::Mason, mod_perl, mod_python, Mozilla and many more I can't remember now. I help maintain the Sourceforge website for the PyQt project currently. I'm working on Materialized Views for PostgreSQL. * What computer languages and other skills do you know? Python, perl, C, in that order. I deal a lot with HTTP and web technologies (HTML and friends). I work with PostgreSQL databases, Qt, PyQt. * Why should we trust you? <--- too blunt? No, it's a great question. You don't have any reason to trust me until you see what I do. Go ahead and search on Google for past posts by me, and search the web for anything you can find on me. But don't give me the keys to your car until you know I can drive and I won't steal it. 7. GPG KEYID and fingerprint This is my old key. Note the expiration date. You won't be using it for long if you use it at all. pub 1024D/0BE958DC 2003-02-28 Jonathan Gardner Key fingerprint = C151 4F3E 6DB3 F51F 31B9 850E 5A0C 05DD 0BE9 58DC sub 1024g/5F007918 2003-02-28 [expires: 2004-02-28] This is my new key. Note the expiration date (or the lack thereof). I created it today upon realization of the expiration date of the above. pub 1024D/C546970C 2004-02-06 Jonathan M. Gardner Key fingerprint = 1687 992A FA8F 4EF8 862D 5E00 AA9E ABFC C546 970C sub 1024g/F4A4CFC0 2004-02-06 - -- Jonathan Gardner jgardner at jonathangardner.net Live Free, Use Linux! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAJUc+qp6r/MVGlwwRAi3FAJ9dsKcEmAtpShZOgHfZG25qdqu0+gCgjKcN h9q7umQIosAK4OpK9cbG0FI= =sfFj -----END PGP SIGNATURE----- From bos at serpentine.com Sat Feb 7 21:38:51 2004 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat, 07 Feb 2004 13:38:51 -0800 Subject: Self-Introduction: Bryan O'Sullivan Message-ID: <1076189931.30161.46.camel@camp4.serpentine.com> Full legal name: Bryan O'Sullivan Country, City: USA, San Francisco Profession or Student status: professional hacker Company or School: representing myself Goals in the Fedora Project: Want to see netplug (http://www.red-bean.com/~bos/) added to Fedora Core, as it's rather extremely useful for both laptops and large clusters. What other projects have I worked on in the past? Everything from DRAM controllers and through kernel hacking, security, databases, up to big distributed systems such as CPU verification tools, Jini (designed part of the original Jini protocols) and BEA WebLogic Server (rewrote much of its security infrastructure). In the recent past, did a little stabilisation work on the 2.5 kernel for x86_64. Currently working on a high-performance 8-million-line GPLed C, C++ and Fortran compiler suite, along with performance tools for Opteron on Linux. What computer languages and other skills do you know? C, C++, Perl, Python, Fortran, Lisp, Haskell, Caml, awk, bash, make, etc, etc. Why should we trust you? Been using Linux for about a decade. Been involved in bit parts of free software projects for about the same time. GPG KEYID and fingerprint pub 1024D/A04AA207 2000-09-15 Bryan O'Sullivan Key fingerprint = F5C1 5C31 36BB FE88 779D A9E7 1BC3 EF1B A04A A207 sub 1152g/E7DC6629 2000-09-15 From wtogami at redhat.com Sun Feb 8 08:31:54 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 07 Feb 2004 22:31:54 -1000 Subject: release candidate zsh configs In-Reply-To: <401F602B.2020301@imapmail.org> References: <401A28E6.3010403@imapmail.org> <401F602B.2020301@imapmail.org> Message-ID: <4025F3FA.6020300@redhat.com> Eric Hattemer wrote: > >> Thanks. :) >> >> Actually it would be good if you could put this rfe into >> bugzilla. That way I won't forgot about it: though I hope >> to take a look at it before too long, it would be very good >> to have a record of the changes there. >> > I will file it two days from now. Sorry that I don't have time at the > moment. > >> >> EH> I would like to remove /etc/skel/.zshrc >> EH> because it is not expected that someone will install >> EH> zsh before adding users. All it does is source >> EH> /etc/profile, which I moved into /etc/zshrc. >> >> Well, no there is a reason for that, see: >> . >> > There is some good discussion there, but I am considering reopening that > bug to get some more ideas about the situation. I suppose the situation > is that redhat wants to give people the ability not to source in bash > /etc/bashrc, or /etc/profile, and allow them to not source in zsh > /etc/zshrc or /etc/profile. That sounds fair that the default .zshrc > can allow them to decide on whether to source the /etc/profile. But the > reason bash can get away with putting things in skel is that its > automatically installed before adduser root, right? zsh is likely to be > added after users are added, and therefore would not copy over the skel > .zshrc, right? Unless the rpm checks to see if each user has a > ~/.zshrc, this may be a problem. This is why I thought sourcing > /etc/profile should be done in /etc/z*, but I suppose that doesn't give > the user a choice to not source /etc/profile. I installed zsh after my > root and eric users. Does the fedora installer copy over > /etc/skel/.zshrc after it adds users? Maybe there is a solution that > would allow all of this to work together. > -Eric Hattemer I just had a thought... Would something like this be inappropriate? If the user runs zsh and ~/.zshrc does not exist but /etc/skel/.zshrc does exist, then copy it into their home directory. Only a small patch to zsh would allow this, and this should not have any drawbacks. Thoughts? Warren From nphilipp at redhat.com Sun Feb 8 09:47:03 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 08 Feb 2004 10:47:03 +0100 Subject: release candidate zsh configs In-Reply-To: <4025F3FA.6020300@redhat.com> References: <401A28E6.3010403@imapmail.org> <401F602B.2020301@imapmail.org> <4025F3FA.6020300@redhat.com> Message-ID: <1076233623.6263.11.camel@wombat.tiptoe.de> On Sun, 2004-02-08 at 09:31, Warren Togami wrote: > I just had a thought... > > Would something like this be inappropriate? > > If the user runs zsh and ~/.zshrc does not exist but /etc/skel/.zshrc > does exist, then copy it into their home directory. Only a small patch > to zsh would allow this, and this should not have any drawbacks. Hmm, somehow this doesn't feel good to me. I'm not a zsh user, but a shell automatically installing a default configuration -- when it would work flawlessly without -- seems strange in my book. If you could get upstream to accept that change, I'd see it differently. At last admins or the zsh user himslef can easily do that manually (admins for all users if they desire to). 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 hattenator at imapmail.org Sun Feb 8 10:27:50 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Sun, 08 Feb 2004 02:27:50 -0800 Subject: release candidate zsh configs In-Reply-To: <1076233623.6263.11.camel@wombat.tiptoe.de> References: <401A28E6.3010403@imapmail.org> <401F602B.2020301@imapmail.org> <4025F3FA.6020300@redhat.com> <1076233623.6263.11.camel@wombat.tiptoe.de> Message-ID: <40260F26.2060804@imapmail.org> Considering that other shells don't do this, it seems strange, although not fundamentally wrong. Someone might delete their .zshrc on purpose, then get it back the next day automatically. But also, if someone ftped into their account, saw all these . files, and randomly started deleting them because they didn't understand them, at least zsh would automatically rebuild that stuff. That's a problem at my university where a .login file is necessary for the default csh to function almost at all. So I agree it would be something you'd have to get zsh.org to accept, and it'd be controversial and different, though not neccessarily logically wrong. -Eric Hattemer Nils Philippsen wrote: >On Sun, 2004-02-08 at 09:31, Warren Togami wrote: > > > >>I just had a thought... >> >>Would something like this be inappropriate? >> >>If the user runs zsh and ~/.zshrc does not exist but /etc/skel/.zshrc >>does exist, then copy it into their home directory. Only a small patch >>to zsh would allow this, and this should not have any drawbacks. >> >> > >Hmm, somehow this doesn't feel good to me. I'm not a zsh user, but a >shell automatically installing a default configuration -- when it would >work flawlessly without -- seems strange in my book. If you could get >upstream to accept that change, I'd see it differently. At last admins >or the zsh user himslef can easily do that manually (admins for all >users if they desire to). > >Nils > > From nphilipp at redhat.com Sun Feb 8 10:51:32 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 08 Feb 2004 11:51:32 +0100 Subject: release candidate zsh configs In-Reply-To: <40260F26.2060804@imapmail.org> References: <401A28E6.3010403@imapmail.org> <401F602B.2020301@imapmail.org> <4025F3FA.6020300@redhat.com> <1076233623.6263.11.camel@wombat.tiptoe.de> <40260F26.2060804@imapmail.org> Message-ID: <1076237492.23695.6.camel@wombat.tiptoe.de> On Sun, 2004-02-08 at 11:27, Eric Hattemer wrote: > Considering that other shells don't do this, it seems strange, although > not fundamentally wrong. Someone might delete their .zshrc on purpose, > then get it back the next day automatically. But also, if someone ftped > into their account, saw all these . files, and randomly started deleting > them because they didn't understand them, at least zsh would > automatically rebuild that stuff. That's a problem at my university > where a .login file is necessary for the default csh to function almost I'd say the user just mustn't do that then ;-). The user can also accidentally move some binary craft into .zshrc which would probably cause it to go berserk and eat his mail ;-). I agree that it would be nice to detect such screwups and _ask_ the user if the default configuration shall be installed over the binary cruft the shell found. But a missing .zshrc is a very valid configuration for me, so that wouldn't apply here. > at all. So I agree it would be something you'd have to get zsh.org to > accept, and it'd be controversial and different, though not neccessarily > logically wrong. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Sun Feb 8 12:01:41 2004 From: buildsys at redhat.com (Build System) Date: Sun, 8 Feb 2004 07:01:41 -0500 Subject: rawhide report: 20040208 changes Message-ID: <200402081201.i18C1fa11708@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20040208 ---------------------------- From ghenry at suretecsystems.com Sun Feb 8 15:54:29 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 8 Feb 2004 15:54:29 +0000 Subject: Security/Updates CD? Message-ID: <200402081554.30141.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I was wondering how difficult (I would do a much as I could) to add an option for install/asking for a security update CD or extra package CD to the installer. So, when installing Fedora you could tick a box and then be asked for a CD with all the latest updates on it, or an extra CD with say Wine3x or Cross overoffice or any other rpms you have. This would be extremely useful for people with modems that buy a CD set form someone. What are everyones thoughts? - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJlu1eWseh9tzvqgRAvxMAKCl8bNcfpH1Vyw1O3kwRjkHe0kj8gCdFkoA fkOIBQD++W6fXBajDPvTjfE= =B/d8 -----END PGP SIGNATURE----- From dhollis at davehollis.com Sun Feb 8 16:00:17 2004 From: dhollis at davehollis.com (David T Hollis) Date: Sun, 08 Feb 2004 11:00:17 -0500 Subject: Security/Updates CD? In-Reply-To: <200402081554.30141.ghenry@suretecsystems.com> References: <200402081554.30141.ghenry@suretecsystems.com> Message-ID: <1076256013.3405.12.camel@dhollis-lnx.kpmg.com> On Sun, 2004-02-08 at 15:54 +0000, Gavin Henry wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > I was wondering how difficult (I would do a much as I could) to add an option > for install/asking for a security update CD or extra package CD to the > installer. > > So, when installing Fedora you could tick a box and then be asked for a CD > with all the latest updates on it, or an extra CD with say Wine3x or Cross > overoffice or any other rpms you have. > > This would be extremely useful for people with modems that buy a CD set form > someone. > > What are everyones thoughts? > Don't you already have this in some form from firstboot? It asks if you want to install other packages from other CDs. I have never looked at what kind of format the other CDs need to be in for it to deal happily with it. Possibly a simple extension from that would be all that is needed. If course, being able to just point it to a website/yum repo/ nfs location would be nice too. -- David T Hollis From ghenry at suretecsystems.com Sun Feb 8 17:34:27 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 8 Feb 2004 17:34:27 +0000 Subject: rpmlint on binary rpm's Message-ID: <200402081734.28921.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Should this be run on binary rpms too? As my src is fine, but the binary has: rpmlint netmon_applet-0.4-0.fdr.1.i386.rpm W: netmon_applet invalid-vendor None W: netmon_applet invalid-distribution None Thanks. - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJnMjeWseh9tzvqgRAtNpAJ9yuEDrPN66GHftP/h4OZUg3ck0LgCdGguq yDYP8WtGy+bpWcY1qTET6Lc= =t0pi -----END PGP SIGNATURE----- From linux at bytebot.net Sun Feb 8 18:01:25 2004 From: linux at bytebot.net (Colin Charles) Date: Mon, 09 Feb 2004 05:01:25 +1100 Subject: Disabled root - by default; up2date more annoying Message-ID: <1076223858.5632.19.camel@hermione> Hi all, some thoughts on end-user improvements follow. As the Linux uptake becomes greater, and Fedora becomes way more popular, and the clueless getting by their daily work as root happens, its only a little while before we have a major "Linux mydoom" styled virus attack (which will give us bad media coverage!). A while back on irc, mharris was also mentioning that folks might not upgrade their software; so even if up2date blinks nastily, nothings going to happen (from a user perspective). So, my proposals: 1. Follow the Mac OS X style of disabling a root login by default. Enable sudo, and the first account that gets created thru the firstboot, gets sudo privileges. Thoughts? 2. up2date blinks a little red icon at the bottom of the screen provided you have a Net connection. *If* a user scrolls across it, it says "30 updates available" for example. How does the typical end-user know what to do? During the user's entire usage of Fedora, (s)he will be having the little blinking red icon! My proposal is to make a pop-up, literally telling you "up2date has found 30 packages". And give a selection list (like what up2date currently provides), and then let the user choose. This can happen once a week once (or at some other time interval), and this ensures that the system is always generally, updated. This may seem like a noisy approach, but if we're targetting the desktop end-user, its probably worthwhile. (Again, stolen from Mac OS X). Thoughts, comments? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ http://fedoranews.org/colin/fnu/ - Fedora News Updates From ms-nospam-0306 at arcor.de Sun Feb 8 18:15:19 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 8 Feb 2004 19:15:19 +0100 Subject: rpmlint on binary rpm's In-Reply-To: <200402081734.28921.ghenry@suretecsystems.com> References: <200402081734.28921.ghenry@suretecsystems.com> Message-ID: <20040208191519.777b6447.ms-nospam-0306@arcor.de> On Sun, 8 Feb 2004 17:34:27 +0000, Gavin Henry wrote: > Should this be run on binary rpms too? > > As my src is fine, but the binary has: > > rpmlint netmon_applet-0.4-0.fdr.1.i386.rpm > W: netmon_applet invalid-vendor None > W: netmon_applet invalid-distribution None Use whatever tools you like, if you think they help you. But don't forget to verify the output of such tools. ;) Note that at fedora.us, for instance, "Packager:", "Vendor:" and "Distribution:" are not used, and the latter two are set by the build system automatically. -- From ghenry at suretecsystems.com Sun Feb 8 19:17:39 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 8 Feb 2004 19:17:39 +0000 Subject: rpmlint on binary rpm's In-Reply-To: <20040208191519.777b6447.ms-nospam-0306@arcor.de> References: <200402081734.28921.ghenry@suretecsystems.com> <20040208191519.777b6447.ms-nospam-0306@arcor.de> Message-ID: <200402081917.42410.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 08 February 2004 18:15, Michael Schwendt wrote: > On Sun, 8 Feb 2004 17:34:27 +0000, Gavin Henry wrote: > > Should this be run on binary rpms too? > > > > As my src is fine, but the binary has: > > > > rpmlint netmon_applet-0.4-0.fdr.1.i386.rpm > > W: netmon_applet invalid-vendor None > > W: netmon_applet invalid-distribution None > > Use whatever tools you like, if you think they help you. But don't forget > to verify the output of such tools. ;) Note that at fedora.us, for > instance, "Packager:", "Vendor:" and "Distribution:" are not used, and the > latter two are set by the build system automatically. > > -- Thanks again Michael. The final version of the specfile is now done. Do you think you could have one last look at it please? http://www.suretecsystems.com/docs/netmon_applet.spec Thanks again. - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJotTeWseh9tzvqgRAptwAJ44au2+ls/RdLQ1mq/qmX5pRifW8gCgkdUe xyVzS0+JP0Toh40R5qt1vJo= =+txN -----END PGP SIGNATURE----- From ville.skytta at iki.fi Sun Feb 8 20:26:12 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 08 Feb 2004 22:26:12 +0200 Subject: rpm --addsign problems In-Reply-To: <200402051140.18408.ghenry@suretecsystems.com> References: <200402051140.18408.ghenry@suretecsystems.com> Message-ID: <1076271971.22286.210.camel@bobcat.mine.nu> On Thu, 2004-02-05 at 13:40, Gavin Henry wrote: > I am trying to sign a SRPM, but issuing rpm --addsign (according to > http://www.fedora.us/wiki/PackageSubmissionQAPolicy) Slightly OT: --addsign for older versions of rpm, where --addsign and --resign are not synonyms, may cause unexpected results here and there as AFAIK rpm has never handled multiple signatures on a single package too well. For newer versions of rpm, --addsign and --resign are exactly the same thing. I've updated the Wiki page to refer to --resign only. From wtogami at redhat.com Sun Feb 8 20:32:57 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 08 Feb 2004 10:32:57 -1000 Subject: Help Request - fedora-rpmdevtools (0.1.7) Message-ID: <40269CF9.7050602@redhat.com> https://bugzilla.fedora.us/show_bug.cgi?id=1167 fedora-rpmdevtools: $TNV (0.1.7) Please comment & test the next revision of the fedora-rpmdevtools package. This version adds and revises some RPM development helper tools. More opinions about the reported fedora-md5 vulnerability would be appreciated too. Warren From notting at redhat.com Sun Feb 8 21:07:34 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 8 Feb 2004 16:07:34 -0500 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> Message-ID: <20040208210734.GA27963@devserv.devel.redhat.com> Mike A. Harris (mharris at redhat.com) said: > >Sounds good to me. I'd love per chipset packaging so that for > >example XFree86-ati-radeon-blah contained the radeon driver, dri .so and > >related bits, but that I can see is a good deal harder to get right > > That is something I definitely want to do in the future also. One of the great benefits of how the OS is distributed now is that, for any hardware supported by the OS, they don't need to go looking for their CDs, or start hitting the network, etc. to get that hardware supported. If you go down this road, you all of a sudden change that, and that's really not good. You also end up having to tie a good deal of logic into installation programs just to get the right package installed. > Also, the driver rpms should have a metadata file included with > them which is essentially like a Windows .INF file, which drops > into a predefined /usr/share/something dir and informs our > config tools what hardware this new driver supports, etc. > Basically a modularized replacement for the ancient Cards > database, and pcitable, where that information is now stored in a > metadata file accompanying the driver. Well, currently, the drivers all have information on what hardware they support included. *Unlike* the kernel drivers, they don't export this in a sane manner. Bill From peter.landy at agentblack.co.uk Fri Feb 6 13:29:25 2004 From: peter.landy at agentblack.co.uk (Peter Landy) Date: Fri, 6 Feb 2004 13:29:25 -0000 (GMT) Subject: Mono on Fedora Message-ID: <44008.62.189.158.225.1076074165.squirrel@jacob.agentblack.co.uk> Has anyone successfully installed Mono on Fedora. I get the Mono base package installed OK but cannot get the MCS complier installed and running. Does anyone have a HowTo on this. Regards Peter Landy From oliverjohntibi at hotmail.com Mon Feb 9 14:32:43 2004 From: oliverjohntibi at hotmail.com (Oliver John Tibi) Date: Mon, 9 Feb 2004 06:32:43 -0800 Subject: Disabled root - by default; up2date more annoying In-Reply-To: <1076223858.5632.19.camel@hermione> Message-ID: It would be very nice to disable the root user for login. Although creating the icon to flash periodically when updates are available (similar to RHN's up2date client), it would also be notable for up2date to update the system on 'silent mode' (daemon mode, if you want); the up2date client may not show a notification icon when updates are available. This option can be configured using an applet for the 'first user' (or the sudo'ed user). Silent updates work perfectly under idle bandwidth, so active updates should not be a problem. O.J. -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com] On Behalf Of Colin Charles Sent: Sunday, February 08, 2004 10:01 AM To: fedora-devel-list at redhat.com Subject: Disabled root - by default; up2date more annoying Hi all, some thoughts on end-user improvements follow. As the Linux uptake becomes greater, and Fedora becomes way more popular, and the clueless getting by their daily work as root happens, its only a little while before we have a major "Linux mydoom" styled virus attack (which will give us bad media coverage!). A while back on irc, mharris was also mentioning that folks might not upgrade their software; so even if up2date blinks nastily, nothings going to happen (from a user perspective). So, my proposals: 1. Follow the Mac OS X style of disabling a root login by default. Enable sudo, and the first account that gets created thru the firstboot, gets sudo privileges. Thoughts? 2. up2date blinks a little red icon at the bottom of the screen provided you have a Net connection. *If* a user scrolls across it, it says "30 updates available" for example. How does the typical end-user know what to do? During the user's entire usage of Fedora, (s)he will be having the little blinking red icon! My proposal is to make a pop-up, literally telling you "up2date has found 30 packages". And give a selection list (like what up2date currently provides), and then let the user choose. This can happen once a week once (or at some other time interval), and this ensures that the system is always generally, updated. This may seem like a noisy approach, but if we're targetting the desktop end-user, its probably worthwhile. (Again, stolen from Mac OS X). Thoughts, comments? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ http://fedoranews.org/colin/fnu/ - Fedora News Updates -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From mandreiana at rdslink.ro Sun Feb 8 22:52:19 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 09 Feb 2004 00:52:19 +0200 Subject: Mono on Fedora In-Reply-To: <44008.62.189.158.225.1076074165.squirrel@jacob.agentblack.co.uk> References: <44008.62.189.158.225.1076074165.squirrel@jacob.agentblack.co.uk> Message-ID: <1076280739.5222.2.camel@marte.biciclete.ro> note: this belongs to fedora-list, not fedora-devel-list. On Fri, 2004-02-06 at 15:29, Peter Landy wrote: > Has anyone successfully installed Mono on Fedora. I get the Mono base > package installed OK but cannot get the MCS complier installed and > running. get mono 0.30 fedora rpms from www.go-mono.com, they install and run fine. Sources work out-of-the-box on fedora too. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From mattdm at mattdm.org Sun Feb 8 22:52:36 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 8 Feb 2004 17:52:36 -0500 Subject: Disabled root - by default; up2date more annoying In-Reply-To: <1076223858.5632.19.camel@hermione> References: <1076223858.5632.19.camel@hermione> Message-ID: <20040208225236.GA29522@jadzia.bu.edu> On Mon, Feb 09, 2004 at 05:01:25AM +1100, Colin Charles wrote: > 1. Follow the Mac OS X style of disabling a root login by default. > Enable sudo, and the first account that gets created thru the firstboot, > gets sudo privileges. Thoughts? For BU Linux, we configure the default X session for root to be a stripped-down environment: metacity with fspanel, with the GUI user configuration tool running and some text explaining about creating a user account. (If someone logs in at the text console, we assume they know what they're doing. Likewise, if they *need* GUI access as root, selecting GNOME or KDE explicitly still works.) We also have modified the GUI tool [1] to add a simple checkbox to add 'wheel' group membership, and set up sudo ALL for members of that group. And beyond that, we use this patch: and updated /etc/security/console.apps files for the various config tools so that they too work for users of the wheel group with sudo-like auth-as-self instead of requiring the root password. [1] this is so far for RHL 9 -- versions for Fedora Core 2 coming soon. The usermode patch has been updated to the latest Fedora devel package, though. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From abel at vallinor4.com Sun Feb 8 23:06:19 2004 From: abel at vallinor4.com (Alexander L. Belikoff) Date: Sun, 8 Feb 2004 18:06:19 -0500 Subject: self-introduction Message-ID: <200402081806.19397.abel@vallinor4.com> Ok, following the http://www.fedora.us/wiki/PackageSubmissionQAPolicy guidelines... ;-) Name: Alexander L. Belikoff Country: USA Profession: Software Developer Company: Bloomberg L.P. Goals: - Help making Fedora Linux the best linux distribution out there, not merely on par with others. - Ensure that Fedora Linux is stable enough for production usage (number crunching, clustering, etc). - Packages I want to see: PVM, frotz, f2c, p2c, svn - Yes, I am doing and I will be doing QA! Historical qualifications: - Projects: Cyrillic HOWTO, ERC (an IRC client for Emacs), misc patches here and there. - Languages: C, C++, Perl, Common Lisp, Java, PHP, others - Dunno :-) GPG: key ID 84242701 pub 1024D/84242701 1999-11-06 Alexander L. Belikoff Key fingerprint = 0D58 A804 1AB1 4CD8 8DA9 424B A86E CD0D 8424 2701 uid Alexander L. Belikoff (a.k.a. Sasha) sub 2048g/BE856296 1999-11-06 Cheers, -- Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9 Bloomberg L.P. 424B A86E CD0D 8424 2701 abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key) From jspaleta at princeton.edu Sun Feb 8 23:56:30 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Sun, 08 Feb 2004 18:56:30 -0500 Subject: Disabled root - by default; up2date more annoying Message-ID: <1076284590.19943.4.camel@goober.localdomain> Colin Charles wrote: 1. Follow the Mac OS X style of disabling a root login by default. Enable sudo, and the first account that gets created thru the firstboot, gets sudo privileges. Thoughts? --- My understanding is that incorporate selinux has a great impact on what 'disabling' root looks like. I'm pretty sure i had a conversation with mkj at one point about the selinux implications for the system tools, the ones we use userhelper and pam_console to ask root password for. I think whatever you wanted to accomplish with sudo, the selinux capabilities make possible in a deeper more secure way. too bad test1 wont have selinux enabled...too play around with this. -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 Mon Feb 9 02:38:45 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 8 Feb 2004 21:38:45 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <20040208210734.GA27963@devserv.devel.redhat.com> References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> <20040208210734.GA27963@devserv.devel.redhat.com> Message-ID: On Sun, 8 Feb 2004, Bill Nottingham wrote: >> >Sounds good to me. I'd love per chipset packaging so that for >> >example XFree86-ati-radeon-blah contained the radeon driver, dri .so and >> >related bits, but that I can see is a good deal harder to get right >> >> That is something I definitely want to do in the future also. > >One of the great benefits of how the OS is distributed now is that, >for any hardware supported by the OS, they don't need to go looking >for their CDs, or start hitting the network, etc. to get that hardware >supported. > >If you go down this road, you all of a sudden change that, and >that's really not good. You also end up having to tie a good deal >of logic into installation programs just to get the right package >installed. I disagree. I think that the "keep it the same forever" approach does not allow existing problems with the current approach to ever be solved. There's also no good reason to believe that packaging things in another way will automatically create the problems you've described. For example, the installer can force all drivers to be installed, and not permit someone to deselect them at install time. It works well in other OS's this way, and there's no reason it can't work in Linux either. Unlike the kernel, which doesn't have a stable binary module ABI, the X server does, so there's no reason why driver modules can't be packaged separately and updated individually as the need arises. With the current method of putting all drivers into one binary blob module with the X server and everything else, a one line driver fix that solves a problem for users but wasnt found until after the OS is released, generally means the user will have to pick up the fix from rawhide, or some one-off unofficial build I do, or they'll have to wait 6 months for the next XFree86 security erratum or something, or the next OS release. We've gotten by "good enough" with that approach, but I personally don't believe "good enough" is good enough. I want to see us do better here, and I think it is both possible to release individual video driver updates, and that it's in our best interest to do so, and to be able to do so. Nobody is forced to put in their CDROM, nor to download them via a network. They do so only if they wish to have that additional option. Right now a user who has video driver problems options include: - Download a new XFree86 update from Red Hat (if any) They have to download up to 150 or more megabytes of largely duplicated binaries, drivers, fonts, and other stuff. Most of this stuff hasn't even changed at all. If they were just doing this for the 1Mb driver update, this is quite wasteful on their bandwidth, our bandwidth, disk space on both sides, and is IMHO a very poor solution. - Wait for the next Red Hat official XFree86 update, which may or may not even solve their problem. We don't release driver updates now, just full XFree86 updates, however a given driver may or may not even have been updated. Many users download new releases in hopes that it may have an updated driver, even if that driver is identical. They're not even aware generally wether or not a driver was updated. There's no easy non-technical way for them to find out. - Download binary drivers from XFree86.org or somewhere else. Not a Red Hat "supported" option, doesn't integrate with the distribution or our tools. An ad-hoc workaround at best, until their vendor (us) has a better solution for them, which currently can be months, if not even longer. There are /many/ cases in which I could fix a driver, or apply patches from upstream, etc. and have a new driver tested in short order via unofficial or "testing" channels, and once enough feedback has been received, I could easily release a "driver update" rpm, containing just the new driver. up2date and/or yum makes it trivial for a user to do updates. In most cases, all the user needs to do then, is restart XFree86 without reconfiguring anything and they're using the new driver. I think that is a very very desireable goal, and a 1Mb driver rpm beats a 150Mb half hour RHN update. ;o) >> Also, the driver rpms should have a metadata file included with >> them which is essentially like a Windows .INF file, which drops >> into a predefined /usr/share/something dir and informs our >> config tools what hardware this new driver supports, etc. >> Basically a modularized replacement for the ancient Cards >> database, and pcitable, where that information is now stored in a >> metadata file accompanying the driver. > >Well, currently, the drivers all have information on what hardware >they support included. *Unlike* the kernel drivers, they don't >export this in a sane manner. The drivers can be dlopen()'d and their functions called by other software. I've never personally tried to do this, but IIRC, the xf86cfg tool does so. I'd have to confirm that however. I'm not sure wether that would be the best approach or not though, but it's something worthy of more research. My basic premise above, is that the current mechanism for packaging, supplying, maintaining, distributing video drivers and updates to users, is not "the best we can do". I _know_ we can do _much_ better, and I believe that there are a lot of benefits both to myself as the maintainer of XFree86, to end users who would like the possibility of getting driver updates sooner than once every 6-12 months, and to Red Hat for having a better solution for customers that meets their needs in a way much closer to what other mainstream operating systems can provide. I don't claim that it is a cakewalk to get there however, nor that there are no obstacles. There are obviously some important issues that would need to be ironed out, including things like the installer, the config tools, and other bits. But if we let things stay as they are now, and never even try to provide a better solution, then we wont ever _have_ a better solution. Rather than having people resist such changes and just state some theoretical problems that might exist if we were to separate out drivers, I would prefer it if people embraced the idea with the thought "this would be good for us all around", and then thought of some real problems it might cause, and then proposed some ideas for how we might go about solving them. For the "the driver didn't get installed when I installed the OS" problem, the solution is simple. We benevolently install all of the drivers without giving anyone any say during installation wether or not they want them all. Also, just for the record... this "split the drivers into separate rpms" idea, is not something I'm trying to force into Fedora Core 2, possibly not even FC3. It's a "we need to get there sometime down the road, how do we go about planning to get there now" idea. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From notting at redhat.com Mon Feb 9 02:54:04 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 8 Feb 2004 21:54:04 -0500 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> <20040208210734.GA27963@devserv.devel.redhat.com> Message-ID: <20040209025401.GB29707@devserv.devel.redhat.com> Mike A. Harris (mharris at redhat.com) said: > >Well, currently, the drivers all have information on what hardware > >they support included. *Unlike* the kernel drivers, they don't > >export this in a sane manner. > > The drivers can be dlopen()'d and their functions called by other > software. The functions aren't at all standard among drivers. I looked at this once. :) Bill From russell at coker.com.au Mon Feb 9 03:26:59 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 9 Feb 2004 14:26:59 +1100 Subject: Disabled root - by default; up2date more annoying In-Reply-To: <1076284590.19943.4.camel@goober.localdomain> References: <1076284590.19943.4.camel@goober.localdomain> Message-ID: <200402091426.59883.russell@coker.com.au> On Mon, 9 Feb 2004 10:56, Jef Spaleta wrote: > My understanding is that incorporate selinux has a great impact on what > 'disabling' root looks like. I'm pretty sure i had a conversation with > mkj at one point about the selinux implications for the system tools, > the ones we use userhelper and pam_console to ask root password for. > I think whatever you wanted to accomplish with sudo, the selinux > capabilities make possible in a deeper more secure way. At the moment with SE Linux we are aiming to have things work much the same as non-SE machines for a default install, this includes having root:sysadm_r logins by default! The problem is that if we block things using SE Linux which otherwise work then many users will just turn off SE Linux to make it work. If something like disabling root logins is to be done then it has to be done without using SE Linux IMHO. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mharris at redhat.com Mon Feb 9 03:50:18 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 8 Feb 2004 22:50:18 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <20040209025401.GB29707@devserv.devel.redhat.com> References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> <20040208210734.GA27963@devserv.devel.redhat.com> <20040209025401.GB29707@devserv.devel.redhat.com> Message-ID: On Sun, 8 Feb 2004, Bill Nottingham wrote: >> >Well, currently, the drivers all have information on what hardware >> >they support included. *Unlike* the kernel drivers, they don't >> >export this in a sane manner. >> >> The drivers can be dlopen()'d and their functions called by other >> software. > >The functions aren't at all standard among drivers. I looked at >this once. :) loadmod.c in xf86cfg appears at least to do this, although it has some comments about the ati and vmware drivers. Not sure if it does exactly what would be needed or not. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From didierbe at sps.nus.edu.sg Mon Feb 9 06:40:19 2004 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Mon, 9 Feb 2004 14:40:19 +0800 (SGT) Subject: problem w/ running opengl/Mesa apps on fc1x Message-ID: Hi all, I noticed that I can no longer run my OpenGL/Mesa apps since I upgraded to FC1. Every time I compile and try to run them I get the following error msg: --------------------------------------------------------- Xlib: extension "XFree86-DRI" missing on display ":0.0". --------------------------------------------------------- My hardware seems to support DRI as a "cat /var/log/XFree86.0.log| grep DRI" gives: (II) Loading extension XFree86-DRI w/ no visible error. I also tried to comment out the line Load "dri" in /etc/X11/XF86Config, but w/ no success. It still gives me this nasty error message! "glxinfo" gives me: =============================================================================== name of display: :0.0 Xlib: extension "XFree86-DRI" missing on display ":0.0". display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 tc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x27 24 dc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x28 24 dc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x29 24 dc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2a 24 dc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None =============================================================================== Can anybody tell me what's wrong w/ the system or if it is some bug? How can I run OpenGL/Mesa apps? With kind regards, Didier. --- PhD student. Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg / didierbe at sps dot nus dot edu dot sg From mharris at redhat.com Mon Feb 9 07:37:11 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 9 Feb 2004 02:37:11 -0500 (EST) Subject: problem w/ running opengl/Mesa apps on fc1x In-Reply-To: References: Message-ID: On Mon, 9 Feb 2004, Didier Casse wrote: >--------------------------------------------------------- >Xlib: extension "XFree86-DRI" missing on display ":0.0". >--------------------------------------------------------- > >My hardware seems to support DRI as a > >"cat /var/log/XFree86.0.log| grep DRI" gives: > >(II) Loading extension XFree86-DRI That does not in any way indicate that your hardware supports DRI. That indicates that the XFree86 config file contains the line ... >w/ no visible error. I also tried to comment out the line > > Load "dri" ... in it, and that the X server has loaded the "dri" X server extension module. This has nothing whatsoever to do with hardware support. Everyone running XFree86 has that line in their log file even if they're using a Trident 8900, as long as the above config file line is present. > >Can anybody tell me what's wrong w/ the system or if it is some bug? How >can I run OpenGL/Mesa apps? Unfortunately, you haven't given any information that is useful to determining what the problem is, nor even stated what video card you are using. This is the fedora development mailing list for discussion of Fedora development issues however, it isn't an end user technical support forum for XFree86 DRI problems. Please subscribe to xfree86-list at redhat.com where this discussion would be on topic, and myself and others will be more than happy to assist you further however. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From didierbe at sps.nus.edu.sg Mon Feb 9 07:46:55 2004 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Mon, 9 Feb 2004 15:46:55 +0800 (SGT) Subject: problem w/ running opengl/Mesa apps on fc1x In-Reply-To: Message-ID: On 09/02/04, at 02:37 -0500, Mike A. Harris wrote: > > Unfortunately, you haven't given any information that is useful > to determining what the problem is, nor even stated what video > card you are using. > > This is the fedora development mailing list for discussion of > Fedora development issues however, it isn't an end user technical > support forum for XFree86 DRI problems. Dear Mike, My Mesa apps used to work w/ earlier versions of RH (i.e RH8 and below) on the same machine where I only changed a Harddisk! I decided to revive them today and realized that they compile correctly but they give the error stated earlier. I think this can also be interpreted as a Fedora issue since some friends ran my program on Debian w/ the latest xfree86 libs and it works fine (On the same brand and configuration of PCs). I just tested on the latest SuSE in the office and guess what? It's also running fine. I will nevertheless post it on the xfree86 list too. With kind regards, Didier. --- PhD student. Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg / didierbe at sps dot nus dot edu dot sg From nos at utel.no Mon Feb 9 08:01:24 2004 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Mon, 09 Feb 2004 09:01:24 +0100 Subject: Spec file help In-Reply-To: <0000054b05092807d4@[192.168.170.10]> References: <0000054b05092807d4@[192.168.170.10]> Message-ID: <000001170104e307d4@[192.168.170.10]> On Fri, 2004-02-06 at 22:39, Karsten Hopp wrote: > On Fri, Feb 06, 2004 at 09:27:23PM +0000, Gavin Henry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Dear all, > > > > I know everyone is extremely busy, but if someone has time to check > over my > > first spec file and give me some feedback/pointers, it would be > greatly > > appreciated. > > > > It was made with Mach and installs on FC1 and RH9 fine. > > > > Thanks, > > > > Gavin. > > > > url: http://www.suretecsystems.com/docs/netmon_applet.spec > > > > > > A few comments: > > > Source0 : > http://www.demonseed.net/~jp/code/netmon_applet/netmon_applet-0.4.tar.gz > It's better to use %{version} here. Otherwise you'd have to change the > version > at two places when you update to p.e. 0.5 Not really. The Source: should be the real URL so QA'ers can copy/paste it for downloading. -- 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 mharris at redhat.com Mon Feb 9 08:02:09 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 9 Feb 2004 03:02:09 -0500 (EST) Subject: problem w/ running opengl/Mesa apps on fc1x In-Reply-To: References: Message-ID: On Mon, 9 Feb 2004, Didier Casse wrote: >> Unfortunately, you haven't given any information that is useful >> to determining what the problem is, nor even stated what video >> card you are using. >> >> This is the fedora development mailing list for discussion of >> Fedora development issues however, it isn't an end user technical >> support forum for XFree86 DRI problems. > > >Dear Mike, > My Mesa apps used to work w/ earlier versions of RH (i.e RH8 >and below) on the same machine where I only changed a Harddisk! I decided >to revive them today and realized that they compile correctly but they >give the error stated earlier. That's fine and dandy, but it isn't on topic on this mailing list. The list is full of off topic junk that makes it hard to follow the few actual development discussions that occur here. Rather than just unsubscribe from the list due to the low S/N ratio, I prefer to tell people to take their off topic questions to alternate lists where they belong, and try to increase the actual amount of real developmental discussion here. >I think this can also be interpreted as a Fedora issue since >some friends ran my program on Debian w/ the latest xfree86 libs >and it works fine (On the same brand and configuration of PCs). >I just tested on the latest SuSE in the office and guess what? >It's also running fine. It may or may not be a Fedora "issue", however it is not a Fedora Core development issue. Send bug reports to bugzilla, send end user technical support requests to fedora-list, send XFree86 help requests to xfree86-list. The only way your message has any relevance on this list, is if you are sitting in the gdb debugger, single stepping through the video driver, and trying to determine why DRI is not working from the development side of things. >I will nevertheless post it on the xfree86 list too. That is the right place for such discussions yes, but not here. If you decide however to debug the X server, be sure to play with ftp://people.redhat.com/mharris/gdb-xfree86 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Nicolas.Mailhot at laPoste.net Mon Feb 9 09:23:50 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 09 Feb 2004 10:23:50 +0100 Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: <1075988553.4747.57.camel@athlon.localdomain> References: <1075988553.4747.57.camel@athlon.localdomain> Message-ID: <1076318630.2104.7.camel@ulysse.olympe.o2t> Le jeu, 05/02/2004 ? 14:42 +0100, Leonard den Ottolander a ?crit : > Hi, > > I tried to add myself to the CC: list of bug #53003, as I want to file a > bug report and patch that should close #53003 as duplicate, but I get > the error: > > You tried to change the component field from AfterStep-APPS to > initscripts, but only the owner or submitter of the bug, or a > sufficiently empowered user, may change that field. That's an old bug - I had it several times last year, never reported it though. Please open a bugzilla bug. 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 mharris at redhat.com Mon Feb 9 09:46:05 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 9 Feb 2004 04:46:05 -0500 (EST) Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: <1076318630.2104.7.camel@ulysse.olympe.o2t> References: <1075988553.4747.57.camel@athlon.localdomain> <1076318630.2104.7.camel@ulysse.olympe.o2t> Message-ID: On Mon, 9 Feb 2004, Nicolas Mailhot wrote: >Date: Mon, 09 Feb 2004 10:23:50 +0100 >From: Nicolas Mailhot >To: fedora-devel-list at redhat.com >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="=-76X7mWNSSJfjwU2irHJ0" >List-Id: Development discussions related to Fedora Core > >Subject: Re: Funny bugzilla error when adding myself to CC: list > >Le jeu, 05/02/2004 ?? 14:42 +0100, Leonard den Ottolander a ??crit : >> Hi, >> >> I tried to add myself to the CC: list of bug #53003, as I want to file a >> bug report and patch that should close #53003 as duplicate, but I get >> the error: >> >> You tried to change the component field from AfterStep-APPS to >> initscripts, but only the owner or submitter of the bug, or a >> sufficiently empowered user, may change that field. > >That's an old bug - I had it several times last year, never reported it >though. Please open a bugzilla bug. It's a bug in your web browser. At least according to Dave Lawrence our bugzilla maintainer. Search bugzilla for bugs that have already been reported about this, including closed bugs. You'll probably find something. Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From de_lupus at pandora.be Mon Feb 9 10:02:14 2004 From: de_lupus at pandora.be (Kristof vansant) Date: Mon, 09 Feb 2004 11:02:14 +0100 Subject: I noticed that kudzu doesn't config OSS emulation is this meant to be? Message-ID: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> I noticed that kudzu doesn't configure OSS emulation is this meant to be? Because I don't think all applications will be alsa ready before the next fc release. I rather see all programme"s use gstreamer but this is to much to wish for :) From cmadams at hiwaay.net Mon Feb 9 11:58:53 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 9 Feb 2004 05:58:53 -0600 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> <20040208210734.GA27963@devserv.devel.redhat.com> Message-ID: <20040209115853.GA1074981@hiwaay.net> Once upon a time, Mike A. Harris said: > Unlike the kernel, which doesn't have a stable binary module ABI, > the X server does, so there's no reason why driver modules can't > be packaged separately and updated individually as the need > arises. How would you actually do this? For example, if you did this today, all the packages would come from the same source RPM. So, an update to one driver would require a rebuild that would bump the release number for all packages (and running up2date or yum would want to fetch all the updated packages). Or will you break up the XFree86 source tree into separate drivers? Will that work? Last time I built XFree86, which was a long time ago, there were a lot of inter-dependencies, so building just one thing was non-trivial. Isn't this the way XFree86 3.x releases were packaged (i.e. a bunch of hardware-specific packages all with the same version-release built from the same source RPM)? Unless you break up the source (so XFree86-ATI-1.2.3-5.i686.rpm and XFree86-nVidia-0.1-1.i386.rpm can exist and be built from separate .src.rpm packages), I don't see this as being a big win. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From buildsys at redhat.com Mon Feb 9 12:03:28 2004 From: buildsys at redhat.com (Build System) Date: Mon, 9 Feb 2004 07:03:28 -0500 Subject: rawhide report: 20040209 changes Message-ID: <200402091203.i19C3SN03957@porkchop.devel.redhat.com> Updated Packages: kudzu-1.1.41-1 -------------- * Thu Jan 29 2004 Bill Nottingham 1.1.41-1 - switch some behaviors on 2.4 vs 2.6 * Fri Dec 05 2003 Jeremy Katz 1.1.40-1 - write out install/remove instead of post-install/pre-remove for modprobe.conf * Fri Nov 21 2003 Bill Nottingham 1.1.39-1 - pci domain support rpmdb-fedora-1.90-0.20040209 ---------------------------- From notting at redhat.com Mon Feb 9 15:26:36 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Feb 2004 10:26:36 -0500 Subject: I noticed that kudzu doesn't config OSS emulation is this meant to be? In-Reply-To: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> References: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> Message-ID: <20040209152635.GC4208@devserv.devel.redhat.com> Kristof vansant (de_lupus at pandora.be) said: > I noticed that kudzu doesn't configure OSS emulation is this meant to > be? It's already in the modprobe.conf.dist file. Bill From rdieter at math.unl.edu Mon Feb 9 15:52:50 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Feb 2004 09:52:50 -0600 Subject: qt-3.3 and QTDIR In-Reply-To: <20040207082701.4589.11774.Mailman@listman.back-rdu.redhat.com> References: <20040207082701.4589.11774.Mailman@listman.back-rdu.redhat.com> Message-ID: <4027ACD2.3070007@math.unl.edu> Any chance of seeing qt-3.3 in FC2? It's -dlopen-opengl option looks promising for improving prelinking... While we're on the subject, redhat's/fedora's default QTDIR has been /usr/lib/qt-3.x for awhile now, which causes at least a small amount of upgrade pain whenever x changes. Is there any good reason (anymore) to not put all qt-3.x installs in a common directory, say something like /usr/lib/qt3? -- Rex From dhollis at davehollis.com Mon Feb 9 16:40:15 2004 From: dhollis at davehollis.com (David T Hollis) Date: Mon, 09 Feb 2004 11:40:15 -0500 Subject: I noticed that kudzu doesn't config OSS emulation is this meant to be? In-Reply-To: <20040209152635.GC4208@devserv.devel.redhat.com> References: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> <20040209152635.GC4208@devserv.devel.redhat.com> Message-ID: <1076344815.14373.3.camel@dhollis-lnx.kpmg.com> On Mon, 2004-02-09 at 10:26 -0500, Bill Nottingham wrote: > Kristof vansant (de_lupus at pandora.be) said: > > I noticed that kudzu doesn't configure OSS emulation is this meant to > > be? > > It's already in the modprobe.conf.dist file. > > Bill One a system I just built from scratch a week ago from Rawhide, I noticed that the /etc/modprobe.conf didn't have the include for modprobe.conf.dist. Happened to notice it when OSS wasn't working for an app. Didn't look into it any further to find out why. In looking at the postinstall for modutils, I have this section: if [ -f /etc/modules.conf -a ! -f /etc/modprobe.conf ] ; then echo "# Note: for use under 2.4, changes must also be made to modules.conf!" >/etc/modprobe.conf echo "include /etc/modprobe.conf.dist" >> /etc/modprobe.conf /sbin/generate-modprobe.conf --stdin < /etc/modules.conf >> /etc/ modprobe.conf 2>/dev/null chmod 644 /etc/modprobe.conf echo "# Note: for use under 2.6, changes must also be made to modprobe.conf!" >> /etc/modules.conf fi Does Anaconda create /etc/modprobe.conf based on what it detects before modutils is installed? If so, it may have/probably failed to put the 'include' statement and modutils didn't add it because modprobe.conf already existed. Just a thought. -- David T Hollis From notting at redhat.com Mon Feb 9 17:00:06 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Feb 2004 12:00:06 -0500 Subject: I noticed that kudzu doesn't config OSS emulation is this meant to be? In-Reply-To: <1076344815.14373.3.camel@dhollis-lnx.kpmg.com> References: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> <20040209152635.GC4208@devserv.devel.redhat.com> <1076344815.14373.3.camel@dhollis-lnx.kpmg.com> Message-ID: <20040209170006.GA9001@devserv.devel.redhat.com> David T Hollis (dhollis at davehollis.com) said: > Does Anaconda create /etc/modprobe.conf based on what it detects before > modutils is installed? If so, it may have/probably failed to put the > 'include' statement and modutils didn't add it because modprobe.conf > already existed. Yeah, anaconda wasn't adding that line until very recently. Longer term, I think we'll just patch modutils to include it by default. Bill From thiers at fosfertil-ultrafertil.com.br Mon Feb 9 18:12:38 2004 From: thiers at fosfertil-ultrafertil.com.br (Thiers Botelho) Date: Mon, 9 Feb 2004 15:12:38 -0300 Subject: RH updates on external packages Message-ID: Hi, I've posted a similar request a while ago on fedora-list and got no answer at all - I suppose it might fit better in here. Some days ago I received, from fedora-announce, info on updated iptables 1.2.9-1.0. That'd be http://www.redhat.com/archives/fedora-announce-list/2004-February/msg00004.html It happens that the announcement mentioned a new config option (IPTABLES_MODULES_UNLOAD), so I went to iptables.org in order to learn some more about it. I couldn't find anything there on the topic ( http://iptables.org/files/changes-iptables-1.2.9.txt ) ; then it downed on me that the Fedora update was 1.2.9-1.0 - this trailing _1.0_ suffix was nowhere to be found on iptables.org (I might as well have missed something there). But the whole point I'd like to understand is more general and not iptables-specific at all . It seems that all updates to FC are published by _someone_at_redhat com_ . So I ask - when RH updates a package in FC, might it make some ADDITIONAL change to the original package ? I'm asking this due to the _1.0_ and to the new switch which was not mentioned on the original changelog. Would someone care to clarify ? Not necessarily on the specific iptables package, but do outside packages receive additional changes before becoming generally available for updating users' systems? Any docs describing this process ? Thnx Thiers From aoliva at redhat.com Mon Feb 9 19:02:56 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Feb 2004 17:02:56 -0200 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Feb 6, 2004, Paul Jakma wrote: > On Fri, 5 Feb 2004, Alexandre Oliva wrote: >> Booting with LVM for the first time, if you have your root >> filesystem in LVM, is a bit tricky. > I dont. There's /no/ value in that IMO. root fs'es should be small > and as easy to boot as possible. Anyone who doesnt have their root > fs's like that is just someone who is waiting to learn a lesson. :) Well, see... /boot is pretty small, but the root filesystem (including /usr) has grown a lot over the past few years. Had I set aside a 5GB partition for that say 2 years ago, since that was a lot more than enough for a full install, I'd hardly be able to do a full install on it nowadays. One of the reasons to use LVM is to make filesystems easier to grow and manage. Say, if I want to install yet another experimental release, I just create a new logical volume for it. No need to go find room for a non-LVM partition in one of the 8 disks on my desktop. >> That said, since it was such a pain to switch back and forth >> between 2.4 and 2.6 in the same tree, I ended up removing 2.6 from >> my FC1 installs, and only using 2.6 in rawhide installs. > Do you mean in general? Or for the case of root-on-lvm only? I think there are some pains to the general case, and greater pains for the root-in-LVM case. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From ms-nospam-0306 at arcor.de Mon Feb 9 19:12:23 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 9 Feb 2004 20:12:23 +0100 Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: References: <1075988553.4747.57.camel@athlon.localdomain> <1076318630.2104.7.camel@ulysse.olympe.o2t> Message-ID: <20040209201223.4ae48048.ms-nospam-0306@arcor.de> On Mon, 9 Feb 2004 04:46:05 -0500 (EST), Mike A. Harris wrote: > >Le jeu, 05/02/2004 ? 14:42 +0100, Leonard den Ottolander a ?crit : > >> Hi, > >> > >> I tried to add myself to the CC: list of bug #53003, as I want to file a > >> bug report and patch that should close #53003 as duplicate, but I get > >> the error: > >> > >> You tried to change the component field from AfterStep-APPS to > >> initscripts, but only the owner or submitter of the bug, or a > >> sufficiently empowered user, may change that field. > > > >That's an old bug - I had it several times last year, never reported it > >though. Please open a bugzilla bug. > > It's a bug in your web browser. At least according to Dave > Lawrence our bugzilla maintainer. I doubt that. Where would the "AfterSteps-APPS" component come from? Above bug #53003 is about "initscripts" _already_ when that bug is triggered. > Search bugzilla for bugs that > have already been reported about this, including closed bugs. > You'll probably find something. -- From cmadams at hiwaay.net Mon Feb 9 19:13:46 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 9 Feb 2004 13:13:46 -0600 Subject: RH updates on external packages In-Reply-To: References: Message-ID: <20040209191346.GB953591@hiwaay.net> Once upon a time, Thiers Botelho said: > I couldn't find anything there on the topic ( > http://iptables.org/files/changes-iptables-1.2.9.txt ) ; then it downed on > > me that the Fedora update was 1.2.9-1.0 - this trailing _1.0_ suffix was > nowhere to be found on iptables.org (I might as well have missed something > there). That is how RPM versioning works. The above package breaks down into: Name: iptables Version: 1.2.9 Release: 1.0 (there is something else called an epoch that can figure in, but don't worry about that right now). The version is generally the upstream (i.e. people who actually wrote the software) version. The release is something specific to the RPM package. That way, if an error is discovered in the packaging, or the upstream releases a patch (maybe without releasing a new version) or someone else produces a useful patch, the RPM release can be raised without changing the version (because it is still based on the same upstream version). For example, say a bug is found in the current FC1 iptables package. Maybe that bug is FC specific, or the upstream maintainers don't consider it necessary to release 1.2.10 at this point. Instead, the package maintainer (someone at Red Hat right now, but that won't always be true) can release a new RPM, iptables-1.2.9-1.1 (or iptables-1.2.9-2). This is still a package based on the iptables.org 1.2.9 version, but a new release of that package for FC1. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ms-nospam-0306 at arcor.de Mon Feb 9 19:20:50 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 9 Feb 2004 20:20:50 +0100 Subject: RH updates on external packages In-Reply-To: References: Message-ID: <20040209202050.6ccff3f0.ms-nospam-0306@arcor.de> On Mon, 9 Feb 2004 15:12:38 -0300, Thiers Botelho wrote: > I've posted a similar request a while ago on fedora-list and got no answer > at all - I suppose it might fit better in here. No, the first half of your message is a user question and suitable for fedora-list. > Some days ago I received, from fedora-announce, info on updated iptables > 1.2.9-1.0. That'd be > > > > http://www.redhat.com/archives/fedora-announce-list/2004-February/msg00004.html > > > It happens that the announcement mentioned a new config option > (IPTABLES_MODULES_UNLOAD), so I went to iptables.org in order to learn > some more about it. Why? It's a feature specific to Red Hat's integration of iptables into the system. Actually, this new option is very good because unloading netfilter connection tracking modules can still lock up. Even in kernel 2.6 it seems. For me it's 100% reproducible with <= Fedora Core 1 kernel on rh73, but also Red Hat Linux 9 (IIRC). -- From paul at dishone.st Mon Feb 9 19:21:16 2004 From: paul at dishone.st (Paul Jakma) Date: Mon, 9 Feb 2004 19:21:16 +0000 (GMT) Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Mon, 9 Feb 2004, Alexandre Oliva wrote: > On Feb 6, 2004, Paul Jakma wrote: > > I dont. There's /no/ value in that IMO. root fs'es should be > > small and as easy to boot as possible. Anyone who doesnt have > > their root fs's like that is just someone who is waiting to learn > > a lesson. :) > Well, see... /boot is pretty small, but the root filesystem > (including /usr) has grown a lot over the past few years. Ah, well, /usr should not be on root IMHO. # df -h / Filesystem Size Used Avail Use% Mounted on /dev/md0 292M 195M 82M 71% / # du -sh /boot/ /root/ 21M /boot 4.1M /root So, FC1 root (at least for this server), excluding /boot and ~root, is 170M. > Had I set aside a 5GB partition for that say 2 years ago, since > that was a lot more than enough for a full install, I'd hardly be > able to do a full install on it nowadays. One of the reasons to > use LVM is to make filesystems easier to grow and manage. Ditto, hence why stuff like /usr should not be on root. > Say, if I want to install yet another experimental release, I just > create a new logical volume for it. No need to go find room for a > non-LVM partition in one of the 8 disks on my desktop. How do resize your root though? Given that it's very difficult to do, from the system itself, it's surely better to have a small root. Eg, I can resize /usr without rebooting. There are other benefits too, eg, the smaller and simpler root is, the lower the likelihood of (hopefully rare) software bugs in fs code hitting my root partition, statistically one would hope these'd be exposed in other bigger and more heavily used partitions than the smallest (and rarely written to) partition on the machine. It's always been best practice to use minimal root fses, i thought? > I think there are some pains to the general case, and greater pains > for the root-in-LVM case. I guess I'll have to do some experimentation with converting from 2.4+LVM1 to 2.6+LVM2 on throwaway installs (eg UML) to see how it goes. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: MS and Y2K: Windows 95, 98, ... and back again to 01 -- Laurent Szyster From thiers at fosfertil-ultrafertil.com.br Mon Feb 9 20:45:42 2004 From: thiers at fosfertil-ultrafertil.com.br (Thiers Botelho) Date: Mon, 9 Feb 2004 17:45:42 -0300 Subject: RH updates on external packages Message-ID: Thnx all. Explained right to the point ! :)) Cheers Thiers From warren at togami.com Mon Feb 9 19:58:16 2004 From: warren at togami.com (Warren Togami) Date: Mon, 09 Feb 2004 09:58:16 -1000 Subject: firefox browser in Extras Message-ID: <4027E658.5040509@togami.com> https://bugzilla.fedora.us/show_bug.cgi?id=1272 firefox submission This needs some fixes and testing before it is suitable for release. Please help if you care about this browser. Warren From aoliva at redhat.com Mon Feb 9 20:15:47 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Feb 2004 18:15:47 -0200 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Feb 9, 2004, Paul Jakma wrote: > Ditto, hence why stuff like /usr should not be on root. Yeah, and /var, etc. I just find it too much of a hassle to keep it all out of /. I used to arrange things like that back in another life as a Solaris sysadmin, but then I'd run out of partitions faster than I'd like. And then, reinstalling things onto a single root filesystem is no big deal anyway. Much simpler than having to create a bunch of new root partitions and other LVs just to do a fresh install on the same box. > How do resize your root though? Booting into another installed OS is the easiest way for me, but there's always the rescue CD. > Eg, I can resize /usr without rebooting. That's something desirable, indeed. I may considering setting up a separate partition for /usr in the future. > There are other benefits too, eg, the smaller and simpler root is, > the lower the likelihood of (hopefully rare) software bugs in fs > code hitting my root partition, statistically one would hope these'd > be exposed in other bigger and more heavily used partitions than the > smallest (and rarely written to) partition on the machine. To enjoy this benefit you *really* need a separate /var too. And unfortunately a significant number of low-level stuff writes to /etc and /dev (lvm and dhcp's resolv.conf munging come to mind) > It's always been best practice to use minimal root fses, i thought? I've always recommended minimal /boot, user stuff in a separate /home or however you want to name it, and the OS stuff in a single partition. It's simple to manage, and is likely to keep the OS more efficient in the long run; fragmenting the root filesystem into multiple partitions tends to generate additional hard disk head movement. Of course the same goes for a separate /home partition, but you really don't want to do without that! -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From ghenry at suretecsystems.com Mon Feb 9 20:22:25 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 9 Feb 2004 20:22:25 +0000 Subject: firefox browser in Extras In-Reply-To: <4027E658.5040509@togami.com> References: <4027E658.5040509@togami.com> Message-ID: <200402092022.30627.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 February 2004 19:58, Warren Togami wrote: > https://bugzilla.fedora.us/show_bug.cgi?id=1272 > firefox submission > > This needs some fixes and testing before it is suitable for release. > Please help if you care about this browser. > > Warren Downloading now. :-) - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJ+wEeWseh9tzvqgRApEVAJsFakY/BL1gAYQcK6+n5XUntUVd9ACgiBSr Re++ciCRwgHMmX8isAkgTSw= =OURf -----END PGP SIGNATURE----- From paul at dishone.st Mon Feb 9 20:51:37 2004 From: paul at dishone.st (Paul Jakma) Date: Mon, 9 Feb 2004 20:51:37 +0000 (GMT) Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Mon, 9 Feb 2004, Alexandre Oliva wrote: > Yeah, and /var, etc. Oh absolutely :) > I just find it too much of a hassle to keep it all out of /. Only if your system lacks decent volume management :) > I used to arrange things like that back in another life as a > Solaris sysadmin, but then I'd run out of partitions faster than > I'd like. And then, reinstalling things onto a single root > filesystem is no big deal anyway. Much simpler than having to > create a bunch of new root partitions and other LVs just to do a > fresh install on the same box. Well, how often do you do install's? The box I'm thinking of upgrading to 2.6+LVM2 from 2.4 LVM1 hasnt been "installed" since RH5.1 or there abouts :) If you're going to be installing new stuff every now and then, seperate partitions again helps - you can "shuggle" stuff around until you have enough contigious partitions free for your new install. And again, LVM helps here: pvmove. In my experience, the /finer/ grained your partitions are, the easier it becomes to rearrange them, as you can be far more selective about how you rearrange things. It also lets you deal with problems far more easily. Eg, it is trivial to deal with /var/spool/mail being full if that is on its own LV, unmount, resize, remount. However, if it is not, you are screwed - you cant unmount /var without taking the machine down to single-user mode. Similarly, if you have /var/tmp/ or /var/lib/cache or whatever on it's own LV, its trivial to unmount that and shrink it (if it has some extra space) if needs be, eg in order to give that space to /var/spool/mail :) Quite handy if you get caught on the hop with respect to system sizing, or if reality decided not to play with your conceptions of disk space needs when you installed and partitioned the machine. Eg, the ratio of mail users keep in folders in /home Vs in their INBOX (ie /var/spool/mail) - you might find the /var/spool/mail is full, while you have many gigs free in your /home LV. 10 minute outage of IMAP/POP3 and SMTP services while you fix it, (but other services dont need to go down) IFF you have "fine grained" partitions. > Booting into another installed OS is the easiest way for me, but > there's always the rescue CD. I view my root fs as my primary rescue partition. Hence, keep it small, keep it as RO as possible (ie /etc should be only dir with regular write activity - try to avoid using ~root for anything other than static shell rc files.) use the safest, most widely tested fs on / (ie ext3, ext2 would be safer, but isnt journalled). > To enjoy this benefit you *really* need a separate /var too. Oh, that goes without saying :) /tmp should be a seperate fs too obviously. (either it's own partition or tmpfs). > And unfortunately a significant number of low-level stuff writes to > /etc and /dev (lvm and dhcp's resolv.conf munging come to mind) Yes, but write's will still be quite rare. (esp if you mount with noatime). > I've always recommended minimal /boot, user stuff in a separate > /home or however you want to name it, and the OS stuff in a single > partition. It's simple to manage, and is likely to keep the OS > more efficient in the long run; fragmenting the root filesystem > into multiple partitions tends to generate additional hard disk > head movement. Well, mostly static partitions shouldnt fragment really. Also, if you're worried about head movement, you can site your most heavily used partition in the middle of the disk, and at least be confident that those heavily used files /are/ in the middle of the disk, not spread across it. (probably the binaries and libs in /usr for a workstation). But how much of a worry is this these days? Optimising volumes to best areas of disk is something I doubt any does any more :) (nearly all my files live on NFS anyway, and then on RAID5 arrays.) > Of course the same goes for a separate /home partition, but you > really don't want to do without that! regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: April 1 This is the day upon which we are reminged of what we are on the other three hundred and sixty-four. -- Mark Twain, "Pudd'nhead Wilson's Calendar" From leonard at den.ottolander.nl Mon Feb 9 21:07:19 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 09 Feb 2004 22:07:19 +0100 Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: <1076318630.2104.7.camel@ulysse.olympe.o2t> References: <1075988553.4747.57.camel@athlon.localdomain> <1076318630.2104.7.camel@ulysse.olympe.o2t> Message-ID: <1076360838.5521.36.camel@athlon.localdomain> Hello Nicolas, > That's an old bug - I had it several times last year, never reported it > though. Please open a bugzilla bug. Might you remember bug #s where this happened to you? So I can verify them and add them to the bug report. TIA. And to Mike, no, this is not a browser bug. How would my browser come up with AfterSteps-APPS? Plus verified in mozilla and konqueror. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ghenry at suretecsystems.com Mon Feb 9 22:46:35 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 9 Feb 2004 22:46:35 +0000 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help Message-ID: <200402092246.41884.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I am trying to help test firefox, but I get errors with mach and I wasn't sure is this should be posted on bugzilla: checking for c++... no checking for g++... no checking for gcc... gcc checking whether the C++ compiler (gcc -O2 -g -march=i386 -mcpu=i686 ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. *** Fix above errors and then restart with "gmake -f client.mk build" make: *** [/usr/src/rpm/BUILD/mozilla/Makefile] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.83042 (%build) ??? Is this my configuration? - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKA3OeWseh9tzvqgRApfvAKCDCuhfXuq0+0Uu2invQRLFurrNZQCfTsuh OOyoZWHWMDiT4M6f9xekbfg= =sIcC -----END PGP SIGNATURE----- From jakub at redhat.com Mon Feb 9 22:49:22 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 9 Feb 2004 17:49:22 -0500 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <200402092246.41884.ghenry@suretecsystems.com> References: <200402092246.41884.ghenry@suretecsystems.com> Message-ID: <20040209224922.GA31589@devserv.devel.redhat.com> On Mon, Feb 09, 2004 at 10:46:35PM +0000, Gavin Henry wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I am trying to help test firefox, but I get errors with mach and I wasn't sure > is this should be posted on bugzilla: > > checking for c++... no > checking for g++... no These 2 lines suggest that you don't have gcc-c++ package installed. Jakub From ghenry at suretecsystems.com Mon Feb 9 23:04:30 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 9 Feb 2004 23:04:30 +0000 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <20040209224922.GA31589@devserv.devel.redhat.com> References: <200402092246.41884.ghenry@suretecsystems.com> <20040209224922.GA31589@devserv.devel.redhat.com> Message-ID: <200402092304.32221.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 February 2004 22:49, Jakub Jelinek wrote: > On Mon, Feb 09, 2004 at 10:46:35PM +0000, Gavin Henry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi all, > > > > I am trying to help test firefox, but I get errors with mach and I wasn't > > sure is this should be posted on bugzilla: > > > > checking for c++... no > > checking for g++... no > > These 2 lines suggest that you don't have gcc-c++ package installed. > > Jakub I followed the mach README and did the minimal install. It should have gcc-c++ any other options to enable this? - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKBH+eWseh9tzvqgRAgebAJ0aOJuuRoKSg5M7BKjHTvnxvsSa8gCfW5oi l1JoN/HMydDrBdlfgiJGPFI= =E+ex -----END PGP SIGNATURE----- From hvdkooij at vanderkooij.org Mon Feb 9 23:40:12 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Tue, 10 Feb 2004 00:40:12 +0100 (CET) Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <200402092304.32221.ghenry@suretecsystems.com> References: <200402092246.41884.ghenry@suretecsystems.com> <20040209224922.GA31589@devserv.devel.redhat.com> <200402092304.32221.ghenry@suretecsystems.com> Message-ID: On Mon, 9 Feb 2004, Gavin Henry wrote: > I followed the mach README and did the minimal install. It should have gcc-c++ > any other options to enable this? Show us the RPM. What do you get from: rpm -qa|grep gcc And while at it, check the libraries: rpm -qa|grep libstd Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From Nicolas.Mailhot at laPoste.net Mon Feb 9 23:43:34 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 10 Feb 2004 00:43:34 +0100 Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: <1076360838.5521.36.camel@athlon.localdomain> References: <1075988553.4747.57.camel@athlon.localdomain> <1076318630.2104.7.camel@ulysse.olympe.o2t> <1076360838.5521.36.camel@athlon.localdomain> Message-ID: <1076370214.1986.1.camel@m222.net81-64-248.noos.fr> Le lun, 09/02/2004 ? 22:07 +0100, Leonard den Ottolander a ?crit : > Hello Nicolas, > > > That's an old bug - I had it several times last year, never reported it > > though. Please open a bugzilla bug. > > Might you remember bug #s where this happened to you? So I can verify > them and add them to the bug report. TIA. I'm sorry I don't remember exactly. These were all cases when I didn't care enough about the bugs to fight the system. > And to Mike, no, this is not a browser bug. How would my browser come up > with AfterSteps-APPS? Plus verified in mozilla and konqueror. I suppose this is js land with a nice component list somewhere. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nphilipp at redhat.com Mon Feb 9 23:52:01 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 10 Feb 2004 00:52:01 +0100 Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <20040209115853.GA1074981@hiwaay.net> References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> <20040208210734.GA27963@devserv.devel.redhat.com> <20040209115853.GA1074981@hiwaay.net> Message-ID: <1076370721.20675.55.camel@wombat.tiptoe.de> On Mon, 2004-02-09 at 12:58, Chris Adams wrote: > Once upon a time, Mike A. Harris said: > > Unlike the kernel, which doesn't have a stable binary module ABI, > > the X server does, so there's no reason why driver modules can't > > be packaged separately and updated individually as the need > > arises. > > How would you actually do this? For example, if you did this today, all > the packages would come from the same source RPM. So, an update to one > driver would require a rebuild that would bump the release number for > all packages (and running up2date or yum would want to fetch all the > updated packages). > > Or will you break up the XFree86 source tree into separate drivers? That'd be a prerequisite, yes. > Will that work? Last time I built XFree86, which was a long time ago, > there were a lot of inter-dependencies, so building just one thing was > non-trivial. These lines in XFree86.spec: [...] # Set enable_sdk to 1 to enable the SDK when an Xserver is built, or 0 to disable %define enable_sdk 1 %if %{with_Xserver} %define with_sdk %{enable_sdk} %else %define with_sdk 0 %endif [...] make me confident that Mike has already thought about the problem ;-). 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 gbpeck at sbcglobal.net Mon Feb 9 23:52:36 2004 From: gbpeck at sbcglobal.net (Gary Peck) Date: Mon, 9 Feb 2004 15:52:36 -0800 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <200402092304.32221.ghenry@suretecsystems.com> References: <200402092246.41884.ghenry@suretecsystems.com> <20040209224922.GA31589@devserv.devel.redhat.com> <200402092304.32221.ghenry@suretecsystems.com> Message-ID: <20040209235236.GA12702@realify.com> On Mon, Feb 09, 2004 at 11:04:30PM +0000, Gavin Henry wrote: > On Monday 09 February 2004 22:49, Jakub Jelinek wrote: > > On Mon, Feb 09, 2004 at 10:46:35PM +0000, Gavin Henry wrote: > > > I am trying to help test firefox, but I get errors with mach and I wasn't > > > sure is this should be posted on bugzilla: > > > > > > checking for c++... no > > > checking for g++... no > > > > These 2 lines suggest that you don't have gcc-c++ package installed. > > I followed the mach README and did the minimal install. It should have gcc-c++ > > any other options to enable this? for some reason, mach doesn't include gcc-c++ in its set of required build packages. i've notified the author but haven't received a reply yet. in the meanwhile, you either have to add "BuildRequires: gcc-c++" to firefox's spec file, or add something like the following to your .machrc file (replacing 'fedora-1-i386-core' with the label of the mach root you're using, if appropriate): packages['fedora-1-i386-core']['build'] = ( packages['fedora-1-i386-core']['build'] + ' gcc-c++' ) gary From warren at togami.com Mon Feb 9 23:59:38 2004 From: warren at togami.com (Warren Togami) Date: Mon, 09 Feb 2004 13:59:38 -1000 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <20040209235236.GA12702@realify.com> References: <200402092246.41884.ghenry@suretecsystems.com> <20040209224922.GA31589@devserv.devel.redhat.com> <200402092304.32221.ghenry@suretecsystems.com> <20040209235236.GA12702@realify.com> Message-ID: <40281EEA.40603@togami.com> Gary Peck wrote: > On Mon, Feb 09, 2004 at 11:04:30PM +0000, Gavin Henry wrote: > >>On Monday 09 February 2004 22:49, Jakub Jelinek wrote: >> >>>On Mon, Feb 09, 2004 at 10:46:35PM +0000, Gavin Henry wrote: >>> >>>>I am trying to help test firefox, but I get errors with mach and I wasn't >>>>sure is this should be posted on bugzilla: >>>> >>>>checking for c++... no >>>>checking for g++... no >>> >>>These 2 lines suggest that you don't have gcc-c++ package installed. >> >>I followed the mach README and did the minimal install. It should have gcc-c++ >> >>any other options to enable this? > > > for some reason, mach doesn't include gcc-c++ in its set of required > build packages. i've notified the author but haven't received a reply > yet. in the meanwhile, you either have to add "BuildRequires: gcc-c++" > to firefox's spec file, or add something like the following to your > .machrc file (replacing 'fedora-1-i386-core' with the label of the mach > root you're using, if appropriate): > > packages['fedora-1-i386-core']['build'] = ( > packages['fedora-1-i386-core']['build'] + ' gcc-c++' ) > > gary > > http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires fedora.us Extras packages generally do not list any BuildRequires that are part of the minimal set as defined by this page. Add fedora-rpmdevtools to your minimal mach environment, and it will automatically pull in everything you need to build anything from fedora.us Extras. Many Red Hat packages will fail, or produce unexpected results though, due to missing or wrong BuildRequires though. We need to fix those eventually. Warren Togami wtogami at redhat.com From g.graham at orrcon.com.au Tue Feb 10 00:01:43 2004 From: g.graham at orrcon.com.au (Gavin Graham) Date: Tue, 10 Feb 2004 10:01:43 +1000 Subject: Building Radeon drivers on 2.6.x kernel rpms. Message-ID: <1076371303.8358.10.camel@localhost.localdomain> Hi, It seems that the kernel headers for 2.6.x are somehow incorrect. I say this as I am trying to build the ATI Radeon drivers and I get the following error message: [root at localhost fglrx]# cd build_mod/ [root at localhost build_mod]# ./make.sh ATI module generator V 2.0 ========================== initializing... Error: XFree86 drm includes at /lib/modules/2.6.1-1.65smp/build/include/../drivers/char/drm do not fit this driver. This driver is designed to only work with X4.1.0 or higher. You can match this by getting Linux kernel 2.4.8 or higher. This has been happening with every release of the Fedora Dev kernel RPMS for 2.6.x and it also happens with Arjan's kernel too. I know there is some issues with the Radeon drivers that need to be overcome for successfull compilation under 2.6.x but this specific problem seems to be moreso with the actual kernel packages. Can anyone shed some light on this?? Regards, -- Gavin Graham Systems Operations Supervisor Orrcon Information Technology Orrcon Pty Ltd P: 07 32740549 E: g.graham at orrcon.com.au F: 07 32740691 M: 0409 897288 WWW: www.orrcon.com.au From leonard at den.ottolander.nl Tue Feb 10 00:07:35 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 10 Feb 2004 01:07:35 +0100 Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: <1076370214.1986.1.camel@m222.net81-64-248.noos.fr> References: <1075988553.4747.57.camel@athlon.localdomain> <1076318630.2104.7.camel@ulysse.olympe.o2t> <1076360838.5521.36.camel@athlon.localdomain> <1076370214.1986.1.camel@m222.net81-64-248.noos.fr> Message-ID: <1076371654.5950.9.camel@athlon.localdomain> Hello Nicolas, > I'm sorry I don't remember exactly. These were all cases when I didn't > care enough about the bugs to fight the system. Any idea of the component and the bug number range? > > And to Mike, no, this is not a browser bug. How would my browser come up > > with AfterSteps-APPS? Plus verified in mozilla and konqueror. > > I suppose this is js land with a nice component list somewhere. Nope. Stripped out any reference to AfterStep from the js in a locally saved version (any component but 3), set the form action with an absolute url and committed, still the same error. If it were a browser bug in js it would suggest Mozilla and Konqueror are using similar js engine code (or repeating the same bugs). Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mharris at redhat.com Tue Feb 10 00:09:28 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 9 Feb 2004 19:09:28 -0500 (EST) Subject: RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc. In-Reply-To: <20040209115853.GA1074981@hiwaay.net> References: <1076065536.6676.7.camel@wombat.tiptoe.de> <20040207115327.GC21830@devserv.devel.redhat.com> <20040208210734.GA27963@devserv.devel.redhat.com> <20040209115853.GA1074981@hiwaay.net> Message-ID: On Mon, 9 Feb 2004, Chris Adams wrote: >> Unlike the kernel, which doesn't have a stable binary module ABI, >> the X server does, so there's no reason why driver modules can't >> be packaged separately and updated individually as the need >> arises. > >How would you actually do this? For example, if you did this today, all >the packages would come from the same source RPM. So, an update to one >driver would require a rebuild that would bump the release number for >all packages (and running up2date or yum would want to fetch all the >updated packages). Simple. Install XFree86-sdk rpm, and then you can recompile a driver src.rpm. Paul Nasrat has put the synaptics driver in fedora.us together, and did up some individual driver rpm files as proof of concept. It is rather trivial stuff really. ;o) >Or will you break up the XFree86 source tree into separate drivers? Who says the drivers will be from XFree86 source? ;o) Maybe they will, maybe they wont. There are lots of places drivers can come from. http://gatos.sf.net http://dri.sf.net http://people.redhat.com/alan etc. etc. etc. >Will that work? Yes, it works now. >Last time I built XFree86, which was a long time ago, there were >a lot of inter-dependencies, so building just one thing was >non-trivial. Depends on what exactly you're trying to build really. For drivers, you need the sdk installed. >Isn't this the way XFree86 3.x releases were packaged (i.e. a bunch of >hardware-specific packages all with the same version-release built from >the same source RPM)? Nope. >Unless you break up the source (so XFree86-ATI-1.2.3-5.i686.rpm >and XFree86-nVidia-0.1-1.i386.rpm can exist and be built from >separate .src.rpm packages), I don't see this as being a big >win. That is exactly the plan Stan. ;o) That is the simple side of things though. I could spend probably 3-4 hours and do all of this by tomorrow. There's a lot of other goodies that can be done too, but for it to be totally user friendly some work in other areas needs to come first. Separate driver rpms overnight, would be useful for people to use, but wouldn't integrate quite perfectly without changes to other things too. I've got plans for those "other things" however, but they haven't left the drawing board yet. That will come in time. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 10 00:12:38 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 9 Feb 2004 19:12:38 -0500 (EST) Subject: Building Radeon drivers on 2.6.x kernel rpms. In-Reply-To: <1076371303.8358.10.camel@localhost.localdomain> References: <1076371303.8358.10.camel@localhost.localdomain> Message-ID: On Tue, 10 Feb 2004, Gavin Graham wrote: >It seems that the kernel headers for 2.6.x are somehow incorrect. I seriously doubt that. >I say this as I am trying to build the ATI Radeon drivers and I get the >following error message: > >[root at localhost fglrx]# cd build_mod/ >[root at localhost build_mod]# ./make.sh >ATI module generator V 2.0 >========================== >initializing... >Error: >XFree86 drm includes at >/lib/modules/2.6.1-1.65smp/build/include/../drivers/char/drm do not fit >this driver. >This driver is designed to only work with X4.1.0 or higher. >You can match this by getting Linux kernel 2.4.8 or higher. > > >This has been happening with every release of the Fedora Dev kernel RPMS >for 2.6.x and it also happens with Arjan's kernel too. Tough luck. ;o) >I know there is some issues with the Radeon drivers that need to be >overcome for successfull compilation under 2.6.x but this specific >problem seems to be moreso with the actual kernel packages. > >Can anyone shed some light on this?? support at ati.com? Seriously, see bug #73733 in bugzilla. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Nicolas.Mailhot at laPoste.net Tue Feb 10 00:14:13 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 10 Feb 2004 01:14:13 +0100 Subject: Funny bugzilla error when adding myself to CC: list In-Reply-To: <1076371654.5950.9.camel@athlon.localdomain> References: <1075988553.4747.57.camel@athlon.localdomain> <1076318630.2104.7.camel@ulysse.olympe.o2t> <1076360838.5521.36.camel@athlon.localdomain> <1076370214.1986.1.camel@m222.net81-64-248.noos.fr> <1076371654.5950.9.camel@athlon.localdomain> Message-ID: <1076372053.2719.1.camel@m222.net81-64-248.noos.fr> Le mar, 10/02/2004 ? 01:07 +0100, Leonard den Ottolander a ?crit : > Hello Nicolas, > > > I'm sorry I don't remember exactly. These were all cases when I didn't > > care enough about the bugs to fight the system. > > Any idea of the component and the bug number range? None at all ;(. It did happen to me often enough last year I know exactly what you're talking about (query, find related bug, try to add a comment, and bugzilla complains you tried to reassign to Afterstep) 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 ghenry at suretecsystems.com Tue Feb 10 00:17:36 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 10 Feb 2004 00:17:36 +0000 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <40281EEA.40603@togami.com> References: <200402092246.41884.ghenry@suretecsystems.com> <20040209235236.GA12702@realify.com> <40281EEA.40603@togami.com> Message-ID: <200402100017.38497.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 February 2004 23:59, Warren Togami wrote: > Gary Peck wrote: > > On Mon, Feb 09, 2004 at 11:04:30PM +0000, Gavin Henry wrote: > >>On Monday 09 February 2004 22:49, Jakub Jelinek wrote: > >>>On Mon, Feb 09, 2004 at 10:46:35PM +0000, Gavin Henry wrote: > >>>>I am trying to help test firefox, but I get errors with mach and I > >>>> wasn't sure is this should be posted on bugzilla: > >>>> > >>>>checking for c++... no > >>>>checking for g++... no > >>> > >>>These 2 lines suggest that you don't have gcc-c++ package installed. > >> > >>I followed the mach README and did the minimal install. It should have > >> gcc-c++ > >> > >>any other options to enable this? > > > > for some reason, mach doesn't include gcc-c++ in its set of required > > build packages. i've notified the author but haven't received a reply > > yet. in the meanwhile, you either have to add "BuildRequires: gcc-c++" > > to firefox's spec file, or add something like the following to your > > .machrc file (replacing 'fedora-1-i386-core' with the label of the mach > > root you're using, if appropriate): > > > > packages['fedora-1-i386-core']['build'] = ( > > packages['fedora-1-i386-core']['build'] + ' gcc-c++' ) > > > > gary > > http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires > fedora.us Extras packages generally do not list any BuildRequires that > are part of the minimal set as defined by this page. > > Add fedora-rpmdevtools to your minimal mach environment, and it will > automatically pull in everything you need to build anything from > fedora.us Extras. Many Red Hat packages will fail, or produce > unexpected results though, due to missing or wrong BuildRequires though. > We need to fix those eventually. Thanks, I will try this tomorrow, as I'm off to bed now. I thought you all used mach to test rpm builds, or do you have standalone build machines with no -devel rpm's installed, like your howto says. Gavin. > Warren Togami > wtogami at redhat.com - -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKCMgeWseh9tzvqgRAj6aAJ0bKgvQDAOd0mKjTRi7TGbzXR7fkQCeLpQw 9nU8c5eoFMRikamRAu/oo7k= =J8w7 -----END PGP SIGNATURE----- From warren at togami.com Tue Feb 10 01:04:02 2004 From: warren at togami.com (Warren Togami) Date: Mon, 09 Feb 2004 15:04:02 -1000 Subject: firefox-0.8-0.fdr.2.src.rpm mach rebuild help In-Reply-To: <200402100017.38497.ghenry@suretecsystems.com> References: <200402092246.41884.ghenry@suretecsystems.com> <20040209235236.GA12702@realify.com> <40281EEA.40603@togami.com> <200402100017.38497.ghenry@suretecsystems.com> Message-ID: <40282E02.6070408@togami.com> Gavin Henry wrote: >>>http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires >>>fedora.us Extras packages generally do not list any BuildRequires that >>>are part of the minimal set as defined by this page. >>> >>>Add fedora-rpmdevtools to your minimal mach environment, and it will >>>automatically pull in everything you need to build anything from >>>fedora.us Extras. Many Red Hat packages will fail, or produce >>>unexpected results though, due to missing or wrong BuildRequires though. >>> We need to fix those eventually. > > > Thanks, I will try this tomorrow, as I'm off to bed now. I thought you all > used mach to test rpm builds, or do you have standalone build machines with > no -devel rpm's installed, like your howto says. > > Gavin. > The HOWTO says both mach and the less perfect "uninstall everything" method are both methods of finding BuildRequires. The latter method is problematic for many reasons and mainly if you are too lazy to use mach. The latter method is usually done with chroots and not a standalone system. Warren From aoliva at redhat.com Tue Feb 10 01:07:32 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Feb 2004 23:07:32 -0200 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Feb 9, 2004, Paul Jakma wrote: > On Mon, 9 Feb 2004, Alexandre Oliva wrote: >> I just find it too much of a hassle to keep it all out of /. > Only if your system lacks decent volume management :) Well... See, creating/renaming/removing one LV is still easier than doing it on 3-5 LVs. No matter how decent such management is. > Well, how often do you do install's? I never upgrade, and I try to test every test release and then some more. So, it's pretty often. > If you're going to be installing new stuff every now and then, > seperate partitions again helps - you can "shuggle" stuff around > until you have enough contigious partitions free for your new > install. And again, LVM helps here: pvmove. But see, you don't need the space to be contiguous, that's one of the beauties of LVM. You can do live pvmove and optimize the system for whatever use you like (see LVreorg in my home page). Having to use separate root partitions would be sort of a nightmare. Really, even if I were to keep separate root filesystems, I'd probably still want to use LVM for them. > Similarly, if you have /var/tmp/ or /var/lib/cache or whatever on > it's own LV, its trivial to unmount that and shrink it (if it has > some extra space) if needs be, eg in order to give that space to > /var/spool/mail :) Yeah. I can tell you like having lots of separate filesystems, and this is surely suitable for the install once and then upgrade. It's not all that convenient for my frequent installs from scratch though. Besides, these machines are pretty much single-user anyway, and I can afford to bring any of them down for maintenance at any time. It's just my personal home office anyway. > INBOX (ie /var/spool/mail) - you might find the /var/spool/mail is > full, while you have many gigs free in your /home LV. Well, for one, /var/spool/mail is a soft link to a directory in a huge filesystem for me. Ditto for mqueue. Such that, when I do a full install, I don't lose mail spool or queued mail. And I've got kickstart scripts that set these links up. >> fragmenting the root filesystem into multiple partitions tends to >> generate additional hard disk head movement. > Well, mostly static partitions shouldnt fragment really. I'm talking about fragmenting data across multiple partitions. If you install a package onto a single filesystems, odds are that all of the data files, libraries and binaries will be close to each other in the disk. But if you have say libs in one partition, binaries in another, config files in another and data files in yet another, there's going to be a lot of disk heads movement that you could have saved by using a single filesystem. > Optimising volumes to best areas of disk is something I doubt any > does any more :) Because filesystems tend to do it for you, to a point. But by breaking filesystems up into small pieces, you stop it from helping you. > (nearly all my files live on NFS anyway, and then on RAID5 arrays.) Well, we all know how slow RAID 5 is. I've recently moved most of my data to RAID 1 + LVM, and performance has improved significantly. I only keep multi-media, seldom modified data in RAID 5, just to save a few hundred GiBs I'd waste with RAID 1. All that said, there's a lot of room for personal preferences and for different install/upgrade strategies. I'm probably jumping out of this thread for now :-) Thanks for your insights. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From katzj at redhat.com Tue Feb 10 01:30:22 2004 From: katzj at redhat.com (katzj at redhat.com) Date: Mon, 9 Feb 2004 18:30:22 -0700 Subject: test Message-ID: <200402100130.i1A1UNb25922@mx1.redhat.com> ?????G?????X??R?}m?8????I8c?o??D??J^;??}?I:DcI??l0,?3??[,?4?\??u?!????????G!?N??9?A????^{b?H????^V?0???????n?????S?\?x?B????&x?U?P???L???L?` T??s????m???,?Y???\Wm??xd3?????r\OO???????8???r??h?~?g?????a2V??fS%?R ?h|0??v??G???5??Pm???S????S? ????)p???w???G?l4???N???? ????-'rm??.F|?!~???b??????qV?k??U?G?5????z??D|?J???NX?H??M???2ar?e&f????z /?If?]&???>|v?ov??y???I_?wutY??$?????f??NJ???? H?H?;??HQ?????0????????.P???Jnn?U?.?$??etM?Hc?O ?G??Sogv??(?u???"03?g*??"?v8Ly???d??????{#??CWF???[????TY'?f?8zM?U? ???-/K????CJ?XN??Q?u?$?????o????Wr????H`?-i??d??2???)Xy?f73?)c A??Ex?s??N1??U?I?-D? m??79~??\???,???\??5??T?N?][*?aM??g}t?????Y??$Wth? M??;?\8s????????09?G??~!??C ???0?o?6P???hS?X?-k?~&T???ZS??v?E]?7?????WmY???7???v8?.#Qh????lN?"5w!???D?V???/??????Rp???v??/s?)S"?b~?7k???">9<{?`???T?%???? ??~?;??V?*dF?6y-?>?A???????s?YY??_????$-??a????;>E?cnb?)???H?h&?P?~73????V;)N\?v"??W\?'???&m?'?4????:???]] ?s{\T?????s?????MT?MF? ?^!?s??????FBv?gK???\N?^?A??9????h??????9?n,???1"*"??[i????y???Q???1RPR4?zv?i?F??? -------------- next part -------------- A non-text attachment was scrubbed... Name: message.pif Type: application/octet-stream Size: 22528 bytes Desc: not available URL: From paul at dishone.st Tue Feb 10 01:47:23 2004 From: paul at dishone.st (Paul Jakma) Date: Tue, 10 Feb 2004 01:47:23 +0000 (GMT) Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: On Tue, 9 Feb 2004, Alexandre Oliva wrote: > Well... See, creating/renaming/removing one LV is still easier > than doing it on 3-5 LVs. No matter how decent such management is. Not if you must boot to a rescue CD to do it. Besides, the shell takes care of repetition for me :). > But see, you don't need the space to be contiguous, that's one of > the beauties of LVM. You can do live pvmove and optimize the > system for whatever use you like (see LVreorg in my home page). Right. Whether you have one or many LVs make no difference though. > Well, for one, /var/spool/mail is a soft link to a directory in a > huge filesystem for me. Surely that is what is mount and /etc/fstab are for? :) (though, mine is a symlink too, but due to autofs). > I'm talking about fragmenting data across multiple partitions. If > you install a package onto a single filesystems, odds are that all > of the data files, libraries and binaries will be close to each > other in the disk. But if you have say libs in one partition, > binaries in another, config files in another and data files in yet > another, there's going to be a lot of disk heads movement that you > could have saved by using a single filesystem. For a set of filesystems on a single disk or RAID1 system, possibly yes. However, for many-spindles + RAID + LVM, you've already ceded some control over which blocks are used. Especially if your system has been in use for quite a while and you have resized and created and deleted LVs, your free physical extents themselves will be fragmented, and so subvert some of the clustering optimisations the fs tries to do. As of course will fragmentation within the FS itself have reduced locality. So, unless you size capacity such that you are guaranteed to _always_ have more than plenty, fragmentation _will_ come into play. If you do intend to actually use the capacity you have, instead, just optimise your disk setup for the general case, try improve the worst-case (even if at the expense of best-case). (as many spindles as possible, appropriately RAIDed). Ie, I'd much rather have a storage system whose performance was a steadyish line than a bell curve (eg many spindle RAID versus a single disk for seek times). Even if the curve's best-case was significantly higher than the steady-line best-case (though not too much obviously). Because then, fragmentation is simply not something to get worried about, and I have better things to worry about. :) > Because filesystems tend to do it for you, to a point. But by > breaking filesystems up into small pieces, you stop it from helping > you. Depends. > Well, we all know how slow RAID 5 is. Read is OK. Write sucks. But it was best compromise between space and efficiency. That has perhaps changed given todays humungous drive sizes. Seek time beats RAID1 though. HPA's RAID6 code seems interesting. I've not seen performance numbers for it though. > I've recently moved most of my data to RAID 1 + LVM, and > performance has improved significantly. I only keep multi-media, > seldom modified data in RAID 5, just to save a few hundred GiBs I'd > waste with RAID 1. Well, I have 36GB of space across 6 9GB spindles. Trying to eek out every GB because SCSI disks are just so damn expensive/GB. Will move to SATA and software RAID I think. RAID1 across 2 SATA spindles would probably provide 200GB useable storage as well as better performance! (how times change, RIP SCSI.). > All that said, there's a lot of room for personal preferences and for > different install/upgrade strategies. Absolutely. :) > I'm probably jumping out of this thread for now :-) And same, it has meandered slightly :) > Thanks for your insights. And yours. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: It's better to burn out than it is to rust. From salimma at fastmail.fm Tue Feb 10 01:54:16 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 10 Feb 2004 08:54:16 +0700 Subject: firefox browser in Extras In-Reply-To: <4027E658.5040509@togami.com> References: <4027E658.5040509@togami.com> Message-ID: <1076378056.3147.8.camel@localhost.localdomain> On Mon, 2004-02-09 at 09:58 -1000, Warren Togami wrote: > https://bugzilla.fedora.us/show_bug.cgi?id=1272 > firefox submission > Wonder when they'll stop changing names ... :) Thankfully this time the only Firefox I'm aware of is the novel+movie in which a traumatized Vietnam vet was sent by the CIA to steal a Russian thought-controlled plane. Let's hope MPAA lawyers are not as loony as SCO's. Fingers crossed... - 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 cornette at insight.rr.com Tue Feb 10 02:12:40 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Mon, 09 Feb 2004 21:12:40 -0500 Subject: I noticed that kudzu doesn't config OSS emulation is this meant to be? In-Reply-To: <20040209152635.GC4208@devserv.devel.redhat.com> References: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> <20040209152635.GC4208@devserv.devel.redhat.com> Message-ID: <40283E18.7040502@insight.rr.com> Bill Nottingham wrote: > Kristof vansant (de_lupus at pandora.be) said: > >>I noticed that kudzu doesn't configure OSS emulation is this meant to >>be? > > > It's already in the modprobe.conf.dist file. > > Bill > > They are in this file. My sound did not work though until I added them to the /etc/modprobe.conf file. I didn't have usb either until I added the below to the file. (This is a development install from early January) include /etc/modprobe.conf.dist alias eth0 3c59x alias eth1 3c59x alias eth2 ne2k-pci alias usbdevfs usbcore alias usb-uhci uhci-hcd alias usb-ohci ohci-hcd alias uhci uhci-hcd alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-slot-0 snd-intel8x0 The below line in the file is cryptic to me. I guess it probes the entry for sound-slot-0 and tries to do something with the audio mixer. I don't know the answer though. install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : I took the entries out of my /etc/rc.local file and rebooted and got sound with these added entries. For usb, I forgot to add usbcore and modprobed usbcore after the system was up. Also, reading the entries of the /etc/modprobe.conf.dist file, I got the impression that it was some sort of a 2.4 to 2.6 modules cross-reference index. If this isn't the purpose of the file and there is no cross-reference index for 2.4 to 2.6 kernel module name changes, there should be and maybe easier conversion from 2.6 configurations to 2.4 kernel configurations could be achieved. Just comments. I hope they are constructive. Jim From cornette at insight.rr.com Tue Feb 10 03:01:08 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Mon, 09 Feb 2004 22:01:08 -0500 Subject: Way OT: Redhat addresses caught by My ISP mail scanner Message-ID: <40284974.3040200@insight.rr.com> This is really off topic, but a concern I would like to see if it could be corrected. The message header that my ISP scanner caught was from several Redhat addresses (bogus, I realize) The header contained this information on the virus screened mail. I usually just delete the message and move on. Since it came from this list, shortly after I posted the messed up modprobe.conf file. I think that a clue might be someone infiltrating through the web interface or is still an active subscriber. Maybe your log files can determine if the perpretrator was doing something during the time or if the messages are being intercepted, contents changed or whatever. sorry for the way off topic post. Jim Excerpt below: Received: (from mail at localhost) by int-mx1.corp.redhat.com (8.11.6/8.11.6) id i1A1UQ305370 for fedora-devel-list at listman.back-rdu.redhat.com; Mon, 09 Feb 2004 20:30:26 -0500 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with SMTP id i1A1UQi05366 for ; Mon, 09 Feb 2004 20:30:26 -0500 Received: from redhat.com (63-227-125-122.dnvr.qwest.net [63.227.125.122]) by mx1.redhat.com (8.11.6/8.11.6) with SMTP id i1A1UNb25922 for ; Mon, 09 Feb 2004 20:30:23 -0500 Date: Mon, 09 Feb 2004 18:30:22 -0700 From: katzj at redhat.com Subject: test Sender: fedora-devel-list-admin at redhat.com To: fedora-devel-list at redhat.com Errors-to: fedora-devel-list-admin at redhat.com Reply-to: fedora-devel-list at redhat.com Message-id: <200402100130.i1A1UNb25922 at mx1.redhat.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_bdrg1QgPFznp6zWNkLhQvw)" -- A friend of mine won't get a divorce, because he hates lawyers more than he hates his wife. From salimma at fastmail.fm Tue Feb 10 03:11:17 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 10 Feb 2004 10:11:17 +0700 Subject: Way OT: Redhat addresses caught by My ISP mail scanner In-Reply-To: <40284974.3040200@insight.rr.com> References: <40284974.3040200@insight.rr.com> Message-ID: <1076382677.3147.11.camel@localhost.localdomain> On Mon, 2004-02-09 at 22:01 -0500, Jim Cornette wrote: > This is really off topic, but a concern I would like to see if it could > be corrected. > > The message header that my ISP scanner caught was from several Redhat > addresses (bogus, I realize) > It is on the mailing list archive as well. Perhaps Listman should be configured to screen attachments of types that should not be seen (. pif, .exe) and warn the list admin? - 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 tadams-lists at myrealbox.com Tue Feb 10 03:51:51 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Mon, 09 Feb 2004 22:51:51 -0500 Subject: Way OT: Redhat addresses caught by My ISP mail scanner In-Reply-To: <1076382677.3147.11.camel@localhost.localdomain> References: <40284974.3040200@insight.rr.com> <1076382677.3147.11.camel@localhost.localdomain> Message-ID: <1076385111.1982.6.camel@aurora.localdomain> Or it could possible also use clamscan to scan for viruses. Trever On Tue, 2004-02-10 at 10:11 +0700, Michel Alexandre Salim wrote: > On Mon, 2004-02-09 at 22:01 -0500, Jim Cornette wrote: > > This is really off topic, but a concern I would like to see if it could > > be corrected. > > > > The message header that my ISP scanner caught was from several Redhat > > addresses (bogus, I realize) > > > It is on the mailing list archive as well. Perhaps Listman should be > configured to screen attachments of types that should not be seen (. > pif, .exe) and warn the list admin? > > - Michel -- "He that demands mercy, and shows none, ruins the bridge over which he himself is to pass." -- Thomas Adams, 1612-1653 From katzj at redhat.com Tue Feb 10 04:33:20 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Feb 2004 23:33:20 -0500 Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: Message-ID: <1076387600.22894.5.camel@isengard> On Mon, 2004-02-09 at 15:15, Alexandre Oliva wrote: > On Feb 9, 2004, Paul Jakma wrote: > > How do resize your root though? > > Booting into another installed OS is the easiest way for me, but > there's always the rescue CD. > > > Eg, I can resize /usr without rebooting. > > That's something desirable, indeed. I may considering setting up a > separate partition for /usr in the future. Online resize with ext3... the patch is in the 2.6 kernel builds now unless I missed a commit removing it :) Jeremy From alex.kiernan at thus.net Tue Feb 10 06:16:04 2004 From: alex.kiernan at thus.net (Alex Kiernan) Date: 10 Feb 2004 06:16:04 +0000 Subject: rawhide report: 20040209 changes In-Reply-To: <200402091203.i19C3SN03957@porkchop.devel.redhat.com> References: <200402091203.i19C3SN03957@porkchop.devel.redhat.com> Message-ID: <814qtzlasb.fsf@alexk-laptop.eng.demon.net> Build System writes: > > > > Updated Packages: > > kudzu-1.1.41-1 > -------------- Huh? Didn't the version just go backwards here from the one two days before? From: Build System Subject: rawhide report: 20040207 changes To: fedora-devel-list at redhat.com Date: Sat, 7 Feb 2004 07:54:37 -0500 Reply-To: fedora-devel-list at redhat.com Updated Packages: kudzu-1.1.43-1 -------------- * Fri Feb 06 2004 Bill Nottingham 1.1.43-1 - add patch for smartarray/dac960 devices () * Wed Feb 04 2004 Bill Nottingham 1.1.42-1 - fix segfault on CLASS_NETWORK devices with no device set (#106332) - fix various network device naming snafus (#114611, #113418) -- Alex Kiernan, Principal Engineer, Development, THUS plc From ivg2 at cornell.edu Tue Feb 10 06:42:52 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 10 Feb 2004 01:42:52 -0500 Subject: Compiling Fedora... athlon Message-ID: <40287D6C.4090601@cornell.edu> Hi, Fedora list, I run the following thing: ~80% of fedora core development + most of fedora.us for fedora 1 + most of livna.org for fedora 1 + naoko project for java + ximian project utopia + custom 2.6 kernel ... I think it's fairly representative of what Fedora will look like some time in the distant future. Anyway, I decided to give sources another try and recompile the distro (athlon optimized). The results are rather discouraging. In case anyone cares, here's a list of 94 srpms that fail to compile on my machine for one reason or another, including full logs: http://128.253.214.219/broken/ Full list of rpms installed is rpms.txt. You'll notice those are not only fedora core rpms, but also fedora.us, livna, and naoko. You'll also notice a bunch simply will refuse to install on athlon, but not on 386 (arch was restricted). I am curious as to why (is athlon not a 386 superset?). By the way I consider any failure past the srpm check a bug, so if an important package is missing, I'm sorry, but the srpm didn't tell me I need it. I don't think that's the case for most of the failures. I've submitted bugzillas for several of those (freetype-headers for gnome-print, the tcsh bug, desktop-printing, some of the gnome deprecated bugs ... but I prefer mail as the means for communication. Plus since a bug stayed in rawhide bugzilla for a year and a half before I got a reply, I just don't trust the thing anymore. I'll appreciate any help on getting those 94 packages compiled. If you more need testing from me, please email back. P.S. Why is this list subscription-only? Is my participation unwanted if not subscribed? Certainly get that feeling after my mail did not make it through the moderator for a week or two. From skvidal at phy.duke.edu Tue Feb 10 06:46:04 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 Feb 2004 01:46:04 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <40287D6C.4090601@cornell.edu> References: <40287D6C.4090601@cornell.edu> Message-ID: <1076395564.20129.23.camel@binkley> > P.S. Why is this list subscription-only? Is my participation unwanted > if not subscribed? Certainly get that feeling after my mail did not make > it through the moderator for a week or two. By being subscriber-only it keeps the virus and spam count to a minimum. -sv From ivg2 at cornell.edu Tue Feb 10 06:47:52 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 10 Feb 2004 01:47:52 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <1076395564.20129.23.camel@binkley> References: <40287D6C.4090601@cornell.edu> <1076395564.20129.23.camel@binkley> Message-ID: <40287E98.9020900@cornell.edu> seth vidal wrote: >>P.S. Why is this list subscription-only? Is my participation unwanted >>if not subscribed? Certainly get that feeling after my mail did not make >>it through the moderator for a week or two. > > > By being subscriber-only it keeps the virus and spam count to a minimum. LKML is not subscriber-only. I seen close to zero spam there. From skvidal at phy.duke.edu Tue Feb 10 06:53:10 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 Feb 2004 01:53:10 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <40287E98.9020900@cornell.edu> References: <40287D6C.4090601@cornell.edu> <1076395564.20129.23.camel@binkley> <40287E98.9020900@cornell.edu> Message-ID: <1076395989.20129.27.camel@binkley> > LKML is not subscriber-only. > I seen close to zero spam there. red hat has a lot more lists than just this one. -sv From hvdkooij at vanderkooij.org Tue Feb 10 06:56:47 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Tue, 10 Feb 2004 07:56:47 +0100 (CET) Subject: Compiling Fedora... athlon In-Reply-To: <40287E98.9020900@cornell.edu> References: <40287D6C.4090601@cornell.edu> <1076395564.20129.23.camel@binkley> <40287E98.9020900@cornell.edu> Message-ID: On Tue, 10 Feb 2004, Ivan Gyurdiev wrote: > seth vidal wrote: > >>P.S. Why is this list subscription-only? Is my participation unwanted > >>if not subscribed? Certainly get that feeling after my mail did not make > >>it through the moderator for a week or two. > > > > > > By being subscriber-only it keeps the virus and spam count to a minimum. > > LKML is not subscriber-only. > I seen close to zero spam there. So? Subscriber-only is the standard on most mailinglist for sensible purposes. (And not just to keep spam out.) Hugo. PS: We DO have at least one infection among the subscribers. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From ivg2 at cornell.edu Tue Feb 10 07:06:40 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 10 Feb 2004 02:06:40 -0500 Subject: Compiling Fedora... athlon In-Reply-To: References: <40287D6C.4090601@cornell.edu> <1076395564.20129.23.camel@binkley> <40287E98.9020900@cornell.edu> Message-ID: <40288300.6090701@cornell.edu> > So? Subscriber-only is the standard on most mailinglist for sensible > purposes. (And not just to keep spam out.) Fine. I do not wish to argue over this, but rather over whether the bugs I posted are real or not. The fact of the matter is that I'm the user (as opposed to the developer), and I do not appreciate being forced to subscribe to report bugs. Therefore I am much more likely to not post my bug report at all. I guess it comes down to what's more important to the list... > PS: We DO have at least one infection among the subscribers. That's unfortunate. From dax at gurulabs.com Tue Feb 10 09:12:02 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 10 Feb 2004 02:12:02 -0700 Subject: Keyboard NumLock Message-ID: <1076404322.2817.803.camel@mentor.gurulabs.com> I know this has come up on a number of occasions and heaven knows I've seen student after student bang there head against this. I've been inspecting SUSE closely for a project and I that they do the "right thing". On SUSE the default /etc/syconfig/keyboard file has the following: # NumLock on? ("yes", or "no" or empty or "bios" for BIOS setting) KBD_NUMLOCK="bios" Could we have something like this in RH? Dax Kelson Guru Labs From dax at gurulabs.com Tue Feb 10 09:14:33 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 10 Feb 2004 02:14:33 -0700 Subject: Keyboard NumLock In-Reply-To: <1076404322.2817.803.camel@mentor.gurulabs.com> References: <1076404322.2817.803.camel@mentor.gurulabs.com> Message-ID: <1076404473.2817.809.camel@mentor.gurulabs.com> On Tue, 2004-02-10 at 02:12, Dax Kelson wrote: > I know this has come up on a number of occasions and heaven knows I've > seen student after student bang there head against this. > > I've been inspecting SUSE closely for a project and I that they do the > "right thing". ... and I "note" that they ... From Nigel.Metheringham at dev.InTechnology.co.uk Tue Feb 10 09:30:30 2004 From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham) Date: Tue, 10 Feb 2004 09:30:30 +0000 Subject: I noticed that kudzu doesn't config OSS emulation is this meant to be? In-Reply-To: <40283E18.7040502@insight.rr.com> References: <1076320934.2839.4.camel@D5772921.kabel.telenet.be> <20040209152635.GC4208@devserv.devel.redhat.com> <40283E18.7040502@insight.rr.com> Message-ID: <1076405430.3106.9.camel@angua.localnet> On Tue, 2004-02-10 at 02:12, Jim Cornette wrote: > They are in this file. My sound did not work though until I added them > to the /etc/modprobe.conf file. I didn't have usb either until I added > the below to the file. (This is a development install from early January) This almost certainly doesn't apply to you, but I have a RH9 box with 2.6 kernel and associated packages, where lots of things related to modules weren't working. This was down to the hotplug package being outdated - within its scripts it has some tests for 2.4 & 2.5 kernels and if they are present uses the /lib/modules//modules.* files. The version of hotplug in RH9 does *not* have 2.6 clauses, so treats them the same as 2.2 and below kernels. Updating hotplug to a later version fixed this for me. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From ms-nospam-0306 at arcor.de Tue Feb 10 09:32:20 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 10 Feb 2004 10:32:20 +0100 Subject: RFC: fedora.us bugzilla keywords Message-ID: <20040210103220.31921878.ms-nospam-0306@arcor.de> This is a request for comments on the following proposal: To add a new bugzilla keyword at bugzilla.fedora.us to mark package requests which have been reviewed and approved by one person and which need a second approval. The rational argument behind this is to make another easy bugzilla query possible which returns packages which someone has reviewed already, but which are in need of a second pair of eyes according to the current policies. Without a bugzilla keyword (and without a global tracking ticket), it would be difficult to find such package requests in the database, and especially people new to "reviewing" might want to build teams with other reviewers. Of course, this doesn't have any influence on package requests which only a single reviewer seems to have interest in. But at least they would be more easy to locate, too. ;) First I've thought about adapting bugzilla.redhat.com triage->foo keywords, but these have the drawback, that once set in an additional comment on a bug ticket, they cannot be taken back and would pollute queries. On the contrary, bugzilla keywords [1] can be added/removed arbitrarily, e.g. to withdraw a package approval in case more issues are found. Fedora.us uses the QA keyword to flag packages which are in need of reviews, the NEEDSWORK keyword to indicate a package is not ready yet (being developed further and could need help), and PUBLISH to flag packages which have been approved and which should be built and published in the "pending" preview repository. The keyword I have in mind would be REVIEWED or APPROVED, but I'm open for different suggestions. The first reviewer who approves a package would set the keyword in addition to the existing keywords (including the QA keyword). The second reviewer would replace QA and REVIEWED with PUBLISH if he approves the package, too. Else he would delete the REVIEWED keyword (and possibly set NEEDSWORK upon major issues) to restart the approval process. When only a single approval is needed, the keyword is not used. Feedback appreciated. -- [1] https://bugzilla.fedora.us/describekeywords.cgi -------------- 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 dishone.st Tue Feb 10 09:38:10 2004 From: paul at dishone.st (Paul Jakma) Date: Tue, 10 Feb 2004 09:38:10 +0000 (GMT) Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: <1076387600.22894.5.camel@isengard> References: <1076387600.22894.5.camel@isengard> Message-ID: On Mon, 9 Feb 2004, Jeremy Katz wrote: > Online resize with ext3... the patch is in the 2.6 kernel builds > now unless I missed a commit removing it :) I've never been brave enough to try online-resize. :) > Jeremy regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: Nothing is ever a total loss; it can always serve as a bad example. From warren at togami.com Tue Feb 10 09:57:54 2004 From: warren at togami.com (Warren Togami) Date: Mon, 09 Feb 2004 23:57:54 -1000 Subject: mailman default RedirectMatch problem? Message-ID: <4028AB22.3060104@togami.com> /etc/httpd/conf.d/mailman.conf: # # httpd configuration settings for use with mailman. # ScriptAlias /mailman/ @MMDIR@/cgi-bin/ Alias /pipermail/ @VARMMDIR@/archives/public/ Options +FollowSymlinks # Uncomment the following line, replacing www.example.com with your server's # name, to redirect queries to /mailman to the listinfo page (recommended). # RedirectMatch /mailman[/]*$ http://www.example.com/mailman/listinfo On a FC1 system I uncommented out the bottom line and set my domain name. Then following the REDHAT install directions I created a mailing list called "mailman". Unfortunately this seems to cause problems. http://www.example.com/mailman/ This URL properly redirects to http://www.example.com/mailman/listinfo http://www.example.com/mailman/listinfo/mailman but this URL also redirects to http://www.example.com/mailman/listinfo It seems that the RedirectMatch happens for any directory in the path ending with "/mailman[/]". When I changed the rule to read: RedirectMatch ^/mailman[/]*$ http://www.example.com/mailman/listinfo http://www.example.com/mailman/listinfo/mailman Then this URL works without redirecting by mistake. Is this a good fix to add to the default /etc/httpd/conf.d/mailman.conf? This is currently in the mailman in FC1 testing, so this should revise that test update I think. Warren Togami wtogami at redhat.com From salimma at fastmail.fm Tue Feb 10 10:32:56 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 10 Feb 2004 17:32:56 +0700 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040210103220.31921878.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> Message-ID: <1076409176.3147.25.camel@localhost.localdomain> On Tue, 2004-02-10 at 10:32 +0100, Michael Schwendt wrote: [snip] > The keyword I have in mind would be REVIEWED or APPROVED, but I'm open for > different suggestions. > APPROVED sounds too final, REVIEWED seems a better fit. My 2 cents, - Michel PS should this not be Cc:ed to fedora.us too? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmatilai at welho.com Tue Feb 10 10:49:12 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 10 Feb 2004 12:49:12 +0200 (EET) Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076409176.3147.25.camel@localhost.localdomain> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> Message-ID: On Tue, 10 Feb 2004, Michel Alexandre Salim wrote: > On Tue, 2004-02-10 at 10:32 +0100, Michael Schwendt wrote: > [snip] > > The keyword I have in mind would be REVIEWED or APPROVED, but I'm open for > > different suggestions. > > > APPROVED sounds too final, REVIEWED seems a better fit. Agreed. +1 for the idea in any case, whatever keyword gets chosen. While on the topic of adding keywords to bugzilla - can we please implement at lesat part of Ville's suggestion here: http://www.fedora.us/pipermail/fedora-devel/2003-December/002388.html Just having keywords like "games", "laptop", "perl" etc attached to package submission/QA bug so you could query for packages you are interested in would make finding the interesting packages a whole lot easier. - Panu - From rms at 1407.org Tue Feb 10 10:53:10 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 10:53:10 +0000 Subject: a couple of bugs with development software Message-ID: <1076410390.1422.101.camel@roque> Hello, I've found two annoying bugs (but not critical) with gnome-terminal and evolution. They could be upstream bugs, but I wanted to make sure they're not FC development only bugs first: a) gnome-terminal ignores tab related shortcuts unless menubar is visible (example: alt+n or ctr+pgup or pgdn) b) evolution unable to (configure to?) use maildirs I have a fairly large mail folder, if it's an mbox file than evolution needs almost the double of the free space to alter the mbox (for example, deleting a spam message). [rms at roque rms]$ rpm -q gnome-terminal evolution gnome-terminal-2.5.1-1 evolution-1.5.3-1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Tue Feb 10 11:08:04 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Feb 2004 06:08:04 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <40288300.6090701@cornell.edu> References: <40287D6C.4090601@cornell.edu> <1076395564.20129.23.camel@binkley> <40287E98.9020900@cornell.edu> <40288300.6090701@cornell.edu> Message-ID: <20040210110804.GB10361@devserv.devel.redhat.com> On Tue, Feb 10, 2004 at 02:06:40AM -0500, Ivan Gyurdiev wrote: > > >So? Subscriber-only is the standard on most mailinglist for sensible > >purposes. (And not just to keep spam out.) > > Fine. I do not wish to argue over this, but rather over whether the bugs > I posted are real or not. The fact of the matter is that I'm the user > (as opposed to the developer), and I do not appreciate being forced to > subscribe to report bugs. Therefore I am much more likely to not post my > bug report at all. I guess it comes down to what's more important to the > list... FC should rebuild. Not all the build dependancies are complete, I've found that too and sometimes it'll spit out valid but useless packages depending on order (eg build xmms before the ogg packages and it builds but doesnt play anything 8)) From alan at redhat.com Tue Feb 10 11:11:27 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Feb 2004 06:11:27 -0500 Subject: a couple of bugs with development software In-Reply-To: <1076410390.1422.101.camel@roque> References: <1076410390.1422.101.camel@roque> Message-ID: <20040210111127.GC10361@devserv.devel.redhat.com> On Tue, Feb 10, 2004 at 10:53:10AM +0000, Rui Miguel Seabra wrote: > a) gnome-terminal > ignores tab related shortcuts unless menubar is visible > (example: alt+n or ctr+pgup or pgdn) This is intended behaviour. Those keys may be used by the app running in the text window, so it has to compromise a little From rms at 1407.org Tue Feb 10 11:15:18 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 11:15:18 +0000 Subject: a couple of bugs with development software In-Reply-To: <20040210111127.GC10361@devserv.devel.redhat.com> References: <1076410390.1422.101.camel@roque> <20040210111127.GC10361@devserv.devel.redhat.com> Message-ID: <1076411717.5412.2.camel@roque> On Tue, 2004-02-10 at 06:11 -0500, Alan Cox wrote: > On Tue, Feb 10, 2004 at 10:53:10AM +0000, Rui Miguel Seabra wrote: > > a) gnome-terminal > > ignores tab related shortcuts unless menubar is visible > > (example: alt+n or ctr+pgup or pgdn) > > This is intended behaviour. Those keys may be used by the app running > in the text window, so it has to compromise a little That is an argument for not responding to any shortcut combo at all, and not for ignoring them when the menubar is hidden. The menubar is ortogonal to combo conflicts :) Is there a way to change this other that using the configuration files (those that end in .c for configuration)? Hugs, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rms at 1407.org Tue Feb 10 11:27:04 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 11:27:04 +0000 Subject: a couple of bugs with development software In-Reply-To: <1076411717.5412.2.camel@roque> References: <1076410390.1422.101.camel@roque> <20040210111127.GC10361@devserv.devel.redhat.com> <1076411717.5412.2.camel@roque> Message-ID: <1076412424.5412.16.camel@roque> On Tue, 2004-02-10 at 11:15 +0000, Rui Miguel Seabra wrote: > not for ignoring them when the menubar is hidden. The menubar is > ortogonal to combo conflicts :) Besides that, if there are shortcuts it's because one doesn't want to use the menu-bar. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laposte.net Tue Feb 10 11:56:24 2004 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Feb 2004 12:56:24 +0100 Subject: a couple of bugs with development software In-Reply-To: <1076410390.1422.101.camel@roque> References: <1076410390.1422.101.camel@roque> Message-ID: <1076414184.14762.2.camel@ulysse.olympe.o2t> Le mar, 10/02/2004 ? 10:53 +0000, Rui Miguel Seabra a ?crit : > > b) evolution > unable to (configure to?) use maildirs > > I have a fairly large mail folder, if it's an mbox file than > evolution needs almost the double of the free space to alter the mbox > (for example, deleting a spam message). I concur - evo 1.5-over-nfs is terrible, I add to add a new maildir source to use it (of course, no way to have the maildir replace the default storage, and the . topdir is real annoying) Plus even if one disable spam filtering the virtual spam folders are still displayed and eating up screen estate. 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 rms at 1407.org Tue Feb 10 12:00:31 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 12:00:31 +0000 Subject: a couple of bugs with development software In-Reply-To: <1076414184.14762.2.camel@ulysse.olympe.o2t> References: <1076410390.1422.101.camel@roque> <1076414184.14762.2.camel@ulysse.olympe.o2t> Message-ID: <1076414430.5412.24.camel@roque> On Tue, 2004-02-10 at 12:56 +0100, Nicolas Mailhot wrote: > default storage, and the . topdir is real annoying) In my opinion this is a lovely change, and allowed me to remove the nautilus entry specifying the location of ~/evolution to some non- visible coordinate). But I still think it should be a gconf option (the path) and that by default it should be ~/.XPTO fo any app (I consider broken in this aspect an app that puts visible directories a newbie user would better not touch by himself. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chiodr at kscems.ksc.nasa.gov Tue Feb 10 12:11:39 2004 From: chiodr at kscems.ksc.nasa.gov (Bob Chiodini) Date: Tue, 10 Feb 2004 07:11:39 -0500 Subject: Building Radeon drivers on 2.6.x kernel rpms. In-Reply-To: <1076371303.8358.10.camel@localhost.localdomain> References: <1076371303.8358.10.camel@localhost.localdomain> Message-ID: <1076415099.21720.4.camel@tweedy.ksc.nasa.gov> On Mon, 2004-02-09 at 19:01, Gavin Graham wrote: > Hi, > > It seems that the kernel headers for 2.6.x are somehow incorrect. > I say this as I am trying to build the ATI Radeon drivers and I get the > following error message: > > [root at localhost fglrx]# cd build_mod/ > [root at localhost build_mod]# ./make.sh > ATI module generator V 2.0 > ========================== > initializing... > Error: > XFree86 drm includes at > /lib/modules/2.6.1-1.65smp/build/include/../drivers/char/drm do not fit > this driver. > This driver is designed to only work with X4.1.0 or higher. > You can match this by getting Linux kernel 2.4.8 or higher. > > > This has been happening with every release of the Fedora Dev kernel RPMS > for 2.6.x and it also happens with Arjan's kernel too. > > I know there is some issues with the Radeon drivers that need to be > overcome for successfull compilation under 2.6.x but this specific > problem seems to be moreso with the actual kernel packages. > > Can anyone shed some light on this?? > Gavin, I am running the Radeon Drivers with FC1 and the 2.6.2 kernel. Make sure you've got the latest release from ATI for XFree 4.3.0. There is 2.6 support built in. I've used it with several of the 2.6 kernels without problem. Bob... From Nicolas.Mailhot at laPoste.net Tue Feb 10 12:18:16 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 10 Feb 2004 13:18:16 +0100 Subject: a couple of bugs with development software In-Reply-To: <1076414430.5412.24.camel@roque> References: <1076410390.1422.101.camel@roque> <1076414184.14762.2.camel@ulysse.olympe.o2t> <1076414430.5412.24.camel@roque> Message-ID: <1076415496.15667.2.camel@ulysse.olympe.o2t> Le mar, 10/02/2004 ? 12:00 +0000, Rui Miguel Seabra a ?crit : > On Tue, 2004-02-10 at 12:56 +0100, Nicolas Mailhot wrote: > > default storage, and the . topdir is real annoying) > > In my opinion this is a lovely change, and allowed me to remove the > nautilus entry specifying the location of ~/evolution to some non- > visible coordinate). I agree (even if an .etc and .share used by all apps would have been way smarter). What I'm talking about is evo maildir handling. Since you can have mail in the root of your maildir, evo maildir tree looks like : maildir . <- . folder |-- folder 1 |-- folder 2 This is real annoying - it eats a line and evo won't let you even rename . 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 redhat.com Tue Feb 10 12:25:26 2004 From: buildsys at redhat.com (Build System) Date: Tue, 10 Feb 2004 07:25:26 -0500 Subject: rawhide report: 20040210 changes Message-ID: <200402101225.i1ACPQG24970@porkchop.devel.redhat.com> Removed package sndconfig Removed package sndconfig Updated Packages: anaconda-9.90-6 --------------- * Fri Feb 06 2004 Anaconda team - built new version from CVS * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 kudzu-1.1.43-1 -------------- * Fri Feb 06 2004 Bill Nottingham 1.1.43-1 - add patch for smartarray/dac960 devices () * Wed Feb 04 2004 Bill Nottingham 1.1.42-1 - fix segfault on CLASS_NETWORK devices with no device set (#106332) - fix various network device naming snafus (#114611, #113418) nss_ldap-207-6 -------------- * Tue Nov 25 2003 Nalin Dahyabhai 207-6 - rebuild * Thu Nov 20 2003 Nalin Dahyabhai 207-5 - fix objectclass and attribute mapping, which failed due to uninitialized fields in mapping index structures, fixed upstream in 210 (#110547) * Mon Nov 10 2003 Nalin Dahyabhai 207-4 - link with the proper libsasl (1 or 2) for the version of OpenLDAP we are linking with (#106801) pam_krb5-2.0.5-1 ---------------- * Fri Oct 10 2003 Nalin Dahyabhai 2.0.4-1 - update to 2.0.4 * Fri Sep 19 2003 Nalin Dahyabhai 2.0.3-1 - update to 2.0.3 * Fri Sep 05 2003 Nalin Dahyabhai 2.0.2-1 - update to 2.0.2 rpmdb-fedora-1.90-0.20040210 ---------------------------- From s.mako at gmx.net Tue Feb 10 12:26:10 2004 From: s.mako at gmx.net (s.mako at gmx.net) Date: Tue, 10 Feb 2004 13:26:10 +0100 (CET) Subject: Self-Introduction: Zoltan Kota Message-ID: 1. Full legal name Zoltan Kota 2. Country, City Hungary, Szeged Germany, Goettingen (until the end of 2004) 3. Profession or Student status Chemist (+ sysadm in the group) 4. Company or School Biological Research Centre, Szeged Max-Planck Institute, Goettingen 5. Your goals in the Fedora Project I want to see pybliographer in Fedora. It's a nice program for handling bibliographic databases. I think there is a need for such a program, since more and more people (eg. scientists) want to do publishing using Linux. 6. Historical qualifications * What other projects have you worked on in the past? I've been involved in the development of pybliographer. I'm working mainly on the documentation and rpm packaging. * What computer languages and other skills do you know? I have worked with bash, perl, python, and C (a bit); php, html, xml. * Why should we trust you? <--- too blunt? I have been using Linux since '97, and I really would like it to provide every tools you may need in everyday work. 7. GPG KEYID and fingerprint pub 1024D/2416EC5C 2004-02-10 Zoltan Kota (Friend of penguins) Key fingerprint = 7910 EC8E E4C4 38CC E4D2 4D66 E83E 2A0B 2416 EC5C sub 1024g/4D195F21 2004-02-10 [expires: 2006-02-09] Zoli From rms at 1407.org Tue Feb 10 12:57:30 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 12:57:30 +0000 Subject: a couple of bugs with development software In-Reply-To: <1076415496.15667.2.camel@ulysse.olympe.o2t> References: <1076410390.1422.101.camel@roque> <1076414184.14762.2.camel@ulysse.olympe.o2t> <1076414430.5412.24.camel@roque> <1076415496.15667.2.camel@ulysse.olympe.o2t> Message-ID: <1076417849.6550.6.camel@roque> On Tue, 2004-02-10 at 13:18 +0100, Nicolas Mailhot wrote: > Le mar, 10/02/2004 ? 12:00 +0000, Rui Miguel Seabra a ?crit : > > On Tue, 2004-02-10 at 12:56 +0100, Nicolas Mailhot wrote: > > > default storage, and the . topdir is real annoying) > > > > In my opinion this is a lovely change, and allowed me to remove the > > nautilus entry specifying the location of ~/evolution to some non- > > visible coordinate). > > I agree (even if an .etc and .share used by all apps would have been way > smarter). > > What I'm talking about is evo maildir handling. Since you can have mail > in the root of your maildir, evo maildir tree looks like : > maildir > . <- . folder > |-- folder 1 > |-- folder 2 > > This is real annoying - it eats a line and evo won't let you even > rename . I think that has to do with compatibility with a local imap server reading your mail folders (which makes it, IMHO, good) :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Tue Feb 10 13:09:18 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 11 Feb 2004 00:09:18 +1100 Subject: yum upgrade Message-ID: <200402110009.18330.russell@coker.com.au> Completing update for pygtk2 - 539/539 Kernel Updated/Installed, checking for bootloader Grub found - making this kernel the default Traceback (most recent call last): File "/usr/bin/yum", line 60, in ? sys.exit(1) File "/usr/share/yum/yummain.py", line 323, in main sys.exit(1) File "/usr/share/yum/pkgaction.py", line 536, in kernelupdate # at the moment, kernel rpms are supposed to grok grub File "/usr/share/yum/up2datetheft.py", line 13, in install_grub import grubcfg File "/usr/share/yum/grubcfg.py", line 12, in ? import iutil File "/usr/share/yum/iutil.py", line 2, in ? import types, os, sys, select, string, stat, signal ImportError: No module named select ---- I installed FC1 (yarrow) from CD and then put in the below /etc/yum.conf and did "yum upgrade". Above is the errors that I get. Is this a known problem? ---- [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 [development] name=Fedora Core $releasever - Development Tree baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/development/i386 [SELinux] name=SELinux repository baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rdieter at math.unl.edu Tue Feb 10 13:28:42 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Feb 2004 07:28:42 -0600 Subject: qt-3.3 and QTDIR In-Reply-To: <20040209170013.27337.65467.Mailman@listman.back-rdu.redhat.com> References: <20040209170013.27337.65467.Mailman@listman.back-rdu.redhat.com> Message-ID: <4028DC8A.3090306@math.unl.edu> Rex Dieter wrote: > Any chance of seeing qt-3.3 in FC2? It's -dlopen-opengl option looks > promising for improving prelinking... > > While we're on the subject, redhat's/fedora's default QTDIR has been > /usr/lib/qt-3.x for awhile now, which causes at least a small amount of > upgrade pain whenever x changes. Is there any good reason (anymore) to > not put all qt-3.x installs in a common directory, say something like > /usr/lib/qt3? FYI, RFE: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115297 -- Rex From Nicolas.Mailhot at laPoste.net Tue Feb 10 13:30:52 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 10 Feb 2004 14:30:52 +0100 Subject: a couple of bugs with development software In-Reply-To: <1076417849.6550.6.camel@roque> References: <1076410390.1422.101.camel@roque> <1076414184.14762.2.camel@ulysse.olympe.o2t> <1076414430.5412.24.camel@roque> <1076415496.15667.2.camel@ulysse.olympe.o2t> <1076417849.6550.6.camel@roque> Message-ID: <1076419852.15993.3.camel@ulysse.olympe.o2t> Le mar, 10/02/2004 ? 12:57 +0000, Rui Miguel Seabra a ?crit : > On Tue, 2004-02-10 at 13:18 +0100, Nicolas Mailhot wrote: > > Le mar, 10/02/2004 ? 12:00 +0000, Rui Miguel Seabra a ?crit : > > > On Tue, 2004-02-10 at 12:56 +0100, Nicolas Mailhot wrote: > > > > default storage, and the . topdir is real annoying) > > > > > > In my opinion this is a lovely change, and allowed me to remove the > > > nautilus entry specifying the location of ~/evolution to some non- > > > visible coordinate). > > > > I agree (even if an .etc and .share used by all apps would have been way > > smarter). > > > > What I'm talking about is evo maildir handling. Since you can have mail > > in the root of your maildir, evo maildir tree looks like : > > maildir > > . <- . folder > > |-- folder 1 > > |-- folder 2 > > > > This is real annoying - it eats a line and evo won't let you even > > rename . > > I think that has to do with compatibility with a local imap server > reading your mail folders (which makes it, IMHO, good) :) Well, sure for compat mails are in the directory itself. But evo don't have to *expose* "." to the user. Either put "." mails directly under the account root, or in "Inbox" (since . would be inbox for your imap server anyway) The way it's done really feels like a last-minute hack. 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 10 14:35:23 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 Feb 2004 15:35:23 +0100 Subject: yum upgrade In-Reply-To: <200402110009.18330.russell@coker.com.au> References: <200402110009.18330.russell@coker.com.au> Message-ID: <20040210153523.1dfc257d@localhost> Russell Coker wrote : > I installed FC1 (yarrow) from CD and then put in the below /etc/yum.conf > and did "yum upgrade". Above is the errors that I get. Is this a known > problem? To use FC development, you need yum 2.0.5 because of python 2.3 changes IIRC. You can grab it from the yum homepage or from : http://freshrpms.net/rpm/yum Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.1-1.65 Load : 1.41 1.03 0.79 From ivg2 at cornell.edu Tue Feb 10 14:36:37 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 10 Feb 2004 09:36:37 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <20040210110804.GB10361@devserv.devel.redhat.com> References: <40287D6C.4090601@cornell.edu> <1076395564.20129.23.camel@binkley> <40287E98.9020900@cornell.edu> <40288300.6090701@cornell.edu> <20040210110804.GB10361@devserv.devel.redhat.com> Message-ID: <4028EC75.9040202@cornell.edu> > FC should rebuild. Not all the build dependancies are complete, I've found > that too and sometimes it'll spit out valid but useless packages depending > on order (eg build xmms before the ogg packages and it builds but doesnt > play anything 8)) But will that happen on a system that already has most packages installed and is merely recompiling for athlon? From katzj at redhat.com Tue Feb 10 14:37:34 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 10 Feb 2004 09:37:34 -0500 Subject: rawhide report: 20040209 changes In-Reply-To: <814qtzlasb.fsf@alexk-laptop.eng.demon.net> References: <200402091203.i19C3SN03957@porkchop.devel.redhat.com> <814qtzlasb.fsf@alexk-laptop.eng.demon.net> Message-ID: <1076423854.11987.2.camel@edoras.local.net> On Tue, 2004-02-10 at 06:16 +0000, Alex Kiernan wrote: > Huh? Didn't the version just go backwards here from the one two days > before? Yes, and it'll go forwards again. Silly tricks with freezes and getting needed things to build. Jeremy From anvil at livna.org Tue Feb 10 14:39:35 2004 From: anvil at livna.org (Dams) Date: Tue, 10 Feb 2004 15:39:35 +0100 Subject: Corporate pressure In-Reply-To: References: <401E480E.1060307@home.se> <4020129E.8060300@home.se> <4024C13B.2020006@home.se> Message-ID: <1076423975.10353.62.camel@gruyere> Le sam 07/02/2004 ? 12:03, Mike A. Harris a ?crit : > www.livna.org perhaps would be best. http://rpm.livna.org/ would be even better. D -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From alexl at stofanet.dk Tue Feb 10 14:45:20 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Tue, 10 Feb 2004 15:45:20 +0100 Subject: permissions Message-ID: <1076424319.3978.1.camel@simba.lion> why isnt it possible to access http://download.fedora.redhat.com/pub/ fedora/linux/core/test/1.90/ ??? Alex Leth From pauln at truemesh.com Tue Feb 10 14:42:24 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 10 Feb 2004 14:42:24 +0000 Subject: permissions In-Reply-To: <1076424319.3978.1.camel@simba.lion> References: <1076424319.3978.1.camel@simba.lion> Message-ID: <20040210144220.GE19143@lichen.truemesh.com> On Tue, Feb 10, 2004 at 03:45:20PM +0100, Alex Thomsen Leth wrote: > why isnt it possible to access http://download.fedora.redhat.com/pub/ > fedora/linux/core/test/1.90/ ??? As with RHL if a directory mysteriously appears but is unaccessible it's probably a hint that something is going to appear there soon :) It'll be announced when it's announced - which obviously includes time to sync to mirrors. Paul From salimma at fastmail.fm Tue Feb 10 14:56:13 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 10 Feb 2004 21:56:13 +0700 Subject: permissions In-Reply-To: <1076424319.3978.1.camel@simba.lion> References: <1076424319.3978.1.camel@simba.lion> Message-ID: <1076424973.3147.28.camel@localhost.localdomain> On Tue, 2004-02-10 at 15:45 +0100, Alex Thomsen Leth wrote: > why isnt it possible to access http://download.fedora.redhat.com/pub/ > fedora/linux/core/test/1.90/ ??? > Presumably it's being mirrored to FTP servers. But thanks for the heads- up! There goes my bandwith until this weekend... - 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 skvidal at phy.duke.edu Tue Feb 10 15:13:01 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 10:13:01 -0500 Subject: yum upgrade In-Reply-To: <200402110009.18330.russell@coker.com.au> References: <200402110009.18330.russell@coker.com.au> Message-ID: <1076425981.14272.3.camel@opus> On Tue, 2004-02-10 at 08:09, Russell Coker wrote: > Completing update for pygtk2 - 539/539 > Kernel Updated/Installed, checking for bootloader > Grub found - making this kernel the default > Traceback (most recent call last): > File "/usr/bin/yum", line 60, in ? > sys.exit(1) > File "/usr/share/yum/yummain.py", line 323, in main > sys.exit(1) > File "/usr/share/yum/pkgaction.py", line 536, in kernelupdate > # at the moment, kernel rpms are supposed to grok grub > File "/usr/share/yum/up2datetheft.py", line 13, in install_grub > import grubcfg > File "/usr/share/yum/grubcfg.py", line 12, in ? > import iutil > File "/usr/share/yum/iutil.py", line 2, in ? > import types, os, sys, select, string, stat, signal > ImportError: No module named select > ---- > > I installed FC1 (yarrow) from CD and then put in the below /etc/yum.conf and > did "yum upgrade". Above is the errors that I get. Is this a known problem? > When upgrading python 2.2 to python 2.3 everything moves out from under yum. This is bad. It means any functions called AFTER the move are victim to nothing being there. I think all I need to do to fix this is make sure I get all the functions imported that I need BEFORE the rpm transaction starts, then invoke them later. -sv From csm at redhat.com Tue Feb 10 15:20:19 2004 From: csm at redhat.com (Chuck Mead) Date: Tue, 10 Feb 2004 10:20:19 -0500 Subject: test In-Reply-To: <200402100130.i1A1UNb25922@mx1.redhat.com> References: <200402100130.i1A1UNb25922@mx1.redhat.com> Message-ID: <4028F6B3.7020606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 katzj at redhat.com did not write: I use postfix for my MTA's and in conjunction with the config found here: http://moongroup.com/outbound.config I block the content which was contained in the original of this message with this regexp: /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(ad[ep]|asd|ba[st]|c[ho]m|cmd|cpl|crt|dbx|dll|exe|hlp|hta|in[fs]|isp|lnk|js|jse|lnk|ocx|md[etw]|ms[cipt]|nws|ocx|ops|pcd|pi|pif|prf|reg|scf|scr|sct|sh[bms]|swf|uue|vb|vb[esx]|vxd|wab|ws[cfh]))"?\s*$/ ~ REJECT Files attached to emails that contain or end in "$3" are prohibited on this server as they may contain viruses. The file named "$2" was rejected. This seems a sinple way to approach the problem of transmission/retransmission of these virii. - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAKPayZfy0juH51WsRAgp2AKCfxbGrDZQwS3HuoWPAoiS5B9aM5gCgnG0i Otfjtndsh2A7a6v2LelsUXA= =qjfk -----END PGP SIGNATURE----- From otaylor at redhat.com Tue Feb 10 15:59:23 2004 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 10 Feb 2004 10:59:23 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <40287D6C.4090601@cornell.edu> References: <40287D6C.4090601@cornell.edu> Message-ID: <1076428762.17907.20.camel@localhost.localdomain> On Tue, 2004-02-10 at 01:42, Ivan Gyurdiev wrote: > I've submitted bugzillas for several of those (freetype-headers for > gnome-print, the tcsh bug, desktop-printing, some of the gnome > deprecated bugs ... but I prefer mail as the means for communication. > Plus since a bug stayed in rawhide bugzilla for a year and a half before > I got a reply, I just don't trust the thing anymore. I think that's an excellent reason to trust bugzilla! If you sent mail to a mailing list, and someone didn't have a chance to look at the problem for 18 months, they'd have completely forgotten that your report existed... I figure I should follow up here since I added a comment to 115081: I can only answer for my own packages (fontconfig, gnome-print, libgnomeprint of the above), but for those, I'm not sure filing such bugs is valuable. I still wouldn't make the change until I had to rebuild the package for some other reason, and at that point, I'm going to be reminded by the build system to fix this... Based on my current (mostly upstream GTK+) workload, I don't have a lot of flexibility in that at the moment, but I think it is an interesting policy question for Fedora in general - just how important is keeping the set of RPMS always recompilable with the current tree? Pro: - People seem to be rebuilding RPMS a lot; if something breaks, bug reports appear very quickly. - Makes mass rebuilds to check, say, compiler changes, easier if everything builds all the time. - Generally good hygiene Con: - It takes developer time that could profitably be used elsewhere - Making everything fully bootstrappable involves significant engineering ... e.g., fixing the freetype <=> XFree86 build loop dependency would require rewriting the makefiles for freetype-demos and getting the changes upstream. (*) Right now, I tend to consider it a "would be nice" but not a "must"; but if it turns out to be an important goal for the Fedora project than it probably needs to be enforced in the process, say by not shipping betas until all packages pass a mass-rebuild. Regards, Owen (*) Note that a bootstrap and mass-rebuild are different things: bootstrap: Recompiling everything from the ground up; clearly requires using at least a few packages from a previous build or a cross-compiler. mass rebuild: Rebuilding all packages, but just against the current tree. From mariuslj at ifi.uio.no Tue Feb 10 16:05:55 2004 From: mariuslj at ifi.uio.no (Marius L. =?ISO-8859-1?Q?J=F8hndal?=) Date: Tue, 10 Feb 2004 17:05:55 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> Message-ID: <1076429155.4126.17.camel@cartman.uio.no> On Tue, 2004-02-10 at 12:49 +0200, Panu Matilainen wrote: > While on the topic of adding keywords to bugzilla - can we please > implement at lesat part of Ville's suggestion here: > http://www.fedora.us/pipermail/fedora-devel/2003-December/002388.html > > Just having keywords like "games", "laptop", "perl" etc attached to > package submission/QA bug so you could query for packages you are interested in would make > finding the interesting packages a whole lot easier. Although it will clutter the keyword field quite a lot, I am very much in favour of having such keywords. I think it might even help some of the packages that have been stuck in QA forever get some attention, as a QA'er will be able to spot packages that are unknown to him, but still fall within his area of interest. Some keywords (pretty much off the top of my head and from Ville's list) that I would like to see: - NETWORKING, MULTIMEDIA, DATABASE, DEVELOPMENT, PUBLISHING, GAMES - GNOME, KDE - PERL, PYTHON i.e. both purpose, environment and language -- Marius L. J?hndal Credo certe ne cras. -------------- 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 kaboom at gatech.edu Tue Feb 10 16:09:50 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 10 Feb 2004 11:09:50 -0500 (EST) Subject: LVM1 to LVM2 plans for FC2 In-Reply-To: References: <1076387600.22894.5.camel@isengard> Message-ID: On Tue, 10 Feb 2004, Paul Jakma wrote: > On Mon, 9 Feb 2004, Jeremy Katz wrote: > > > Online resize with ext3... the patch is in the 2.6 kernel builds > > now unless I missed a commit removing it :) > > I've never been brave enough to try online-resize. :) I've used it without problems later, chris From kaboom at gatech.edu Tue Feb 10 16:22:02 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 10 Feb 2004 11:22:02 -0500 (EST) Subject: release candidate zsh configs In-Reply-To: <4025F3FA.6020300@redhat.com> References: <401A28E6.3010403@imapmail.org> <401F602B.2020301@imapmail.org> <4025F3FA.6020300@redhat.com> Message-ID: On Sat, 7 Feb 2004, Warren Togami wrote: > I just had a thought... > > Would something like this be inappropriate? > > If the user runs zsh and ~/.zshrc does not exist but /etc/skel/.zshrc > does exist, then copy it into their home directory. Only a small patch > to zsh would allow this, and this should not have any drawbacks. Yes, it would be inappropriate. Long-standing semantics for /etc/skel is that putting files there copies them to new user accounts when new user accounts are created, not magically at other times. If you need magic, write a shell script and run it to update existing accounts.... Changing that for one config file only would be inconsistent. Changing it for everything would make Fedora behave differently than most other Unixen. later, chris From katzj at redhat.com Tue Feb 10 17:01:24 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 10 Feb 2004 12:01:24 -0500 Subject: a couple of bugs with development software In-Reply-To: <1076410390.1422.101.camel@roque> References: <1076410390.1422.101.camel@roque> Message-ID: <1076432484.1542.20.camel@mirkwood.boston.redhat.com> On Tue, 2004-02-10 at 10:53 +0000, Rui Miguel Seabra wrote: > a) gnome-terminal > ignores tab related shortcuts unless menubar is visible > (example: alt+n or ctr+pgup or pgdn) Upstream. > b) evolution > unable to (configure to?) use maildirs Upstream. Although this will become a non-issue for FC2 very soon. With the new schedule for evolution 2.0, I'm going to be reverting the package in development back to a 1.4.x later in the week. Jeremy From rms at 1407.org Tue Feb 10 17:08:11 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 17:08:11 +0000 Subject: a couple of bugs with development software In-Reply-To: <1076432484.1542.20.camel@mirkwood.boston.redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> Message-ID: <1076432891.1771.13.camel@roque> On Tue, 2004-02-10 at 12:01 -0500, Jeremy Katz wrote: > On Tue, 2004-02-10 at 10:53 +0000, Rui Miguel Seabra wrote: > > a) gnome-terminal > Upstream. > > > b) evolution > Upstream. Although this will become a non-issue for FC2 very soon. > With the new schedule for evolution 2.0, I'm going to be reverting the > package in development back to a 1.4.x later in the week. okay. *chuif*chuif* I'm already quite fond of evolution 1.5 ;) -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From salimma at fastmail.fm Tue Feb 10 17:21:04 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 11 Feb 2004 00:21:04 +0700 Subject: a couple of bugs with development software In-Reply-To: <1076432891.1771.13.camel@roque> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <1076432891.1771.13.camel@roque> Message-ID: <1076433663.31586.11.camel@localhost.localdomain> On Tue, 2004-02-10 at 17:08 +0000, Rui Miguel Seabra wrote: [snip] > > > b) evolution > > Upstream. Although this will become a non-issue for FC2 very soon. > > With the new schedule for evolution 2.0, I'm going to be reverting the > > package in development back to a 1.4.x later in the week. > > okay. *chuif*chuif* I'm already quite fond of evolution 1.5 ;) > Seeing that you are not alone, I suppose one of us could package evo snapshots for fedora.us-unstable. I'd do it unless someone with more bandwith on his hosting site volunteers - the last time I hosted Evolution (1.4, binaries though) my site got swamped. - 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 de_lupus at pandora.be Tue Feb 10 17:56:51 2004 From: de_lupus at pandora.be (Kristof Vansant) Date: Tue, 10 Feb 2004 18:56:51 +0100 Subject: I was wondering why fedora has choosen yum over apt-get References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> Message-ID: <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> What are the key benefits of yum over apt-get cause I got a friend telling me yum is crap and I should switch to apt-get in stead. Apt-get goes really fast in comparisment to yum. But I tell him there must be a good reason why fedora uses yum, I only don't know what :). Can someone explain it to me. Thx, Lupus (Kristof Vansant Belgium) From smoogen at lanl.gov Tue Feb 10 17:58:04 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 10 Feb 2004 10:58:04 -0700 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> Message-ID: <1076435884.27329.2.camel@smoogen2.lanl.gov> These are the probable reasons: A) Seth works at Duke in North Carolina. A proportion of Red Hat works at Raleigh in North Carolina. B) yum is written in python and so fits with the core Red Hat tool-kit of writing all tools in python. While most conspiraicies would have that Red Hat considers 'apt as the tool of the Debil'.. I think the 2 above are much more likely. On Tue, 2004-02-10 at 10:56, Kristof Vansant wrote: > What are the key benefits of yum over apt-get cause I got a friend telling > me yum is crap and I should switch to apt-get in stead. > Apt-get goes really fast in comparisment to yum. > But I tell him there must be a good reason why fedora uses yum, I only don't > know what :). > > Can someone explain it to me. > > Thx, > > Lupus (Kristof Vansant Belgium) -- 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 skvidal at phy.duke.edu Tue Feb 10 18:01:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 13:01:48 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076435884.27329.2.camel@smoogen2.lanl.gov> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> Message-ID: <1076436108.14272.38.camel@opus> On Tue, 2004-02-10 at 12:58, Stephen Smoogen wrote: > These are the probable reasons: > A) Seth works at Duke in North Carolina. A proportion of Red Hat works > at Raleigh in North Carolina. yes - this is it - it's a big north carolina conspiracy. We're also all working to get edwards elected, too. :) Oh and any time I screw something up someone from red hat comes to my apartment with a baseball bat. -sv From alexandre.abreu at proteus.com.br Tue Feb 10 19:00:59 2004 From: alexandre.abreu at proteus.com.br (Alexandre de Abreu) Date: Tue, 10 Feb 2004 17:00:59 -0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> Message-ID: <40292A6B.5000508@proteus.com.br> Kristof Vansant wrote: > What are the key benefits of yum over apt-get cause I got a friend telling > me yum is crap and I should switch to apt-get in stead. > Apt-get goes really fast in comparisment to yum. > But I tell him there must be a good reason why fedora uses yum, I only don't > know what :). > > Can someone explain it to me. Read this document and free your mind: http://www.linux.duke.edu/projects/yum/questions.ptml []'s -- Alexandre Lima de Abreu, RHCE, LPIC-2 http://www.proteus.com.br Proteus Security Systems -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2832 bytes Desc: S/MIME Cryptographic Signature URL: From skvidal at phy.duke.edu Tue Feb 10 18:08:02 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 13:08:02 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <40292A6B.5000508@proteus.com.br> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <40292A6B.5000508@proteus.com.br> Message-ID: <1076436481.14272.44.camel@opus> On Tue, 2004-02-10 at 14:00, Alexandre de Abreu wrote: > Kristof Vansant wrote: > > What are the key benefits of yum over apt-get cause I got a friend telling > > me yum is crap and I should switch to apt-get in stead. > > Apt-get goes really fast in comparisment to yum. > > But I tell him there must be a good reason why fedora uses yum, I only don't > > know what :). > > > > Can someone explain it to me. > > Read this document and free your mind: > http://www.linux.duke.edu/projects/yum/questions.ptml don't read that document. Much of it is out of date now. Panu and Gustavo have done a bunch of work to make some of the things mentioned a bout apt no longer valid. The part about it being a lot of code is still true but . -sv From icon at linux.duke.edu Tue Feb 10 18:11:25 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Tue, 10 Feb 2004 13:11:25 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076436108.14272.38.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <1076436108.14272.38.camel@opus> Message-ID: <40291ECD.4030807@linux.duke.edu> seth vidal wrote: > yes - this is it - it's a big north carolina conspiracy. We're also all > working to get edwards elected, too. :) Oh and any time I screw > something up someone from red hat comes to my apartment with a baseball > bat. Actually, they just call me and I subtly and imperceptibly disrupt the NFS performance on our fileserver... just enough to drive you mad. :D Cheers, -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE I am looking for a job in Canada! http://linux.duke.edu/~icon/cajob.ptml From de_lupus at pandora.be Tue Feb 10 18:16:57 2004 From: de_lupus at pandora.be (Kristof Vansant) Date: Tue, 10 Feb 2004 19:16:57 +0100 Subject: I was wondering why fedora has choosen yum over apt-get References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> Message-ID: <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> k but I still don't understand why with yum everything goes slower then with apt-get. Has apt-get better mirror support or something? My friend has a big apt-get sources list and yum list. Apt-get had his sources list in 2 minutes. Yum was still loading header files after half an hour. I can understand his frustration. What's the cause in this big speed difference? And yes I have read http://linux.duke.edu/projects/yum/questions.ptml ----- Original Message ----- From: "Stephen Smoogen" To: Sent: Tuesday, February 10, 2004 6:58 PM Subject: Re: I was wondering why fedora has choosen yum over apt-get > These are the probable reasons: > A) Seth works at Duke in North Carolina. A proportion of Red Hat works > at Raleigh in North Carolina. > B) yum is written in python and so fits with the core Red Hat tool-kit > of writing all tools in python. > > While most conspiraicies would have that Red Hat considers 'apt as the > tool of the Debil'.. I think the 2 above are much more likely. > > On Tue, 2004-02-10 at 10:56, Kristof Vansant wrote: > > What are the key benefits of yum over apt-get cause I got a friend telling > > me yum is crap and I should switch to apt-get in stead. > > Apt-get goes really fast in comparisment to yum. > > But I tell him there must be a good reason why fedora uses yum, I only don't > > know what :). > > > > Can someone explain it to me. > > > > Thx, > > > > Lupus (Kristof Vansant Belgium) > -- > 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 -- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From csm at redhat.com Tue Feb 10 18:12:52 2004 From: csm at redhat.com (Chuck Mead) Date: Tue, 10 Feb 2004 13:12:52 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076436108.14272.38.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <1076436108.14272.38.camel@opus> Message-ID: <40291F24.7070402@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: | On Tue, 2004-02-10 at 12:58, Stephen Smoogen wrote: | |>These are the probable reasons: |>A) Seth works at Duke in North Carolina. A proportion of Red Hat works |>at Raleigh in North Carolina. | | | | yes - this is it - it's a big north carolina conspiracy. We're also all | working to get edwards elected, too. :) Oh and any time I screw | something up someone from red hat comes to my apartment with a baseball | bat. That would be me! /me has a large LART collection! - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAKR8kZfy0juH51WsRAuIHAJ9Ru6aISWKrOVOACvdj78NjsFiKmACeKaz+ ekSTA0tlSKu9yjeBwN9S5vQ= =VKTW -----END PGP SIGNATURE----- From katzj at redhat.com Tue Feb 10 18:19:03 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 10 Feb 2004 13:19:03 -0500 Subject: a couple of bugs with development software In-Reply-To: <1076433663.31586.11.camel@localhost.localdomain> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <1076432891.1771.13.camel@roque> <1076433663.31586.11.camel@localhost.localdomain> Message-ID: <1076437143.1542.24.camel@mirkwood.boston.redhat.com> On Wed, 2004-02-11 at 00:21 +0700, Michel Alexandre Salim wrote: > On Tue, 2004-02-10 at 17:08 +0000, Rui Miguel Seabra wrote: > [snip] > > > > b) evolution > > > Upstream. Although this will become a non-issue for FC2 very soon. > > > With the new schedule for evolution 2.0, I'm going to be reverting the > > > package in development back to a 1.4.x later in the week. > > > > okay. *chuif*chuif* I'm already quite fond of evolution 1.5 ;) > > > Seeing that you are not alone, I suppose one of us could package evo > snapshots for fedora.us-unstable. I'm planning to keep my builds going on people.redhat.com as I've been doing since I started building 1.5. Mostly because I'm going to continue to build it for my own use, so I might as well put them up for others. Jeremy From shahms at shahms.com Tue Feb 10 18:29:20 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 10 Feb 2004 10:29:20 -0800 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> Message-ID: <1076437759.9613.27.camel@shahms.mesd.k12.or.us> On Tue, 2004-02-10 at 09:56, Kristof Vansant wrote: > What are the key benefits of yum over apt-get cause I got a friend telling > me yum is crap and I should switch to apt-get in stead. > Apt-get goes really fast in comparisment to yum. > But I tell him there must be a good reason why fedora uses yum, I only don't > know what :). > > Can someone explain it to me. > > Thx, > > Lupus (Kristof Vansant Belgium) I cannot speak for Fedora, but I can say that from my experiences using both apt-rpm and yum I have found yum to be much more "reasonable". I suspect that the reason for this is that yum is more forgiving of minor inconsistencies than is apt, which may be good or bad, depending on your position. Yum, unlike apt, will proceed with an upgrade or install even if a completely unrelated package is slightly out-of-whack. For example, I ran into problems relating to the gnome-libs package a while back. Apt was completely unable to resolve the issues (mostly because of weird dependency issues). An update would fail saying to run 'apt-get install -f' which would then offer to uninstall all of GNOME for me, which was entirely unnecessary. The "correct" (but ugly) solution required removing the offending packages with --no-deps and running yum to replace them (because apt refuses to run if the rpm database is not in a consistent state). You can argue that apt's behavior is correct, but that correctness makes it completely useless in many real-world situations. Many packaging problems require "creative" (albeit temporary) solutions until the upstream packages are fixed. My tools should not get in my way. This is UNIX, my tools are supposed to do what I say, even if they think I'm off my rocker. There's a reason RPM lets you do stupid things like "--force" and "--nodeps". I have many more examples of apt getting in my way where yum (by not trying to be as smart) worked. Yum never asks me to remove packages when I say "install" or "update". -- Shahms King From smoogen at lanl.gov Tue Feb 10 18:30:23 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 10 Feb 2004 11:30:23 -0700 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076436108.14272.38.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <1076436108.14272.38.camel@opus> Message-ID: <1076437823.27329.10.camel@smoogen2.lanl.gov> On Tue, 2004-02-10 at 11:01, seth vidal wrote: > On Tue, 2004-02-10 at 12:58, Stephen Smoogen wrote: > > These are the probable reasons: > > A) Seth works at Duke in North Carolina. A proportion of Red Hat works > > at Raleigh in North Carolina. > > > yes - this is it - it's a big north carolina conspiracy. We're also all > working to get edwards elected, too. :) Oh and any time I screw > something up someone from red hat comes to my apartment with a baseball > bat. > Well I wasnt going to mention the Electric 'devices' they used to use at Red Hat.. but I am pretty sure they are used still. Anyway.. its all because I didnt get the job at Duke :). > -sv -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From ville.skytta at iki.fi Tue Feb 10 18:32:52 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 10 Feb 2004 20:32:52 +0200 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> Message-ID: <1076437972.20592.41.camel@bobcat.mine.nu> On Tue, 2004-02-10 at 12:49, Panu Matilainen wrote: > On Tue, 10 Feb 2004, Michel Alexandre Salim wrote: > > > On Tue, 2004-02-10 at 10:32 +0100, Michael Schwendt wrote: > > [snip] > > > The keyword I have in mind would be REVIEWED or APPROVED, but I'm open for > > > different suggestions. > > > > > APPROVED sounds too final, REVIEWED seems a better fit. > > Agreed. +1 for the idea in any case, whatever keyword gets chosen. +1 too in general, whatever the keyword, or if it is a keyword in the first place. Bugzilla also has a thing called "attachment statuses" which could be used for this purpose. The feature is already there in bugzilla.fedora.us but has not been used. The thing is that attachment statuses are for _attachments_, ie. reviews would need to be attached instead of inlining. Mileages vary whether it's a good thing or not, and I don't know whether use of the feature needs any special permissions. More info: http://www.fedora.us/pipermail/fedora-devel/2003-March/000697.html > While on the topic of adding keywords to bugzilla - can we please > implement at lesat part of Ville's suggestion here: > http://www.fedora.us/pipermail/fedora-devel/2003-December/002388.html I would obviously welcome that :) Perhaps someone could throw in a Wiki draft for suggested keywords etc. Marius's list would be a good start. From salimma at fastmail.fm Tue Feb 10 18:38:04 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 11 Feb 2004 01:38:04 +0700 Subject: a couple of bugs with development software In-Reply-To: <1076437143.1542.24.camel@mirkwood.boston.redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <1076432891.1771.13.camel@roque> <1076433663.31586.11.camel@localhost.localdomain> <1076437143.1542.24.camel@mirkwood.boston.redhat.com> Message-ID: <1076438283.32085.8.camel@localhost.localdomain> On Tue, 2004-02-10 at 13:19 -0500, Jeremy Katz wrote: > I'm planning to keep my builds going on people.redhat.com as I've been > doing since I started building 1.5. Mostly because I'm going to > continue to build it for my own use, so I might as well put them up for > others. > Nice to know, thanks. A manual migration back after a similarly manual migration forward would be as depressing as La Grande Arm?e's retreat from Russia in 1813 :) - 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 rms at 1407.org Tue Feb 10 18:34:45 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 18:34:45 +0000 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076436481.14272.44.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <40292A6B.5000508@proteus.com.br> <1076436481.14272.44.camel@opus> Message-ID: <1076438084.1771.43.camel@roque> On Tue, 2004-02-10 at 13:08 -0500, seth vidal wrote: > On Tue, 2004-02-10 at 14:00, Alexandre de Abreu wrote: > > Kristof Vansant wrote: > > > What are the key benefits of yum over apt-get cause I got a friend telling > > > me yum is crap and I should switch to apt-get in stead. > > > Apt-get goes really fast in comparisment to yum. > > > But I tell him there must be a good reason why fedora uses yum, I only don't > > > know what :). > > > > > > Can someone explain it to me. > > > > Read this document and free your mind: > > http://www.linux.duke.edu/projects/yum/questions.ptml > > don't read that document. > Much of it is out of date now. Panu and Gustavo have done a bunch of > work to make some of the things mentioned a bout apt no longer valid. > The part about it being a lot of code is still true but . It is a lot of code, true, but I rather have 1000 lines of good C code than the equivalent functionality in python (with potentially much less lines of code) if it is bad quality (this is in a general case and not specifically the case of yum, which I can't speak about in terms of programming quality period). Also, one should pay attention that... Yum provides the features of apt w/o all the dpkg-compatibility baggage. ... is plain false (even then). It only proves how little experience has been had with apt. apt4rpm works so much better one a computer with 32MB of ram than yum... but so much better... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rms at 1407.org Tue Feb 10 18:38:06 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 18:38:06 +0000 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076437759.9613.27.camel@shahms.mesd.k12.or.us> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> Message-ID: <1076438286.1771.47.camel@roque> On Tue, 2004-02-10 at 10:29 -0800, Shahms King wrote: > I cannot speak for Fedora, but I can say that from my experiences using > both apt-rpm and yum I have found yum to be much more "reasonable". I > suspect that the reason for this is that yum is more forgiving of minor > inconsistencies than is apt, which may be good or bad, depending on your > position. Yum, unlike apt, will proceed with an upgrade or install even > if a completely unrelated package is slightly out-of-whack. So it is better to have a potentially unstable system? > For example, I ran into problems relating to the gnome-libs package a > while back. Apt was completely unable to resolve the issues (mostly > because of weird dependency issues). Or packages without enough Q/A? Evidently their dependencies were not properly declared. > database is not in a consistent state). You can argue that apt's > behavior is correct, but that correctness makes it completely useless in > many real-world situations. Unmanageable systems too. The problem is with the packages (and they should be fixed) not with apt. > Many packaging problems require "creative" (albeit temporary) solutions > until the upstream packages are fixed. Install src.rpm, correct the spec. It's usually very easy. > My tools should not get in my > way. This is UNIX, my tools are supposed to do what I say, even if they > think I'm off my rocker. There's a reason RPM lets you do stupid things > like "--force" and "--nodeps". I have many more examples of apt getting > in my way where yum (by not trying to be as smart) worked. Yum never > asks me to remove packages when I say "install" or "update". Yet you recur to "creative" solutions? Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Tue Feb 10 18:43:05 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 13:43:05 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076437823.27329.10.camel@smoogen2.lanl.gov> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <1076436108.14272.38.camel@opus> <1076437823.27329.10.camel@smoogen2.lanl.gov> Message-ID: <1076438585.14272.49.camel@opus> > Well I wasnt going to mention the Electric 'devices' they used to use at > Red Hat.. but I am pretty sure they are used still. Anyway.. its all > because I didnt get the job at Duke :). so you know why you didn't get the job, right? you were WAY too qualified. -sv From dcbw at redhat.com Tue Feb 10 18:43:30 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 10 Feb 2004 13:43:30 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> Message-ID: <1076438610.2344.9.camel@dcbw.boston.redhat.com> I'm rather wondering this too... It takes a _long_ time to download these headers. Can yum (correct me if it does already): 1) compress the .hdr files 2) Use HTTP 1.1 Pipelining or keepalive support? I guess since apt just downloads a large file once, it has less setup/ teardown for TCP/IP. Or am I showing my ignorance? Dan On Tue, 2004-02-10 at 19:16 +0100, Kristof Vansant wrote: > k but I still don't understand why with yum everything goes slower then with > apt-get. > Has apt-get better mirror support or something? > My friend has a big apt-get sources list and yum list. Apt-get had his > sources list in 2 minutes. Yum was still loading header files after half an > hour. > I can understand his frustration. What's the cause in this big speed > difference? > > And yes I have read http://linux.duke.edu/projects/yum/questions.ptml > > ----- Original Message ----- > From: "Stephen Smoogen" > To: > Sent: Tuesday, February 10, 2004 6:58 PM > Subject: Re: I was wondering why fedora has choosen yum over apt-get > > > > These are the probable reasons: > > A) Seth works at Duke in North Carolina. A proportion of Red Hat works > > at Raleigh in North Carolina. > > B) yum is written in python and so fits with the core Red Hat tool-kit > > of writing all tools in python. > > > > While most conspiraicies would have that Red Hat considers 'apt as the > > tool of the Debil'.. I think the 2 above are much more likely. > > > > On Tue, 2004-02-10 at 10:56, Kristof Vansant wrote: > > > What are the key benefits of yum over apt-get cause I got a friend > telling > > > me yum is crap and I should switch to apt-get in stead. > > > Apt-get goes really fast in comparisment to yum. > > > But I tell him there must be a good reason why fedora uses yum, I only > don't > > > know what :). > > > > > > Can someone explain it to me. > > > > > > Thx, > > > > > > Lupus (Kristof Vansant Belgium) > > -- > > 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 -- > > > > > > -- > > 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 rms at 1407.org Tue Feb 10 18:40:12 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 18:40:12 +0000 Subject: a couple of bugs with development software In-Reply-To: <1076437143.1542.24.camel@mirkwood.boston.redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <1076432891.1771.13.camel@roque> <1076433663.31586.11.camel@localhost.localdomain> <1076437143.1542.24.camel@mirkwood.boston.redhat.com> Message-ID: <1076438412.1771.50.camel@roque> yes please, thank you! my fondness is also related to being forced to use x509 certificates in the very near future on my employment :) Which new evo supports! Rui On Tue, 2004-02-10 at 13:19 -0500, Jeremy Katz wrote: > I'm planning to keep my builds going on people.redhat.com as I've been > doing since I started building 1.5. Mostly because I'm going to > continue to build it for my own use, so I might as well put them up for > others. -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rms at 1407.org Tue Feb 10 18:42:57 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 18:42:57 +0000 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076435884.27329.2.camel@smoogen2.lanl.gov> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> Message-ID: <1076438577.1771.55.camel@roque> On Tue, 2004-02-10 at 10:58 -0700, Stephen Smoogen wrote: > These are the probable reasons: > A) Seth works at Duke in North Carolina. A proportion of Red Hat works > at Raleigh in North Carolina. > B) yum is written in python and so fits with the core Red Hat tool-kit > of writing all tools in python. > > While most conspiraicies would have that Red Hat considers 'apt as the > tool of the Debil'.. I think the 2 above are much more likely. I believe that too, however I add a third reason... C) misconceptions about apt vs yum similar to the misconceptions about rpm vs apt :) in the sense that some people compare really petty things, sometimes without thinking them over much. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Tue Feb 10 18:53:15 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 13:53:15 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076438610.2344.9.camel@dcbw.boston.redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <1076438610.2344.9.camel@dcbw.boston.redhat.com> Message-ID: <1076439195.14272.59.camel@opus> > Can yum (correct me if it does already): > > 1) compress the .hdr files > 2) Use HTTP 1.1 Pipelining or keepalive support? it does both of these already. The headers are just too big. When I originally wrote yum it was for my environment. My environment is terribly over-bandwidth'd. So downloading 7MB of headers via http took < 15s. And since the full download of 7MB of headers only really happens ONCE, I never saw the problem. now I do, now I'm working on a solution. I've been working with the other pkg mgmt people (apt-rpm, apt-deb, red carpet, yum, up2date, anaconda, rpmfind, system-config-packages, rpm) on a format for metadata that, ideally, we could all share and use. We worked out a format that we're mostly happy with and I've posted about here, multiple times, before: http://linux.duke.edu/metadata/readme.metadata I've been working on making yum work with this format. I hope to have some test releases out before the end of February, we'll see if I can do it. the goal is to have an xml file that describes the pkg metadata. This would be one file, substantially smaller than the headers, and much simpler to check out and cache. some samples are up at: http://linux.duke.edu/metadata/ so now, instead of downloading the hdrs it would download the xml and work from there. In the best of all words, the metadata format (since it is not specific to any package manager) would be usable by all of them and then mirrors would be able to have a single format for all the pkg mgmt tools. That's what I'd like to see happen. -sv From salimma at fastmail.fm Tue Feb 10 18:57:29 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 11 Feb 2004 01:57:29 +0700 Subject: not SVN? (was: An introduction of the new cheerleader...) In-Reply-To: References: <200401260707.56591.abel@vallinor4.com> Message-ID: <1076439449.32085.16.camel@localhost.localdomain> On Tue, 2004-01-27 at 18:10 +0100, Pau Aliagas wrote: [snip] > I'd definately go for arch. It supports signed archives, repository > integrity checks, distributed development, easy branching, no special > server needed (ftp, sftp, http and webdav would do). > https://bugzilla.fedora.us/show_bug.cgi?id=1266 A guinea pig for my package! Thanks, - 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 shahms at shahms.com Tue Feb 10 19:05:24 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 10 Feb 2004 11:05:24 -0800 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076438286.1771.47.camel@roque> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> <1076438286.1771.47.camel@roque> Message-ID: <1076439924.9613.45.camel@shahms.mesd.k12.or.us> On Tue, 2004-02-10 at 10:38, Rui Miguel Seabra wrote: > On Tue, 2004-02-10 at 10:29 -0800, Shahms King wrote: > > I cannot speak for Fedora, but I can say that from my experiences using > > both apt-rpm and yum I have found yum to be much more "reasonable". I > > suspect that the reason for this is that yum is more forgiving of minor > > inconsistencies than is apt, which may be good or bad, depending on your > > position. Yum, unlike apt, will proceed with an upgrade or install even > > if a completely unrelated package is slightly out-of-whack. > > So it is better to have a potentially unstable system? No, however, when I know the correct solution to a problem that apt is convinced will lead to an "unstable system" and therefore refuses to perform said operation, it is no longer a useful tool. Or, at the very least, its utility is vastly reduced. Additionally, if I am willing to live with a potentially unstable system, apt should not get in my way. > > For example, I ran into problems relating to the gnome-libs package a > > while back. Apt was completely unable to resolve the issues (mostly > > because of weird dependency issues). > > Or packages without enough Q/A? Evidently their dependencies were not > properly declared. Or Obsoletes or Epoch or . . . Any number of issues that have no impact on the software itself. If I am aware of these issues, I can work around them until they are properly Q/A'd as long as I'm not using apt. Additionally, apt has had problems with packages that were completely correct, simply replacing other packages that have different dependencies. Say, replacing ximian packages with the official Fedora ones. Ximian had a newer version of gnome-libs than Fedora Core, however, that version was not the one required by the FC packages. Rather than downgrading that one package, apt decided the only way to resolve the issue was to uninstall all of GNOME (even the GNOME2 packages which didn't require gnome-libs at all). If you think that is the "correct" solution, then continue using apt. I, however, will: rpm -e --nodeps gnome-libs yum install gnome-libs yum update and continue on my merry way. > > database is not in a consistent state). You can argue that apt's > > behavior is correct, but that correctness makes it completely useless in > > many real-world situations. > > Unmanageable systems too. The problem is with the packages (and they > should be fixed) not with apt. The primary problem is with the packages, however, apt's inability to "do-what-I-say-and-damn-the-torpedoes" is a problem with apt, not a specific package. > > Many packaging problems require "creative" (albeit temporary) solutions > > until the upstream packages are fixed. > > Install src.rpm, correct the spec. It's usually very easy. *sigh* Yeah, you try that when one GNOME package is very slightly mispackaged in such as way as to require recompiling all of GNOME. Or XFree86. Or OpenOffice.org. Seriously, I have better things to do with my time than recompile a package with a one-line change to the specfile that has no impact on the software itself. > > My tools should not get in my > > way. This is UNIX, my tools are supposed to do what I say, even if they > > think I'm off my rocker. There's a reason RPM lets you do stupid things > > like "--force" and "--nodeps". I have many more examples of apt getting > > in my way where yum (by not trying to be as smart) worked. Yum never > > asks me to remove packages when I say "install" or "update". > > Yet you recur to "creative" solutions? I don't even know what you're trying to say here... Removing packages when asked to update a completely unrelated package (in the absence of "Obsoletes" is complete counter-intuitive and just asking for trouble, especially when the default is 'Y' unlike yum). > Rui -- Shahms King From rms at 1407.org Tue Feb 10 19:13:06 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Feb 2004 19:13:06 +0000 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076439924.9613.45.camel@shahms.mesd.k12.or.us> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> <1076438286.1771.47.camel@roque> <1076439924.9613.45.camel@shahms.mesd.k12.or.us> Message-ID: <1076440386.1771.69.camel@roque> On Tue, 2004-02-10 at 11:05 -0800, Shahms King wrote: > > > database is not in a consistent state). You can argue that apt's > > > behavior is correct, but that correctness makes it completely useless in > > > many real-world situations. > > > > Unmanageable systems too. The problem is with the packages (and they > > should be fixed) not with apt. > > The primary problem is with the packages, however, apt's inability to > "do-what-I-say-and-damn-the-torpedoes" is a problem with apt, not a > specific package. > > > > Many packaging problems require "creative" (albeit temporary) solutions > > > until the upstream packages are fixed. > > > > Install src.rpm, correct the spec. It's usually very easy. > > *sigh* Yeah, you try that when one GNOME package is very slightly > mispackaged in such as way as to require recompiling all of GNOME. Or > XFree86. Or OpenOffice.org. Seriously, I have better things to do with > my time than recompile a package with a one-line change to the specfile > that has no impact on the software itself. > > > > My tools should not get in my > > > way. This is UNIX, my tools are supposed to do what I say, even if they > > > think I'm off my rocker. There's a reason RPM lets you do stupid things > > > like "--force" and "--nodeps". I have many more examples of apt getting > > > in my way where yum (by not trying to be as smart) worked. Yum never > > > asks me to remove packages when I say "install" or "update". > > > > Yet you recur to "creative" solutions? > > I don't even know what you're trying to say here... Just that it's a little incoherent to say you don't like to do wacky things and yet you do them :) > Removing packages > when asked to update a completely unrelated package (in the absence of > "Obsoletes" is complete counter-intuitive and just asking for trouble, > especially when the default is 'Y' unlike yum). apt detects that your system has broken dependencies that can't be corrected with your repository. The safest solution, of course, is to clean it. Fix your system is the best answer, even though it may require fixing the rpm. In the end, it's always your choice, but after that don't complain :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmatilai at welho.com Tue Feb 10 19:29:59 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 10 Feb 2004 21:29:59 +0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076439924.9613.45.camel@shahms.mesd.k12.or.us> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> <1076438286.1771.47.camel@roque> <1076439924.9613.45.camel@shahms.mesd.k12.or.us> Message-ID: <1076441399.13695.15.camel@chip.laiskiainen.org> On Tue, 2004-02-10 at 21:05, Shahms King wrote: > On Tue, 2004-02-10 at 10:38, Rui Miguel Seabra wrote: > > Or Obsoletes or Epoch or . . . Any number of issues that have no impact > on the software itself. If I am aware of these issues, I can work > around them until they are properly Q/A'd as long as I'm not using apt. > Additionally, apt has had problems with packages that were completely > correct, simply replacing other packages that have different > dependencies. Say, replacing ximian packages with the official Fedora > ones. Ximian had a newer version of gnome-libs than Fedora Core, > however, that version was not the one required by the FC packages. > Rather than downgrading that one package, apt decided the only way to > resolve the issue was to uninstall all of GNOME (even the GNOME2 > packages which didn't require gnome-libs at all). If you think that is > the "correct" solution, then continue using apt. I, however, will: > > rpm -e --nodeps gnome-libs > yum install gnome-libs > yum update > > and continue on my merry way. If that's all it took to fix the issue you could've done it by saying "apt-get install gnome-libs=" to force the downgrade. Or do "rpm -e --nodeps gnome-libs; apt-get install gnome-libs". Note that your solution required *downgrade* of a package, that's something no depsolver will even consider normally (even if they can) and it's generally just unrealistic to expect software to automatically come up with solutions to every imaginable dependency problem (in a way which satisfies you). That said, yes, it'd be nice if apt had an "shut up and do what I say" mode when you're fixing up a system which is completely and totally busted and apt *could* help a lot if it wasn't so uptight about the temporary incoherency of the package database. > I don't even know what you're trying to say here... Removing packages > when asked to update a completely unrelated package (in the absence of > "Obsoletes" is complete counter-intuitive and just asking for trouble, > especially when the default is 'Y' unlike yum). Since you mentioned this having to do with Ximian ... yep, I know about the "db4 obsoletes db1" issue but thats really a packaging bug on behalf of Ximian which they get away with other depsolvers only because there never happened to be an update to db4 which would've then removed db1 and broken the system anyway. - Panu - From pmatilai at welho.com Tue Feb 10 19:44:09 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 10 Feb 2004 21:44:09 +0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076436481.14272.44.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <40292A6B.5000508@proteus.com.br> <1076436481.14272.44.camel@opus> Message-ID: <1076442249.13695.27.camel@chip.laiskiainen.org> On Tue, 2004-02-10 at 20:08, seth vidal wrote: > On Tue, 2004-02-10 at 14:00, Alexandre de Abreu wrote: > > Kristof Vansant wrote: > > > What are the key benefits of yum over apt-get cause I got a friend telling > > > me yum is crap and I should switch to apt-get in stead. > > > Apt-get goes really fast in comparisment to yum. > > > But I tell him there must be a good reason why fedora uses yum, I only don't > > > know what :). > > > > > > Can someone explain it to me. > > > > Read this document and free your mind: > > http://www.linux.duke.edu/projects/yum/questions.ptml > > don't read that document. > Much of it is out of date now. Panu and Gustavo have done a bunch of > work to make some of the things mentioned a bout apt no longer valid. > The part about it being a lot of code is still true but . Yep, it's a lot of code, especially compared to yum, and not particularly easy to understand either. OTOH a software whose tar.bz is under a megabyte is hardly huge these days, compared to various other OSS projects :) - Panu - From shahms at shahms.com Tue Feb 10 20:12:51 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 10 Feb 2004 12:12:51 -0800 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076441399.13695.15.camel@chip.laiskiainen.org> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> <1076438286.1771.47.camel@roque> <1076439924.9613.45.camel@shahms.mesd.k12.or.us> <1076441399.13695.15.camel@chip.laiskiainen.org> Message-ID: <1076443971.9613.64.camel@shahms.mesd.k12.or.us> > > If that's all it took to fix the issue you could've done it by saying > "apt-get install gnome-libs=" to force the > downgrade. Or do "rpm -e --nodeps gnome-libs; apt-get install > gnome-libs". Neither of those worked, because some currently installed packages required the ximian version (those packages would have been updated by the FC packages) and some required the old version (those would not) either way, apt decided the only solution was removing all of them. The interdependencies were more convoluted than apt could work out (and more convoluted than I would expect it to work out). I however, was more than capable of resolving the issues provided my tools allowed me to do so. Apt did not, yum did. It's as simple as that. The second solution leaves the rpm database with missing deps, which apt will complain about and then refuse to run. However, the second solution works if you replace apt with yum. Yum doesn't have anyway (that I'm aware of) for specifying a specific version, otherwise I suspect the first method would have worked as well. > Note that your solution required *downgrade* of a package, that's > something no depsolver will even consider normally (even if they can) > and it's generally just unrealistic to expect software to automatically > come up with solutions to every imaginable dependency problem (in a way > which satisfies you). Nor do I expect it to. However, I expect it to tell me that it cannot resolve the dependency issues and then exit, rather than offering to remove hundreds of packages. > That said, yes, it'd be nice if apt had an "shut up and do what I say" > mode when you're fixing up a system which is completely and totally > busted and apt *could* help a lot if it wasn't so uptight about the > temporary incoherency of the package database. Exactly. > > > I don't even know what you're trying to say here... Removing packages > > when asked to update a completely unrelated package (in the absence of > > "Obsoletes" is complete counter-intuitive and just asking for trouble, > > especially when the default is 'Y' unlike yum). > > Since you mentioned this having to do with Ximian ... yep, I know about > the "db4 obsoletes db1" issue but thats really a packaging bug on behalf > of Ximian which they get away with other depsolvers only because there > never happened to be an update to db4 which would've then removed db1 > and broken the system anyway. > > - Panu - Yup, which can be worked around by having both versions installed simultaneously and will work with both apt and yum with the appropriate configuration changes until proper packages get released. That was not the issue. -- Shahms King From ms-nospam-0306 at arcor.de Tue Feb 10 20:14:55 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 10 Feb 2004 21:14:55 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076429155.4126.17.camel@cartman.uio.no> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076429155.4126.17.camel@cartman.uio.no> Message-ID: <20040210211455.06af4582.ms-nospam-0306@arcor.de> On Tue, 10 Feb 2004 17:05:55 +0100, Marius L. wrote: > Although it will clutter the keyword field quite a lot, I am very much > in favour of having such keywords. I think it might even help some of > the packages that have been stuck in QA forever get some attention, as a > QA'er will be able to spot packages that are unknown to him, but still > fall within his area of interest. > > Some keywords (pretty much off the top of my head and from Ville's list) > that I would like to see: > > - NETWORKING, MULTIMEDIA, DATABASE, DEVELOPMENT, PUBLISHING, GAMES > - GNOME, KDE > - PERL, PYTHON > > i.e. both purpose, environment and language What happens with software which fits into multiple categories? For categorization, triage like keywords in the first or subsequent bugzilla comments seem more suitable, e.g. category->networking category->python as there would rarely be the need to take them back. It would be easier to add/remove categories, too. -- From pmatilai at welho.com Tue Feb 10 20:46:33 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 10 Feb 2004 22:46:33 +0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076443971.9613.64.camel@shahms.mesd.k12.or.us> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> <1076438286.1771.47.camel@roque> <1076439924.9613.45.camel@shahms.mesd.k12.or.us> <1076441399.13695.15.camel@chip.laiskiainen.org> <1076443971.9613.64.camel@shahms.mesd.k12.or.us> Message-ID: <1076445993.13695.44.camel@chip.laiskiainen.org> On Tue, 2004-02-10 at 22:12, Shahms King wrote: > > > > If that's all it took to fix the issue you could've done it by saying > > "apt-get install gnome-libs=" to force the > > downgrade. Or do "rpm -e --nodeps gnome-libs; apt-get install > > gnome-libs". > > Neither of those worked, because some currently installed packages > required the ximian version (those packages would have been updated by > the FC packages) and some required the old version (those would not) > either way, apt decided the only solution was removing all of them. The > interdependencies were more convoluted than apt could work out (and more > convoluted than I would expect it to work out). I however, was more > than capable of resolving the issues provided my tools allowed me to do > so. Apt did not, yum did. It's as simple as that. > > The second solution leaves the rpm database with missing deps, which apt > will complain about and then refuse to run. However, the second > solution works if you replace apt with yum. Yum doesn't have anyway > (that I'm aware of) for specifying a specific version, otherwise I > suspect the first method would have worked as well. Actually apt does allow running with inconsistent db if a) it can find a solution which fixes the situation when running with -f b) you provide a solution to the situation within a single command It's often possible to do b) (because you can do simultaneous remove and install/upgrade operations within a single command) but certainly not always (been there plenty enough times :) - Panu - From de_lupus at pandora.be Tue Feb 10 20:58:11 2004 From: de_lupus at pandora.be (Kristof Vansant) Date: Tue, 10 Feb 2004 21:58:11 +0100 Subject: looks like reiserfs4 will be released in a month, it looks promising References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076437759.9613.27.camel@shahms.mesd.k12.or.us> <1076438286.1771.47.camel@roque> <1076439924.9613.45.camel@shahms.mesd.k12.or.us> <1076441399.13695.15.camel@chip.laiskiainen.org> <1076443971.9613.64.camel@shahms.mesd.k12.or.us> <1076445993.13695.44.camel@chip.laiskiainen.org> Message-ID: <001001c3f018$98054770$723de0d5@lupusbcc8e7249> source: http://www.newsfactor.com/story.xhtml?story_title=The_Secret_World_of_ReiserFS&story_id=23157&category=databases I wonder if redhat will use it if it is more secure and faster then ext3. Fingers crossed ;) Lupus (Kristof Vansant Belgium) From wtogami at redhat.com Tue Feb 10 21:01:17 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 10 Feb 2004 11:01:17 -1000 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> Message-ID: <4029469D.6030106@redhat.com> Kristof Vansant wrote: > k but I still don't understand why with yum everything goes slower then with > apt-get. > Has apt-get better mirror support or something? yum actually has better mirror and fail-over support than apt today. > My friend has a big apt-get sources list and yum list. Apt-get had his > sources list in 2 minutes. Yum was still loading header files after half an > hour. Could be DNS related issues. Also, if it is a HTTP server make sure KeepAlive is enabled on the server side or it will suck. > I can understand his frustration. What's the cause in this big speed > difference? > Aside from header download, yum of today is extremely slow at calculating dependencies. One often quoted benchmark is 10 seconds apt vs. 50 minutes yum for calculating the dependencies in a large transaction like upgrading from RH9 to FC1 on a 400MHz P2 system. Seth Vidal mentioned that this situation should dramatically improve in the future with the new XML based metadata. Far fewer files are downloaded for headers, meaning more efficient data compression and faster header downloading. And something about the new design means yum will be able to calculate deps much faster than it does today. As for reasons why Red Hat Linux/Fedora does not yet have apt-get today: 1) Missing multilib support like yum or up2date currently has today. This is a medium priority that I probably need to force myself to work on because nobody else seems interested in working on this. This makes me think... does not Debian have dual 32bit/64bit archs? How do they handle multilib if their apt doesn't support it yet either? 2) XML metadata needs to be implemented. Panu Matilainen mentioned that he is working on this. This will allow apt to use the same mirrors that yum, up2date and possibly other tools (Ximian?) that support the new metadata. 3) Concern that apt is redundant to the other clients, and maintaining it would be cost/time prohibitive. Aside from the speed advantages, I personally see apt as my personal favorite for several other reasons: 1) Installation of specified non-repository packages and calculated dependencies. 2) Automated SRPM source building, walking the dependency tree (currently problematic due to flaws in the SRPMS themselves, and perhaps some remaining apt bugs). 3) Removal of entire trees with dependencies. 4) Optional external PM and great flexibility in configuration, allowing a wide array of needed buildsystem functionality for tools like mach/djinni. Enrico Scholz and Panu Matilainencan explain this in greater detail. 5) Extremely well maintained codebase with multiple distributions active in its maintenance. They keep up with the latest versions of rpm religiously. apt is an important tool for me to eventually have in Fedora, but for now I am content to use and maintain it at fedora.us for FC1 and prior distributions. fedora.us mirrors for FC1 and earlier have the entire distribution, all updates, updates-testing, plus stable/testing/unstable Extras trees. http://www.fedora.us/wiki/FedoraHOWTO Get started using fedora.us quickly by following these instructions. Use either apt, yum or up2date. https://bugzilla.fedora.us/show_bug.cgi?id=1180 The next release of apt, with Panu Matilainen's proof of concept optional dynamic menu based mirror chooser. Try this! Warren Togami wtogami at redhat.com From mharris at redhat.com Tue Feb 10 21:02:28 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 10 Feb 2004 16:02:28 -0500 (EST) Subject: /etc/rc and potential startup improvements In-Reply-To: <1076091101.3341.55.camel@shahms.mesd.k12.or.us> References: <1076086739.3341.38.camel@shahms.mesd.k12.or.us> <20040206173253.GB29445@devserv.devel.redhat.com> <1076091101.3341.55.camel@shahms.mesd.k12.or.us> Message-ID: On Fri, 6 Feb 2004, Shahms King wrote: >If I can get 10-15% "for free" (i.e. an optional component that will be >used if available) I'd say it's worth it. "for free" perhaps, but it isn't "for free", so not worth it. In order to make any _major_ change to the system like this, there _has_ to be _major_ gains beyond just a crappy 15%. If it were say 500% faster, then it might be worth considering. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jkeating at j2solutions.net Tue Feb 10 21:13:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 10 Feb 2004 13:13:32 -0800 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <4029469D.6030106@redhat.com> References: <1076410390.1422.101.camel@roque> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <200402101313.40824.jkeating@j2solutions.net> On Tuesday 10 February 2004 13:01, Warren Togami wrote: > 3) Removal of entire trees with dependencies. Not to nit-pick, but yum supports this too. yum remove foo will remove foo, and all of foo's deps. (prompting you of course) -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) 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 Feb 10 21:29:35 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 10 Feb 2004 22:29:35 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076437972.20592.41.camel@bobcat.mine.nu> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> Message-ID: <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> On Tue, 10 Feb 2004 20:32:52 +0200, Ville Skytt? wrote: > Bugzilla also has a thing called "attachment statuses" which could be > used for this purpose. These are not covered by queries, are they? -- From aoliva at redhat.com Tue Feb 10 21:41:12 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Feb 2004 19:41:12 -0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <4029469D.6030106@redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: On Feb 10, 2004, Warren Togami wrote: > Far fewer files are downloaded for headers, meaning more efficient > data compression and faster header downloading. Unless I misunderstand, the one gotcha is the common case of a small changes in a large repositories requiring the entire set of (single file) header information to be downloaded. This *could* become a bandwidth problem, not only for people in the wrong ends of small pipes, but also for servers, since rhn-applet would probably keep on fetching it over and over (at least every time it changes). -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From cra at WPI.EDU Tue Feb 10 21:52:21 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 10 Feb 2004 16:52:21 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <20040210215221.GT1556@angus.ind.WPI.EDU> On Tue, Feb 10, 2004 at 07:41:12PM -0200, Alexandre Oliva wrote: > Unless I misunderstand, the one gotcha is the common case of a small > changes in a large repositories requiring the entire set of (single > file) header information to be downloaded. This *could* become a > bandwidth problem, not only for people in the wrong ends of small > pipes, but also for servers, since rhn-applet would probably keep on > fetching it over and over (at least every time it changes). As opposed to fetching the entire directory listing to see if new files have appeared or changed? It is much faster to determine if a single, known file name, has changed. From notting at redhat.com Tue Feb 10 21:53:00 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Feb 2004 16:53:00 -0500 Subject: FC2 Test 1 - rescheduled Message-ID: <20040210215300.GA22952@devserv.devel.redhat.com> Fedora Core 2 Test 1 is now scheduled for release on Thursday, February 12, at 10AM EST. The schedule at: http://fedora.redhat.com/participate/schedule/ will be updated shortly. Bill From warren at togami.com Tue Feb 10 21:53:33 2004 From: warren at togami.com (Warren Togami) Date: Tue, 10 Feb 2004 11:53:33 -1000 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <402952DD.3040609@togami.com> Alexandre Oliva wrote: > On Feb 10, 2004, Warren Togami wrote: > > >>Far fewer files are downloaded for headers, meaning more efficient >>data compression and faster header downloading. > > > Unless I misunderstand, the one gotcha is the common case of a small > changes in a large repositories requiring the entire set of (single > file) header information to be downloaded. This *could* become a > bandwidth problem, not only for people in the wrong ends of small > pipes, but also for servers, since rhn-applet would probably keep on > fetching it over and over (at least every time it changes). > I don't know the details of the new metadata format, but I believe I heard Seth talking about there being a single signed file containing hashes of the others. You only need to grab that small file often, the others far less often. Watching my web server logs, surprisingly a higher amount of total bandwidth usage is mainly in .hdr files compared to the apt bz2 compressed metadata. Roughly 60% of the users using my mirror are apt, 40% yum. Warren From ville.skytta at iki.fi Tue Feb 10 22:16:27 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 11 Feb 2004 00:16:27 +0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <200402101313.40824.jkeating@j2solutions.net> References: <1076410390.1422.101.camel@roque> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <200402101313.40824.jkeating@j2solutions.net> Message-ID: <1076451387.13720.19.camel@bobcat.mine.nu> On Tue, 2004-02-10 at 23:13, Jesse Keating wrote: > On Tuesday 10 February 2004 13:01, Warren Togami wrote: > > 3) Removal of entire trees with dependencies. > > Not to nit-pick, but yum supports this too. yum remove foo will remove > foo, and all of foo's deps. (prompting you of course) Maybe Warren meant "apt-get -D remove foo". In addition to removing foo and all packages that depend on foo, -D will cause all packages which only foo alone depends on to be removed as well. IIRC the last one is not implemented in yum, ie. its "dep tree removal" is one way only. No, -D is not documented in the apt-get(8) man page :/ From ville.skytta at iki.fi Tue Feb 10 22:25:30 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 11 Feb 2004 00:25:30 +0200 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> Message-ID: <1076451930.13720.26.camel@bobcat.mine.nu> On Tue, 2004-02-10 at 23:29, Michael Schwendt wrote: > On Tue, 10 Feb 2004 20:32:52 +0200, Ville Skytt? wrote: > > > Bugzilla also has a thing called "attachment statuses" which could be > > used for this purpose. > > These are not covered by queries, are they? They are, but one has to use the "advanced querying using boolean charts" options at the bottom of the query page. A simple example which finds everything with first-review set: https://bugzilla.fedora.us/buglist.cgi?field0-0-0=attachstatusdefs.name&type0-0-0=anywords&value0-0-0=first-review From heinlein at madboa.com Tue Feb 10 22:27:41 2004 From: heinlein at madboa.com (Paul Heinlein) Date: Tue, 10 Feb 2004 14:27:41 -0800 (PST) Subject: cups providing LPRng Message-ID: At work, we are stalled on getting a cups server up and into production. Let's just assume, for the sake of discussion, that I'm stuck using a legacy lpr/lpd server for now. We've got a workable /etc/printcap that we push with cfengine to all our *nix hosts. Thing is, cups doesn't like our printcap (nor does it like our lpr server, which is quite ancient, but that's another story and outside my control). So I grabbed LPRng-3.8.19-3.1.src.rpm from the Red Hat 9 tree and built it for Fedora. I'm able to 'rpm -i' the new binary package without difficulty, but 'rpm -U' fails because the cups rpm provides LPRng (so -U wants to remove the cups package): $ rpm -q --provides cups /usr/bin/cancel /usr/bin/lp /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/lpstat LPRng = 3.8.15-3 config(cups) = 1:1.1.19-13 lpd lpr cups = 1:1.1.19-13 That seems amiss to me. Is there a compelling reason why cups has to provide LPRng? Do I have to play dueling rpms, telling LPRng that it provides cups = 1:1.1.19-13.1? --Paul Heinlein From aoliva at redhat.com Tue Feb 10 22:44:16 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Feb 2004 20:44:16 -0200 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <20040210215221.GT1556@angus.ind.WPI.EDU> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> Message-ID: On Feb 10, 2004, "Charles R. Anderson" wrote: > On Tue, Feb 10, 2004 at 07:41:12PM -0200, Alexandre Oliva wrote: >> Unless I misunderstand, the one gotcha is the common case of a small >> changes in a large repositories requiring the entire set of (single >> file) header information to be downloaded. This *could* become a >> bandwidth problem, not only for people in the wrong ends of small >> pipes, but also for servers, since rhn-applet would probably keep on >> fetching it over and over (at least every time it changes). > As opposed to fetching the entire directory listing to see if new > files have appeared or changed? It is much faster to determine if a > single, known file name, has changed. Not as opposed to. If there was a single small file containing references to the others, fine, that's ok to update every time. But having a single file that's a collection of all the headers, no matter how compressed it is, it's probably too much info to download every time it changes. It appears to me that having the headers available for separate downloads would be better, even if they're *also* available in a highly-compressed format for a speedy initial download. But then, mirrors lose on disk space. One can't win, I guess. Unless... rproxy (rsync-based web cache) anyone? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From kir at darnet.ru Tue Feb 10 22:47:44 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Wed, 11 Feb 2004 01:47:44 +0300 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <4029469D.6030106@redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <40295F90.8030506@darnet.ru> Warren Togami wrote: > 3) Removal of entire trees with dependencies. I just wonder whether this functionality will ever be implemented in yum. Seth, can you shed the light on this, please? From skvidal at phy.duke.edu Tue Feb 10 22:48:41 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 17:48:41 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> Message-ID: <1076453321.15803.52.camel@opus> > Not as opposed to. If there was a single small file containing > references to the others, fine, that's ok to update every time. But > having a single file that's a collection of all the headers, no matter > how compressed it is, it's probably too much info to download every > time it changes. It appears to me that having the headers available > for separate downloads would be better, even if they're *also* > available in a highly-compressed format for a speedy initial > download. But then, mirrors lose on disk space. One can't win, I > guess. Unless... rproxy (rsync-based web cache) anyone? The primary metadata file, for all of fc1, is 400K, compressed. That's a doable download almost any time. The repomd.xml has an md5sum and a timestamp of the primary and other metadata files - so you can know if it has changed, fairly well. Now, inside the primary xml file is a lot of stuff, most specifically is the byte range for the rpm headers in the rpm. So now you can use http 1.1, ftp and file byte ranges to grab the headers you need when you need them to build your transaction set. urlgrabber now has the code to make all of this possible and it works fairly well in my tests. and then, if you don't want to get the entire filelists but just want to list all the files for a certain package - you can just grab that package's header from the rpm itself and dump the filelists. Kinda cool. -sv From skvidal at phy.duke.edu Tue Feb 10 22:50:56 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 10 Feb 2004 17:50:56 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <40295F90.8030506@darnet.ru> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <40295F90.8030506@darnet.ru> Message-ID: <1076453456.15803.55.camel@opus> On Tue, 2004-02-10 at 17:47, Kir Kolyshkin wrote: > Warren Togami wrote: > > > 3) Removal of entire trees with dependencies. > > I just wonder whether this functionality will ever be implemented in > yum. Seth, can you shed the light on this, please? do you mean the leaf-node case or the cascading removals? The latter works now. The former can be implemented - it's just a matter of available developer time and interest (read that as me :) It's not all that hard, really. Take the list of deps for the package you want to remove. Look at them, if nothing else depends on them, other than the package you want to remove, remove them also. -sv From twaugh at redhat.com Tue Feb 10 22:52:06 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 10 Feb 2004 22:52:06 +0000 Subject: cups providing LPRng In-Reply-To: References: Message-ID: <20040210225206.GF25654@redhat.com> On Tue, Feb 10, 2004 at 02:27:41PM -0800, Paul Heinlein wrote: > That seems amiss to me. Is there a compelling reason why cups has to > provide LPRng? It's so that upgrades from Red Hat Linux work: otherwise you get left with an orphaned spooler. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From heinlein at madboa.com Tue Feb 10 22:59:12 2004 From: heinlein at madboa.com (Paul Heinlein) Date: Tue, 10 Feb 2004 14:59:12 -0800 (PST) Subject: cups providing LPRng In-Reply-To: <20040210225206.GF25654@redhat.com> References: <20040210225206.GF25654@redhat.com> Message-ID: On Tue, 10 Feb 2004, Tim Waugh wrote: > > That seems amiss to me. Is there a compelling reason why cups has > > to provide LPRng? > > It's so that upgrades from Red Hat Linux work: otherwise you get > left with an orphaned spooler. Ah. Thanks. I'd *really* like to graft an LPRng package into our local installation images and yum tree. Any suggestions? --Paul Heinlein From skvidal at phy.duke.edu Tue Feb 10 23:25:11 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 Feb 2004 18:25:11 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <20040210215221.GT1556@angus.ind.WPI.EDU> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> Message-ID: <1076455511.23430.0.camel@binkley> > As opposed to fetching the entire directory listing to see if new > files have appeared or changed? It is much faster to determine if a > single, known file name, has changed. Not true - it doesn't get a dir listing. yum currently uses the header.info file to determine which headers are new. a dir listing is: 1. expensive 2. unreliable on webservers 3. frequently unavailable. -sv From kir at darnet.ru Tue Feb 10 23:33:28 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Wed, 11 Feb 2004 02:33:28 +0300 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076453456.15803.55.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <40295F90.8030506@darnet.ru> <1076453456.15803.55.camel@opus> Message-ID: <40296A48.5070907@darnet.ru> seth vidal wrote: >The former can be implemented - it's just a matter of available >developer time and interest (read that as me :) > >It's not all that hard, really. > >Take the list of deps for the package you want to remove. Look at them, >if nothing else depends on them, other than the package you want to >remove, remove them also. > Yes, this is exactly what I was asking about. Thanks! From toshio at tiki-lounge.com Tue Feb 10 23:35:27 2004 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 10 Feb 2004 18:35:27 -0500 Subject: Setting up mach Message-ID: <1076456125.9704.57.camel@Madison.badger.com> Hi, I have some problems with setting up mach. If someone screams "go to the mach list" I'll do that, otherwise I hope some other packagers can help me out. FC1 + updates. mach-0.4.3 from http://thomas.apestaart.org/projects/mach I have been doing builds on an old desktop machine that I have but it's been having memory/cpu/kernel problems that I haven't tracked down yet so I decided I'd have to install mach on my laptop to do QA builds there. Unfortunately, my laptop has only 6GB which I need for things besides a mach chroot. So I nfs mounted a (rw,no_root_squash)partition from the desktop machine into my /var/lib/mach directory and tried to get things running. Running 'mach setup base' per the mach README gives me: Preparing root Updating apt sources ... and apparently hangs. (strace on mach is complaining that apt-get isn't giving it any data. strace on apt-get tells me it's waiting in a read()). Is running mach on an nfs partition not going to work? (File locking? Permissions?) Or is there some configuration on my end I should look into? Thanks, Toshio -- Toshio From mrsam at courier-mta.com Tue Feb 10 23:40:13 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 10 Feb 2004 18:40:13 -0500 Subject: cups providing LPRng References: <20040210225206.GF25654@redhat.com> Message-ID: Paul Heinlein writes: > On Tue, 10 Feb 2004, Tim Waugh wrote: > >> > That seems amiss to me. Is there a compelling reason why cups has >> > to provide LPRng? >> >> It's so that upgrades from Red Hat Linux work: otherwise you get >> left with an orphaned spooler. > > Ah. Thanks. I'd *really* like to graft an LPRng package into our local > installation images and yum tree. Any suggestions? Bump the release number, and rebuild it from source. -------------- 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 Tue Feb 10 23:45:11 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 11 Feb 2004 00:45:11 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076451930.13720.26.camel@bobcat.mine.nu> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> Message-ID: <20040211004511.52c94705.ms-nospam-0306@arcor.de> On Wed, 11 Feb 2004 00:25:30 +0200, Ville Skytt? wrote: > > > Bugzilla also has a thing called "attachment statuses" which could be > > > used for this purpose. > > > > These are not covered by queries, are they? > > They are, but one has to use the "advanced querying using boolean > charts" options at the bottom of the query page. Great! I was there, of course, and saw all the other "Attachment *" search options, but missed "Attachment Status". :-/ + It's good how the status of an attached review is tied to the review, i.e. the attachment. On the contrary, a review posted as additional comment would be separate from a bugzilla keyword. + It's good that attaching reviews, instead of copying them into the comments field, would solve some of the auto-wrapping problems some people have, which invalidate GPG signatures. It also "compresses" the list of additional comments. + Clicking on text/plain attachments displays them in a fresh screen and makes it easier to save them. On the contrary, comments need a cut'n'paste operation which might suffer from wrapping problems as covered above. + Posting reviews as attachments would separate them from ordinary comments. - It's bad that changing an attachment status is not logged in the list of additional comments, but only in the separate "Activity log" unless a comment is added explicitly on the "Edit" screen. That way you could raise the status of old attachment without giving a reason. Question: Does this raise the hurdle to QA again? As reviewers would be required to not just post a clearsigned comment, they would need to become familiar with the "Create a New Attachment" window. -- From Axel.Thimm at physik.fu-berlin.de Tue Feb 10 23:49:04 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 11 Feb 2004 00:49:04 +0100 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <20040210234904.GC30226@neu.nirvana> On Tue, Feb 10, 2004 at 07:41:12PM -0200, Alexandre Oliva wrote: > On Feb 10, 2004, Warren Togami wrote: > > > Far fewer files are downloaded for headers, meaning more efficient > > data compression and faster header downloading. > > Unless I misunderstand, the one gotcha is the common case of a small > changes in a large repositories requiring the entire set of (single > file) header information to be downloaded. This *could* become a > bandwidth problem, not only for people in the wrong ends of small > pipes, but also for servers, since rhn-applet would probably keep on > fetching it over and over (at least every time it changes). This could be accomplished by an incremental approach. In a two file scenario there could be a weekly updated base file and file with up to date differences to that. Every week the latter file gets merged to the weekly file and is resetted to 0 length. That way the large bandwidth consumption happens only once a week and you have only two files to check for downloading. Add more tiers for adjusting the development/update pace. I only don't know how well the xml metadata diff file could remove entries from the base file (or the higher tier), but I think it would be doable. -- 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 hattenator at imapmail.org Wed Feb 11 00:43:47 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 10 Feb 2004 16:43:47 -0800 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> Message-ID: <40297AC3.5030402@imapmail.org> Make sure you're comparing similar mirrors. The apt that I got defaults to download.fedora.us, which I can get ~100K/s from. However, yum defaults to redhat.com, from which I get about 500B/s. I changed yum to use mirrors.kernel.org and I get close to 200K/s. Then the header files downloaded within a minute or so (if I remember). Yum doesn't report connection speed by default, though, and I haven't looked into whether it can. -Eric Hattemer Kristof Vansant wrote: >k but I still don't understand why with yum everything goes slower then with >apt-get. >Has apt-get better mirror support or something? >My friend has a big apt-get sources list and yum list. Apt-get had his >sources list in 2 minutes. Yum was still loading header files after half an >hour. >I can understand his frustration. What's the cause in this big speed >difference? > >And yes I have read http://linux.duke.edu/projects/yum/questions.ptml > > > > > > > From tcallawa at redhat.com Wed Feb 11 02:29:54 2004 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 10 Feb 2004 20:29:54 -0600 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <4029469D.6030106@redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <1076466594.4717.36.camel@zorak> On Tue, 2004-02-10 at 11:01 -1000, Warren Togami wrote: > 1) Missing multilib support like yum or up2date currently has today. > This is a medium priority that I probably need to force myself to work > on because nobody else seems interested in working on this. This makes > me think... does not Debian have dual 32bit/64bit archs? How do they > handle multilib if their apt doesn't support it yet either? The short answer: Dirty hacks with package naming. However, to their credit, Debian seems to recognize this as a problem and some momentum is occurring to enable true multilib. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader "The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley's "Brave New World" From russell at coker.com.au Wed Feb 11 04:54:03 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 11 Feb 2004 15:54:03 +1100 Subject: looks like reiserfs4 will be released in a month, it looks promising In-Reply-To: <001001c3f018$98054770$723de0d5@lupusbcc8e7249> References: <1076410390.1422.101.camel@roque> <1076445993.13695.44.camel@chip.laiskiainen.org> <001001c3f018$98054770$723de0d5@lupusbcc8e7249> Message-ID: <200402111554.03955.russell@coker.com.au> On Wed, 11 Feb 2004 07:58, "Kristof Vansant" wrote: > source: > http://www.newsfactor.com/story.xhtml?story_title=The_Secret_World_of_Reise >rFS&story_id=23157&category=databases > > I wonder if redhat will use it if it is more secure and faster then ext3. > Fingers crossed ;) XFS has been tested more extensively, it would probably be a good idea to get full XFS support before Reiser4. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From helios82 at optushome.com.au Wed Feb 11 07:42:38 2004 From: helios82 at optushome.com.au (Matt H.) Date: Wed, 11 Feb 2004 17:42:38 +1000 Subject: possible /etc/X11/prefdm script error? Message-ID: Just looking through the /etc/X11/prefdm script, I noticed that after the file /etc/sysconfig/desktop is read in, the if code block tests on variable $DISPLAYMANAGER. Looking in the /etc/sysconfig/desktop, you can see that the preferred display manager is set in variable $DESKTOP. Therefore, shouldn't this if block test on $DESKTOP rather than $DISPLAYMANAGER? Or in alternative thinking, maybe the variable in /etc/sysconfig/desktop should be changed to $DISPLAYMANAGER? -- Matt From zomps at mail.astar.ee Wed Feb 11 08:50:06 2004 From: zomps at mail.astar.ee (Raul) Date: Wed, 11 Feb 2004 10:50:06 +0200 Subject: possible /etc/X11/prefdm script error? In-Reply-To: References: Message-ID: <4029ECBE.1060807@mail.astar.ee> Matt H. wrote: > Just looking through the /etc/X11/prefdm script, I noticed that after > the file /etc/sysconfig/desktop is read in, the if code block tests on > variable $DISPLAYMANAGER. Looking in the /etc/sysconfig/desktop, you can > see that the preferred display manager is set in variable $DESKTOP. > > Therefore, shouldn't this if block test on $DESKTOP rather than > $DISPLAYMANAGER? > > Or in alternative thinking, maybe the variable in /etc/sysconfig/desktop > should be changed to $DISPLAYMANAGER? > and the autologin program is to gone in bugzilla are 3 bugz that kdm cant to autologin sinze fedora test3 Raul From stfn at gmx.net Wed Feb 11 09:42:18 2004 From: stfn at gmx.net (Stefan Hoelldampf) Date: Wed, 11 Feb 2004 10:42:18 +0100 Subject: FC2 Test 1 - rescheduled In-Reply-To: <20040210215300.GA22952@devserv.devel.redhat.com> References: <20040210215300.GA22952@devserv.devel.redhat.com> Message-ID: <4029F8FA.4050906@gmx.net> Bill Nottingham wrote: > Fedora Core 2 Test 1 is now scheduled for release on Thursday, > February 12, at 10AM EST. > > The schedule at: > http://fedora.redhat.com/participate/schedule/ > > will be updated shortly. I think there is an mistake in the schedule: > 29 March test3, translation build freeze (builds completed) > ... Continual freeze, only critical bugs fixed until release > 9 March Absolute devel freeze > 15 April Export approval, mirror master populated by EOD I hope you mean "9 April Absolute devel freeze" :-) Kind Regards, Stefan From s.mako at gmx.net Wed Feb 11 09:43:40 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Wed, 11 Feb 2004 10:43:40 +0100 (CET) Subject: bug and new package In-Reply-To: Message-ID: Hi, Last year I submitted a bug through bugzilla.redhat.com, which affects recode-3.6-9 in Fedore Core 1. A recommended patch is also attached. It has still a status NEW, so it seems for me nothing happened until now. Is it possible to make the bug handling process faster? The package, I would like to submit, requires recode. New packages: I'm a bit confused now how to contribute new packages. On fedora.us I can read, it will be merged with fedora.redhat and the package naming guideline applies only to fedora.us. On fedora.redhat there are information about a future Extra, Alternative ... repository structure and a modified package naming concept (latter is in the mailing list)... What to do then? Is it better to wait for finishing the merging, or to submit to fedora.us? Zoli From Axel.Thimm at physik.fu-berlin.de Wed Feb 11 10:02:54 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 11 Feb 2004 11:02:54 +0100 Subject: XFS support (was: looks like reiserfs4 will be released in a month, it looks promising) In-Reply-To: <200402111554.03955.russell@coker.com.au> References: <1076410390.1422.101.camel@roque> <1076445993.13695.44.camel@chip.laiskiainen.org> <001001c3f018$98054770$723de0d5@lupusbcc8e7249> <200402111554.03955.russell@coker.com.au> Message-ID: <20040211100254.GD15579@neu.nirvana> On Wed, Feb 11, 2004 at 03:54:03PM +1100, Russell Coker wrote: > On Wed, 11 Feb 2004 07:58, "Kristof Vansant" wrote: > > source: > > http://www.newsfactor.com/story.xhtml?story_title=The_Secret_World_of_Reise > >rFS&story_id=23157&category=databases > > > > I wonder if redhat will use it if it is more secure and faster then ext3. > > Fingers crossed ;) > > XFS has been tested more extensively, it would probably be a good idea to get > full XFS support before Reiser4. full XFS support is in FC2! :) If you are eager to use it for FC1, RH9,8.0,73 try http://atrpms.physik.fu-berlin.de/name/kernel/ http://atrpms.physik.fu-berlin.de/name/xfsprogs/ and optionally http://atrpms.physik.fu-berlin.de/name/xfsdump/ http://atrpms.physik.fu-berlin.de/name/attr/ http://atrpms.physik.fu-berlin.de/name/acl/ http://atrpms.physik.fu-berlin.de/name/dmapi/ -- 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 redhat.com Wed Feb 11 10:52:01 2004 From: buildsys at redhat.com (Build System) Date: Wed, 11 Feb 2004 05:52:01 -0500 Subject: rawhide report: 20040211 changes Message-ID: <200402111052.i1BAq1d03466@porkchop.devel.redhat.com> Removed package rpmdb-fedora Updated Packages: From lorenzo at reality.it Wed Feb 11 11:12:29 2004 From: lorenzo at reality.it (Lorenzo Luconi Trombacchi) Date: Wed, 11 Feb 2004 12:12:29 +0100 Subject: FC2 Test 1 - rescheduled In-Reply-To: <20040210215300.GA22952@devserv.devel.redhat.com> References: <20040210215300.GA22952@devserv.devel.redhat.com> Message-ID: <402A0E1D.6050503@reality.it> will be released an x86_64 version or only an i386 version? Lorenzo >Fedora Core 2 Test 1 is now scheduled for release on Thursday, >February 12, at 10AM EST. > >The schedule at: > http://fedora.redhat.com/participate/schedule/ > >will be updated shortly. > >Bill > > > > From ronny-vlug at vlugnet.org Wed Feb 11 12:00:59 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Wed, 11 Feb 2004 13:00:59 +0100 Subject: possible /etc/X11/prefdm script error? In-Reply-To: References: Message-ID: <200402111300.59810.ronny-vlug@vlugnet.org> On Wednesday 11 February 2004 08:42, Matt H. wrote: > Just looking through the /etc/X11/prefdm script, I noticed that after > the file /etc/sysconfig/desktop is read in, the if code block tests on > variable $DISPLAYMANAGER. Looking in the /etc/sysconfig/desktop, you can > see that the preferred display manager is set in variable $DESKTOP. > > Therefore, shouldn't this if block test on $DESKTOP rather than > $DISPLAYMANAGER? > > Or in alternative thinking, maybe the variable in /etc/sysconfig/desktop > should be changed to $DISPLAYMANAGER? no $DESKTOP is used for the default desktop, $DISPLAYMANAGER for the displaymanager :) have a look in /etc/X11/xdm/Xsession and /etc/X11/xinit/Xclients -- ronny From mrsam at courier-mta.com Wed Feb 11 12:08:31 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 11 Feb 2004 07:08:31 -0500 Subject: rawhide report: 20040211 changes References: <200402111052.i1BAq1d03466@porkchop.devel.redhat.com> Message-ID: Build System writes: > > > Removed package rpmdb-fedora Say what? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Feb 11 13:01:45 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Feb 2004 13:01:45 +0000 Subject: FC2 Test 1 - rescheduled In-Reply-To: <402A0E1D.6050503@reality.it> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> Message-ID: <1076504505.8611.3.camel@delerium.codemonkey.org.uk> On Wed, 2004-02-11 at 11:12, Lorenzo Luconi Trombacchi wrote: > will be released an x86_64 version or only an i386 version? I don't think so for test1. (We've had a hard enough time just whacking the bugs in x86 8-) Though I believe Justin is putting together an 'unofficial' iso set. Dave -- Dave Jones Red Hat From csm at redhat.com Wed Feb 11 14:24:32 2004 From: csm at redhat.com (Chuck Mead) Date: Wed, 11 Feb 2004 09:24:32 -0500 Subject: FC2 Test 1 - rescheduled In-Reply-To: <1076504505.8611.3.camel@delerium.codemonkey.org.uk> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> <1076504505.8611.3.camel@delerium.codemonkey.org.uk> Message-ID: <402A3B20.10405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Jones wrote: | On Wed, 2004-02-11 at 11:12, Lorenzo Luconi Trombacchi wrote: | |>will be released an x86_64 version or only an i386 version? | | | I don't think so for test1. | (We've had a hard enough time just whacking the bugs in x86 8-) | | Though I believe Justin is putting together an 'unofficial' iso set. Justin told me last night that he is hoping to have it ready on Monday of next week. - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAKjsgZfy0juH51WsRAnpVAJ0QsZpC5ziASk+tGvXjycgHNExAhgCfe2tL EwidshDFe7xwnxKFIrXMt9U= =x7aV -----END PGP SIGNATURE----- From jspaleta at princeton.edu Wed Feb 11 14:30:02 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 11 Feb 2004 09:30:02 -0500 Subject: Fedora Bug Day Today...err I guess I mean Tonite..err so I guess i mean Fedora Bug Nite Tonite!!!!!! Message-ID: <1076509801.10091.36.camel@spatula.pppl.gov> Fedora Bug Day Tonite!!!!!! 7.30pm EST - 'til I fall asleep Theme: A general call to arms, for bugbusting!!!!! *Why tonite? Why not today? Sadly, I'm being forced to be away from all internet connected computers today, and my wireless neural implant isn't working. Someone is trying to tell me i have "work" to do, or something. I'm just as confused as you are about all this. But this evening, unless my isp has other plans, i'll be jacked into the net for a large chunk of time. Drop by #fedora-bugs on the freenode network in about oh 10 or so hours from now and help get involved with the bugzilla triage effort. Though now that mitr has bugzilla editting rights, you can stop into the irc channel in the meantime and see if he's around. So if you want to help out with triage. What is triage? maybe this will explain: https://lists.dulug.duke.edu/pipermail/fedora-triage-list/2004-January/000003.html *What can i do RIGHT NOW! Become involved in the fedora.us QA process and help QA packages that are waiting to be published in the fedora.us addon repo: http://www.fedora.us/QA Please look over that list, and pick a package you would like to see published for the community to enjoy that you are interested in. There are 348 packages sitting waiting for QA. That's 348 packages the Fedora community could be enjoying in the published fedora.us repository trees, once they have made it through the community peer-review process. Remember, until the full merge is completed and Fedora Extras and Alternatives is up and running...community packagers are being advised to use fedora.us's process. How do you become involved in the fedora.us peer-review process? Easy, read: http://www.fedora.us/wiki/PackageSubmissionQAPolicy Not only is this a good way to help out, by being part of the peer-review process that helps make sure high quality packages are available to the community, but doing the peer-review QA, can help you learn how to do better rpm packaging. For those of you who dream of the fame and fortune of being Fedora Extras contributors down the road, getting involved in the fedora.us QA process now is a good place to start. -jef"technically, getting this notice out 10 hours before I'm going to be available, actually means this notice isn't late...in fact its probably the earliest notice i've done for a bug day so far"spaleta From lorenzo at reality.it Wed Feb 11 15:38:55 2004 From: lorenzo at reality.it (Lorenzo Luconi Trombacchi) Date: Wed, 11 Feb 2004 16:38:55 +0100 Subject: FC2 Test 1 - rescheduled In-Reply-To: <402A3B20.10405@redhat.com> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> <1076504505.8611.3.camel@delerium.codemonkey.org.uk> <402A3B20.10405@redhat.com> Message-ID: <402A4C8F.80707@reality.it> > | Though I believe Justin is putting together an 'unofficial' iso set. > > Justin told me last night that he is hoping to have it ready on Monday > of next week. > Ok. This is very good! I'm ready to test it!!!! :-)))) A new kernel will be released with this unofficial version? The last kernels released have a Kernel Panic problem (I wrote an email some days ago with the kernel panic message). I tested the last kernels on Athlon64 with Asus K8V mainboard and on APPRO Dual Opteron and I always got a Kernel Panic message. At present Athlon64 is working fine with 2.6.1-1.47. A Fedora Core 2 for AMD64 roadmap exists? Lorenzo From csm at redhat.com Wed Feb 11 15:44:14 2004 From: csm at redhat.com (Chuck Mead) Date: Wed, 11 Feb 2004 10:44:14 -0500 Subject: FC2 Test 1 - rescheduled In-Reply-To: <402A4C8F.80707@reality.it> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> <1076504505.8611.3.camel@delerium.codemonkey.org.uk> <402A3B20.10405@redhat.com> <402A4C8F.80707@reality.it> Message-ID: <402A4DCE.4080305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lorenzo Luconi Trombacchi wrote: | |> | Though I believe Justin is putting together an 'unofficial' iso set. |> |> Justin told me last night that he is hoping to have it ready on Monday |> of next week. |> | Ok. This is very good! I'm ready to test it!!!! :-)))) | | A new kernel will be released with this unofficial version? The last | kernels released have a Kernel Panic problem (I wrote | an email some days ago with the kernel panic message). I tested the last | kernels on Athlon64 with Asus K8V | mainboard and on APPRO Dual Opteron and I always got a Kernel Panic | message. At present Athlon64 is working fine with | 2.6.1-1.47. If memory serves this is the kernel he told me was going to be in the release. | A Fedora Core 2 for AMD64 roadmap exists? I don't know. That sounds to me like a question for Christian Gafton. - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAKk3OZfy0juH51WsRAmvEAKCK3Y6fjhfMy/sF1LC8R3ftDkQZ0QCeJg84 aKZCHVq86CJZdnGloQpKhoo= =I8h4 -----END PGP SIGNATURE----- From 64bit_fedora at comcast.net Wed Feb 11 15:50:05 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Wed, 11 Feb 2004 09:50:05 -0600 Subject: FC2 Test 1 - rescheduled In-Reply-To: <402A4C8F.80707@reality.it> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> <1076504505.8611.3.camel@delerium.codemonkey.org.uk> <402A3B20.10405@redhat.com> <402A4C8F.80707@reality.it> Message-ID: <20040211155005.GA5446@comcast.net> On Wed, Feb 11, 2004 at 04:38:55PM +0100, Lorenzo Luconi Trombacchi wrote: > > A new kernel will be released with this unofficial version? The last > kernels released have a Kernel Panic problem (I wrote > an email some days ago with the kernel panic message). I tested the last > kernels on Athlon64 with Asus K8V > mainboard and on APPRO Dual Opteron and I always got a Kernel Panic > message. At present Athlon64 is working fine with > 2.6.1-1.47. > Yes, a newer kernel revision will be included, and it does boot on AMD64. > A Fedora Core 2 for AMD64 roadmap exists? > Not officially a seperate roadmap since after test1 for FC2, the AMD64 roadmap should be the i386 roadmap. It should have begun with test1, but as Dave said, there were other issues, and it got bumped. With the devel tree being used for updates, once the unofficial test1 is released, we should remain in sync with i386 from that point forward. Thanks, Justin From notting at redhat.com Wed Feb 11 17:37:32 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 11 Feb 2004 12:37:32 -0500 Subject: rawhide report: 20040211 changes In-Reply-To: References: <200402111052.i1BAq1d03466@porkchop.devel.redhat.com> Message-ID: <20040211173732.GB19687@devserv.devel.redhat.com> Sam Varshavchik (mrsam at courier-mta.com) said: > >Removed package rpmdb-fedora > > Say what? It probably failed to build for some odd reason. Bill From davej at redhat.com Wed Feb 11 18:02:01 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Feb 2004 18:02:01 +0000 Subject: FC2 Test 1 - rescheduled In-Reply-To: <20040211155005.GA5446@comcast.net> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> <1076504505.8611.3.camel@delerium.codemonkey.org.uk> <402A3B20.10405@redhat.com> <402A4C8F.80707@reality.it> <20040211155005.GA5446@comcast.net> Message-ID: <1076522520.27122.16.camel@delerium.codemonkey.org.uk> On Wed, 2004-02-11 at 15:50, Justin M. Forbes wrote: > On Wed, Feb 11, 2004 at 04:38:55PM +0100, Lorenzo Luconi Trombacchi wrote: > > > > A new kernel will be released with this unofficial version? The last > > kernels released have a Kernel Panic problem (I wrote > > an email some days ago with the kernel panic message). I tested the last > > kernels on Athlon64 with Asus K8V > > mainboard and on APPRO Dual Opteron and I always got a Kernel Panic > > message. At present Athlon64 is working fine with > > 2.6.1-1.47. > > > Yes, a newer kernel revision will be included, and it does boot on AMD64. Yup. You'll have to. iirc, 1.66 is what we're including in i386 test1, and you'll need at least 1.67 to get it to even boot, as there was a one liner (now included in mainline) that meant it blew up really horribly during boot on amd64. FWIW, I'm trying to test each update on my hammer to make sure it still boots each time too, but some days I just get too bogged down to do complete testing (and hey, thats what users are for right? :-) Things are looking pretty decent on amd64 these days, even without any extra amd64 specific patches, which is good. > Not officially a seperate roadmap since after test1 for FC2, the AMD64 > roadmap should be the i386 roadmap. It should have begun with test1, but > as Dave said, there were other issues, and it got bumped. With the devel > tree being used for updates, once the unofficial test1 is released, we > should remain in sync with i386 from that point forward. Not tried an amd64 install from rawhide yet. Might give that a go tonight. It should be in a pretty decent state right now. Dave From wtogami at redhat.com Wed Feb 11 18:04:28 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 11 Feb 2004 08:04:28 -1000 Subject: dvgrab, 1394 and firewire stuff Message-ID: <402A6EAC.5000005@redhat.com> We now have an opportunity to upgrade the "ancient" versions of the firewire packages before the February 27th deadline. Please suggest upgrade versions, URL's, exact patches in this thread. It would help if you actually test them too... Warren From 64bit_fedora at comcast.net Wed Feb 11 18:21:10 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Wed, 11 Feb 2004 12:21:10 -0600 Subject: FC2 Test 1 - rescheduled In-Reply-To: <1076522520.27122.16.camel@delerium.codemonkey.org.uk> References: <20040210215300.GA22952@devserv.devel.redhat.com> <402A0E1D.6050503@reality.it> <1076504505.8611.3.camel@delerium.codemonkey.org.uk> <402A3B20.10405@redhat.com> <402A4C8F.80707@reality.it> <20040211155005.GA5446@comcast.net> <1076522520.27122.16.camel@delerium.codemonkey.org.uk> Message-ID: <20040211182110.GC5446@comcast.net> On Wed, Feb 11, 2004 at 06:02:01PM +0000, Dave Jones wrote: > > Not tried an amd64 install from rawhide yet. Might give that a go > tonight. It should be in a pretty decent state right now. > Installing from rawhide will leave out the 32bit stuff needed, and currently rawhide is frozen at kernel-2.6.1-1.65. Once the kernel update can push (tomorrow?) It should install fine. When I do the test1 push sometime this weekend/monday at the latest, the 32bit stuff will be included as well. Justin From mike at flyn.org Wed Feb 11 18:27:10 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 11 Feb 2004 12:27:10 -0600 Subject: Pam_mount introduction Message-ID: <20040211182709.GA2433@imp.flyn.org> I would like to formally introduce a package I have been working on to the Fedora community. Pam_mount has been in the Fedora.us QA process for about three months: https://bugzilla.fedora.us/show_bug.cgi?id=1013 What is it? Pam_mount is a PAM module that allows one to transparently mount password-protected volumes upon logging in to a system. It mounts using one's system password and it supports CIFS, SMB, NCP and loopback encrypted volumes out of the box. Other volume types could easily be configured. It can mount volumes that share the same password as your system account and even, with a little trickery, transparently mount volumes with unique passwords. Why do I think it is important? Several people have told me that they find pam_mount very useful for integrating Linux desktops into Windows/SMB desktop networks. I hope that this is a more common occurance in the next few years. I think pam_mount may be able to help. I have been working hard to get pam_mount to easily fit into Fedora. For example, I have written a patch for authconfig that allows one to configure pam_mount using the tool: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=97561&action=view In addition, I have filed several bug reports in GNOME and Red Hat's bugzilla databases (and submitted patches in several cases). Many of these issues are now fixed: Bug 67605: shut down gconfd on logout https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=67605 Bug 97361: improve exit-gconfd-on-logout chances http://bugzilla.gnome.org/show_bug.cgi?id=97361 Bug 126071: Gdm does not ensure user's programs exit before calling pam_close_session http://bugzilla.gnome.org/show_bug.cgi?id=126071 What do I want from you? If you are interested in pam_mount then I would love your help with the pam_mount QA process. In addition, I would like to have people test my authconfig patch (and submit comments to Bugzilla). If you work for Red Hat, please consider pam_mount for Fedora Core 3 (or even 2 if possible)! Thank you -- I look forward to getting your feedback! -- Mike :wq From hvdkooij at vanderkooij.org Wed Feb 11 19:37:39 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Wed, 11 Feb 2004 20:37:39 +0100 (CET) Subject: Fedora Bug Day Today...err I guess I mean Tonite..err so I guess i mean Fedora Bug Nite Tonite!!!!!! In-Reply-To: <1076509801.10091.36.camel@spatula.pppl.gov> References: <1076509801.10091.36.camel@spatula.pppl.gov> Message-ID: On Wed, 11 Feb 2004, Jef Spaleta wrote: > Fedora Bug Day Tonite!!!!!! 7.30pm EST - 'til I fall asleep That translates to 19:30 EST which in turn is tomorrow (2004-02-12) at 00:30 UTC Just so Europeans know they have to skip sleep. (And honestly I alway have to look thrice with this am/pm stuff to figure out the time.) Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From ivg2 at cornell.edu Wed Feb 11 19:43:00 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 11 Feb 2004 14:43:00 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <1076428762.17907.20.camel@localhost.localdomain> References: <40287D6C.4090601@cornell.edu> <1076428762.17907.20.camel@localhost.localdomain> Message-ID: <402A85C4.2020709@cornell.edu> > I think that's an excellent reason to trust bugzilla! If you sent > mail to a mailing list, and someone didn't have a chance to look > at the problem for 18 months, they'd have completely forgotten > that your report existed... If a bug stays unfixed for 18 months then something must be seriously wrong with the bug tracking/fixing process, whatever it is. Anyway, fine... bugzillas shall be filed, since people are not happy with me posting bugs on the "development" list. I will start by filing bugs for libgnomeprint and fontconfig to make sure you don't forget about them :) Speaking of which, it would be nice if bugzilla supported filing bugs that relate to more than one component. That's one of the reasons I prefer mail as the means of communication. Bugzilla's just a dumb machine, and I much prefer to deal with a human that understands that bugs are often related. Correct me if I'm wrong about this. And how can I file a bug which does not relate to one of those components, but something more general? (like the fact that fedora menus are a mess) How can I file a bug whose component I do not know ... if something broke in gnome, I know it's broken, and I have no idea which component is responsible... > Based on my current (mostly upstream GTK+) workload, I don't have > a lot of flexibility in that at the moment, but I think it is an > interesting policy question for Fedora in general - just how important > is keeping the set of RPMS always recompilable with the current > tree? I'd like to know the answer too. > Pro: > - People seem to be rebuilding RPMS a lot; if something breaks, > bug reports appear very quickly. > - Makes mass rebuilds to check, say, compiler changes, easier > if everything builds all the time. > - Generally good hygiene I am compiling for athlon, because I'd like to benefit from the speed optimizations for my arch. I would appreciate if things compiled. Then Fedora could easily provide an athlon set of rpms one day. > Con: > - It takes developer time that could profitably be used elsewhere > - Making everything fully bootstrappable involves significant > engineering ... e.g., fixing the freetype <=> XFree86 build > loop dependency would require rewriting the makefiles for > freetype-demos and getting the changes upstream. (*) > Right now, I tend to consider it a "would be nice" but not a > "must"; but if it turns out to be an important goal for the Fedora > project than it probably needs to be enforced in the process, > say by not shipping betas until all packages pass a mass-rebuild. > > Regards, > Owen > > (*) Note that a bootstrap and mass-rebuild are different things: > > bootstrap: Recompiling everything from the ground up; > clearly requires using at least a few packages from a previous > build or a cross-compiler. > mass rebuild: Rebuilding all packages, but just against the > current tree. From jkt at redhat.com Wed Feb 11 19:54:46 2004 From: jkt at redhat.com (Jay Turner) Date: Wed, 11 Feb 2004 14:54:46 -0500 Subject: Compiling Fedora... athlon In-Reply-To: <402A85C4.2020709@cornell.edu> References: <40287D6C.4090601@cornell.edu> <1076428762.17907.20.camel@localhost.localdomain> <402A85C4.2020709@cornell.edu> Message-ID: <20040211195446.GJ7085@redhat.com> On Wed, Feb 11, 2004 at 02:43:00PM -0500, Ivan Gyurdiev wrote: > Speaking of which, it would be nice if bugzilla supported filing bugs > that relate to more than one component. That's one of the reasons > I prefer mail as the means of communication. Bugzilla's just a dumb > machine, and I much prefer to deal with a human that understands that > bugs are often related. Correct me if I'm wrong about this. And how can > I file a bug which does not relate to one of those components, but > something more general? (like the fact that fedora menus are a mess) > How can I file a bug whose component I do not know ... if something > broke in gnome, I know it's broken, and I have no idea which component > is responsible... There's a component called "distribution" where you can log general distribution bugs. As for not knowing the particular component which a bug resides in, make an educated guess and the developers will generally sort it out from there. - 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 kir at darnet.ru Wed Feb 11 20:43:09 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Wed, 11 Feb 2004 23:43:09 +0300 Subject: Compiling Fedora... athlon In-Reply-To: <20040211195446.GJ7085@redhat.com> References: <40287D6C.4090601@cornell.edu> <1076428762.17907.20.camel@localhost.localdomain> <402A85C4.2020709@cornell.edu> <20040211195446.GJ7085@redhat.com> Message-ID: <402A93DD.1080602@darnet.ru> Jay Turner wrote: >On Wed, Feb 11, 2004 at 02:43:00PM -0500, Ivan Gyurdiev wrote: > > >>Speaking of which, it would be nice if bugzilla supported filing bugs >>that relate to more than one component. That's one of the reasons >>I prefer mail as the means of communication. Bugzilla's just a dumb >>machine, and I much prefer to deal with a human that understands that >>bugs are often related. Correct me if I'm wrong about this. And how can >>I file a bug which does not relate to one of those components, but >>something more general? (like the fact that fedora menus are a mess) >>How can I file a bug whose component I do not know ... if something >>broke in gnome, I know it's broken, and I have no idea which component >>is responsible... >> >> > >There's a component called "distribution" where you can log general >distribution bugs. As for not knowing the particular component which a bug >resides in, make an educated guess and the developers will generally sort >it out from there. > > ...or, if you absolutely have no idea, use general "distribution" component and hope that person responsible for this component will reassign your bug to proper component/person. As for the bug interdependencies, there are several mechanisms in bugzilla for dealing with that. 1. Duplicates. If two bugs are the same (almost the same), one can be marked as a DUPLICATE for the other. 2. References in comments. One can just write smth like "this bug is probably related to bug #123456", and bugzilla will create a hyperlink to bug #123456 from that text. 3. Dependencies. A bug can depend on another bug to be fixed, and bugzilla has a mechanism to enter and use this info. PS if developers don't react to the bug during some long time, one reason can be is bug description is not clear. It may be too small and lacking details, or it may be too long and hard-to-read. Sure, there are many other reasons. In any case, you can always add _non-offensive_ comment to the bug in question, asking that more info can you provide (or actually providing some more info on bug if you feel you have it). It also serves as a "developer ping". From dhollis at davehollis.com Wed Feb 11 20:50:45 2004 From: dhollis at davehollis.com (David T Hollis) Date: Wed, 11 Feb 2004 15:50:45 -0500 Subject: dvgrab, 1394 and firewire stuff In-Reply-To: <402A6EAC.5000005@redhat.com> References: <402A6EAC.5000005@redhat.com> Message-ID: <1076532645.24623.1.camel@dhollis-lnx.kpmg.com> On Wed, 2004-02-11 at 08:04 -1000, Warren Togami wrote: > We now have an opportunity to upgrade the "ancient" versions of the > firewire packages before the February 27th deadline. Please suggest > upgrade versions, URL's, exact patches in this thread. It would help if > you actually test them too... > > Warren > dvgrab is currently at 1.5. I have an SRPM available at http://www. davehollis.com/~dhollis/dvgrab-1.5-1.src.rpm. -- David T Hollis From czar at czarc.net Wed Feb 11 22:51:43 2004 From: czar at czarc.net (Gene C.) Date: Wed, 11 Feb 2004 17:51:43 -0500 Subject: firefox on the amd64 Message-ID: <200402111751.43293.czar@czarc.net> Is anyone working on getting firefox working on the x86_64? -- Gene From dag at wieers.com Wed Feb 11 23:06:49 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 12 Feb 2004 00:06:49 +0100 (CET) Subject: firefox on the amd64 In-Reply-To: <200402111751.43293.czar@czarc.net> References: <200402111751.43293.czar@czarc.net> Message-ID: On Wed, 11 Feb 2004, Gene C. wrote: > Is anyone working on getting firefox working on the x86_64? As soon as RHFC2 for AMD64 is released, I'll be maintaining also a seperate AMD64 repository. I'm now waiting to get a RHEL3 AMD64 entitlement and so I hope to build my repository for that too. In the meantime you can use the 32bit version from: http://dag.wieers.com/packages/firefox/ Now onto thunderbird 0.5. ;-) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From cornette at insight.rr.com Wed Feb 11 23:49:11 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Wed, 11 Feb 2004 18:49:11 -0500 Subject: test - passed, but other lists still have it In-Reply-To: <4028F6B3.7020606@redhat.com> References: <200402100130.i1A1UNb25922@mx1.redhat.com> <4028F6B3.7020606@redhat.com> Message-ID: <402ABF77.3020702@insight.rr.com> Chuck Mead wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > katzj at redhat.com *did not write:* > > > > I use postfix for my MTA's and in conjunction with the config found here: > > http://moongroup.com/outbound.config > > I block the content which was contained in the original of this message > with this regexp: > > /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(ad[ep]|asd|ba[st]|c[ho]m|cmd|cpl|crt|dbx|dll|exe|hlp|hta|in[fs]|isp|lnk|js|jse|lnk|ocx|md[etw]|ms[cipt]|nws|ocx|ops|pcd|pi|pif|prf|reg|scf|scr|sct|sh[bms]|swf|uue|vb|vb[esx]|vxd|wab|ws[cfh]))"?\s*$/ > Has this block been implemented for the other lists? I have received messages from fedora-test-list that were from addresses that were not someome at redhat.com addresses. - nbryant at optonline.net and also another email. Both were non-rhat addresses. This mail came back with the attatchment removed and I didn't get a warning message from my ISP. If the block works. It sounds like it would be great to implement for all lists. Jim From csm at redhat.com Wed Feb 11 23:51:51 2004 From: csm at redhat.com (Chuck Mead) Date: Wed, 11 Feb 2004 18:51:51 -0500 Subject: test - passed, but other lists still have it In-Reply-To: <402ABF77.3020702@insight.rr.com> References: <200402100130.i1A1UNb25922@mx1.redhat.com> <4028F6B3.7020606@redhat.com> <402ABF77.3020702@insight.rr.com> Message-ID: <402AC017.1040400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Cornette wrote: | Chuck Mead wrote: | |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> katzj at redhat.com *did not write:* |> |> |> |> I use postfix for my MTA's and in conjunction with the config found here: |> |> http://moongroup.com/outbound.config |> |> I block the content which was contained in the original of this message |> with this regexp: |> |> /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(ad[ep]|asd|ba[st]|c[ho]m|cmd|cpl|crt|dbx|dll|exe|hlp|hta|in[fs]|isp|lnk|js|jse|lnk|ocx|md[etw]|ms[cipt]|nws|ocx|ops|pcd|pi|pif|prf|reg|scf|scr|sct|sh[bms]|swf|uue|vb|vb[esx]|vxd|wab|ws[cfh]))"?\s*$/ |> | | | Has this block been implemented for the other lists? I have received | messages from fedora-test-list that were from addresses that were not | someome at redhat.com addresses. - nbryant at optonline.net and also another | email. Both were non-rhat addresses. | | This mail came back with the attatchment removed and I didn't get a | warning message from my ISP. | | If the block works. It sounds like it would be great to implement for | all lists. ~From what I can tell this is not being done. - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAKsAXZfy0juH51WsRAvUNAJ9t9REnraq4dxvedNguy+5VukNPFACfT/78 JhCoLboPHdEpvPCuX81Rhdg= =JkME -----END PGP SIGNATURE----- From rob.myers at gtri.gatech.edu Thu Feb 12 00:01:06 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Wed, 11 Feb 2004 19:01:06 -0500 Subject: firefox on the amd64 In-Reply-To: <200402111751.43293.czar@czarc.net> References: <200402111751.43293.czar@czarc.net> Message-ID: <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> On Wed, 2004-02-11 at 17:51, Gene C. wrote: > Is anyone working on getting firefox working on the x86_64? nope, but let me know if there is anything i can help test. rob. From czar at czarc.net Thu Feb 12 00:12:45 2004 From: czar at czarc.net (Gene C.) Date: Wed, 11 Feb 2004 19:12:45 -0500 Subject: firefox on the amd64 In-Reply-To: <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> References: <200402111751.43293.czar@czarc.net> <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> Message-ID: <200402111912.45635.czar@czarc.net> On Wednesday 11 February 2004 19:01, Rob Myers wrote: > On Wed, 2004-02-11 at 17:51, Gene C. wrote: > > Is anyone working on getting firefox working on the x86_64? > > nope, but let me know if there is anything i can help test. As luck would have it, I found that the x86_64 patch for mozilla-1.6 also works for firefox (at least it compiles). I probably will not get rpms built until tomorrow. When I do, I will put it out on a server and post a notice here as well as to fedora.us (https://bugzilla.fedora.us/show_bug.cgi?id=1272). Besides compiling, I would like to make sure that it basically works. -- Gene From warren at togami.com Thu Feb 12 00:26:57 2004 From: warren at togami.com (Warren Togami) Date: Wed, 11 Feb 2004 14:26:57 -1000 Subject: firefox on the amd64 In-Reply-To: <200402111912.45635.czar@czarc.net> References: <200402111751.43293.czar@czarc.net> <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> <200402111912.45635.czar@czarc.net> Message-ID: <402AC851.3000301@togami.com> Gene C. wrote: > On Wednesday 11 February 2004 19:01, Rob Myers wrote: > >>On Wed, 2004-02-11 at 17:51, Gene C. wrote: >> >>>Is anyone working on getting firefox working on the x86_64? >> >>nope, but let me know if there is anything i can help test. > > > As luck would have it, I found that the x86_64 patch for mozilla-1.6 also > works for firefox (at least it compiles). I probably will not get rpms built > until tomorrow. When I do, I will put it out on a server and post a notice > here as well as to fedora.us > (https://bugzilla.fedora.us/show_bug.cgi?id=1272). > > Besides compiling, I would like to make sure that it basically works. This isn't really my decision, but I think we should not bother distributing 64bit mozilla or firefox unless all of the popular plugin providers also distribute 64bit gcc 3.3.x plugins. The browser is not very useful without the plugins for end users. Nothing stops 3rd party repositories from doing so though... Warren From alan at redhat.com Thu Feb 12 00:29:01 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 11 Feb 2004 19:29:01 -0500 Subject: firefox on the amd64 In-Reply-To: <402AC851.3000301@togami.com> References: <200402111751.43293.czar@czarc.net> <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> <200402111912.45635.czar@czarc.net> <402AC851.3000301@togami.com> Message-ID: <20040212002901.GA12513@devserv.devel.redhat.com> On Wed, Feb 11, 2004 at 02:26:57PM -1000, Warren Togami wrote: > This isn't really my decision, but I think we should not bother > distributing 64bit mozilla or firefox unless all of the popular plugin > providers also distribute 64bit gcc 3.3.x plugins. The browser is not > very useful without the plugins for end users. If we don't ship the browser, they wont ship the plugins. From cra at WPI.EDU Thu Feb 12 00:36:44 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 11 Feb 2004 19:36:44 -0500 Subject: firefox on the amd64 In-Reply-To: <402AC851.3000301@togami.com> References: <200402111751.43293.czar@czarc.net> <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> <200402111912.45635.czar@czarc.net> <402AC851.3000301@togami.com> Message-ID: <20040212003644.GB15491@angus.ind.WPI.EDU> On Wed, Feb 11, 2004 at 02:26:57PM -1000, Warren Togami wrote: > The browser is not very useful without the plugins for end users. I disagree. Plugins are for eye candy or crashing the browser. From stevelist at silverorange.com Thu Feb 12 01:26:48 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Wed, 11 Feb 2004 21:26:48 -0400 Subject: Firefox as default browser in Fedora Message-ID: <402AD658.1070406@silverorange.com> In the interest of disclosure, I've worked on the Visual Identity team responsible for the new Firefox logo (and more stuff to come). I'm not making money on it, but I am involved in Firefox. I would like to see Firefox included as the default web browser on Fedora. I know the discussion about including Mozilla Firebird has been had several times over here on the fedora-devel-list. The general consensus I was able to garner from searching the archives seems to be something like this: > ?There are already too many browsers in Fedora? This is certainly true. I don't think anyone would advocate adding another browser without dropping one of the existing browsers. Mozilla 'classic' would be the prime candidate. That said, I would hate to see necessities to keep Mozilla prevent a strong browser from getting in. > ?Mozilla is required for other apps? There didn't seem to be any confirmation of this, but there was speculation that some other apps in Fedora may depend on Mozilla libraries. For example, Karl DeBisschop said of replacing Mozilla with Firefox, still called firebird at the time (http://redhat.com/archives/fedora-devel-list/2003-December/msg00295.html): > Can't speak for others, but I'd take that trade. It's probably not > really practical, however, because epiphany (and galeon2) both depend > on the libs from mozilla classic, so ath that point why would you not > have the browser since you already had the libs. Or could galeon and > epiphany be made to run on the Firebird libs? Can anyone clarify this? It looks to me that Epiphany does require Mozilla - but nothing else seems to. > ?The Mozilla suite is is more complete? Well, Firefox can certainly replace the browser component of Mozilla (Navigator). I'm not sure if Thunderbird is ready to be included as a mail client ? but then again, Evolution is already in there and with it's move into Gnome, is clearly a strong default. Also, ChatZilla can be installed on top of Firefox as an XPI. > ?It's not ready (1.0) yet? This has probably been the biggest hurdle to getting Firefox into Fedora, and rightly so. However, I find that the latest 0.8 release is a stable release and the lack of a ?1.0? status is really just nomenclature. Many people have been using Firefox (then firebird) as their primary browser for over six months (myself included). Also, from now on, development on Firefox is aimed at refinements towards 1.0. Now would be a good time to get started on bringing it into Fedora, to have it ready and integrated in time with Firefox 1.0. Even if it is decided to wait for 1.0 before including Firefox or making it the default browser, I don't think it is necessary to wait for 1.0 to make a decision. Firefox 0.8 is strong enough to be judged worthy of inclusion/default-status as is. I think that Firefox is a better browsing experience. It is faster, smaller (significantly smaller almost half the size of Mozilla Navigator packages). Comments/feedback appreciated. Thank you, Steven Garrity From cornette at insight.rr.com Thu Feb 12 02:21:06 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Wed, 11 Feb 2004 21:21:06 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <402AD658.1070406@silverorange.com> References: <402AD658.1070406@silverorange.com> Message-ID: <402AE312.6030909@insight.rr.com> Steven Garrity wrote: > In the interest of disclosure, I've worked on the Visual Identity team > responsible for the new Firefox logo (and more stuff to come). I'm not > making money on it, but I am involved in Firefox. > > I would like to see Firefox included as the default web browser on Fedora. > > I know the discussion about including Mozilla Firebird has been had > several times over here on the fedora-devel-list. The general consensus > I was able to garner from searching the archives seems to be something > like this: > > >> ?There are already too many browsers in Fedora? > > This is certainly true. I don't think anyone would advocate adding > another browser without dropping one of the existing browsers. Mozilla > 'classic' would be the prime candidate. That said, I would hate to see > necessities to keep Mozilla prevent a strong browser from getting in. > > >> ?Mozilla is required for other apps? > > There didn't seem to be any confirmation of this, but there was > speculation that some other apps in Fedora may depend on Mozilla libraries. > > For example, Karl DeBisschop said of replacing Mozilla with Firefox, > still called firebird at the time > (http://redhat.com/archives/fedora-devel-list/2003-December/msg00295.html): > >> Can't speak for others, but I'd take that trade. It's probably not >> really practical, however, because epiphany (and galeon2) both depend >> on the libs from mozilla classic, so ath that point why would you not >> have the browser since you already had the libs. Or could galeon and >> epiphany be made to run on the Firebird libs? > > > Can anyone clarify this? It looks to me that Epiphany does require > Mozilla - but nothing else seems to. > > >> ?The Mozilla suite is is more complete? > > Well, Firefox can certainly replace the browser component of Mozilla > (Navigator). I'm not sure if Thunderbird is ready to be included as a > mail client ? but then again, Evolution is already in there and with > it's move into Gnome, is clearly a strong default. Also, ChatZilla can > be installed on top of Firefox as an XPI. > > >> ?It's not ready (1.0) yet? > > This has probably been the biggest hurdle to getting Firefox into > Fedora, and rightly so. However, I find that the > latest 0.8 release is a stable release and the lack of a ?1.0? > status is really just nomenclature. Many people have been using Firefox > (then firebird) as their primary browser for over six months (myself > included). > > Also, from now on, development on Firefox is aimed at refinements > towards 1.0. Now would be a good time to get started on bringing it into > Fedora, to have it ready and integrated in time with Firefox 1.0. > > Even if it is decided to wait for 1.0 before including Firefox or making > it the default browser, I don't think it is necessary to wait for 1.0 to > make a decision. Firefox 0.8 is strong enough to be judged worthy of > inclusion/default-status as is. > > I think that Firefox is a better browsing experience. It is > faster, smaller (significantly smaller almost half the size of Mozilla > Navigator packages). > > Comments/feedback appreciated. > > Thank you, > Steven Garrity > > > I started using Mozilla back before it was included with Redhat distributions. I like the integration with the mail client and feel that it is still a decent browser. I tried Firefox (when it was still MozillaFirebird and also Thunderbird.) It seems that splitting the browser from the email client seems as bad an idea as messing up nautilus as it currently is. (A poor and pretty worthless filemanager of late). If Mozilla ever stops getting the support and the seperate browser and mail client scheme still keeps compatibility, between the two seperate entities, then I have no rants about switching to seperatated programs to replace the mozilla browser/mailclient/html editor. I use all of these and believe that they are good as one entity or suite. I will probably download and test firefox in the future, but since it is new and probably going to be far from not needing bug fixes on a pretty regular basis. I think holding off for awhile, on including firefox and Thunderbird, would be a good move. Including it in the development tree might be a good idea though, since development is pretty much changing a lot, unless frozen for a beta release. Just my view, Jim -- A friend of mine won't get a divorce, because he hates lawyers more than he hates his wife. From cra at WPI.EDU Thu Feb 12 02:32:42 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 11 Feb 2004 21:32:42 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <402AD658.1070406@silverorange.com> References: <402AD658.1070406@silverorange.com> Message-ID: <20040212023242.GC15491@angus.ind.WPI.EDU> On Wed, Feb 11, 2004 at 09:26:48PM -0400, Steven Garrity wrote: > >?It's not ready (1.0) yet? > This has probably been the biggest hurdle to getting Firefox into > Fedora, and rightly so. However, I find that the > latest 0.8 release is a stable release and the lack of a ?1.0? > status is really just nomenclature. Many people have been using Firefox > (then firebird) as their primary browser for over six months (myself > included). Does Firefox work with/migrate your existing Mozilla profile without losing data? I consider that feature to be a major blocker to including Firefox as a default browser in Fedora. From warren at togami.com Thu Feb 12 02:42:38 2004 From: warren at togami.com (Warren Togami) Date: Wed, 11 Feb 2004 16:42:38 -1000 (HST) Subject: Firefox as default browser in Fedora In-Reply-To: <402AD658.1070406@silverorange.com> References: <402AD658.1070406@silverorange.com> Message-ID: <32820.66.91.85.198.1076553758.squirrel@togami.com> > In the interest of disclosure, I've worked on the Visual Identity team > responsible for the new Firefox logo (and more stuff to come). I'm not > making money on it, but I am involved in Firefox. > http://forums.mozillazine.org/viewtopic.php?t=50876 http://forums.mozillazine.org/viewtopic.php?p=366523#366523 On the topic of the Firefox logo, this is some seemingly unhappy news. The logo however is unrelated to your question. > I would like to see Firefox included as the default web browser on Fedora. https://bugzilla.fedora.us/show_bug.cgi?id=1272 The first hurdle will be eventual official inclusion into Fedora. The first step in reaching that goal would be to make the Firefox 0.8 submitted package at fedora.us of the highest quality now. Could you serve as an active liason with upstream developers in order to help this process? I personally use and really love Firebird and now Firefox, but there are a few realistic hurdles, mostly technical to make this a possibility. Read below. > > I know the discussion about including Mozilla Firebird has been had > several times over here on the fedora-devel-list. The general consensus > I was able to garner from searching the archives seems to be something > like this: > > >> ?There are already too many browsers in Fedora? > This is certainly true. I don't think anyone would advocate adding > another browser without dropping one of the existing browsers. Mozilla > 'classic' would be the prime candidate. That said, I would hate to see > necessities to keep Mozilla prevent a strong browser from getting in. > Blizzard mentioned that the lack of automatic importing is a blocker for inclusion of both Firebird and Thunderbird. I personally see the current poor situation of xremote clashes, broken xremote functions (while Thunderbird is running), and poor dekstop integration (actually launching the right user-chosen Preferred Application) globally as hurdles. I personally use a bunch of ugly hacks in my personal FC desktop in order to make all the applications work together. The xremote problems make it extremely problematic to use Firefox, while keeping the regular Mozilla suite as the mail client. Some users really want to keep it this way. The lack of automatic importing makes it difficult to quickly switch to the Firefox/Thunderbird combo. That combo does work well with ugly script hacks that avoid the broken xremote functions. > >> ?Mozilla is required for other apps? > There didn't seem to be any confirmation of this, but there was > speculation that some other apps in Fedora may depend on Mozilla > libraries. > > For example, Karl DeBisschop said of replacing Mozilla with Firefox, > still called firebird at the time > (http://redhat.com/archives/fedora-devel-list/2003-December/msg00295.html): >> Can't speak for others, but I'd take that trade. It's probably not >> really practical, however, because epiphany (and galeon2) both depend >> on the libs from mozilla classic, so ath that point why would you not >> have the browser since you already had the libs. Or could galeon and >> epiphany be made to run on the Firebird libs? > > Can anyone clarify this? It looks to me that Epiphany does require > Mozilla - but nothing else seems to. > gaim and other GPL applications that need SSL capability are unable to use OpenSSL due to GPL incompatibility. As a result gaim has the option of linking against mozilla-nss or gnutls. gnutls is not shipped in the distribution (something about code quality?), so gaim currently needs mozilla-nss. I think fedora.us ships something that uses mozilla-nss too, but I cannot remember off the top of my head. I suppose it may be possible to link gaim to Firefox, but I don't know if anyone has tried. I heard something about openoffice using a mozilla component for *something*, but I don't know the details there. Can anyone confirm? > >> ?The Mozilla suite is is more complete? > Well, Firefox can certainly replace the browser component of Mozilla > (Navigator). I'm not sure if Thunderbird is ready to be included as a > mail client ? but then again, Evolution is already in there and with > it's move into Gnome, is clearly a strong default. Also, ChatZilla can > be installed on top of Firefox as an XPI. I personally use Firefox and Thunderbird every day. IMHO both clients are ready, but it is impossible to use Firefox if you are unable to stop using the old mozilla suite. The poor behavior of xremote is just such a hassle. And again the lack of automatic import... https://bugzilla.fedora.us/show_bug.cgi?id=1113 Thunderbird 0.5 at fedora.us It seems a terrible situation that the upstream "official" tarball was broken (contained CRLF's) with the first two attempts. Anyone know if they fixed this yet? Please help us polish the supporting scripts of Thunderbird so we can finally release this into fedora.us Extras. Please also give opinions about the package name. Ignore my comments around #45. Yes I was full of crack. See this report below for my proposed solution to go into the official mozilla-1.6 update and firefox /usr/bin startup scripts. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114524 This fix workarounds the broken xremote functions, enough to make mozilla somewhat usable while Thunderbird is running. Firefox should be fully usable when properly configured. Reviews of this fix are needed. Warren Togami wtogami at redhat.com From stevelist at silverorange.com Thu Feb 12 03:14:33 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Wed, 11 Feb 2004 23:14:33 -0400 Subject: Firefox as default browser in Fedora In-Reply-To: <32820.66.91.85.198.1076553758.squirrel@togami.com> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> Message-ID: <402AEF99.8090406@silverorange.com> Warren Togami wrote: > http://forums.mozillazine.org/viewtopic.php?t=50876 > http://forums.mozillazine.org/viewtopic.php?p=366523#366523 > On the topic of the Firefox logo, this is some seemingly unhappy news. > The logo however is unrelated to your question. I wouldn't worry too much about this. We're still working on it. > https://bugzilla.fedora.us/show_bug.cgi?id=1272 > The first hurdle will be eventual official inclusion into Fedora. The > first step in reaching that goal would be to make the Firefox 0.8 > submitted package at fedora.us of the highest quality now. Could you > serve as an active liason with upstream developers in order to help this > process? Agreed - I've been keeping an eye on the package progress so far. I would be glad to help any way I can, including acting as a liaison with the upstream developers. I'm in touch with the Firefox developers in the context of the visual identity work, but I am not a developer myself. That said, I do feel I can get the right information to the right people. > Blizzard mentioned that the lack of automatic importing is a blocker for > inclusion of both Firebird and Thunderbird. I certainly agree that with a mail application, smooth profile migration is key. However, with a web-browser, the profile is much less significant. I'm not necessarily advocating the inclusion of Thunderbird - especially with the great work being done with Evolution. So, as you pointed out, making sure that Firefox can play nice with Mozilla Mail is important, which leads us to... > I personally see the current poor situation of xremote clashes, broken > xremote functions (while Thunderbird is running), and poor dekstop > integration (actually launching the right user-chosen Preferred > Application) globally as hurdles. I personally use a bunch of ugly hacks > in my personal FC desktop in order to make all the applications work > together. > > The xremote problems make it extremely problematic to use Firefox, while > keeping the regular Mozilla suite as the mail client. Some users really > want to keep it this way. The lack of automatic importing makes it > difficult to quickly switch to the Firefox/Thunderbird combo. That combo > does work well with ugly script hacks that avoid the broken xremote > functions. I completely agree. I had to get a script to launch Firefox too. It works fine once a decent launch script is in place, but I agree that this needs to be improved. That said, this is something that could potentially be patched band-aid solutions in the Fedora package while the core issues are worked out. Is there anyone who has knowledge to help me talk to the Firefox developers about the xremote problems, or better yet, someone who can help the Firefox developers fix the problems? Please let me know. > gaim and other GPL applications that need SSL capability are unable to use > OpenSSL due to GPL incompatibility. As a result gaim has the option of > linking against mozilla-nss or gnutls. gnutls is not shipped in the > distribution (something about code quality?), so gaim currently needs > mozilla-nss. I think fedora.us ships something that uses mozilla-nss too, > but I cannot remember off the top of my head. I suppose it may be > possible to link gaim to Firefox, but I don't know if anyone has tried. I'm not sure about this - can anyone clarify? Thanks for the thoughtful reply Warren, Steven Garrity From smoogen at lanl.gov Thu Feb 12 03:18:37 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 11 Feb 2004 20:18:37 -0700 (MST) Subject: firefox on the amd64 In-Reply-To: <20040212003644.GB15491@angus.ind.WPI.EDU> References: <200402111751.43293.czar@czarc.net> <1076544066.25182.1084.camel@dungeness.stl.gtri.gatech.edu> <200402111912.45635.czar@czarc.net> <402AC851.3000301@togami.com> <20040212003644.GB15491@angus.ind.WPI.EDU> Message-ID: On Wed, 11 Feb 2004, Charles R. Anderson wrote: >On Wed, Feb 11, 2004 at 02:26:57PM -1000, Warren Togami wrote: >> The browser is not very useful without the plugins for end users. > >I disagree. Plugins are for eye candy or crashing the browser. Then why not just use lynx :)? -- 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 cra at WPI.EDU Thu Feb 12 04:14:54 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 11 Feb 2004 23:14:54 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <402AEF99.8090406@silverorange.com> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> <402AEF99.8090406@silverorange.com> Message-ID: <20040212041454.GA30329@angus.ind.WPI.EDU> On Wed, Feb 11, 2004 at 11:14:33PM -0400, Steven Garrity wrote: > >Blizzard mentioned that the lack of automatic importing is a blocker for > >inclusion of both Firebird and Thunderbird. > I certainly agree that with a mail application, smooth profile migration > is key. However, with a web-browser, the profile is much less > significant. Many people will be upset to lose their years of cookie permissions, saved form data, and saved passwords. At least bookmarks can be copied around pretty easily. From corsepiu at faw.uni-ulm.de Thu Feb 12 09:34:43 2004 From: corsepiu at faw.uni-ulm.de (Ralf Corsepius) Date: Thu, 12 Feb 2004 10:34:43 +0100 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <4029469D.6030106@redhat.com> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> Message-ID: <1076578482.3858.15.camel@mccallum.corsepiu.faw.uni-ulm.de> On Tue, 2004-02-10 at 22:01, Warren Togami wrote: > Kristof Vansant wrote: > > k but I still don't understand why with yum everything goes slower then with > > apt-get. > > Has apt-get better mirror support or something? > > yum actually has better mirror and fail-over support than apt today. Probably true with yum > 2.0.4. FC1's yum still lacks a download-only option. > > My friend has a big apt-get sources list and yum list. Apt-get had his > > sources list in 2 minutes. Yum was still loading header files after half an > > hour. > > Could be DNS related issues. One possibility. Other reasons * The sizes: The over-all size of a yum headers/ directory is larger than the size of apt's pkglists etc. * Connectivity/Reachability of server: When downloading a headers/ directory (or many files from it), yum uses many connections, apt uses few connections. > > I can understand his frustration. What's the cause in this big speed > > difference? > > > 3) Concern that apt is redundant to the other clients, and maintaining > it would be cost/time prohibitive. I don't understand, both apt and yum repositories can be generated as part of the same automated process. The time consuming part is writing the rpms/rpm.specs. > Aside from the speed advantages, I personally see apt as my personal > favorite for several other reasons: So do I. (I still haven't figured out yum's counterpart of apt-get source and apt-get build-dep :-) ) Ralf From gteale at cmedltd.com Thu Feb 12 09:35:46 2004 From: gteale at cmedltd.com (Geoff Teale) Date: Thu, 12 Feb 2004 09:35:46 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <20040212041454.GA30329@angus.ind.WPI.EDU> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> <402AEF99.8090406@silverorange.com> <20040212041454.GA30329@angus.ind.WPI.EDU> Message-ID: <1076578546.21973.4.camel@dubya> On Thu, 2004-02-12 at 04:14, Charles R. Anderson wrote: > Many people will be upset to lose their years of cookie permissions, > saved form data, and saved passwords. At least bookmarks can be > copied around pretty easily. This cannot be the be-all and end-all argument. If it was we'd never move forward. That said including firefox as an option is a sensible first stage - making it the default is a whole step beyond that and introduces other questions like: "Why not epiphany? (as an integral part of Gnome)" -- Geoff Teale Cmed Technology From rms at 1407.org Thu Feb 12 09:56:38 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 12 Feb 2004 09:56:38 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <402AEF99.8090406@silverorange.com> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> <402AEF99.8090406@silverorange.com> Message-ID: <1076579798.1658.135.camel@roque> On Wed, 2004-02-11 at 23:14 -0400, Steven Garrity wrote: > Warren Togami wrote: > > http://forums.mozillazine.org/viewtopic.php?t=50876 > > http://forums.mozillazine.org/viewtopic.php?p=366523#366523 > > On the topic of the Firefox logo, this is some seemingly unhappy news. > > The logo however is unrelated to your question. > I wouldn't worry too much about this. We're still working on it. Work something reasonable out soon. Similar conditions may make Firefox unsuitable for Fedora Core in terms of licensing. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Thu Feb 12 10:40:14 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 12 Feb 2004 05:40:14 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <1076578546.21973.4.camel@dubya> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> <402AEF99.8090406@silverorange.com> <20040212041454.GA30329@angus.ind.WPI.EDU> <1076578546.21973.4.camel@dubya> Message-ID: <20040212104014.GB4571@devserv.devel.redhat.com> On Thu, Feb 12, 2004 at 09:35:46AM +0000, Geoff Teale wrote: > first stage - making it the default is a whole step beyond that and > introduces other questions like: > > "Why not epiphany? (as an integral part of Gnome)" Which is the question I'd always ask, because epiphany is consistent with the desktop and has good translations. From alan at redhat.com Thu Feb 12 10:45:52 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 12 Feb 2004 05:45:52 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <1076579798.1658.135.camel@roque> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> <402AEF99.8090406@silverorange.com> <1076579798.1658.135.camel@roque> Message-ID: <20040212104552.GC4571@devserv.devel.redhat.com> On Thu, Feb 12, 2004 at 09:56:38AM +0000, Rui Miguel Seabra wrote: > Work something reasonable out soon. Similar conditions may make Firefox > unsuitable for Fedora Core in terms of licensing. I don't think that will be a big problem. The trademark stuff is actually hard to do right (I've been watching the gnome people fail horribly for over a year but since they are about to ship GPL code linked with their logo in 2.6 I guess estoppel is about to resolve the problem for good 8)). The Fedora trademark rules were also a lot of fun for the lawyers (thanks Mark btw...). The Mozilla situation for Firebird seems to be just like the Red Hat one, remove the logos, have fun. One good thing is that they plan to also have official artwork that isnt the trademarked one so vendors can at least make it plain that its "not official mozilla" rather than having to rip the credit logos out. For the general artwork - you'd want bluecurve art anyway to make it match the desktop a bit better Alan From gteale at cmedltd.com Thu Feb 12 10:47:17 2004 From: gteale at cmedltd.com (Geoff Teale) Date: Thu, 12 Feb 2004 10:47:17 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <20040212104014.GB4571@devserv.devel.redhat.com> References: <402AD658.1070406@silverorange.com> <32820.66.91.85.198.1076553758.squirrel@togami.com> <402AEF99.8090406@silverorange.com> <20040212041454.GA30329@angus.ind.WPI.EDU> <1076578546.21973.4.camel@dubya> <20040212104014.GB4571@devserv.devel.redhat.com> Message-ID: <1076582837.10928.36.camel@dubya> On Thu, 2004-02-12 at 10:40, Alan Cox wrote: > Which is the question I'd always ask, because epiphany is consistent > with the desktop and has good translations. Absolutely. We have to keep the Welsh contingent happy! ;) I am running firefox on my laptop right now. Whilst it is very nice (and I must say the logo is wonderful) my main Fedora box at home, and this machine (my work Gentoo box) both run epiphany and I find it to be by far the best web browser within a Gnome desktop. So long as Gnome is the default desktop I would argue for epiphany as the (eventual) successor to Mozilla as the default browser. -- GJT gteale at cmedltd.com Seeing is deceiving. It's eating that's believing. -- James Thurber From salimma at fastmail.fm Thu Feb 12 14:54:08 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Thu, 12 Feb 2004 21:54:08 +0700 Subject: bug and new package In-Reply-To: References: Message-ID: <1076597648.4412.0.camel@localhost.localdomain> On Wed, 2004-02-11 at 10:43 +0100, Zoltan Kota wrote: [snip] > list)... What to do then? Is it better to wait for finishing the merging, > or to submit to fedora.us? > Submit to fedora.us for now. HTH, - 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 mike at flyn.org Thu Feb 12 17:05:07 2004 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 12 Feb 2004 11:05:07 -0600 Subject: Bugzilla and Fedora Core 2 Test 1 Message-ID: <20040212170507.GA2509@imp.flyn.org> What product should bugs in Fedora Core 2 Test 1 be filed against? Red Hat Bugzilla provides the following options: Fedora Core, 1 Fedora Core, devel Fedora Core, test1 Fedora Core, test2 Fedora Core, test3 I'm not clear whether "Fedora Core, test1" means "Fedora Core 1, test1" or "Fedora Core , test1." Perhaps Bugzilla has not yet been updated to reflect Fedora Core 2 Test 1's release? -- Mike :wq From notting at redhat.com Thu Feb 12 17:09:46 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Feb 2004 12:09:46 -0500 Subject: Bugzilla and Fedora Core 2 Test 1 In-Reply-To: <20040212170507.GA2509@imp.flyn.org> References: <20040212170507.GA2509@imp.flyn.org> Message-ID: <20040212170946.GC18065@devserv.devel.redhat.com> W. Michael Petullo (mike at flyn.org) said: > What product should bugs in Fedora Core 2 Test 1 be filed against? > Red Hat Bugzilla provides the following options: ... > Fedora Core, test1 This is the correct one. The fact that there is currently a FC1 test 1 (for x86-64) and FC2 test 1 (for x86) is a minor problem, but hopefully one that won't happen again. >:) Bill From leonard at den.ottolander.nl Thu Feb 12 17:47:18 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 12 Feb 2004 18:47:18 +0100 Subject: Evolution crashing on editing To: field In-Reply-To: <20040212170507.GA2509@imp.flyn.org> References: <20040212170507.GA2509@imp.flyn.org> Message-ID: <1076608037.7635.5.camel@athlon.localdomain> Hi folks, (Sorry for threadjacking, but I can not post otherwise.) Since monday morning I experience a crash whenever I try to create a new mail message in Evolution and either press the To: button or edit the To: field. This means that I can only mail by replying. This is getting very annoying as you can imagine. Anybody else experiencing the same thing? Any help to resolve this issue quickly is appreciated. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115308 and http://bugzilla.ximian.com/show_bug.cgi?id=54243 . Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dhollis at davehollis.com Thu Feb 12 18:24:37 2004 From: dhollis at davehollis.com (David T Hollis) Date: Thu, 12 Feb 2004 13:24:37 -0500 Subject: Evolution crashing on editing To: field In-Reply-To: <1076608037.7635.5.camel@athlon.localdomain> References: <20040212170507.GA2509@imp.flyn.org> <1076608037.7635.5.camel@athlon.localdomain> Message-ID: <1076610277.5396.0.camel@dhollis-lnx.kpmg.com> On Thu, 2004-02-12 at 18:47 +0100, Leonard den Ottolander wrote: > Hi folks, > > (Sorry for threadjacking, but I can not post otherwise.) > > Since monday morning I experience a crash whenever I try to create a new > mail message in Evolution and either press the To: button or edit the > To: field. This means that I can only mail by replying. > > This is getting very annoying as you can imagine. Anybody else > experiencing the same thing? Any help to resolve this issue quickly is > appreciated. > > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115308 and > http://bugzilla.ximian.com/show_bug.cgi?id=54243 . > I'm running with Evo 1.5.3-1 and evolution-data-server 0.0.6-1 and I haven't seen that problem at all. -- David T Hollis From leonard at den.ottolander.nl Thu Feb 12 18:52:07 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 12 Feb 2004 19:52:07 +0100 Subject: Evolution crashing on editing To: field In-Reply-To: <1076610277.5396.0.camel@dhollis-lnx.kpmg.com> References: <20040212170507.GA2509@imp.flyn.org> <1076608037.7635.5.camel@athlon.localdomain> <1076610277.5396.0.camel@dhollis-lnx.kpmg.com> Message-ID: <1076611927.7635.9.camel@athlon.localdomain> Hello David, > > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115308 and > > http://bugzilla.ximian.com/show_bug.cgi?id=54243 . > > > I'm running with Evo 1.5.3-1 and evolution-data-server 0.0.6-1 and I > haven't seen that problem at all. I am running 1.4.5-7. I would like to see this fixed in that version, as I don't feel like upgrading yet. In some cases I like to just use an app. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From erik at totalcirculation.com Thu Feb 12 18:57:17 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 12 Feb 2004 13:57:17 -0500 Subject: Self Introduction: Erik S. LaBianca Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB65905C8CA@smith.interlink.local> 1. Full legal name Erik Sakala LaBianca 2. Country, City Berrien Springs, MI, USA 3. Profession or Student status Software Developer 4. Company or School Interlink, Inc. 5. Your goals in the Fedora Project * Which packages do you want to see published? I'd like to see all the software I use on a regular basis included with Fedora Core and Extras. The sore spots right now are amavisd, the firebird database, rsnapshot, and an assortment of CPAN modules. * Do you want to do QA? Yes, if it means I don't have to maintain my own custom RPMS anymore :) * Anything else special? I'm particularly interested in seeing a user-friendly backup system included out of the box with fedora. I've also done some work towards an easy way of creating a kickstart from a modified running system. I think ease of installation / restore is already a real selling point for fedora, but it still needs some work. 6. Historical qualifications * What other projects have you worked on in the past? Primarily proprietary commercial software, and little unpublished hacks to open source stuff. I maintain a suite of custom RPMS that we use to kickstart install all our production servers. * What computer languages and other skills do you know? I'm a reasonably competent C++, Java and Delphi/Pascal programmer. I also speak Perl well but am migrating to Python. I've written tons of PHP code too but I'm trying to avoid doing it ever again. I've been using Linux (Slackware, Debian, Redhat, Gentoo, Fedora) for around 10 years, and have been a system administrator for both Windows and Linux for the last 4 or so. I've also been the project manager and system architect for several projects, so I have some useful communication and problem solving skills. * Why should we trust you? Maybe you shouldn't? Wait and see. I have a longtime commitment to linux and open source, and I have some useful skills. 7. GPG KEYID and fingerprint pub 1024D/736A7502 2004-02-12 Erik S. LaBianca Key fingerprint = EAB0 63A2 716A A392 6DA6 FCBD C5E3 2C16 736A 7502 sub 1024g/A82006E2 2004-02-12 --erik From jdthood at yahoo.co.uk Thu Feb 12 19:20:47 2004 From: jdthood at yahoo.co.uk (=?iso-8859-1?q?J.D.=20Hood?=) Date: Thu, 12 Feb 2004 19:20:47 +0000 (GMT) Subject: [ANNOUNCE] apmd 3.2.1 Message-ID: <20040212192047.23119.qmail@web86106.mail.ukl.yahoo.com> In October 2002 Avery Pennarun, the current upstream maintainer of apmd, agreed that Debian maintainers should go ahead and modify the program in order to close certain bugs submitted by Debian users; after a period of testing we would submit the changes back upstream. The changes were duly made and the modified program has resided happily in Debian unstable and testing for several months; no problems have been reported. The tarball was recently cleaned up to prepare it for upstream release. You can download the new tarball, apmd_3.2.1.orig.tar.gz from a Debian mirror or from: ftp://ftp.debian.org/debian/pool/main/a/apmd/ The ChangeLog file has been updated to describe all the changes that have occurred since release 3.0.2. -- Thomas Hood ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From mark at harddata.com Thu Feb 12 19:45:32 2004 From: mark at harddata.com (Mark) Date: Thu, 12 Feb 2004 12:45:32 -0700 Subject: Yum and multiple arches. Message-ID: <200402121245.32521.mark@harddata.com> Okay, I noticed an issue with yum updating the only x86_64 depencies and not the i386 depencies as well when I updating to mozilla-1.6.0. It did however update both i386 and x86_64 versions of mozilla. I have yum setup this way. (edited for brevity) [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 exclude=*debuginfo* [development] name=Fedora Core $releasever - $basearch - Development Packages baseurl=ftp://workbot/fc1.devel-x86_64/x86_64/Fedora [development - x86] name=Fedora Core 2-test1 - i386 - development packages baseurl=ftp://ftp.telus.net/pub/fedora/linux/core/development/i386 I am assuming that this is an issue arising from yum not being written to handle multiple arches. -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From skvidal at phy.duke.edu Thu Feb 12 19:51:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 12 Feb 2004 14:51:35 -0500 Subject: Yum and multiple arches. In-Reply-To: <200402121245.32521.mark@harddata.com> References: <200402121245.32521.mark@harddata.com> Message-ID: <1076615495.18730.54.camel@opus> On Thu, 2004-02-12 at 14:45, Mark wrote: > Okay, > > I noticed an issue with yum updating the only x86_64 depencies and not the > i386 depencies as well when I updating to mozilla-1.6.0. It did however > update both i386 and x86_64 versions of mozilla. > > I have yum setup this way. (edited for brevity) > What version of yum are you using? 2.0.5 shouldn't have this issue. -sv From mark at harddata.com Thu Feb 12 20:10:39 2004 From: mark at harddata.com (Mark) Date: Thu, 12 Feb 2004 13:10:39 -0700 Subject: Yum and multiple arches. In-Reply-To: <1076615495.18730.54.camel@opus> References: <200402121245.32521.mark@harddata.com> <1076615495.18730.54.camel@opus> Message-ID: <200402121310.39377.mark@harddata.com> On February 12, 2004 12:51 pm, seth vidal wrote: > On Thu, 2004-02-12 at 14:45, Mark wrote: > > Okay, > > > > I noticed an issue with yum updating the only x86_64 depencies and not > > the i386 depencies as well when I updating to mozilla-1.6.0. It did > > however update both i386 and x86_64 versions of mozilla. > > > > I have yum setup this way. (edited for brevity) > > What version of yum are you using? > > 2.0.5 shouldn't have this issue. I am running yum-2.0.5-1 though I can't remember if I upgraded yum after though, so it probably works now. It took me a few days to figure out why mozilla stopped working. I know I didn't have too much trouble installing mplayer. The only issues I came across occurred if you have the x86_64 package already installed and some file conflicts. I don't know how yum would be able to work around this and repackaging lots of i386 libraries just for x86_64 would be a lot of work. regards, -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From buildsys at redhat.com Thu Feb 12 20:57:14 2004 From: buildsys at redhat.com (Build System) Date: Thu, 12 Feb 2004 15:57:14 -0500 Subject: rawhide report: 20040212 changes Message-ID: <200402122057.i1CKvEX15948@porkchop.devel.redhat.com> New package automake17 A GNU tool for automatically creating Makefiles. New package iptstate A top-like display of IP Tables state table entries New package redhat-java-rpm-scripts Helper scripts for Java rpms Updated Packages: MagicPoint-1.10a-6 ------------------ * Mon Feb 09 2004 Akira TAGOH 1.10a-6 - magicpoint-1.10a-fix-gcc-warnings2.patch: applied to fix gcc warnings (#115161) - magicpoint-1.10a-fix-ft2build.patch: applied to fix build error for freetype. - magicpoint-1.10a-fix-usleep.patch: applied to fix missing compile options. Omni-0.9.1-3 ------------ * Thu Feb 05 2004 Tim Waugh 0.9.1-3 - Fixed GCC 3.4 compilation. SDL-1.2.6-3.1 ------------- * Thu Feb 05 2004 Thomas Woerner 1.2.6-3.1 - disabled several video modes, hopefuilly fixes (#113831) SysVinit-2.85-17 ---------------- * Tue Feb 10 2004 Dan Walsh 2.85-17 - Check for current policy and previous depending on how policy was written * Thu Feb 05 2004 Jonathan Blandford 2.85-15 - rebuild w/o SELINUX for RHEL 3 U2 XFree86-4.3.0-45.0.2 -------------------- * Sat Jan 31 2004 Mike A. Harris 4.3.0-45.0.2 - Added XFree86-4.3.0-Xserver-dix-xkb-key-repeating-bug-CVS-backport.patch to fix a bug in DIX when xkb is being used that causes keys to repeat spuriously on some hardware under certain system loads. This patch has been backported from the 4.3.0-48 developmental head package. (#76959,114635) - Added XFree86-4.3.0-XRes-IncludeSharedObjectInNormalLib.patch to make libXRes get built PIC for bug (#114292) - Updated XFree86-4.3.0-missing-lib-sharedreqs.patch to remove dependancy on libXt caused by improper dependancy listing in SharedXmuuReqs (#113336) * Thu Jan 29 2004 Mike A. Harris 4.3.0-45.0.1.EL.test - Build test release for RHEL3 U2 testing anaconda-9.91-0.20040210144945 ------------------------------ * Tue Feb 10 2004 Anaconda team - built new version from CVS * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 apr-0.9.4-6 ----------- * Tue Feb 03 2004 Joe Orton 0.9.4-6 - define apr_off_t as int/long/... to prevent it changing with _FILE_OFFSET_BITS on 32-bit platforms * Mon Jan 12 2004 Joe Orton 0.9.4-5 - add apr_temp_dir_get fixes from HEAD * Thu Jan 08 2004 Joe Orton 0.9.4-4 - ensure that libapr is linked against libpthread - don't link libapr against -lnsl apr-util-0.9.4-7 ---------------- * Thu Feb 05 2004 Joe Orton 0.9.4-7 - fix warnings from use of apr_optional*.h with gcc 3.4 arts-1.2.0-0.3 -------------- * Thu Feb 05 2004 Than Ngo 1.2.0-0.3 - rebuilt against qt 3.3.0 * Tue Feb 03 2004 Than Ngo 8:1.2.0-0.1 - 3.2.0 release authconfig-4.6.1-1 ------------------ * Fri Feb 06 2004 Nalin Dahyabhai 4.6.1-1 - fix man page: --enableldapssl should be --enableldaptls - make --enableldapssl an alias for --enableldaptls bluez-libs-2.5-1 ---------------- * Tue Feb 10 2004 Karsten Hopp 2.5-1 - update to 2.5 bluez-utils-2.4-1 ----------------- * Mon Feb 09 2004 Karsten Hopp 2.4-1 - update to 2.4 - new -build patch - new -hciattach-initspeed patch - new -pinwait patch * Mon Feb 09 2004 Karsten Hopp 2.3-15 - fix updates. Last command run at update was /sbin/chkconfig --del bluetooth (Dag Wieers) boost-1.31.0-2 -------------- * Mon Feb 09 2004 Benjamin Kosnik 1.31.0-2 - Update to boost-1.31.0 * Thu Jan 22 2004 Benjamin Kosnik 1.31.0-1 - Update to boost-1.31.0.rc2 - (#109307: Compile Failure with boost libraries) - (#104831: Compile errors in apps using Boost.Python...) - Unify into boost, boost-devel rpms. - Simplify installation using bjam and prefix install. * Tue Sep 09 2003 Nalin Dahyabhai 1.30.2-2 - require boost-devel instead of devel in subpackages which require boost-devel - remove stray Prefix: tag cdrtools-2.01-0.a25.3 --------------------- * Thu Feb 05 2004 Harald Hoyer - 8:2.01-0.a25.3 - new iconv patch (10) cracklib-2.7-26 --------------- * Wed Feb 04 2004 Nalin Dahyabhai 2.7-26 - update URL (previous page moved) (#114894) * Fri Jan 30 2004 Nalin Dahyabhai 2.7-25 - fix ldconfig invocation in trigger for older versions which included the soname symlink (#114620) cups-1.1.20-3 ------------- * Thu Feb 05 2004 Tim Waugh 1:1.1.20-3 - Improved PIE patch. - Fixed compilation with GCC 3.4. * Thu Jan 29 2004 Tim Waugh - Don't ship cupsconfig now that nothing uses it. curl-7.10.8-1 ------------- * Sat Jan 31 2004 Florian La Roche - update to 7.10.8 - remove patch2, already upstream cyrus-imapd-2.2.3-2 ------------------- * Tue Feb 03 2004 Karsten Hopp - switch to Simon Matter's cyrus-imapd package, which has some major improvements over the old Red Hat package. - configdirectory moved from /var/imap to /var/lib/imap - sasl_pwcheck_method changed to saslauthd - needed to delete package/vendor tags for buildsystem. - added USEPIE variable for linking with -fpie flag - removed rpath from linker arguments - removed email header from README.HOWTO-recover-mailboxes - added lib64 patch - use CFLAGS from specfile in imtest subdir - disable -pie on ppc for now * Thu Jan 29 2004 Simon Matter - convert sieve scripts to UTF-8 only if sievec failed before - add note to the readme about limiting loggin on busy servers - added build time option to chose the syslog facility * Wed Jan 28 2004 Simon Matter - sieve scripts are now converted to UTF-8 with cvt_cyrusdb_all distcache-0.4.2-9 ----------------- * Sun Jan 25 2004 Joe Orton 0.4.2-9 - add BuildRequires (#114115) - add config lines to init scripts docbook-utils-0.6.14-1 ---------------------- * Wed Feb 11 2004 Tim Waugh 0.6.14-1 - 0.6.14. - All patches integrated. dvdrtools-0.1.4-4 ----------------- * Thu Feb 05 2004 Harald Hoyer - 0.1.4-4 - added ret.patch (113666) - put autoconf changes in patch99 * Wed Jun 04 2003 Elliot Lee - rebuilt * Mon May 26 2003 Harald Hoyer 0.1.4-1 - version 0.1.4 e2fsprogs-1.35-5.1 ------------------ * Thu Feb 05 2004 Thomas Woerner 1.35-5.1 - C++ header fix for ext2fs.h * Thu Feb 05 2004 Thomas Woerner 1.35-5 - newest WIP version (2004.01.31) ethereal-0.10.0a-3 ------------------ * Wed Feb 04 2004 Phil Knirsch 0.10.0a-3 - Added missing build requires on glib2-devel and gtk2-devel (#114565). fam-2.6.10-1 ------------ * Wed Feb 04 2004 Alexander Larsson 2.6.10-1 - update to 2.6.10 - fix manpage (#52864) - Don't link to libstdc++ (#111687) - Fix dnotify patch to fix a monitor leak (#106936) fedora-logos-1.1.21-1 --------------------- * Tue Feb 03 2004 Jonathan Blandford 1.1.21-1 - add rhgb logo fetchmail-6.2.0-9 ----------------- * Mon Feb 02 2004 Nalin Dahyabhai 6.2.0-9 - add patch to ensure that stuffed warnings always end in cr-lf (#114470) * Tue Nov 25 2003 Nalin Dahyabhai - blah, merge multiple patches for krb5-config things into one * Fri Nov 14 2003 Nalin Dahyabhai - fix gssapi support authenticating to imap, even when connected to pop foomatic-3.0.0-23 ----------------- * Mon Feb 09 2004 Tim Waugh 3.0.0-23 - Fix up HP Color Inkjet CP1700 support. - Remove PrintoutMode option from gimp-print driver to avoid breaking it. - Update filters to 3.0.1rc3. - Update engine to 3.0.1rc2 - No long need symlink patch. freeradius-0.9.3-2.1 -------------------- * Thu Feb 05 2004 Thomas Woerner 0.9.3-2.1 - using -fPIC instead of -fpic for s390 ans s390x * Thu Feb 05 2004 Thomas Woerner 0.9.3-2 - radiusd is pie, now * Tue Nov 25 2003 Thomas Woerner 0.9.3-1 - new version 0.9.3 (bugfix release) gd-2.0.21-1 ----------- * Mon Feb 02 2004 Phil Knirsch 2.0.21-1 - Updated to 2.0.21 * Tue Aug 12 2003 Florian La Roche - update to 2.0.15 * Wed Jun 04 2003 Elliot Lee - rebuilt gdm-2.4.4.5-9 ------------- * Tue Feb 03 2004 Warren Togami 1:2.4.4.5-9 - add two lines to match upstream CVS to xdmcp_sessions.patch Fully resolves #110315 and #113154 * Sun Feb 01 2004 Warren Togami 1:2.4.4.5-8 - patch30 xdmcp_session counter fix from gdm-2.5.90.0 #110315 - automake14 really needed, not automake - BR libcroco-devel, libcroco-devel, libattr-devel, gettext - conditionally BR libselinux-devel - explicit epoch in all deps - make the ja.po time format change with a sed expression rather than overwriting the whole file (Petersen #113995) gedit-2.5.3-3 ------------- * Wed Feb 11 2004 Dan Williams 1:2.5.3-3 - Correctly convert last path from open/save into a directory for storing in gconf, not a file * Fri Feb 06 2004 Dan Williams 1:2.5.3-2 - Bring file selector size/last path patch up to 2.5.3 - Fix up the recent-files locking algorithm to have finer resolution timeouts gettext-0.14.1-1 ---------------- * Mon Feb 02 2004 Leon Ho - rebuilt to 0.14.1 ghostscript-7.07-20 ------------------- * Thu Feb 05 2004 Tim Waugh 7.07-20 - Fix compilation with GCC 3.4. gimp-2.0-0.pre3.2 ----------------- * Sun Feb 08 2004 Nils Philippsen - require gtk2, glib2 >= 2.3.0, pango >= 1.3.0 * Fri Feb 06 2004 Nils Philippsen - version 2.0pre3 - update buildroot patch - enable building static libs (old default) - have '--define'able enable_* - disable building of print plugin, it's in another package * Fri Jan 30 2004 Nils Philippsen - rebuild against new libcroco gimp-print-4.2.6-5 ------------------ * Thu Feb 12 2004 Tim Waugh 4.2.6-5 - Build for Fedora development. * Sun Feb 01 2004 Tim Waugh 4.2.6-4 - Build for Fedora Core 1 update. - Fix for C8x paper alignment (bug #114698). * Sat Jan 24 2004 Nils Philippsen 4.2.6-3 - build against gimp2 - buildrequire gimp's epoch as well glibc-2.3.3-8 ------------- * Tue Feb 10 2004 Jakub Jelinek 2.3.3-8 - update from CVS gnome-panel-2.5.3.1-3 --------------------- * Fri Feb 06 2004 Dan Williams 2.5.3.1-3 - Add in file locking retries for egg-recent-model stuff, as with gedit. Makes gnome-panel and other apps like gedit not fight for recent files list on NFS home directories gnome-vfs2-2.4.1-1 ------------------ * Wed Oct 15 2003 Alexander Larsson 2.4.1-1 - Update to 2.4.1, fixes bug #107130 * Tue Sep 09 2003 Alexander Larsson 2.4.0-1 - update to 2.4.0 * Tue Sep 02 2003 Alexander Larsson 2.3.90-1 - update to 2.3.90 gnumeric-1.2.6-2 ---------------- * Fri Feb 06 2004 Daniel Reed 1:1.2.6-1 - Version bump (1.2.6) * Tue Oct 14 2003 Jonathan Blandford 1:1.2.1-2 - add ssconvert groff-1.18.1-30 --------------- * Mon Feb 09 2004 Adrian Havill - provide I18N version of nroff that accepts --legacy parameter (used by man-1.5m2-2) * Thu Dec 18 2003 Thomas Woerner - fixed missing BuildRequires (#110574) gstreamer-0.7.3-4 ----------------- * Wed Feb 04 2004 Bill Nottingham 0.7.3-4 - fix %post * Wed Jan 28 2004 Alexander Larsson 0.7.3-3 - add s390 patch * Tue Jan 27 2004 Jonathan Blandford 0.7.3-1 - new version hicolor-icon-theme-0.3-1 ------------------------ * Wed Feb 04 2004 Alexander Larsson 0.3-1 - update to 0.3 hpijs-1.5-6 ----------- * Thu Feb 05 2004 Tim Waugh 1.5-6 - Fixed compilation with GCC 3.4. httpd-2.0.48-14 --------------- * Tue Feb 03 2004 Joe Orton 2.0.48-14 - mod_dav: fix 401 on destination and reject unescaped fragment in URI - remove redundant ldconfig invocation from mod_ssl %post - remove unnecessary -headusage patch * Fri Jan 30 2004 Joe Orton 2.0.48-13 - allow further customisation of init script (Peter Bieringer, #114619) - worker fixes from upstream - use basename(filename) in APLOG_MARK to reduce noise levels at "LogLevel debug" * Wed Jan 28 2004 Joe Orton 2.0.48-12 - mod_ssl: cosmetic tweaks for pass phrase prompting - simplify rebranding a little im-sdk-11.4-9 ------------- * Tue Feb 10 2004 Yu Shao r11.4-9 - #115217, gnonme-im-switcher-applet doesn't start bug * Fri Feb 06 2004 Yu Shao r11.4-8 - more bug fixes, gtk crashing #112290, library inclusion #113925 * Thu Feb 05 2004 Yu Shao r11.4-7 - more bug fixes, canna requirement and initscript kakasi-2.3.4-15 --------------- * Tue Feb 03 2004 Akira TAGOH 2.3.4-15 - kakasi-2.3.4-fix-bad-source.patch: applied to fix gcc warning. (#114744) kernel-2.6.2-1.74 ----------------- * Tue Feb 10 2004 Dave Jones - update to 2.6.3-rc2 * Sun Feb 08 2004 Dave Jones - Update to 2.6.3-rc1-bk1 - Disable ipfwadm/ipchains compatability. It's time to move on. * Fri Feb 06 2004 Dave Jones - Update to 2.6.2-bk2 kinput2-v3.1-14 --------------- * Thu Feb 12 2004 Akira TAGOH v3.1-14 - kinput2-v3.1-fix-gcc-warning.patch: applied to fix gcc warning. (#114750) krb5-1.3.1-10 ------------- * Mon Feb 09 2004 Nalin Dahyabhai 1.3.1-10 - catch krb4 send_to_kdc cases in kdc preference patch * Mon Feb 02 2004 Nalin Dahyabhai 1.3.1-9 - remove patch to set TERM in klogind which, combined with the upstream fix in 1.3.1, actually produces the bug now (#114762) * Mon Jan 19 2004 Nalin Dahyabhai 1.3.1-8 - when iterating over lists of interfaces which are "up" from getifaddrs(), skip over those which have no address (#113347) kudzu-1.1.44-1 -------------- * Wed Feb 11 2004 Bill Nottingham 1.1.44-1 - new and improved PS/2 probe - requires a 2.6 kernel libgnomecups-0.1.6-4 -------------------- * Thu Feb 05 2004 Dan Williams 0.1.6-4 - Augment NVR to differentiate Fedora Core/RHEL * Thu Jan 22 2004 Dan Williams 0.1.6-3 - Bump for rebuild into Fedora Core 2 * Wed Dec 03 2003 Dan Williams - Initial Red Hat RPM release. libtool-1.5.2-1 --------------- * Mon Jan 26 2004 Jens Petersen - 1.5.2-1 - update to 1.5.2 bugfix release - update libtool-1.5-libtool.m4-x86_64.patch - nolonger need libtool-1.5-mktemp.patch, libtool-1.5-expsym-linux.patch, libtool-1.5-readonlysym.patch, libtool-1.5-relink-libdir-order-91110.patch, libtool-1.5-AC_PROG_LD_GNU-quote-v-97608.patch and libtool-1.5-nostdlib.patch libunwind-0.96-1 ---------------- * Thu Jan 29 2004 Jeff Johnston 0.96.1 - Import version 0.96. libusb-0.1.8-1 -------------- * Wed Feb 11 2004 Tim Waugh 0.1.8-1 - 0.1.8. lm_sensors-2.8.3-3 ------------------ * Thu Feb 05 2004 Phil Knirsch 2.8.3-3 - Modified sensors.conf to a noreplace config file. * Wed Feb 04 2004 Phil Knirsch 2.8.3-2 - Fixed newly included initscript (#114608). man-1.5m2-2 ----------- * Mon Feb 09 2004 Adrian Havill 1.5m2-2 - add all locale man pages - convert all msgs and manpages to utf-8 - downconvert via transliteration C locale man pages just in case - patch #3, #8, #10, #17, #29, #31 no longer needed-- made it upstream - patch #9, #14 and #19 now superfluous-- strs already termed and len checked - disable patch #22: defer cat creation to existence of dir, not conf directive - patch #32 mostly merged upstream. Keep the "-a" in grep though so all locales' grep see man pages as text not binary (patch 37) - iconv patch no longer needed now that utf-8-to-legacy conversion is not needed - patch #52 and #53 not needed: CJK all point to nroff instead of groff, let the nroff script decide, based on the charset of the environment and/or the charset of the man page, as to what parameters to pass to groff (and whether iconv preprocessing is necessary) - the string "NROFF_OLD_CHARSET", if present in the man.config for the NROFF path, will now be replaced by the old character set so that nroff can figure out what the character set/encoding is - fix man to reflect status codes returned by forked child processes (#115204) - lots of makewhatis changes: re-add custom rh client stuff (/usr/bin vs /usr/sbin), -o option, /var/cache/man, utf-8 verification, convert the encoding spaghetti in the makewhatis awk script to UTF-8, identify languages in comments * 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) * 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 man-pages-1.66-1 ---------------- * Wed Feb 11 2004 Adrian Havill 1.66-1 - update to 1.66 - add posix section processing for sections 0p, 1p, 3p (#114584) * Mon Dec 15 2003 Adrian Havill 1.64-2 - update to 1.64 - convert iso-8859-1 en locale pages to UTF-8 for fc2 (#108991) * Wed Sep 24 2003 Adrian Havill 1.60-4.1 - bump n-v-r man-pages-cs-0.16-2 ------------------- * Tue Feb 10 2004 Akira TAGOH 0.16-2 - removed man.1 because the latest man contains it. man-pages-de-0.4-7 ------------------ * Tue Feb 10 2004 Akira TAGOH 0.4-7 - removed apropos.1, man.1, whatis.1, and man.config.5, because the latest man contains those manpages. man-pages-fr-0.9.7-9 -------------------- * Tue Feb 10 2004 Akira TAGOH 0.9.7-9 - removed apropos.1, man.1, whatis.1, and man.config.5, because the latest man contains those manpages. man-pages-it-0.3.0-13 --------------------- * Tue Feb 10 2004 Akira TAGOH 0.3.0-13 - removed apropos.1, man.1, whatis.1, man.config.5, and makewhatis.8, because the latest man contains those manpages. man-pages-ja-20040115-2 ----------------------- * Tue Feb 10 2004 Akira TAGOH 20040115-2 - removed apropos.1, man.1, and whatis.1. the latest man contains those manpages now. man-pages-ko-1.48-11 -------------------- * Tue Feb 10 2004 Akira TAGOH 1.48-11 - removed man.1 and man.config.5, because the latest man contains those manpages. man-pages-pl-0.22-14 -------------------- * Tue Feb 10 2004 Akira TAGOH 0.22-14 - removed apropos.1, man.1, whatis.1, and man.config.5, because the latest man contains those manpages. mkinitrd-3.5.19-1 ----------------- * Mon Feb 09 2004 Jeremy Katz - 3.5.19-1 - nash/mkinitrd: quiet mode for nash and necessary mkinitrd changes to work with it - mkinitrd: add lxo's patch for copying lvm.conf (#112099) - new-kernel-pkg: allow specifying the banner used in the boot loader config on the command line (#114809) * Tue Jan 13 2004 Jeremy Katz - mkinitrd: add patch from Alex Kiernan for modules with multiple deps in 2.6 (#113306) mod_perl-1.99_11-4 ------------------ * Fri Feb 06 2004 Joe Orton 1.99_11-4 - rebuild to pick up libdb-4.2 mod_python-3.0.4-1 ------------------ * Tue Feb 03 2004 Gary Benson 3.0.4-1 - upgrade to 3.0.4 (fixes CVE CAN-2003-0973) mtr-0.54-2 ---------- * Wed Feb 04 2004 Phil Knirsch 0.54-2 - Fix to build on current tree. mutt-1.4.1-5 ------------ * Tue Jan 27 2004 Bill Nottingham 5:1.4.1-5 - add patch to fix menu padding (CAN-2004-0078, #109317) ncpfs-2.2.3-3 ------------- * Mon Feb 02 2004 Karsten Hopp 2.2.3-3 - fix array usage (#110897) ncurses-5.4-1 ------------- * Tue Feb 10 2004 Adrian Havill 5.4-1 - version update to 5.4 neon-0.24.4-1 ------------- * Mon Feb 09 2004 Joe Orton 0.24.4-1 - update to 0.24.4 net-snmp-5.1-9 -------------- * Tue Feb 03 2004 Phil Knirsch 5.1-9 - Reverted removal of _includir redefiniton due to php-snmp dependancy. - Remove SO_BSDCOMPAT setsockopt() call, deprecated. netpbm-10.19-4 -------------- * Tue Feb 10 2004 Phil Knirsch 10.19-4 - Fixed several tmp vulnerabilities in scripts and apps. Based on Debian security fix for netpbm-9.24. * Mon Feb 09 2004 Phil Knirsch 10.19-3 - Included doc tarball with manpages (#114755). - Fixed small manpage incorrectness (#84922). - Fixed message from giftopnm (#114756). nvi-m17n-1.79-20011024.17 ------------------------- * Mon Feb 09 2004 Akira TAGOH 1.79-20011024.17 - nvi-1.79-fix-gcc-warnings.patch: applied to fix gcc warnings. (#115194) openjade-1.3.2-10 ----------------- * Sat Jan 31 2004 Tim Waugh 1.3.2-10 - More C++ fixes (for GCC 3.4). openldap-2.1.25-4 ----------------- * Tue Feb 10 2004 Nalin Dahyabhai 2.1.25-4 - remove 'reload' from the init script -- it never worked as intended (#115310) * Wed Feb 04 2004 Nalin Dahyabhai 2.1.25-3 - commit that last fix correctly this time * Tue Feb 03 2004 Nalin Dahyabhai 2.1.25-2 - fix incorrect use of find when attempting to detect a common permissions error in the init script (#114866) openoffice.org-1.1.0-27 ----------------------- * Mon Feb 09 2004 Dan Williams 1.1.0-27 - Don't install spadmin .desktop file since spadmin isn't shipped - Remove some python cruft - Don't use blocking lockf() when locking ~/.recently-used * Wed Feb 04 2004 Dan Williams 1.1.0-26 - Add libgnomecups to BuildRequires * Mon Feb 02 2004 Dan Williams 1.1.0-25 - Fix up font locations and use correct opensymbol font pam-0.77-33 ----------- * Tue Feb 10 2004 Dan Walsh 0.77-33 - close and reopen terminal after changing context. * Thu Feb 05 2004 Dan Walsh 0.77-32 - Check for valid tty * Tue Feb 03 2004 Dan Walsh 0.77-31 - Check for multiple > 1 passwd-0.68-8 ------------- * Wed Feb 04 2004 Dan Walsh 0.68-8 - add check for enforcing mode pcmcia-cs-3.2.7-1.4 ------------------- * Wed Feb 11 2004 Bill Nottingham - don't build on s390* * Wed Jan 28 2004 Arjan van de Ven - merge mgalgoci's cleanups * Mon Dec 02 2002 Bill Nottingham 3.1.31-11 - fix exclusion of /etc/pcmcia/config policy-1.4.14-1 --------------- * Tue Feb 10 2004 Dan Walsh 1.4.14-1 - Latest from Russell * Tue Feb 10 2004 Dan Walsh 1.4.13-6 - Fix build and include policy sources only in policy-sources * Tue Feb 10 2004 Dan Walsh 1.4.13-4 - Build file_contexts/file_contexts privoxy-3.0.3-2 --------------- * Sun Feb 01 2004 Karsten Hopp 3.0.3-2 - build for Fedora Core 2 * Sat Jan 31 2004 Karsten Hopp 3.0.3-0.9 - build for upstream procps-3.1.15-4 --------------- pyxf86config-0.3.14-1 --------------------- * Mon Feb 09 2004 Alexander Larsson 0.3.14-1 - fix range array bug qt-3.3.0-0.2 ------------ * Thu Feb 05 2004 Than Ngo 1:3.3.0-0.2 - fix fontdatabase - don't use strip in install script - fix qt default setting * Wed Feb 04 2004 Than Ngo 1:3.3.0-0.1 - 3.3.0 * Fri Jan 30 2004 Than Ngo 1:3.2.3-0.4 - add mouse patch from CVS, bug #114647 rcs-5.7-23 ---------- * Wed Feb 04 2004 Phil Knirsch 5.7-23 - Switched copyright to license. :-) * Fri Oct 31 2003 Phil Knirsch 5.7-22 - Included sameuserlocks patch from James Olin Oden (#107947). rdesktop-1.3.1-1 ---------------- * Wed Feb 11 2004 Warren Togami 1.3.1-1 - upgrade to 1.3.1 rhgb-0.11.2-3 ------------- * Thu Feb 05 2004 Dan Walsh 0.11.2-3 - Remove extra umount. Fixes SELinux error * Tue Feb 03 2004 Jonathan Blandford 0.11.2-2 - remove logo temporarily for RHEL. rhnlib-1.5-1 ------------ * Tue Feb 10 2004 Mihai Ibanescu 1.5-1 - Fixed #115318 rpm-4.3-0.10 ------------ * Wed Feb 11 2004 Jeff Johnson 4.3-0.10 - re-add --enable-posixmutexes to build. * Mon Jan 19 2004 Jeff Johnson 4.3-0.9 - python: return None for NEVRAO, [] for everything else. * Mon Jan 12 2004 Jeff Johnson 4.3-0.7 - fix: handle files w/o contexts correctly. rsh-0.17-20 ----------- * Thu Feb 05 2004 Thomas Woerner 0.17-20 - in.rexecd, in.rlogind and in.rshd are pie, now ruby-1.8.1-1 ------------ * Wed Feb 04 2004 Akira TAGOH 1.8.1-1 - New upstream release. - don't use any optimization for ia64 to avoid the build failure. - ruby-1.8.1-ia64-stack-limit.patch: applied to fix SystemStackError when the optimization is disabled. samba-3.0.2-5 ------------- * Mon Feb 09 2004 Jay Fenlason 3.0.2-5 - New upstream version: 3.0.2 final includes security fix for #114995 (CAN-2004-0082) - Edit postun script for the -common package to restart winbind when appropriate. Fixes bugzilla #114051. * Mon Feb 02 2004 Jay Fenlason 3.0.2-3rc2 - add %dir entries for /usr/lib64/samba and /usr/lib64/samba/charset - Upgrade to new upstream version - build mount.cifs for the new cifs filesystem in the 2.6 kernel. sane-backends-1.0.13-4 ---------------------- * Thu Feb 05 2004 Tim Waugh 1.0.13-4 - Fixed compilation with GCC 3.4. setools-1.2.1-1 --------------- * Fri Feb 06 2004 Dan Walsh 1.2.1-1 - New patch * Fri Feb 06 2004 Dan Walsh 1.2-1 - Latest upstream version sip-3.10-2 ---------- * Wed Feb 11 2004 Than Ngo 3.10-2 - rebuilt against qt 3.3.0 * Wed Feb 04 2004 Than Ngo 3.10-1 - 3.10 sound-juicer-0.5.10.1-1 ----------------------- * Thu Feb 05 2004 Brent Fox 0.5.10.1-1 - new version switchdesk-4.0.1-1 ------------------ * Tue Feb 03 2004 Than Ngo 4.0.1-1 - 4.0.1 release * Sun Feb 01 2004 Than Ngo 4.0.0-1 - 4.0.0 release - fixed #40226, #71711, #71990, #72744, #75751, #78603, #81801, #84043, #85077, #89347, #105880, #108582, #109683, #110312, #114190 - Thu Jun 26 2003 Than Ngo 3.9.8-18 - build with gcc-3.3-12 - fix desktop file issue - cleanup specfile - disable debuginfo * Wed Jun 04 2003 Elliot Lee - rebuilt sysreport-1.3.8-1 ----------------- * Wed Feb 11 2004 Than Ngo 1.3.8-1 - 1.3.8 * Wed Feb 11 2004 Than Ngo 1.3.7.1-1 - sysreport hangs with dmidecode, #115362 * Mon Sep 08 2003 Than Ngo 1.3.7-1 - modify sysreport to include information on cluster setup for AS2.1/Taroon system-config-date-1.7.1-2 -------------------------- * Tue Feb 03 2004 Brent Fox 1.7.1-2 - correct typo in URL in specfile system-config-display-1.0.5-1 ----------------------------- * Fri Jan 30 2004 Brent Fox 1.0.5-1 - correct naming in the spec file description system-config-nfs-1.2.2-2 ------------------------- * Mon Feb 09 2004 Brent Fox 1.2.2-2 - add entry for /usr/bin/nfs-export - add mnemonic to toolbar buttons * Mon Feb 09 2004 Brent Fox 1.2.2-1 - add command line interface system-config-printer-0.6.93-1 ------------------------------ * Fri Feb 06 2004 Tim Waugh 0.6.93-1 - 0.6.93: - Enable F12 in the text interface (bug #113732). - Fix the rest of bug #109942, and bug #115062. * Thu Feb 05 2004 Tim Waugh - Make gui package obsolete the correct thing (bug #114981). * Tue Feb 03 2004 Tim Waugh 0.6.92-1 - 0.6.92: - Another 'single IP address' bug fix (bug #114414). system-config-securitylevel-1.3.2-1 ----------------------------------- * Tue Feb 03 2004 Brent Fox 1.3.2-1 - F12 functionality fixed system-config-services-0.8.6-3 ------------------------------ * Tue Jan 06 2004 Daniel J Walsh 0.8.6-3 - Fix console app so it launches properly system-config-users-1.2.9-1 --------------------------- * Tue Feb 03 2004 Brent Fox 1.2.9-1 - remove comparison to gtk.TRUE (bug #114266) talk-0.17-22 ------------ * Wed Feb 04 2004 Phil Knirsch 0.17-22 - Fixed copyright to license. - Fixed description for main package (#114683). tcl-8.4.5-4 ----------- * Mon Feb 02 2004 Jens Petersen - 8.4.5-4 - include all private .h files under /usr/include/tcl-private tcsh-6.12-7 ----------- * Tue Feb 10 2004 Nalin Dahyabhai 6.12-7 - remove declaration of setpgrp() which conflicts with libc's (#115185) telnet-0.17-27 -------------- * Thu Feb 05 2004 Harald Hoyer - 1:0.17-27 - added PIE compile flags tetex-2.0.2-11 -------------- * Fri Jan 30 2004 Tim Waugh 2.0.2-11 - Updated LaTeX2HTML Japanese patch (bug #114630). - Updated pTeX to 3.1.3 (bug #114630). tree-1.4b3-2 ------------ * Thu Feb 05 2004 Tim Waugh 1.4b3-2 - Fixed compilation with GCC 3.4. ttfonts-ja-1.2-32 ----------------- * Thu Feb 05 2004 Akira TAGOH 1.2-32 - removed default*.font because it's no longer used. ttfonts-ko-1.0.11-32 -------------------- * Thu Feb 05 2004 Akira TAGOH 1.0.11-32 - removed default*.font because it's no longer used. - fixed %post and %postun to check real writable for nfs mount. * Wed Jul 09 2003 David Joo 1.0.11-30 -rebuilt for RHEL ttfonts-zh_CN-2.14-2 -------------------- * Thu Feb 05 2004 Akira TAGOH 2.14-2 - removed default*.font because it's no longer used. ttfonts-zh_TW-2.11-24 --------------------- * Thu Feb 05 2004 Akira TAGOH 2.11-24 - removed default*.font because it's no longer used. - fixed %post and %postun to check real writable for nfs mount. * Tue Jul 08 2003 Leon Ho - rebuilt udev-016-1 ---------- * Thu Feb 05 2004 Harald Hoyer - - version 016 - fixed initscript - customized udev.rules and permissions - fixed klibc build vim-6.2.253-1 ------------- * Wed Feb 11 2004 Karsten Hopp 6.2.253-1 - patchlevel 253 - disable netbeans vixie-cron-3.0.1-86 ------------------- * Wed Feb 04 2004 Dan Walsh - 3.0.1-86 - Add security_getenforce check. w3m-0.4.1-10 ------------ * Tue Feb 10 2004 Akira TAGOH 0.4.1-10 - gc6.2alpha5-ppc64.patch: removed because no need to apply. - gc6.2.tar.gz: update to the stable version. - gc6.2-fix-prelink.patch: applied to fix prelink issue. (#115201: Jakub Jelinek) xemacs-sumo-20040202-1 ---------------------- * Wed Feb 04 2004 Jens Petersen - 20040202-1 - update to 2004-02-02 sumos - update browse-url-htmlview-84262.patch - subtract 100 from all patch numbers xinetd-2.3.13-1 --------------- * Thu Jan 29 2004 Jay Fenlason 2.3.13-1 - Upgrade to new upstream version, which obsoletes most patches. - Add new tcp_rpc patch, to turn on the nolibwrap flag on tcp rpc services, since libwrap cannot be used on them. xmlsec1-1.2.4-1 --------------- * Wed Feb 11 2004 Daniel Veillard 1.2.4-1 - updated with upstream release from Aleksey xsane-0.92-4 ------------ * Sun Jan 25 2004 Tim Waugh 0.92-4 - Gimp patch updated. * Fri Jan 23 2004 Tim Waugh 0.92-3 - Translations are broken -- turn them off for the time being. - Really apply the patch this time. - Fix up post/postun scriptlets. * Fri Jan 23 2004 Tim Waugh 0.92-2 - Apply patch for building against new gimp. From devscott at charter.net Thu Feb 12 22:34:26 2004 From: devscott at charter.net (Scott Sloan) Date: Thu, 12 Feb 2004 16:34:26 -0600 Subject: FC1 and FC2 compatibility Message-ID: <1076625266.7101.3.camel@ssloan> Is there any compatibility issues with using rpms for FC1 on FC2? From mark at mark.mielke.cc Fri Feb 13 06:13:51 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 13 Feb 2004 01:13:51 -0500 Subject: ncurses now mono-only (ncurses-5.4-1)? Message-ID: <20040213061351.GA2321@mark.mielke.cc> Just a heads up... mutt now comes up in two colours since I upgraded to ncurses on fedora-devel-latest... No time for me to investigate right now... 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 twaugh at redhat.com Fri Feb 13 09:51:42 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 13 Feb 2004 09:51:42 +0000 Subject: FC1 and FC2 compatibility In-Reply-To: <1076625266.7101.3.camel@ssloan> References: <1076625266.7101.3.camel@ssloan> Message-ID: <20040213095142.GA25654@redhat.com> On Thu, Feb 12, 2004 at 04:34:26PM -0600, Scott Sloan wrote: > Is there any compatibility issues with using rpms for FC1 on FC2? In other words, reasons that an RPM built on one will not work on another? There will be at least these: o Different Python version (and module ABI) means that packages providing extension modules will be providing modules that do not work with the running Python. In turn, any packages that want to use those extension modules will not be able to. o The libdb library has changed soname, and so anything that uses it will require the version it was built against. o So has libdbus, but there are far fewer things using that. o GIMP has been upgraded, and I think the plug-in ABI may have changed incompatibly. Packages providing GIMP plug-ins will be affected. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zboszor at freemail.hu Fri Feb 13 12:21:44 2004 From: zboszor at freemail.hu (Boszormenyi Zoltan) Date: Fri, 13 Feb 2004 13:21:44 +0100 Subject: cdrdao-1.1.8 released Message-ID: <402CC158.1000403@freemail.hu> Hi, cdrdao-1.1.8 has just been released. It would be nice to have it in FC2 since it can write CDs without the ide-scsi emulation. -- Best regards, Zolt?n B?sz?rm?nyi --------------------- What did Hussein say about his knife? One in Bush worth two in the hand. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 13 12:27:50 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 13 Feb 2004 13:27:50 +0100 Subject: FC1 and FC2 compatibility In-Reply-To: <20040213095142.GA25654@redhat.com> References: <1076625266.7101.3.camel@ssloan> <20040213095142.GA25654@redhat.com> Message-ID: <20040213132750.1b95294c@localhost> Tim Waugh wrote : > On Thu, Feb 12, 2004 at 04:34:26PM -0600, Scott Sloan wrote: > > > Is there any compatibility issues with using rpms for FC1 on FC2? > > In other words, reasons that an RPM built on one will not work on > another? There will be at least these: > > o Different Python version (and module ABI) means that packages > providing extension modules will be providing modules that do not > work with the running Python. In turn, any packages that want to > use those extension modules will not be able to. > > o The libdb library has changed soname, and so anything that uses it > will require the version it was built against. > > o So has libdbus, but there are far fewer things using that. > > o GIMP has been upgraded, and I think the plug-in ABI may have changed > incompatibly. Packages providing GIMP plug-ins will be affected. I see at least another major change : o New rpm 4.3 vs. 4.2 with new soname, so applications like apt which are linked against librpm need to be recompiled. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.1-1.65 Load : 0.32 0.22 0.24 From buildsys at redhat.com Fri Feb 13 12:33:38 2004 From: buildsys at redhat.com (Build System) Date: Fri, 13 Feb 2004 07:33:38 -0500 Subject: rawhide report: 20040213 changes Message-ID: <200402131233.i1DCXc904836@porkchop.devel.redhat.com> New package rpmdb-fedora The entire rpm database for the Red Hat Linux distribution. New package xerces-j The Xerces XML parser Updated Packages: PyQt-3.10-3 ----------- * Thu Feb 12 2004 Than Ngo 3.10-3 - add some patch files from CVS, which supports Qt 3.3.0 * Thu Feb 12 2004 Than Ngo 3.10-2 - use new methode of building SIP * Wed Feb 11 2004 Than Ngo 3.10-1 - 3.10 release - build against qt 3.3.0 anaconda-9.91-0.20040212195024 ------------------------------ * Thu Feb 12 2004 Anaconda team - built new version from CVS * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 dbus-0.20-2 ----------- * Wed Feb 11 2004 Havoc Pennington 0.20-2 - rebuild in fc2, cups now updated * Wed Jan 07 2004 Bill Nottingham 0.20-1 - update to upstream 0.20 eel2-2.5.7-1 ------------ * Fri Feb 13 2004 Alexander Larsson 2.5.7-1 - update to 2.5.7 ghostscript-7.07-21 ------------------- * Thu Feb 12 2004 Tim Waugh 7.07-21 - Leave gdevpdfm.c seemingly-mistaken bitwise ops alone (bug #115396). gnome-vfs2-2.5.7-1 ------------------ * Fri Feb 13 2004 Alexander Larsson 2.5.7-1 - update to 2.5.7 * Mon Feb 09 2004 Alexander Larsson 2.5.6-4 - build-req fam-devel and openssl-devel (#111109) - Own libdir/gnome-vfs-2.0/include (#113045) * Fri Feb 06 2004 Alexander Larsson 2.5.6-3 - Clean up the patch list - Fix the network: issue - Remove core file from tarball grub-0.94-1 ----------- * Thu Feb 12 2004 Jeremy Katz 0.94-1 - update to 0.94, patch merging and updating as necessary gtkam-0.1.10-1 -------------- * Thu Feb 12 2004 Tim Waugh 0.1.10-1 - 0.1.10. kdelibs-3.2.0-0.4 ----------------- * Mon Feb 09 2004 Than Ngo 6:3.2.0-0.4 - add new icon patch file * Thu Feb 05 2004 Than Ngo 6:3.2.0-0.3 - build against qt 3.3.0 - fix a bug in ksslopen on x86_64, bug #114835 * Tue Feb 03 2004 Than Ngo 6:3.2.0-0.2 - 3.2.0 release libxml2-2.6.6-1 --------------- * Thu Feb 12 2004 Daniel Veillard - upstream release 2.6.6 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems nautilus-2.5.7-1 ---------------- * Fri Feb 13 2004 Alexander Larsson 2.5.7-1 - update to 2.5.7 * Fri Jan 30 2004 Alexander Larsson 2.5.6-1 - update to 2.5.6 * Tue Jan 27 2004 Alexander Larsson 2.5.5-1 - update to 2.5.5 nautilus-cd-burner-0.6.5-1 -------------------------- * Fri Feb 13 2004 Alexander Larsson 0.6.5-1 - update to 0.6.5 nfs-utils-1.0.6-5 ----------------- * Thu Feb 12 2004 Thomas Woerner - make rpc.lockd, rpc.statd, rpc.mountd and rpc.nfsd pie * Wed Jan 28 2004 Steve Dickson - Added the NFSv4 bits * Mon Dec 29 2003 Steve Dickson - Added the -z flag to nfsstat policy-1.4.14-6 --------------- * Tue Feb 10 2004 Dan Walsh 1.4.14-6 - add privoxy and canna back in * Tue Feb 10 2004 Dan Walsh 1.4.14-5 - Merge in latest changes from NSA - Add requirement so sources pulls policy - fix epoch - More rules for nfs homedirs and mozilla * Tue Feb 10 2004 Dan Walsh 1.4.14-2 - Add support for nfs homedirs and automount portmap-4.0-58 -------------- * Thu Feb 12 2004 Thomas Woerner 4.0-58 - added PIE patch from Ulrich Drepper * Tue Sep 23 2003 Florian La Roche - allow to compile without tcp_wrappers pwlib-1.4.7-4.1 --------------- * Tue Jan 27 2004 Alexander Larsson 1.4.7-4.1 - Fix some range checks in asn parser * Wed Jan 22 2003 Tim Powers - rebuilt * Wed Jan 08 2003 Alexander Larsson 1.4.7-3 - pwlib-1.4.7-noipv6.patch: Disable ipv6 check, damien claims it's unstable. pygtk2-2.0.0-3 -------------- * Thu Feb 12 2004 Jeremy Katz - 2.0.0-3 - own %{_libdir}/python?.?/site-packages/gtk-2.0/gtk dir (#113048) sip-3.10-3 ---------- * Thu Feb 12 2004 Than Ngo 3.10-3 - use new method of building SIP spamassassin-2.63-6 ------------------- * Wed Feb 11 2004 Warren Togami 2.63-6 - require sitelib instead * Wed Jan 21 2004 Warren Togami 2.63-3 - krb5-backcompat.patch so older krb5-devel does not fail * Wed Jan 21 2004 Warren Togami 2.63-2 - upgrade to 2.63 sylpheed-0.9.9-1 ---------------- * Fri Feb 13 2004 Akira TAGOH 0.9.9-1 - New upstream release. ttmkfdir-3.0.9-8 ---------------- * Thu Feb 12 2004 Yu Shao 3.0.9-8 - patch for building package against freetype-2.1.7 - from kanagawa jigorou (jigorou3 at mail.goo.ne.jp) #114682 From mail.sw.rh.rhl.devel at spam.fi.basen.net Fri Feb 13 12:48:41 2004 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J. Niemi) Date: Fri, 13 Feb 2004 14:48:41 +0200 Subject: include php-imap in FC2 (bug #115535) Message-ID: <200402131248.i1DCmfmA005990@d103.fi.basen.net> Hi, I'm advocating that php-imap, which was removed from Rawhide in php-4.3.4-4, should be reintroduced before the release of FC2. I noticed it was missing while preparing to evaluate FogBUGZ (shameless plug, google will tell you more) and migrating a IMP installation from FreeBSD to Fedora. Since it looks like it got disabled because the "imap" package providing the c-client API vanished it would be rather easy to recreate a c-client package for the libraries/header files only and ignore the rest. PHP would then be rebuilt with the corresponding new buildrequire statement. I've filed bug #115535 for tracking purposes and Joe Orton requested me to take the discussion here instead of bugzilla. I'm also able to package the c-client library based on the previous imap rpm if that is the conclusion of this discussion. Thanks. // kaj From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 13 13:00:12 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 13 Feb 2004 14:00:12 +0100 Subject: FC1.90 orhphaned directory report Message-ID: <87eksz9lsz.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, I updated the report about used-but-unowned directories to the state of FC1.90. The results can be seen at http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/fc1.90.html.gz Enrico From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 13 13:02:46 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 13 Feb 2004 14:02:46 +0100 Subject: ncurses now mono-only (ncurses-5.4-1)? In-Reply-To: <20040213061351.GA2321@mark.mielke.cc> (Mark Mielke's message of "Fri, 13 Feb 2004 01:13:51 -0500") References: <20040213061351.GA2321@mark.mielke.cc> Message-ID: <87ad3n9lop.fsf@kosh.ultra.csn.tu-chemnitz.de> mark at mark.mielke.cc (Mark Mielke) writes: > Just a heads up... mutt now comes up in two colours since I upgraded > to ncurses on fedora-devel-latest... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115499 Describes workaround too (using "old" xterm terminfo file). Enrico From jspaleta at princeton.edu Fri Feb 13 13:53:26 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 13 Feb 2004 08:53:26 -0500 Subject: FC1.90 orhphaned directory report Message-ID: <1076680405.3113.12.camel@spatula.pppl.gov> Enrico Scholz: > I updated the report about used-but-unowned directories to the > state of FC1.90. The results can be seen at I'm tempted in using a Bug Day to encourage community to submit spec file patches to bugzilla that fix as many of these orphaned directories as possible. But.... talking to Enrico about this on irc, he seems to think in most cases it would take more time for package maintainers to review community patches than it would to fix the specfiles themselves using this handy list. So I'm looking for opinions, do I bother trying to actually organize a bug day around this list of orphaned directories. This seems focused enough of an issue to maybe even have an example to follow and some easy-bake instructions...for the enthusiastically unexperienced rpm packager out in the community, who is subconsciously looking for a good reason to mess with specfile writing. -jef From alexander.dalloz at uni-bielefeld.de Fri Feb 13 13:55:40 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Fri, 13 Feb 2004 14:55:40 +0100 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <200402131248.i1DCmfmA005990@d103.fi.basen.net> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> Message-ID: <1076680540.4726.4.camel@sirendipity.dogma.lan> Am Fr, den 13.02.2004 schrieb Kaj J. Niemi um 13:48: > Hi, > > I'm advocating that php-imap, which was removed from Rawhide in php-4.3.4-4, > should be reintroduced before the release of FC2. I noticed it was missing > while preparing to evaluate FogBUGZ (shameless plug, google will tell you more) > and migrating a IMP installation from FreeBSD to Fedora. > > Since it looks like it got disabled because the "imap" package providing the > c-client API vanished it would be rather easy to recreate a c-client package > for the libraries/header files only and ignore the rest. PHP would then be > rebuilt with the corresponding new buildrequire statement. > > I've filed bug #115535 for tracking purposes > and Joe Orton > requested me to take the discussion here instead of bugzilla. I'm also able > to package the c-client library based on the previous imap rpm if that is > the conclusion of this discussion. > > Thanks. > > > // kaj I highly support your request! I am a Horde/IMP user too since long time. I thought Squirrelmail, as an alternative for Horde/IMP, shipped with FC2 would require imap support in PHP too. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2149.nptl Sirendipity 14:51:30 up 4 days, 17:34, load average: 0.00, 0.03, 0.02 [ ????? ?'????? - gnothi seauton ] From ms-nospam-0306 at arcor.de Fri Feb 13 14:51:42 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 13 Feb 2004 15:51:42 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040211004511.52c94705.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> Message-ID: <20040213155142.6916307b.ms-nospam-0306@arcor.de> Ping... [Attachment statuses to signal "first review", "second review"] Question: Does this raise the hurdle to QA again compared with adding just another bugzilla keyword? As reviewers would be required to not just post a clearsigned comment. They would need to become familiar with the "Create a New Attachment" window. [...] I've managed to locate a few package requests with one positive review and created a dummy attachment on each of them to flag it "first-review". These can be located easily now: At the bottom of https://bugzilla.fedora.us/query.cgi I've been lazy and added a query on Attachment Status is equal to first-review to find those packages. Long link: ;) https://bugzilla.fedora.us/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=attachstatusdefs.name&type0-0-0=equals&value0-0-0=first-review -- From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 13 16:16:37 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 13 Feb 2004 17:16:37 +0100 Subject: FC1.90 orhphaned directory report In-Reply-To: <87eksz9lsz.fsf@kosh.ultra.csn.tu-chemnitz.de> (Enrico Scholz's message of "Fri, 13 Feb 2004 14:00:12 +0100") References: <87eksz9lsz.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <871xoz9cpm.fsf@kosh.ultra.csn.tu-chemnitz.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > I updated the report about used-but-unowned directories to the state of > FC1.90. The results can be seen at > > http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/fc1.90.html.gz Based on changelog entries I sorted it by authors (some mappings are obviously wrong, but most should be correct): http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/fc1.90-author.html.gz Since this page does not have a legend, a short description: * red paths -> no package owns them * blue paths -> special paths, which need a more general solution (e.g. all the locale directories) * gray paths -> already owned by other packages; this kind needs probably the most work since it must be decided which package is the right owner. It is explained also at http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/fc1.90.html.gz#-explain-cat-1 Enrico From blizzard at redhat.com Fri Feb 13 16:11:49 2004 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 13 Feb 2004 11:11:49 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <402AD658.1070406@silverorange.com> References: <402AD658.1070406@silverorange.com> Message-ID: <402CF745.8090209@redhat.com> Steven Garrity wrote: > In the interest of disclosure, I've worked on the Visual Identity team > responsible for the new Firefox logo (and more stuff to come). I'm not > making money on it, but I am involved in Firefox. > > I would like to see Firefox included as the default web browser on > Fedora. > > I know the discussion about including Mozilla Firebird has been had > several times over here on the fedora-devel-list. The general consensus > I was able to garner from searching the archives seems to be something > like this: Internally we're having the firefox vs. epiphany discussion at least for Red Hat (which may or may not have anything to do with fedora, it's hard to say at this point.) Anyway, there are a few major stumbling blocks: o Firefox/phoenix/firebird hasn't reached 1.0, nor has anyone made the promises assocated with long term profile stability that come along with it. o Firefox doesn't have automatic profile migration. This is a _huge_ stumbling block for people coming from the Mozilla world. o Firefox doesn't look like other apps on the desktop. That is, it doesn't have enough of a native look and feel. I'm not that worried about the layout of pages - which I think is excellent in gecko in general - but the UI is odd. Preferences are different than the HIG and just about every other gnome app, button sizes and layout are all wrong, menus are wrong, icons are wrong, and it would be a huge amount of work to sync all this up. Plus it's a cost that you have to continue to pay over and over again since it's not something that would stay in sync. This is something that has echos of the old Netscape vs. Mozilla UI problems that were so huge a couple of years ago, and was one of the main reasons that the old phoenix project was started. People want control over the UI and they don't want to have to deal with people to have what they want. For whatever reason, people won't compromise over UI. So we have flame wars. And we have forks. And we go round-n-round. And we're having this discussion again. Anyway, the point being that the UI for epiphany is basically what we want and it's hard to change over to using firefox which is still changing a bit over time. o There's still the huge "what do we do about XUL apps, are they cool enough to support or not and can we do it within the scope of epiphany" discussion as well. So this is still an ongoing discussion. > > > >> ?Mozilla is required for other apps? > > There didn't seem to be any confirmation of this, but there was > speculation that some other apps in Fedora may depend on Mozilla > libraries. > > For example, Karl DeBisschop said of replacing Mozilla with Firefox, > still called firebird at the time > (http://redhat.com/archives/fedora-devel-list/2003-December/msg00295.html): > There are some external programs that use various bits of Mozilla. This includes, but is probably not limited to, gaim and maybe still evolution, which use mozilla-nss for SSL. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ ------------ From steve at rueb.com Fri Feb 13 16:48:21 2004 From: steve at rueb.com (Steve Bergman) Date: Fri, 13 Feb 2004 10:48:21 -0600 Subject: Firefox as default browser in Fedora In-Reply-To: <402CF745.8090209@redhat.com> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> Message-ID: <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> I understand that it is not a cut and dried decision. The two things that jump out at me with regards to the majority of users, i.e. nontechnical or home users, are consistency of the interface and the ability to install java, flash, etc. by themselves. Under windows they can do it, with epiphany, no way. I think that most people are able to pick up a new interface for a particular application. But dropping to a shell and typing cryptic commands at a $ prompt? They'd have to call a consultant. Most users today don't even know what DOS is. I'd better stop here before I make myself feel any older.... ;-) -Steve From toshio at tiki-lounge.com Fri Feb 13 17:12:29 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 13 Feb 2004 12:12:29 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <1076692348.15632.12.camel@Madison.badger.com> On Fri, 2004-02-13 at 11:48, Steve Bergman wrote: > I understand that it is not a cut and dried decision. The two things > that jump out at me with regards to the majority of users, i.e. > nontechnical or home users, are consistency of the interface and the > ability to install java, flash, etc. by themselves. In this vein, I think the number one thing a web browser has to be able to do is browse content on the web. This isn't limited to having plugins for multimedia, but also web pages that use browser specific features or disallow you from accessing because they determine your browser is incompatible. My bank was willing to fix their settings after I explained how Mozilla was the successor to Netscape and thus would inherit a substantial user base. I could probably use the same arguments successfully for Firefox (once blessed). I doubt I could do the same for Epiphany or Galeon. -Toshio From bwheadley at earthlink.net Fri Feb 13 17:21:40 2004 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Fri, 13 Feb 2004 11:21:40 -0600 Subject: Firefox as default browser in Fedora In-Reply-To: <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <402D07A4.9060106@earthlink.net> Steve Bergman wrote: > I understand that it is not a cut and dried decision. The two things > that jump out at me with regards to the majority of users, i.e. > nontechnical or home users, are consistency of the interface and the > ability to install java, flash, etc. by themselves. Under windows they > can do it, with epiphany, no way. I think that most people are able to > pick up a new interface for a particular application. But dropping to a > shell and typing cryptic commands at a $ prompt? They'd have to call a > consultant. Most users today don't even know what DOS is. I'd better > stop here before I make myself feel any older.... ;-) > It's not a finished product. Put it out there as a WIP or a Technology Preview, but not at the exclusion of Moz 1.6 -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From steve at rueb.com Fri Feb 13 17:31:00 2004 From: steve at rueb.com (Steve Bergman) Date: Fri, 13 Feb 2004 11:31:00 -0600 Subject: Firefox as default browser in Fedora In-Reply-To: <402D07A4.9060106@earthlink.net> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> <402D07A4.9060106@earthlink.net> Message-ID: <1076693460.4982.12.camel@ip68-12-228-23.ok.ok.cox.net> On Fri, 2004-02-13 at 11:21, Bryan W. Headley wrote: > It's not a finished product. Put it out there as a WIP or a Technology > Preview, but not at the exclusion of Moz 1.6 > Oh, I'm certainly in agreement there. I'm really thinking in terms of "at such time as a browser besides mozilla is ready". Of course, by that time Firefox will probably *be* mozilla. The more I think about it, and after thinking about Toshio's point, I'm thinking the best thing to do is probably just keep following the mozilla path. The functionality of the browser is too important for Fedora to veer off the beaten path. Yeah, I know, all of them are Gecko and all that, but still. -Steve From bwheadley at earthlink.net Fri Feb 13 17:44:55 2004 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Fri, 13 Feb 2004 11:44:55 -0600 Subject: Firefox as default browser in Fedora In-Reply-To: <1076693460.4982.12.camel@ip68-12-228-23.ok.ok.cox.net> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> <402D07A4.9060106@earthlink.net> <1076693460.4982.12.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <402D0D17.3090004@earthlink.net> Steve Bergman wrote: > On Fri, 2004-02-13 at 11:21, Bryan W. Headley wrote: > > >>It's not a finished product. Put it out there as a WIP or a Technology >>Preview, but not at the exclusion of Moz 1.6 >> > > > Oh, I'm certainly in agreement there. I'm really thinking in terms of > "at such time as a browser besides mozilla is ready". Of course, by > that time Firefox will probably *be* mozilla. The more I think about > it, and after thinking about Toshio's point, I'm thinking the best thing > to do is probably just keep following the mozilla path. The thing to keep in mind is, Mozilla.org will say when Firefox is ready and should replace the current browser/mail client. -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From stark at jeamland.ca Fri Feb 13 17:52:40 2004 From: stark at jeamland.ca (stark) Date: Fri, 13 Feb 2004 09:52:40 -0800 Subject: Firefox as default browser in Fedora In-Reply-To: <402D0D17.3090004@earthlink.net> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> <402D07A4.9060106@earthlink.net> <1076693460.4982.12.camel@ip68-12-228-23.ok.ok.cox.net> <402D0D17.3090004@earthlink.net> Message-ID: <1076694760.5051.2.camel@maranello.jeamland.ca> Not that my opinion should be the defining one, but I must say that it is extremely irritating and difficult to figure out (with FC1) how to get firebird (ok, now firefox) even installed on Fedora. I agree it likely should not (yet) be the default, but please please please make it available with the core! It's important that we offer a stable environment with maximal technology offerings, but it's also important that users should be able to try out that technology in the form that they're most comfortable with.... And Firefox is great! Very Very Very nice program that works beautifully! Dana "Mozilla is too big and bloated, but I'm using evolution so that argument went out the window" Lacoste On Fri, 2004-02-13 at 09:44, Bryan W. Headley wrote: > Steve Bergman wrote: > > On Fri, 2004-02-13 at 11:21, Bryan W. Headley wrote: > > > > > >>It's not a finished product. Put it out there as a WIP or a Technology > >>Preview, but not at the exclusion of Moz 1.6 > >> > > > > > > Oh, I'm certainly in agreement there. I'm really thinking in terms of > > "at such time as a browser besides mozilla is ready". Of course, by > > that time Firefox will probably *be* mozilla. The more I think about > > it, and after thinking about Toshio's point, I'm thinking the best thing > > to do is probably just keep following the mozilla path. > > The thing to keep in mind is, Mozilla.org will say when Firefox is ready > and should replace the current browser/mail client. > > -- > ____ .:. ____ > Bryan W. Headley - bwheadley at earthlink.net > From steve at rueb.com Fri Feb 13 19:01:45 2004 From: steve at rueb.com (Steve Bergman) Date: Fri, 13 Feb 2004 13:01:45 -0600 Subject: Should dhclient put an entry in /etc/hosts? Message-ID: <1076698905.7648.5.camel@ip68-12-228-23.ok.ok.cox.net> My cable ISP is having problems today and DNS requests are quick slow. I notice that it is taking longer than usual to log in and a ridiculous amount of time to bring up a gnome-terminal window. A little investigation shows that it is indeed the DNS lookup on my own host name that is slowing things down so much. It seems like something as local as a terminal window should not be dependent on an external DNS request. Shouldn't dhclient add the assigned hostname and IP to /etc/hosts automatically? -Steve From robert at marcanoonline.com Fri Feb 13 19:16:12 2004 From: robert at marcanoonline.com (Robert Marcano) Date: Fri, 13 Feb 2004 15:16:12 -0400 Subject: Should dhclient put an entry in /etc/hosts? In-Reply-To: <1076698905.7648.5.camel@ip68-12-228-23.ok.ok.cox.net> References: <1076698905.7648.5.camel@ip68-12-228-23.ok.ok.cox.net> Message-ID: <1076699772.4050.2.camel@pcrobert.intranet.promca.com> On Fri, 2004-02-13 at 15:01, Steve Bergman wrote: > My cable ISP is having problems today and DNS requests are quick slow. > I notice that it is taking longer than usual to log in and a ridiculous > amount of time to bring up a gnome-terminal window. A little > investigation shows that it is indeed the DNS lookup on my own host name > that is slowing things down so much. It seems like something as local > as a terminal window should not be dependent on an external DNS > request. Shouldn't dhclient add the assigned hostname and IP to > /etc/hosts automatically? My internet provider assigns to my machine a hostname and it is not registered in their DNS server, so I modified the "network" service script in order to always run "hostname localhost" at the end of the "start" section. I am sure that there are better solutions , but i needed a fast fix ;-) > > -Steve From jspaleta at princeton.edu Fri Feb 13 19:53:09 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 13 Feb 2004 14:53:09 -0500 Subject: Firefox as default browser in Fedora Message-ID: <1076701988.3113.42.camel@spatula.pppl.gov> stark wrote: > It's important that we offer a stable environment with > maximal technology offerings, but it's also important that > users should be able to try out that technology in the > form that they're most comfortable with.... Core can not offer all things to all people... if you want to TRY OUT technology..you use the yet to be officially created fedora extras repository when it becomes available. Core can not have 17 different gecko base web browser Core can not have 17 different wysiwyg editors Core can not have 17 different instant message apps. Core can't even possibly have all possible functionality one could possibly want without serious bloating the number of cd images.... If Firefox only makes sense because its "the future" then it should be considered for Core in "the future" We can NOT keep adding more and more applications into Core without seriously affecting the ease of installation. 7 packed binary disks isn't something i look forward to downloading for fc4. People need to think hard about the legitmate technical merit guidelines to use for throwing things in and out of Core once Extras opens up. Having this debate package by package, for every possible package that could be included/exclude from Core is going to go no where fast. -jef"i can't wait till Core takes up 3 dvd isos"spaleta From stark at jeamland.ca Fri Feb 13 20:00:37 2004 From: stark at jeamland.ca (stark) Date: Fri, 13 Feb 2004 12:00:37 -0800 Subject: Firefox as default browser in Fedora In-Reply-To: <1076701988.3113.42.camel@spatula.pppl.gov> References: <1076701988.3113.42.camel@spatula.pppl.gov> Message-ID: <1076702436.5051.5.camel@maranello.jeamland.ca> > created fedora extras repository when it becomes available. OK, I'd settle for this. But seeing as it's not available, how about some INCLUDED docs indicating how to get these apps? I moved to Fedora from FreeBSD and found getting yum and apt-get working very difficult and poorly documented. I don't care _how_ I just want to be able to find out the answer :) Dana Lacoste From stevelist at silverorange.com Fri Feb 13 20:05:04 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Fri, 13 Feb 2004 16:05:04 -0400 Subject: Firefox as default browser in Fedora In-Reply-To: <402CF745.8090209@redhat.com> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> Message-ID: <402D2DF0.90507@silverorange.com> Christopher Blizzard wrote: > Internally we're having the firefox vs. epiphany discussion at least for Red Hat (which may or may not have anything to do with fedora, it's hard to say at this point.) > > Anyway, there are a few major stumbling blocks: > > o Firefox/phoenix/firebird hasn't reached 1.0, nor has anyone made the promises assocated with long term profile stability that come along with it. True. Though it is clear that from now (0.8) on, the focus is on polishing and stabilizing for 1.0. As detailed in this weblog post (http://www.deftone.com/blogzilla/archives/towards_firefox_10.html) Ben Goodger states in a forum that the two priorities for 1.0 are Seamless Data Migration from other browsers and Automated extension update, stability and version compatibility. Good news. > o Firefox doesn't have automatic profile migration. This is a _huge_ stumbling block for people coming from the Mozilla world. Yup. See above. > o Firefox doesn't look like other apps on the desktop. That is, it doesn't have enough of a native look and feel. I'm not that worried about the layout of pages - which I think is excellent in gecko in general - but the UI is odd. Preferences are different than the HIG and just about every other gnome app, button sizes and layout are all wrong, menus are wrong, icons are wrong, and it would be a huge amount of work to sync all this up. Plus it's a cost that you have to continue to pay over and over again since it's not something that would stay in sync. > > This is something that has echos of the old Netscape vs. Mozilla UI problems that were so huge a couple of years ago, and was one of the main reasons that the old phoenix project was started. People want control over the UI and they don't want to have to deal with people to have what they want. For whatever reason, people won't compromise over UI. So we have flame wars. And we have forks. And we go round-n-round. And we're having this discussion again. > > Anyway, the point being that the UI for epiphany is basically what we want and it's hard to change over to using firefox which is still changing a bit over time. Well, Firefox clearly doesn't follow all of the HIG, and theoretically cannot follow them as, in some cases, they clash (reasonably so) with the equivalent guidelines for OS X and Windows. However, they have done a very nice job in making Firefox play well in Gnome. The XFT/GTK2 builds have a nice native feel in Gnome. I've been working with on new Mozilla Visual Identity team and we are acutely aware of the difficulty in wanted to be both native/integrated and cross-platform. So far - I think we're doing a pretty good job. For example, if you try Firefox 0.8 on Mac OS X, you'll see that it has as native a feel as Camino. I think we can do the same on Gnome. Steven Garrity From strange at nsk.no-ip.org Fri Feb 13 20:26:52 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 13 Feb 2004 20:26:52 +0000 Subject: cdrdao-1.1.8 released In-Reply-To: <402CC158.1000403@freemail.hu> References: <402CC158.1000403@freemail.hu> Message-ID: <20040213202652.GA2560@nsk.no-ip.org> On Fri, Feb 13, 2004 at 01:21:44PM +0100, Boszormenyi Zoltan wrote: > Hi, > > cdrdao-1.1.8 has just been released. > It would be nice to have it in FC2 since it can > write CDs without the ide-scsi emulation. cdrdao 1.1.7 on fedora-devel can write cds directly by ATAPI access: $ rpm -q cdrdao cdrdao-1.1.7-8.atapi.1 $ rpm -q --changelog cdrdao | head -n3 * Mon Jan 26 2004 Harald Hoyer 1.1.7-8.atapi.1 - added ATAPI: support Of course, having it updated to 1.1.8 shouldn't hurt anybody. Regards, Luciano Rocha From ville.skytta at iki.fi Fri Feb 13 21:00:00 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 13 Feb 2004 23:00:00 +0200 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040213155142.6916307b.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> Message-ID: <1076706000.9498.110.camel@bobcat.mine.nu> On Fri, 2004-02-13 at 16:51, Michael Schwendt wrote: > Ping... > > [Attachment statuses to signal "first review", "second review"] > > Question: Does this raise the hurdle to QA again compared with adding just > another bugzilla keyword? As reviewers would be required to not just post > a clearsigned comment. They would need to become familiar with the "Create > a New Attachment" window. Maybe. Further, it would be more "correct" process-wise if the initial package submission was the attachment. Then, reviews would be posted by editing that attachment, setting the status, and binding the reviews clearly to that particular submission/revision. However, it would result in reviews being posted as the "edit attachment" comments, ie. again inlined. New package revisions would be made again by posting a new attachment, which would obsolete the previous submission attachment. So, from the submitter POV: 1) Submit an initial description about the package. 2) Post an attachment containing the URL (or something else) to the package. 3) Wait for reviews; if need to revise, post another attachment and obsolete the old one. And the reviewer: 1) Review the package submitted as the attachment. 2) Edit the submission attachment, set the status flags and post the review comments as the edit attachment comments. Sign the review at least if it's a positive one etc. Some stuff to check: - Is it possible to create a query that does not match attachment statuses for obsoleted attachments? - Is the Bugzilla web (and email UI) good enough for implementing this or will it cause too much confusion to be worth it? This is already even more complex than the "the review is the attachment" approach. Dunno... From nietzel at rhinobox.org Fri Feb 13 21:28:30 2004 From: nietzel at rhinobox.org (Earle Robert Nietzel) Date: Fri, 13 Feb 2004 22:28:30 +0100 Subject: Building Radeon drivers on 2.6.x kernel rpms. In-Reply-To: <1076371303.8358.10.camel@localhost.localdomain> References: <1076371303.8358.10.camel@localhost.localdomain> Message-ID: <1076707710.1960.4.camel@ws001.rhinobox.org> Thats because make can't find the drm header files in /lib/modules/2.6.1-1.65smp/build/drivers/char/drm You can correct this by removing the drm directory and adding a symlink to: /usr/src/linux-2.6.1-1.65/drivers/char/drm This will fix this problem. Earle On Tue, 2004-02-10 at 10:01 +1000, Gavin Graham wrote: > Hi, > > It seems that the kernel headers for 2.6.x are somehow incorrect. > I say this as I am trying to build the ATI Radeon drivers and I get the > following error message: > > [root at localhost fglrx]# cd build_mod/ > [root at localhost build_mod]# ./make.sh > ATI module generator V 2.0 > ========================== > initializing... > Error: > XFree86 drm includes at > /lib/modules/2.6.1-1.65smp/build/include/../drivers/char/drm do not fit > this driver. > This driver is designed to only work with X4.1.0 or higher. > You can match this by getting Linux kernel 2.4.8 or higher. > > > This has been happening with every release of the Fedora Dev kernel RPMS > for 2.6.x and it also happens with Arjan's kernel too. > > I know there is some issues with the Radeon drivers that need to be > overcome for successfull compilation under 2.6.x but this specific > problem seems to be moreso with the actual kernel packages. > > Can anyone shed some light on this?? > > Regards, > -- > Gavin Graham > Systems Operations Supervisor > Orrcon Information Technology > Orrcon Pty Ltd > P: 07 32740549 E: g.graham at orrcon.com.au > F: 07 32740691 M: 0409 897288 > WWW: www.orrcon.com.au > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pros-n-cons at bak.rr.com Fri Feb 13 21:36:05 2004 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 13 Feb 2004 13:36:05 -0800 Subject: Firefox as default browser in Fedora In-Reply-To: <1076702436.5051.5.camel@maranello.jeamland.ca> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> Message-ID: <1076708165.13573.1.camel@turtle.localdomain> On Fri, 2004-02-13 at 12:00, stark wrote: > > created fedora extras repository when it becomes available. > > OK, I'd settle for this. > > But seeing as it's not available, how about some INCLUDED docs > indicating how to get these apps? I moved to Fedora from FreeBSD > and found getting yum and apt-get working very difficult and poorly > documented. > > I don't care _how_ I just want to be able to find out the answer :) > > Dana Lacoste > The Fedora FAQ has a great yum.conf http://fedora.artoo.net/faq/samples/yum.conf just throw that file in /etc and uncomment the DaG repositories for Firefox From strange at nsk.no-ip.org Fri Feb 13 22:07:46 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 13 Feb 2004 22:07:46 +0000 Subject: XFree86 @devel vs @updates Message-ID: <20040213220745.GA3503@nsk.no-ip.org> Hello, I've been tracking fedora-devel for some weeks, but I also track FC1 updates & updates-testing. Today I updated my fedora-devel mirror and I see XFree86-4.3.0-45.0.2 packages, but on FC1 updates-testing there are XFree86-4.3.0-50, that rpm and yum consider above the development version. So which should I use? Which one is the more up to date? Regards, Luciano Rocha From jspaleta at princeton.edu Fri Feb 13 22:10:22 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 13 Feb 2004 17:10:22 -0500 Subject: Firefox as default browser in Fedora Message-ID: <1076710222.3113.53.camel@spatula.pppl.gov> stark wrote: > But seeing as it's not available, how about some INCLUDED docs > indicating how to get these apps? I moved to Fedora from FreeBSD > and found getting yum and apt-get working very difficult and poorly > documented. http://fedora.redhat.com/projects/docs/ I suggest you spend a few minutes skimming the archives for the past couple/three months to get a feel for where things stand on the documentation project front. https://listman.redhat.com/archives/fedora-docs-list/ -jef From strange at nsk.no-ip.org Fri Feb 13 22:49:45 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 13 Feb 2004 22:49:45 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <1076692348.15632.12.camel@Madison.badger.com> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> <1076692348.15632.12.camel@Madison.badger.com> Message-ID: <20040213224945.GA3822@nsk.no-ip.org> On Fri, Feb 13, 2004 at 12:12:29PM -0500, Toshio wrote: > On Fri, 2004-02-13 at 11:48, Steve Bergman wrote: > > I understand that it is not a cut and dried decision. The two things > > that jump out at me with regards to the majority of users, i.e. > > nontechnical or home users, are consistency of the interface and the > > ability to install java, flash, etc. by themselves. > > In this vein, I think the number one thing a web browser has to be able > to do is browse content on the web. This isn't limited to having > plugins for multimedia, but also web pages that use browser specific > features or disallow you from accessing because they determine your > browser is incompatible. My bank was willing to fix their settings > after I explained how Mozilla was the successor to Netscape and thus > would inherit a substantial user base. I could probably use the same > arguments successfully for Firefox (once blessed). I doubt I could do > the same for Epiphany or Galeon. That shouldn't be necessary. For all web purposes, epiphany and firefox are mozilla: epiphany: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Epiphany/1.0.7" firefox: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8" Besides, they shouldn't be blocking from UA... Regards, Luciano Rocha From strange at nsk.no-ip.org Fri Feb 13 22:53:24 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 13 Feb 2004 22:53:24 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <1076708165.13573.1.camel@turtle.localdomain> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> Message-ID: <20040213225324.GB3822@nsk.no-ip.org> On Fri, Feb 13, 2004 at 01:36:05PM -0800, Vincent wrote: > On Fri, 2004-02-13 at 12:00, stark wrote: > > > created fedora extras repository when it becomes available. > > > > OK, I'd settle for this. > > > > But seeing as it's not available, how about some INCLUDED docs > > indicating how to get these apps? I moved to Fedora from FreeBSD > > and found getting yum and apt-get working very difficult and poorly > > documented. > > > > I don't care _how_ I just want to be able to find out the answer :) > > > > Dana Lacoste > > > > The Fedora FAQ has a great yum.conf > http://fedora.artoo.net/faq/samples/yum.conf > just throw that file in /etc and uncomment the DaG repositories for > Firefox But that's no use for a newbie. Can't a package be created for FC inclusion with menu entries for installation of 3rd party software? Like java, firefox, flash, etc.? Regards, Luciano Rocha From nphilipp at redhat.com Fri Feb 13 23:05:02 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 14 Feb 2004 00:05:02 +0100 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076453321.15803.52.camel@opus> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> Message-ID: <1076713501.12133.2.camel@wombat.tiptoe.de> On Tue, 2004-02-10 at 23:48, seth vidal wrote: > > Not as opposed to. If there was a single small file containing > > references to the others, fine, that's ok to update every time. But > > having a single file that's a collection of all the headers, no matter > > how compressed it is, it's probably too much info to download every > > time it changes. It appears to me that having the headers available > > for separate downloads would be better, even if they're *also* > > available in a highly-compressed format for a speedy initial > > download. But then, mirrors lose on disk space. One can't win, I > > guess. Unless... rproxy (rsync-based web cache) anyone? > > > The primary metadata file, for all of fc1, is 400K, compressed. > > That's a doable download almost any time. The repomd.xml has an md5sum > and a timestamp of the primary and other metadata files - so you can > know if it has changed, fairly well. I think I don't understand you here -- how am I supposed to compute an MD5 sum lying on a webserver without downloading the file first? 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 pros-n-cons at bak.rr.com Fri Feb 13 23:15:38 2004 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 13 Feb 2004 15:15:38 -0800 Subject: Firefox as default browser in Fedora In-Reply-To: <20040213225324.GB3822@nsk.no-ip.org> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> Message-ID: <1076714138.12310.1.camel@turtle.localdomain> On Fri, 2004-02-13 at 14:53, Luciano Miguel Ferreira Rocha wrote: > On Fri, Feb 13, 2004 at 01:36:05PM -0800, Vincent wrote: > > On Fri, 2004-02-13 at 12:00, stark wrote: > > > > created fedora extras repository when it becomes available. > > > > > > OK, I'd settle for this. > > > > > > But seeing as it's not available, how about some INCLUDED docs > > > indicating how to get these apps? I moved to Fedora from FreeBSD > > > and found getting yum and apt-get working very difficult and poorly > > > documented. > > > > > > I don't care _how_ I just want to be able to find out the answer :) > > > > > > Dana Lacoste > > > > > > > The Fedora FAQ has a great yum.conf > > http://fedora.artoo.net/faq/samples/yum.conf > > just throw that file in /etc and uncomment the DaG repositories for > > Firefox > > But that's no use for a newbie. Can't a package be created for FC inclusion > with menu entries for installation of 3rd party software? Like java, > firefox, flash, etc.? > > Regards, > Luciano Rocha > If they did it by default that would mean they support it, which is not true. From toshio at tiki-lounge.com Fri Feb 13 23:33:59 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 13 Feb 2004 18:33:59 -0500 Subject: Firefox as default browser in Fedora In-Reply-To: <20040213224945.GA3822@nsk.no-ip.org> References: <402AD658.1070406@silverorange.com> <402CF745.8090209@redhat.com> <1076690891.4497.6.camel@ip68-12-228-23.ok.ok.cox.net> <1076692348.15632.12.camel@Madison.badger.com> <20040213224945.GA3822@nsk.no-ip.org> Message-ID: <1076715234.15632.157.camel@Madison.badger.com> On Fri, 2004-02-13 at 17:49, Luciano Miguel Ferreira Rocha wrote: > That shouldn't be necessary. For all web purposes, epiphany and firefox are > mozilla: > epiphany: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 > Epiphany/1.0.7" > > firefox: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 > Firefox/0.8" > Cool. Good to know I won't have to try to explain software politics to financial institutions :-) > Besides, they shouldn't be blocking from UA... > Sure, but I think it's a corollary to Murphy's Law: "If your browser has the features to display the website, the website authors will prevent it because they can." -Toshio -- Toshio From strange at nsk.no-ip.org Fri Feb 13 23:38:35 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 13 Feb 2004 23:38:35 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <1076714138.12310.1.camel@turtle.localdomain> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> <1076714138.12310.1.camel@turtle.localdomain> Message-ID: <20040213233835.GA4476@nsk.no-ip.org> On Fri, Feb 13, 2004 at 03:15:38PM -0800, Vincent wrote: > > > > But that's no use for a newbie. Can't a package be created for FC inclusion > > with menu entries for installation of 3rd party software? Like java, > > firefox, flash, etc.? > > > > Regards, > > Luciano Rocha > > > > If they did it by default that would mean they support it, which is not > true. I'd thought a menu labelled "Unsuported Applications" would be enough. Regards, Luciano Rocha From ms-nospam-0306 at arcor.de Fri Feb 13 23:53:19 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 14 Feb 2004 00:53:19 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076706000.9498.110.camel@bobcat.mine.nu> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> Message-ID: <20040214005319.6242aee5.ms-nospam-0306@arcor.de> On Fri, 13 Feb 2004 23:00:00 +0200, Ville Skytt? wrote: > Further, it would be more "correct" process-wise if the initial package > submission was the attachment. Which would also make it easier to find the most recent package in a ticket. Scrolling up from the bottom to search for URLs in comments, which announce an updated package, is not ideal. > Then, reviews would be posted by editing > that attachment, setting the status, and binding the reviews clearly to > that particular submission/revision. However, it would result in > reviews being posted as the "edit attachment" comments, ie. again > inlined. Right now I don't really care for the exact procedure, since working with an increased number of attachments might turn out to get a bit confusing at times. Still it would be nice to have a way to locate reviews. I consider it an unfortunate circumstance, that a few reviewers spend time on a package which won't be published because it needs another review. Often, after some time, the packager updates such a package even after a first publish vote, and the reviewer would need to check that update again and hope that another person joins to get the second approval. Fine if fedora.us package queue becomes a source for working src.rpms, too, but that's not enough. > Some stuff to check: > - Is it possible to create a query that does not match attachment > statuses for obsoleted attachments? Shouldn't be a problem since attachment statuses can be taken back, if need be, and queries can be limited on "open" tickets. > - Is the Bugzilla web (and email UI) good enough for implementing this > or will it cause too much confusion to be worth it? We probably need to test-drive this a bit. Not as a new policy, but as an option. > This is already even more complex than the "the review is the > attachment" approach. Dunno... As a last resort, we might try the REVIEWED keyword, too. Much more feedback from the target group of these changes is necessary. -- From skvidal at phy.duke.edu Sat Feb 14 01:02:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 13 Feb 2004 20:02:40 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076713501.12133.2.camel@wombat.tiptoe.de> References: <1076410390.1422.101.camel@roque> <1076432484.1542.20.camel@mirkwood.boston.redhat.com> <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> Message-ID: <1076720560.13049.4.camel@binkley> > I think I don't understand you here -- how am I supposed to compute an > MD5 sum lying on a webserver without downloading the file first? go read the specification for the metadata. the idea is this. repomd.xml is a file that ONLY has: the md5sums of the other metadata files. it doesn't contain any information about the packages, it only contains information about the metadata files. so you download the repomd.xml file (which is tiny tiny <1K), you check your md5sums versus the ones in the file, to determine what you might need. That also means you can gpg sign this repomd.xml file for security. -sv From alan at redhat.com Sat Feb 14 01:15:07 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Feb 2004 20:15:07 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076720560.13049.4.camel@binkley> References: <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> Message-ID: <20040214011507.GA7506@devserv.devel.redhat.com> On Fri, Feb 13, 2004 at 08:02:40PM -0500, seth vidal wrote: > so you download the repomd.xml file (which is tiny tiny <1K), you check > your md5sums versus the ones in the file, to determine what you might > need. Is the repomd data small enough that you can also stick it in DNS TXT records so that you can use the domain name service as a global cache for keeping lookup costs down ? From skvidal at phy.duke.edu Sat Feb 14 01:37:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 13 Feb 2004 20:37:35 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <20040214011507.GA7506@devserv.devel.redhat.com> References: <000c01c3efff$435c7ea0$723de0d5@lupusbcc8e7249> <1076435884.27329.2.camel@smoogen2.lanl.gov> <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> Message-ID: <1076722655.13049.11.camel@binkley> > Is the repomd data small enough that you can also stick it in DNS TXT > records so that you can use the domain name service as a global cache > for keeping lookup costs down ? I'm kinda hoping your joking, but. here's a sample: http://linux.duke.edu/projects/metadata/samples/repomd-sample.xml -sv From alan at redhat.com Sat Feb 14 02:02:44 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Feb 2004 21:02:44 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076722655.13049.11.camel@binkley> References: <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> Message-ID: <20040214020244.GA20715@devserv.devel.redhat.com> On Fri, Feb 13, 2004 at 08:37:35PM -0500, seth vidal wrote: > > records so that you can use the domain name service as a global cache > > for keeping lookup costs down ? > > I'm kinda hoping your joking, but. Im quite serious - there are numerous protocols that have used DNS for this purpose and awareness is now growing (its been one of those neat things nobody quite 'got' for years). > here's a sample: > http://linux.duke.edu/projects/metadata/samples/repomd-sample.xml Well you might want to lose the xml for the TXT records but the rest would certainly fit nicely into DNS From skvidal at phy.duke.edu Sat Feb 14 02:29:03 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 13 Feb 2004 21:29:03 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <20040214020244.GA20715@devserv.devel.redhat.com> References: <003601c3f002$11abf9f0$723de0d5@lupusbcc8e7249> <4029469D.6030106@redhat.com> <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> Message-ID: <1076725743.13049.18.camel@binkley> On Fri, 2004-02-13 at 21:02 -0500, Alan Cox wrote: > On Fri, Feb 13, 2004 at 08:37:35PM -0500, seth vidal wrote: > > > records so that you can use the domain name service as a global cache > > > for keeping lookup costs down ? > > > > I'm kinda hoping your joking, but. > > Im quite serious - there are numerous protocols that have used DNS for > this purpose and awareness is now growing (its been one of those neat things > nobody quite 'got' for years). I'm curious how this is useful when there can be multiple repositories on any given server. Is there a good place to look for how the dns txt information is being more commonly used? -sv From cturner at redhat.com Sat Feb 14 02:37:54 2004 From: cturner at redhat.com (Chip Turner) Date: 13 Feb 2004 21:37:54 -0500 Subject: Perl 5.8.2 in Rawhide In-Reply-To: <1070925662.31135.107.camel@bobcat.mine.nu> References: <1070791231.11239.3.camel@bobcat.mine.nu> <1070925662.31135.107.camel@bobcat.mine.nu> Message-ID: Ville Skytt? writes: > On Mon, 2003-12-08 at 04:40, Chip Turner wrote: > > Ville Skytt? writes: > > > > > Any chance of getting #73970 fixed? > > > > Wow, that's an old bug. Considering it's extremely sane and even > > already had a patch attached, how could I refuse? :) > > > > Building now, should how up in rawhide soon. > > Thanks! > > > Any other pet bugs that you'd like to see fixed? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75195 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89415 > Both old and could be resolved as CURRENTRELEASE. But why is CGI.pm and > friends included in the perl package in the first place? AFAICT it's > not part of upstream perl. Does the perl package contain other bundled > CPAN modules like this? Actually a number of modules in CPAN are also included in the core perl package; CGI.pm is one such, as is Storable, etc. Perl 5.8.3 in Rawhide includes CGI.pm 3.01. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105866 > Not in the perl package, but perl-DateManip. Upgrading to 5.42a (along > with the attached patch in the bug) would be appreciated by folks using > UTF-8 locales. Built into rawhide this afternoon. The patch wasn't necessary, it seemed to pass its 'make test' just fine. Actually, a lot of other packages were built into rawhide, too. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From alan at redhat.com Sat Feb 14 02:40:13 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Feb 2004 21:40:13 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076725743.13049.18.camel@binkley> References: <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> <1076725743.13049.18.camel@binkley> Message-ID: <20040214024013.GA26270@devserv.devel.redhat.com> On Fri, Feb 13, 2004 at 09:29:03PM -0500, seth vidal wrote: > I'm curious how this is useful when there can be multiple repositories > on any given server. Put the path in DNS too or a defined short form then its query fedora-2-test1.foobar.org txt > Is there a good place to look for how the dns txt information is being > more commonly used? Rendezvous (DNS-SD) http://www.zeroconf.org/Rendezvous/txtrecords.html RFC1464 (overview) DNS RBL (txt records explain why the block exists) IPSEC OE (gives info to do keying) SPF (anti spam) HESIOD (authentication caching via dns txt) From mharris at redhat.com Sat Feb 14 04:29:44 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 13 Feb 2004 23:29:44 -0500 (EST) Subject: XFree86 @devel vs @updates In-Reply-To: <20040213220745.GA3503@nsk.no-ip.org> References: <20040213220745.GA3503@nsk.no-ip.org> Message-ID: On Fri, 13 Feb 2004, Luciano Miguel Ferreira Rocha wrote: >Date: Fri, 13 Feb 2004 22:07:46 +0000 >From: Luciano Miguel Ferreira Rocha >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: Development discussions related to Fedora Core > >Subject: XFree86 @devel vs @updates > > >Hello, > >I've been tracking fedora-devel for some weeks, but I also track FC1 updates & >updates-testing. > >Today I updated my fedora-devel mirror and I see XFree86-4.3.0-45.0.2 >packages, but on FC1 updates-testing there are XFree86-4.3.0-50, that rpm >and yum consider above the development version. > >So which should I use? Which one is the more up to date? The XFree86 4.3.0 src.rpm is 100% shared between: - Red Hat Linux 9 - Red Hat Enterprise Linux 3 - Fedora Core 1 - Fedora development - Red Hat Linux 8.0 (It can be built 'unofficially' for RHL 8.0 with the addition of some RHL 9 packages to the system.) Packages built for RHL 8.0, I set the release tag to "1.80.n", packages for RHL 9, the release tag is set to "1.90.n", and packages for RHEL, the release tag is set to "n.EL", where Fedora Core 1 erratum, as well as Fedora development, I set the release simply to "n". So, for release '55', which is the absolute latest one, which was just released as erratum across the board, the release number for each product is: RHL8.0 - 1.80.55 (my personal unofficial builds [1]) RHL9 - 2.90.55 RHEL3 - 55.EL FC1 - 55 devel - whatever random number of the day/week/month I decide to use in order to confuse people. It might even go backwards, or use irrational numbers. The value of 'n' is what determines which is the 'latest' for the given release. The binary packages for each of the above OS releases are not all build 100% identically. Inside the spec file, there are 5 rpm macros to determine what OS release the package should be configured to build for. Depending on which of the 5 macros is set to "1", the build is reconfigured to build especially for that particular OS release. The macros are: %if ! %{build_autodetect_mode} # Set *one* of the following build targets to 1 as appropriate # Fedora Core development builds a.k.a. "rawhide" %define build_rawhide 0 # Fedora Core 1 %define build_yarrow 1 # Red Hat Enterprise Linux version 3 (AS/WS/ES/PW) %define build_taroon 0 # Red Hat Linux 9 (Shrike) %define build_shrike 0 # Red Hat Linux 8.0 (Psyche) %define build_psyche 0 >From the above, my current spec file is configured to build Fedora Core 1 (Yarrow) packages. The next question which might be on people's minds is "What are the differences between each of the above build targets Mike?" Each OS release, new enhancements are made, some of which are experimental and need some time in rawhide testing, etc. before I can deem them worthy of being included in future erratum for older OS releases. I wrap those changes in %if %{build_rawhide} checks in the spec file. Over time, I may consider such a change stable enough to be considered ok for some or all of the other releases, and will change the conditionalizaton appropriately. Other changes and improvements made, sometimes require features only present in a particular OS release or releases, and so I have to conditionalize the inclusion of those features to just the releases it will work on. An example of this is our libGL optimization patch: # Only apply this to Cambridge and Taroon builds %define with_libGL_opt_patch %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' -o '%{build_taroon}' -eq '1' ] && echo 1 || echo 0) The above support wont work on older OS releases due to requiring new gcc and/or glibc and/or kernel support for example. # Only apply to Cambridge until well tested, then apply to Taroon also. %define with_libGL_exec_shield_fixes %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' ] && echo 1 || echo 0) This is an example of testing out exec-shield on Fedora Core guinea pigs. ;o) The intent here being to test this functionality well before applying the patches to other OS releases. The recent XFree86 security exploits which we just released erratum for, were just tested with exec-shield enabled and the X server was found not vulnerable to the exploit while exec-shield was enabled. So those running Fedora Core 1 or rawhide, who have exec-shield enabled, don't need to bother updating to fix the security issue that was just released. I'll probably enable the above check on other OS releases once confirming we have exec-shield support on them. ;o) Anyhow... It's Friday and I was a bit bored. Having read through the subject lines of fedora-devel-list I found myself craving some actual development related content, kindof like a chocolate bar, and so I figured I'd post the above tidbits in case someone found them useful/informative, etc. Perhaps I can even sucker some people into testing rawhide XFree86 out on previous OS releases now, and get even more test coverage. ;o) Anyhow, hope this is useful to someone... time to go read now.. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From cmadams at hiwaay.net Sat Feb 14 04:37:04 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 13 Feb 2004 22:37:04 -0600 Subject: XFree86 @devel vs @updates In-Reply-To: References: <20040213220745.GA3503@nsk.no-ip.org> Message-ID: <20040214043704.GC1476547@hiwaay.net> Once upon a time, Mike A. Harris said: > devel - whatever random number of the day/week/month I decide > to use in order to confuse people. It might even go > backwards, or use irrational numbers. Does Jeff Johnson know you use irrational numbers for releases? :-) Just make sure they stay real! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ByteEnable at austin.rr.com Sat Feb 14 06:31:18 2004 From: ByteEnable at austin.rr.com (ByteEnable) Date: Sat, 14 Feb 2004 00:31:18 -0600 Subject: XFree86 @devel vs @updates In-Reply-To: References: <20040213220745.GA3503@nsk.no-ip.org> Message-ID: <1076740278.9970.4.camel@ByteEnable> On Fri, 2004-02-13 at 22:29, Mike A. Harris wrote: > On Fri, 13 Feb 2004, Luciano Miguel Ferreira Rocha wrote: > > >Date: Fri, 13 Feb 2004 22:07:46 +0000 > >From: Luciano Miguel Ferreira Rocha > >To: fedora-devel-list at redhat.com > >Content-Type: text/plain; charset=us-ascii > >List-Id: Development discussions related to Fedora Core > > > >Subject: XFree86 @devel vs @updates > > > > > >Hello, > > > >I've been tracking fedora-devel for some weeks, but I also track FC1 updates & > >updates-testing. > > > >Today I updated my fedora-devel mirror and I see XFree86-4.3.0-45.0.2 > >packages, but on FC1 updates-testing there are XFree86-4.3.0-50, that rpm > >and yum consider above the development version. > > > >So which should I use? Which one is the more up to date? > > The XFree86 4.3.0 src.rpm is 100% shared between: > > - Red Hat Linux 9 > - Red Hat Enterprise Linux 3 > - Fedora Core 1 > - Fedora development > - Red Hat Linux 8.0 (It can be built 'unofficially' for RHL 8.0 > with the addition of some RHL 9 packages to the system.) > > Packages built for RHL 8.0, I set the release tag to "1.80.n", > packages for RHL 9, the release tag is set to "1.90.n", and > packages for RHEL, the release tag is set to "n.EL", where Fedora > Core 1 erratum, as well as Fedora development, I set the release > simply to "n". > > So, for release '55', which is the absolute latest one, which was > just released as erratum across the board, the release number for > each product is: > > RHL8.0 - 1.80.55 (my personal unofficial builds [1]) > RHL9 - 2.90.55 > RHEL3 - 55.EL > FC1 - 55 > devel - whatever random number of the day/week/month I decide > to use in order to confuse people. It might even go > backwards, or use irrational numbers. > > > The value of 'n' is what determines which is the 'latest' for the > given release. The binary packages for each of the above OS > releases are not all build 100% identically. Inside the spec > file, there are 5 rpm macros to determine what OS release the > package should be configured to build for. Depending on which of > the 5 macros is set to "1", the build is reconfigured to build > especially for that particular OS release. > > The macros are: > > %if ! %{build_autodetect_mode} > # Set *one* of the following build targets to 1 as appropriate > # Fedora Core development builds a.k.a. "rawhide" > %define build_rawhide 0 > # Fedora Core 1 > %define build_yarrow 1 > # Red Hat Enterprise Linux version 3 (AS/WS/ES/PW) > %define build_taroon 0 > # Red Hat Linux 9 (Shrike) > %define build_shrike 0 > # Red Hat Linux 8.0 (Psyche) > %define build_psyche 0 > > > >From the above, my current spec file is configured to build > Fedora Core 1 (Yarrow) packages. > > The next question which might be on people's minds is "What are > the differences between each of the above build targets Mike?" > > Each OS release, new enhancements are made, some of which are > experimental and need some time in rawhide testing, etc. before I > can deem them worthy of being included in future erratum for > older OS releases. I wrap those changes in %if %{build_rawhide} > checks in the spec file. Over time, I may consider such a change > stable enough to be considered ok for some or all of the other > releases, and will change the conditionalizaton appropriately. > > Other changes and improvements made, sometimes require features > only present in a particular OS release or releases, and so I > have to conditionalize the inclusion of those features to just > the releases it will work on. An example of this is our libGL > optimization patch: > > # Only apply this to Cambridge and Taroon builds > %define with_libGL_opt_patch %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' -o '%{build_taroon}' -eq '1' ] && echo 1 || echo 0) > > The above support wont work on older OS releases due to requiring > new gcc and/or glibc and/or kernel support for example. > > > # Only apply to Cambridge until well tested, then apply to Taroon also. > %define with_libGL_exec_shield_fixes %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' ] && echo 1 || echo 0) > > This is an example of testing out exec-shield on Fedora Core > guinea pigs. ;o) The intent here being to test this > functionality well before applying the patches to other OS > releases. The recent XFree86 security exploits which we just > released erratum for, were just tested with exec-shield enabled > and the X server was found not vulnerable to the exploit while > exec-shield was enabled. So those running Fedora Core 1 or > rawhide, who have exec-shield enabled, don't need to bother > updating to fix the security issue that was just released. I'll > probably enable the above check on other OS releases once > confirming we have exec-shield support on them. ;o) > > Anyhow... It's Friday and I was a bit bored. Having read > through the subject lines of fedora-devel-list I found myself > craving some actual development related content, kindof like a > chocolate bar, and so I figured I'd post the above tidbits in > case someone found them useful/informative, etc. > > Perhaps I can even sucker some people into testing rawhide > XFree86 out on previous OS releases now, and get even more test > coverage. ;o) > > Anyhow, hope this is useful to someone... time to go read now.. > > TTYL > > -- > Mike A. Harris ftp://people.redhat.com/mharris > OS Systems Engineer - XFree86 maintainer - Red Hat > You sound like you make releases on a whim and whenever you get around to it. There is no sign off or test plan that you follow? I surely hope that you are jesting. Byte From wtogami at redhat.com Sat Feb 14 06:34:54 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 13 Feb 2004 20:34:54 -1000 Subject: XFree86 @devel vs @updates In-Reply-To: <20040214043704.GC1476547@hiwaay.net> References: <20040213220745.GA3503@nsk.no-ip.org> <20040214043704.GC1476547@hiwaay.net> Message-ID: <402DC18E.8060602@redhat.com> Chris Adams wrote: > Once upon a time, Mike A. Harris said: > >>devel - whatever random number of the day/week/month I decide >> to use in order to confuse people. It might even go >> backwards, or use irrational numbers. > > > Does Jeff Johnson know you use irrational numbers for releases? :-) > > Just make sure they stay real! I am extremely upset that they stole my idea of incrementing Epoch by pi for each release, and instead implemented complex numbers in rpmvercmp in the upcoming FC2 test2. There is absolutely no way we will win the marketshare battle without trigonometric version metrics. Also watch for the kernel-space C++ floating point math accelerator module currently proposed for test3. I am hoping that can be stabilized before the freeze on February 27th. Crossing my fingers on this one. Warren From mark at mark.mielke.cc Sat Feb 14 06:49:22 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Sat, 14 Feb 2004 01:49:22 -0500 Subject: heads up: grub-0.94-1.i386.rpm doesn't boot... Message-ID: <20040214064922.GA2210@mark.mielke.cc> PIII 800Mhz fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse After installing grub, and doing the normal "root (hd0,0)\nsetup (hd0)\n" grub did not function properly. At boot time I see a blinking cursor at the top-right of a blank screen. I experimented a little, and finally restored grub-0.93-7.i386.rpm from yarrow. It wouldn't boot until I issued another "root (hd0,0)\nsetup (hd0)\n". So, it looks like the boot sector is bad, at least, that the boot sector doesn't work with my hardware. The above is really a simplified explanation. I had to fiddle quite a bit as I didn't have a boot disk handy, but I do have a second disk in the machine with a slightly out-of-date working image, with a valid grub boot sector, and a BIOS that lets me re-order my disks for booting and enumeration processes... :-) Anybody is staying on devel-latest may wish to watch out for grub-0.94.1. Have a boot disk handy, and keep a copy of grub-0.93-7.i386.rpm to restore from! 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 mharris at redhat.com Sat Feb 14 08:39:05 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 14 Feb 2004 03:39:05 -0500 (EST) Subject: XFree86 @devel vs @updates In-Reply-To: <1076740278.9970.4.camel@ByteEnable> References: <20040213220745.GA3503@nsk.no-ip.org> <1076740278.9970.4.camel@ByteEnable> Message-ID: On Sat, 14 Feb 2004, ByteEnable wrote: >You sound like you make releases on a whim and whenever you get >around to it. There is no sign off or test plan that you >follow? I surely hope that you are jesting. I'm not particularly sure where you draw those bogus conclusions from, nor that it is your business to do so. My workload, priorities, timetable/schedule, and plans are not of your personal concern however. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From hvdkooij at vanderkooij.org Sat Feb 14 08:40:46 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Sat, 14 Feb 2004 09:40:46 +0100 (CET) Subject: Firefox as default browser in Fedora In-Reply-To: <20040213233835.GA4476@nsk.no-ip.org> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> <1076714138.12310.1.camel@turtle.localdomain> <20040213233835.GA4476@nsk.no-ip.org> Message-ID: On Fri, 13 Feb 2004, Luciano Miguel Ferreira Rocha wrote: > On Fri, Feb 13, 2004 at 03:15:38PM -0800, Vincent wrote: > > > > If they did it by default that would mean they support it, which is not > > true. > > I'd thought a menu labelled "Unsuported Applications" would be enough. Sounds like you haven't done any real life customer support. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From lorenzo at reality.it Sat Feb 14 09:08:24 2004 From: lorenzo at reality.it (Lorenzo Luconi Trombacchi) Date: Sat, 14 Feb 2004 10:08:24 +0100 Subject: Grub and Segfaults on AMD64 Message-ID: <402DE588.4010900@reality.it> What about the Segmentation Faults message when execute grub command on x86_64 arch? I have just installed grub-0.94-1, but the problem persists. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112906 Lorenzo From ville.skytta at iki.fi Sat Feb 14 13:06:04 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 14 Feb 2004 15:06:04 +0200 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040214005319.6242aee5.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> Message-ID: <1076763963.9498.169.camel@bobcat.mine.nu> On Sat, 2004-02-14 at 01:53, Michael Schwendt wrote: > On Fri, 13 Feb 2004 23:00:00 +0200, Ville Skytt? wrote: > > > Further, it would be more "correct" process-wise if the initial package > > submission was the attachment. > > Which would also make it easier to find the most recent package in a > ticket. Scrolling up from the bottom to search for URLs in comments, which > announce an updated package, is not ideal. Right. > > Some stuff to check: > > - Is it possible to create a query that does not match attachment > > statuses for obsoleted attachments? > > Shouldn't be a problem since attachment statuses can be taken back, > if need be, and queries can be limited on "open" tickets. The drawback in taking back or resetting statuses is that it is extra work (not much) and causes useless mail traffic (this is a worse problem IMO). It'd be better if that could be avoided and the query would take care of it instead. > Much more feedback from the target group of these changes is necessary. Yep. But let's start experimenting with this stuff to get some hands-on experience how it feels. From de_lupus at pandora.be Sat Feb 14 13:50:59 2004 From: de_lupus at pandora.be (Kristof vansant) Date: Sat, 14 Feb 2004 14:50:59 +0100 Subject: I found 2 packages that put a .pc file in /usr/share/pkgconfig/ Message-ID: <1076766658.22622.1.camel@D5E03ED8.kabel.telenet.be> I found 2 packages that put a .pc file in /usr/share/pkgconfig/ I think pkgconfig only uses /usr/lib/pkgtool/ I thought? Bug or not? [root at d5e03ed8 lupus]# cd /usr/share/pkgconfig/ [root at d5e03ed8 pkgconfig]# ls gnome-icon-theme.pc gtk-doc.pc [root at d5e03ed8 pkgconfig]# rpm -qf gnome-icon-theme.pc gnome-icon-theme-1.1.5-1 [root at d5e03ed8 pkgconfig]# rpm -qf gtk-doc.pc gtk-doc-1.1-3.1 [root at d5e03ed8 pkgconfig]# Lupus (Kristof Vansant Belgium) From strange at nsk.no-ip.org Sat Feb 14 14:33:33 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 14 Feb 2004 14:33:33 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> <1076714138.12310.1.camel@turtle.localdomain> <20040213233835.GA4476@nsk.no-ip.org> Message-ID: <20040214143333.GA2236@nsk.no-ip.org> On Sat, Feb 14, 2004 at 09:40:46AM +0100, Hugo van der Kooij wrote: > On Fri, 13 Feb 2004, Luciano Miguel Ferreira Rocha wrote: > > > On Fri, Feb 13, 2004 at 03:15:38PM -0800, Vincent wrote: > > > > > > If they did it by default that would mean they support it, which is not > > > true. > > > > I'd thought a menu labelled "Unsuported Applications" would be enough. > > Sounds like you haven't done any real life customer support. No, I haven't. Still, fedora's lists are constantly bombarded with questions about unsupported software. Not much would change, eh? Regards, Luciano Rocha From buildsys at redhat.com Sat Feb 14 15:08:35 2004 From: buildsys at redhat.com (Build System) Date: Sat, 14 Feb 2004 10:08:35 -0500 Subject: rawhide report: 20040214 changes Message-ID: <200402141508.i1EF8ZN17969@porkchop.devel.redhat.com> Updated Packages: From skvidal at phy.duke.edu Sat Feb 14 17:58:30 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 14 Feb 2004 12:58:30 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <20040214024013.GA26270@devserv.devel.redhat.com> References: <20040210215221.GT1556@angus.ind.WPI.EDU> <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> <1076725743.13049.18.camel@binkley> <20040214024013.GA26270@devserv.devel.redhat.com> Message-ID: <1076781510.13049.35.camel@binkley> > Put the path in DNS too or a defined short form > > then its query fedora-2-test1.foobar.org txt > > > Is there a good place to look for how the dns txt information is being > > more commonly used? > > Rendezvous (DNS-SD) > http://www.zeroconf.org/Rendezvous/txtrecords.html > > RFC1464 (overview) > > DNS RBL (txt records explain why the block exists) This sounds cool, though I must admit the involvement with someone's dns admin will have to be a lot greater. You'd have to update this data any time a package changed. Would you be willing to come up with a spec on how you think apt/yum/ up2date/redcarpet/etc should access this data? I'm going to have to admit being a bit intimidated by the complexities here. -sv From cra at WPI.EDU Sat Feb 14 18:21:50 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 14 Feb 2004 13:21:50 -0500 Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <1076781510.13049.35.camel@binkley> References: <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> <1076725743.13049.18.camel@binkley> <20040214024013.GA26270@devserv.devel.redhat.com> <1076781510.13049.35.camel@binkley> Message-ID: <20040214182150.GA22046@angus.ind.WPI.EDU> On Sat, Feb 14, 2004 at 12:58:30PM -0500, seth vidal wrote: > This sounds cool, though I must admit the involvement with someone's dns > admin will have to be a lot greater. You'd have to update this data any > time a package changed. Dynamic DNS would help in this regard. From dirk.wendland at nexgo.de Sat Feb 14 18:28:18 2004 From: dirk.wendland at nexgo.de (Dirk Wendland) Date: Sat, 14 Feb 2004 19:28:18 +0100 Subject: G++ In-Reply-To: <20040214182150.GA22046@angus.ind.WPI.EDU> References: <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> <1076725743.13049.18.camel@binkley> <20040214024013.GA26270@devserv.devel.redhat.com> <1076781510.13049.35.camel@binkley> <20040214182150.GA22046@angus.ind.WPI.EDU> Message-ID: <1076783297.2955.3.camel@Internetpc> Hello I??m working on my own development tool. On an Intel CPU g++ works well but on an AMD DURON CPU there are for several times Memory failures from g++. Had anybody the same Problems ? I??m working with Fedora 1 AMD DURON 800MHZ 256 MB RAM. Greetings -- Dirk Wendland homepage:www.develop.if2.de mail:dirk.wendland at nexgo.de working on:Develop a development tool for html|php|c++|java|OpenGL From surak at casa.surak.eti.br Sat Feb 14 18:37:48 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Sat, 14 Feb 2004 15:37:48 -0300 Subject: Fedora site and lists Message-ID: <1076783868.10172.22.camel@casa> I don't know if fedora-devel is the right place to discuss this, but seems it is. The thing is: it's not easy to search for anything on fedora-lists (and redhat in general). If you go to fedora.redhat.com, you have to crawl to participate, communicate, fedora-list and then fedora-archive links. Preety much clicks for an newbie search why that video card won't start X on fedora install. Besides that, there's a "search red hat" on the top of every page, and looking on it does not seem to produce very much relevant results, as every page returns something as unuseful as "Red Hat -- Linux, Embedded Linux and Open Source Solutions"... I'm speaking for several people, which are not that dumb, but just are not able to find the answers for their doubts. -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From jaap at haitsma.org Sat Feb 14 18:36:50 2004 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Sat, 14 Feb 2004 19:36:50 +0100 Subject: Are there any new packages in FC 2 test 1 Message-ID: <402E6AC2.7070300@haitsma.org> Hi, I was wondering if there are any new packages (so not counting updates) in FC 2 test 1 compared to FC 1. Can't find it on the website. Jaap From mark at talios.com Sat Feb 14 18:43:28 2004 From: mark at talios.com (Mark Derricutt) Date: Sun, 15 Feb 2004 07:43:28 +1300 Subject: Firefox as default browser in Fedora In-Reply-To: <1076714138.12310.1.camel@turtle.localdomain> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> <1076714138.12310.1.camel@turtle.localdomain> Message-ID: <1076784208.5186.23.camel@localhost> On Sat, 2004-02-14 at 12:15, Vincent wrote: > If they did it by default that would mean they support it, which is not > true. Ages ago I was thinking having all these known "certified" 3rd party repositories included in the main yum.conf from core, but dissabled, with a GUI config program that enabled/disabled the other repositories. Then, a new user could simply be told "run package-config and enable Planet CCRMA, then install xxxxx like this". From teg at pvv.org Sat Feb 14 18:50:16 2004 From: teg at pvv.org (=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?=) Date: Sat, 14 Feb 2004 19:50:16 +0100 Subject: G++ In-Reply-To: <1076783297.2955.3.camel@Internetpc> References: <1076453321.15803.52.camel@opus> <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> <1076725743.13049.18.camel@binkley> <20040214024013.GA26270@devserv.devel.redhat.com> <1076781510.13049.35.camel@binkley> <20040214182150.GA22046@angus.ind.WPI.EDU> <1076783297.2955.3.camel@Internetpc> Message-ID: <402E6DE8.3020704@pvv.org> Dirk Wendland wrote: >Hello > >I??m working on my own development tool. On an Intel CPU g++ works well >but on an AMD DURON CPU there are for several times Memory failures from >g++. Had anybody the same Problems ? I??m working with Fedora 1 AMD DURON >800MHZ 256 MB RAM. > > I'd suggest you run "mentest" on your system, segmentation errors on the compiler are usually a sign of a broken/marginally working system. Unless it's always on the same line in the code you're compiling, that is. From ottohaliburton at comcast.net Sat Feb 14 18:56:45 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Sat, 14 Feb 2004 12:56:45 -0600 Subject: G++ In-Reply-To: <1076783297.2955.3.camel@Internetpc> Message-ID: <000a01c3f32c$4b87fde0$13c7ac43@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Dirk Wendland > Sent: Saturday, February 14, 2004 12:28 PM > To: fedora-devel-list at redhat.com > Subject: G++ > > Hello > > I??m working on my own development tool. On an Intel CPU g++ works well > but on an AMD DURON CPU there are for several times Memory failures from > g++. Had anybody the same Problems ? I??m working with Fedora 1 AMD DURON > 800MHZ 256 MB RAM. > > Greetings > > -- > Dirk Wendland > homepage:www.develop.if2.de > mail:dirk.wendland at nexgo.de > working on:Develop a development tool for html|php|c++|java|OpenGL > > whip out the manual, I thought there was a switch for amd but I haven't looked at the manual is so long I maybe wrong. From strange at nsk.no-ip.org Sat Feb 14 19:49:21 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 14 Feb 2004 19:49:21 +0000 Subject: dbus-0.20.2 vs cups-1.1.20-3 Message-ID: <20040214194921.GA6836@nsk.no-ip.org> Hello, I've just upgraded my system to latest development packages, and afterwards the dbus system refused to start, complaining about "Failed to start message bus: Attribute "send" is invalid on element in this context" I tracked the offending element to /etc/dbus-1/system.d/cups.conf (the error message _could_ be a little more informative), and I fixed the error by changing "send=" to "send_destination=" and "receive=" to "receive_sender=". I don't know if those are the correct changes, but it seemed so from the dbus' configuration files. Regards, Luciano Rocha From strange at nsk.no-ip.org Sat Feb 14 20:01:13 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 14 Feb 2004 20:01:13 +0000 Subject: dbus-0.20.2 vs cups-1.1.20-3 In-Reply-To: <20040214194921.GA6836@nsk.no-ip.org> References: <20040214194921.GA6836@nsk.no-ip.org> Message-ID: <20040214200113.GA7083@nsk.no-ip.org> On Sat, Feb 14, 2004 at 07:49:21PM +0000, Luciano Miguel Ferreira Rocha wrote: > > Hello, > > I've just upgraded my system to latest development packages, and afterwards > the dbus system refused to start, complaining about > "Failed to start message bus: Attribute "send" is invalid on element > in this context" > > I tracked the offending element to /etc/dbus-1/system.d/cups.conf (the error > message _could_ be a little more informative), and I fixed the error by > changing "send=" to "send_destination=" and "receive=" to "receive_sender=". > > I don't know if those are the correct changes, but it seemed so from the > dbus' configuration files. > Already updated on cups-1.1.20-4. My mirror didn't have it by I found it on fedora's site. Regards, Luciano Rocha From pros-n-cons at bak.rr.com Sat Feb 14 21:45:24 2004 From: pros-n-cons at bak.rr.com (Vincent) Date: Sat, 14 Feb 2004 13:45:24 -0800 Subject: Firefox as default browser in Fedora In-Reply-To: <1076784208.5186.23.camel@localhost> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> <1076714138.12310.1.camel@turtle.localdomain> <1076784208.5186.23.camel@localhost> Message-ID: <1076795124.13766.7.camel@turtle.localdomain> On Sat, 2004-02-14 at 10:43, Mark Derricutt wrote: > On Sat, 2004-02-14 at 12:15, Vincent wrote: > > > If they did it by default that would mean they support it, which is not > > true. > > Ages ago I was thinking having all these known "certified" 3rd party > repositories included in the main yum.conf from core, but dissabled, > with a GUI config program that enabled/disabled the other repositories. > > Then, a new user could simply be told "run package-config and enable > Planet CCRMA, then install xxxxx like this". > > In a way that holds true. Go to the Fedora FAQ, download the yum.conf and uncomment [livna-stable] and [dag] repositories. then yum -y install foo-plugin etc. This seems easier to me than going though a wizard, I don't see what all the noise is about. From strange at nsk.no-ip.org Sat Feb 14 22:09:18 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 14 Feb 2004 22:09:18 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <1076795124.13766.7.camel@turtle.localdomain> References: <1076701988.3113.42.camel@spatula.pppl.gov> <1076702436.5051.5.camel@maranello.jeamland.ca> <1076708165.13573.1.camel@turtle.localdomain> <20040213225324.GB3822@nsk.no-ip.org> <1076714138.12310.1.camel@turtle.localdomain> <1076784208.5186.23.camel@localhost> <1076795124.13766.7.camel@turtle.localdomain> Message-ID: <20040214220918.GA7906@nsk.no-ip.org> On Sat, Feb 14, 2004 at 01:45:24PM -0800, Vincent wrote: > On Sat, 2004-02-14 at 10:43, Mark Derricutt wrote: > > On Sat, 2004-02-14 at 12:15, Vincent wrote: > > > > > If they did it by default that would mean they support it, which is not > > > true. > > > > Ages ago I was thinking having all these known "certified" 3rd party > > repositories included in the main yum.conf from core, but dissabled, > > with a GUI config program that enabled/disabled the other repositories. > > > > Then, a new user could simply be told "run package-config and enable > > Planet CCRMA, then install xxxxx like this". > > > > > > In a way that holds true. Go to the Fedora FAQ, download the yum.conf > and uncomment [livna-stable] and [dag] repositories. then yum -y install > foo-plugin etc. This seems easier to me than going though a wizard, I > don't see what all the noise is about. I'd be more happy if that information, or a link to the FAQ, was available at installation time. I haven't gone through an installatation lately so I don't know if there's such an info on FC installs. I'd be even more happy for the wizard. Not for me, as I don't even use gnome, but for those new to the distribution. But I didn't intend on making noise, so I'll just shut up. Regards, Luciano Rocha From jspaleta at princeton.edu Sat Feb 14 22:36:10 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Sat, 14 Feb 2004 17:36:10 -0500 Subject: Firefox as default browser in Fedora Message-ID: <1076798170.9503.12.camel@goober.localdomain> Luciano Miguel Ferreira Rocha wrote: > I'd be more happy if that information, or a link to the FAQ, was > available at installation time. I haven't gone through an > installatation lately so I don't know if there's such an info on FC > installs. I seriously doubt this will happen ever... I seriously doubt that ANY mention of specific 3rd party repositories will be included in any install time documentation or any instructions that come as part of Fedora Core. There are several reasons I could argue. but I'll stay away from commenting on the legality of providing information or links to repositories containing software that is affected by the DMCA in the united states. I doubt few here are qualified and informed enough about the scope of the legal issues surrounding the DMCA to have a constructive conversation about the liabilities involved. Frankly it's not worth arguing about, because legal hurdles are not subject to the whim of public opinion. Let me instead say, that personally, I don't think its appropriate to single out a few 3rd party repositories for inclusion in a default config file. I think 3rd party repositories have to build their own brand and name recognition, and I don't think its appropriate for Fedora Core to comment on which 3rd party repos are of value by placing them in the default configs. Instead, maybe there is a way to build a process by which it is easy for users to go to a repository website, click a single link, or drag and drop a link, to configure a new repository. -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 strange at nsk.no-ip.org Sat Feb 14 22:58:21 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 14 Feb 2004 22:58:21 +0000 Subject: Firefox as default browser in Fedora In-Reply-To: <1076798170.9503.12.camel@goober.localdomain> References: <1076798170.9503.12.camel@goober.localdomain> Message-ID: <20040214225821.GA8030@nsk.no-ip.org> On Sat, Feb 14, 2004 at 05:36:10PM -0500, Jef Spaleta wrote: > Luciano Miguel Ferreira Rocha wrote: > > I'd be more happy if that information, or a link to the FAQ, was > > available at installation time. I haven't gone through an > > installatation lately so I don't know if there's such an info on FC > > installs. > > I seriously doubt this will happen ever... > I seriously doubt that ANY mention of specific 3rd party repositories > will be included in any install time documentation or any instructions > that come as part of Fedora Core. > > There are several reasons I could argue. but I'll stay away from > commenting on the legality of providing information or links to > repositories containing software that is affected by the DMCA in the > united states. I doubt few here are qualified and informed enough about > the scope of the legal issues surrounding the DMCA to have a > constructive conversation about the liabilities involved. Frankly it's > not worth arguing about, because legal hurdles are not subject to the > whim of public opinion. > > Let me instead say, that personally, I don't think its appropriate to > single out a few 3rd party repositories for inclusion in a default > config file. I think 3rd party repositories have to build their own > brand and name recognition, and I don't think its appropriate for Fedora > Core to comment on which 3rd party repos are of value by placing them in > the default configs. > > Instead, maybe there is a way to build a process by which it is easy for > users to go to a repository website, click a single link, or drag and > drop a link, to configure a new repository. > > -jef Actually, my first thought and writing wasn't about repositories, but installares that would fetch the binaries from the vendors' sites. Would _that_ infringe on the DMCA? It could be difficult to maintain, due to site changes and version updates, but there could be a site with instructions for some software about how to get the files and install it. Had I more time and this discussion not started, I would hade made a proof of concept and presented it for discussion, but almost all responses I got were negative about other things: against existance of a "unsuported apps" menu, that could confound people to think they were supported; against repositores; against information on install time documentation about faqs or repositories or 3rd party files. If people are so opposed to the ideia then I'll leave it at that. Regards, Luciano Rocha From alan at redhat.com Sun Feb 15 00:06:32 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 14 Feb 2004 19:06:32 -0500 Subject: G++ In-Reply-To: <1076783297.2955.3.camel@Internetpc> References: <1076713501.12133.2.camel@wombat.tiptoe.de> <1076720560.13049.4.camel@binkley> <20040214011507.GA7506@devserv.devel.redhat.com> <1076722655.13049.11.camel@binkley> <20040214020244.GA20715@devserv.devel.redhat.com> <1076725743.13049.18.camel@binkley> <20040214024013.GA26270@devserv.devel.redhat.com> <1076781510.13049.35.camel@binkley> <20040214182150.GA22046@angus.ind.WPI.EDU> <1076783297.2955.3.camel@Internetpc> Message-ID: <20040215000632.GA26538@devserv.devel.redhat.com> On Sat, Feb 14, 2004 at 07:28:18PM +0100, Dirk Wendland wrote: > I??m working on my own development tool. On an Intel CPU g++ works well > but on an AMD DURON CPU there are for several times Memory failures from > g++. Had anybody the same Problems ? I??m working with Fedora 1 AMD DURON > 800MHZ 256 MB RAM. If you get random crashes rather than a predictable crash in the same spot then see the SIG11 FAQ - its almost certainly memory or CPU problems. Gcc/g++ just happen to be superb system stress testers From mitr at volny.cz Sun Feb 15 01:55:10 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Sun, 15 Feb 2004 02:55:10 +0100 Subject: I found 2 packages that put a .pc file in /usr/share/pkgconfig/ In-Reply-To: <1076766658.22622.1.camel@D5E03ED8.kabel.telenet.be> References: <1076766658.22622.1.camel@D5E03ED8.kabel.telenet.be> Message-ID: <20040215015510.GB1890@popelka.ms.mff.cuni.cz> On Sat, Feb 14, 2004 at 02:50:59PM +0100, Kristof vansant wrote: > I found 2 packages that put a .pc file in /usr/share/pkgconfig/ > I think pkgconfig only uses /usr/lib/pkgtool/ I thought? > > Bug or not? No, the pkgconfig in FC looks also in /usr/share/pkgconfig. This is needed for noarch packages (like gtk-doc and gnome-icon-theme). With the old setup a gtk-doc package built on AMD64 would have the .pc file in /usr/lib64, which is wrong when this (noarch) package is installed on i386. Mirek From riel at redhat.com Sun Feb 15 04:04:21 2004 From: riel at redhat.com (Rik van Riel) Date: Sat, 14 Feb 2004 23:04:21 -0500 (EST) Subject: I was wondering why fedora has choosen yum over apt-get In-Reply-To: <20040214011507.GA7506@devserv.devel.redhat.com> Message-ID: On Fri, 13 Feb 2004, Alan Cox wrote: > Is the repomd data small enough that you can also stick it in DNS TXT > records so that you can use the domain name service as a global cache > for keeping lookup costs down ? If we're worried about security, keep DNSSEC in mind. Do any of the registrars and/or root servers support it already ? -- "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 cturner at redhat.com Sun Feb 15 04:48:20 2004 From: cturner at redhat.com (Chip Turner) Date: 14 Feb 2004 23:48:20 -0500 Subject: Perl requires/provides proposal Message-ID: The problem: It's not always obvious what perl RPMs under which an RPM containing perl modules can run. Perl itself is generally module-compatible inside of major revisions, but currently we don't build RPMs that have strong dependencies enforcing this (and protecting from installing modules under different versions of perl). Currently some perl modules have requires on the perl NVRE they want but this requires manual intervention and epoch-awareness, which is not always programmatically doable. Proposed solution: All future perl packages will contain new provides in the perl() namespace to specify both the modules they can run as well as the embedded environments they provide. All future perl modules will contain similar requires. Currently, all perl modules and the perl package itself have sets of Perl provides and requires that are "namespaced." These dependencies look like perl(FOO) where FOO is a module name, or perl(:BAR) where :BAR is a tag made up by me that means something to me. Currently the :BAR style tags are used for things that break binary compatibilty (check "rpm -q perl --provides | grep 'perl(:'" -- things like threading module, perlio, etc show up). So the plan is to add perl(:MODULE-COMPAT-5.8.3) (and 5.8.2, 5.8.1, and 5.8.0) as Provides to the perl package itself, and add this equivalent to any perl module: perl(:MODULE-COMPAT-$(perl -MConfig -e 'print $Config{version}')). In other words, a module, when compiled, will require the :MODULE-COMPAT tag of the version of perl it was compiled under. Also, the perl module itself will explicitly own all dirs listed in its @INC list. Some perl modules have requires on these dirs to solve the problem above, and this would make those modules work, but that's not really the right solution, hence the need for a more "official" expression of the dependencies involved. Thoughts? Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From ms-nospam-0306 at arcor.de Sun Feb 15 05:11:26 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 15 Feb 2004 06:11:26 +0100 Subject: Perl requires/provides proposal In-Reply-To: References: Message-ID: <20040215061126.013c5490.ms-nospam-0306@arcor.de> On 14 Feb 2004 23:48:20 -0500, Chip Turner wrote: > So the plan is to add perl(:MODULE-COMPAT-5.8.3) (and 5.8.2, 5.8.1, > and 5.8.0) as Provides to the perl package itself, and add this > equivalent to any perl module: perl(:MODULE-COMPAT-$(perl -MConfig -e > 'print $Config{version}')). In other words, a module, when compiled, > will require the :MODULE-COMPAT tag of the version of perl it was > compiled under. In which way would this be different from making a Perl module depend on a path like "eval $(perl -V:vendorlib) && echo $vendorlib"? In both cases you would get an explicit versioned dependence. And for the Perl module package to be compatible with the main Perl package, the former would depend on a specific version+path provided and supported by the latter. > Also, the perl module itself will explicitly own all dirs listed in > its @INC list. Looks like a type mistake. I think it should read: Also, the perl package itself will explicitly own all dirs listed in its @INC list. > Some perl modules have requires on these dirs to solve > the problem above, and this would make those modules work, but that's > not really the right solution, hence the need for a more "official" > expression of the dependencies involved. > > Thoughts? What makes a dependence on a specific path from @INC less right than an explicit dependence on a versioned virtual capability? -- From cturner at redhat.com Sun Feb 15 05:27:06 2004 From: cturner at redhat.com (Chip Turner) Date: 15 Feb 2004 00:27:06 -0500 Subject: Perl requires/provides proposal In-Reply-To: <20040215061126.013c5490.ms-nospam-0306@arcor.de> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> Message-ID: Michael Schwendt writes: > On 14 Feb 2004 23:48:20 -0500, Chip Turner wrote: > > > So the plan is to add perl(:MODULE-COMPAT-5.8.3) (and 5.8.2, 5.8.1, > > and 5.8.0) as Provides to the perl package itself, and add this > > equivalent to any perl module: perl(:MODULE-COMPAT-$(perl -MConfig -e > > 'print $Config{version}')). In other words, a module, when compiled, > > will require the :MODULE-COMPAT tag of the version of perl it was > > compiled under. > > In which way would this be different from making a Perl module depend on a > path like "eval $(perl -V:vendorlib) && echo $vendorlib"? In both cases > you would get an explicit versioned dependence. And for the Perl module > package to be compatible with the main Perl package, the former would > depend on a specific version+path provided and supported by the latter. Well, as Warren showed, this can break if another module provides that directory (which can happen from a third part perl module, or even one of our own). Also, the dependency we're trying to express is 'hello, I'm a module, and I require a perl interpreter that can run a perl 5.8.3 module compiled with ithreads and perlio' not 'hello, I'm a module and I need any rpm that contains some specific directory'. I'd like there to be semantic meaning for the dependency above simply asserting directory existence. Plus I don't like the idea of a non-vendor provided perl module requiring vendorlib; it should require the lib of the target build type (ie, site, vendor, or core). Both approaches would work pretty mcuh equally in practice, but sticking with the perl namespace approach lets us extend it later (such as handling packages that embed perl, or some new perl compile option that breaks binary compatibility). > > Also, the perl module itself will explicitly own all dirs listed in > > its @INC list. > > Looks like a type mistake. I think it should read: > > Also, the perl package itself will explicitly own all dirs listed in > its @INC list. Indeed, good catch. > > Some perl modules have requires on these dirs to solve > > the problem above, and this would make those modules work, but that's > > not really the right solution, hence the need for a more "official" > > expression of the dependencies involved. > > > > Thoughts? > > What makes a dependence on a specific path from @INC less right than > an explicit dependence on a versioned virtual capability? The semantic meaning of the virtual capability vs the simple file system assertion of a file/directory dependency (pretty much covered above). Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From ms-nospam-0306 at arcor.de Sun Feb 15 06:04:08 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 15 Feb 2004 07:04:08 +0100 Subject: Perl requires/provides proposal In-Reply-To: References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> Message-ID: <20040215070408.6abfad99.ms-nospam-0306@arcor.de> On 15 Feb 2004 00:27:06 -0500, Chip Turner wrote: > Well, as Warren showed, this can break if another module provides that > directory (which can happen from a third part perl module, or even one > of our own). Ah, yes, I've had eliminated that from memory already. :) (though, 3rd party perl modules should not pollute a build environment) Dependence on a virtual capability is less likely to break, of course, if the virtual capability is well-maintained. E.g. when you create some of the virtual provides by examining @INC automatically. Perl 5.6.1 would not search in 5.6.0 site/vendor locations, for instance. > Also, the dependency we're trying to express is 'hello, > I'm a module, and I require a perl interpreter that can run a perl > 5.8.3 module compiled with ithreads and perlio' not 'hello, I'm a > module and I need any rpm that contains some specific directory'. I'd > like there to be semantic meaning for the dependency above simply > asserting directory existence. Yes. I was still focusing on the availability on vendor/site directories in the perl package when they are in @INC, too. > Plus I don't like the idea of a non-vendor provided perl module > requiring vendorlib; it should require the lib of the target build > type (ie, site, vendor, or core). So true. Interestingly, $sitelib has been included within the main perl package for a long time. Unlike $vendorlib. So, only perl modules which install into vendor locations have had the need to find another way on how to depend on the main perl package. -- From mharris at redhat.com Sun Feb 15 06:51:17 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 15 Feb 2004 01:51:17 -0500 (EST) Subject: XFree86: New via driver with DRI Message-ID: I have updated the "via" video driver in XFree86-4.3.0-56 in rawhide with Alan Cox's latest driver. The new driver has DRI support however a typo in the spec file caused the DRI driver not to get built in 4.3.0-56, so only the new 2D driver is present in this build. The next build which fixes the typo, 4.3.0-57 is currently being built, and should contain the via DRI 3D driver unless something else goes wrong. ;o) I'm going to sleep so wont be babysitting the build, nor doublechecking the packages for sanity before tomorrow sometime. Welcome to RAWhide. ;o) Please test the new XFree86 build out on via hardware, and report any problems in bugzilla. DRI support requires that you be running the latest Fedora development kernel. I don't know if the Fedora Core 1 or RHL 9 kernels have the via DRM module in them or not. If not - nag davej. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From warren at togami.com Sun Feb 15 08:11:22 2004 From: warren at togami.com (Warren Togami) Date: Sat, 14 Feb 2004 22:11:22 -1000 (HST) Subject: Perl requires/provides proposal In-Reply-To: <20040215070408.6abfad99.ms-nospam-0306@arcor.de> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> <20040215070408.6abfad99.ms-nospam-0306@arcor.de> Message-ID: <39256.66.91.85.198.1076832682.squirrel@togami.com> > On 15 Feb 2004 00:27:06 -0500, Chip Turner wrote: > >> Well, as Warren showed, this can break if another module provides that >> directory (which can happen from a third part perl module, or even one >> of our own). > > Ah, yes, I've had eliminated that from memory already. :) > (though, 3rd party perl modules should not pollute a build environment) > > Dependence on a virtual capability is less likely to break, of course, if > the virtual capability is well-maintained. E.g. when you create some of > the virtual provides by examining @INC automatically. Perl 5.6.1 would not > search in 5.6.0 site/vendor locations, for instance. > Should we leave the existing fedora.us Extras as-is, or should we provide maybe a "perl-virtual" package that provides the equivalent virtual provides as this new standard for FC2. That way all perl modules from now on can have theoretical compatibility and exact Requires, completely avoiding these ugly hacks of requiring a directory. Thoughts? Warren From jfm512 at free.fr Sun Feb 15 09:22:12 2004 From: jfm512 at free.fr (Jean Francois Martinez) Date: 15 Feb 2004 10:22:12 +0100 Subject: YUM's shortcomings Message-ID: <1076836918.1174.29.camel@agnes.fremen.dune> Yum has for now two serious shortcomings 1) It has no browser, even a curses based one. You cannot, like with apt or urpmi, browse what is available, select what you are interested in and have it installed 2) It does not deal with removable media. Unlike what happens with apt or urpmi it will not prompt you for the CD containing what you need. End result is that, since I have ADSL I often end downloading packages I have on CD and I am not happy about it. Copying everything on hard disk is a possibility but there are still plenty of boxes with 5 to 10 G disks where using 20% or more of disk space for keeping packages is not an option. And plenty of people who have huge disks (80g or more) and who are psychogically disturbed about keeping whole distros on disk. The problem of the huge download of headers is a PITA who only happens once. The two problems I mentionned happen every day. Atre there any plans to fix them? -- Jean Francois Martinez From warren at togami.com Sun Feb 15 09:54:05 2004 From: warren at togami.com (Warren Togami) Date: Sat, 14 Feb 2004 23:54:05 -1000 Subject: Some status stuff, and transition of fedora.us list Message-ID: <402F41BD.6090203@togami.com> As the fedora.us Extras merger with fedora.redhat.com draws nearer, I believe we should move all discussion to fedora-devel-list at redhat.com list rather than continue on fedora-devel at fedora.us. The old list has served us well for the past year, but I believe it will help to focus all efforts on the new list. fedora-announce at fedora.us will continue to operate for announcements of new fedora.us package releases. fedora.us will continue to accept FC1 and FC1.90 packages for Extras inclusion. Later fedora.us will go into pure maintenance mode, existing only to support fedora.us Extras FC1 and earlier, and some infrastructure for the Fedora Legacy project. The old Extras will be maintained in bugzilla.fedora.us and fedora-devel-list at redhat.com as long as the community developers still care about those packages. 1.90 is only temporarily at fedora.us mainly as a staging area for importing to fedora.redhat.com Extras CVS when it goes online. http://advogato.org/person/wtogami/ I wrote some more notes and random other stuff in my new blog here. The goal is for the FC1 to FC1.90 rebuilt packages, fixed packages, and a few more inclusions for Extras are to be imported into the CVS server when it goes online "soon". I do not know how soon. Please do not wait for the CVS. Continue submitting stuff to bugzilla.fedora.us. Fix and QA the packages already there. The stuff already published at fedora.us stuff will probably be imported first, and developer track records there taken into consideration for "who to trust sooner" with CVS access to certain package ACL's. (Of course many other well known developers in the community will be given access quickly if they follow the legal forms and other requirements that will posted when it goes live.) It is my personal goal to have the CVS and new infrastructure being built at fedora.redhat.com to accelerate development and lower time overhead, without lowering the bar of quality that fedora.us has achieved during the past year. More and better tools will need to be written for automated package tests, GPG signing/checking requirements, and other stuff in order to make these otherwise boring matters of procedure seemless and quick for developers. https://bugzilla.redhat.com/bugzilla-devel/ While on that subject, I realized I forgot to mention this earlier. dkl has setup a non-production Bugzilla here where we can test Bugzilla concepts, and perhaps more importantly, safely test XML-RPC interfaces of command-line tools like the stuff ESR was working on. I am personally not fully convinced that such tools will be effective, but I am interested to see working code prove the concept. Otherwise... kill those FC2 bugs. The 2.6 GNOME and kernel will be HUGE for us as a community in so many ways. With your help, let us make this the most awesome release ever. Warren "little more than a cheerleader" Togami From ms-nospam-0306 at arcor.de Sun Feb 15 11:17:49 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 15 Feb 2004 12:17:49 +0100 Subject: Perl requires/provides proposal In-Reply-To: <39256.66.91.85.198.1076832682.squirrel@togami.com> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> <20040215070408.6abfad99.ms-nospam-0306@arcor.de> <39256.66.91.85.198.1076832682.squirrel@togami.com> Message-ID: <20040215121749.202c4c78.ms-nospam-0306@arcor.de> On Sat, 14 Feb 2004 22:11:22 -1000 (HST), Warren Togami wrote: > Should we leave the existing fedora.us Extras as-is, or should we provide > maybe a "perl-virtual" package that provides the equivalent virtual > provides as this new standard for FC2. That way all perl modules from now > on can have theoretical compatibility and exact Requires, completely > avoiding these ugly hacks of requiring a directory. > > Thoughts? Sounds good. Let's touch them when the time has come. The perl module packages in fedora.us should be pretty stable upgrade-wise, since they don't depend on a specific Perl version (except for automated sanity related deps like perl >= 0:5.005). But for update packages to be modified and prepared for FC 1.90, we should no longer include "unowned" vendor/site/multi directories, even if the updated package will create unowned directories on FC1. As soon as a new perl core package is available, which provides the necessary virtual capabilities as Chip Turner has explained, we could simulate it with a meta-package for FC1 to benefit from being able to build the same src.rpm for multiple releases of FC and increase the dependencies of noarch.rpms. We could make such a package include the unowned Perl directories, too. -- From alexl at stofanet.dk Sun Feb 15 12:20:54 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Sun, 15 Feb 2004 13:20:54 +0100 Subject: yum upgrade Message-ID: <1076847644.14851.0.camel@D40A32D9.rev.stofanet.dk> im trying to do a yum uprade but im getting this error: > Gathering header information file(s) from server(s) > Server: Fedora Core 1.90 - Development Tree > Finding updated packages > Downloading needed headers > Finding obsoleted packages > Traceback (most recent call last): > File "/usr/bin/yum", line 30, in ? > yummain.main(sys.argv[1:]) > File "/usr/share/yum/yummain.py", line 249, in main > obsoleting, obsoleted = clientStuff.returnObsoletes(HeaderInfo, rpmDBInfo, nulist) > File "/usr/share/yum/clientStuff.py", line 286, in returnObsoletes > rc = rpmUtils.compareEVR((e1, v1, r1), (obe, obv, obr)) > File "/usr/share/yum/rpmUtils.py", line 120, in compareEVR > rc = rpm.labelCompare((e1, v1, r1), (e2, v2, r2)) > rpm.error: Invalid version or release - possibly None > > what could be wrong > > Alex Leth From ville.skytta at iki.fi Sun Feb 15 13:38:49 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 15 Feb 2004 15:38:49 +0200 Subject: Perl requires/provides proposal In-Reply-To: <20040215121749.202c4c78.ms-nospam-0306@arcor.de> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> <20040215070408.6abfad99.ms-nospam-0306@arcor.de> <39256.66.91.85.198.1076832682.squirrel@togami.com> <20040215121749.202c4c78.ms-nospam-0306@arcor.de> Message-ID: <1076852329.9498.280.camel@bobcat.mine.nu> On Sun, 2004-02-15 at 13:17, Michael Schwendt wrote: > Sounds good. Let's touch them when the time has come. The perl module > packages in fedora.us should be pretty stable upgrade-wise, since they > don't depend on a specific Perl version (except for automated sanity > related deps like perl >= 0:5.005). But for update packages to be modified > and prepared for FC 1.90, we should no longer include "unowned" > vendor/site/multi directories, even if the updated package will create > unowned directories on FC1. As soon as a new perl core package is > available, which provides the necessary virtual capabilities as Chip > Turner has explained, we could simulate it with a meta-package for FC1 to > benefit from being able to build the same src.rpm for multiple releases of > FC and increase the dependencies of noarch.rpms. We could make such a > package include the unowned Perl directories, too. +1 From ville.skytta at iki.fi Sun Feb 15 14:00:09 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 15 Feb 2004 16:00:09 +0200 Subject: Perl requires/provides proposal In-Reply-To: References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> Message-ID: <1076853608.9498.303.camel@bobcat.mine.nu> On Sun, 2004-02-15 at 07:27, Chip Turner wrote: > Michael Schwendt writes: > > > On 14 Feb 2004 23:48:20 -0500, Chip Turner wrote: > > > > > So the plan is to add perl(:MODULE-COMPAT-5.8.3) (and 5.8.2, 5.8.1, > > > and 5.8.0) as Provides to the perl package itself, and add this > > > equivalent to any perl module: perl(:MODULE-COMPAT-$(perl -MConfig -e > > > 'print $Config{version}')). In other words, a module, when compiled, > > > will require the :MODULE-COMPAT tag of the version of perl it was > > > compiled under. [...] > Also, the dependency we're trying to express is 'hello, > I'm a module, and I require a perl interpreter that can run a perl > 5.8.3 module compiled with ithreads and perlio' not 'hello, I'm a > module and I need any rpm that contains some specific directory'. I'd > like there to be semantic meaning for the dependency above simply > asserting directory existence. All this sounds good, but the $(perl -MConfig -e 'print $Config{version}')) expression above does not cover the ithreads and perlio and friends cases. I think a special rpm macro generates the correct virtual dependency would be welcome if the dependency would cover other cases than just the version. For example: Requires: %{perl_module_compat} ...which would expand to something like Requires: perl(:MODULE_COMPAT-5.8.3-ithreads-perlio) This would make the dep generation easier and more robust. On the other hand, then it becomes an issue whether to use "perl" or "%{__perl}" or something else in the macro body. As long as it's the same thing which is fed to "perl Makefile.PL" or "%{__perl} Makefile.PL" things should be ok. Oh, and providing those meta compatibility packages for older perl package releases would be harder with the macro as there's no easy way to drop in new macros from a package (think no macros.d directory). This issue exists also even if there would be no special macro, and AFACIS the best that can be done would be to document and encourage packagers to use "%{__perl}" or "perl" or whatever consistently in both the dep generation and building the module. OTOH if the above macro would exist, it would be more important as the choice would already have been made in the macro body. This should also be consistent with the way the current %{perl_install*} variables are resolved, which currently use "perl" but I've posted a RFE: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115156 Further, the ithreads and perlio cases are irrelevant for quite a few pure Perl / noarch modules, and would add a "too strict" dependency on the target mother Perl package. IOW, it'd be (:MODULE-COMPAT-x.y.z-foo-bar) where a (:MODULE-COMPAT-x.y.z) would suffice. I don't know if this is something to worry about though. From skvidal at phy.duke.edu Sun Feb 15 14:09:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 15 Feb 2004 09:09:35 -0500 Subject: yum upgrade In-Reply-To: <1076847644.14851.0.camel@D40A32D9.rev.stofanet.dk> References: <1076847644.14851.0.camel@D40A32D9.rev.stofanet.dk> Message-ID: <1076854175.17242.48.camel@binkley> On Sun, 2004-02-15 at 13:20 +0100, Alex Thomsen Leth wrote: > im trying to do a yum uprade but im getting this error: > > It'd be useful to have more debugging information but if I had to guess I'd say you had some damaged entries in your rpmdb. -sv From skvidal at phy.duke.edu Sun Feb 15 14:13:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 15 Feb 2004 09:13:44 -0500 Subject: YUM's shortcomings In-Reply-To: <1076836918.1174.29.camel@agnes.fremen.dune> References: <1076836918.1174.29.camel@agnes.fremen.dune> Message-ID: <1076854423.17242.50.camel@binkley> On Sun, 2004-02-15 at 10:22 +0100, Jean Francois Martinez wrote: > Yum has for now two serious shortcomings > wrong list - take this to the yum mailing list - it's a lot more relevant there: info: https://lists.dulug.duke.edu/mailman/listinfo/yum/ -sv From mike at flyn.org Sun Feb 15 16:00:52 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 15 Feb 2004 10:00:52 -0600 Subject: Fedora build system Message-ID: <20040215160052.GA6505@imp.flyn.org> Does the amazing beast known as the Fedora Build System exist yet? If so, where does one find it? Fedora's Package Submission QAPolicy states: [...] Release Manager does ... 1. Send SRPM to build system. 2. Send resulting SRPM and RPMS to signing server. 3. Sign 4. Post candidate builds 5. Change bug status to RESOLVED PENDING [...] I don't know where to find this build system. I have only found an email from Warren to fedora-devel dated Nov 18, 2003 laying out the architecture of the system. Could someone clarify this portion of the release procedure? -- Mike :wq From nomis80 at nomis80.org Sun Feb 15 16:07:11 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Sun, 15 Feb 2004 11:07:11 -0500 Subject: Fedora build system In-Reply-To: <20040215160052.GA6505@imp.flyn.org> References: <20040215160052.GA6505@imp.flyn.org> Message-ID: <200402151107.11997.nomis80@nomis80.org> On February 15, 2004 11:00, W. Michael Petullo wrote: > [...] > Release Manager does ... > > 1. Send SRPM to build system. > 2. Send resulting SRPM and RPMS to signing server. > 3. Sign > 4. Post candidate builds > 5. Change bug status to RESOLVED PENDING > [...] > Could someone clarify this portion of the release procedure? You're not the Release Manager, someone else is. When you see that the bug status has been changed to RESOLVED PENDING that means that step is done. -- Simon Perreault -- http://nomis80.org From ville.skytta at iki.fi Sun Feb 15 16:13:31 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 15 Feb 2004 18:13:31 +0200 Subject: Fedora build system In-Reply-To: <20040215160052.GA6505@imp.flyn.org> References: <20040215160052.GA6505@imp.flyn.org> Message-ID: <1076861611.9498.328.camel@bobcat.mine.nu> On Sun, 2004-02-15 at 18:00, W. Michael Petullo wrote: > Does the amazing beast known as the Fedora Build System exist yet? If so, > where does one find it? See http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/ From buildsys at redhat.com Sun Feb 15 16:40:49 2004 From: buildsys at redhat.com (Build System) Date: Sun, 15 Feb 2004 11:40:49 -0500 Subject: rawhide report: 20040215 changes Message-ID: <200402151640.i1FGen510395@porkchop.devel.redhat.com> New package libdv Software decoder for DV format video. Updated Packages: XFree86-4.3.0-56 ---------------- * Sat Feb 14 2004 Mike A. Harris 4.3.0-56 - Happy VIAlentines Day Edition. Feel the love. - Updated the 'via' driver to latest driver from Alan Cox, which contains DRI support among other things. Only enabled for build_rawhide and build_psyche for the time being, until it has been adequately tested. - Added DevelDriDrivers to host.def with 'via' driver added, conditionalized to the with_via_dri_driver macro - Conditionalize with_via_driver to only build on x86 architecture - Added XFree86-4.3.0-i740-missing-symbol-vbeFree.patch to add a missing symbol to the i740 driver (#115676) - Built 4.3.0-56 with target build_rawhide for Fedora Core development * Thu Feb 12 2004 Mike A. Harris 4.3.0-55 - Added {x11datadir}/X11/xinit back to package list, which seems to have been inadvertently dropped during attempts to get package to compile on Red Hat Linux 9 s390 builds earlier this week. - Built 4.3.0-55 with target build_yarrow for Fedora Core 1 erratum - Built 4.3.0-55.EL with target build_taroon for Red Hat Enterprise Linux 3 erratum - Built 4.3.0-2.90.55 with target build_shrike for Red Hat Linux 9 erratum * Wed Feb 11 2004 Mike A. Harris 4.3.0-54 - Added XFree86-4.3.0-libXfont-security-CAN-2004-0083-CAN-2004-0084-CAN-2004-0106.patch to fix all recent security flaws in libXfont which are outlined in CAN-2004-0083, CAN-2004-0084, CAN-2004-0106, discovered by iDefense, David Dawes and others. This patch replace all previous libXfont patches from XFree86 builds 4.3.0-49 through to present. - Added XFree86-4.3.0-libXfont-security-CAN-2004-0083-CAN-2004-0084-CAN-2004-0106-v2.patch which is the same as the above patch, but modified to cleanly apply to 4.3.0, renamed to keep all patches present in src.rpm for comparative purposes. - Built 4.3.0-54 with target build_yarrow for Fedora Core 1 erratum - Built 4.3.0-54.EL with target build_taroon for Red Hat Enterprise Linux 3 erratum - Built 4.3.0-2.90.54 with target build_shrike for Red Hat Linux 9 erratum dvgrab-1.5-1 ------------ * Thu Feb 12 2004 Warren Togami 1.5-1 - upgrade to 1.5 - spec cleanups - remove INSTALL, TODO; Add NEWS - Now requires libdv, docs say it is much faster and better output than raw1394 - BuildRequires libraw1394-devel, libavc1394-devel, libdv-devel, libjpeg-devel, libpng-devel, libogg-devel, libvorbis-devel kdeaddons-3.2.0-1.4 ------------------- * Sat Feb 14 2004 Than Ngo 3.2.0-1.4 - fix rpm file list * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Than Ngo 3.2.0-0.3 - 3.2.0 release - built against qt 3.3.0 kdeadmin-3.2.0-1.3 ------------------ * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Than Ngo 7:3.2.0-0.3 - 3.2.0 release - build against qt 3.3.0 * Tue Jan 27 2004 Than Ngo 3.1.95-0.2 - cleanup specfile kdeartwork-3.2.0-1.3 -------------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Than Ngo 3.2.0-0.3 - 3.2.0 release - build against qt 3.3.0 kdebindings-3.2.0-1.3 --------------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Than Ngo 3.2.0-0.3 - 3.2.0 release - built against qt 3.3.0 kdeedu-3.2.0-1.3 ---------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Than Ngo 3.2.0-0.3 - 3.2.0 release - built against qt 3.3.0 kdegraphics-3.2.0-1.3 --------------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Than Ngo 7:3.2.0-0.3 - 3.2.0 release - built against qt 3.3.0 - add prereq /sbin/ldconfig kdenetwork-3.2.0-1.3 -------------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Sat Feb 07 2004 Than Ngo 3.2.0-0.3 - 3.2.0 release - built against qt-3.3.0 kdesdk-3.2.0-1.3 ---------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Sun Feb 08 2004 Than Ngo 2:3.2.0-0.3 - 3.2.0 release - built against qt-3.3.0 kdetoys-3.2.0-1.3 ----------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Sun Feb 08 2004 Than Ngo 3.2.0-0.3 - 3.2.0 release - built against qt 3.3.0 kdeutils-3.2.0-1.1 ------------------ * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Feb 11 2004 Than Ngo 6:3.2.0-0.1 - 3.2.0 release - built against qt 3.3.0 kdevelop-3.0.0-1.3 ------------------ * Fri Feb 13 2004 Elliot Lee - rebuilt * Sun Feb 08 2004 Than Ngo 9:3.0.0-0.3 - 3.2.0 release - built against qt-3.3.0 kernel-2.6.2-1.81 ----------------- * Sat Feb 14 2004 Dave Jones - Update to 2.6.3-rc2-bk4 koffice-1.3-4 ------------- * Sat Feb 14 2004 Than Ngo 4:1.3-4 - rebuilt against qt 3.3.0 * Fri Feb 13 2004 Elliot Lee - rebuilt less-382-1 ---------- * Sat Feb 14 2004 Karsten Hopp 382-1 - new upstream version * Fri Feb 13 2004 Elliot Lee - rebuilt libavc1394-0.4.1-1 ------------------ * Thu Feb 12 2004 Warren Togami 0.4.1-1 - upgrade to 0.4.1 - Spec cleanups - License -> Copyright - Remove INSTALL; Add News, ChangeLog - Applications/Multimedia -> System Environment/Libraries libraw1394-0.10.0-1 ------------------- * Thu Feb 12 2004 Warren Togami 0.10.0-1 - upgrade to 0.10.0 - Spec cleanups - Remove INSTALL, add NEWS - Add new binaries - libtool, auto* not needed nut-1.4.1-3 ----------- * Sat Feb 14 2004 Than Ngo 1.4.1-3 - add some missing drivers * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Feb 11 2004 Than Ngo 1.4.1-1 - 1.4.1 - fixed permission problem (bug #115290) perl-libwww-perl-5.76-2 ----------------------- quanta-3.2.0-1.1 ---------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Feb 11 2004 Than Ngo 6:3.2.0-0.1 - 3.2.0 release - built against qt 3.3.0 rpmdb-fedora-1.90-0.20040215 ---------------------------- From surak at casa.surak.eti.br Sun Feb 15 17:34:18 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Sun, 15 Feb 2004 14:34:18 -0300 Subject: XFree86: New via driver with DRI In-Reply-To: References: Message-ID: <1076866458.13164.21.camel@casa> Em Dom, 2004-02-15 ?s 03:51, Mike A. Harris escreveu: > I have updated the "via" video driver in XFree86-4.3.0-56 in > rawhide with Alan Cox's latest driver. The new driver has DRI > support however a typo in the spec file caused the DRI driver not > to get built in 4.3.0-56, so only the new 2D driver is present in > this build. Hi Mike, this driver has nothing to do with savage one, right? That one for via ple and kle boards... If not, are there any plans to put the via/s3 open source one on FC2? I remember some people was porting it to xfree 4.3 and the newer mesa, but didn't see anything about it for quite some time... -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From alan at redhat.com Sun Feb 15 17:35:45 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 15 Feb 2004 12:35:45 -0500 Subject: XFree86: New via driver with DRI In-Reply-To: <1076866458.13164.21.camel@casa> References: <1076866458.13164.21.camel@casa> Message-ID: <20040215173545.GB11605@devserv.devel.redhat.com> On Sun, Feb 15, 2004 at 02:34:18PM -0300, Alexandre Strube wrote: > this driver has nothing to do with savage one, right? That one for via > ple and kle boards... If not, are there any plans to put the via/s3 open PLE and KLE is trident video. CLE is "via" along with KM400 etc although those only support 2D bits not Xv or 3D (bug via about that bit not me). Also no MPEG2 yet. > source one on FC2? I remember some people was porting it to xfree 4.3 > and the newer mesa, but didn't see anything about it for quite some > time... Its still a bit rickety and it has trivial security exploits because the 2D engine is overexposed to user space From surak at casa.surak.eti.br Sun Feb 15 17:45:24 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Sun, 15 Feb 2004 14:45:24 -0300 Subject: XFree86: New via driver with DRI In-Reply-To: <20040215173545.GB11605@devserv.devel.redhat.com> References: <1076866458.13164.21.camel@casa> <20040215173545.GB11605@devserv.devel.redhat.com> Message-ID: <1076867123.13164.27.camel@casa> Em Dom, 2004-02-15 ?s 14:35, Alan Cox escreveu: > PLE and KLE is trident video. CLE is "via" along with KM400 etc although Weird. I have a via kl266, which uses the savage driver. The lspci output is VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] I'm probably confused kl266 with those kle133, which uses cyberblade video, as far as I can remember. > > source one on FC2? I remember some people was porting it to xfree 4.3 > > and the newer mesa, but didn't see anything about it for quite some > > time... > Its still a bit rickety and it has trivial security exploits because the > 2D engine is overexposed to user space Thanks for the info. I'm preety sure I have to save some money and get a real and supported video card. -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From alan at redhat.com Sun Feb 15 17:46:59 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 15 Feb 2004 12:46:59 -0500 Subject: XFree86: New via driver with DRI In-Reply-To: <1076867123.13164.27.camel@casa> References: <1076866458.13164.21.camel@casa> <20040215173545.GB11605@devserv.devel.redhat.com> <1076867123.13164.27.camel@casa> Message-ID: <20040215174659.GA16994@devserv.devel.redhat.com> On Sun, Feb 15, 2004 at 02:45:24PM -0300, Alexandre Strube wrote: > Em Dom, 2004-02-15 ?s 14:35, Alan Cox escreveu: > > > PLE and KLE is trident video. CLE is "via" along with KM400 etc although > > Weird. I have a via kl266, which uses the savage driver. The lspci > output is My error KLE133 is trident KLE266 is S3 > > Its still a bit rickety and it has trivial security exploits because the > > 2D engine is overexposed to user space > > Thanks for the info. I'm preety sure I have to save some money and get a > real and supported video card. If you've got an S3 you can grab the bits from the DRI sf site and have a play. It seems to work ok for most people now From lstfedoradevel at mw.hn.org Sun Feb 15 17:48:11 2004 From: lstfedoradevel at mw.hn.org (Ivan Leong) Date: Mon, 16 Feb 2004 01:48:11 +0800 Subject: Are there any new packages in FC 2 test 1 In-Reply-To: <402E6AC2.7070300@haitsma.org> References: <402E6AC2.7070300@haitsma.org> Message-ID: <402FB0DB.3020304@mw.hn.org> Here you go, all 147 of them: alsa-lib-1.0.2-1 alsa-lib-devel-1.0.2-1 alsa-utils-1.0.2-1 bind-libs-9.2.3-5 checkpolicy-1.4-6 cyrus-imapd-2.1.16-2 db4-tcl-4.2.52-2 dbh-1.0.15-1 dbh-devel-1.0.15-1 device-mapper-1.00.07-2 distcache-0.4.2-8 distcache-devel-0.4.2-8 emacs-common-21.3-9 emacs-nox-21.3-9 evolution-data-server-0.0.6-1 evolution-data-server-devel-0.0.6-1 exim-4.30-5 exim-doc-4.30-5 exim-mon-4.30-5 exim-sa-4.30-5 flac-1.1.0-1 flac-devel-1.1.0-1 flac-xmms-1.1.0-1 fonts-bengali-0.1-1 gcc-c++-ssa-3.5ssa-0.20040120.110 gcc-gfortran-ssa-3.5ssa-0.20040120.110 gcc-java-ssa-3.5ssa-0.20040120.110 gcc-objc-ssa-3.5ssa-0.20040120.110 gcc-ssa-3.5ssa-0.20040120.110 gcc34-3.4.0-0.3 gcc34-c++-3.4.0-0.3 gcc34-java-3.4.0-0.3 ghostscript-gtk-7.07-19 gnome-keyring-0.1.3-1 gnome-keyring-devel-0.1.3-1 gnome-vfs2-smb-2.5.6-1 hicolor-icon-theme-0.2-1 iiimf-client-lib-11_4-4 iiimf-client-lib-devel-11_4-4 iiimf-csconv-11_4-4 iiimf-docs-11_4-4 iiimf-gtk-11_4-4 iiimf-le-canna-11_4-4 iiimf-le-hangul-11_4-4 iiimf-le-newpy-11_4-4 iiimf-le-unit-11_4-4 iiimf-protocol-lib-11_4-4 iiimf-protocol-lib-devel-11_4-4 iiimf-server-11_4-4 iiimf-x-11_4-4 ipsec-tools-0.2.2-8 kde-i18n-Lithuanian-3.1.95-0.1 kdeaddons-atlantikdesigner-3.1.95-0.1 kdeartwork-icons-3.1.95-0.1 koffice-i18n-1.3-2 libexif-0.5.12-1 libexif-devel-0.5.12-1 libgcc-ssa-3.5ssa-0.20040120.110 libgcj-ssa-3.5ssa-0.20040120.110 libgcj-ssa-devel-3.5ssa-0.20040120.110 libgcj34-3.4.0-0.3 libgcj34-devel-3.4.0-0.3 libgfortran-ssa-3.5ssa-0.20040120.110 libgfortran-ssa-devel-3.5ssa-0.20040120.110 libgnomecups-0.1.6-3 libgnomecups-devel-0.1.6-3 libmudflap-3.5ssa-0.20040120.110 libmudflap-devel-3.5ssa-0.20040120.110 libselinux-1.4-9 libselinux-devel-1.4-9 libstdc++-ssa-3.5ssa-0.20040120.110 libstdc++-ssa-devel-3.5ssa-0.20040120.110 libstdc++34-3.4.0-0.3 libstdc++34-devel-3.4.0-0.3 libxfce4mcs-4.0.3-2 libxfce4mcs-devel-4.0.3-2 libxfce4util-4.0.3-2 libxfce4util-devel-4.0.3-2 libxfcegui4-4.0.3-2 libxfcegui4-devel-4.0.3-2 libxklavier-0.97-1 libxklavier-devel-0.97-1 lvm2-2.00.08-2 nabi-0.11-3 openobex-apps-1.0.0-1 pcmcia-cs-3.2.7-1.3 php-pear-4.3.4-7 policy-1.4.10-6 policy-sources-1.4.10-6 policycoreutils-1.4-7 quanta-devel-3.1.95-0.1 rhdb-utils-2.0-2 selinux-doc-1.4-1 setools-1.1.1-1 setools-devel-1.1.1-1 setools-gui-1.1.1-1 shared-mime-info-0.13-1 speex-1.0.3-1 speex-devel-1.0.3-1 system-config-bind-2.0.2-3 system-config-boot-0.2.1-1 system-config-date-1.7.1-1 system-config-display-1.0.4-1 system-config-httpd-1.2.0-1 system-config-keyboard-1.2.1-1 system-config-kickstart-2.5.4-1 system-config-language-1.1.5-1 system-config-mouse-1.2.3-1 system-config-netboot-0.1.3-2 system-config-network-1.3.15-1 system-config-network-tui-1.3.15-1 system-config-nfs-1.2.1-1 system-config-packages-1.9.3-2 system-config-printer-0.6.91-1 system-config-printer-gui-0.6.91-1 system-config-proc-0.25-1 system-config-rootpassword-1.1.3-1 system-config-samba-1.2.2-1 system-config-securitylevel-1.3.1-1 system-config-securitylevel-tui-1.3.1-1 system-config-services-0.8.6-2 system-config-soundcard-1.2.2-1 system-config-users-1.2.8-1 system-logviewer-0.9.5-1 system-switch-mail-0.5.22-2 system-switch-mail-gnome-0.5.22-2 tix-devel-8.1.4-95 tix-doc-8.1.4-95 tvtime-0.9.12-2 udev-015-1 xfce-mcs-manager-4.0.3-2 xfce-mcs-manager-devel-4.0.3-2 xfce-mcs-plugins-4.0.3-2 xfce-utils-4.0.3-2 xfce4-panel-4.0.3-2 xfdesktop-4.0.3-2 xffm-4.0.3-2 xffm-icons-4.0.3-1 xfsprogs-2.6.0-3 xfsprogs-devel-2.6.0-3 xfwm4-4.0.3.1-2 xfwm4-themes-4.0.3-1 xmlsec1-1.2.3-1 xmlsec1-devel-1.2.3-1 xmlsec1-openssl-1.2.3-1 xmlsec1-openssl-devel-1.2.3-1 zsh-html-4.0.9-1 Jaap A. Haitsma wrote: > Hi, > > I was wondering if there are any new packages (so not counting > updates) in FC 2 test 1 compared to FC 1. Can't find it on the website. > > Jaap > > From mharris at redhat.com Sun Feb 15 20:22:20 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 15 Feb 2004 15:22:20 -0500 (EST) Subject: Fedora build system In-Reply-To: <20040215160052.GA6505@imp.flyn.org> References: <20040215160052.GA6505@imp.flyn.org> Message-ID: On Sun, 15 Feb 2004, W. Michael Petullo wrote: >Does the amazing beast known as the Fedora Build System exist yet? Nope, not yet. >I don't know where to find this build system. I have only found an >email from Warren to fedora-devel dated Nov 18, 2003 laying out the >architecture of the system. > >Could someone clarify this portion of the release procedure? In limbo. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Feb 15 20:25:19 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 15 Feb 2004 15:25:19 -0500 (EST) Subject: XFree86: New via driver with DRI In-Reply-To: <1076866458.13164.21.camel@casa> References: <1076866458.13164.21.camel@casa> Message-ID: On Sun, 15 Feb 2004, Alexandre Strube wrote: >> I have updated the "via" video driver in XFree86-4.3.0-56 in >> rawhide with Alan Cox's latest driver. The new driver has DRI >> support however a typo in the spec file caused the DRI driver not >> to get built in 4.3.0-56, so only the new 2D driver is present in >> this build. > >Hi Mike, > >this driver has nothing to do with savage one, right? That one for via >ple and kle boards... If not, are there any plans to put the via/s3 open >source one on FC2? I remember some people was porting it to xfree 4.3 >and the newer mesa, but didn't see anything about it for quite some >time... This is the driver named "via" for VIA EPIA onboard video chipsets. Fedora Core 1 had an earlier version of this driver in it already, however the new version is one that Alan Cox has been working on, which has DRI support. The 4.3.0-56 build however is missing the DRI 3D module due to a typo I made in the spec file. XFree86-4.3.0-57 should fix that, however our buildsystem is undergoing a massive rebuild of the entire OS right now and all buildmachines are unavailable to me, so unfortunately people will have to wait a few days now probably. ;o( -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From davej at redhat.com Sun Feb 15 21:46:09 2004 From: davej at redhat.com (Dave Jones) Date: Sun, 15 Feb 2004 21:46:09 +0000 Subject: XFree86: New via driver with DRI In-Reply-To: References: Message-ID: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> On Sun, 2004-02-15 at 06:51, Mike A. Harris wrote: > Please test the new XFree86 build out on via hardware, and report > any problems in bugzilla. DRI support requires that you be > running the latest Fedora development kernel. I don't know if > the Fedora Core 1 or RHL 9 kernels have the via DRM module in > them or not. If not - nag davej. ;o) RHL9 - No, it doesn't actually have the VIA DRM code at all there. Unless someone finds the time to backport it, it isn't likely to happen. FC1 - Enabled since 2166. Dave From mharris at redhat.com Mon Feb 16 00:39:51 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 15 Feb 2004 19:39:51 -0500 (EST) Subject: XFree86: New via driver with DRI In-Reply-To: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> References: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> Message-ID: On Sun, 15 Feb 2004, Dave Jones wrote: >> Please test the new XFree86 build out on via hardware, and report >> any problems in bugzilla. DRI support requires that you be >> running the latest Fedora development kernel. I don't know if >> the Fedora Core 1 or RHL 9 kernels have the via DRM module in >> them or not. If not - nag davej. ;o) > >RHL9 - No, it doesn't actually have the VIA DRM code at all there. >Unless someone finds the time to backport it, it isn't likely to >happen. > >FC1 - Enabled since 2166. Ok, good to know. For the current time, the new via driver will only be present in rawhide builds only, and no other OS release builds. There are issues I've heard Alan discussing in IRC that I'd want to see fixed before releasing the driver in an officially supported product. Other than that though, feedback from people is appreciated. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alan at redhat.com Mon Feb 16 01:01:17 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 15 Feb 2004 20:01:17 -0500 Subject: XFree86: New via driver with DRI In-Reply-To: References: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> Message-ID: <20040216010117.GB24001@devserv.devel.redhat.com> On Sun, Feb 15, 2004 at 07:39:51PM -0500, Mike A. Harris wrote: > Ok, good to know. For the current time, the new via driver will > only be present in rawhide builds only, and no other OS release > builds. There are issues I've heard Alan discussing in IRC that Such as ? From surak at casa.surak.eti.br Mon Feb 16 02:19:32 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Sun, 15 Feb 2004 23:19:32 -0300 Subject: ProSavage and DRI (Was Re: XFree86: New via driver with DRI) In-Reply-To: <20040215174659.GA16994@devserv.devel.redhat.com> References: <1076866458.13164.21.camel@casa> <20040215173545.GB11605@devserv.devel.redhat.com> <1076867123.13164.27.camel@casa> <20040215174659.GA16994@devserv.devel.redhat.com> Message-ID: <1076897972.16235.15.camel@casa> Em Dom, 2004-02-15 ?s 14:46, Alan Cox escreveu: > > > Its still a bit rickety and it has trivial security exploits because the > > > 2D engine is overexposed to user space (....) > If you've got an S3 you can grab the bits from the DRI sf site and have a > play. It seems to work ok for most people now Got it, but don't know how to compile it for fedora. According to what Alex Deucher said on DRI list ( http://www.mail-archive.com/dri-devel at lists.sourceforge.net/msg14732.html ), which is "you need to build the savage kernel module. The code is in: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel Change to that directory and then type: make -f Makefile.linux or make -f Makefile.linux LINUXDIR=/path/to/kernel/src If you are using redhat 9 (possibly fedora as well), the build will fail because redhat is using the MM code from 2.6 in their 2.4 kernels. If that is the case you will need to download and install a vanilla 2.4 kernel." I tried it anyway, and then the result was: In file included from gamma_drv.c:49: drm_init.h: In function `gamma_cpu_valid': drm_init.h:123: `boot_cpu_data_R4a8db2ac' undeclared (first use in this function) In file included from gamma_drv.c:55: drm_memory.h:64:1: warning: "pte_pfn" redefined In file included from /usr/src/linux-2.4.22-1.2140.nptl/include/asm/pgtable.h:124, from /usr/src/linux-2.4.22-1.2140.nptl/include/linux/mm.h:26, from /usr/src/linux-2.4.22-1.2140.nptl/include/linux/slab.h:14, from /usr/src/linux-2.4.22-1.2140.nptl/include/linux/proc_fs.h:5, from drmP.h:50, from gamma_drv.c:34: /usr/src/linux-2.4.22-1.2140.nptl/include/asm/pgtable-2level.h:63:1: warning: this is the location of the previous definition In file included from gamma_drv.c:57: drm_vm.h: In function `gamma_mmap': drm_vm.h:600: `boot_cpu_data_R4a8db2ac' undeclared (first use in this function) In file included from gamma_drv.c:58: drm_stub.h: In function `gamma_stub_open': drm_stub.h:72: warning: implicit declaration of function `try_inc_mod_count_Re6105b23' In file included from gamma_drv.c:58: drm_stub.h: In function `gamma_stub_putminor': drm_stub.h:147: warning: implicit declaration of function `inter_module_unregister_R7a9e845e' drm_stub.h: In function `gamma_stub_register': drm_stub.h:188: warning: implicit declaration of function `inter_module_register_R62dada05' make[2]: ** [gamma_drv.o] Erro 1 make[2]: Saindo do diret?rio `/home/surak/savage/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel' make[1]: ** [_mod_/home/surak/savage/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel] Erro 2 make[1]: Saindo do diret?rio `/usr/src/linux-2.4.22-1.2140.nptl' make: ** [modules] Erro 2 As I want to keep with fedora kernels, (and I just realized that this machine has it outdated), am I trapped? Will I have to grab a vanilla kernel for this? Thanks for any help. -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From mharris at redhat.com Mon Feb 16 07:54:43 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 16 Feb 2004 02:54:43 -0500 (EST) Subject: XFree86: New via driver with DRI In-Reply-To: <20040216010117.GB24001@devserv.devel.redhat.com> References: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> <20040216010117.GB24001@devserv.devel.redhat.com> Message-ID: On Sun, 15 Feb 2004, Alan Cox wrote: >> Ok, good to know. For the current time, the new via driver will >> only be present in rawhide builds only, and no other OS release >> builds. There are issues I've heard Alan discussing in IRC that > >Such as ? I heard you comment I believe in IRC, or perhaps email something about security issues. I searched my IRC log briefly with /lastlog and didn't spot anything. Am I mistaken? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alan at redhat.com Mon Feb 16 09:47:21 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Feb 2004 04:47:21 -0500 Subject: XFree86: New via driver with DRI In-Reply-To: References: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> <20040216010117.GB24001@devserv.devel.redhat.com> Message-ID: <20040216094721.GE375@devserv.devel.redhat.com> On Mon, Feb 16, 2004 at 02:54:43AM -0500, Mike A. Harris wrote: > On Sun, 15 Feb 2004, Alan Cox wrote: > >> Ok, good to know. For the current time, the new via driver will > >> only be present in rawhide builds only, and no other OS release > >> builds. There are issues I've heard Alan discussing in IRC that > > > >Such as ? > > I heard you comment I believe in IRC, or perhaps email something > about security issues. I searched my IRC log briefly with > /lastlog and didn't spot anything. Am I mistaken? S3 Savage has security issues, VIA I don't believe does, but that isnt to say a review wouldnt do any harm From naoki at valuecommerce.com Mon Feb 16 10:13:45 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 16 Feb 2004 19:13:45 +0900 Subject: up2date 4.3.11-2 traceback. Message-ID: <403097D9.9080602@valuecommerce.com> Should I file a bug for this? [root at box ~]# up2date -l http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide using mirror: http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/ Fetching Obsoletes list for channel: fedora-core-rawhide... Fetching obsoletes list for http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/... Traceback (most recent call last): File "/usr/sbin/up2date", line 1267, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 797, in main fullUpdate, dryRun=options.dry_run)) File "/usr/sbin/up2date", line 1141, in batchRun batch.run() File "up2dateBatch.py", line 62, in run File "up2dateBatch.py", line 108, in __findPackagesToUpdate File "packageList.py", line 574, in getPackagesToInstall File "packageList.py", line 454, in __findObsoletingPackages TypeError: int() argument must be a string or a number From mharris at redhat.com Mon Feb 16 10:30:56 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 16 Feb 2004 05:30:56 -0500 (EST) Subject: XFree86: New via driver with DRI In-Reply-To: <20040216094721.GE375@devserv.devel.redhat.com> References: <1076881569.5066.2.camel@delerium.codemonkey.org.uk> <20040216010117.GB24001@devserv.devel.redhat.com> <20040216094721.GE375@devserv.devel.redhat.com> Message-ID: On Mon, 16 Feb 2004, Alan Cox wrote: >> I heard you comment I believe in IRC, or perhaps email something >> about security issues. I searched my IRC log briefly with >> /lastlog and didn't spot anything. Am I mistaken? > >S3 Savage has security issues, VIA I don't believe does, but that >isnt to say a review wouldnt do any harm Ah, I must have misread you then. This is good. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From buildsys at redhat.com Mon Feb 16 10:46:04 2004 From: buildsys at redhat.com (Build System) Date: Mon, 16 Feb 2004 05:46:04 -0500 Subject: rawhide report: 20040216 changes Message-ID: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20040216 ---------------------------- From naoki at valuecommerce.com Mon Feb 16 10:55:15 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 16 Feb 2004 19:55:15 +0900 Subject: up2date 4.3.11-2 traceback. In-Reply-To: <403097D9.9080602@valuecommerce.com> References: <403097D9.9080602@valuecommerce.com> Message-ID: <4030A193.3090200@valuecommerce.com> Seem to have found the problem : It would fail on : yum fedora-dev-updates http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/ Fetching Obsoletes list for channel: fedora-dev-updates... Traceback (most recent call last): File "/usr/sbin/up2date", line 1267, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 797, in main fullUpdate, dryRun=options.dry_run)) File "/usr/sbin/up2date", line 1141, in batchRun batch.run() File "up2dateBatch.py", line 62, in run File "up2dateBatch.py", line 108, in __findPackagesToUpdate File "packageList.py", line 574, in getPackagesToInstall File "packageList.py", line 454, in __findObsoletingPackages TypeError: int() argument must be a string or a number But yum fedora-development http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386 Fetching Obsoletes list for channel: fedora-development... Fetching rpm headers... ################################ And so on.. hmmm. Naoki wrote: > Should I file a bug for this? > > [root at box ~]# up2date -l > http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide > using mirror: > http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/ > > Fetching Obsoletes list for channel: fedora-core-rawhide... > > Fetching obsoletes list for > http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/... > Traceback (most recent call last): > File "/usr/sbin/up2date", line 1267, in ? > sys.exit(main() or 0) > File "/usr/sbin/up2date", line 797, in main > fullUpdate, dryRun=options.dry_run)) > File "/usr/sbin/up2date", line 1141, in batchRun > batch.run() > File "up2dateBatch.py", line 62, in run > File "up2dateBatch.py", line 108, in __findPackagesToUpdate > File "packageList.py", line 574, in getPackagesToInstall > File "packageList.py", line 454, in __findObsoletingPackages > TypeError: int() argument must be a string or a number > > From jorton at redhat.com Mon Feb 16 11:45:37 2004 From: jorton at redhat.com (Joe Orton) Date: Mon, 16 Feb 2004 11:45:37 +0000 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <200402131248.i1DCmfmA005990@d103.fi.basen.net> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> Message-ID: <20040216114537.GA6685@redhat.com> On Fri, Feb 13, 2004 at 02:48:41PM +0200, Kaj J. Niemi wrote: > I'm advocating that php-imap, which was removed from Rawhide in php-4.3.4-4, > should be reintroduced before the release of FC2. I noticed it was missing > while preparing to evaluate FogBUGZ (shameless plug, google will tell you more) > and migrating a IMP installation from FreeBSD to Fedora. > > Since it looks like it got disabled because the "imap" package providing the > c-client API vanished it would be rather easy to recreate a c-client package > for the libraries/header files only and ignore the rest. PHP would then be > rebuilt with the corresponding new buildrequire statement. Right: the issue is really about whether or not to include the c-client library in FC2: the feeling internally seems to be that getting rid of c-client was a good thing. Hopefully others can follow up on that. Regards, joe From Bernd.Bartmann at sohanet.de Mon Feb 16 11:57:07 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Mon, 16 Feb 2004 12:57:07 +0100 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <20040216114537.GA6685@redhat.com> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> Message-ID: <4030B013.8050702@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Orton wrote: | Right: the issue is really about whether or not to include the c-client | library in FC2: the feeling internally seems to be that getting rid of | c-client was a good thing. Hopefully others can follow up on that. Removing something without providing an alternative solution is not a good thing. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAMLASkQuIaHu84cIRAiSbAJ9zFlCuI/RFeL+ZKcZcnjz47TO4DgCfUtiT JyOTLHLn1OvrQWfLhn94iL0= =USRR -----END PGP SIGNATURE----- From mharris at redhat.com Mon Feb 16 13:05:07 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 16 Feb 2004 08:05:07 -0500 (EST) Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <20040216114537.GA6685@redhat.com> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> Message-ID: On Mon, 16 Feb 2004, Joe Orton wrote: >> I'm advocating that php-imap, which was removed from Rawhide in php-4.3.4-4, >> should be reintroduced before the release of FC2. I noticed it was missing >> while preparing to evaluate FogBUGZ (shameless plug, google will tell you more) >> and migrating a IMP installation from FreeBSD to Fedora. >> >> Since it looks like it got disabled because the "imap" package providing the >> c-client API vanished it would be rather easy to recreate a c-client package >> for the libraries/header files only and ignore the rest. PHP would then be >> rebuilt with the corresponding new buildrequire statement. > >Right: the issue is really about whether or not to include the >c-client library in FC2: the feeling internally seems to be that >getting rid of c-client was a good thing. Hopefully others can >follow up on that. Someone has privately asked me to comment on this mail thread so I'll do so, but be brief and to the point. I haven't maintained the UW imap package for over a year in the distribution, and have no personal interest in the software, nor of maintaining it. The code is insecure, and is in my own personal opinion poorly written, with many bad assumptions. It is a burden to whoever gets stuck maintaining it or the c-client portion of it, as it is a recipe for disaster just waiting to happen. I won't give any more specific details than that other than to have people examine the source code for themselves, as I'm not interested in debating the merits or lack thereof of UW's MTA/MDA/MUA products. BUGTRAQ archives, and CVE advisories should provide some useful details though. ;o) I'm not interested personally in the development of UW pine/imap/c-client software, however I am a pine user, and still make unofficial pine rpms. Since we no longer ship imap or pine, and have no plans on re-including either of them, and since php-imap seems to require c-client in order to function (at least that is my understanding currently anyway), there seem to be 2 solutions: 1) Review the license that the UW c-client library is licensed under to ensure it is OSS friendly under the Fedora Project licensing guidelines. If so, include just the c-client library directly in the php-imap package, and have it self contained there, patched with whatever security fixes are needed, similarly to current UW imap releases. or 2) Drop php-imap from the distribution or 3) Drop php-imap and replace it with a similar piece of software which does not use c-client. These are just off the top of my head suggestions I'm offering because I was asked directly however. I personally have no developmental interest in MTA/MDA/MUA software packages, including imap/pine/c-client, and so my opinion is just advisory. ;o) Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From yovko at yovko.net Mon Feb 16 13:25:41 2004 From: yovko at yovko.net (Yovko Lambrev) Date: Mon, 16 Feb 2004 15:25:41 +0200 (EET) Subject: MySQL - Optional GPL License Exception for PHP Message-ID: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> Please be informed that MySQL AB released an optional GPL License Exception for PHP. Text of the exception: As a special exception, MySQL AB gives permission to distribute derivative works that are formed with GPL-licensed MySQL software and with software licensed under version 3.0 of the PHP license. You must obey the GNU General Public License in all respects for all of the code used other than code licensed under version 3.0 of the PHP license. Full license info: http://mysql.online.bg/products/opensource-license.html Will this be enough to include MySQL 4.x in Fedora Core? -- Best regards, Yovko Lambrev http://yovko.net From rms at 1407.org Mon Feb 16 13:55:29 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 16 Feb 2004 13:55:29 +0000 Subject: MySQL - Optional GPL License Exception for PHP In-Reply-To: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> References: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> Message-ID: <1076939728.3232.43.camel@roque> On Mon, 2004-02-16 at 15:25 +0200, Yovko Lambrev wrote: > Please be informed that MySQL AB released an optional GPL License > Exception for PHP. > > Text of the exception: > As a special exception, MySQL AB gives permission to distribute derivative > works that are formed with GPL-licensed MySQL software and with software > licensed under version 3.0 of the PHP license. You must obey the GNU ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Will this be enough to include MySQL 4.x in Fedora Core? Old news, and useless since our PHP is version 4.x :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kjb at dds.nl Mon Feb 16 14:24:30 2004 From: kjb at dds.nl (Klaasjan Brand) Date: Mon, 16 Feb 2004 15:24:30 +0100 Subject: MySQL - Optional GPL License Exception for PHP In-Reply-To: <1076939728.3232.43.camel@roque> References: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> <1076939728.3232.43.camel@roque> Message-ID: <1076941470.14668.11.camel@topicus6> On Mon, 2004-02-16 at 14:55, Rui Miguel Seabra wrote: > > licensed under version 3.0 of the PHP license. You must obey the GNU > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Will this be enough to include MySQL 4.x in Fedora Core? > > Old news, and useless since our PHP is version 4.x :) Check /usr/share/doc/php-4.3.4/LICENSE; the license version is 3. Klaasjan From rms at 1407.org Mon Feb 16 14:23:30 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 16 Feb 2004 14:23:30 +0000 Subject: MySQL - Optional GPL License Exception for PHP In-Reply-To: <1076941470.14668.11.camel@topicus6> References: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> <1076939728.3232.43.camel@roque> <1076941470.14668.11.camel@topicus6> Message-ID: <1076941410.3232.51.camel@roque> On Mon, 2004-02-16 at 15:24 +0100, Klaasjan Brand wrote: > On Mon, 2004-02-16 at 14:55, Rui Miguel Seabra wrote: > > > licensed under version 3.0 of the PHP license. You must obey the GNU > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > Will this be enough to include MySQL 4.x in Fedora Core? > > Old news, and useless since our PHP is version 4.x :) > Check /usr/share/doc/php-4.3.4/LICENSE; the license version is 3. Oops... my bad, even whilst pointing it out I still read version 3 of PHP :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From surak at casa.surak.eti.br Mon Feb 16 15:26:09 2004 From: surak at casa.surak.eti.br (Alexandre) Date: Mon, 16 Feb 2004 12:26:09 -0300 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <4030B013.8050702@sohanet.de> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> <4030B013.8050702@sohanet.de> Message-ID: <1076945169.11167.4.camel@ahrak.surak.eti.br> Em Seg, 2004-02-16 ?s 08:57, Bernd Bartmann escreveu: > Joe Orton wrote: > | Right: the issue is really about whether or not to include the c-client > | library in FC2: the feeling internally seems to be that getting rid of > | c-client was a good thing. Hopefully others can follow up on that. > Removing something without providing an alternative solution is not a > good thing. This means that squirrelmail is going to me removed also... Hum... not good. []s Alexandre Strube From jdennis at redhat.com Mon Feb 16 16:32:17 2004 From: jdennis at redhat.com (John Dennis) Date: Mon, 16 Feb 2004 11:32:17 -0500 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <1076945169.11167.4.camel@ahrak.surak.eti.br> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> <4030B013.8050702@sohanet.de> <1076945169.11167.4.camel@ahrak.surak.eti.br> Message-ID: <1076949137.1313.12.camel@finch.boston.redhat.com> On Mon, 2004-02-16 at 10:26, Alexandre wrote: > Em Seg, 2004-02-16 ?s 08:57, Bernd Bartmann escreveu: > > > Joe Orton wrote: > > | Right: the issue is really about whether or not to include the c-client > > | library in FC2: the feeling internally seems to be that getting rid of > > | c-client was a good thing. Hopefully others can follow up on that. > > Removing something without providing an alternative solution is not a > > good thing. > > This means that squirrelmail is going to me removed also... Hum... not > good. Correct me if I'm wrong but I thought squirrelmail depended on imap, not on some particular imap or its underlying library. FC2 will have cyrus imap and dovecot. Isn't this an alternative solution? From alan at redhat.com Mon Feb 16 16:36:43 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Feb 2004 11:36:43 -0500 Subject: MySQL - Optional GPL License Exception for PHP In-Reply-To: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> References: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> Message-ID: <20040216163643.GA23940@devserv.devel.redhat.com> On Mon, Feb 16, 2004 at 03:25:41PM +0200, Yovko Lambrev wrote: > Will this be enough to include MySQL 4.x in Fedora Core? As was pointed out before - there are things like OpenSSL in with php in apache modules. I'm hopeful MySQL can work something out because I'd like to see all the bits in place From alexander.dalloz at uni-bielefeld.de Mon Feb 16 16:43:28 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Mon, 16 Feb 2004 17:43:28 +0100 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <1076949137.1313.12.camel@finch.boston.redhat.com> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> <4030B013.8050702@sohanet.de> <1076945169.11167.4.camel@ahrak.surak.eti.br> <1076949137.1313.12.camel@finch.boston.redhat.com> Message-ID: <1076949808.4176.220.camel@sirendipity.dogma.lan> Am Mo, den 16.02.2004 schrieb John Dennis um 17:32: > On Mon, 2004-02-16 at 10:26, Alexandre wrote: > > Em Seg, 2004-02-16 ?s 08:57, Bernd Bartmann escreveu: > > > > > Joe Orton wrote: > > > | Right: the issue is really about whether or not to include the c-client > > > | library in FC2: the feeling internally seems to be that getting rid of > > > | c-client was a good thing. Hopefully others can follow up on that. > > > Removing something without providing an alternative solution is not a > > > good thing. > > > > This means that squirrelmail is going to me removed also... Hum... not > > good. > > Correct me if I'm wrong but I thought squirrelmail depended on imap, not > on some particular imap or its underlying library. FC2 will have cyrus > imap and dovecot. Isn't this an alternative solution? Each webmail application requires an IMAP/POP server. But how does squirrelmail does contact the server? I thought squirrelmail is written in PHP, just like Horde/IMP which I am using. Horde/IMP needs the php-imap support to establish the connection to the server. I believe Alexandre had that in mind too. I do not need uw-imapd but php-imap. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2166.nptl Sirendipity 17:39:10 up 1 day, 21:18, load average: 0.05, 0.12, 0.12 [ ????? ?'????? - gnothi seauton ] From jorton at redhat.com Mon Feb 16 16:48:23 2004 From: jorton at redhat.com (Joe Orton) Date: Mon, 16 Feb 2004 16:48:23 +0000 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <1076945169.11167.4.camel@ahrak.surak.eti.br> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> <4030B013.8050702@sohanet.de> <1076945169.11167.4.camel@ahrak.surak.eti.br> Message-ID: <20040216164823.GA11609@redhat.com> On Mon, Feb 16, 2004 at 12:26:09PM -0300, Alexandre wrote: > Em Seg, 2004-02-16 ?s 08:57, Bernd Bartmann escreveu: > > > Joe Orton wrote: > > | Right: the issue is really about whether or not to include the c-client > > | library in FC2: the feeling internally seems to be that getting rid of > > | c-client was a good thing. Hopefully others can follow up on that. > > Removing something without providing an alternative solution is not a > > good thing. > > This means that squirrelmail is going to me removed also... Hum... not > good. No, squirrelmail does not require the php-imap extension, it implements an IMAP client entirely in PHP code. It works fine without php-imap (AFAIK). Regards, joe From tdiehl at rogueind.com Mon Feb 16 16:51:51 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 16 Feb 2004 11:51:51 -0500 (EST) Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <1076949137.1313.12.camel@finch.boston.redhat.com> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> <4030B013.8050702@sohanet.de> <1076945169.11167.4.camel@ahrak.surak.eti.br> <1076949137.1313.12.camel@finch.boston.redhat.com> Message-ID: On Mon, 16 Feb 2004, John Dennis wrote: > On Mon, 2004-02-16 at 10:26, Alexandre wrote: > > Em Seg, 2004-02-16 ??s 08:57, Bernd Bartmann escreveu: > > > > > Joe Orton wrote: > > > | Right: the issue is really about whether or not to include the c-client > > > | library in FC2: the feeling internally seems to be that getting rid of > > > | c-client was a good thing. Hopefully others can follow up on that. > > > Removing something without providing an alternative solution is not a > > > good thing. > > > > This means that squirrelmail is going to me removed also... Hum... not > > good. > > Correct me if I'm wrong but I thought squirrelmail depended on imap, not > on some particular imap or its underlying library. FC2 will have cyrus > imap and dovecot. Isn't this an alternative solution? php-imap is not in the list of deps for squirrelmail. (icarus pts4) # rpm -q --requires squirrelmail /bin/sh /usr/bin/env /usr/sbin/sendmail config(squirrelmail) = 1.2.11-1 httpd httpd perl perl php >= 4.0.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 tmpwatch >= 2.8 (icarus pts4) # AFAIK you only need an imap server. Tom From webmaster at margo.bijoux.nom.br Mon Feb 16 16:02:31 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Mon, 16 Feb 2004 14:02:31 -0200 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <1076949808.4176.220.camel@sirendipity.dogma.lan> References: <1076949808.4176.220.camel@sirendipity.dogma.lan> Message-ID: <20040216170232.11491.qmail@hm36.locaweb.com.br> On Mon, 16 Feb 2004 17:43:28 +0100, Alexander Dalloz escreveu: > Each webmail application requires an IMAP/POP server. But how does > squirrelmail does contact the server? I thought squirrelmail is written > in PHP, just like Horde/IMP which I am using. Horde/IMP needs the > php-imap support to establish the connection to the server. I believe > Alexandre had that in mind too. > > I do not need uw-imapd but php-imap. > > Alexander >From the rpm package of squirrelmail (on FC1 , as I am far from my FC2 machine): capeta:RPMS->rpm -qRp squirrelmail-1.4.0-1.noarch.rpm /bin/sh /usr/bin/env /usr/sbin/sendmail aspell config(squirrelmail) = 1.4.0-1 httpd httpd perl perl perl(Cwd) perl(IO::Socket) php >= 4.0.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 tmpwatch >= 2.8 I also looked at the functions dir of squirrelmail and it looks like squirrelmail has its own imap access routines.. But having php-imap is interesting , as other tools like Horde/IMP need this package.. -------------------- Pedro Fernandes Macedo From nutello at sweetness.com Mon Feb 16 17:23:01 2004 From: nutello at sweetness.com (Rudi Chiarito) Date: Mon, 16 Feb 2004 18:23:01 +0100 Subject: YUM's shortcomings In-Reply-To: <1076836918.1174.29.camel@agnes.fremen.dune> References: <1076836918.1174.29.camel@agnes.fremen.dune> Message-ID: <20040216172301.GD22506@server4.8080.it> On Sun, Feb 15, 2004 at 10:22:12AM +0100, Jean Francois Martinez wrote: > Yum has for now two serious shortcomings > > 1) It has no browser, even a curses based one. You cannot, like > with apt or urpmi, browse what is available, select what you are > interested in and have it installed But why would you need that, when a recent version of bash-completion lets you do something like yum install ? ;) (some might argue to have bash-completion in FC or even installed by default) Rudi From jdennis at redhat.com Mon Feb 16 17:23:04 2004 From: jdennis at redhat.com (John Dennis) Date: Mon, 16 Feb 2004 12:23:04 -0500 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <20040216170232.11491.qmail@hm36.locaweb.com.br> References: <1076949808.4176.220.camel@sirendipity.dogma.lan> <20040216170232.11491.qmail@hm36.locaweb.com.br> Message-ID: <1076952184.1313.34.camel@finch.boston.redhat.com> My understanding is that squirrelmail does not demand usage of php-imap but will exhibit better performance if it does use it. With respect to php-imap, it does depend on and build against the c-client library that was part of the UW imap-devel package. I believe those who have pointed out that php-imap is disabled in FC2 are correct. To support php-imap, if its really needed, would require an rpm with c-client libs in it. From toshio at tiki-lounge.com Mon Feb 16 17:31:30 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 16 Feb 2004 12:31:30 -0500 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076763963.9498.169.camel@bobcat.mine.nu> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> Message-ID: <1076952688.3227.24.camel@Madison.badger.com> On Sat, 2004-02-14 at 08:06, Ville Skytt? wrote: > > Much more feedback from the target group of these changes is necessary. > > Yep. But let's start experimenting with this stuff to get some hands-on > experience how it feels. Am I the target group? :-) I just QA'd a package and tried out giving it a first-review attachment. I think it's significantly different than the current approach and marginally more work. I think the learning curve might be a tad more (Currently we submit a new comment for everything: package submission & QA submission. On top of that we have to remember to set keywords. In this scheme package submission would be add attachment, upload file. QA: edit attachment & remember to set status. And remember to set keywords when necessary.) Maybe the future would be substitute attachment statuses for changable keywords (PUBLISH, NEEDSWORK, etc would be an attachment status. rh9/1/2 would be keyword.) Most of the extra work with using attachments is because the bugzilla UI isn't geared towards doing this. For instance, I found I had to set the attachment status as a separate step from submitting the attachment (Would not happen if the original attachment was the package submission.) Additionally, the UI lends itself to confusion in this case: where we currently have the submission form on the first bugzilla form, in an attachment scheme we'd have to leave the tempting Add comment form blank and click to the add/edit attachment page to do our work. I think a new keyword is a simpler solution that gets us the bare essentials of what we want. The attachment is more elegant in it's representation of the data, but we need to enhance the UI to make it work well. -Toshio -- Toshio From surak at casa.surak.eti.br Mon Feb 16 16:50:16 2004 From: surak at casa.surak.eti.br (Alexandre) Date: Mon, 16 Feb 2004 13:50:16 -0300 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <1076949808.4176.220.camel@sirendipity.dogma.lan> References: <200402131248.i1DCmfmA005990@d103.fi.basen.net> <20040216114537.GA6685@redhat.com> <4030B013.8050702@sohanet.de> <1076945169.11167.4.camel@ahrak.surak.eti.br> <1076949137.1313.12.camel@finch.boston.redhat.com> <1076949808.4176.220.camel@sirendipity.dogma.lan> Message-ID: <1076950215.11167.21.camel@ahrak.surak.eti.br> Em Seg, 2004-02-16 ?s 13:43, Alexander Dalloz escreveu: > (....) > > Correct me if I'm wrong but I thought squirrelmail depended on imap, not > > on some particular imap or its underlying library. FC2 will have cyrus > > imap and dovecot. Isn't this an alternative solution? > Each webmail application requires an IMAP/POP server. But how does > squirrelmail does contact the server? I thought squirrelmail is written > in PHP, just like Horde/IMP which I am using. Horde/IMP needs the > php-imap support to establish the connection to the server. I believe > Alexandre had that in mind too. That's exactly what I had in mind. In fact, it didn't work at the first time I've installed it, as squirrelmail was complaining about php-imap support. Installing php-imap package solved it, until now. From surak at casa.surak.eti.br Mon Feb 16 16:52:04 2004 From: surak at casa.surak.eti.br (Alexandre) Date: Mon, 16 Feb 2004 13:52:04 -0300 Subject: include php-imap in FC2 (bug #115535) In-Reply-To: <20040216170232.11491.qmail@hm36.locaweb.com.br> References: <1076949808.4176.220.camel@sirendipity.dogma.lan> <20040216170232.11491.qmail@hm36.locaweb.com.br> Message-ID: <1076950323.11167.24.camel@ahrak.surak.eti.br> Em Seg, 2004-02-16 ?s 13:02, Pedro Fernandes Macedo escreveu: > I also looked at the functions dir of squirrelmail and it looks like squirrelmail has its own imap access routines.. But having php-imap is interesting , as other tools like Horde/IMP need this package.. It didn't use to work without php-imap. My personal experience about it.. It didn't complained to install, but didn't work. From icon at linux.duke.edu Mon Feb 16 18:05:08 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Mon, 16 Feb 2004 13:05:08 -0500 Subject: Keyboard switcher in test1 Message-ID: <40310654.2050100@linux.duke.edu> Hello, all: The gnome keyboard switching applet in test1 doesn't work -- it gives an OAFID error. It's a real hindrance to some of us who like switching their keyboard layouts for fun and profit. :) What needs to be done to resolve this issue? I don't think it's upstream, and b.r.c searching is not giving me any results. Cheers, -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE I am looking for a job in Canada! http://linux.duke.edu/~icon/cajob.ptml From ms-nospam-0306 at arcor.de Mon Feb 16 18:37:10 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 16 Feb 2004 19:37:10 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1076952688.3227.24.camel@Madison.badger.com> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> Message-ID: <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> On Mon, 16 Feb 2004 12:31:30 -0500, Toshio wrote: > On Sat, 2004-02-14 at 08:06, Ville Skytt? wrote: > > > Much more feedback from the target group of these changes is necessary. > > > > Yep. But let's start experimenting with this stuff to get some hands-on > > experience how it feels. > > Am I the target group? :-) Yes. :) > I just QA'd a package and tried out giving > it a first-review attachment. I think it's significantly different than > the current approach and marginally more work. Thanks for trying! I've noticed, too, that creating an attachment and changing the bugzilla keywords line are separate steps. And someone who submitted the second-review would need three steps (attach, change status, change keywords). Personally, I wouldn't mind the extra step for setting the attachment status. But that's why feedback is needed. E.g. I like how attachments solve the problem of invalidated GPG signatures (I haven't had any of those myself, though). > I think a new keyword is a simpler solution that gets us the bare > essentials of what we want. Votes on what keyword to try are still taken. REVIEWED has been preferred, it seems. I've thought about another keyword like ON_QA as a silent indicator from someone adding himself to the "Cc" field that he's planned to review the package. Of course, a short comment would be sufficient, albeit not searchable. Btw, I think there ought to be more communication between packagers and reviewers anyway, so a packager doesn't apply severe modifications while a reviewer is checking the current release. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From leonard at den.ottolander.nl Mon Feb 16 18:46:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 16 Feb 2004 19:46:36 +0100 Subject: Fedora Update Notifications In-Reply-To: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> References: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> Message-ID: <1076957196.4747.18.camel@athlon.localdomain> Hello Chris, Thomas, Jay, Thanks for releasing these security updates. Is it maybe possible that the developers decide on a common subject format for update notifications? Since all these three are security related the tag [SECURITY] would have been a nice add on. Also the subjects vary in more ways. Two are speaking of Fedora, but only one also mentions the version. Something like [SECURITY] Fedora Core Update: would be a good solution. Such a subject format of course has to be communicated to all developers. Another solution would be to set up a central organ that would release all security update notifications. Something like a Fedora Security Announcement Team (F-SAT). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From Bernd.Bartmann at sohanet.de Mon Feb 16 19:02:26 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Mon, 16 Feb 2004 20:02:26 +0100 Subject: Fedora Update Notifications In-Reply-To: <1076957196.4747.18.camel@athlon.localdomain> References: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> <1076957196.4747.18.camel@athlon.localdomain> Message-ID: <403113C2.8040909@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leonard den Ottolander schrieb: | Hello Chris, Thomas, Jay, | | Thanks for releasing these security updates. Is it maybe possible that | the developers decide on a common subject format for update | notifications? Since all these three are security related the tag | [SECURITY] would have been a nice add on. | | Also the subjects vary in more ways. Two are speaking of Fedora, but | only one also mentions the version. Something like | [SECURITY] Fedora Core Update: | would be a good solution. | | Such a subject format of course has to be communicated to all | developers. Another solution would be to set up a central organ that | would release all security update notifications. Something like a Fedora | Security Announcement Team (F-SAT). Exactly. I already suggested the same thing a long time ago but nodoby seems to care :-((. Also still missing is a central web-site listing all Fedora errata/update advisories. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAMRPBkQuIaHu84cIRArzOAKCqnF4zPThvCgKo4SYPx9AG8lp4UACgleqx zoG3QNevn0wLKV/jUWPOtRA= =+LsG -----END PGP SIGNATURE----- From surak at casa.surak.eti.br Mon Feb 16 18:20:04 2004 From: surak at casa.surak.eti.br (Alexandre) Date: Mon, 16 Feb 2004 15:20:04 -0300 Subject: Developing graphical applications Message-ID: <1076955604.11167.69.camel@ahrak.surak.eti.br> Hello list, I want to develop a surveillance application, which would run on a fedora machine. This application will capture images from a bt878 card (4-input type), and show the four inputs on a single window. This is quite simple to do on C with SDL, in fullscreen, using video4linux functions to grab the images from bt878, and creating 4 sdl surfaces, one for each window. However, as the application gets more complex, develop a user interface in fullscreen, in C, is too much complicated to develop and maintain. So, I decided to use GTK for the interface, and python as the development language, which would make me learn python also, this would make much easier to develop windows, menus and dialogs with glade, and just put the captured images on the right places. My problem begins here: How I put a image window inside a gtk container, in python. And this image needs to be updated fast, as the surveillance cameras are sending data all the time. something like 6fps for each window would be ok. And all of this must run in Fedora, with the minimum external dependencies possible (the reason I've posted it here, and not in a python list). I though of pygame (python + sdl), but it won't do, as a surface needs to be in its own window. Don't know how I could do this under a GTK window... Any advice? Thanks for your reply. []s Alexandre Strube From tony at tgds.net Mon Feb 16 19:26:38 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 16 Feb 2004 20:26:38 +0100 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel Message-ID: <1076957661.27602.27.camel@localhost.localdomain> >> OK so I installed a fresh VMware Workstation 3.2.1 and patched it >> with vmware-any-any50. Exact same error. > Do not use Fedora's prebuilt kernels with 3.2.1. RedHat broke /dev/mem > completely, so you can use it only as root (and even that is > questionable). > If you'll build your kernel from Linus's sources, it will work. It > is impossible to fix this problem with binary patch, just whole > RedHat's idea about /dev/mem is broken. > Petr I can confirm that not even the root user can run vmware with 2.6.1x kernel. My kernel was built from the 2.6.1-1.37 SRC rpm. Is this a Fedora problem or a vmware problem? Cheers Tony Grant -- www.tgds.net Library management software toolkit From wtogami at redhat.com Mon Feb 16 20:00:30 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 16 Feb 2004 10:00:30 -1000 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <1076957661.27602.27.camel@localhost.localdomain> References: <1076957661.27602.27.camel@localhost.localdomain> Message-ID: <4031215E.7030500@redhat.com> Tony Grant wrote: >>>OK so I installed a fresh VMware Workstation 3.2.1 and patched it >>>with vmware-any-any50. Exact same error. > > >>Do not use Fedora's prebuilt kernels with 3.2.1. RedHat broke /dev/mem >>completely, so you can use it only as root (and even that is >>questionable). >>If you'll build your kernel from Linus's sources, it will work. It >>is impossible to fix this problem with binary patch, just whole >>RedHat's idea about /dev/mem is broken. >> Petr > > > I can confirm that not even the root user can run vmware with 2.6.1x > kernel. My kernel was built from the 2.6.1-1.37 SRC rpm. > > Is this a Fedora problem or a vmware problem? > > Cheers > > Tony Grant > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115769 I have total success running vmware workstation 4.0.5 within latest FC2 after using vmware-any-any-update50. Warren From felipe_alfaro at linuxmail.org Mon Feb 16 20:08:46 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 16 Feb 2004 21:08:46 +0100 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <1076957661.27602.27.camel@localhost.localdomain> References: <1076957661.27602.27.camel@localhost.localdomain> Message-ID: <1076962125.1914.4.camel@teapot.felipe-alfaro.com> On Mon, 2004-02-16 at 20:26, Tony Grant wrote: > I can confirm that not even the root user can run vmware with 2.6.1x > kernel. My kernel was built from the 2.6.1-1.37 SRC rpm. I'm running VMware 4.5.0 build-7174 on 2.6.2 with no problems at all, with an exception: I had to modify the sources for the vmmon kernel module to remove the _exit(1) syscall which is totally absurd for a module and causes errors when compiling on -mm kernels. > Is this a Fedora problem or a vmware problem? What is your problem exactly? From ed at redhat.com Mon Feb 16 20:35:03 2004 From: ed at redhat.com (Edward C. Bailey) Date: Mon, 16 Feb 2004 15:35:03 -0500 Subject: Thoughts on how to structure the release notes... Message-ID: Hello all, A while ago, I broached the subject of release notes quality on fedora-list. and asked for feedback on ways to make the release notes better. One of the subjects mentioned was to make the content more accessible by splitting things up a bit more, possibly by using RPM's package groups. I personally liked the concept behind that idea, though I thought using more newbie-friendly groups might be a better choice. Since the package groups used by Anaconda are a bit easier to understand, I thought it would be better to use the groups defined by the comps.xml file. My plan (for Fedora Core 2 Test 2) is to structure the release notes to use the following list of groups. That doesn't mean every one of these groups will be present in the release notes -- only that, if something needs to be said about a given package, that content will be put in the release notes, under a heading reflecting that package's group. For example, if I need to write something about emacs, it'll appear under the "Emacs" heading. On the other hand, if nothing needs to be written about emacs, the "Emacs" heading will not be present in the release notes. Here are some of the groups that are currently used in Fedora Core 2 Test 1: Administration Tools Authoring and Publishing Base Compatibility Arch Development Support Compatibility Arch Support Core DNS Name Server Development Libraries Development Tools Dialup Networking Support Editors Emacs Engineering and Scientific FTP Server GNOME Desktop Environment GNOME Software Development Games and Entertainment Graphical Internet Graphics KDE Desktop Environment KDE Software Development Kernel Development Legacy Software Development Mail Server Network Servers News Server Office/Productivity Printing Support Ruby SQL Database Server Server Configuration Tools Sound and Video Supported Packages System Tools Text-based Internet Web Server Windows File Server X Software Development X Window System XEmacs These are not the only groups; there are also groups that relate to the support of various languages. There are quite a few, and given that I doubt there would be much that needs to be written about them, I feel that it would be easier to compress them into a single "Internationalization Support" heading. Here are the groups: Arabic Support Assamese Support Bengali Support Brazilian Support British Support Catalan Support Chinese Support Cyrillic Support Czech Support Danish Support Dutch Support Estonian Support Finnish Support French Support German Support Greek Support Hebrew Support Hungarian Support ISO8859-2 Support ISO8859-9 Support Italian Support Japanese Support Korean Support Norwegian Support Polish Support Portuguese Support Romanian Support Russian Support Serbian Support Slovak Support Slovenian Support Spanish Support Swedish Support Turkish Support Ukrainian Support Hmmm. Of course, if there's not much of a chance that there will be a lot of content for packages under these groups, maybe it doesn't matter, and if something noteworthy about the kde-i18n-Hungarian package needs to be said, perhaps it should be said under the "Hungarian Support" heading... :-) In any case, what does everyone think? Is this a good change, a bad change, or just a change? Ed -- Ed Bailey Red Hat, Inc. http://www.redhat.com/ From dax at gurulabs.com Mon Feb 16 20:43:17 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 16 Feb 2004 13:43:17 -0700 Subject: Fixing the numlock problem Message-ID: <1076964197.2818.68.camel@mentor.gurulabs.com> As I mentioned earlier (and got no responses on). SUSE does the right thing in respect to the numlock key. The default behavior on SUSE is to follow the BIOS. To check the BIOS setting, SUSE use the command hwinfo. I'm wondering if that functionality could be added to kudzu? Both hwinfo and kudzu are GPL. The source can be obtained here: ftp://ftp.suse.com/pub/suse/i386/9.0/suse/src/hwinfo-7.30-32.src.rpm Here is how it is pieced together: /etc/sysconfig/keyboard ::::::::::: # # NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting) KBD_NUMLOCK="bios" ::::::::::: /etc/init.d/kbd ::::::::::: elif test "$KBD_NUMLOCK" = "bios"; then /usr/sbin/hwinfo --bios|grep -q 'Num Lock: on' ::::::::::: I'm wondering if that functionality could be added to kudzu? Both hwinfo and kudzu are GPL. The source can be obtained here: ftp://ftp.suse.com/pub/suse/i386/9.0/suse/src/hwinfo-7.30-32.src.rpm Incidentally, on my system 'hwinfo --bios' produces the following output: 01: None 00.0: 10105 BIOS [Created at bios.92] Unique ID: rdCR.lZF+r4EgHp4 Hardware Class: bios BIOS Keyboard LED Status: Scroll Lock: off Num Lock: on Caps Lock: off Serial Port 0: 0x3f8 Parallel Port 0: 0x378 Base Memory: 639k PnP BIOS: @@@0000 MP spec rev 1.4 info: OEM id: "DELL" Product id: "Dim 4600" 1 CPUs (0 disabled) SMBIOS Version: 2.3 BIOS Info: Vendor: "Dell Computer Corporation" Version: "A03" Date: "07/21/2003" Features: 001b00003c29de80 00000317 PCI supported PnP supported APM supported BIOS flashable BIOS shadowing allowed ESCD supported CD boot supported Selectable boot supported EDD spec supported ACPI supported USB Legacy supported AGP supported LS-120 boot supported BIOS Boot Spec supported System Info: Manufacturer: "Dell Computer Corporation" Product: "Dimension 4600" Serial: "7L4YF31" Wake-up: 0x06 (Power Switch) Board Info: Manufacturer: "Dell Computer Corp." Product: "02Y832" Serial: "..CN4811136F01W1." Chassis Info: Manufacturer: "Dell Computer Corporation" Type: 0x06 (Mini Tower) Processor Info: Processor Socket: "Microprocessor" (ZIF Socket) Processor Manufacturer: "Intel" Voltage: 1.1 V External Clock: 800 Max. Speed: 3200 Current Speed: 2800 Status: 0x41 (Socket Populated, CPU Enabled) On Board Devices: Ethernet: "Intel Pro 100 VE Network Connection" On Board Devices: Sound: "AC'97 Audio Controller" OEM Strings: www.dell.com Language Info: Languages: en|US|iso8859-1 Current: en|US|iso8859-1 Physical Memory Array: Max. Size: 4 GB (No Error Correction) Memory Device: Location: "CHANNEL A DIMM 0" Size: 256 MB Type: 64 bits, Syncronous SDRAM, DIMM Speed: 400 MHz Memory Device: Location: "CHANNEL B DIMM 0" Size: 256 MB Type: 64 bits, Syncronous SDRAM, DIMM Speed: 400 MHz Memory Device: Location: "CHANNEL A DIMM 1" Size: No Memory Installed Memory Device: Location: "CHANNEL B DIMM 1" Size: No Memory Installed Config Status: cfg=no, avail=yes, need=no From notting at redhat.com Mon Feb 16 20:58:38 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Feb 2004 15:58:38 -0500 Subject: Fixing the numlock problem In-Reply-To: <1076964197.2818.68.camel@mentor.gurulabs.com> References: <1076964197.2818.68.camel@mentor.gurulabs.com> Message-ID: <20040216205838.GA28335@devserv.devel.redhat.com> Dax Kelson (dax at gurulabs.com) said: > The source can be obtained here: > > ftp://ftp.suse.com/pub/suse/i386/9.0/suse/src/hwinfo-7.30-32.src.rpm Sure, taking patches. :) From the post, looks like a DMI wrapper. Aside from that, feel free to file a bug, it will get looked at eventually. Bill From toshio at tiki-lounge.com Mon Feb 16 21:23:38 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 16 Feb 2004 16:23:38 -0500 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> Message-ID: <1076966616.3227.44.camel@Madison.badger.com> I just found another difference with attachments: Whereas a comment is emailed to the other people on the CC list/reporter/etc, the attachment is not. So the email that is sent has very little value. I probably will miss the details most when an updated package is released with the URL listed in an attachment as I'll have to hit bugzilla to find the URL instead of copying from the email and using wget to retrieve it. I also find it can be useful to get emails showing me what things other people look for in QA (non-showstoppers, what information is relevant to a QA report, etc.) -Toshio On Mon, 2004-02-16 at 13:37, Michael Schwendt wrote: > On Mon, 16 Feb 2004 12:31:30 -0500, Toshio wrote: > > > On Sat, 2004-02-14 at 08:06, Ville Skytt? wrote: > > > > Much more feedback from the target group of these changes is necessary. > > > > > > Yep. But let's start experimenting with this stuff to get some hands-on > > > experience how it feels. > > > > Am I the target group? :-) > > Yes. :) > > > I just QA'd a package and tried out giving > > it a first-review attachment. I think it's significantly different than > > the current approach and marginally more work. > > Thanks for trying! I've noticed, too, that creating an attachment and > changing the bugzilla keywords line are separate steps. And someone who > submitted the second-review would need three steps (attach, change status, > change keywords). Personally, I wouldn't mind the extra step for setting > the attachment status. But that's why feedback is needed. > > E.g. I like how attachments solve the problem of invalidated GPG > signatures (I haven't had any of those myself, though). > > > I think a new keyword is a simpler solution that gets us the bare > > essentials of what we want. > > Votes on what keyword to try are still taken. REVIEWED has been > preferred, it seems. > > I've thought about another keyword like ON_QA as a silent indicator from > someone adding himself to the "Cc" field that he's planned to review the > package. Of course, a short comment would be sufficient, albeit not > searchable. > > Btw, I think there ought to be more communication between packagers and > reviewers anyway, so a packager doesn't apply severe modifications while a > reviewer is checking the current release. -- Toshio From tony at tgds.net Mon Feb 16 21:27:03 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 16 Feb 2004 22:27:03 +0100 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <4031215E.7030500@redhat.com> References: <1076957661.27602.27.camel@localhost.localdomain> <4031215E.7030500@redhat.com> Message-ID: <1076966823.27602.33.camel@localhost.localdomain> Le lun 16/02/2004 ? 21:00, Warren Togami a ?crit : > >>Do not use Fedora's prebuilt kernels with 3.2.1 ^^^^^ > I have total success running vmware workstation 4.0.5 within latest FC2 > after using vmware-any-any-update50. vmware 4x does not run on the Epia-M CPU. That is why I run 3.2.1 which works just fine for my daily needs. I stopped working after 2.6.0xxx series kernels. I had dual boot machines and 2.6.1 has all the VIA stuff I need for DVB-S and other Epia specific tweeks are falling into place quite nicely. What happened to /dev/mem between 2.6.0 and 2.6.1? Cheers Tony Grant -- www.tgds.net Library management software toolkit From toshio at tiki-lounge.com Mon Feb 16 22:23:18 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 16 Feb 2004 17:23:18 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: References: Message-ID: <1076970196.3227.104.camel@Madison.badger.com> warning: a tad long warning2: just my two cents. read with a grain of salt. disclaimers ad nauseum On Mon, 2004-02-16 at 15:35, Edward C. Bailey wrote: > My plan (for Fedora Core 2 Test 2) is to structure the release notes to > use the following list of groups. That doesn't mean every one of these > groups will be present in the release notes -- only that, if something > needs to be said about a given package, that content will be put in the > release notes, under a heading reflecting that package's group. > I like the idea of more structure. I don't know if I agree with using comps.xml for groups, though. My usage of the release notes is to read them before the install. They inform my decisions about what software I want on my system, which software I can do without, and which software will try to replace software I already use. I want to see major sections of exciting/important architectural changes with subsections dealing with specific things that went into making this happen. So I would like groups based on changes to the distro rather than groups based on lists of programs. (Ie: selinux group w/ description of selinux and how packages have changed/been added to make this work.) That might be a lot more work though as it requires a human to decide what the overall themes are and construct how those themes fit with the changes in the features of indiidual packages. If a package-based scheme is adopted, I think the groups should be thought out a little more. Even though the release notes are a flat file, there should be a hierarchy to it (So emacs, xemacs, and editors can be together; development tools and ruby; etc) If a group has too many worthy changes, then subsections can be broken out. If not, then keep the changes together so the grouping reduces the number of things I'm thinking about rather than increases it. Once again, just my two cents. I'm sure I'll find useful whatever format is produced. -Toshio -- Toshio From leonard at den.ottolander.nl Mon Feb 16 22:39:49 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 16 Feb 2004 23:39:49 +0100 Subject: Thoughts on how to structure the release notes... In-Reply-To: References: Message-ID: <1076971189.4747.47.camel@athlon.localdomain> Hello Edward, > Base > Core What's the difference between these two? Or more specifically, what is Core? > Emacs > XEmacs Shouldn't these be moved to Office/Productivity? > Ruby Move to Development Tools? > Supported Packages ? > I feel that > it would be easier to compress them into a single "Internationalization > Support" heading. Sure. > Is this a good change, a bad change, or just a change? Using obvious package groups is a good idea IMO, as is good documentation in general. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pp at ee.oulu.fi Mon Feb 16 23:00:40 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 17 Feb 2004 01:00:40 +0200 Subject: XFree86 4.3.0-56 EPIA test results Message-ID: <20040216230040.GA29706@ee.oulu.fi> Hiya I did some testing on the new via XFree86 driver, and it certainly works a lot better than the old one (which didn't work at all for me :-) ) Biggest annoyance was Xv not working very well (basically the colors were quite a bit off, hard to explain how :-) ). Grabbing the driver from http://www.shipmail.org/%7Ethomas/via/xfree43/epia7.2/ fixed that. For DRI I just patched 2.6.2-1.81 with http://epia.kalf.org/gryle_patches/via-v4l-1.4a-drm.patch.gz (with use of floating point in ddmpeg.c fixed, there are two uses of *1.5 in the code, which were trivially fixed :-). With http://www.uk.linux.org/~alan/via_dri.so that was enough to make glx and tuxracer work (colors were somewhat off in the latter, tho...) Will bugzilla once -57 (and the devel kernel with via dri support the existance of which was suggested a while back, but which is nowhere to be found), that hopefully should make the dust settle enough to a bug report to be useful at all :-) -- Pekka Pietikainen From dax at gurulabs.com Tue Feb 17 00:11:08 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 16 Feb 2004 17:11:08 -0700 Subject: bug created for "fix numlock" Message-ID: <1076976668.4509.4.camel@mentor.gurulabs.com> Add comments or yourself to the CC if you wish: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115909 From bart.martens at chello.be Tue Feb 17 00:15:38 2004 From: bart.martens at chello.be (Bart Martens) Date: Tue, 17 Feb 2004 01:15:38 +0100 Subject: Fedora Update Notifications In-Reply-To: <403113C2.8040909@sohanet.de> References: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> <1076957196.4747.18.camel@athlon.localdomain> <403113C2.8040909@sohanet.de> Message-ID: <1076976938.1591.12.camel@localhost.localdomain> On Mon, 2004-02-16 at 20:02, Bernd Bartmann wrote: > Also still missing is a central web-site listing all > Fedora errata/update advisories. You can find the released updates listed on FedoraNews. http://fedoranews.org/updates/ Note that evolution-1.4.5-7 still shows Red Hat errata. Since the list of Fedora Core updates is also available in XML format on the FedoraNews website (thank you Thomas Chung and Colin Charles), I replaced the newsfeed of Red Hat errata by a newsfeed of Fedora Core updates. http://fedoranews.org/rss/fedora-updates.xml https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113798 Bart Martens -------------- 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 cornette at insight.rr.com Tue Feb 17 02:38:59 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Mon, 16 Feb 2004 21:38:59 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: References: Message-ID: <40317EC3.3090206@insight.rr.com> Edward C. Bailey wrote: >Hello all, > > A while ago, I broached the subject of release notes quality on >fedora-list. and asked for feedback on ways to make the release notes >better. One of the subjects mentioned was to make the content more >accessible by splitting things up a bit more, possibly by using RPM's >package groups. > > I personally liked the concept behind that idea, though I thought using >more newbie-friendly groups might be a better choice. Since the package >groups used by Anaconda are a bit easier to understand, I thought it would >be better to use the groups defined by the comps.xml file. > > My plan (for Fedora Core 2 Test 2) is to structure the release notes to >use the following list of groups. That doesn't mean every one of these >groups will be present in the release notes -- only that, if something >needs to be said about a given package, that content will be put in the >release notes, under a heading reflecting that package's group. > > For example, if I need to write something about emacs, it'll appear >under the "Emacs" heading. On the other hand, if nothing needs to be >written about emacs, the "Emacs" heading will not be present in the release >notes. > >Here are some of the groups that are currently used in Fedora Core 2 Test >1: > >Administration Tools >Authoring and Publishing >---etc > > The use of the categories from the group selection sounds like a good idea. Maybe a bit more compression with the categories might be better for a less cluttered page. Since the categories won't all need commenting on. It might work out using the same selections. I would like to see an install and upgrade section. The upgrade to list programs removed or added, plus any additional hints on importing the new programs or removing the orphaned programs from the upgraded system. On the install section. Things concerning what hardware needs special attention and things related to known issues concerning the current test or final release. Jim From mike at flyn.org Tue Feb 17 04:10:34 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 16 Feb 2004 22:10:34 -0600 Subject: FC1.90 orhphaned directory report In-Reply-To: <871xoz9cpm.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87eksz9lsz.fsf@kosh.ultra.csn.tu-chemnitz.de> <871xoz9cpm.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20040217041033.GA16196@imp.flyn.org> >> I updated the report about used-but-unowned directories to the state of >> FC1.90. The results can be seen at >> >> http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/fc1.90.html.gz > > Based on changelog entries I sorted it by authors (some mappings are > obviously wrong, but most should be correct): > > http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/fc1.90-author.html.gz [...] I've also been independently working on this problem. I have made several bug reports related to unowned files. Many have been fixed. For what it is worth here is the list of related Bugzilla bugs that have not been fixed (all exist in Core 2 Test 1): o [Bug 112871] /usr/include/acl is not owned by libacl-devel package o [Bug 112872] /usr/include/attr is not owned by the libattr package o [Bug 112874] /usr/include/libgsf-1 is not owned by package o [Bug 112863] /etc/gconf/2 is not owned by package o [Bug 113774] /usr/share/doc/acl is not owned in package o [Bug 113779] /usr/share/doc/attr is not owned by package o [Bug 113822] /usr/share/doc/HTML not owned by package o [Bug 114475] Files and directories not owned by package (mozilla-1.6) o [Bug 114652] Directories not owned by package o [Bug 114692] stuff not owned by xscreensaver o [Bug 113046] /usr/lib/gnumeric/1.2.1-bonobo/plugins is not owned by package o [Bug 113544] Several directories are not owned by packages (/usr/share/man/cs) -- Mike :wq From mharris at redhat.com Tue Feb 17 05:52:16 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 17 Feb 2004 00:52:16 -0500 (EST) Subject: XFree86 4.3.0-56 EPIA test results In-Reply-To: <20040216230040.GA29706@ee.oulu.fi> References: <20040216230040.GA29706@ee.oulu.fi> Message-ID: On Tue, 17 Feb 2004, Pekka Pietikainen wrote: >I did some testing on the new via XFree86 driver, and it >certainly works a lot better than the old one (which didn't work >at all for me :-) ) Wonderful! >For DRI I just patched 2.6.2-1.81 with >http://epia.kalf.org/gryle_patches/via-v4l-1.4a-drm.patch.gz >(with use of floating point in ddmpeg.c fixed, there are two uses of *1.5 in >the code, which were trivially fixed :-). With >http://www.uk.linux.org/~alan/via_dri.so that was enough to make glx and >tuxracer work (colors were somewhat off in the latter, tho...) Good to hear. >Will bugzilla once -57 (and the devel kernel with via dri >support the existance of which was suggested a while back, but >which is nowhere to be found), that hopefully should make the >dust settle enough to a bug report to be useful at all :-) -57 is now ready, and includes the via_dri.so module properly. Please test the 4.3.0-57 package out using the included via_drv.o 2D driver, via_dri.so 3D driver, and ensuring you're not using 3rd party bits, so the testing is clean. Thanks for testing, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 17 06:00:40 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 17 Feb 2004 01:00:40 -0500 (EST) Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) Message-ID: I just sent an email to fedora-devel-list and got back this autoresponder. I fear that if people like this are permitted to have such broken mail configurations, that people wont want to post to the list. I know I don't want to get back autoresponders just for posting to the list, and I'd prefer to unsubscribe than to get such nonsense back. Are other people getting this garbage? Perhaps we should remove this person from the list until they correct their broken email configuration? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ---------- Forwarded message ---------- Date: Mon, 16 Feb 2004 23:53:04 -0600 From: jslivko at slackercentral.com To: mharris at redhat.com Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad The message you sent requires that you verify that you are a real live human being and not a spam source. To complete this verification, simply reply to this message and leave the subject line intact. The headers of the message sent from your address are show below: >From slacker at tbp.slackercentral.com Mon Feb 16 23:53:04 2004 Received: from slacker by tbp.slackercentral.com with local-bsmtp (Exim 4.24) id 1AsyAJ-0006EB-QZ for jslivko at slackercentral.com; Mon, 16 Feb 2004 23:53:04 -0600 Received: from [66.187.233.30] (helo=hormel.redhat.com) by tbp.slackercentral.com with esmtp (Exim 4.24) id 1AsyAJ-0006E7-LC for jslivko at slackercentral.com; Mon, 16 Feb 2004 23:53:03 -0600 Received: from listman.back-rdu.redhat.com (listman.back-rdu.redhat.com [10.10.2.136]) by hormel.redhat.com (Postfix) with ESMTP id 8D85D135D06; Tue, 17 Feb 2004 00:52:54 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.back-rdu.redhat.com (8.11.6/8.11.6) with ESMTP id i1H5oUB05225 for ; Tue, 17 Feb 2004 00:50:30 -0500 Received: (from mail at localhost) by int-mx1.corp.redhat.com (8.11.6/8.11.6) id i1H5qHG00314 for fedora-devel-list at listman.back-rdu.redhat.com; Tue, 17 Feb 2004 00:52:17 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i1H5qHi00310 for ; Tue, 17 Feb 2004 00:52:17 -0500 Received: from devel.capslock.lan (mharris.cipe.redhat.com [10.0.1.136]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i1H5qEkD006943 for ; Tue, 17 Feb 2004 00:52:14 -0500 From: "Mike A. Harris" X-X-Sender: mharris at devel.capslock.lan To: fedora-devel-list at redhat.com Subject: Re: XFree86 4.3.0-56 EPIA test results In-Reply-To: <20040216230040.GA29706 at ee.oulu.fi> Message-ID: References: <20040216230040.GA29706 at ee.oulu.fi> Organization: Red Hat Inc. X-Unexpected-Header: The Spanish Inquisition MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-loop: fedora-devel-list at redhat.com Errors-To: fedora-devel-list-admin at redhat.com X-BeenThere: fedora-devel-list at redhat.com X-Mailman-Version: 2.0.13 Precedence: junk Reply-To: fedora-devel-list at redhat.com List-Help: List-Post: List-Subscribe: , List-Id: Development discussions related to Fedora Core List-Unsubscribe: , List-Archive: Date: Tue, 17 Feb 2004 00:52:16 -0500 (EST) X-Spam-Exim: DcmpxlhWH3fXxaVh6UetEL6w X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on tbp.slackercentral.com X-Spam-Status: No, hits=-4.9 required=7.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: From jkeating at j2solutions.net Tue Feb 17 06:27:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Feb 2004 22:27:23 -0800 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: References: Message-ID: <200402162227.23565.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 16 February 2004 22:00, Mike A. Harris wrote: > Perhaps we should remove this person from the list until they > correct their broken email configuration? It's a flawed attempt at anti-spam software, by making email senders verify that they exist. It's really annoying, and extremely annoying when it happens on a mailing list. And yes, everybody who posts to the list will get this message from the l_user. - -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAMbRL4v2HLvE71NURAinXAJ4nLCeJ354zgLKGi+pAt0enqt4j6ACglo4z 5D6gytmdCwNosKK9arctXh0= =SaUs -----END PGP SIGNATURE----- From cgray at vosource.com Tue Feb 17 06:52:03 2004 From: cgray at vosource.com (Chris Gray) Date: Tue, 17 Feb 2004 00:52:03 -0600 Subject: Very OT: The Most Important Question In-Reply-To: <65160.65.41.204.93.1076990292.squirrel@65.41.204.93> Message-ID: <01b701c3f522$8e6f0700$0200a8c0@clglaptop> So, when do we get to buy new Fedora baseball caps like the wicked black low-profile Shadowman caps that Redhat sells? And what manner of Open Source project doesn't have cool t-shirts? Who's in charge of procuring and selling schwag? I will volunteer if the job isn't already filled. Seriously. Chris G. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.585 / Virus Database: 370 - Release Date: 2/11/2004 From mharris at redhat.com Tue Feb 17 07:47:31 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 17 Feb 2004 02:47:31 -0500 (EST) Subject: Very OT: The Most Important Question In-Reply-To: <01b701c3f522$8e6f0700$0200a8c0@clglaptop> References: <01b701c3f522$8e6f0700$0200a8c0@clglaptop> Message-ID: On Tue, 17 Feb 2004, Chris Gray wrote: >So, when do we get to buy new Fedora baseball caps like the wicked black >low-profile Shadowman caps that Redhat sells? And what manner of Open Source >project doesn't have cool t-shirts? > >Who's in charge of procuring and selling schwag? Red Hat. >I will volunteer if the job isn't already filled. Seriously. The Red Hat Shadowman logo is trademarked by Red Hat, please review the Red Hat trademark usage guidelines located at: http://www.redhat.com/about/corporate/trademark/guidelines.html I believe it would probably be in violation of acceptable use of the Red Hat trademark guidlines, however I am not a lawyer, and so I do not speak authoritatively of course. You'd have to consult with your own attourney to determine wether such usage of Red Hat trademarks would be ok or not. Not really on topic for this mailing list however. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Bernd.Bartmann at sohanet.de Tue Feb 17 08:24:37 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Tue, 17 Feb 2004 09:24:37 +0100 Subject: Fedora Update Notifications In-Reply-To: <1076976938.1591.12.camel@localhost.localdomain> References: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> <1076957196.4747.18.camel@athlon.localdomain> <403113C2.8040909@sohanet.de> <1076976938.1591.12.camel@localhost.localdomain> Message-ID: <4031CFC5.5020605@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bart Martens wrote: | On Mon, 2004-02-16 at 20:02, Bernd Bartmann wrote: | |>Also still missing is a central web-site listing all |>Fedora errata/update advisories. | | | You can find the released updates listed on FedoraNews. | | http://fedoranews.org/updates/ | | Note that evolution-1.4.5-7 still shows Red Hat errata. Since the list | of Fedora Core updates is also available in XML format on the FedoraNews | website (thank you Thomas Chung and Colin Charles), I replaced the | newsfeed of Red Hat errata by a newsfeed of Fedora Core updates. | | http://fedoranews.org/rss/fedora-updates.xml | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113798 Cool. Thanks Bart. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAMc/FkQuIaHu84cIRAlZhAJ9D0SYCNKbsXjTMSLF+iFbm/7GYoACgguIl CHk93cOgJ6mwSnQO86ZNu4o= =Q8MX -----END PGP SIGNATURE----- From lorenzo at reality.it Tue Feb 17 09:42:23 2004 From: lorenzo at reality.it (Lorenzo Luconi Trombacchi) Date: Tue, 17 Feb 2004 10:42:23 +0100 Subject: Fedora Update Notifications In-Reply-To: <4031CFC5.5020605@sohanet.de> References: <200402161046.i1GAk4Z08354@porkchop.devel.redhat.com> <1076957196.4747.18.camel@athlon.localdomain> <403113C2.8040909@sohanet.de> <1076976938.1591.12.camel@localhost.localdomain> <4031CFC5.5020605@sohanet.de> Message-ID: <4031E1FF.3050704@reality.it> Bernd Bartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bart Martens wrote: > > | On Mon, 2004-02-16 at 20:02, Bernd Bartmann wrote: > | > |>Also still missing is a central web-site listing all > |>Fedora errata/update advisories. > | > | > | You can find the released updates listed on FedoraNews. > | > | http://fedoranews.org/updates/ This is good, but probably an official released updates section for Fedora Core should be present in the official Fedora web site at http://fedora.redhat.com or at least a link to http://fedoranews.org or http://fedoranews.org/updates/ I think all Fedora people know fedora.redhat.com but many of them don't know the fedoranews.org web site. Lorenzo > > > - -- > Dipl.-Ing. (FH) Bernd Bartmann > I.S. Security and Network Engineer > SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin > Fon: +49 30 214783-44 / Fax: +49 30 214783-46 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAMc/FkQuIaHu84cIRAlZhAJ9D0SYCNKbsXjTMSLF+iFbm/7GYoACgguIl > CHk93cOgJ6mwSnQO86ZNu4o= > =Q8MX > -----END PGP SIGNATURE----- > > From ralph+fedora at strg-alt-entf.org Tue Feb 17 11:15:44 2004 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Tue, 17 Feb 2004 12:15:44 +0100 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: References: Message-ID: <20040217111544.GD12139@localhorst.br.de> Mike A. Harris wrote: > I just sent an email to fedora-devel-list and got back this > autoresponder. > Perhaps we should remove this person from the list until they > correct their broken email configuration? Yes, I am all for it. People using TMDA (or similar programs) without whitelisting mailing lists should ask themselves if they really know what they are doing. Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliverjohntibi at hotmail.com Tue Feb 17 12:19:57 2004 From: oliverjohntibi at hotmail.com (Oliver John Tibi) Date: Tue, 17 Feb 2004 20:19:57 +0800 Subject: Very OT: The Most Important Question References: <01b701c3f522$8e6f0700$0200a8c0@clglaptop> Message-ID: Dear Mike, I think Chris was referring to "whoever was selling Fedora goods", and not "whoever sells Red Hat products as Fedora goods". The term "Red Hat" was properly used as consumer identification. And besides, we all need to change our "look and feel", right? I sure could use a new blue Fedora baseball cap (or others might like a blue "Fedora" fedora)! And yes, who IS in charge of the merchandise? It's so nice to have one of them! Thanks, O.J. ----- Original Message ----- From: Mike A. Harris To: fedora-devel-list at redhat.com Sent: Tuesday, February 17, 2004 3:47 PM Subject: Re: Very OT: The Most Important Question On Tue, 17 Feb 2004, Chris Gray wrote: >So, when do we get to buy new Fedora baseball caps like the wicked black >low-profile Shadowman caps that Redhat sells? And what manner of Open Source >project doesn't have cool t-shirts? > >Who's in charge of procuring and selling schwag? Red Hat. >I will volunteer if the job isn't already filled. Seriously. The Red Hat Shadowman logo is trademarked by Red Hat, please review the Red Hat trademark usage guidelines located at: http://www.redhat.com/about/corporate/trademark/guidelines.html I believe it would probably be in violation of acceptable use of the Red Hat trademark guidlines, however I am not a lawyer, and so I do not speak authoritatively of course. You'd have to consult with your own attourney to determine wether such usage of Red Hat trademarks would be ok or not. Not really on topic for this mailing list however. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at stofanet.dk Tue Feb 17 12:42:23 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Tue, 17 Feb 2004 13:42:23 +0100 Subject: cd burn Message-ID: <1077021743.9561.1.camel@simba.lion> i have a problem with burning in the fc2 test1. if im running cdrecord -scanbus i get this. > [root at simba root]# cdrecord -scanbus > Cdrecord-Clone 2.01a25 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J?rg Schilling > cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open SCSI driver. > cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. > cdrecord: For possible transport specifiers try 'cdrecord dev=help'. > [root at simba root]# > > what could be wrong?? the new kernel dosnt use scsi emulation or?? > > Alex Leth From mihai at xcyb.org Tue Feb 17 12:42:38 2004 From: mihai at xcyb.org (Mihai Maties) Date: Tue, 17 Feb 2004 14:42:38 +0200 Subject: cdrdao-1.1.8 released In-Reply-To: <20040213202652.GA2560@nsk.no-ip.org> References: <402CC158.1000403@freemail.hu> <20040213202652.GA2560@nsk.no-ip.org> Message-ID: <200402171442.38566@xcyb0rg> On Friday 13 February 2004 22:26, Luciano Miguel Ferreira Rocha wrote: > > cdrdao-1.1.8 has just been released. > > It would be nice to have it in FC2 since it can > > write CDs without the ide-scsi emulation. > > cdrdao 1.1.7 on fedora-devel can write cds directly by ATAPI access: Does anyone successfully burned CDs with cdrdao on kernel 2.4 ? I tried both 1.1.7-8.atapi from rawhide and the final 1.1.8 and I was unable to write any CDs. I patched cdrdao myself a few months ago for this but the behaviour is the same: it detects the burner, it can blank a disk, but the write process fails with an "unable to retrieve drive capabilities page" error. I tried this on different systems (and different burners) but it failed every time (cdrecord/readcd works perfectly on these systems [using ATAPI]). The only thing I didn't try was running cdrdao on a 2.6 kernel so I was wondering if this is the problem... Mihai From mihai at xcyb.org Tue Feb 17 12:47:53 2004 From: mihai at xcyb.org (Mihai Maties) Date: Tue, 17 Feb 2004 14:47:53 +0200 Subject: cd burn In-Reply-To: <1077021743.9561.1.camel@simba.lion> References: <1077021743.9561.1.camel@simba.lion> Message-ID: <200402171447.53203@xcyb0rg> On Tuesday 17 February 2004 14:42, Alex Thomsen Leth wrote: > i have a problem with burning in the fc2 test1. > > if im running cdrecord -scanbus i get this. > > > [root at simba root]# cdrecord -scanbus > > Cdrecord-Clone 2.01a25 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J?rg > > Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. > > Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord > > -scanbus'. Make sure you are root. cdrecord: For possible transport > > specifiers try 'cdrecord dev=help'. [root at simba root]# > > > > what could be wrong?? the new kernel dosnt use scsi emulation or?? Use cdrecord -scanbus dev=ATAPI: instead and specify devices with "dev=ATAPI:/dev/hdc" or "dev=ATAPI:0,0,0". Mihai From peter.backlund at home.se Tue Feb 17 12:59:16 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 17 Feb 2004 13:59:16 +0100 Subject: cd burn In-Reply-To: <1077021743.9561.1.camel@simba.lion> References: <1077021743.9561.1.camel@simba.lion> Message-ID: <40321024.9060006@home.se> Alex Thomsen Leth wrote: > i have a problem with burning in the fc2 test1. > > if im running cdrecord -scanbus i get this. Wrong list. Try fedora-list at redhat.com. >>cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Follow that piece of advice. /Peter From tadams-lists at myrealbox.com Tue Feb 17 13:20:14 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 17 Feb 2004 08:20:14 -0500 Subject: gpg keys in FC2 test 1 Message-ID: <1077024014.2384.42.camel@aurora.localdomain> I don't know if I have a bug in my local system or what. However, every few days my public keyring seems to be erased. Even _my_ public keys are going away and I am having to redownload them. Is anyone else seeing this? I am not sure how to verify if this is a local install problem, or what. Thanks for any help. Trever -- "No man knows how bad he is till he has tried very hard to be good." -- C.S. Lewis From dstewart at atl.lmco.com Tue Feb 17 13:37:40 2004 From: dstewart at atl.lmco.com (Doug Stewart) Date: Tue, 17 Feb 2004 08:37:40 -0500 Subject: Very OT: The Most Important Question In-Reply-To: References: <01b701c3f522$8e6f0700$0200a8c0@clglaptop> Message-ID: <40321924.4030007@atl.lmco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oliver John Tibi wrote: | Dear Mike, | | I think Chris was referring to "whoever was selling Fedora goods", and not "whoever sells Red Hat products as Fedora goods". The term "Red Hat" was properly used as consumer identification. And besides, we all need to change our "look and feel", right? I sure could use a new blue Fedora baseball cap (or others might like a blue "Fedora" fedora)! | | And yes, who IS in charge of the merchandise? It's so nice to have one of them! | | Thanks, | O.J. | ----- Original Message ----- | From: Mike A. Harris | To: fedora-devel-list at redhat.com | Sent: Tuesday, February 17, 2004 3:47 PM | Subject: Re: Very OT: The Most Important Question | | | On Tue, 17 Feb 2004, Chris Gray wrote: | | >So, when do we get to buy new Fedora baseball caps like the wicked black | >low-profile Shadowman caps that Redhat sells? And what manner of Open Source | >project doesn't have cool t-shirts? | > | >Who's in charge of procuring and selling schwag? | | Red Hat. | | >I will volunteer if the job isn't already filled. Seriously. | | The Red Hat Shadowman logo is trademarked by Red Hat, please | review the Red Hat trademark usage guidelines located at: | | http://www.redhat.com/about/corporate/trademark/guidelines.html | | I believe it would probably be in violation of acceptable use of | the Red Hat trademark guidlines, however I am not a lawyer, and | so I do not speak authoritatively of course. | | You'd have to consult with your own attourney to determine wether | such usage of Red Hat trademarks would be ok or not. | | Not really on topic for this mailing list however. | | | -- | Mike A. Harris ftp://people.redhat.com/mharris | OS Systems Engineer - XFree86 maintainer - Red Hat | | | -- | fedora-devel-list mailing list | fedora-devel-list at redhat.com | http://www.redhat.com/mailman/listinfo/fedora-devel-list | I like the idea of Fedora merchandise, but first, don't we need to have an official logo? In that department, Fedora is sadly lacking... And, to keep this on topic, is there a fedora-artwork*.rpm underway, with "official" Fedora logo swag? If not, where do I submit the bugzilla RFE? *grin* - -- - ---------- Doug Stewart Systems Administrator/Web Applications Developer Lockheed Martin Advanced Technology Labs Quidquid latine dictum sit, altum viditur -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAMhkkN50Q8DVvcvkRAqWyAJ9/Av1vuokEFkXovl3Y9mW2G7SkkwCdFpcX kn4ooh6x4uSul6JWUsXzcco= =06bC -----END PGP SIGNATURE----- From ckloiber at redhat.com Tue Feb 17 14:37:38 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Tue, 17 Feb 2004 09:37:38 -0500 Subject: cd burn In-Reply-To: <200402171447.53203@xcyb0rg> References: <1077021743.9561.1.camel@simba.lion> <200402171447.53203@xcyb0rg> Message-ID: <1077028658.16493.2.camel@ckk.rdu.redhat.com> On Tue, 2004-02-17 at 07:47, Mihai Maties wrote: > On Tuesday 17 February 2004 14:42, Alex Thomsen Leth wrote: > > i have a problem with burning in the fc2 test1. > > > > if im running cdrecord -scanbus i get this. > > > > > [root at simba root]# cdrecord -scanbus > > > Cdrecord-Clone 2.01a25 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J?rg > > > Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. > > > Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord > > > -scanbus'. Make sure you are root. cdrecord: For possible transport > > > specifiers try 'cdrecord dev=help'. [root at simba root]# > > > > > > what could be wrong?? the new kernel dosnt use scsi emulation or?? > > Use > cdrecord -scanbus dev=ATAPI: > instead and specify devices with "dev=ATAPI:/dev/hdc" or "dev=ATAPI:0,0,0". Once you figure out what the device is, edit /etc/cdrecord.conf and add a line like: CDR_DEVICE=cdrw cdrw= ATAPI:0,0,0 48 4m burnfree After you do this, you should never have to specify dev= again (unless you have multiple burners). -- Chris Kloiber, RHCX Red Hat, Inc. From buildsys at redhat.com Tue Feb 17 14:51:06 2004 From: buildsys at redhat.com (Build System) Date: Tue, 17 Feb 2004 09:51:06 -0500 Subject: rawhide report: 20040217 changes Message-ID: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> New package commons-beanutils Jakarta Commons Beanutils Component New package commons-digester Jakarta Commons Digester Component New package commons-modeler Jakarta Commons Modeler Component New package mx4j Java Management Extensions (JMX) New package servletapi Jakarta Servlet and JSP APIs Updated Packages: XFree86-4.3.0-57 ---------------- * Sun Feb 15 2004 Mike A. Harris 4.3.0-57 - Oops, now we change DevelDriDrivers to DevelDRIDrivers so that the via DRI driver actually builds this time. - Oops, now we change '%define DevelDRIDrivers' to '#define DevelDRIDrivers' so that the via DRI driver actually builds this time. - Added XFree86-4.3.0-build-libXinerama-before-libGL-for-via-driver.patch because the via DRI driver links against libXinerama, and seems to be the only DRI driver which does so. This patch causes libXinerama to be compiled before libGL to ensure the via driver will link properly. apr-0.9.4-8 ----------- * Sun Feb 15 2004 Joe Orton 0.9.4-8 - rebuilt without -Wall -Werror * Fri Feb 13 2004 Elliot Lee 0.9.4-7 - rebuilt apr-util-0.9.4-9 ---------------- * Mon Feb 16 2004 Joe Orton 0.9.4-9 - fix sdbm apr_dbm_exists() on s390x/ppc64 * Fri Feb 13 2004 Elliot Lee 0.9.4-8 - rebuilt gpm-1.20.1-41 ------------- * Sat Feb 14 2004 Florian La Roche - already add shared lib symlinks at install time - fix subscript #114289 * Fri Feb 13 2004 Elliot Lee - rebuilt * Tue Nov 18 2003 Adrian Havill 1.20.1-39 - re-add the $OPTIONS that gets pulled in from /etc/sysconfig/gpm to the init.d script (#110248) kernel-2.6.2-1.85 ----------------- * Mon Feb 16 2004 Dave Jones - Merge to 2.6.3-rc3-bk1 - Optimise for size. (Saves ~300KB of kernel memory) - disable psaux emulation. - Enable i2c-via and i2c-viapro modules. kernel-utils-2.4-9.1.117 ------------------------ libxslt-1.1.3-1 --------------- * Mon Feb 16 2004 Daniel Veillard - upstream release 1.1.3 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems man-pages-ja-20040215-1 ----------------------- * Mon Feb 16 2004 Akira TAGOH 20040215-1 - updates to 20040215. * Fri Feb 13 2004 Elliot Lee - rebuilt pcmcia-cs-3.2.7-1.5 ------------------- * Mon Feb 16 2004 Bill Nottingham - add %triggerpostun on kernel-pcmcia-cs to recreate chkconfig links (#115732) perl-5.8.3-6 ------------ * Sun Feb 15 2004 Chip Turner 3:5.8.3-6 - fix very broken @INC calculations with slightly less broken @INC calculations (not perfectly handled but the result is correct) - fix broken -Dsitearch declaration * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Jan 28 2004 Chip Turner 3:5.8.3-5 - update incpush patch to better handle multilib prelink-0.3.0-21 ---------------- * Mon Feb 16 2004 Jakub Jelinek 0.3.0-21 - fix prelink abort in certain cases where a new PT_LOAD segment needs to be added (seen on AMD64) redhat-artwork-0.92-1 --------------------- * Mon Feb 16 2004 Than Ngo 0.92-1 - 0.92, fixed middle clicked on maximal and button double click on menu button rpm-4.3-0.11 ------------ * Sun Feb 15 2004 Jeff Johnson 4.3-0.11 - fix: set fcontext from pkg when file_contexts doesn't exist (#114040). - fix: set fcontext for "mkdir -p" directories not in packages. - fix: setfiles (aka rpmsx.c) dinna handle patterns correctly. - establish rpm_script_t before scriptlet exec. rpmdb-fedora-1.90-0.20040217 ---------------------------- samba-3.0.2-7 ------------- * Mon Feb 16 2004 Karsten Hopp 3.0.2-7 - fix ownership in -common package * Fri Feb 13 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Jay Fenlason - Change all requires lines to list an explicit epoch. Closes #102715 sysreport-1.3.9-1 ----------------- * Sun Feb 15 2004 Than Ngo 1.3.9-1 - search for "grub" info for boot only on x86, #115325 system-switch-mail-0.5.23-1 --------------------------- * Sun Feb 15 2004 Than Ngo 0.5.23-1 - 0.5.23 release * Tue Nov 25 2003 Than Ngo 0.5.22-1 - 0.5.22: renamed to system-switch-mail, support Exim MTA * Mon Sep 29 2003 Than Ngo 0.5.21-1 - 0.5.21, fixed Categories util-linux-2.12-2 ----------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 12 2004 Elliot Lee 2.12-1 - Final 2.12 has been out for ages - might as well use it. * Wed Jan 28 2004 Steve Dickson 2.12pre-4 - Added mount patches that have NFS version 4 support From cturner at redhat.com Tue Feb 17 15:29:53 2004 From: cturner at redhat.com (Chip Turner) Date: 17 Feb 2004 10:29:53 -0500 Subject: Perl requires/provides proposal In-Reply-To: <20040215121749.202c4c78.ms-nospam-0306@arcor.de> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> <20040215070408.6abfad99.ms-nospam-0306@arcor.de> <39256.66.91.85.198.1076832682.squirrel@togami.com> <20040215121749.202c4c78.ms-nospam-0306@arcor.de> Message-ID: Michael Schwendt writes: > On Sat, 14 Feb 2004 22:11:22 -1000 (HST), Warren Togami wrote: > > > Should we leave the existing fedora.us Extras as-is, or should we provide > > maybe a "perl-virtual" package that provides the equivalent virtual > > provides as this new standard for FC2. That way all perl modules from now > > on can have theoretical compatibility and exact Requires, completely > > avoiding these ugly hacks of requiring a directory. > > > > Thoughts? > > Sounds good. Let's touch them when the time has come. The perl module > packages in fedora.us should be pretty stable upgrade-wise, since they > don't depend on a specific Perl version (except for automated sanity > related deps like perl >= 0:5.005). But for update packages to be modified > and prepared for FC 1.90, we should no longer include "unowned" > vendor/site/multi directories, even if the updated package will create > unowned directories on FC1. As soon as a new perl core package is > available, which provides the necessary virtual capabilities as Chip > Turner has explained, we could simulate it with a meta-package for FC1 to > benefit from being able to build the same src.rpm for multiple releases of > FC and increase the dependencies of noarch.rpms. We could make such a > package include the unowned Perl directories, too. Would an errata of perl 5.8.3 for FC1 (and maybe RHL9) with the proper provides, directory ownerships, etc help? Anyone willing to help test such a beast? :) Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From salimma at fastmail.fm Tue Feb 17 16:48:19 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 17 Feb 2004 23:48:19 +0700 Subject: sbp2 firewire failure on kernels 2.6.1-1.61, 2.6.2-1.81 Message-ID: <1077036499.27356.181183510@webmail.messagingengine.com> I get the following errors when I turn on my external hard drive enclosure: ------------------------------------------------------------------ ieee1394: got invalid ack 11 from node 65472 (tcode 4) ieee1394: got invalid ack 11 from node 65472 (tcode 4) ieee1394: got invalid ack 11 from node 65472 (tcode 4) ieee1394: ConfigROM quadlet transaction error for node 0-00:1023 ieee1394: Node changed: 0-00:1023 -> 0-01:1023 ------------------------------------------------------------------ sbp2 does *not* get loaded automatically. If I unload ohci1394 and reload it, I get: ------------------------------------------------------------------ ieee1394: ConfigROM quadlet transaction error for node 0-00:1023 ohci1394: $Rev: 1097 $ Ben Collins ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[d0202000-d02027ff] Max Packet=[2048] ieee1394: Node added: ID:BUS[0-00:1023] GUID[005077350710020e] ieee1394: Host added: ID:BUS[0-01:1023] GUID[08004603015ea68f] ieee1394: unsolicited response packet received - no tlabel match sbp2: $Rev: 1096 $ Ben Collins ieee1394: sbp2: Driver forced to serialize I/O (serialize_io = 1) scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices ieee1394: sbp2: sbp2_firmware_revision = 100102 ------------------------------------------------------------------- Still no drive detected, until I attempt to mount a partition: ieee1394: sbp2: Logged into SBP-2 device ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: ST312002 Model: 2A Rev: Type: Direct-Access ANSI SCSI revision: 06 SCSI device sdb: 234467403 512-byte hdwr sectors (120047 MB) sdb: asking for cache data failed sdb: assuming drive cache: write through sdb:<3>ieee1394: sbp2: aborting sbp2 command Read (10) 00 0d f9 b0 48 00 00 03 00 ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset eth1: New link status: Disconnected (0002) eth1: New link status: Connected (0001) ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset What is the status of firewire support on FC2-devel? It is quite worrying it seems to be retrogressing ever since 2.4.21 was released (first requiring rescan-scsi-bus.sh, and now this). Is there any possibility of shipping a 2.4 kernel in addition to 2.6 for FC2 final? Hardware's Sony Vaio Z1MP, Centrino (Pentium-M 1.3GHz) with a USB memory stick interface. Relevant lsmod lines: sbp2 27656 0 ohci1394 41860 0 sd_mod 16928 0 usb_storage 65984 0 scsi_mod 124600 4 sbp2,sg,sd_mod,usb_storage Has anyone run into a similar problem? Bugzilla has nothing to say on that - I'll probably file a report tomorrow. Thanks, - Michel -- http://www.fastmail.fm - I mean, what is it about a decent email service? From ellson at research.att.com Tue Feb 17 16:58:34 2004 From: ellson at research.att.com (John Ellson) Date: Tue, 17 Feb 2004 11:58:34 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> Message-ID: <4032483A.8070302@research.att.com> Build System wrote: >kernel-2.6.2-1.85 >----------------- >* Mon Feb 16 2004 Dave Jones > >- disable psaux emulation. > > So now I have no mouse at all. Neither gpm nor X11. Neither serial nor usb. Do I need to manually change something in /dev or add something to /etc/modprobe.conf ? John Ellson From gleblanc at linuxweasel.com Tue Feb 17 17:35:14 2004 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: Tue, 17 Feb 2004 09:35:14 -0800 Subject: rawhide report: 20040217 changes In-Reply-To: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> Message-ID: <403250D2.7010408@linuxweasel.com> Hmm, can I get the code that generates this email, somehow? I'd like to see about writing one that does the formatting a bit nicer. Greg [snip] From notting at redhat.com Tue Feb 17 17:55:56 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 17 Feb 2004 12:55:56 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <403250D2.7010408@linuxweasel.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <403250D2.7010408@linuxweasel.com> Message-ID: <20040217175556.GA5922@devserv.devel.redhat.com> Gregory Leblanc (gleblanc at linuxweasel.com) said: > Hmm, can I get the code that generates this email, somehow? I'd like to > see about writing one that does the formatting a bit nicer. It's pretty stupid. Attached. 'Package' is an old rpm abstraction... it's really not worth pushing. Bill -------------- next part -------------- #!/usr/bin/python # Generates a changelog between build trees. # # Usage: treediff [--html] tree1 tree2 import getopt import string import glob import sys sys.path.append('/home/devel/notting/prog/prospector') import os from stat import * from Package import Package args = sys.argv[1:] if not args or not args[0] or not args[1]: print "Usage: treediff tree1 tree2\n" sys.exit(-1) tree1 = args[0] tree2 = args[1] new = [] axed = [] changed = [] filelist = os.listdir('%s/SRPMS/' % tree1) filelist.sort() for file in filelist: if file[-4:] != '.rpm': continue p = Package('%s/SRPMS/%s' % (tree1,file)) # is same version in old tree? try: oldname = '%s/SRPMS/%s' % (tree2, file) foo=open(oldname,'r') foo.close() except: oldversion = glob.glob('%s/SRPMS/%s*' % (tree2, p.getName()) ) if not oldversion: new.append('New package %s\n\t%s\n' % (p.getName(),p.getSummary())) else: oldp = Package(oldversion[0]) newCL = string.split(p.getChangeLog(3),'\n') oldCL = string.split(oldp.getChangeLog(3),'\n') clist = [] if newCL and oldCL: while (newCL[0] != oldCL[0]): clist.append(newCL[0]) newCL=newCL[1:] if not newCL: break elif newCL: clist = newCL nvr = "%s-%s-%s" % (p.getName(), p.getVersion(), p.getRelease()) hashes = "-" * len(nvr) changed.append("%s\n%s\n%s" % (nvr,hashes,string.join(clist,'\n'))) for file in os.listdir('%s/SRPMS/' % tree2): if file[-4:] != '.rpm': continue p = Package('%s/SRPMS/%s' % (tree2, file)) if not glob.glob('%s/SRPMS/%s*' % (tree1, p.getName())): axed.append('Removed package %s\n' % p.getName()); print string.join(new,'\n'),'\n\n',string.join(axed,'\n'),'\nUpdated Packages:\n\n',string.join(changed,'\n') From mike at flyn.org Tue Feb 17 18:24:41 2004 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 17 Feb 2004 12:24:41 -0600 Subject: More loitering process curiosities In-Reply-To: <20031103201233.GA11890@imp.flyn.org> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> <1067577613.15833.61.camel@localhost.localdomain> <20031031175656.GA1020@imp.flyn.org> <20031031214256.GA7403@imp.flyn.org> <20031101003341.GA2681@imp.flyn.org> <1067879284.6904.2.camel@localhost.localdomain> <20031103201233.GA11890@imp.flyn.org> Message-ID: <20040217182441.GA3576@imp.flyn.org> >>>> We've made some progress getting gconfd-2 to exit when a user logs out >>>> (see "gconfd-2 does not exit when a user log out, breaks unmounting >>>> home" thread). Now I am interested in turning my attention to some >>>> other processes that seem to loiter around after one logs out of a GNOME >>>> 2.4.0 session. >>>> Pam_mount performs an lsof that claims the processes are still running >>>> when pam_close_session is called, but the processes are gone after the >>>> user is completely logged out (Unlike gconfd-2, which stayed running >>>> for two minutes). >>>> The following processes hang around (with $HOME as their CWD): >>>> bonobo-activation-server >>>> gnome-settings-daemon >>>> xscreensaver >>>> mapping-daemon >>> But I'm still curious about this process hierarchy. Why do processes >>> like bonobo-activation-server and gnome-panel seem to execute with init >>> as their parent? >> When doing a fork/exec, GLib programs usually use the g_spawn_ family of >> functions; these fork twice, creating an intermediate child process that >> immediately exits and is reaped by the parent. The purpose is to avoid >> zombies, as usually in a GUI context parent/child doesn't mean much. >> (e.g. say Evolution launches your web browser there's no point really >> having the browser be a child of evolution) > Thanks to all who explained. There is also a mail thread from 2000 on > gnome-devel-list titled "Process Tree." > I updated the gconfd-2-killing gnome-session patch I have submitted to > GNOME's bugzilla to use execvp/waitpid instead of gnome_execute_async. > Is there a more GNOME/glib-happy way to wait for a forked process? > I also send the following very simple patch to the gdm folks. It fixes my > problem with X programs hanging around when pam_close_session is called, > but I'm not sure if it would break anything else. Here it is: [...] These problems still exist in Fedora Core 2 Test 1. Though gconfd-2 seems to have been resolved, the following processes still have problems quiting when a user logs out: bonobo-activation-server keeps $HOME open as its CWD (libbonobo-2.5.3-1) gnome-vfs-daemon keeps $HOME open as its CWD (gnome-vfs2-2.5.7-1) mapping-daemon keeps $HOME open as its CWD (nautilus-cd-burner-0.6.5-1) gnome-settings-daemon? All of these processes make unmounting $HOME on logout difficult. See also: http://bugzilla.gnome.org/show_bug.cgi?id=97361 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=67605 -- Mike :wq From davej at redhat.com Tue Feb 17 18:30:56 2004 From: davej at redhat.com (Dave Jones) Date: Tue, 17 Feb 2004 18:30:56 +0000 Subject: rawhide report: 20040217 changes In-Reply-To: <4032483A.8070302@research.att.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> Message-ID: <1077042656.7226.4.camel@delerium.codemonkey.org.uk> On Tue, 2004-02-17 at 16:58, John Ellson wrote: > >- disable psaux emulation. > So now I have no mouse at all. Neither gpm nor X11. Neither serial nor > usb. > > Do I need to manually change something in /dev or add something to > /etc/modprobe.conf ? anything using /dev/psaux should be changed over to use /dev/input/mice Dave From pp at ee.oulu.fi Tue Feb 17 18:34:53 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 17 Feb 2004 20:34:53 +0200 Subject: XFree86 4.3.0-56 EPIA test results In-Reply-To: References: <20040216230040.GA29706@ee.oulu.fi> Message-ID: <20040217183453.GA19904@ee.oulu.fi> On Tue, Feb 17, 2004 at 12:52:16AM -0500, Mike A. Harris wrote: > -57 is now ready, and includes the via_dri.so module properly. > Please test the 4.3.0-57 package out using the included via_drv.o > 2D driver, via_dri.so 3D driver, and ensuring you're not using > 3rd party bits, so the testing is clean. Just tested with -57 and the good news is that DRI works just fine (after compiling the necessary module, and accepting that menus in tuxracer are brown, the game itself was fine). Xv initially worked ok (with zero 3rd party components including the dri module) until I did a power-off (rebooting a new kernel wasn't enough). After that it had the same problems as -56 (Xv stuff looking completely wrong). Reverting to the via_drv binary I mentioned in the original report made things work, even when switching back to the -57 via_drv.o So there seems to be a "Make Xv work" register that isn't being set by the driver, but it doesn't get set the wrong way either :-) Reported as #116027. Sure would be nice to get the dri code in the 2.6 kernel btw., the drivers/char/drm parts of http://epia.kalf.org/gryle_patches/via-v4l-1.4a-drm.patch.gz patch just fine into 2.6.2-1.85 (the drivers/media/video stuff that uses e.g. floating point can be left out, which is what I did for this iteration of testing) -- Pekka Pietikainen From alan at redhat.com Tue Feb 17 18:54:41 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 17 Feb 2004 13:54:41 -0500 Subject: XFree86 4.3.0-56 EPIA test results In-Reply-To: <20040217183453.GA19904@ee.oulu.fi> References: <20040216230040.GA29706@ee.oulu.fi> <20040217183453.GA19904@ee.oulu.fi> Message-ID: <20040217185441.GB25396@devserv.devel.redhat.com> On Tue, Feb 17, 2004 at 08:34:53PM +0200, Pekka Pietikainen wrote: > http://epia.kalf.org/gryle_patches/via-v4l-1.4a-drm.patch.gz patch just fine > into 2.6.2-1.85 (the drivers/media/video stuff that uses e.g. floating point > If can be left out, which is what I did for this iteration of testing) If it even mentions ddmpeg its obsolete btw - so better to port the 2.4 patches From aoliva at redhat.com Tue Feb 17 19:05:24 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 17 Feb 2004 16:05:24 -0300 Subject: sbp2 firewire failure on kernels 2.6.1-1.61, 2.6.2-1.81 In-Reply-To: <1077036499.27356.181183510@webmail.messagingengine.com> References: <1077036499.27356.181183510@webmail.messagingengine.com> Message-ID: On Feb 17, 2004, "Michel Alexandre Salim" wrote: > What is the status of firewire support on FC2-devel? I had some minor issues with 2.6.1-1.65 that prevented it from recognizing my Maxtor 5000DV early in the boot (I had mkinitrd --with=sd_mod --with=sbp2, such that I could do RAID 1 to the external disk), but those were all fixed in 2.6.2. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From aoliva at redhat.com Tue Feb 17 19:09:30 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 17 Feb 2004 16:09:30 -0300 Subject: cd burn In-Reply-To: <40321024.9060006@home.se> References: <1077021743.9561.1.camel@simba.lion> <40321024.9060006@home.se> Message-ID: On Feb 17, 2004, Peter Backlund wrote: > Alex Thomsen Leth wrote: >> i have a problem with burning in the fc2 test1. if im running >> cdrecord -scanbus i get this. > Wrong list. Try fedora-list at redhat.com. Actually, since the question has to do with a test release, fedora-test-list at redhat.com -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From ville.skytta at iki.fi Tue Feb 17 20:26:44 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 17 Feb 2004 22:26:44 +0200 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> Message-ID: <1077049604.9498.613.camel@bobcat.mine.nu> On Mon, 2004-02-16 at 20:37, Michael Schwendt wrote: > > I just QA'd a package and tried out giving > > it a first-review attachment. I think it's significantly different than > > the current approach and marginally more work. > > Thanks for trying! I've noticed, too, that creating an attachment and > changing the bugzilla keywords line are separate steps. And someone who > submitted the second-review would need three steps (attach, change status, > change keywords). Personally, I wouldn't mind the extra step for setting > the attachment status. But that's why feedback is needed. But keep in mind that assuming the package _submission_ is the attachment (which I suggested earlier), reviews would not (need to) be. Editing the submission attachment and adding the review as the clearsigned comment in the attachment status modification can be done with one form submission. The possibly resulting PUBLISH keyword requires another one though. From ellson at research.att.com Tue Feb 17 20:29:34 2004 From: ellson at research.att.com (John Ellson) Date: Tue, 17 Feb 2004 15:29:34 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <1077042656.7226.4.camel@delerium.codemonkey.org.uk> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> Message-ID: <403279AE.6010500@research.att.com> Dave Jones wrote: >On Tue, 2004-02-17 at 16:58, John Ellson wrote: > > > >>>- disable psaux emulation. >>> >>> >>So now I have no mouse at all. Neither gpm nor X11. Neither serial nor >>usb. >> >>Do I need to manually change something in /dev or add something to >>/etc/modprobe.conf ? >> >> > >anything using /dev/psaux should be changed over to use /dev/input/mice > > Dave > > > > Dave, Thanks. That worked. I had a softlink /dev/mouse -> /dev/psaux that I changed to /dev/mouse -> /dev/input/mice and I had references to /dev/psaux that I changed to refer to /dev/mouse in: /etc/X11/XF85Config /etc/sysconfig/mouse John From leonard at den.ottolander.nl Tue Feb 17 21:22:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 17 Feb 2004 22:22:27 +0100 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: References: Message-ID: <1077052947.4773.5.camel@athlon.localdomain> Hello Mike, > Perhaps we should remove this person from the list until they > correct their broken email configuration? In the past the list maintainers have been very responsive if you approach them directly with such issues. I've done it a couple of times and it always worked to get such a person temporarily removed from the list. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jorton at redhat.com Tue Feb 17 21:37:10 2004 From: jorton at redhat.com (Joe Orton) Date: Tue, 17 Feb 2004 21:37:10 +0000 Subject: MySQL - Optional GPL License Exception for PHP In-Reply-To: <20040216163643.GA23940@devserv.devel.redhat.com> References: <64775.195.212.29.163.1076937941.squirrel@webmail.openintegra.com> <20040216163643.GA23940@devserv.devel.redhat.com> Message-ID: <20040217213710.GA6114@redhat.com> On Mon, Feb 16, 2004 at 11:36:43AM -0500, Alan Cox wrote: > On Mon, Feb 16, 2004 at 03:25:41PM +0200, Yovko Lambrev wrote: > > Will this be enough to include MySQL 4.x in Fedora Core? > > As was pointed out before - there are things like OpenSSL in with > php in apache modules. I'm hopeful MySQL can work something out because > I'd like to see all the bits in place OpenSSL is slightly different: it could easily fall under the "things provided with your system" exception. We already redistribute lots of GPL code linked against OpenSSL. (I know Debian do take a hard line on OpenSSL, maybe we should too) But regardless, a change to the mysql.com web site does not influence the licensing of the code in mysql-4.0.18.tar.gz in any way. I've pinged Zak Greant at MySQL who was dealing with this for a status update. joe From leonard at den.ottolander.nl Tue Feb 17 21:51:03 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 17 Feb 2004 22:51:03 +0100 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: <1077052947.4773.5.camel@athlon.localdomain> References: <1077052947.4773.5.camel@athlon.localdomain> Message-ID: <1077054663.4773.9.camel@athlon.localdomain> > Hello Mike, > > > Perhaps we should remove this person from the list until they > > correct their broken email configuration? > > In the past the list maintainers have been very responsive if you > approach them directly with such issues. I've done it a couple of times > and it always worked to get such a person temporarily removed from the > list. Could you please contact the list admin? Evolution still crashes on me when editing the To: field, so I am unable to contact the admin myself. For fedora-devel the admin is bfox at redhat.com. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Feb 17 22:00:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 17 Feb 2004 23:00:21 +0100 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: <1077054663.4773.9.camel@athlon.localdomain> References: <1077052947.4773.5.camel@athlon.localdomain> <1077054663.4773.9.camel@athlon.localdomain> Message-ID: <1077055220.4773.17.camel@athlon.localdomain> Hi, > Could you please contact the list admin? Evolution still crashes on me > when editing the To: field, so I am unable to contact the admin myself. > For fedora-devel the admin is bfox at redhat.com. Clicking an email address in a mail message however works. I contacted Brent about this issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ckloiber at redhat.com Tue Feb 17 22:07:45 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Tue, 17 Feb 2004 17:07:45 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> Message-ID: <1077055665.16493.182.camel@ckk.rdu.redhat.com> On Tue, 2004-02-17 at 09:51, Build System wrote: > samba-3.0.2-7 > ------------- > * Mon Feb 16 2004 Karsten Hopp 3.0.2-7 > > - fix ownership in -common package > > * Fri Feb 13 2004 Elliot Lee > > - rebuilt > > * Fri Feb 13 2004 Jay Fenlason > > - Change all requires lines to list an explicit epoch. Closes #102715 Not quite (minutes ago): Testing package set / solving RPM inter-dependencies... There was a package dependency problem. The message was: Unresolvable chain of dependencies: samba-3.0.2-7 requires samba-common = %{epoch}:3.0.2 samba-client-3.0.2-7 requires samba-common = %{epoch}:3.0.2 samba-swat-3.0.2-7 requires samba = %{epoch}:3.0.2 -- Chris Kloiber, RHCX Red Hat, Inc. From bfox at redhat.com Tue Feb 17 22:08:50 2004 From: bfox at redhat.com (Brent Fox) Date: Tue, 17 Feb 2004 17:08:50 -0500 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: <1077055220.4773.17.camel@athlon.localdomain> References: <1077052947.4773.5.camel@athlon.localdomain> <1077054663.4773.9.camel@athlon.localdomain> <1077055220.4773.17.camel@athlon.localdomain> Message-ID: <1077055730.14307.39.camel@verve.devel.redhat.com> On Tue, 2004-02-17 at 17:00, Leonard den Ottolander wrote: > Hi, > > > Could you please contact the list admin? Evolution still crashes on me > > when editing the To: field, so I am unable to contact the admin myself. > > For fedora-devel the admin is bfox at redhat.com. > > Clicking an email address in a mail message however works. I contacted > Brent about this issue. I've disabled sending mail to jslivko at slackercentral.com for the time being. Hopefully this avoids the problem until his email configuration gets sorted out. Cheers, Brent From gbpeck at sbcglobal.net Tue Feb 17 22:17:40 2004 From: gbpeck at sbcglobal.net (Gary Peck) Date: Tue, 17 Feb 2004 14:17:40 -0800 Subject: rawhide report: 20040217 changes In-Reply-To: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> Message-ID: <20040217221740.GA816@realify.com> On Tue, Feb 17, 2004 at 09:51:06AM -0500, Build System wrote: > util-linux-2.12-2 > ----------------- > * Fri Feb 13 2004 Elliot Lee > > - rebuilt > > * Thu Feb 12 2004 Elliot Lee 2.12-1 > > - Final 2.12 has been out for ages - might as well use it. > > * Wed Jan 28 2004 Steve Dickson 2.12pre-4 > > - Added mount patches that have NFS version 4 support The new util-linux package has an older version than the previous one from rawhide (2.12-2 < 2.12pre-3). Should it get an epoch, or is this a case of "you're using rawhide, so you'll need to force the package upgrade"? gary From sopwith at redhat.com Tue Feb 17 22:27:06 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 17 Feb 2004 17:27:06 -0500 (EST) Subject: rawhide report: 20040217 changes In-Reply-To: <20040217221740.GA816@realify.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <20040217221740.GA816@realify.com> Message-ID: On Tue, 17 Feb 2004, Gary Peck wrote: > The new util-linux package has an older version than the previous one > from rawhide (2.12-2 < 2.12pre-3). Should it get an epoch, or is this a > case of "you're using rawhide, so you'll need to force the package > upgrade"? Force it - it's not going to matter for upgrades from FC1, so right now it's not a major issue. Ciao, -- Elliot From fenlason at redhat.com Tue Feb 17 22:35:19 2004 From: fenlason at redhat.com (Jay Fenlason) Date: Tue, 17 Feb 2004 17:35:19 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <1077055665.16493.182.camel@ckk.rdu.redhat.com> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <1077055665.16493.182.camel@ckk.rdu.redhat.com> Message-ID: <20040217223519.GK4335@redhat.com> On Tue, Feb 17, 2004 at 05:07:45PM -0500, Chris Kloiber wrote: > On Tue, 2004-02-17 at 09:51, Build System wrote: > > > samba-3.0.2-7 > > ------------- > > * Mon Feb 16 2004 Karsten Hopp 3.0.2-7 > > > > - fix ownership in -common package > > > > * Fri Feb 13 2004 Elliot Lee > > > > - rebuilt > > > > * Fri Feb 13 2004 Jay Fenlason > > > > - Change all requires lines to list an explicit epoch. Closes #102715 > > Not quite (minutes ago): > > Testing package set / solving RPM inter-dependencies... > There was a package dependency problem. The message was: > > Unresolvable chain of dependencies: > samba-3.0.2-7 requires samba-common = %{epoch}:3.0.2 > samba-client-3.0.2-7 requires samba-common = %{epoch}:3.0.2 > samba-swat-3.0.2-7 requires samba = %{epoch}:3.0.2 You need the new 3.0.2a-1 RPMs that were just built. -- JF From czar at czarc.net Tue Feb 17 22:50:22 2004 From: czar at czarc.net (Gene C.) Date: Tue, 17 Feb 2004 17:50:22 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <1077042656.7226.4.camel@delerium.codemonkey.org.uk> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> Message-ID: <200402171750.22243.czar@czarc.net> On Tuesday 17 February 2004 13:30, Dave Jones wrote: > On Tue, 2004-02-17 at 16:58, John Ellson wrote: > > >- disable psaux emulation. > > > > So now I have no mouse at all. Neither gpm nor X11. Neither serial nor > > usb. > > > > Do I need to manually change something in /dev or add something to > > /etc/modprobe.conf ? > > anything using /dev/psaux should be changed over to use /dev/input/mice Errk ... no, this is not sufficent ... "should be changed" ... sorry, that does not cut it. While I can understand that this change to the kernel is a good idea, a statement in an email that it "should be changed" is not enough. Who/what did the original sym-link of /dev/mouse to psaux anyway? I assume that it sould be system-config-mouse. When I booted the new kernel, "stuff" detected that the mouse setup was wrong and invoked the mouse config program but it did not fix things. Expecting a user to quess the right magic to do to fix things should NOT be the way things are done. What should have been done is: 1. Update system-config-mouse to set things up correctly. 2. Add a requires to the kernel rpm for that version or later of system-config-mouse. -- Gene From cra at WPI.EDU Tue Feb 17 23:39:35 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 17 Feb 2004 18:39:35 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <200402171750.22243.czar@czarc.net> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> <200402171750.22243.czar@czarc.net> Message-ID: <20040217233935.GV1556@angus.ind.WPI.EDU> On Tue, Feb 17, 2004 at 05:50:22PM -0500, Gene C. wrote: > Errk ... no, this is not sufficent ... "should be changed" ... sorry, that > does not cut it. If you don't like to fix things manually, then don't use rawhide, or file a bug report in bugzilla. Don't bitch here about it. From mrsam at courier-mta.com Wed Feb 18 00:34:02 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 17 Feb 2004 19:34:02 -0500 Subject: autoconf breakage on x86_64. Message-ID: I don't know the right way to fix this, but something is definitely broken; and something needs to be fixed, one way or the other. The question is what exactly needs to be fixed. Consider something like this: LIBS="-lresolv $LIBS" AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no)) Here's what happens on x86_64: gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5 /tmp/ccW7EeDX.o(.text+0x7): In function `main': /home/mrsam/src/courier/authlib/configure:5160: undefined reference to `res_query' collect2: ld returned 1 exit status configure:5147: $? = 1 configure: failed program was: [ blah blah blah ] | /* We use char because int might match the return type of a gcc2 | builtin and then its argument prototype would still apply. */ | char res_query (); | int | main () | { | res_query (); | ; | return 0; | } The same exact test on FC1 x86 will work. The reason appears to be that you have to #include on x86_64 in order to succesfully pull res_query() out of libresolv.so. You don't need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC does not include any headers, but uses a manual prototype. So, what now? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drepper at redhat.com Wed Feb 18 00:52:10 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 17 Feb 2004 16:52:10 -0800 Subject: autoconf breakage on x86_64. In-Reply-To: References: Message-ID: <4032B73A.2010704@redhat.com> Sam Varshavchik wrote: > I don't know the right way to fix this, but something is definitely > gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5 > /tmp/ccW7EeDX.o(.text+0x7): In function `main': > /home/mrsam/src/courier/authlib/configure:5160: undefined reference to > `res_query' > collect2: ld returned 1 exit status > configure:5147: $? = 1 > configure: failed program was: > > [ blah blah blah ] > > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char res_query (); > | int > | main () > | { > | res_query (); > | ; > | return 0; > | } > > > The same exact test on FC1 x86 will work. Only for compatibility reasons. This is no supported interface of the resolver library. It is not exported for the ABIs which don't need it to be compatible with older releases. If a programmer things her/his code needs this interface an implementation must come with the program. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From tadams-lists at myrealbox.com Wed Feb 18 02:11:12 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 17 Feb 2004 21:11:12 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <1077042656.7226.4.camel@delerium.codemonkey.org.uk> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> Message-ID: <1077070272.1940.1.camel@aurora.localdomain> On Tue, 2004-02-17 at 18:30 +0000, Dave Jones wrote: > On Tue, 2004-02-17 at 16:58, John Ellson wrote: > > > >- disable psaux emulation. > > So now I have no mouse at all. Neither gpm nor X11. Neither serial nor > > usb. > > > > Do I need to manually change something in /dev or add something to > > /etc/modprobe.conf ? > > anything using /dev/psaux should be changed over to use /dev/input/mice > > Dave So, how does one do this for X when you can't even start the configuration device? Trever -- "You can surrender Without a prayer But never ever pray Pray without surrender You can fight Fight without ever wining But you can never ever win Win without fight" -- Niel Peart From surak at casa.surak.eti.br Wed Feb 18 02:37:23 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Tue, 17 Feb 2004 23:37:23 -0300 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: References: Message-ID: <1077071843.21724.37.camel@casa> Em Ter, 2004-02-17 ?s 03:00, Mike A. Harris escreveu: > I know I don't want to get back autoresponders just for posting > to the list, and I'd prefer to unsubscribe than to get such > nonsense back. Are other people getting this garbage? > Perhaps we should remove this person from the list until they > correct their broken email configuration? There are worse things than this - an HUGE isp of latin america created what they call "anti-spam", which is, every message you send to their customers gets back with a html saying a "click here so the message will arrive"... Well that's annoying -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From davej at redhat.com Wed Feb 18 02:37:47 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 18 Feb 2004 02:37:47 +0000 Subject: rawhide report: 20040217 changes In-Reply-To: <200402171750.22243.czar@czarc.net> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> <200402171750.22243.czar@czarc.net> Message-ID: <1077071867.27223.5.camel@delerium.codemonkey.org.uk> On Tue, 2004-02-17 at 22:50, Gene C. wrote: > > anything using /dev/psaux should be changed over to use /dev/input/mice > > Errk ... no, this is not sufficent ... "should be changed" ... sorry, that > does not cut it. > > While I can understand that this change to the kernel is a good idea, a > statement in an email that it "should be changed" is not enough. Welcome to rawhide. Dave From surak at casa.surak.eti.br Wed Feb 18 02:42:04 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Tue, 17 Feb 2004 23:42:04 -0300 Subject: cdrdao-1.1.8 released In-Reply-To: <200402171442.38566@xcyb0rg> References: <402CC158.1000403@freemail.hu> <20040213202652.GA2560@nsk.no-ip.org> <200402171442.38566@xcyb0rg> Message-ID: <1077072123.21724.40.camel@casa> Em Ter, 2004-02-17 ?s 09:42, Mihai Maties escreveu: > > > cdrdao-1.1.8 has just been released. > > > It would be nice to have it in FC2 since it can > > > write CDs without the ide-scsi emulation. > > cdrdao 1.1.7 on fedora-devel can write cds directly by ATAPI access: > Does anyone successfully burned CDs with cdrdao on kernel 2.4 ? I tried both Yes. Dozens. Both cd-r and rw. And "umount /mnt/cdrom && cdrdao blank" is the only way I use to blank my cd-rws... -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From davej at redhat.com Wed Feb 18 02:38:41 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 18 Feb 2004 02:38:41 +0000 Subject: rawhide report: 20040217 changes In-Reply-To: <1077070272.1940.1.camel@aurora.localdomain> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> <1077070272.1940.1.camel@aurora.localdomain> Message-ID: <1077071921.27223.7.camel@delerium.codemonkey.org.uk> On Wed, 2004-02-18 at 02:11, Trever L. Adams wrote: > > anything using /dev/psaux should be changed over to use /dev/input/mice > So, how does one do this for X when you can't even start the > configuration device? Edit it out of /etc/X11/XF86Config by hand for now. Dave From surak at casa.surak.eti.br Wed Feb 18 02:45:51 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Tue, 17 Feb 2004 23:45:51 -0300 Subject: rawhide report: 20040217 changes In-Reply-To: <1077070272.1940.1.camel@aurora.localdomain> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <4032483A.8070302@research.att.com> <1077042656.7226.4.camel@delerium.codemonkey.org.uk> <1077070272.1940.1.camel@aurora.localdomain> Message-ID: <1077072351.21724.42.camel@casa> Em Ter, 2004-02-17 ?s 23:11, Trever L. Adams escreveu: > > anything using /dev/psaux should be changed over to use /dev/input/mice > So, how does one do this for X when you can't even start the > configuration device? That's what boot disks were made for. And as it's rawhide, no one can complain about a "oh no I cannot reboot" :-) -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From webmaster at margo.bijoux.nom.br Wed Feb 18 02:44:55 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Tue, 17 Feb 2004 23:44:55 -0300 Subject: Your email requires verification verify#GqpMTvNbtNDxbslsHYNry2VpFYY7h1ad (fwd) In-Reply-To: <1077071843.21724.37.camel@casa> References: <1077071843.21724.37.camel@casa> Message-ID: <4032D1A7.6090104@margo.bijoux.nom.br> Alexandre Strube wrote: >There are worse things than this - an HUGE isp of latin america created >what they call "anti-spam", which is, every message you send to their >customers gets back with a html saying a "click here so the message will >arrive"... Well that's annoying > > > Agreed.. This annoys me completely , specially because I'm the postmaster for my work domain and also the admin of the mailman list... So , every first day of the month , I get millions of messages from them asking me to visit the page , just to send the montly password reminders for our mailing list users... Looks like they need to get some bounces back to them to learn a bit... Pedro Macedo From ms-nospam-0306 at arcor.de Wed Feb 18 04:05:39 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 18 Feb 2004 05:05:39 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1077049604.9498.613.camel@bobcat.mine.nu> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> <1077049604.9498.613.camel@bobcat.mine.nu> Message-ID: <20040218050539.69608397.ms-nospam-0306@arcor.de> On Tue, 17 Feb 2004 22:26:44 +0200, Ville Skytt? wrote: > On Mon, 2004-02-16 at 20:37, Michael Schwendt wrote: > > > > I just QA'd a package and tried out giving > > > it a first-review attachment. I think it's significantly different than > > > the current approach and marginally more work. > > > > Thanks for trying! I've noticed, too, that creating an attachment and > > changing the bugzilla keywords line are separate steps. And someone who > > submitted the second-review would need three steps (attach, change status, > > change keywords). Personally, I wouldn't mind the extra step for setting > > the attachment status. But that's why feedback is needed. > > But keep in mind that assuming the package _submission_ is the > attachment (which I suggested earlier), reviews would not (need to) be. > Editing the submission attachment and adding the review as the > clearsigned comment in the attachment status modification can be done > with one form submission. The possibly resulting PUBLISH keyword > requires another one though. You mean to paste a clearsigned review into _that_ small window in the "Edit attachment" screen? Well, let's hope that this would not give people headaches about invalidated signatures again. I still like attachment statuses though. It just starts to make the package submission process more strict, which is not a good thing. Maybe another keyword has not been a bad idea afterall. -- From ms-nospam-0306 at arcor.de Wed Feb 18 07:14:32 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 18 Feb 2004 08:14:32 +0100 Subject: Perl requires/provides proposal In-Reply-To: References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> <20040215070408.6abfad99.ms-nospam-0306@arcor.de> <39256.66.91.85.198.1076832682.squirrel@togami.com> <20040215121749.202c4c78.ms-nospam-0306@arcor.de> Message-ID: <20040218081432.4aea4788.ms-nospam-0306@arcor.de> On 17 Feb 2004 10:29:53 -0500, Chip Turner wrote: > Would an errata of perl 5.8.3 for FC1 (and maybe RHL9) with the proper > provides, directory ownerships, etc help? Anyone willing to help test > such a beast? :) Let's move forward and focus on FC2. Trying to update/maintain old releases only kills finite resources. Of course, you could release an FC1 Test Update anytime and hope for feedback, regardless of whether the update will make it. -- From salimma at fastmail.fm Wed Feb 18 08:02:51 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 18 Feb 2004 15:02:51 +0700 Subject: sbp2 firewire failure on kernels 2.6.1-1.61, 2.6.2-1.81 Message-ID: <1077091371.20954.181227422@webmail.messagingengine.com> On 17 Feb 2004 16:05:24 -0300, "Alexandre Oliva" said: > On Feb 17, 2004, "Michel Alexandre Salim" wrote: > > > What is the status of firewire support on FC2-devel? > > I had some minor issues with 2.6.1-1.65 that prevented it from > recognizing my Maxtor 5000DV early in the boot (I had mkinitrd > --with=sd_mod --with=sbp2, such that I could do RAID 1 to the external > disk), but those were all fixed in 2.6.2. > That should not be necessary if I am not doing RAID/LVM, right? Firewire initialization takes place after LVM, so it should work. If I have the drive turned on at boot time, kudzu takes a long time to complete, generating the following dmesg entries: ieee1394: sbp2: Logged into SBP-2 device ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: ST312002 Model: 2A Rev: Type: Direct-Access ANSI SCSI revision: 06 SCSI device sdb: 234467403 512-byte hdwr sectors (120047 MB) sdb: asking for cache data failed sdb: assuming drive cache: write through sdb:<6>kudzu: numerical sysctl 1 23 is obsolete. ieee1394: sbp2: aborting sbp2 command Read (10) 00 0d f9 b0 48 00 00 03 00 ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset ieee1394: sbp2: aborting sbp2 command Test Unit Ready 00 00 00 00 00 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0 SCSI error : <1 0 0 0> return code = 0x50000 end_request: I/O error, dev sdb, sector 234467400 Buffer I/O error on device sdb, logical block 234467400 Buffer I/O error on device sdb, logical block 234467401 Buffer I/O error on device sdb, logical block 234467402 scsi1 (0:0): rejecting I/O to offline device Buffer I/O error on device sdb, logical block 234467400 Buffer I/O error on device sdb, logical block 234467401 Buffer I/O error on device sdb, logical block 234467402 unsupported disk (sdb) sdb1 Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 ----------- the problem is probably not specific to ieee1394, actually, since I get similar errors connecting the drive to USB. Not to mention the drive geometry appears different too (under 2.4 fdisk reports one extra cylinder for USB2 if I recall correctly, and I had to take care not to allocate it to a partition). rmmod-ing sbp2 after those errors results consistently in segfaults, here's the dump: ieee1394: sbp2: Logged out of SBP-2 device Unable to handle kernel paging request at virtual address 6b6b6c1f printing eip: f096d7c5 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010246 EIP is at scsi_device_put+0x5/0x40 [scsi_mod] eax: 6b6b6b6b ebx: ecf5e89c ecx: 00000000 edx: ecf5eddc esi: ef0297d8 edi: ef08675c ebp: ef0298fc esp: d7083f04 ds: 007b es: 007b ss: 0068 Process rmmod (pid: 20048, threadinfo=d7082000 task=d7f448a0) Stack: ef0297d8 f090e890 00000008 ef0297d8 ef08675c ef08675c 00000000 f090deb8 ee6a7970 f091388c f091388c c0253086 f09138f0 f09138f0 c02530a8 f0adc6cc f0adc680 c0253321 f0913894 f091388c 00000000 c02536f4 f0913a00 c0363920 Call Trace: [] sbp2_remove_device+0x180/0x190 [sbp2] [] sbp2_remove+0x38/0x50 [sbp2] [] device_release_driver+0x56/0x60 [] driver_detach+0x18/0x30 [] bus_remove_driver+0x51/0x90 [] driver_unregister+0x14/0x3a [] sbp2_module_exit+0xa/0x14 [sbp2] [] sys_delete_module+0x11b/0x190 [] unmap_vma+0x30/0xa0 [] do_munmap+0x1ad/0x280 [] __fput+0x98/0xf0 [] syscall_call+0x7/0xb Code: 8b 80 b4 00 00 00 8b 00 85 c0 74 0b ff 88 00 01 00 00 83 38 ---- Any idea? Should I bugzilla this, and perhaps forward it to linux1394 maintainers? Going to try a newer kernel first, but before that, resize my Windows partition so I could triple boot FC1, FC2T1 and XP. - Michel -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again From warren at togami.com Wed Feb 18 09:19:56 2004 From: warren at togami.com (Warren Togami) Date: Tue, 17 Feb 2004 23:19:56 -1000 (HST) Subject: Perl requires/provides proposal In-Reply-To: <20040218081432.4aea4788.ms-nospam-0306@arcor.de> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de><20040215070408.6abfad99.ms-nospam-0306@arcor.de><39256.66.91.85.198.1076832682.squirrel@togami.com><20040215121749.202c4c78.ms-nospam-0306@arcor.de> <20040218081432.4aea4788.ms-nospam-0306@arcor.de> Message-ID: <32812.66.91.85.198.1077095996.squirrel@togami.com> > On 17 Feb 2004 10:29:53 -0500, Chip Turner wrote: > >> Would an errata of perl 5.8.3 for FC1 (and maybe RHL9) with the proper >> provides, directory ownerships, etc help? Anyone willing to help test >> such a beast? :) > > Let's move forward and focus on FC2. Trying to update/maintain old > releases only kills finite resources. > > Of course, you could release an FC1 Test Update anytime and hope for > feedback, regardless of whether the update will make it. > I would advise only taking advantage of a perl upgrade opportunity like a RH9 & FC1 major nbugfix or security issue where perl upgrade would be a necessity. Otherwise I would not want to upgrade perl only to implement the virtual provides framework. This is also not a solution for pre-RH9 distributions. Agreed that we should focus on FC2. We have plenty of issues there alone. Warren From davej at redhat.com Wed Feb 18 11:10:50 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 18 Feb 2004 11:10:50 +0000 Subject: sbp2 firewire failure on kernels 2.6.1-1.61, 2.6.2-1.81 In-Reply-To: <1077091371.20954.181227422@webmail.messagingengine.com> References: <1077091371.20954.181227422@webmail.messagingengine.com> Message-ID: <1077102650.25755.2.camel@delerium.codemonkey.org.uk> On Wed, 2004-02-18 at 08:02, Michel Alexandre Salim wrote: > > the problem is probably not specific to ieee1394, actually, since I get > similar errors connecting the drive to USB. Not to mention the drive > geometry appears different too (under 2.4 fdisk reports one extra > cylinder for USB2 if I recall correctly, and I had to take care not to > allocate it to a partition). > > rmmod-ing sbp2 after those errors results consistently in segfaults, > here's the dump: I've been going through every module we ship finding out if stuff rmmod's cleanly. The amount that doesn't is truly terrifying. > ieee1394: sbp2: Logged out of SBP-2 device > Unable to handle kernel paging request at virtual address 6b6b6c1f > printing eip: > f096d7c5 > *pde = 00000000 > Oops: 0000 [#1] > CPU: 0 > EIP: 0060:[] Not tainted > EFLAGS: 00010246 > EIP is at scsi_device_put+0x5/0x40 [scsi_mod] > eax: 6b6b6b6b ebx: ecf5e89c ecx: 00000000 edx: ecf5eddc > esi: ef0297d8 edi: ef08675c ebp: ef0298fc esp: d7083f04 > ds: 007b es: 007b ss: 0068 > Process rmmod (pid: 20048, threadinfo=d7082000 task=d7f448a0) > Stack: ef0297d8 f090e890 00000008 ef0297d8 ef08675c ef08675c 00000000 > f090deb8 > ee6a7970 f091388c f091388c c0253086 f09138f0 f09138f0 c02530a8 > f0adc6cc > f0adc680 c0253321 f0913894 f091388c 00000000 c02536f4 f0913a00 > c0363920 > Call Trace: > [] sbp2_remove_device+0x180/0x190 [sbp2] > [] sbp2_remove+0x38/0x50 [sbp2] > [] device_release_driver+0x56/0x60 > [] driver_detach+0x18/0x30 > [] bus_remove_driver+0x51/0x90 > [] driver_unregister+0x14/0x3a > [] sbp2_module_exit+0xa/0x14 [sbp2] > [] sys_delete_module+0x11b/0x190 > [] unmap_vma+0x30/0xa0 > [] do_munmap+0x1ad/0x280 > [] __fput+0x98/0xf0 > [] syscall_call+0x7/0xb > > Code: 8b 80 b4 00 00 00 8b 00 85 c0 74 0b ff 88 00 01 00 00 83 38 > ---- > > Any idea? Should I bugzilla this, and perhaps forward it to linux1394 > maintainers? Let the 1394 folks know. If you bugzilla it, we'll likely just point them at it anyway. If they give you any nonsense about "its a vendor kernel, we only support mainline", Fedora is 100% identical to upstream in regard to firewire. > Going to try a newer kernel first Yes, please do. Dave From f.simon at email.it Wed Feb 18 13:20:40 2004 From: f.simon at email.it (Simon) Date: Wed, 18 Feb 2004 14:20:40 +0100 Subject: FC2 on DVD? Message-ID: <002601c3f622$01a530f0$0100000a@itaca> Is there any chance that FC2 will be released also as a single DVD iso too? Isn't that more handy? Thanks. -- Simon. From czar at czarc.net Wed Feb 18 13:21:09 2004 From: czar at czarc.net (Gene C.) Date: Wed, 18 Feb 2004 08:21:09 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <1077071867.27223.5.camel@delerium.codemonkey.org.uk> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402171750.22243.czar@czarc.net> <1077071867.27223.5.camel@delerium.codemonkey.org.uk> Message-ID: <200402180821.09458.czar@czarc.net> On Tuesday 17 February 2004 21:37, Dave Jones wrote: > On Tue, 2004-02-17 at 22:50, Gene C. wrote: > > > anything using /dev/psaux should be changed over to use /dev/input/mice > > > > Errk ... no, this is not sufficent ... "should be changed" ... sorry, > > that does not cut it. > > > > While I can understand that this change to the kernel is a good idea, a > > statement in an email that it "should be changed" is not enough. > > Welcome to rawhide. OK. Question: when FC2 test2, FC2 test3, etc. come along and a user does an "upgrade" install, what is going to "fix things up" so that they work? -- Gene From f.simon at email.it Wed Feb 18 13:34:37 2004 From: f.simon at email.it (Simon) Date: Wed, 18 Feb 2004 14:34:37 +0100 Subject: 3Com 3c940 ethernet card Message-ID: <000d01c3f623$f41dfc80$0100000a@itaca> The 3Com 3c940 ethernet card embedded in my Asus KV8 Deluxe is supported by the kernel module sk98lin but not detected during FC2 installing. 0000:00:0a.0 Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 12) Bus 0, device 10, function 0: Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 18). IRQ 10. Master Capable. Latency=64. Min Gnt=23.Max Lat=31. Non-prefetchable 32 bit memory at 0xfde00000 [0xfde03fff]. I/O at 0xb000 [0xb0ff]. Is this the right place to report it? Thanks. -- Simon. From czar at czarc.net Wed Feb 18 13:48:21 2004 From: czar at czarc.net (Gene C.) Date: Wed, 18 Feb 2004 08:48:21 -0500 Subject: 3Com 3c940 ethernet card In-Reply-To: <000d01c3f623$f41dfc80$0100000a@itaca> References: <000d01c3f623$f41dfc80$0100000a@itaca> Message-ID: <200402180848.21160.czar@czarc.net> On Wednesday 18 February 2004 08:34, Simon wrote: > The 3Com 3c940 ethernet card embedded in my Asus KV8 Deluxe is supported by > the kernel module sk98lin but not detected during FC2 installing. > > 0000:00:0a.0 Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 12) > > Bus 0, device 10, function 0: > Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 18). > IRQ 10. > Master Capable. Latency=64. Min Gnt=23.Max Lat=31. > Non-prefetchable 32 bit memory at 0xfde00000 [0xfde03fff]. > I/O at 0xb000 [0xb0ff]. > > Is this the right place to report it? bugzilla is the place to report it ... already done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115511 -- Gene From rpn at netmonks.org Wed Feb 18 14:22:28 2004 From: rpn at netmonks.org (Rodrigo Parra Novo) Date: Wed, 18 Feb 2004 11:22:28 -0300 Subject: failure generating bootdisk.img: kernel-BOOT is too big Message-ID: <1077114148.7373.11.camel@intranet.freesoftware> Greetings, while making changes on Fedora Core 1, I needed to recompile the kernel-* packages, to change a few drivers, needed by a customer of mine. But when I attempt to create the installation bootdisk (so my customer can install Fedora with the new drivers), upd-instroot bombs saying there is no enough space on bootdisk.img. Checking all changes I've made, I noted that my new kernel-BOOT has a vmlinuz which is about 8KB bigger than the older one. So here is my question: anyone knows a few safe switches I can disable on the kernel-BOOT build, to regain this extra space used by the new drivers? (this space must be taken from stuff in the kernel itself, not modules) Thanks in advance, Rodrigo From dstewart at atl.lmco.com Wed Feb 18 14:35:54 2004 From: dstewart at atl.lmco.com (Doug Stewart) Date: Wed, 18 Feb 2004 09:35:54 -0500 Subject: FC2 on DVD? In-Reply-To: <002601c3f622$01a530f0$0100000a@itaca> References: <002601c3f622$01a530f0$0100000a@itaca> Message-ID: <4033784A.6000009@atl.lmco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon wrote: | Is there any chance that FC2 will be released also as a single DVD iso too? | Isn't that more handy? | | Thanks. | -- | Simon. | | I, for one, prefer downloading all of the CD isos myself and constructing the DVD iso using the mkdvdiso.sh that has been posted to this list. I'd rather have to re-download a single 600MB corrupt CD ISO rather than an entire 4GB corrupt DVD ISO. - -- - ---------- Doug Stewart Systems Administrator/Web Applications Developer Lockheed Martin Advanced Technology Labs Quidquid latine dictum sit, altum viditur -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAM3hKN50Q8DVvcvkRApfPAJ0cxX1JnRHvh6shMe6mF3R9dBY8gACfYIn4 Mf4V60P+z1jkIgIZ7/k8h9g= =4Ob5 -----END PGP SIGNATURE----- From cra at WPI.EDU Wed Feb 18 14:40:51 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 18 Feb 2004 09:40:51 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: <200402180821.09458.czar@czarc.net> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402171750.22243.czar@czarc.net> <1077071867.27223.5.camel@delerium.codemonkey.org.uk> <200402180821.09458.czar@czarc.net> Message-ID: <20040218144051.GE11971@angus.ind.WPI.EDU> On Wed, Feb 18, 2004 at 08:21:09AM -0500, Gene C. wrote: > Question: when FC2 test2, FC2 test3, etc. come along and a user does an > "upgrade" install, what is going to "fix things up" so that they work? Nothing. Upgrades aren't supported between test releases, or from a test release to the final release. From buildsys at redhat.com Wed Feb 18 15:10:31 2004 From: buildsys at redhat.com (Build System) Date: Wed, 18 Feb 2004 10:10:31 -0500 Subject: rawhide report: 20040218 changes Message-ID: <200402181510.i1IFAV206842@porkchop.devel.redhat.com> New package commons-fileupload Jakarta Commons Fileupload Component New package commons-pool Jakarta Commons Pool Component New package iiimf-le-xcin An IIIMF Language Engine for Traditional Chinese. Removed package gcc-ssa Updated Packages: arts-1.2.0-1.4 -------------- * Tue Feb 17 2004 Than Ngo 1.2.0-1.4 - add missing build requirements - add patch file from Bero #115507 * Fri Feb 13 2004 Elliot Lee - rebuilt bind-9.2.3-7 ------------ * Tue Feb 17 2004 Daniel Walsh 9.2.3-7 - Add COPYRIGHT * Fri Feb 13 2004 Elliot Lee - rebuilt cdparanoia-alpha9.8-20 ---------------------- * Tue Feb 17 2004 Peter Jones alpha9.8-20 - take ownership of /usr/include/cdda * Fri Feb 13 2004 Elliot Lee - rebuilt diskcheck-1.6-1 --------------- * Wed Feb 18 2004 Harald Hoyer - 2:1.6-1 - fixed traceback for non-df filesystems like ntfs (115861) dovecot-0.99.10.4-3 ------------------- * Tue Feb 17 2004 Jeremy Katz - 0.99.10.4-3 - restart properly if it dies (#115594) * Fri Feb 13 2004 Elliot Lee - rebuilt firstboot-1.3.5-1 ----------------- * Tue Feb 17 2004 Brent Fox 1.3.5-1 - call self.win.present() to allow initial keyboard input * Mon Feb 16 2004 Brent Fox 1.3.4-1 - UTF-8ify fr.po - make sure the root window stays on the bottom (bug #105631) gnome-spell-1.0.5-4 ------------------- * Tue Feb 17 2004 Jeremy Katz - 1.0.5-4 - allow building with deprecated gtk+ widgets (#115082) * Fri Feb 13 2004 Elliot Lee - rebuilt im-sdk-11.4-11 -------------- * Mon Feb 16 2004 Yu Shao r11.4-11 - #115215, init script doesn't show ok bug - #113922, gconf error bug * Fri Feb 13 2004 Elliot Lee - rebuilt kernel-2.6.2-1.87 ----------------- libwnck-2.5.1-3 --------------- * Tue Feb 17 2004 Alexander Larsson 2.5.1-3 - Link to Xres now that it is PIC * Fri Feb 13 2004 Elliot Lee - rebuilt netpbm-10.19-6 -------------- * Tue Feb 17 2004 Phil Knirsch 10.19-6 - Fixed problem in pnmquant with GetOptions() and args/ARGV (#115788). * Fri Feb 13 2004 Elliot Lee 10.19-5 - rebuilt perl-Parse-RecDescent-1.94-3 ---------------------------- * Tue Feb 17 2004 Chip Turner 1.94-2 - fix rm to not be interactive (bz115997) * Fri Feb 13 2004 Chip Turner 1.94-1 - update to 1.94 policy-1.4.16-2 --------------- * Mon Feb 16 2004 Dan Walsh 1.4.16-2 - Latest from Russell - Added lots more ypbind fixes - put back in krb5_conf_t so can dontaudit writes. * Fri Feb 13 2004 Elliot Lee - rebuilt pygtk2-2.0.0-5 -------------- * Tue Feb 17 2004 Jeremy Katz - 2.0.0-5 - GtkTextSearchFlags is flags, not enum (#114910) * Fri Feb 13 2004 Elliot Lee - rebuilt qt-3.3.0-0.3 ------------ * Tue Feb 17 2004 Than Ngo 3.3.0-0.3 - enable IPv6 support - use dlopen, instead of linking with OpenGL libraries directly - don't install backup files rpmdb-fedora-1.90-0.20040218 ---------------------------- samba-3.0.2a-1 -------------- * Mon Feb 16 2004 Jay Fenlason 3.0.2a-1 - Upgrade to 3.0.2a servletapi-2.3-2 ---------------- * Tue Feb 17 2004 Gary Benson 2.3-2 - Add missing epoch to -devel subpackage's dependencies (#115999). system-config-display-1.0.6-1 ----------------------------- * Tue Feb 17 2004 Brent Fox 1.0.6-1 - write XF86Config to the correct path (bug #115501) system-config-soundcard-1.2.3-1 ------------------------------- * Mon Feb 16 2004 Brent Fox 1.2.3-1 - fix some product naming in soundcard.py (bug #115698) x3270-3.3.2.p1-3 ---------------- * Tue Feb 17 2004 Karsten Hopp 3.3.2.p1-3 - include license file * Fri Feb 13 2004 Elliot Lee - rebuilt xmms-1.2.9-4.p -------------- * Sat Feb 14 2004 Than Ngo 1:1.2.9-4.p - disable xmms-1.2.8-arts.patch * Fri Feb 13 2004 Elliot Lee - rebuilt From notting at redhat.com Wed Feb 18 17:19:47 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Feb 2004 12:19:47 -0500 Subject: FC2 on DVD? In-Reply-To: <002601c3f622$01a530f0$0100000a@itaca> References: <002601c3f622$01a530f0$0100000a@itaca> Message-ID: <20040218171946.GE10166@devserv.devel.redhat.com> Simon (f.simon at email.it) said: > Is there any chance that FC2 will be released also as a single DVD iso too? > Isn't that more handy? DVD isos will almost certainly be generated for the final release, and maybe one later test release. Bill From georg at georgs.org Wed Feb 18 18:28:06 2004 From: georg at georgs.org (Georg E Schneider) Date: Wed, 18 Feb 2004 18:28:06 +0000 Subject: FC2 on DVD? In-Reply-To: <002601c3f622$01a530f0$0100000a@itaca> References: <002601c3f622$01a530f0$0100000a@itaca> Message-ID: <4033AEB6.90305@georgs.org> Simon schrieb: >Is there any chance that FC2 will be released also as a single DVD iso too? >Isn't that more handy? > >Thanks. >-- >Simon. > > > > FC2 is the future and I think It will provided as DVD too like FC1 via torrent. If you mean a test release, I think it will be not provided. But you can build your own DVD. Go back to message id msg00736 of 2003-October from this list. HTH Georg E Schneider From ed at redhat.com Wed Feb 18 19:28:39 2004 From: ed at redhat.com (Edward C. Bailey) Date: Wed, 18 Feb 2004 14:28:39 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: <1076970196.3227.104.camel@Madison.badger.com> (toshio@tiki-lounge.com's message of "Mon, 16 Feb 2004 17:23:18 -0500") References: <1076970196.3227.104.camel@Madison.badger.com> Message-ID: >>>>> "Toshio" == Toshio writes: ... Toshio> I like the idea of more structure. I don't know if I agree with Toshio> using comps.xml for groups, though. ... Toshio> So I would like groups based on changes to the distro rather than Toshio> groups based on lists of programs. (Ie: selinux group w/ Toshio> description of selinux and how packages have changed/been added to Toshio> make this work.) Yes, this would be very nice. I'd note, however, that many of the types of entries that have been put in the release notes in the past have been "one-offs" -- to use your example, there might only be one short blurb about a change to SELinux, and no other SELinux-related stuff. So the possibility exists for release notes with many sections, most of which are one entry in length. Not that useful... :-) Of course, the two counter-examples to this are Anaconda and the kernel; As it turns out, Anaconda is the sole occupant of the "Supported Packages" group (yeah, I don't know what that name is supposed to mean, either), and the kernel is part of the "Core" group (which contains ~40 other packages, most of which I've never written about in the release notes). So although this approach is different from the one you've described, the effect may end up being quite close to what you're asking for... :-) Toshio> That might be a lot more work though as it requires a human to Toshio> decide what the overall themes are and construct how those themes Toshio> fit with the changes in the features of indiidual packages. Bingo! You've hit on the exact reason I'm not going to do it that way! :-) The problem is that the content for the release notes comes to me in dribs and drabs -- never all at once. This makes is difficult to come up with a structure (other than "mechanically" -- like basing the structure on package groups) that makes sense. Add to this the fact that the release notes are *always* undergoing last-minute -- er, make that last-second -- changes, and you can see that the effort to come up with a nicely thought-out structure is too great, and the time in which to do it is too small. Toshio> If a package-based scheme is adopted, I think the groups should be Toshio> thought out a little more. Well, I have absolutely no control over that, so if you want to see a change in the package groups, it's time to talk it up on the list and hope the right developers see it. :-) Toshio> Even though the release notes are a flat file, there should be a Toshio> hierarchy to it (So emacs, xemacs, and editors can be together; Toshio> development tools and ruby; etc) If a group has too many worthy Toshio> changes, then subsections can be broken out. If not, then keep the Toshio> changes together so the grouping reduces the number of things I'm Toshio> thinking about rather than increases it. The way the release notes are displayed in Anaconda limits what I can do as far as the hierarchy is concerned. The HTML rendering widget used is pretty primitive, so a single-level hierarchy is pretty much the best we can shoot for. Toshio> Once again, just my two cents. I'm sure I'll find useful whatever Toshio> format is produced. Thanks -- hopefully you won't be disappointed... :-) Ed -- Ed Bailey Red Hat, Inc. http://www.redhat.com/ From ville.skytta at iki.fi Wed Feb 18 19:36:10 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 18 Feb 2004 21:36:10 +0200 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <20040218050539.69608397.ms-nospam-0306@arcor.de> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> <1077049604.9498.613.camel@bobcat.mine.nu> <20040218050539.69608397.ms-nospam-0306@arcor.de> Message-ID: <1077132969.9498.775.camel@bobcat.mine.nu> On Wed, 2004-02-18 at 06:05, Michael Schwendt wrote: > You mean to paste a clearsigned review into _that_ small window in the > "Edit attachment" screen? Well, let's hope that this would not give people > headaches about invalidated signatures again. Yep, that's one of the things I'm a bit worried whether the Bugzilla UI really works for this purpose. Patching the textarea to be bigger would of course be trivial. > I still like attachment > statuses though. It just starts to make the package submission process > more strict, which is not a good thing. Maybe another keyword has not > been a bad idea afterall. Seconded. From ed at redhat.com Wed Feb 18 19:39:06 2004 From: ed at redhat.com (Edward C. Bailey) Date: Wed, 18 Feb 2004 14:39:06 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: <40317EC3.3090206@insight.rr.com> (Jim Cornette's message of "Mon, 16 Feb 2004 21:38:59 -0500") References: <40317EC3.3090206@insight.rr.com> Message-ID: >>>>> "Jim" == Jim Cornette writes: Jim> The use of the categories from the group selection sounds like a good Jim> idea. Maybe a bit more compression with the categories might be better Jim> for a less cluttered page. Since the categories won't all need Jim> commenting on. It might work out using the same selections. That was my plan -- to eliminate all sections lacking any content... Jim> I would like to see an install and upgrade section. The upgrade to Jim> list programs removed or added, plus any additional hints on importing Jim> the new programs or removing the orphaned programs from the upgraded Jim> system. I intend to keep the "packages added/removed/deprecated" sections that were part of the FC1 release notes. I doubt the types of hints you're looking for will be part of that, however -- that kind of stuff doesn't tend to be the sort of content sent to me. Of course, if the community wants to start work documenting those kinds of issues, I'll be more than happy to add the resulting content... ;-) Jim> On the install section. Things concerning what hardware needs special Jim> attention and things related to known issues concerning the current Jim> test or final release. Um, isn't that what the release notes as a whole are supposed to do? :-) Ed -- Ed Bailey Red Hat, Inc. http://www.redhat.com/ From ed at redhat.com Wed Feb 18 19:42:08 2004 From: ed at redhat.com (Edward C. Bailey) Date: Wed, 18 Feb 2004 14:42:08 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: <1076971189.4747.47.camel@athlon.localdomain> (Leonard den Ottolander's message of "Mon, 16 Feb 2004 23:39:49 +0100") References: <1076971189.4747.47.camel@athlon.localdomain> Message-ID: >>>>> "Leonard" == Leonard den Ottolander writes: Leonard> Hello Edward, >> Base Core Leonard> What's the difference between these two? Or more specifically, Leonard> what is Core? /usr/share/comps/i386/comps.xml :-) (My plan is to have a sentence or two starting each section that describes the group...) ... Leonard> Shouldn't these be moved to Office/Productivity? ... Leonard> Move to Development Tools? The groups and how they are used is not my area of authority -- I have to work with whatever is there... Ed -- Ed Bailey Red Hat, Inc. http://www.redhat.com/ From tdiehl at rogueind.com Wed Feb 18 21:17:26 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 18 Feb 2004 16:17:26 -0500 (EST) Subject: FC2 on DVD? In-Reply-To: <20040218171946.GE10166@devserv.devel.redhat.com> References: <002601c3f622$01a530f0$0100000a@itaca> <20040218171946.GE10166@devserv.devel.redhat.com> Message-ID: On Wed, 18 Feb 2004, Bill Nottingham wrote: > Simon (f.simon at email.it) said: > > Is there any chance that FC2 will be released also as a single DVD iso too? > > Isn't that more handy? > > DVD isos will almost certainly be generated for the final release, > and maybe one later test release. Whoops there goes more mirror disk space!! :-) Tom From tdiehl at rogueind.com Wed Feb 18 21:19:08 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 18 Feb 2004 16:19:08 -0500 (EST) Subject: rawhide report: 20040217 changes In-Reply-To: <200402180821.09458.czar@czarc.net> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402171750.22243.czar@czarc.net> <1077071867.27223.5.camel@delerium.codemonkey.org.uk> <200402180821.09458.czar@czarc.net> Message-ID: On Wed, 18 Feb 2004, Gene C. wrote: > On Tuesday 17 February 2004 21:37, Dave Jones wrote: > > On Tue, 2004-02-17 at 22:50, Gene C. wrote: > > > > anything using /dev/psaux should be changed over to use /dev/input/mice > > > > > > Errk ... no, this is not sufficent ... "should be changed" ... sorry, > > > that does not cut it. > > > > > > While I can understand that this change to the kernel is a good idea, a > > > statement in an email that it "should be changed" is not enough. > > > > Welcome to rawhide. > > OK. > > Question: when FC2 test2, FC2 test3, etc. come along and a user does an > "upgrade" install, what is going to "fix things up" so that they work? You are!! If not then reinstall. Upgrades from test to test and test to final are not nore were they ever supported. If they worked you were lucky. Tom From hvdkooij at vanderkooij.org Wed Feb 18 21:25:31 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Wed, 18 Feb 2004 22:25:31 +0100 (CET) Subject: rawhide report: 20040217 changes In-Reply-To: <20040218144051.GE11971@angus.ind.WPI.EDU> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402171750.22243.czar@czarc.net> <1077071867.27223.5.camel@delerium.codemonkey.org.uk> <200402180821.09458.czar@czarc.net> <20040218144051.GE11971@angus.ind.WPI.EDU> Message-ID: On Wed, 18 Feb 2004, Charles R. Anderson wrote: > On Wed, Feb 18, 2004 at 08:21:09AM -0500, Gene C. wrote: > > Question: when FC2 test2, FC2 test3, etc. come along and a user does an > > "upgrade" install, what is going to "fix things up" so that they work? > > Nothing. Upgrades aren't supported between test releases, or from a > test release to the final release. But will FC1 to testX be supported? It would be nice to see in what way a test release is able to perform a task that will required from FC2. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From czar at czarc.net Wed Feb 18 22:05:50 2004 From: czar at czarc.net (Gene C.) Date: Wed, 18 Feb 2004 17:05:50 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402180821.09458.czar@czarc.net> Message-ID: <200402181705.50763.czar@czarc.net> On Wednesday 18 February 2004 16:19, Tom Diehl wrote: > > Question: when FC2 test2, FC2 test3, etc. come along and a user does an > > "upgrade" install, what is going to "fix things up" so that they work? > > You are!! If not then reinstall. Upgrades from test to test and test to > final are not nore were they ever supported. If they worked you were lucky. The only time I have used upgrade is to test the upgrade process. I believe you minunderstood what I meant (I did say it clearly enough). By Fc2test2, FC2test3, etc. I mean upgrading from FC1 to FC2test2, etc (or RHL9 to FC2test2). Right now neither system-config-mouse nor system-config-display handle this properly (they still try to us psaux and or don't do anything). These have been bugzilla'ed. When it comes up wrong, the system trys to fix things by running mouseconfig (system-config-mouse) but this does nothing. Similarly, I could be able to run system-config-display --reconfig and have it create a new /etc/X11/XF86Config which works. It starts out trying to use psaux and gets nowhere. I was complaining because I believe this transition could have been handled smoother. However, test1 is a beta and will have rough edges. What I am concerned about is how the final will work. -- Gene From hvdkooij at vanderkooij.org Wed Feb 18 22:10:54 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Wed, 18 Feb 2004 23:10:54 +0100 (CET) Subject: rawhide report: 20040217 changes In-Reply-To: <200402181705.50763.czar@czarc.net> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402180821.09458.czar@czarc.net> <200402181705.50763.czar@czarc.net> Message-ID: On Wed, 18 Feb 2004, Gene C. wrote: > I believe you minunderstood what I meant (I did say it clearly enough). By > Fc2test2, FC2test3, etc. I mean upgrading from FC1 to FC2test2, etc (or RHL9 > to FC2test2). I do not think anyone could reconstruct this meaning from your original posting. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From tdiehl at rogueind.com Wed Feb 18 22:29:35 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 18 Feb 2004 17:29:35 -0500 (EST) Subject: rawhide report: 20040217 changes In-Reply-To: <200402181705.50763.czar@czarc.net> References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402180821.09458.czar@czarc.net> <200402181705.50763.czar@czarc.net> Message-ID: On Wed, 18 Feb 2004, Gene C. wrote: > On Wednesday 18 February 2004 16:19, Tom Diehl wrote: > > > Question: when FC2 test2, FC2 test3, etc. come along and a user does an > > > "upgrade" install, what is going to "fix things up" so that they work? > > > > You are!! If not then reinstall. Upgrades from test to test and test to > > final are not nore were they ever supported. If they worked you were lucky. > > The only time I have used upgrade is to test the upgrade process. > > I believe you minunderstood what I meant (I did say it clearly enough). By > Fc2test2, FC2test3, etc. I mean upgrading from FC1 to FC2test2, etc (or RHL9 > to FC2test2). Right now neither system-config-mouse nor > system-config-display handle this properly (they still try to us psaux and or > don't do anything). These have been bugzilla'ed. Umm, sorry I did misunderstand. > When it comes up wrong, the system trys to fix things by running mouseconfig > (system-config-mouse) but this does nothing. > > Similarly, I could be able to run system-config-display --reconfig and have it > create a new /etc/X11/XF86Config which works. It starts out trying to use > psaux and gets nowhere. > > I was complaining because I believe this transition could have been handled > smoother. However, test1 is a beta and will have rough edges. What I am > concerned about is how the final will work. Given that Dave Jones has disabled the psaux stuff in the kernel I expect this to get fixed. FWIW a fresh install of FC2 T1 sets up psaux also. Tom From tdiehl at rogueind.com Wed Feb 18 22:31:50 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 18 Feb 2004 17:31:50 -0500 (EST) Subject: rawhide report: 20040217 changes In-Reply-To: References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> <200402171750.22243.czar@czarc.net> <1077071867.27223.5.camel@delerium.codemonkey.org.uk> <200402180821.09458.czar@czarc.net> <20040218144051.GE11971@angus.ind.WPI.EDU> Message-ID: On Wed, 18 Feb 2004, Hugo van der Kooij wrote: > On Wed, 18 Feb 2004, Charles R. Anderson wrote: > > > On Wed, Feb 18, 2004 at 08:21:09AM -0500, Gene C. wrote: > > > Question: when FC2 test2, FC2 test3, etc. come along and a user does an > > > "upgrade" install, what is going to "fix things up" so that they work? > > > > Nothing. Upgrades aren't supported between test releases, or from a > > test release to the final release. > > But will FC1 to testX be supported? It would be nice to see in what way a > test release is able to perform a task that will required from FC2. Normally yes, but several RH people have stated there is some breakage in FC2 T1, although I forget the details. Tom From cra at WPI.EDU Wed Feb 18 22:38:56 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 18 Feb 2004 17:38:56 -0500 Subject: FC2 on DVD? In-Reply-To: References: <002601c3f622$01a530f0$0100000a@itaca> <20040218171946.GE10166@devserv.devel.redhat.com> Message-ID: <20040218223856.GM26418@angus.ind.WPI.EDU> On Wed, Feb 18, 2004 at 04:17:26PM -0500, Tom Diehl wrote: > > DVD isos will almost certainly be generated for the final release, > > and maybe one later test release. > Whoops there goes more mirror disk space!! :-) Jigdo! http://bugzilla.fedora.us/show_bug.cgi?id=1252 Please help QA. If it works out, this may be a solution to the CD ISO and DVD ISO problem. From czar at czarc.net Wed Feb 18 23:47:22 2004 From: czar at czarc.net (Gene C.) Date: Wed, 18 Feb 2004 18:47:22 -0500 Subject: rawhide report: 20040217 changes In-Reply-To: References: <200402171451.i1HEp6p14787@porkchop.devel.redhat.com> Message-ID: <200402181847.22756.czar@czarc.net> On Wednesday 18 February 2004 17:31, Tom Diehl wrote: > On Wed, 18 Feb 2004, Hugo van der Kooij wrote: > > On Wed, 18 Feb 2004, Charles R. Anderson wrote: > > > On Wed, Feb 18, 2004 at 08:21:09AM -0500, Gene C. wrote: > > > > Question: when FC2 test2, FC2 test3, etc. come along and a user does > > > > an "upgrade" install, what is going to "fix things up" so that they > > > > work? > > > > > > Nothing. Upgrades aren't supported between test releases, or from a > > > test release to the final release. > > > > But will FC1 to testX be supported? It would be nice to see in what way a > > test release is able to perform a task that will required from FC2. > > Normally yes, but several RH people have stated there is some breakage > in FC2 T1, although I forget the details. Breakage in the early rounds is more or less par for the course. Its the final that I am concerned about. -- Gene From toshio at tiki-lounge.com Thu Feb 19 00:09:17 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 18 Feb 2004 19:09:17 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: References: <1076970196.3227.104.camel@Madison.badger.com> Message-ID: <1077149351.12589.189.camel@Madison.badger.com> On Wed, 2004-02-18 at 14:28, Edward C. Bailey wrote: > >>>>> "Toshio" == Toshio writes: > Toshio> So I would like groups based on changes to the distro rather than > Toshio> groups based on lists of programs. (Ie: selinux group w/ > Toshio> description of selinux and how packages have changed/been added to > Toshio> make this work.) > > Yes, this would be very nice. I'd note, however, that many of the types of > entries that have been put in the release notes in the past have been > "one-offs" -- to use your example, there might only be one short blurb > about a change to SELinux, and no other SELinux-related stuff. So the > possibility exists for release notes with many sections, most of which are > one entry in length. Not that useful... :-) > I don't want small one-off groups. The SELinux group would talk about all the bits and pieces of all the packages that had to be modified to make the change happen. Like you say though, this is a lot^H^H^H^H^H too much work. > Toshio> If a package-based scheme is adopted, I think the groups should be > Toshio> thought out a little more. > > Well, I have absolutely no control over that, so if you want to see a > change in the package groups, it's time to talk it up on the list and hope > the right developers see it. :-) > I think that the use case of a software installer versus informational reading is different enough that the comps.xml file can be fine for the installer and inappropriate for the release notes. That said, I think the comps.xml file can be a very good starting place. It just needs some simple adjustments like condensing several of the comps.xml groups into one meta-group. When you talk about not including a group if there's nothing to say about it, that's good, but in my view, there shouldn't be a group if there's not at least three entries in it. (Maybe I did too many outlines in grade school:-) But the information should still be in the release notes. So the information has to be promoted up a level to find a metagroup with enough information in it to justify its existence. > Toshio> Even though the release notes are a flat file, there should be a > Toshio> hierarchy to it (So emacs, xemacs, and editors can be together; > Toshio> development tools and ruby; etc) If a group has too many worthy > Toshio> changes, then subsections can be broken out. If not, then keep the > Toshio> changes together so the grouping reduces the number of things I'm > Toshio> thinking about rather than increases it. > > The way the release notes are displayed in Anaconda limits what I can do as > far as the hierarchy is concerned. The HTML rendering widget used is > pretty primitive, so a single-level hierarchy is pretty much the best we > can shoot for. > I don't need hypertext links and all that, but can't we do something like this: Editors: * Emacs o An Emacs nifty new feature o An Elisp nifty new feature o A new wanderlust feature * XEmacs o yadda yadda yadda 0 yadda-yadda 2 * Vim Desktop Environments * Gnome o ... o ... o ... * KDE * XFCE Network servers * imap * web server o mod_ssl o tux o mod_python * samba If there's a lot to say about a component, then add more entries underneath. If there really isn't then leave it all at the next higher level. I need more organization to help my brain remember all the changes in the distribution. Even a shallow hierarchy like this makes it possible to remember a lot more detail. -Toshio -- Toshio From katmandu at fs.inf.br Thu Feb 19 13:50:20 2004 From: katmandu at fs.inf.br (Adriano Del Vigna de Almeida) Date: Thu, 19 Feb 2004 10:50:20 -0300 Subject: Modifications at the GNOME main menu Message-ID: <1077198253.24314.16.camel@adriano.freesoftware> Hello there! I'm working in modifications in the GNOME main menu, reorganizing it, adding and removing some features. Currently I'm working into the 'redhat-menus' package, simply making modifications for tests. But I got no results. For example, I removed the 'Accessories' section from 'applications-submenu.m4' file, recompiled the package and re-installed the package, and got no results. The 'Accessories' menu section remains there. Any other modification get no results. Am I working at the correct package and files? Thanks in advance! Adriano Del Vigna de Almeida Free Software Bras?lia - Curitiba - Rio de Janeiro - S?o Paulo Email: katmandu at fs.inf.br ICQ#: 14898488 -------------- next part -------------- An HTML attachment was scrubbed... URL: From surak at casa.surak.eti.br Thu Feb 19 14:08:07 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Thu, 19 Feb 2004 11:08:07 -0300 Subject: Modifications at the GNOME main menu In-Reply-To: <1077198253.24314.16.camel@adriano.freesoftware> References: <1077198253.24314.16.camel@adriano.freesoftware> Message-ID: <1077199686.19367.26.camel@casa> Em Qui, 2004-02-19 ?s 10:50, Adriano Del Vigna de Almeida escreveu: > For example, I removed the 'Accessories' section from > 'applications-submenu.m4' file, recompiled the package and > re-installed the package, and got no results. The 'Accessories' menu > section remains there. Any other modification get no results. Am I > working at the correct package and files? Oi Adriano! there was some postings about changing redhat menu gnomes on fedora-list yesterday or the day before. Look the archives as I deleted the message. O que ? essa fs.inf.br? > -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From surak at casa.surak.eti.br Thu Feb 19 14:08:35 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Thu, 19 Feb 2004 11:08:35 -0300 Subject: Changing gnome menus Message-ID: <1077199715.19367.28.camel@casa> http://www.wse.jhu.edu/newtnotes/main_file.php/sysadmin/55/ -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From mike at netlyncs.com Thu Feb 19 15:21:46 2004 From: mike at netlyncs.com (Mike Chambers) Date: Thu, 19 Feb 2004 09:21:46 -0600 Subject: Rawhide Dir Message-ID: <1077204105.1596.5.camel@bart.netlyncs.com> Is it just me, or does the Fedora download server and the mirrors have double versions of packages instead of the older one being deleted? --- Mike Chambers Madisonville, KY 2.6.2-1.87 #1 Mon Feb 16 21:30:19 EST 2004 i686 GNU/Linux 09:20:53 up 1:09, 1 user, load average: 1.51, 1.59, 1.46 From leonard at den.ottolander.nl Thu Feb 19 10:23:37 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 19 Feb 2004 11:23:37 +0100 Subject: Gnome-panel update? Message-ID: <1077186217.11891.4.camel@athlon.localdomain> Hi, Seeing the multitude of issues with gnome-panel that have not been solved I thought it might be time for an update. There are two approaches to this: Fixing the current tree, or updating to 2.4.2 which is a bug fix release. Considering the first option I have gathered some issues and patches. Please have a look at http://www.ottolander.nl/gnome-panel/ for details. You might want to give the attached spec file and patches a try. I am not sure how difficult an update to 2.4.2 would be in relation to patches that have already been applied to 2.4.0. Thoughts? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dirk.wendland at nexgo.de Thu Feb 19 10:35:03 2004 From: dirk.wendland at nexgo.de (Dirk Wendland) Date: Thu, 19 Feb 2004 11:35:03 +0100 Subject: Winex Message-ID: <1077186903.2905.8.camel@Internetpc> Hello coul??d in next destribution add winex package I don??t know the license for this project but for gamers under Linux it is an alternative way to play the games on Linux machines ... Greetings Dirk From warren at togami.com Thu Feb 19 10:37:10 2004 From: warren at togami.com (Warren Togami) Date: Thu, 19 Feb 2004 00:37:10 -1000 (HST) Subject: Cleaning up "Preferred Applications" & Desktop Consistency In-Reply-To: <200312301656.24850.nomis80@nomis80.org> References: <3FE984B0.6050906@togami.com> <200312241109.24239.nomis80@nomis80.org> <3FE9FD65.5060103@togami.com> <200312301656.24850.nomis80@nomis80.org> Message-ID: <33136.66.91.85.198.1077187030.squirrel@togami.com> > On December 24, 2003 15:56, Warren Togami wrote: >> I would please ask that you check this yourself, as I have far too many >> other things to work on. Please report back your findings. > > I just committed my patch to CVS. Konqueror 3.2 will have CTRL-+ and > CTRL-- as > zoom accels. > > -- > Simon Perreault -- http://nomis80.org Using kdebase-3.2.0-0.4 (based on KDE 3.2.0 and qt 3.3.0), CTRL+- works in shrinking the font, but CTRL++ appears to not work at first glance like Mozilla. However the actual problem is that it literally is set to CTRL++, and CTRL+= does not work, so the user must hit CTRL-Shift-= which is not what is expected. Would it be possible to set Konqueror's default to work with CTRL+= as well as CTRL++ like Mozilla's default? Warren Togami wtogami at redhat.com From warren at togami.com Thu Feb 19 11:17:00 2004 From: warren at togami.com (Warren Togami) Date: Thu, 19 Feb 2004 01:17:00 -1000 (HST) Subject: Cleaning up "Preferred Applications" & Desktop Consistency In-Reply-To: <200312241109.24239.nomis80@nomis80.org> References: <3FE984B0.6050906@togami.com> <200312241109.24239.nomis80@nomis80.org> Message-ID: <33287.66.91.85.198.1077189420.squirrel@togami.com> > On December 24, 2003 07:21, Warren Togami wrote: >> 13) In the name of end-user application consistency, Konqueror could use >> some extra key-bindings by default to make it behave like Mozilla. The >> following do not conflict with current Konqueror defaults. >> >> CTRL-W Close current tab. >> CTRL-+ Larger font. >> CTRL-- Smaller font. > > Konqueror key bindings have been modified recently (ie. in the last week > or > so) for reasons similar to your own. Discussion has taken place on the > kde-usability mailing list, so you should search the archives > (http://lists.kde.org/?l=kde-usability&r=1&w=2). > >> Other common Mozilla keybindings conflict with already defined Konqueror >> bindings, and I really don't feel it is worth the emotional & political >> fight to ask that they change. > > Some "unification" keybindings were decided against, because they were in > fact > disrupting the unification of KDE as a whole. For eaxmple, CTRL-wheel was > proposed as a zoom control, like many other browsers do. But this was > rejected because in every Qt app, CTRL-wheel works like page up/page down. > > The point is: you might be tempted to unify Konqueror with other browsers, > but > don't forget that you will probably be breaking unification within KDE. So > your best bet is to CC: every change to kde-usability at mail.kde.org, > especially if the KDE community has any worth to you. > >> Any active KDE developers here? Could you please get these checked-in >> so it can be in KDE 3.2? RH/Fedora will not apply this change, and we >> will only have it if upstream applies it. Please confirm in a reply >> when it has been submitted. > > This is a good policy. Check the current 3.2 configuration, I think has > what > you want. If not, tell me what you need and I'll get kde-usability to > discuss > it. Please review and discuss these proposed changes upstream and report back. If they reject a certain change, it would help if you can get reasons. Font Bigger CTRL+= Shortcut (proposed) CTRL=+ Alternate (proposed) This simple change would make it behave exactly like Mozilla's defaults. Clear Location Bar Ctrl+L Shortcut (proposed) Simple addition makes it behave very similar to Mozilla. Full Screen Mode Ctrl+Shift+F Shortcut F11 Alternate (proposed) Simple addition makes it behave like Mozilla and Internet Explorer while retaining the previous shortcut. Activate Next Tab Ctrl+. Shortcut Ctrl+] Alternate Ctrl+PageDown (proposed) Add Mozilla's binding if possible as another alternate, or replacing the less popular of the two current methods. Which is the less popular of the two? The PageUp and PageDown seems to be a standard for changing between tabs across many GNOME apps. Is there a KDE equivalent standardized? Activate Previous Tab Ctrl+ Shortcut Ctrl+[ Alternate Ctrl+PageUp (proposed) Add Mozilla's binding if possible as another alternate, or replacing the less popular of the two current methods. Which is the less popular of the two? The PageUp and PageDown seems to be a standard for changing between tabs across many GNOME apps. Is there a KDE equivalent standardized? New Tab Ctrl+Shift+N Shortcut Ctrl+T Alternate (proposed) Open Terminal currently uses Ctrl+T. This may be a controversial change for this reason. The Ctrl+T function of Mozilla is heavily used. If KDE does not accept this change upstream, I may personally lobby for it for Fedora defaults anyway. Open Terminal would then need a different default shortcut. Warren Togami wtogami at redhat.com From twaugh at redhat.com Thu Feb 19 12:20:57 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 19 Feb 2004 12:20:57 +0000 Subject: FC1 and FC2 compatibility In-Reply-To: <20040213095142.GA25654@redhat.com> References: <1076625266.7101.3.camel@ssloan> <20040213095142.GA25654@redhat.com> Message-ID: <20040219122057.GO6654@redhat.com> On Fri, Feb 13, 2004 at 09:51:42AM +0000, I wrote: > o The libdb library has changed soname, and so anything that uses it > will require the version it was built against. Looks like we have a db-compat package actually. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nomis80 at nomis80.org Thu Feb 19 15:56:40 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Thu, 19 Feb 2004 10:56:40 -0500 Subject: Cleaning up "Preferred Applications" & Desktop Consistency In-Reply-To: <33136.66.91.85.198.1077187030.squirrel@togami.com> References: <3FE984B0.6050906@togami.com> <200312301656.24850.nomis80@nomis80.org> <33136.66.91.85.198.1077187030.squirrel@togami.com> Message-ID: <200402191056.40279.nomis80@nomis80.org> On February 19, 2004 5:37, Warren Togami wrote: > Using kdebase-3.2.0-0.4 (based on KDE 3.2.0 and qt 3.3.0), CTRL+- works in > shrinking the font, but CTRL++ appears to not work at first glance like > Mozilla. However the actual problem is that it literally is set to > CTRL++, and CTRL+= does not work, so the user must hit CTRL-Shift-= which > is not what is expected. Yes, this is a known problem. If I enabled the CTRL+= shortcut, then the numeric keypad + would not work. We could not quickly find a fix and so we settled for the know-stable way. I filed #75627 which you can view at http://bugs.kde.org/show_bug.cgi?id=75627. -- Simon Perreault -- http://nomis80.org From notting at redhat.com Thu Feb 19 16:08:46 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Feb 2004 11:08:46 -0500 Subject: Rawhide Dir In-Reply-To: <1077204105.1596.5.camel@bart.netlyncs.com> References: <1077204105.1596.5.camel@bart.netlyncs.com> Message-ID: <20040219160846.GA29545@devserv.devel.redhat.com> Mike Chambers (mike at netlyncs.com) said: > Is it just me, or does the Fedora download server and the mirrors have > double versions of packages instead of the older one being deleted? The script has --max-delete set to avoid nuking the tree on major screwups. However, if 90% of the tree changes, this causes the old ones to stick around. It will get cleaned up later today/tomorrow. Bill From linux at bytebot.net Thu Feb 19 17:06:45 2004 From: linux at bytebot.net (Colin Charles) Date: Fri, 20 Feb 2004 01:06:45 +0800 Subject: Winex In-Reply-To: <1077186903.2905.8.camel@Internetpc> References: <1077186903.2905.8.camel@Internetpc> Message-ID: <1077206709.1605.71.camel@hermione> On Thu, 2004-02-19 at 18:35, Dirk Wendland wrote: > could in next destribution add winex package No. > I dont know the license for this project but for gamers under Linux it > is an alternative way to play the games on Linux machines ... Last I checked, WineX costed you money even (subscription based model). The cvs checkout versions are free though. -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ http://fedoranews.org/colin/fnu/ - Fedora News Updates From salimma at fastmail.fm Thu Feb 19 17:08:15 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Fri, 20 Feb 2004 00:08:15 +0700 Subject: Winex In-Reply-To: <1077186903.2905.8.camel@Internetpc> References: <1077186903.2905.8.camel@Internetpc> Message-ID: <1077210495.2885.31.camel@bushido.mshome.net> On Thu, 2004-02-19 at 11:35 +0100, Dirk Wendland wrote: > Hello > > coul?d in next destribution add winex package > Nope. While the main tree of WineX is licensed under Aladdin Free Public License, AFAIK (like bleeding-edge ghostscript releases, before they eventually get GPL'ed), the parts that access copy-protected CDs, as well as probably DirectX, are proprietary, in accordance with TransGaming's NDA it seems. WineX is not really usable without that, and while IANAL, my reading of the AFPL says you can't make money selling it, which will limit Fedora's distribution to that of SuSE (no cheap CDs, downloads OK) > I don?t know the license for this project but for gamers under Linux it > is an alternative way to play the games on Linux machines ... > You could, of course, pay Transgaming $5 everytime they do a release. Or get a longer-term subscription; you cannot post support requests if you do not have a current subscription. Just remember that since Transgaming's disagreement with Codeweavers and most other developers, any work done by each side would not necessarily end up being used by the other (main Wine is now LGPL instead of X11- licensed) 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 thunderbirds at pandora.be Thu Feb 19 17:23:01 2004 From: thunderbirds at pandora.be (Gregory Petit) Date: Thu, 19 Feb 2004 18:23:01 +0100 Subject: 3Com 3c940 ethernet card In-Reply-To: <000d01c3f623$f41dfc80$0100000a@itaca> References: <000d01c3f623$f41dfc80$0100000a@itaca> Message-ID: <200402191823.03026.thunderbirds@pandora.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op woensdag 18 februari 2004 14:34, schreef Simon: > The 3Com 3c940 ethernet card embedded in my Asus KV8 Deluxe is supported by > the kernel module sk98lin but not detected during FC2 installing. > ... and what about your soundcard? I've the same motherboard, but I can't get my soundcard up. If it works, can you mail me your modprobe.conf? I've tried several configurations I saw on the fedora mailinglists, but it still doesn't work. ... Oh, and what about xmms? I get a core dump, you also? to get your NIC up and running, add alias eth0 sk98lin in modules.conf. Kind regards, Gregory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFANPD1IXdlaijlOucRAor2AJ9Y8B8dwzN6WotG1j8zmkjmbERyPQCcDxEU hF3JAXJlInadV1nfhNZM4ok= =4Kxd -----END PGP SIGNATURE----- From nomis80 at nomis80.org Thu Feb 19 17:33:31 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Thu, 19 Feb 2004 12:33:31 -0500 Subject: Cleaning up "Preferred Applications" & Desktop Consistency In-Reply-To: <33287.66.91.85.198.1077189420.squirrel@togami.com> References: <3FE984B0.6050906@togami.com> <200312241109.24239.nomis80@nomis80.org> <33287.66.91.85.198.1077189420.squirrel@togami.com> Message-ID: <200402191233.31519.nomis80@nomis80.org> On February 19, 2004 6:17, Warren Togami wrote: > Font Bigger > CTRL+= Shortcut (proposed) > CTRL=+ Alternate (proposed) > This simple change would make it behave exactly like Mozilla's defaults. Everyone agrees that this should be done. I will investigate methods to do it. > Clear Location Bar > Ctrl+L Shortcut (proposed) > Simple addition makes it behave very similar to Mozilla. In KDE 3.1, that shortcut was present. > Full Screen Mode > Ctrl+Shift+F Shortcut > F11 Alternate (proposed) > Simple addition makes it behave like Mozilla and Internet Explorer while > retaining the previous shortcut. I'm fully in favor of this. > Activate Next Tab > Ctrl+. Shortcut > Ctrl+] Alternate > Ctrl+PageDown (proposed) > Add Mozilla's binding if possible as another alternate, or replacing the > less popular of the two current methods. Which is the less popular of the > two? The PageUp and PageDown seems to be a standard for changing between > tabs across many GNOME apps. Is there a KDE equivalent standardized? The standard KDE shortcut for next tab is CTRL+], but I couldn't find it written anywhere. CTRL+. was added for people with non-us keyboards who have to press a second modifier key to reach the ]. We could add a third shortcut, so there's no need to remove one of the other two. There is another problem though: CTRL+PageDown is already defined as a standard KDE-wide shortcut. See http://developer.kde.org/documentation/standards/kde/style/keys/cursorKeys.html. It is used to go down one logical screen, ie. go to the next page. I can imagine this being used in paged media like PDF documents, but on a website it has no meaning. I will propose this key in addition to the other two. Since it is not used, and will not be used as defined in the standard, I think we can make an exception. > Activate Previous Tab > Ctrl+ Shortcut > Ctrl+[ Alternate > Ctrl+PageUp (proposed) > Add Mozilla's binding if possible as another alternate, or replacing the > less popular of the two current methods. Which is the less popular of the > two? The PageUp and PageDown seems to be a standard for changing between > tabs across many GNOME apps. Is there a KDE equivalent standardized? Same as above. > New Tab > Ctrl+Shift+N Shortcut > Ctrl+T Alternate (proposed) > Open Terminal currently uses Ctrl+T. This may be a controversial change > for this reason. The Ctrl+T function of Mozilla is heavily used. If KDE > does not accept this change upstream, I may personally lobby for it for > Fedora defaults anyway. Open Terminal would then need a different default > shortcut. This has been discussed on kde-usability and is associated with bug #59794, which can be viewed at http://bugs.kde.org/show_bug.cgi?id=59794. There seems to be more people for than against. I will propose a patch that closes this bug. To be continued... -- Simon Perreault -- http://nomis80.org From f.simon at email.it Thu Feb 19 17:40:06 2004 From: f.simon at email.it (simon) Date: Thu, 19 Feb 2004 18:40:06 +0100 Subject: 3Com 3c940 ethernet card References: <000d01c3f623$f41dfc80$0100000a@itaca> <200402191823.03026.thunderbirds@pandora.be> Message-ID: <001001c3f70f$6ae70140$0700000a@ulisse> > > The 3Com 3c940 ethernet card embedded in my Asus KV8 Deluxe is supported by > > ... and what about your soundcard? I've the same motherboard, but I can't get > my soundcard up. > If it works, can you mail me your modprobe.conf? I've tried several > configurations I saw on the fedora mailinglists, but it still doesn't work. FC2-test1 has sucessfully found and configured the right module (I dont remember which one). The problem is that the channel names are wrong, turn up all devices (master, headphones, wave, line-out, etc...), remove the "mute"... and find which ones are the real channels. -- Simon. From katmandu at fs.inf.br Thu Feb 19 18:06:04 2004 From: katmandu at fs.inf.br (Adriano Del Vigna de Almeida) Date: Thu, 19 Feb 2004 15:06:04 -0300 Subject: Modifications at the GNOME main menu In-Reply-To: <1077199686.19367.26.camel@casa> References: <1077198253.24314.16.camel@adriano.freesoftware> <1077199686.19367.26.camel@casa> Message-ID: <1077213964.24314.88.camel@adriano.freesoftware> > Em Qui, 2004-02-19 ?s 10:50, Adriano Del Vigna de Almeida escreveu: > > > For example, I removed the 'Accessories' section from > > 'applications-submenu.m4' file, recompiled the package and > > re-installed the package, and got no results. The 'Accessories' menu > > section remains there. Any other modification get no results. Am I > > working at the correct package and files? > > Oi Adriano! > > there was some postings about changing redhat menu gnomes on fedora-list > yesterday or the day before. Look the archives as I deleted the message. I looked there, and they are archived for the last month, January (http://www.redhat.com/archives/fedora-devel-list/2004-January/msg00202.html). But that are user specific solutions. I need a system-wide solution. In fact, I need to modify the default GNOME application menu to have a more similar organization to MS-Windows 9x/Me/2000 'Start' menu. So I started to hack the 'redhat-menus' package. And got no results. There is no documentation inside the package about the inner working of this feature. This list seems to me the only place to ask for questions, since this is a Red Hat specific package... Any other direction? > > O que ? essa fs.inf.br? The company I work for... :) > > > -- > []s > > Alexandre Ganso > 500 FOUR vermelha - Diretor Steel Goose Moto Group Adriano Del Vigna de Almeida Free Software Bras?lia - Curitiba - Rio de Janeiro - S?o Paulo Email: katmandu at fs.inf.br ICQ#: 14898488 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smiley-3.png Type: image/png Size: 819 bytes Desc: not available URL: From thunderbirds at pandora.be Thu Feb 19 18:12:40 2004 From: thunderbirds at pandora.be (Gregory Petit) Date: Thu, 19 Feb 2004 19:12:40 +0100 Subject: sound on ASUS K8V (was: 3Com 3c940 ethernet card) In-Reply-To: <001001c3f70f$6ae70140$0700000a@ulisse> References: <000d01c3f623$f41dfc80$0100000a@itaca> <200402191823.03026.thunderbirds@pandora.be> <001001c3f70f$6ae70140$0700000a@ulisse> Message-ID: <200402191912.44176.thunderbirds@pandora.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op donderdag 19 februari 2004 18:40, schreef simon: > FC2-test1 has sucessfully found and configured the right module (I dont > remember which one). The problem is that the channel names are wrong, turn > up all devices (master, headphones, wave, line-out, etc...), remove the > "mute"... and find which ones are the real channels. Hmmm, nope, doesn't works. Here's my etc/modprobe.conf: include /etc/modprobe.conf.dist alias scsi_hostadapter sata_via alias scsi_hostadapter1 sata_promise alias usb-controller ehci-hcd alias usb-controller1 uhci-hcd alias ieee1394-controller ohci1394 alias sound-slot-0 snd-via82xx install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : alias eth0 sk98lin This is what Fedora detected by default (execept for the sk98lin driver). Am I missing in this conf file? Kind regards, Gregory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFANPyYIXdlaijlOucRAn9hAJ9LAD31Yob98gKlQguPf92iYpArOACdGy8x JfCZlYOm2g31neEcpATaFG4= =8O6J -----END PGP SIGNATURE----- From nate at acsmagnum.com Thu Feb 19 19:30:25 2004 From: nate at acsmagnum.com (Nate Bradley) Date: Thu, 19 Feb 2004 13:30:25 -0600 Subject: Help building an rpm Message-ID: I hope this is the right list. I am trying to build an rpm for mod_perl-1.29 (I'm using apache 1.3) rpmbuild is complaining that the perl files cannot be found and that is true because the directory cannot be cd'd to directly. It is looking for the files in /var/tmp/mod_perl-root/usr/lib/perl?/... but when I cd to '/var/tmp/mod_perl-root/usr/lib/perl? the directory doesn't exist. if I cd to '/var/tmp/mod_perl-root/usr/lib' there is a 'debug' directory instead of 'perl?'. only when I cd to '/var/tmp/mod_perl-root' then cd to 'usr/lib' does the perl (and everything else) directory appear. What is this behavior?? I'm including the .spec file modified from mod_perl-1.26-5. %define defperlver 5.8.1 %define perlver %(rpm -q perl --queryformat '%%{version}' 2> /dev/null || echo %{defperlver}) %define perlmajor %(echo %{perlver} | cut -f1 -d.) %define contentdir /var/www Summary: An embedded Perl interpreter for the Apache Web server. Name: mod_perl Version: 1.29 Release: 1 Group: System Environment/Daemons Source0: http://perl.apache.org/dist/mod_perl-1.29.tar.gz License: GPL URL: http://perl.apache.org/ BuildRoot: %{_tmppath}/%{name}-root Requires: webserver, perl = %{perlver} BuildPrereq: apache-devel, perl Prereq: perl %description Mod_perl incorporates a Perl interpreter into the Apache web server, so that the Apache web server can directly execute Perl code. Mod_perl links the Perl runtime library into the Apache web server and provides an object-oriented Perl interface for Apache's C language API. The end result is a quicker CGI script turnaround process, since no external Perl interpreter has to be started. Install mod_perl if you're installing the Apache web server and you'd like for it to directly incorporate a Perl interpreter. %prep %setup -q -n mod_perl-%{version} %build # Compile the module. perl Makefile.PL \ USE_APXS=1 WITH_APXS=%{_sbindir}/apxs PERL_USELARGEFILES=0 \ EVERYTHING=1 CCFLAGS="$RPM_OPT_FLAGS -fPIC -DEAPI" make # Run the test suite. make test %install [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT make pure_install INSTALLDIRS=vendor PREFIX=$RPM_BUILD_ROOT%{_prefix} # Install the module itself. mkdir -p $RPM_BUILD_ROOT/etc/httpd/modules install -c -m 755 apaci/libperl.so $RPM_BUILD_ROOT/etc/httpd/modules/ # Install its manual. mkdir -p $RPM_BUILD_ROOT%{contentdir}/html/manual/mod/mod_perl install -c -m 644 htdocs/manual/mod/mod_perl.html \ $RPM_BUILD_ROOT%{contentdir}/html/manual/mod make -C faq rm faq/pod2htm* install -m644 faq/*.html $RPM_BUILD_ROOT%{contentdir}/html/manual/mod/mod_perl/ # Remove the temporary files. #find $RPM_BUILD_ROOT%{_libdir}/perl?/vendor_perl/*/*/auto -name "*.bs" | xargs rm #rm $RPM_BUILD_ROOT%{_libdir}/perl?/vendor_perl/*/*/auto/%{name}/.packlist %clean [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root) %doc CREDITS Changes README SUPPORT cgi_to_mod_perl.pod mod_perl.pod %doc mod_perl_method_handlers.pod mod_perl_traps.pod mod_perl_tuning.pod %doc INSTALL faq/*.html eg faq %doc apache-modlist.html %{contentdir}/html/manual/mod/* #%{_libdir}/apache/libperl.so /etc/httpd/modules/libperl.so %{_libdir}/perl?/vendor_perl/*/*/auto/* %{_libdir}/perl?/vendor_perl/*/*/Apache* %{_libdir}/perl?/vendor_perl/*/*/Bundle/* %{_libdir}/perl?/vendor_perl/*/*/cgi* %{_libdir}/perl?/vendor_perl/*/*/mod_perl* %{_mandir}/man3/*.3* From ghenry at suretecsystems.com Thu Feb 19 19:44:52 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 19 Feb 2004 19:44:52 +0000 Subject: Help building an rpm In-Reply-To: References: Message-ID: <200402191944.58285.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is an example perl specfile here: http://atrpms.physik.fu-berlin.de/dist/fc1/perl-GD/perl-GD.spec - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANRI3eWseh9tzvqgRAkTcAKCZLRmj94OAU36zfoVoSkMB4HiklwCeMEnr DJVK4jb+G0589SkMX9v1aYU= =WKIf -----END PGP SIGNATURE----- From markmc at redhat.com Thu Feb 19 17:14:29 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 19 Feb 2004 17:14:29 +0000 Subject: Gnome-panel update? In-Reply-To: <1077186217.11891.4.camel@athlon.localdomain> References: <1077186217.11891.4.camel@athlon.localdomain> Message-ID: <1077210868.3458.40.camel@laptop> Hi Leonard, On Thu, 2004-02-19 at 10:23, Leonard den Ottolander wrote: > Hi, > > Seeing the multitude of issues with gnome-panel that have not been > solved I thought it might be time for an update. There are two > approaches to this: Fixing the current tree, or updating to 2.4.2 which > is a bug fix release. > > Considering the first option I have gathered some issues and patches. > Please have a look at http://www.ottolander.nl/gnome-panel/ for details. > You might want to give the attached spec file and patches a try. > > I am not sure how difficult an update to 2.4.2 would be in relation to > patches that have already been applied to 2.4.0. Thoughts? I'm hoping to start getting a handle on this either tommorrow or next week. I don't know yet what approach we'll take - the first thing I have to do is figure out what are the most visible outstanding bug and how many of them have been fixed upstream in 2.4.2. Actually, it would be very helpful if you could compile such a list ... Cheers, Mark. From katmandu at fs.inf.br Thu Feb 19 21:56:50 2004 From: katmandu at fs.inf.br (Adriano Del Vigna de Almeida) Date: Thu, 19 Feb 2004 18:56:50 -0300 Subject: Modifications at the GNOME main menu In-Reply-To: <1077213964.24314.88.camel@adriano.freesoftware> References: <1077198253.24314.16.camel@adriano.freesoftware> <1077199686.19367.26.camel@casa> <1077213964.24314.88.camel@adriano.freesoftware> Message-ID: <1077227810.24314.101.camel@adriano.freesoftware> Ann... I got it all working now... I were making a mistake when 'configure'ing the package. I was setting the prefix variable to '/usr', and it should be just '/'. Every thing is working now... Now I have one more question ;) Its possible to sort the GNOME main menu other than alphabetically? > > Em Qui, 2004-02-19 ?s 10:50, Adriano Del Vigna de Almeida escreveu: > > > > > For example, I removed the 'Accessories' section from > > > 'applications-submenu.m4' file, recompiled the package and > > > re-installed the package, and got no results. The 'Accessories' menu > > > section remains there. Any other modification get no results. Am I > > > working at the correct package and files? > > > > Oi Adriano! > > > > there was some postings about changing redhat menu gnomes on fedora-list > > yesterday or the day before. Look the archives as I deleted the message From leonard at den.ottolander.nl Thu Feb 19 22:51:08 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 19 Feb 2004 23:51:08 +0100 Subject: Gnome-panel update? In-Reply-To: <1077210868.3458.40.camel@laptop> References: <1077186217.11891.4.camel@athlon.localdomain> <1077210868.3458.40.camel@laptop> Message-ID: <1077231067.12220.28.camel@athlon.localdomain> Hi Mark, > > Please have a look at http://www.ottolander.nl/gnome-panel/ for details. > I'm hoping to start getting a handle on this either tommorrow or next week. Great. > I don't know yet what approach we'll take - Neither do I. Not sure how much work it would be to combine current patches with 2.4.2 (for as much needed). I do think upgrading to 2.4.2 would be the best solution, but I am unsure of how much work that would involve. > the first thing I have > to do is figure out what are the most visible outstanding bug This time I started from the top. These are the ones I could grasp. > and how many of them have been fixed upstream in 2.4.2. A couple of the open bugs, and probably a couple that have not been identified on Fedora yet. > Actually, it would be very helpful if you could compile such a list ... See the above URL for the current state of the list. These appear to be addressable issues to me. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ghenry at suretecsystems.com Thu Feb 19 23:02:18 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 19 Feb 2004 23:02:18 +0000 Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) Message-ID: <200402192302.20987.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, for anyone that is interested I have made some rpms for the New Linux version of PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) I have hosted the rpms here: http://www.suretecsystems.com/putty/md5sums http://www.suretecsystems.com/putty/putty-0.54-0.1.noarch.rpm http://www.suretecsystems.com/putty/putty.spec http://www.suretecsystems.com/putty/putty-0.54-0.1.src.rpm Should I submit these to the Fedora QA team and update the specfile Fedora standards and to fdr extension? - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANUB6eWseh9tzvqgRAnbfAJ4hGz8F9UESJ5pMLqA3JrbuZ3RahgCfQeUW y7bcwOax6TgVz1b4PLSuDtU= =NGLx -----END PGP SIGNATURE----- From dag at wieers.com Fri Feb 20 00:10:37 2004 From: dag at wieers.com (Dag Wieers) Date: Fri, 20 Feb 2004 01:10:37 +0100 (CET) Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: <200402192302.20987.ghenry@suretecsystems.com> References: <200402192302.20987.ghenry@suretecsystems.com> Message-ID: Hi Gavin, On Thu, 19 Feb 2004, Gavin Henry wrote: > for anyone that is interested I have made some rpms for the New Linux version > of PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) > > I have hosted the rpms here: > > http://www.suretecsystems.com/putty/md5sums > http://www.suretecsystems.com/putty/putty-0.54-0.1.noarch.rpm > http://www.suretecsystems.com/putty/putty.spec > http://www.suretecsystems.com/putty/putty-0.54-0.1.src.rpm I looked at your SPEC file and compared it what I had. I have the following differences: + What is the reason for choosing noarch ? + No desktop entry + No desktop icon + No manpages (there are 2 missing since the last release though) + You have a static version-less dependency for gtk+ + Don't use %makeinstall where possible You can compare it with: http://dag.wieers.com/packages/putty/putty.spec > Should I submit these to the Fedora QA team and update the specfile Fedora > standards and to fdr extension? For those interested for RHEL21, RH73, RH80, RH90, RHEL3 and RHFC1 at: http://dag.wieers.com/packages/putty/ Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From pri.rhl1 at iadonisi.to Fri Feb 20 01:01:22 2004 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: Thu, 19 Feb 2004 20:01:22 -0500 Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: <200402192302.20987.ghenry@suretecsystems.com> References: <200402192302.20987.ghenry@suretecsystems.com> Message-ID: <1077238882.10083.53.camel@va.local.linuxlobbyist.org> On Thu, 2004-02-19 at 18:02, Gavin Henry wrote: [snip] > I have hosted the rpms here: > > http://www.suretecsystems.com/putty/md5sums > http://www.suretecsystems.com/putty/putty-0.54-0.1.noarch.rpm > http://www.suretecsystems.com/putty/putty.spec > http://www.suretecsystems.com/putty/putty-0.54-0.1.src.rpm Just an FYI. For a reason that had me stumped for a while, I couldn't reach this web site. I was about to post a message to that effect until I remembered that ECN has now been turned on by default in the 2.6 kernel that comes with FC2T1. I'm running FC1, but I've upgraded my kernel to the rawhide kernel. Turning this bit off (sysctl -w net.ipv4.tcp_ecn=0) fixed the problem. So, as an FYI to you, realizing that you may have no control over the problem, you are very likely behind one of those routers from an unnamed popular networking vendor that doesn't like ECN. Anyhow, thanks for the rpms. I didn't even know there was a Linux version of putty. -- -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 didierbe at sps.nus.edu.sg Fri Feb 20 02:41:01 2004 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Fri, 20 Feb 2004 10:41:01 +0800 (SGT) Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: Message-ID: On 20/02/04, at 01:10 +0100, Dag Wieers wrote: > > I looked at your SPEC file and compared it what I had. I have the > following differences: > > + What is the reason for choosing noarch ? > + No desktop entry > + No desktop icon > + No manpages (there are 2 missing since the last release though) > + You have a static version-less dependency for gtk+ > + Don't use %makeinstall where possible > > You can compare it with: > > http://dag.wieers.com/packages/putty/putty.spec > > > For those interested for RHEL21, RH73, RH80, RH90, RHEL3 and RHFC1 at: > > http://dag.wieers.com/packages/putty/ I've always been amazed by the way you create your spec files! I've packaged some rpms too but when I compared my spec files to yours, well they looked so inferior! :-/ If I may ask, how do you package so rapidly and so neatly? I've read Maximum rpm plus various docs on the net but they seem to lack this finesse that you use. What's your secret? Do you have some sort of scripts which are on standby and which can package virtually anything? And one last question: How to you package for different versions of RH? For instance I've FC1 right now in my box, if I want to package for RH9 and below, how should I go about it? Thanks for your time. With kind regards, Didier. --- PhD student. Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg / didierbe at sps dot nus dot edu dot sg Web: http://ssls.nus.edu.sg From ghenry at suretecsystems.com Fri Feb 20 07:39:58 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 20 Feb 2004 07:39:58 +0000 Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: References: <200402192302.20987.ghenry@suretecsystems.com> Message-ID: <200402200740.01689.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 February 2004 00:10, Dag Wieers wrote: > Hi Gavin, > > On Thu, 19 Feb 2004, Gavin Henry wrote: > > for anyone that is interested I have made some rpms for the New Linux > > version of PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) > > > > I have hosted the rpms here: > > > > http://www.suretecsystems.com/putty/md5sums > > http://www.suretecsystems.com/putty/putty-0.54-0.1.noarch.rpm > > http://www.suretecsystems.com/putty/putty.spec > > http://www.suretecsystems.com/putty/putty-0.54-0.1.src.rpm > > I looked at your SPEC file and compared it what I had. I have the > following differences: > > + What is the reason for choosing noarch ? > + No desktop entry > + No desktop icon > + No manpages (there are 2 missing since the last release though) > + You have a static version-less dependency for gtk+ > + Don't use %makeinstall where possible Cheers Dag, I will look over this and reply later today. > > You can compare it with: > > http://dag.wieers.com/packages/putty/putty.spec > > > Should I submit these to the Fedora QA team and update the specfile > > Fedora standards and to fdr extension? > > For those interested for RHEL21, RH73, RH80, RH90, RHEL3 and RHFC1 at: > > http://dag.wieers.com/packages/putty/ > > Kind regards, > -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- > [Any errors in spelling, tact or fact are transmission errors] - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANbnOeWseh9tzvqgRAmReAJ9C4IfOkCHM92BmGiXGBQAMuJx0KQCePX+q dKvI7ycQR5vMQ6zaimBV64E= =Qefr -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Fri Feb 20 09:19:18 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 20 Feb 2004 09:19:18 -0000 (GMT) Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: References: <200402192302.20987.ghenry@suretecsystems.com> Message-ID: <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> > Hi Gavin, > > On Thu, 19 Feb 2004, Gavin Henry wrote: > >> for anyone that is interested I have made some rpms for the New Linux >> version >> of PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) >> >> I have hosted the rpms here: >> >> http://www.suretecsystems.com/putty/md5sums >> http://www.suretecsystems.com/putty/putty-0.54-0.1.noarch.rpm >> http://www.suretecsystems.com/putty/putty.spec >> http://www.suretecsystems.com/putty/putty-0.54-0.1.src.rpm > > I looked at your SPEC file and compared it what I had. I have the > following differences: > > + What is the reason for choosing noarch ? I am a beginner with building rpms, so I am trying to do as many as possible. I thought, if it was noarch it would indicate it would work on any rpm distro. > + No desktop entry > + No desktop icon I didn't notice there was any. > + No manpages (there are 2 missing since the last release though) I need to check for these. > + You have a static version-less dependency for gtk+ Again, a beginner, so all this will be changed. > + Don't use %makeinstall where possible I understand this bit. You have: %makeinstall -C unix -f Makefile.gtk in your specfile. > > You can compare it with: > > http://dag.wieers.com/packages/putty/putty.spec > > I know you are much better than most at doing rpms, so I will update mine to include a desktop entry, pic and man files. Also, take out gtk+ in requires and what is this for: ### FIXME: Disable missing pscp.1 and psftp.1. (Please fix upstream) %{__perl} -pi.orig -e ' s|-O2|%{optflags}|g; s|/usr/local|%{_prefix}|g; s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; ' unix/Makefile.gtk Is this built for servral version of gnome? Hence you if/else loops. Again, I am learning :-) Lastly, if I had known you had done one already, I wouldn't of done one :-) But mine does a least work ;) -- Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com From s.mako at gmx.net Fri Feb 20 10:00:21 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Fri, 20 Feb 2004 11:00:21 +0100 (CET) Subject: Self-Introduction: Zoltan Kota - new key Message-ID: 1. Full legal name Zoltan Kota Something went wrong on my computer, so I had to create a new pgp key: 7. GPG KEYID and fingerprint pub 1024D/F2594A58 2004-02-16 Zoltan Kota Key fingerprint = 9CCB A661 FE96 800F 31F0 40DB 9C65 8C7A F259 4A58 sub 1024g/18904A30 2004-02-16 [expires: 2006-02-15] Zoli From buildsys at redhat.com Fri Feb 20 10:20:37 2004 From: buildsys at redhat.com (Build System) Date: Fri, 20 Feb 2004 05:20:37 -0500 Subject: rawhide report: 20040220 changes Message-ID: <200402201020.i1KAKbT08825@porkchop.devel.redhat.com> From dag at wieers.com Fri Feb 20 10:30:41 2004 From: dag at wieers.com (Dag Wieers) Date: Fri, 20 Feb 2004 11:30:41 +0100 (CET) Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> References: <200402192302.20987.ghenry@suretecsystems.com> <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> Message-ID: On Fri, 20 Feb 2004, Gavin Henry wrote: > > I looked at your SPEC file and compared it what I had. I have the > > following differences: > > > > + What is the reason for choosing noarch ? > > I am a beginner with building rpms, so I am trying to do as many as possible. I understand. > I thought, if it was noarch it would indicate it would work on any rpm > distro. Well, sadly RPM doesn't have a standard for saying for which distribution something was made. It would have been nice even if Red Hat would have added something more to the Distribution-tag than only 'Red Hat Linux' so that one could query rpmdb for those. That's why some repositories are adding distrotags. In my opinion it's better to have 5 identical packages with a different package name (release) than to have one package that's uncertain for what distro it was packaged for (omitting the distrotag is difficult as you can't say it will work for any future distribution). noarch packages is to indicate that a package works for any architecture. Mostly used for shell-scripts, some python/perl packages and other packages that don't contain architecture specific binaries. > > + No desktop entry > > + No desktop icon > > I didn't notice there was any. Well, even if there's no icon GUI programs should appear somewhere in the menu. If I have no icon I usually take the icon that Red Hat provides for the same Category so that it doesn't show up with a blank. But putty was something that people mat recognize from the icon (when they move from Windows to Linux) so I thought it was important to have the same icon. > > + No manpages (there are 2 missing since the last release though) > > I need to check for these. > > > + You have a static version-less dependency for gtk+ > > Again, a beginner, so all this will be changed. Well, actually if you wanted to create one package that worked for different Red Hat packages, this was the right way to do it. But I don't think it's better to tag a package for a specific distribution and then the requirement isn't really needed (and wrt managing the files unwanted). > > + Don't use %makeinstall where possible > > I understand this bit. You have: > %makeinstall -C unix -f Makefile.gtk in your specfile. Yes, since you didn't include the manpages, using %makefile would have forced you to include everything the developers wanted you to include. It's always better to follow an existing infrastructure if you can. In a lot of case you can't though. > I know you are much better than most at doing rpms, so I will update mine > to include a desktop entry, pic and man files. Also, take out gtk+ in > requires and what is this for: > > ### FIXME: Disable missing pscp.1 and psftp.1. (Please fix upstream) > %{__perl} -pi.orig -e ' > s|-O2|%{optflags}|g; > s|/usr/local|%{_prefix}|g; > s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; > ' unix/Makefile.gtk Well, I favor perl-oneliners over patches as they allow me to quickly see what it does without having to look for other files and sometimes lots of data. They also stand a fair chance of working when you update to newer releases and can even be automated to test if a specific patch is still needed. Of course sometimes a patch is absolutely required, but if it can be done inline I'd rather do it like that. The first substitution replaces the normal compiler-flags to what RPM is normally using. The second replaces all instanced of /usr/local by the prefix that's defined by RPM, usually /usr. And the last substitution disables 2 manpages (comment above) that were rmeoved from the official release). > Is this built for servral version of gnome? Hence you if/else loops. Yes, this is rather sad. RH73 and earlier don't have a desktop-file-install utilitiy which I use to install desktop-files. So that's why I first query for its existance and then use it if it exists. > Again, I am learning :-) That's good ! ;) > Lastly, if I had known you had done one already, I wouldn't of done one :-) > > But mine does a least work ;) Well, it's definitely better to try yourself and then look at others (than just look at others). If you're goal is to learn to package, anyway. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From salimma at fastmail.fm Fri Feb 20 12:44:09 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Fri, 20 Feb 2004 19:44:09 +0700 Subject: FC2 on DVD? In-Reply-To: <20040218223856.GM26418@angus.ind.WPI.EDU> References: <002601c3f622$01a530f0$0100000a@itaca> <20040218171946.GE10166@devserv.devel.redhat.com> <20040218223856.GM26418@angus.ind.WPI.EDU> Message-ID: <1077281049.20391.1.camel@bushido.mshome.net> On Wed, 2004-02-18 at 17:38 -0500, Charles R. Anderson wrote: [snip] > Jigdo! > > http://bugzilla.fedora.us/show_bug.cgi?id=1252 > > Please help QA. If it works out, this may be a solution to the CD ISO > and DVD ISO problem. Neat. Been waiting to see something like this outside Debian for a while; would be handy when doing test releases. - 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 mharris at redhat.com Fri Feb 20 12:47:07 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 20 Feb 2004 07:47:07 -0500 (EST) Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> References: <200402192302.20987.ghenry@suretecsystems.com> <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> Message-ID: On Fri, 20 Feb 2004, Gavin Henry wrote: >> I looked at your SPEC file and compared it what I had. I have the >> following differences: >> >> + What is the reason for choosing noarch ? > >I am a beginner with building rpms, so I am trying to do as many as possible. > >I thought, if it was noarch it would indicate it would work on any rpm >distro. "noarch" means "no architecture" or rather "architecture independant", which means that the contents of the package are useable as-is on x86, AMD64, ia64, alpha, sparc, ppc, ppc64, etc. without modification. Examples of noarch packages are documentation, fonts, other packages which are strictly architecture independant data, packages containing only interpreted perl, python, shell scripts, etc. Any package which contains code compiled specificially for a given architecture, such as i386, must not be flagged as "noarch", as rpm will allow it to be installed on any architecture then, which will result in failure at runtime. >> + No manpages (there are 2 missing since the last release though) > >I need to check for these. Make sure rpm is configured to refuse to generate packages if any files have been installed in the buildroot which are not listed in the %files section. That is the default if you install redhat-rpm-config. Hope this helps. Take care! TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jhf at rivenstone.net Fri Feb 20 14:15:09 2004 From: jhf at rivenstone.net (Joseph Fannin) Date: Fri, 20 Feb 2004 09:15:09 -0500 Subject: FC2 on DVD? In-Reply-To: <4033784A.6000009@atl.lmco.com> References: <002601c3f622$01a530f0$0100000a@itaca> <4033784A.6000009@atl.lmco.com> Message-ID: <20040220141509.GA2784@rivenstone.net> On Wed, Feb 18, 2004 at 09:35:54AM -0500, Doug Stewart wrote: > Simon wrote: >> Is there any chance that FC2 will be released also as a single DVD iso >> too? > > I, for one, prefer downloading all of the CD isos myself and > constructing the DVD iso using the mkdvdiso.sh that has been posted to > this list. > > I'd rather have to re-download a single 600MB corrupt CD ISO rather than > an entire 4GB corrupt DVD ISO. Corrupt isos can be fixed with rsync. Please? Every time RedHat puts out a new release my cable modem slows down for about a week. :-) -- Joseph Fannin jhf at rivenstone.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From leonard at den.ottolander.nl Fri Feb 20 15:06:20 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 20 Feb 2004 16:06:20 +0100 Subject: Gnome-panel update? In-Reply-To: <1077210868.3458.40.camel@laptop> References: <1077186217.11891.4.camel@athlon.localdomain> <1077210868.3458.40.camel@laptop> Message-ID: <1077289579.4766.32.camel@athlon.localdomain> Hello Mark, > > Seeing the multitude of issues with gnome-panel that have not been > > solved I thought it might be time for an update. There are two > > approaches to this: Fixing the current tree, or updating to 2.4.2 which > > is a bug fix release. >From the changes made to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104178 I understand you are planning to upgrade to 2.4.2. Great. This means I need only to gather patches for issues that are not addressed upstream. I think the missing help file for the update tool falls into this category. I am unsure if the missing help file for the show desktop applet has been solved upstream. This should be an easy fix for the author anyway. What is your opinion on splitting of a -devel package? Maybe Michael Schwendt is willing to generate the necessary spec file diff. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jkeating at j2solutions.net Fri Feb 20 17:21:38 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 20 Feb 2004 09:21:38 -0800 Subject: Building kernel rpms... Message-ID: <200402200921.42382.jkeating@j2solutions.net> When I have a kernel.src.rpm expanded in my rpmbuild directory, what is the proper command to issue on the .spec file to build all the kernels? the up/smp/bigmem stuff? rpmbuild -ba kernel.spec only gives me up, BOOT, DOC, -source. TIA! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) 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 nphilipp at redhat.com Fri Feb 20 17:34:16 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 20 Feb 2004 18:34:16 +0100 Subject: Building kernel rpms... In-Reply-To: <200402200921.42382.jkeating@j2solutions.net> References: <200402200921.42382.jkeating@j2solutions.net> Message-ID: <1077298456.9928.72.camel@wombat.tiptoe.de> On Fri, 2004-02-20 at 18:21, Jesse Keating wrote: > When I have a kernel.src.rpm expanded in my rpmbuild directory, what is > the proper command to issue on the .spec file to build all the kernels? > the up/smp/bigmem stuff? > > rpmbuild -ba kernel.spec only gives me up, BOOT, DOC, -source. This is because you're building the i386 target. If you want the other stuff, you should build the i686 and athlon targets as well: rpmbuild --target=athlon ... rpmbuild --target=i686 ... 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 jkeating at j2solutions.net Fri Feb 20 17:48:35 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 20 Feb 2004 09:48:35 -0800 Subject: Building kernel rpms... In-Reply-To: <1077298456.9928.72.camel@wombat.tiptoe.de> References: <200402200921.42382.jkeating@j2solutions.net> <1077298456.9928.72.camel@wombat.tiptoe.de> Message-ID: <200402200948.35145.jkeating@j2solutions.net> On Friday 20 February 2004 09:34, Nils Philippsen wrote: > This is because you're building the i386 target. If you want the > other stuff, you should build the i686 and athlon targets as well: > > rpmbuild --target=athlon ... > rpmbuild --target=i686 ... Yep, confirmed on IRC. rpmbuild -ba --target=i386,i686,athlon is what I needed to run. Cheers! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) 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 pp at ee.oulu.fi Fri Feb 20 17:59:01 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Fri, 20 Feb 2004 19:59:01 +0200 Subject: XFree86 4.3.0-56 EPIA test results In-Reply-To: <20040217185441.GB25396@devserv.devel.redhat.com> References: <20040216230040.GA29706@ee.oulu.fi> <20040217183453.GA19904@ee.oulu.fi> <20040217185441.GB25396@devserv.devel.redhat.com> Message-ID: <20040220175901.GA284@ee.oulu.fi> On Tue, Feb 17, 2004 at 01:54:41PM -0500, Alan Cox wrote: > On Tue, Feb 17, 2004 at 08:34:53PM +0200, Pekka Pietikainen wrote: > > http://epia.kalf.org/gryle_patches/via-v4l-1.4a-drm.patch.gz patch just fine > > into 2.6.2-1.85 (the drivers/media/video stuff that uses e.g. floating point > > If can be left out, which is what I did for this iteration of testing) > > If it even mentions ddmpeg its obsolete btw - so better to port the 2.4 > patches I just checked the situation, and the patch mentioned above is identical to the 2.4.22-ac4 one (if you only use the drivers/char/drm bit of it, that is), a few small tweaks to make it compile. The only change in it that is strictly not necessary to have things working is exporting via_fb_alloc and _free in via_mm.c (which is probably for the ddmpeg stuff and thus can be removed) -- Pekka Pietikainen From cturner at redhat.com Fri Feb 20 18:17:01 2004 From: cturner at redhat.com (Chip Turner) Date: 20 Feb 2004 13:17:01 -0500 Subject: Perl requires/provides proposal In-Reply-To: <20040218081432.4aea4788.ms-nospam-0306@arcor.de> References: <20040215061126.013c5490.ms-nospam-0306@arcor.de> <20040215070408.6abfad99.ms-nospam-0306@arcor.de> <39256.66.91.85.198.1076832682.squirrel@togami.com> <20040215121749.202c4c78.ms-nospam-0306@arcor.de> <20040218081432.4aea4788.ms-nospam-0306@arcor.de> Message-ID: Michael Schwendt writes: > On 17 Feb 2004 10:29:53 -0500, Chip Turner wrote: > > > Would an errata of perl 5.8.3 for FC1 (and maybe RHL9) with the proper > > provides, directory ownerships, etc help? Anyone willing to help test > > such a beast? :) > > Let's move forward and focus on FC2. Trying to update/maintain old > releases only kills finite resources. Agreed. However, RHEL3 needs a perl errata, so it isn't extra work. Basically I'm planning on putting an update to 5.8.3 out for RHL3 and FC1, letting it bake a bit, then look into getting it into RHEL3. I don't anticipate any disruption, and putting in the new virtual provides is basically zero-cost above the update itself. > Of course, you could release an FC1 Test Update anytime and hope for > feedback, regardless of whether the update will make it. Yep. Coming soon. Watch this space :) Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From ghenry at suretecsystems.com Fri Feb 20 18:17:19 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 20 Feb 2004 18:17:19 +0000 Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: References: <200402192302.20987.ghenry@suretecsystems.com> <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> Message-ID: <200402201817.21740.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 February 2004 10:30, Dag Wieers wrote: > On Fri, 20 Feb 2004, Gavin Henry wrote: > > > I looked at your SPEC file and compared it what I had. I have the > > > following differences: > > > > > > + What is the reason for choosing noarch ? > > > > I am a beginner with building rpms, so I am trying to do as many as > > possible. > > I understand. > > > I thought, if it was noarch it would indicate it would work on any rpm > > distro. > > Well, sadly RPM doesn't have a standard for saying for which distribution > something was made. It would have been nice even if Red Hat would have > added something more to the Distribution-tag than only 'Red Hat Linux' so > that one could query rpmdb for those. I am going to make this a normal fdr one. > > That's why some repositories are adding distrotags. In my opinion it's > better to have 5 identical packages with a different package name > (release) than to have one package that's uncertain for what distro it was > packaged for (omitting the distrotag is difficult as you can't say it will > work for any future distribution). > > noarch packages is to indicate that a package works for any architecture. > Mostly used for shell-scripts, some python/perl packages and other > packages that don't contain architecture specific binaries. > > > > + No desktop entry > > > + No desktop icon > > > > I didn't notice there was any. > > Well, even if there's no icon GUI programs should appear somewhere in the > menu. If I have no icon I usually take the icon that Red Hat provides for > the same Category so that it doesn't show up with a blank. I will use you desktop entry, but change the names a wee bit. > > But putty was something that people mat recognize from the icon (when they > move from Windows to Linux) so I thought it was important to have the same > icon. > > > > + No manpages (there are 2 missing since the last release though) > > > > I need to check for these. > > > > > + You have a static version-less dependency for gtk+ > > > > Again, a beginner, so all this will be changed. > > Well, actually if you wanted to create one package that worked for > different Red Hat packages, this was the right way to do it. But I don't > think it's better to tag a package for a specific distribution and then > the requirement isn't really needed (and wrt managing the files unwanted). Ok. > > > > + Don't use %makeinstall where possible > > > > I understand this bit. You have: > > %makeinstall -C unix -f Makefile.gtk in your specfile. > > Yes, since you didn't include the manpages, using %makefile would have > forced you to include everything the developers wanted you to include. I ment to say that I don't understand your comment here. > > It's always better to follow an existing infrastructure if you can. In a > lot of case you can't though. > > > I know you are much better than most at doing rpms, so I will update mine > > to include a desktop entry, pic and man files. Also, take out gtk+ in > > requires and what is this for: > > > > ### FIXME: Disable missing pscp.1 and psftp.1. (Please fix upstream) > > %{__perl} -pi.orig -e ' > > s|-O2|%{optflags}|g; > > s|/usr/local|%{_prefix}|g; > > s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; > > ' unix/Makefile.gtk > > Well, I favor perl-oneliners over patches as they allow me to quickly see > what it does without having to look for other files and sometimes lots of > data. They also stand a fair chance of working when you update to newer > releases and can even be automated to test if a specific patch is still > needed. Shouldn't you have a BuildRequires: perl then? > > Of course sometimes a patch is absolutely required, but if it can be done > inline I'd rather do it like that. > > The first substitution replaces the normal compiler-flags to what RPM is > normally using. The second replaces all instanced of /usr/local by the > prefix that's defined by RPM, usually /usr. And the last substitution > disables 2 manpages (comment above) that were rmeoved from the official > release). > > > Is this built for servral version of gnome? Hence you if/else loops. > > Yes, this is rather sad. RH73 and earlier don't have a > desktop-file-install utilitiy which I use to install desktop-files. So > that's why I first query for its existance and then use it if it exists. > > > Again, I am learning :-) > > That's good ! ;) > > > Lastly, if I had known you had done one already, I wouldn't of done one > > :-) > > > > But mine does a least work ;) > > Well, it's definitely better to try yourself and then look at others (than > just look at others). If you're goal is to learn to package, anyway. Agreed. :-) I will post the new urls when done. > > Kind regards, > -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- > [Any errors in spelling, tact or fact are transmission errors] - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANk8veWseh9tzvqgRAooWAJ41b3aakGsgFWDqnfHbPnKXLkkHJACgmdrI Sedy71blLw+N37qa8GWTiXg= =Mn9l -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Fri Feb 20 18:20:25 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 20 Feb 2004 18:20:25 +0000 Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: References: <200402192302.20987.ghenry@suretecsystems.com> <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> Message-ID: <200402201820.28469.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 February 2004 12:47, Mike A. Harris wrote: > On Fri, 20 Feb 2004, Gavin Henry wrote: > >> I looked at your SPEC file and compared it what I had. I have the > >> following differences: > >> > >> + What is the reason for choosing noarch ? > > > >I am a beginner with building rpms, so I am trying to do as many as > > possible. > > > >I thought, if it was noarch it would indicate it would work on any rpm > >distro. > > "noarch" means "no architecture" or rather "architecture > independant", which means that the contents of the package are > useable as-is on x86, AMD64, ia64, alpha, sparc, ppc, ppc64, etc. > without modification. Examples of noarch packages are > documentation, fonts, other packages which are strictly > architecture independant data, packages containing only > interpreted perl, python, shell scripts, etc. > > Any package which contains code compiled specificially for a > given architecture, such as i386, must not be flagged as > "noarch", as rpm will allow it to be installed on any > architecture then, which will result in failure at runtime. > > >> + No manpages (there are 2 missing since the last release though) > > > >I need to check for these. > > Make sure rpm is configured to refuse to generate packages if any > files have been installed in the buildroot which are not listed > in the %files section. That is the default if you install > redhat-rpm-config. I uninstalled this to stop the debug rpms being built. Is there another way? > > Hope this helps. > > Take care! > TTYL > > > > -- > Mike A. Harris ftp://people.redhat.com/mharris > OS Systems Engineer - XFree86 maintainer - Red Hat - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANk/peWseh9tzvqgRAkibAJ42akR2CQgMILdZB5/oNuHqqrU8HgCcCgH1 AR9B+UuSGh5t4wVnimTvczg= =krhF -----END PGP SIGNATURE----- From carwyn at carwyn.com Fri Feb 20 18:29:47 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 20 Feb 2004 18:29:47 +0000 Subject: PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/) In-Reply-To: <200402201820.28469.ghenry@suretecsystems.com> References: <200402192302.20987.ghenry@suretecsystems.com> <63938.193.195.148.66.1077268758.squirrel@www.suretecsystems.com> <200402201820.28469.ghenry@suretecsystems.com> Message-ID: <4036521B.7020309@carwyn.com> Gavin Henry wrote: >>Make sure rpm is configured to refuse to generate packages if any >>files have been installed in the buildroot which are not listed >>in the %files section. That is the default if you install >>redhat-rpm-config. >> >> > >I uninstalled this to stop the debug rpms being built. Is there another way? > > Well given the definition that creates it in /usr/lib/rpm/macros is: %debug_package \ %ifnarch noarch\ %global __debug_package 1\ %package debug\ Summary: Debug information for package %{name}\ Group: Development/Debug\ AutoReqProv: 0\ %description debug\ This package provides debug information for package %{name}.\ Debug information is useful when developing applications that use this\ package or when debugging this package.\ %files debug -f debugfiles.list\ %defattr(-,root,root)\ %endif\ %{nil} Putting: %debug_package %{nil} .. in your $HOME/.rpmmacros file is one way is it not? Carwyn From ed at redhat.com Fri Feb 20 19:19:37 2004 From: ed at redhat.com (Edward C. Bailey) Date: Fri, 20 Feb 2004 14:19:37 -0500 Subject: Thoughts on how to structure the release notes... In-Reply-To: <1077149351.12589.189.camel@Madison.badger.com> (toshio@tiki-lounge.com's message of "Wed, 18 Feb 2004 19:09:17 -0500") References: <1076970196.3227.104.camel@Madison.badger.com> <1077149351.12589.189.camel@Madison.badger.com> Message-ID: >>>>> "Toshio" == Toshio writes: Toshio> I don't want small one-off groups. The SELinux group would talk Toshio> about all the bits and pieces of all the packages that had to be Toshio> modified to make the change happen. Like you say though, this is a Toshio> lot^H^H^H^H^H too much work. You bet it would be! Whew -- every really important part of my body just puckered when I read this! :-) ... Toshio> I think that the use case of a software installer versus Toshio> informational reading is different enough that the comps.xml file Toshio> can be fine for the installer and inappropriate for the release Toshio> notes. That said, I think the comps.xml file can be a very good Toshio> starting place. It just needs some simple adjustments like Toshio> condensing several of the comps.xml groups into one meta-group. Maybe so, be keep in mind that such "simple adjustments" are what will chew up the majority of my most scarce commodity -- time. If I can get, say, 90% of the benefit, and that last 10% is going to double the amount of time required, it's not worth it -- I'll take the 90% benefit, and use the time saved for other tasks. That said, it may be that the structure of the comps file could use a bit of tweaking. However, that aspect of the distribution is not mine to tweak. :-) ... >> The way the release notes are displayed in Anaconda limits what I can >> do as far as the hierarchy is concerned. The HTML rendering widget used >> is pretty primitive, so a single-level hierarchy is pretty much the best >> we can shoot for. Toshio> I don't need hypertext links and all that, but can't we do Toshio> something like this: ... Toshio> If there's a lot to say about a component, then add more entries Toshio> underneath. If there really isn't then leave it all at the next Toshio> higher level. Toshio> I need more organization to help my brain remember all the changes Toshio> in the distribution. Even a shallow hierarchy like this makes it Toshio> possible to remember a lot more detail. I'll see if I can sweet-talk some developers into working on this -- one has already privately expressed willingness to look into this, so cross your fingers. :-) Ed -- Ed Bailey Red Hat, Inc. http://www.redhat.com/ From sopwith at redhat.com Fri Feb 20 20:38:04 2004 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 20 Feb 2004 15:38:04 -0500 (EST) Subject: FC2 test2 devel freeze reminder Message-ID: February 27. It's coming. File bug reports. Soon! Have fun, -- Elliot From czar at czarc.net Fri Feb 20 21:01:28 2004 From: czar at czarc.net (Gene C.) Date: Fri, 20 Feb 2004 16:01:28 -0500 Subject: FC2 test2 devel freeze reminder In-Reply-To: References: Message-ID: <200402201601.28185.czar@czarc.net> On Friday 20 February 2004 15:38, Elliot Lee wrote: > February 27. > > It's coming. > > File bug reports. > > Soon! With the current state of a number of mirrors (not in sync) it is difficult to get the updated packages so that we are not reporting bugs already fixed. I assume that the massive updated was needed to build everything with FC2test1 ... OK, needed step. But, something needs to be done about syncing the mirrors. IIRC, mirrors pulled their updates from a separate server (not download.fedora.redhat.com). If this is true, then something else needs to be done. If it is not true, then it should be considered so that folks with mirrors are not fighting for bandwidth with everyone else. Yes, I found a mirror that was in sync and did have bandwidth but that was a very manual, trial-and-error process. -- Gene From ghenry at suretecsystems.com Fri Feb 20 23:23:22 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 20 Feb 2004 23:23:22 +0000 Subject: New PuTTY 0.54-0.3 rpms for review. Message-ID: <200402202323.24851.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dag Wieers if you have a second, could you look these over? Or anyone else :-) http://www.suretecsystems.com/putty/md5sums http://www.suretecsystems.com/putty/putty-0.54-0.3.i386.rpm http://www.suretecsystems.com/putty/putty-0.54-0.3.src.rpm http://www.suretecsystems.com/putty/putty.spec http://www.suretecsystems.com/putty/SuretecSystemsLtd.asc Thanks. - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANpbqeWseh9tzvqgRAgaUAKCnbLzpOUwVnrbbkS0lyYF/fxV2RgCeN8rI MNS6KjbPwW8mumI9vRkka+4= =KfVc -----END PGP SIGNATURE----- From jwboyer at charter.net Sat Feb 21 03:37:34 2004 From: jwboyer at charter.net (Josh Boyer) Date: Fri, 20 Feb 2004 21:37:34 -0600 Subject: FC2 test2 devel freeze reminder In-Reply-To: <200402201601.28185.czar@czarc.net> References: <200402201601.28185.czar@czarc.net> Message-ID: <200402202137.34363.jwboyer@charter.net> On Friday 20 February 2004 03:01 pm, Gene C. wrote: > Yes, I found a mirror that was in sync and did have bandwidth but that was > a very manual, trial-and-error process. are you using yum? if you list multiple baseurls for the [development] channel in your /etc/yum.conf file it will do the searching for you. i only have 4 listed and yum can usually find one out of those that has enough bandwidth to get me all i need. i think up2date has the ability to use mirrors also, but i am not sure how. hope that helps. josh From salimma at fastmail.fm Sat Feb 21 03:45:21 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Sat, 21 Feb 2004 10:45:21 +0700 Subject: FC2 test2 devel freeze reminder In-Reply-To: <200402202137.34363.jwboyer@charter.net> References: <200402201601.28185.czar@czarc.net> <200402202137.34363.jwboyer@charter.net> Message-ID: <1077335121.4444.6.camel@bushido.mshome.net> On Fri, 2004-02-20 at 21:37 -0600, Josh Boyer wrote: > i think up2date has the ability to use mirrors also, but i am not sure how. > Last time I tried up2date it seems to round-robin the mirrors listed on Red Hat's site. - 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 salimma at fastmail.fm Sat Feb 21 03:46:40 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Sat, 21 Feb 2004 10:46:40 +0700 Subject: FC2 test2 devel freeze reminder In-Reply-To: References: Message-ID: <1077335200.4444.9.camel@bushido.mshome.net> On Fri, 2004-02-20 at 15:38 -0500, Elliot Lee wrote: > February 27. > > It's coming. > > File bug reports. > > Soon! > Yikes. I still can't get my Firewire/USB external HDD kit to work on *any* 2.6 kernels. If I can't track it down this weekend I guess I'll file a preliminary bug report. - 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 llim at redhat.com Sat Feb 21 03:50:31 2004 From: llim at redhat.com (Lawrence Lim) Date: Sat, 21 Feb 2004 13:50:31 +1000 (EST) Subject: Testers Required for Next Generation Input Method Message-ID: The Fedora Project will be adopting a revolutionary new Input Method system in the upcoming release of the Fedora Core 2. We would like to extend an invitation at this time to East Asian users in particular to test this preliminary release and provide us with feedback so we can improve the software and ensure that the Input Methods will be easier, more efficient and pleasant to use. Intranet/Internet Input Method Framework (IIIMF) is the next generation Input Method Framework set to replace the legacy X Window System Input Method (XIM) used by existing Input Methods such as chinput, xcin, kinput2, ami and many others. As the technology is still at its infancy, wider testing effort by community is needed to expediate the maturity of the technology. IIIMF server loads Language Engines (LE) dynamically at runtime as requested by clients. In this first round of testing, four LEs are available: + iiimf-le-inpinyin for Simplified Chinese (zh_CN.UTF-8) + iiimf-le-xcin for Traditional Chinese (zh_TW.UTF-8) + iiimf-le-canna for Japanese (ja_JP.UTF-8) + iiimf-le-hangul for Korean (ko_KR.UTF-8) If you wish to participate in this first round of testing, a Testing Guide is now available at . It will give you the necessary information in setting up the IIIMF and using the LE specific to your locale. Input Method Testing Discussion Mailing List: fedora-i18n-list at redhat.com Subscribe at: https://www.redhat.com/mailman/listinfo/fedora-i18n-list IRC: Channel #fedora-i18n on irc.freenode.net -- Best Regards, Fedora I18N Team From salimma at fastmail.fm Sat Feb 21 10:36:59 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Sat, 21 Feb 2004 17:36:59 +0700 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: <200402202323.24851.ghenry@suretecsystems.com> References: <200402202323.24851.ghenry@suretecsystems.com> Message-ID: <1077359819.11262.9.camel@bushido.mshome.net> On Fri, 2004-02-20 at 23:23 +0000, Gavin Henry wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dag Wieers if you have a second, could you look these over? Or anyone else :-) > Sure :) A couple of notes: - .desktop file should go to %{_datadir}/applications as per freedesktop.org spec; %{_datadir}/gnome/apps is GNOME1-ish; directory does not even exist on a clean Fedora system Since this is fedora-devel I think you could safely assume there will be few users running < RH9 :) - Fedora.us buildroot is %{_tmppath}/%{name}-%{version}-%{release}-root- %(%{__id_u} -n) This allows multiple users to recompile the same package without writing over each other's builds HTH :) - 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 f.simon at email.it Sat Feb 21 10:52:10 2004 From: f.simon at email.it (Simon) Date: Sat, 21 Feb 2004 11:52:10 +0100 Subject: sound on ASUS K8V (was: 3Com 3c940 ethernet card) References: <000d01c3f623$f41dfc80$0100000a@itaca> <200402191823.03026.thunderbirds@pandora.be> <001001c3f70f$6ae70140$0700000a@ulisse> <200402191912.44176.thunderbirds@pandora.be> Message-ID: <000901c3f868$cc695c10$0c00000a@itaca> > alias sound-slot-0 snd-via82xx > install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && > > This is what Fedora detected by default (execept for the sk98lin driver). > > Am I missing in this conf file? No, it is ok, mine is the same. I tell you again... for me the problem was the mixer. You have to install and use gnome-alsamixer, I dont remember if fedora provide it, anyway you can download it from freshrpms: http://yarrow.freshrpms.net/rpm.html?id=89 Use it to manage the mixer... you'll find that "Master" is useless and you have to adjust volume using "Headphones", "Wave" and "Sorround" if I'm not wrong. Anyway remove "mute" from all channels and turn the volume up to see which are the working channels. -- Simon. From ghenry at suretecsystems.com Sat Feb 21 11:15:40 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 21 Feb 2004 11:15:40 +0000 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: <1077359819.11262.9.camel@bushido.mshome.net> References: <200402202323.24851.ghenry@suretecsystems.com> <1077359819.11262.9.camel@bushido.mshome.net> Message-ID: <200402211115.49117.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 21 February 2004 10:36, Michel Alexandre Salim wrote: > On Fri, 2004-02-20 at 23:23 +0000, Gavin Henry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Dag Wieers if you have a second, could you look these over? Or anyone > > else :-) > > Sure :) > > A couple of notes: > - .desktop file should go to %{_datadir}/applications as per > freedesktop.org spec; %{_datadir}/gnome/apps is GNOME1-ish; directory > does not even exist on a clean Fedora system > > Since this is fedora-devel I think you could safely assume there will be > few users running < RH9 :) > > - Fedora.us buildroot is %{_tmppath}/%{name}-%{version}-%{release}-root- > %(%{__id_u} -n) > > This allows multiple users to recompile the same package without writing > over each other's builds Cheers. Another update I think :-) > > HTH :) > > - Michel - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFANz3ieWseh9tzvqgRAuhjAJwJgycA7VJfNWafWFeTP9jftD6O+ACeJFDM egQVqR9fZph2SrSg2121fEM= =7v/z -----END PGP SIGNATURE----- From llch at redhat.com Sat Feb 21 12:06:14 2004 From: llch at redhat.com (Leon Ho) Date: Sat, 21 Feb 2004 22:06:14 +1000 (EST) Subject: Testers Required for Next Generation Input Method In-Reply-To: Message-ID: URLs are: Full invitation letter: http://apac.redhat.com/iiimftest/ Testing guide: http://apac.redhat.com/iiimftest/testing-guide/ IIIMF testing packages: http://apac.redhat.com/iiimftest/files IIIMF open source project site and other projects on OpenI18N: http://www.openi18n.org/ http://www.openi18n.org/modules.php?op=modload&name=Sections&file=index&req=vi$ Regards, Leon On Sat, 21 Feb 2004, Lawrence Lim wrote: > The Fedora Project will be adopting a revolutionary new Input Method > system in the upcoming release of the Fedora Core 2. We would like to > extend an invitation at this time to East Asian users in particular to > test this preliminary release and provide us with feedback so we can > improve the software and ensure that the Input Methods will be easier, > more efficient and pleasant to use. > > Intranet/Internet Input Method Framework (IIIMF) is the next generation > Input Method Framework set to replace the legacy X Window System Input > Method (XIM) used by existing Input Methods such as chinput, xcin, > kinput2, ami and many others. As the technology is still at its infancy, > wider testing effort by community is needed to expediate the maturity of > the technology. > > IIIMF server loads Language Engines (LE) dynamically at runtime as > requested by clients. In this first round of testing, four LEs are > available: > + iiimf-le-inpinyin for Simplified Chinese (zh_CN.UTF-8) > + iiimf-le-xcin for Traditional Chinese (zh_TW.UTF-8) > + iiimf-le-canna for Japanese (ja_JP.UTF-8) > + iiimf-le-hangul for Korean (ko_KR.UTF-8) > > If you wish to participate in this first round of testing, a Testing Guide > is now available at . It will give you the necessary information in > setting up the IIIMF and using the LE specific to your locale. > > Input Method Testing Discussion > Mailing List: fedora-i18n-list at redhat.com > Subscribe at: > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > IRC: Channel #fedora-i18n on irc.freenode.net > > > -- > Best Regards, > Fedora I18N Team > > > -- Leon Ho Team Leader of Engineering Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer From salimma at fastmail.fm Sat Feb 21 14:27:19 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Sat, 21 Feb 2004 21:27:19 +0700 Subject: Testers Required for Next Generation Input Method In-Reply-To: References: Message-ID: <1077373638.13557.2.camel@bushido.mshome.net> On Sat, 2004-02-21 at 22:06 +1000, Leon Ho wrote: > URLs are: > > Full invitation letter: > http://apac.redhat.com/iiimftest/ > Pity I can't write in any East Asian multibyte languages, but I'll try and get some people I know to go over it. Where is Red Hat APAC based, incidentally? Singapore, Malaysia, RoC? - 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 salimma at fastmail.fm Sat Feb 21 14:31:04 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Sat, 21 Feb 2004 21:31:04 +0700 Subject: Testers Required for Next Generation Input Method In-Reply-To: References: Message-ID: <1077373863.13557.5.camel@bushido.mshome.net> On Sat, 2004-02-21 at 22:06 +1000, Leon Ho wrote: > IIIMF testing packages: > http://apac.redhat.com/iiimftest/files Could you guys run yum-arch on the repository? Saves the hassle of downloading individual RPMs. Thanks, 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 mrchoke at opentle.org Sat Feb 21 15:18:50 2004 From: mrchoke at opentle.org (Supphachoke Suntiwichaya) Date: Sat, 21 Feb 2004 22:18:50 +0700 Subject: Mouse related issue In-Reply-To: <1074210673.2686.13.camel@zontar.clueserver.org> References: <1074159524.3482.10.camel@zontar.clueserver.org> <20040115174717.GH1925@devserv.devel.redhat.com> <1074207898.6484.17.camel@zontar.clueserver.org> <1074208440.4013.23.camel@tyler-rh.tlarson.com> <1074210673.2686.13.camel@zontar.clueserver.org> Message-ID: <403776DA.5090101@opentle.org> Alan wrote: >On Thu, 2004-01-15 at 15:14, Tyler larson wrote: > > >>On Thu, 2004-01-15 at 16:04, Alan wrote: >> >> >>>On Thu, 2004-01-15 at 09:47, Alan Cox wrote: >>> >>> >>>>On Thu, Jan 15, 2004 at 01:38:45AM -0800, Alan wrote: >>>> >>>> >>>>>In Redhat 9 I would just bring up the redhat mouse configure app and it >>>>>would reset the mouse. That does not work in Fedora any more. >>>>> >>>>> >>>>Switch to text mode and back probably does the right thing >>>> >>>> >>>There does not seem to be a keybinding for that anymore. (Used to be >>>something like Alt-F12.) I guess I get to hack one in. >>> >>> >>Ctrl-Alt-F1 (through F6), and yeah, it's still there. >> >> > >Kewl. Thanks! > >One slight problem here... It does not fix the mouse. > >Here is the situation: > >I switch over to another system on my KVM switch and the mouse cursor >becomes very jumpy and does all sorts of nasty random things. > >I am using Fedora 1 with the 2.6.1-1.126 smp kernel. > >Switching to a text console does not reset the mouse. > >Restarting gpm does not reset the mouse. > >The mouse has the same problem in the text console(s) as well. > >In the syslog, I get the messages: > >Jan 15 15:23:53 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. >Jan 15 15:24:19 zontar last message repeated 3 times >Jan 15 15:24:23 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. >Jan 15 15:24:52 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. >Jan 15 15:25:57 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. >Jan 15 15:25:59 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. >Jan 15 15:26:02 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. >Jan 15 15:27:05 zontar gpm: gpm shutdown succeeded >Jan 15 15:27:06 zontar gpm: gpm startup succeeded >Jan 15 15:27:08 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. >Jan 15 15:27:16 zontar kernel: psmouse.c: Explorer Mouse at >isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. > >The only way to get the mouse to go back to "sane operation" is to >reboot the machine. > >Is this a problem in the 2.6.x kernels or am I missing something? > > > Hi,,, I using FC2 Test1 kernel 2.6.1-1.65 I got problem too... If AUX port is really absent please use the 'i8042.noaux' option. serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 atkbd.c: Unknown key pressed (raw set 0, code 0x0 on isa0060/serio0). atkbd.c: Use 'setkeycodes 00 ' to make it known. input: PS/2 Generic Mouse on isa0060/serio0 psmouse.c: Mouse at isa0060/serio0/input0 lost synchronization, throwing 2 bytes away. psmouse.c: Mouse at isa0060/serio0/input0 lost synchronization, throwing 1 bytes away. last message repeated 8 times This messages show only when I used SMP Kernel. I can't use keyboard ,when I press some key mouse cursor jumping. I used KVM too. but I can used UP Kernel... ?? MrChoke -- Name : Supphachoke Suntiwichaya Email : MrChoke at opentle.org From buildsys at redhat.com Sat Feb 21 17:55:56 2004 From: buildsys at redhat.com (Build System) Date: Sat, 21 Feb 2004 12:55:56 -0500 Subject: rawhide report: 20040221 changes Message-ID: <200402211755.i1LHtuk12259@porkchop.devel.redhat.com> Updated Packages: Canna-3.7p1-4 ------------- * Thu Feb 19 2004 Akira TAGOH 3.7p1-4 - Canna-3.7p1-notimeout.patch: applied to avoid cant-mount-the-dictionaries issue. (#114886) MySQL-python-0.9.2-3 -------------------- * Fri Feb 20 2004 Tom Lane - reinstate (and update) patch for /usr/lib64 compatibility - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt * Tue Nov 25 2003 Patrick Macdonald 0.9.2-1 - update to 0.9.2 - remove patches (no longer applicable) XFree86-4.3.0-59 ---------------- * Thu Feb 19 2004 Mike A. Harris 4.3.0-59 - Added XFree86-4.3.0-xrandr-manpage-typo-fix.patch to fix manpage (#83702) - Added XFree86-4.3.0-radeon-9200-dvi-snow.patch to fix issue on Radeon 9200 when using DVI panel and encountering snow and other artifacts (#112073) - Updated XFree86-4.3.0-debug-logging-ioport-based-rate-setting.patch to have it patch both lnx_kbd.c and lnx_io.c because both files insanely contain identical cut and pasted copies of the exact same source code, so nothing shows up in the X server log when testing with previous patch as the calls never got invoked in lnx_kbd.c (#115769) * Wed Feb 18 2004 Mike A. Harris 4.3.0-58 - Added XFree86-4.3.0-debug-logging-ioport-based-rate-setting.patch to get some useful debugging information as to why the X server seems to be unable to use the KDKBDREP ioctl(), and is falling back to direct I/O port bashing, which causes problems in the kernel (#115769) - Removed /usr/X11R6/lib/X11/fonts/misc and /usr/X11R6/lib/X11/fonts/cyrillic from the default xfs font path, as /usr/X11R6/lib/X11/fonts/misc:unscaled is present by default, which is what we want, and the cyrillic one gets added automatically if cyrillic fonts get installed. - Updated libXrender to the version 0.8.4 maintenance release, which fixes a problem in 0.8.3 that caused antialiased fonts to be inadvertently disabled in KDE (#109351) - Updated libXft to version 2.1.3 from freedesktop.org xlibs, and enabled it for build_rawhide and build_psyche just for testing purposes for now. - Conditionalize the patches XFree86-4.3.0-fixes-for-freetype-2.1.7-v2.patch, and XFree86-4.3.0-redhat-xft-loadtarget.patch to only be applied when with_new_xft is 0, as it is not needed for Xft 2.1.3 - Added XFree86-4.3.0-SDK-add-missing-includes-for-synaptics.patch from Paul Nasrat, to fix the SDK so that 3rd party drivers such as "synaptics" can be built in external rpm packages (#99351,103498,114804) - Comment out host.def supported driver list for alpha architecture, and just build the default drivers, as we no longer have official Alpha products, so there is no reason to restrict driver support to hardware that works or is reasonably considered to work. Ship it all and see what breaks. - Disabled tdfx driver DRI support in Fedora Core development, as we have at least temporarily deprecated Glide3 due to it no longer compiling properly. Alan was working on fixing this, so we will probably re-enable tdfx DRI support once Glide3 is working again. - Removed XFree86-4.3.0-fixes-for-freetype-2.1.7-v2.patch and replaced it with XFree86-4.3.0-general-fixes-for-freetype-2.1.7.patch which excludes Xft2 fixups, and XFree86-4.3.0-xft-2.1.2-fixes-for-freetype-2.1.7.patch which includes only Xft2 fixups needed for xft-2.1.2, as 2.1.3 includes this fix already adjtimex-1.13-12 ---------------- * Thu Feb 19 2004 Than Ngo 1.13-12 - add fix for new glibc - add COPYRIGHT file * Fri Feb 13 2004 Elliot Lee - rebuilt alchemist-1.0.32-1 ------------------ * Thu Feb 19 2004 Tim Waugh 1.0.32-1 - Unnest a function (bug #116248). * Thu Jan 15 2004 Tim Waugh 1.0.31-1 - Fixed another accidental bitwise operation. * Thu Jan 08 2004 Tim Waugh 1.0.30-1 - Fix several accidental bitwise operations. - Unnest a function (bug #110691). anaconda-9.91-0.20040219213330 ------------------------------ * Thu Feb 19 2004 Anaconda team - built new version from CVS * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 apr-0.9.4-9 ----------- * Thu Feb 19 2004 Joe Orton 0.9.4-9 - undocument apr_dir_read() ordering constraint and fix tests * Sun Feb 15 2004 Joe Orton 0.9.4-8 - rebuilt without -Wall -Werror * Fri Feb 13 2004 Elliot Lee 0.9.4-7 - rebuilt binutils-2.14.90.0.8-7 ---------------------- * Fri Feb 20 2004 Jakub Jelinek 2.14.90.0.8-7 - fix -pie on ppc32 * Fri Feb 20 2004 Jakub Jelinek 2.14.90.0.8-6 - clear .plt sh_entsize on sparc32 - put whole .got into relro area with -z now -z relro cdrdao-1.1.8-2 -------------- * Fri Feb 20 2004 Harald Hoyer - 1.1.8-1 - fixed ambigous operator cast * Wed Feb 18 2004 Harald Hoyer - 1.1.8-1 - use scsilib from cdrecord-devel * Mon Feb 16 2004 Harald Hoyer - 1.1.8-1 - version 1.1.8 cdrtools-2.01-0.a25.4 --------------------- * Wed Feb 18 2004 Harald Hoyer - 8:2.01-0.a25.4 - added endianness patch from cdrdao coreutils-5.2.0-2 ----------------- * Fri Feb 20 2004 Dan Walsh 5.2.0-2 - fix chcon to ignore . and .. directories for recursing * Fri Feb 20 2004 Tim Waugh 5.2.0-1 - Patch ls so that failed stat() is handled gracefully (Ulrich Drepper). - 5.2.0. * Thu Feb 19 2004 Tim Waugh - More AFS patch tidying. desktop-file-utils-0.4-1 ------------------------ * Thu Feb 19 2004 Mark McLoughlin 0.4-1 - Update to 0.4 desktop-printing-0.1.10-24 -------------------------- * Fri Feb 20 2004 Tim Waugh 0.1.10-24 - Requires dbus-0.20. * Fri Feb 13 2004 Elliot Lee - rebuilt dev86-0.16.15-1 --------------- * Fri Feb 20 2004 Thomas Woerner 0.16.15-1 - new version 0.16.15 epiphany-1.0.7-3 ---------------- * Thu Feb 19 2004 Christopher Blizzard 1.0.7-3 - disable the nautilus view. doesn't seem to work anymore. * Fri Feb 13 2004 Elliot Lee - rebuilt foomatic-3.0.1-1 ---------------- * Thu Feb 19 2004 Tim Waugh 3.0.1-1 - Upgrade db to 20040219. - Upgrade hpijs to 1.5-20040219. - Upgrade engine to 3.0.1. - Upgrade filters to 3.0.1. gcc34-3.4.0-0.3.1 ----------------- * Fri Feb 13 2004 Elliot Lee - rebuilt gimp-2.0-1.pre3.4 ----------------- * Wed Feb 18 2004 Tim Waugh - Added epoch to gimp-perl obsoletes tag. * Fri Feb 13 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Nils Philippsen - fix typo in %_enable_print macro - install convenience symlinks (gimp, gimp-remote, gimptool) gimp-print-4.2.6-7 ------------------ * Fri Feb 20 2004 Nils Philippsen 4.2.6-7 - fix gimp_dialog_new() invocations and related stuff in gimp2 patch glibc-2.3.3-10 -------------- * Fri Feb 20 2004 Jakub Jelinek 2.3.3-10 - update from CVS * Fri Feb 20 2004 Jakub Jelinek 2.3.3-9 - update from CVS * Tue Feb 10 2004 Jakub Jelinek 2.3.3-8 - update from CVS gnome-panel-2.5.3.1-6 --------------------- * Thu Feb 19 2004 Jeremy Katz - 2.5.3.1-6 - and again for real this time hwdata-0.107-1 -------------- * Thu Feb 19 2004 Mike A. Harris 0.107-1 - Massive Viewsonic monitor update for MonitorsDB (#84882) * Fri Feb 13 2004 John Dennis 0.106-1 - fix typo, GP should have been HP * Thu Jan 29 2004 Bill Nottingham 0.105-1 - many monitor updates (#114260, #114216, #113993, #113932, #113782, - add some PCMCIA cards (#113006, #112505) im-sdk-11.4-15 -------------- * Fri Feb 20 2004 Yu Shao - updated im-sdk-20040203-build.patch, closed init start bug (#115285) * Fri Feb 20 2004 Jens Petersen - 1:11.4-14 - do not specify Canna version, instead make leif modules executable for find-requires (#113999) - avoid newpy libtool lib install with im-sdk-newpy-noinst-lt.patch - buildrequire openmotif-devel, iiimf-le-newpy requires openmotif - make subpackage require current EVR - improve subpackage groups and drop superfluous autoreqprov's - rename prefix to im_dir and use it throughout * Thu Feb 19 2004 Yu Shao - build errors, patches from Jens Petersen (#116224) kdebase-3.2.0-1.6 ----------------- * Thu Feb 19 2004 Than Ngo 6:3.2.0-1.6 - KDM, use standard directory /usr/share/xsessions - fix a bug in selection of session type in KDM * Tue Feb 17 2004 Than Ngo 6:3.2.0-1.5 - fix typo bug, _smp_mflags instead smp_mflags * Fri Feb 13 2004 Elliot Lee - rebuilt kdeedu-3.2.0-1.4 ---------------- * Thu Feb 19 2004 Than Ngo 3.2.0-1.4 - add missing ldconfig in post/postun, #116171 kernel-2.6.3-1.96 ----------------- * Fri Feb 20 2004 Dave Jones - Update to 2.6.3-bk2 - Fix up typo in amd64 MSR defines (Will Cohen) kernel-utils-2.4-9.1.118 ------------------------ * Fri Feb 20 2004 Arjan van de Ven - switch to cpudyn * Mon Feb 16 2004 Arjan van de Ven - update irqbalanced to new (2.6 compatible) version kernel-utils-2.4-9.1.119 ------------------------ mozplugger-1.5.0-3 ------------------ * Wed Feb 18 2004 Than Ngo 1.5.0-3 - drop mozplugger-1.1.3-redhat.patch, it's included in new upstream - add patch file to fix swallow issue, thanks to Louis Bavoil net-tools-1.60-22 ----------------- * Thu Feb 19 2004 Phil Knirsch - Added netplug-1.2.1 to net-tools (FR #103419). nss_ldap-207-6 -------------- * Tue Nov 25 2003 Nalin Dahyabhai 207-6 - rebuild * Thu Nov 20 2003 Nalin Dahyabhai 207-5 - fix objectclass and attribute mapping, which failed due to uninitialized fields in mapping index structures, fixed upstream in 210 (#110547) * Mon Nov 10 2003 Nalin Dahyabhai 207-4 - link with the proper libsasl (1 or 2) for the version of OpenLDAP we are linking with (#106801) openCryptoki-2.1.3-7 -------------------- * Thu Feb 19 2004 Phil Knirsch 2.1.3-7 - rebuilt * Wed Feb 18 2004 Phil Knirsch 2.1.3-6 - Fixed small bug in files section. * Fri Feb 13 2004 Elliot Lee - rebuilt openh323-1.13.2-0.pre1.0 ------------------------ * Fri Feb 20 2004 Alexander Larsson 1.13.2-0.pre1.0 - update to 1.13.2pre1 * Fri Feb 13 2004 Elliot Lee - rebuilt openmotif-2.2.2-16.3 -------------------- * Thu Feb 19 2004 Thomas Woerner 2.2.2-16.3 - rebuilt * Thu Dec 18 2003 Thomas Woerner - added missing BuildRequires for XFree86-devel * Thu Nov 27 2003 Thomas Woerner 2.2.2-16.2 - removed rpath oprofile-0.8-0.20040121.2 ------------------------- * Thu Feb 19 2004 Will Cohen - Use automake 1.6. pnm2ppa-1.04-10 --------------- * Thu Feb 19 2004 Tim Waugh - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt policy-1.4.17-8 --------------- * Fri Feb 20 2004 Jeremy Katz - 1.4.17-8 - rpm_script_t -> ldconfig_t so that ld.so.conf has right context * Fri Feb 20 2004 Dan Walsh 1.4.17-7 - A couple of more missing policies * Fri Feb 20 2004 Dan Walsh 1.4.17-6 - Add /lib64 support continue working on kde and yp, nis, nfs support policycoreutils-1.4-9 --------------------- * Thu Feb 19 2004 Dan Walsh 1.4-9 - Add sort patch pwlib-1.6.3-0.pre1.0 -------------------- * Fri Feb 20 2004 Alexander Larsson 1.6.3-0.pre1.0 - update to 1.6.3pre1 * Tue Feb 17 2004 Alexander Larsson 1.5.0-4 - add ranges security fix pyxf86config-0.3.15-1 --------------------- * Thu Feb 19 2004 Brent Fox 0.3.15-1 - remove the setupMice() function createTemplate() - because the 2.6 kernel puts both PS/2 and USB mice on the same device * Mon Feb 09 2004 Alexander Larsson 0.3.14-1 - fix range array bug * Thu Nov 06 2003 Jeremy Katz 0.3.13-2 - rebuild for python 2.3 - don't build on ppc64 either since X is missing bits there as well rhdb-utils-3.0-2 ---------------- * Fri Feb 20 2004 Tom Lane - Remove beta label from pg_filedump. * Fri Feb 20 2004 Tom Lane - Update to version 3.0. - Increment Buildrequires to >= PostgreSQL 7.4 - Rebuild for Fedora Core 2. * Fri Feb 13 2004 Elliot Lee - rebuilt rhpl-0.127-2 ------------ * Fri Feb 20 2004 Brent Fox 0.127-2 - correct a typo * Fri Feb 20 2004 Brent Fox 0.127-1 - changes to mouse handling in xhwstate.py rpm-4.3-0.13 ------------ * Fri Feb 20 2004 Jeff Johnson 4.3-0.13 - fix: only first "mkdir -p" directory had context set. rpmdb-fedora-1.90-0.20040221 ---------------------------- s390utils-1.2.4-4 ----------------- * Thu Feb 19 2004 Phil Knirsch 2:1.2.4-4 - Fixed rebuilt on fc2. * Thu Feb 19 2004 Phil Knirsch 2:1.2.4-3 - Fixed automenu patch, was allocating 1 line to little. * Mon Feb 16 2004 Phil Knirsch 2:1.2.4-2 - rebuilt sendmail-8.12.11-3.2 -------------------- * Thu Feb 19 2004 Thomas Woerner 8.2.11-3.2 - removed buildreq for gdbm-devel * Thu Feb 19 2004 Thomas Woerner 8.2.11-3 - RH3.0E version: sasl1, no pie, old_setup (provide /etc/aliases) - new switches for pie and old_setup * Thu Feb 05 2004 Thomas Woerner 8.2.11-2.1 - new Sendmail.conf for sasl1 (#114726) sip-3.10-5 ---------- * Thu Feb 19 2004 Than Ngo 3.10-5 - fix lib64 issue * Fri Feb 13 2004 Elliot Lee - rebuilt squid-2.5.STABLE4-3 ------------------- * Fri Feb 20 2004 Jay Fenlason 7:2.5.STABLE4-3 - Clean up the spec file to work on 64-bit platforms (use /usr/lib64 instead of /usr/lib, etc) - Make the release number in the changelog section agree with reality. - use -fPIE rather than -fpie. s390 fails with just -fpie * Fri Feb 13 2004 Elliot Lee - rebuilt * Thu Feb 05 2004 Jay Fenlason - Incorporate many upstream patches - Include many spec file changes from D.Johnson system-config-display-1.0.7-1 ----------------------------- * Thu Feb 19 2004 Brent Fox 1.0.7-1 - don't import rhpl.mouse in xconf.py tsclient-0.132-2 ---------------- * Thu Feb 19 2004 Mark McLoughlin 0.132-2 - Add to the menus - bug #99570 * Wed Feb 18 2004 Mark McLoughlin 0.132-1 - Update to 0.132 - Add rdesktop dependancy - see bug #114769 * Fri Feb 13 2004 Elliot Lee - rebuilt xerces-j-2.2.1-14 ----------------- * Thu Feb 19 2004 Gary Benson 2.2.1-14 - Delete links correctly in preun scriptlet. * Fri Feb 13 2004 Elliot Lee 2.2.1-13 - Rebuilt. * Thu Feb 12 2004 Gary Benson 2.2.1-12 - Rebuild for Fedora. xpdf-3.00-3 ----------- * Fri Feb 20 2004 Than Ngo 3.00-3 - better fix for building with freetype 2.1.7 * Tue Feb 17 2004 Than Ngo 3.00-2 - t1lib-5.0.1 * Tue Jan 27 2004 Than Ngo 3.00-1 - 3.00 release - add patch file to built with new freetype-2.1.7 From leonard at den.ottolander.nl Sat Feb 21 18:04:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 21 Feb 2004 19:04:36 +0100 Subject: Closing bugs UPSTREAM Message-ID: <1077386675.4746.15.camel@athlon.localdomain> Hello, I would like to know what the policy about closing bugs UPSTREAM is. I feel resolving bugs as UPSTREAM might not be the correct approach if the bug will be fixed in an update. Also there is the danger of it being abused as an easy way out. More appropriate would be to close a bug as UPSTREAM if it can not be addressed locally. Bugs for which upstream fixes are applied are more appropriately closed CURRENTRELEASE as soon as the update is made available. An example of this is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114498 . This bug will be fixed locally with the next update of gnome-panel. Thus I feel it should be closed CURRENTRELEASE at the release of the update, and not UPSTREAM. A good example of closing UPSTREAM might be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112469 as this issue has *not* yet been solved upstream, and thus can not be addressed locally (I changed my mind on that one ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From markmc at redhat.com Sat Feb 21 18:42:54 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sat, 21 Feb 2004 18:42:54 +0000 Subject: Closing bugs UPSTREAM In-Reply-To: <1077386675.4746.15.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> Message-ID: <1077388973.5259.13.camel@laptop> Hi, On Sat, 2004-02-21 at 18:04, Leonard den Ottolander wrote: > Hello, > > I would like to know what the policy about closing bugs UPSTREAM is. I > feel resolving bugs as UPSTREAM might not be the correct approach if the > bug will be fixed in an update. Also there is the danger of it being > abused as an easy way out. More appropriate would be to close a bug as > UPSTREAM if it can not be addressed locally. Bugs for which upstream > fixes are applied are more appropriately closed CURRENTRELEASE as soon > as the update is made available. My take on it is that the only bugs that *shouldn't* be closed UPSTREAM are Fedora specific bugs and/or highly visible/important bugs. If you identify a bug as existing upstream and you don't think the bug is important enough to address with with an extra patch in Fedora, then it should be tracked upstream. We want to work upstream as much as possible. > An example of this is > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114498 . This bug > will be fixed locally with the next update of gnome-panel. Thus I feel > it should be closed CURRENTRELEASE at the release of the update, and not > UPSTREAM. I wouldn't have closed this, but the end result is the same. Its fixed upstream and the fix will be in the next update. Good Luck, Mark. From leonard at den.ottolander.nl Sat Feb 21 19:18:00 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 21 Feb 2004 20:18:00 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: <1077388973.5259.13.camel@laptop> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> Message-ID: <1077391079.4921.8.camel@athlon.localdomain> Hello Mark, > We want to work upstream as much as possible. With this I firmly agree. But that does not mean that bugs that are fixed locally (ie by applying upstream patches or update releases) should be closed as UPSTREAM, because in relation to the distribution they are fixed CURRENTRELEASE. Again, imo closing UPSTREAM should be restricted to issues that are not yet solved (upstream), thus cannot be solved CURRENTRELEASE (or whatever), and have to be tracked upstream. Solved issues that are back ported (or fixed by an update) do not fall into this category. I would love to hear the opinions of other (Red Hat) developers on what they think bug resolution UPSTREAM should be used for. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leon at geon.donetsk.ua Sat Feb 21 20:04:46 2004 From: leon at geon.donetsk.ua (Leonid Kanter) Date: Sat, 21 Feb 2004 22:04:46 +0200 Subject: Problems with nfs Message-ID: <1077393885.1905.5.camel@localhost.localdomain> I'm unable to mount my rh7.3-based nfs server from fc2 box. There are two lines in messages on nfs server: rpc.mountd: authenticated mount request from xxx.xxx.com.ua:922 for /md1 (/md1) rpc.mountd: getfh failed: Operation not permitted If I try to mount this resource from any box with kernel 2.4 - it's ok. How can I mount it from 2.6 box? From redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 00:53:46 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 00:53:46 +0000 Subject: RFC: Tripwire name change Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As the package maintainer for Tripwire, I have stumbled onto a (seemingly) insoluble problem, which can only be addressed by changing the package name of Tripwire from "tripwire" to "Tripwire". Rather than repeat the whole story verbatim, I simply refer you to the original RFC on bugzilla: http://bugzilla.fedora.us/show_bug.cgi?id=1308 Comments welcome. Regards, Keith G. Robertson-Turner tripwire-devel[AT]genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAN/0v2XoLj+pGfn8RAsQLAJsEnY92r7wfScceJ4CUE4rr+3gITwCeJLRE 4Jj+MTgLDIJcr5D4yN7IU7U= =vVa4 -----END PGP SIGNATURE----- From dag at wieers.com Sun Feb 22 01:13:48 2004 From: dag at wieers.com (Dag Wieers) Date: Sun, 22 Feb 2004 02:13:48 +0100 (CET) Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: <200402202323.24851.ghenry@suretecsystems.com> References: <200402202323.24851.ghenry@suretecsystems.com> Message-ID: On Fri, 20 Feb 2004, Gavin Henry wrote: > Dag Wieers if you have a second, could you look these over? Or anyone else :-) > > http://www.suretecsystems.com/putty/putty.spec Obviously what I would do is already in my SPEC file. Let me tell you why I do some things differently. First of all you seem to want to format everything the way you do. And it looks pretty nice, but I don't think it is very useful. Aligning ':' is a nobel thing but apart from being very time consuming it doesn't gain you anything. And I even think it is more difficult to read. (Does vi even color-highlight this correctly ??) Formatting however is mostly a personal preference anyway. Then putting a line between sections is something that fedora.us thought was a very good idea (no arguing about it back then!) and after a few months abandoned unanimously... Adding a BuildRequirement for desktop-file-utils makes sense if you're limiting yourself to distributions that have it. RHEL2.1 doesn't and is supported until 2006 IIRC. Perl for me belongs to the standard build environment and therefor doesn't need mentioning. You seem to 'quiet' the %setup output, which is something I _want_ to have in my buildlogs. If people are building my source-package I want them to be able to even compare the content of a tarball. It also helps to identify extra documentation or other files after inspection a buildlog when you go over your buildlog one last time. (part of the methodology, in the end this saves a lot of time as you don't have to re-release a package because you omitted something by mistake) You've put my perl one-liner on one-line ;)) But you're doing 3 substitutions in one go and it becomes less obvious what you're doing if you make it unreadable this way. eg. %{__perl} -pi -e ' s,-O2,$RPM_OPT_FLAGS,g;s,/usr/local,%{_prefix},g;s,^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$, ,' unix/Makefile.gtk vs. %{__perl} -pi.orig -e ' s|-O2|%{optflags}|g; s|/usr/local|%{_prefix}|g; s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; ' unix/Makefile.gtk Simplicity comes first, readability second. Putting a perl one-liner on a single line you're not making this more simple, but sure less readable. (Remember that when it gets fixed upstream you should verify that it can be removed, if it takes you 1 minute to understand what it did...) Some of the stuff was already mentioned. You're not using %{_datadir}/applications, you're adding yet another vendor. I would add the desktop-file inline so that it is one less extra source which greatly enhances your ability to have a clear overview of everything. In your case to evaluate the package you need to look at at least another file. I also noticed you're repeating the package-name in your description, eg. Summary: PuTTY - A Free Telnet/SSH Client, plus utilities There's no added value by doing so. What's even more people don't know exactly what to expect. If you have alternative software packaged, the summary should indicate what the difference is. Look at: openssh - The OpenSSH implementation of SSH protocol versions 1 and 2. telnet - The client program for the telnet remote login protocol. putty - GUI SSH, Telnet and Rlogin client. rsh - Clients for remote access (rsh, rlogin, rcp). At least you can tell from the summary putty is a GUI program, which is essential information for someone who needs to choose. I also try to avoid using GNOME/GTK/KDE directly as it shouldn't matter to the end-user. I also end a summary with a dot, which is often done by Red Hat too. Once again it may be a personal preference. Also you're using $RPM_BUILD_ROOT instead of %{buildroot} and although there's no real difference, you're mostly using macros everywhere else. This has been discussed at fedora.us also and I'm not sure if they have a valid reason to use a shell variable instead of the macro. (I know jbj made a statement about it and I don't think it adds to the equation) To me (personally) the macro fits better and makes it easier for the eyes. (FOR THE SAME PEOPLE THINK THAT I'M NOW SHOUTING AND IT HURTS THE EYES ;-) Well, those are my suggestions and some go directly against fedora.us guidelines. So be it. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Sun Feb 22 01:23:27 2004 From: dag at wieers.com (Dag Wieers) Date: Sun, 22 Feb 2004 02:23:27 +0100 (CET) Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: References: <200402202323.24851.ghenry@suretecsystems.com> Message-ID: On Sun, 22 Feb 2004, Dag Wieers wrote: > You've put my perl one-liner on one-line ;)) But you're doing 3 > substitutions in one go and it becomes less obvious what you're doing if > you make it unreadable this way. > > eg. > %{__perl} -pi -e ' s,-O2,$RPM_OPT_FLAGS,g;s,/usr/local,%{_prefix},g;s,^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$, ,' unix/Makefile.gtk > > vs. > %{__perl} -pi.orig -e ' > s|-O2|%{optflags}|g; > s|/usr/local|%{_prefix}|g; > s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; > ' unix/Makefile.gtk > > Simplicity comes first, readability second. Putting a perl one-liner on a > single line you're not making this more simple, but sure less readable. > (Remember that when it gets fixed upstream you should verify that it can > be removed, if it takes you 1 minute to understand what it did...) I forgot to add that you removed my comment: ### FIXME: Disable missing pscp.1 and psftp.1. (Please fix upstream) Of course you understand the 3rd substitution when you're reading it now, but there's no guarantee that the next time you're upgrading this package you'd still remember. Especially because it doesn't say that in fact you're diasbling 2 lines with the substitution. Removing the comment will have a penalty the next time you want to upgrade it. The comments are there to help you (or anyone else) to remember things without having to go once again through the code to see what it is substituting. (The FIXME comments are special in my case as they're indicated on the website so that other people now why they're missing and it may get fixed upstream too.) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From notting at redhat.com Sun Feb 22 06:12:51 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 22 Feb 2004 01:12:51 -0500 Subject: RFC: Tripwire name change In-Reply-To: References: Message-ID: <20040222061251.GA7055@devserv.devel.redhat.com> Keith G. Robertson-Turner (redhat-forums at genesis-x.nildram.co.uk) said: > As the package maintainer for Tripwire, I have stumbled onto a > (seemingly) insoluble problem, which can only be addressed by changing > the package name of Tripwire from "tripwire" to "Tripwire". > > Rather than repeat the whole story verbatim, I simply refer you to the > original RFC on bugzilla: > > http://bugzilla.fedora.us/show_bug.cgi?id=1308 Specspo needs to die... the out-of-band nature of it is bad. Unfortunately, there's not anything better yet. Bill From salimma at fastmail.fm Sun Feb 22 07:54:35 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Sun, 22 Feb 2004 14:54:35 +0700 Subject: Closing bugs UPSTREAM In-Reply-To: <1077391079.4921.8.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> Message-ID: <1077436475.17222.3.camel@bushido.mshome.net> On Sat, 2004-02-21 at 20:18 +0100, Leonard den Ottolander wrote: > Hello Mark, > > > We want to work upstream as much as possible. > > With this I firmly agree. But that does not mean that bugs that are > fixed locally (ie by applying upstream patches or update releases) > should be closed as UPSTREAM, because in relation to the distribution > they are fixed CURRENTRELEASE. > [snip] But would not CURRENTRELEASE indicate that an update has been released by the distributor (Red Hat/Fedora) ? It's similar to RAWHIDE which indicate that the bug has been closed in the development tree. - 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 redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 09:09:56 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 09:09:56 +0000 Subject: RFC: Tripwire name change References: <20040222061251.GA7055@devserv.devel.redhat.com> Message-ID: On Sun, 22 Feb 2004 01:12:51 -0500, Bill Nottingham wrote: > Keith G. Robertson-Turner said: >> http://bugzilla.fedora.us/show_bug.cgi?id=1308 > > Specspo needs to die... the out-of-band nature of it is bad. > > Unfortunately, there's not anything better yet. As I stated on bugzilla, the whole specspo thing was new to me. In fact I was rather shocked to be confronted by that sort of behaviour, which is almost Virus-like. Being an English native speaker, I have the luxury of not really having to think about "human language" issues on computers, since nearly all software on all platforms has documentation and buttons/popups/menus etc in English, if no other language (although I have noticed the very occasional exception). I remember (being an ex-Amigan) that the Amiga Workbench "Locale" system was very neat and easy. In fact I'm running (the new updated) UAE here now (thank you Richard Drummond), and I'm reminded of how simple but effective it really is. One "assign" to "Locale:", which then contains Catalogs, Countries, Languages, Providers, Flags and Help (oh sorry another assign ... to "HELP:"). The developer/maintainer of each app was responsible for providing its translation catalog, and that was that. If it didn't come with translations, often you would find someone else had already done it, and uploaded the tiny archive containing the translation catalog to Aminet. (Side note and shameless plug: I've packaged UAE and it's in the QA queue on fedora.us). The idea of having one huge behemoth file (Windows Registry style) for locale translations, is abhorrent, and I must say, very un-Linux. At the very least, the catalog entries should have been hard locked to a specific version of each package, that way if the versions don't match, then the contents of the specspo catalog are ignored. That particular omission is what amazes me most ... it defies belief, but then I guess that's an RPM bug, not specspo which is, after all, only data files. Anyway, I'll wait a few days, then if there are no major issues, I'll go ahead and change the name of the Tripwire package (actually it's done already, I just haven't posted to bugzilla yet). - K From warren at togami.com Sun Feb 22 09:22:47 2004 From: warren at togami.com (Warren Togami) Date: Sat, 21 Feb 2004 23:22:47 -1000 (HST) Subject: RFC: Tripwire name change In-Reply-To: References: <20040222061251.GA7055@devserv.devel.redhat.com> Message-ID: <33458.66.91.85.198.1077441767.squirrel@togami.com> > On Sun, 22 Feb 2004 01:12:51 -0500, Bill Nottingham wrote: > >> Keith G. Robertson-Turner said: >>> http://bugzilla.fedora.us/show_bug.cgi?id=1308 >> >> Specspo needs to die... the out-of-band nature of it is bad. >> >> Unfortunately, there's not anything better yet. > > As I stated on bugzilla, the whole specspo thing was new to me. In fact I > was rather shocked to be confronted by that sort of behaviour, which is > almost Virus-like. > > Being an English native speaker, I have the luxury of not really having to > think about "human language" issues on computers, since nearly all > software on all platforms has documentation and buttons/popups/menus etc > in English, if no other language (although I have noticed the very > occasional exception). > > I remember (being an ex-Amigan) that the Amiga Workbench "Locale" system > was very neat and easy. In fact I'm running (the new updated) UAE here now > (thank you Richard Drummond), and I'm reminded of how simple but effective > it really is. One "assign" to "Locale:", which then contains Catalogs, > Countries, Languages, Providers, Flags and Help (oh sorry another assign > ... to "HELP:"). The developer/maintainer of each app was responsible for > providing its translation catalog, and that was that. If it didn't come > with translations, often you would find someone else had already done it, > and uploaded the tiny archive containing the translation catalog to > Aminet. (Side note and shameless plug: I've packaged UAE and it's in the > QA queue on fedora.us). > > The idea of having one huge behemoth file (Windows Registry style) for > locale translations, is abhorrent, and I must say, very un-Linux. At the > very least, the catalog entries should have been hard locked to a specific > version of each package, that way if the versions don't match, then the > contents of the specspo catalog are ignored. That particular omission is > what amazes me most ... it defies belief, but then I guess that's an RPM > bug, not specspo which is, after all, only data files. > > Anyway, I'll wait a few days, then if there are no major issues, I'll go > ahead and change the name of the Tripwire package (actually it's done > already, I just haven't posted to bugzilla yet). > It seems like an extremely ugly way to avoid the specspo problem. If this package needs a name change to avoid it, that would mean that this is an acceptable solution for other packages too. There MUST be a better way. Perhaps... BuildConflicts: specspo Conflicts: specspo ... Yeah I am half kidding... but you think of a better solution. Warren From redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 09:57:14 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 09:57:14 +0000 Subject: RFC: Tripwire name change References: <20040222061251.GA7055@devserv.devel.redhat.com> <33458.66.91.85.198.1077441767.squirrel@togami.com> Message-ID: On Sat, 21 Feb 2004 23:22:47 -1000, Warren Togami wrote: > Keith G. Robertson-Turner said: >> Anyway, I'll wait a few days, then if there are no major issues, I'll go >> ahead and change the name of the Tripwire package (actually it's done >> already, I just haven't posted to bugzilla yet). > It seems like an extremely ugly way to avoid the specspo problem. If this > package needs a name change to avoid it, that would mean that this is an > acceptable solution for other packages too. There MUST be a better way. > Perhaps... > > BuildConflicts: specspo > Conflicts: specspo > > ... Yeah I am half kidding... but you think of a better solution. Actually specspo is not a BuildConflicts ... it has no effect at build time. Post build, the querying of either the uninstalled RPM or the installed package, is hijacked by specspo (%SUMMARY and %DESCRIPTION only AFAICT). Seems a bit rough to deny everyone their locale catalogs of the RPM database, just for the sake of Tripwire. I mean, it doesn't bother me, but there's bound to be some non-English speakers that would miss it. As a temporary measure ... hmmm, maybe. I just feel awkward about nominating Tripwire as the "Angel of Death" for specspo ;-| It's a bit cheeky, isn't it? Maintainer changes package summary; another package causes problem as a result; solution ... kill the other package. No, I don't like it, but it might come to that. I wish we had a voting system. - K. From leon at geon.donetsk.ua Sun Feb 22 10:13:00 2004 From: leon at geon.donetsk.ua (Leonid Kanter) Date: Sun, 22 Feb 2004 12:13:00 +0200 Subject: Broken yum header? Message-ID: <403880AC.9010401@geon.donetsk.ua> It looks like VFlib2-2.25.6-20 header is broken on all mirrors, because my up2date is falling down on fetching this header with traceback IOError: Not a gzipped file From russell at coker.com.au Sun Feb 22 11:26:05 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Feb 2004 22:26:05 +1100 Subject: yum and postinst Message-ID: <200402222226.05214.russell@coker.com.au> When a package is installed and the scriptlet can't run, should the installation of that package be considered complete, or should I be able to run the scriptlet after fixing the problem? [root at fedora-se tmp]# yum install e2fsprogs Gathering header information file(s) from server(s) Server: SELinux repository Server: Fedora Core 1.90 - Development Tree Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: e2fsprogs 1.35-6.1.i386] Is this ok [y/N]: y Getting e2fsprogs-1.35-6.1.i386.rpm e2fsprogs-1.35-6.1.i386.r 100% |=========================| 731 kB 00:06 Running test transaction: Test transaction complete, Success! e2fsprogs 100 % done 1/2 error: %post(e2fsprogs-1.35-6.1) scriptlet failed, exit status 255 Updated: e2fsprogs 1.35-6.1.i386 Transaction(s) Complete [root at fedora-se tmp]# yum install e2fsprogs Gathering header information file(s) from server(s) Server: SELinux repository Server: Fedora Core 1.90 - Development Tree Finding updated packages Downloading needed headers e2fsprogs is installed and is the latest version. No actions to take -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From ms-nospam-0306 at arcor.de Sun Feb 22 11:40:29 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 22 Feb 2004 12:40:29 +0100 Subject: RFC: Tripwire name change In-Reply-To: References: Message-ID: <20040222124029.5b44eceb.ms-nospam-0306@arcor.de> On Sun, 22 Feb 2004 00:53:46 +0000, Keith G. Robertson-Turner wrote: > As the package maintainer for Tripwire, I have stumbled onto a > (seemingly) insoluble problem, which can only be addressed by changing > the package name of Tripwire from "tripwire" to "Tripwire". > > Rather than repeat the whole story verbatim, I simply refer you to the > original RFC on bugzilla: > > http://bugzilla.fedora.us/show_bug.cgi?id=1308 > > Comments welcome. Other packages are affected, too, where entries in specspo are out-of-date and point to files which don't exist anymore. I've reported one of them a long time ago. However, you cannot blame specspo alone. Part of the problem is that you've put documentation into tripwire's %description field. Better move quickstart documentation into a separate README file and keep the package description short and to the point. -- From markmc at redhat.com Sun Feb 22 11:44:12 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sun, 22 Feb 2004 11:44:12 +0000 Subject: Closing bugs UPSTREAM In-Reply-To: <1077391079.4921.8.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> Message-ID: <1077450252.6344.23.camel@laptop> Hi Leonard, On Sat, 2004-02-21 at 19:18, Leonard den Ottolander wrote: > > We want to work upstream as much as possible. > > With this I firmly agree. But that does not mean that bugs that are > fixed locally (ie by applying upstream patches or update releases) > should be closed as UPSTREAM, because in relation to the distribution > they are fixed CURRENTRELEASE. > > Again, imo closing UPSTREAM should be restricted to issues that are not > yet solved (upstream), thus cannot be solved CURRENTRELEASE (or > whatever), and have to be tracked upstream. Solved issues that are back > ported (or fixed by an update) do not fall into this category. As I said - I wouldn't have closed this particular bug as UPSTREAM either. But I think we have different interpretations of what UPSTREAM means. Effectively, closing UPSTREAM means "we don't think this bug is important/serious enough to warrant tracking specifically for Fedora"[1] - i.e. whenever it gets fixed upstream, and we pull that upstream version into Fedora, then and only then will the bug be fixed in Fedora ... and we don't need to know exactly at what point the fix is pulled into Fedora. So, in the case of this bug - I would have left it open and made sure it was either fixed in an FC1 update or Raw Hide. Why? Because its a fairly embarassing bug which is easy to fix. My decision to not close it UPSTREAM would have had nothing to do with whether or not it was already fixed upstream. The only thing I think you could hope to achieve by doing things the way you suggest is that when we release an update we would have a nice list of every bugzilla.redhat.com bug which was fixed in that update. But bear in mind - for us to achieve that, for every bug closed UPSTREAM, we would have to track the upstream bug, re-open the closed bug and re-close CURRENTRELEASE. That's a lot of work, and not worthwhile. Cheers, Mark. From warren at togami.com Sun Feb 22 11:45:29 2004 From: warren at togami.com (Warren Togami) Date: Sun, 22 Feb 2004 01:45:29 -1000 Subject: DRAFT - Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO Message-ID: <40389659.20209@togami.com> http://togami.com/~warren/guides/remoteraidcrazies/ Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO Have you ever wanted to convert a remote system where you have only SSH access from a single disk and identical blank disk, to Linux software RAID-1? Well I had to do it twice late December. After a few disasters I managed to figure out this procedure. It worked great on RH9 and FC1, but for some reason I don't understand it failed on RHEL3. Any suggestions for improving the procedure or the mdadm manual start on RHEL3 failed would be appreciated. Yeah this isn't really Fedora related... Warren From leonard at den.ottolander.nl Sun Feb 22 12:56:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 13:56:51 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: <1077436475.17222.3.camel@bushido.mshome.net> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> Message-ID: <1077454610.4749.9.camel@athlon.localdomain> Hi Michel, > But would not CURRENTRELEASE indicate that an update has been released > by the distributor (Red Hat/Fedora) ? It's similar to RAWHIDE which > indicate that the bug has been closed in the development tree. Yup. That's why I suggested to leave the bug open and close it as soon as a gnome-panel update comes out, as it was fixed upstream and thus will flow back into Fedora. But I understand from Mark that tracking bugs in such a way is too time consuming to be worthwhile, at least in his opinion. It seems we have a slightly different interpretation of what the tag UPSTREAM means, the difference being that I believe only bugs that are not yet solved upstream should be closed as UPSTREAM. Anyway, I am looking forward to the test update of gnome-panel :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 12:57:21 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 12:57:21 +0000 Subject: RFC: Tripwire name change References: <20040222124029.5b44eceb.ms-nospam-0306@arcor.de> Message-ID: On Sun, 22 Feb 2004 12:40:29 +0100, Michael Schwendt wrote: > On Sun, 22 Feb 2004 00:53:46 +0000, Keith G. Robertson-Turner wrote: >> http://bugzilla.fedora.us/show_bug.cgi?id=1308 >> >> Comments welcome. > > Other packages are affected, too, where entries in specspo are > out-of-date and point to files which don't exist anymore. I've reported > one of them a long time ago. Sylpheed, wasn't it? > However, you cannot blame specspo alone. Part of the problem is that > you've put documentation into tripwire's %description field. Better move > quickstart documentation into a separate README file and keep the > package description short and to the point. Actually I didn't put it there, it was there already, I inherited it from the Red Hat release (circa 2000). All I did was modify it to reflect the new path and name of the script it references - (and that was to address another old FHS bug - "non-conffile-in-etc"). File that as a bug if you like, and I'll deal with it. In fact, I'm in favour of that; documentation has no place in the package description. However, the above bug only serves to emphasise the fact that specspo is a (essentially upstream) problem. Currently, if I were to follow that advice and move the reference to twinstall.sh/tripwire-setup-keyfiles out of the description, nobody would see the change ... instead they'd see line 17720 of /usr/share/doc/specspo-9.0.92/dist.pot (translated in one of the "mo" files), which reads: "After installing this package, run /etc/tripwire/twinstall.sh to\n" The *real* irony is ... there *is* no translation for Tripwire anyway ... it's all in English in the "mo" files, so why is it in there at all? I'm loath to change the name, but I don't feel comfortable squeezing out other people's packages either, however in this case I might have to make an exception. I'm with Warren for making specspo a "Conflicts". - K. From markmc at redhat.com Sun Feb 22 13:11:53 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sun, 22 Feb 2004 13:11:53 +0000 Subject: Closing bugs UPSTREAM In-Reply-To: <1077454610.4749.9.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> Message-ID: <1077455512.6344.37.camel@laptop> Hi Leonard, On Sun, 2004-02-22 at 12:56, Leonard den Ottolander wrote: > It seems we have a slightly different interpretation of what the tag > UPSTREAM means, the difference being that I believe only bugs that are > not yet solved upstream should be closed as UPSTREAM. I'm trying to figure out what you think doing it this way would achieve ... I may be missing something here, you know :-) Cheers, Mark. From leonard at den.ottolander.nl Sun Feb 22 13:34:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 14:34:01 +0100 Subject: DRAFT - Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO In-Reply-To: <40389659.20209@togami.com> References: <40389659.20209@togami.com> Message-ID: <1077456840.4749.44.camel@athlon.localdomain> Hello Warren, > http://togami.com/~warren/guides/remoteraidcrazies/ > Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO Just browsed the document quickly, so just some brief remarks. The disks do not need to be identical, as long as the used partitions are about the same size things are fine. The copying of the partition table is a crude hack, although it will work if the disks are identical. The output of the fdisk l command seems somewhat redundant. Just mention fd is the value to be used for Linux auto raid, or leave it out all together as it is obvious from the rest of the example. Not so long ago I had to setup a system remotely myself. As it only contained a swap and a single partition I had to repartition it. I set this system up as a redundant system sharing most of the data partitions (/home, /var/log, /var/spool, /tmp, /var/tmp), but separate system partitions (/, /usr), so the system can be booted back to its old state if an update fails. Such a setup can also be useful if you try to setup a system as you did, as it makes it possible for someone to reboot the system for you to a known good state if you faq up. In your case the second installation does not need to be identical, just a minimal rescue installation. To avoid an unusable system when booting to the newly setup system if for some reason something goes wrong is to use the single boot option, make sure the system reboots on panic and set the new system up to reboot within a few minutes in /etc/rc.d/rc.local (the first two options you use as well, the latter is probably not as important in your case as it was in mine). If for some reason you can't login the system will be rebooted to the old state, otherwise you can cancel the shutdown. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mharris at redhat.com Sun Feb 22 13:38:26 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 08:38:26 -0500 (EST) Subject: Closing bugs UPSTREAM In-Reply-To: <1077436475.17222.3.camel@bushido.mshome.net> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> Message-ID: On Sun, 22 Feb 2004, Michel Alexandre Salim wrote: >> Hello Mark, >> >> > We want to work upstream as much as possible. >> >> With this I firmly agree. But that does not mean that bugs that are >> fixed locally (ie by applying upstream patches or update releases) >> should be closed as UPSTREAM, because in relation to the distribution >> they are fixed CURRENTRELEASE. >> >[snip] >But would not CURRENTRELEASE indicate that an update has been released >by the distributor (Red Hat/Fedora) ? It's similar to RAWHIDE which >indicate that the bug has been closed in the development tree. CURRENTRELEASE means you filed a bug report for an older version of the OS, which is fixed in the current version of the OS, or in an erratum update for the new OS, but it is not fixed in any erratum for the OS release that you filed it for, and there is no plan to do so. For example: Someone files a bug report against XFree86 for Red Hat Linux 8.0 tomorrow. I look at it and immediately know that this problem is not present in RHL 9 or FC1. Alternatively, maybe it is in RHL 9 or FC1 but has been fixed in an update to FC1. I close it as "CURRENTRELEASE". The rough translation being "this is fixed in the current version of our operating system, or by an update to the current version. We wont be fixing this problem as an update to the version of the OS that you are using. Please upgrade your OS." Something like that anyway. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Feb 22 13:52:23 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 08:52:23 -0500 (EST) Subject: Closing bugs UPSTREAM In-Reply-To: <1077391079.4921.8.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> Message-ID: On Sat, 21 Feb 2004, Leonard den Ottolander wrote: >I would love to hear the opinions of other (Red Hat) developers on what >they think bug resolution UPSTREAM should be used for. Here's how I use UPSTREAM. After looking at a bug, I may decide that it is something that needs to be fixed upstream first before we will look at it further. There are many reasons why we might decide that. Some include: - The problem is of a nature that may require more time to fix than can be justified by the engineering resources that might have to be spent investigating it, especially when comparing it to all other bug reports and other priorities. - The problem may be something that it isn't likely to affect many users, and may be considere a very low priority, so low that it may never find it's way onto the radar. However the same bug reported upstream might end up getting fixed in a day/week/month or whatever. - The problem might be an obscure problem which requires physical access to the specific hardware, or might require technical specifications or other materials which I do not have access to, but which one of the many developers upstream might be able to fix in a much shorter timescale. - Perhaps the bug already is reported upstream. If it is a known bug that affects multiple distributions, it is often better to track it in one place - upstream, than to do it in 10 different distribution specific bugzillas, etc. - The bug/problem is in an area of code for which we do not have any expertise, however there are one or more experts in that area upstream, of whom are known to usually handle bug reports in that area of code generally very quickly. No sense one of us wasting hours/days or longer trying to learn how something works that someone upstream who is already an expert in the area can fix in 10 minutes. xkb is an example of something I generally refer people to UPSTREAM (and then soon after apply the bug fixes from upstream in most cases) Once a person has filed their bug upstream, and pasted the URL in our bugzilla, and I've closed it UPSTREAM, I periodically scan all of my UPSTREAM bug reports to follow them once in a while. If the bug upstream has been fixed, I may apply the patch, or perhaps backport it if necessary. In some cases however, the changes are larger than I'm willing to apply to our sources, or carry with them too much risk of regression. In those cases I may leave the bug as is, or change it to DEFERRED for a future OS release. Also, if someone notifies me something is fixed upstream now, which is in our UPSTREAM state, I can set it to REOPENED and review the upstream resolution perhaps sooner than my next 'UPSTREAM' bug scan (depending on my schedule, etc.). That's a rough idea how I use it at least. Other developers may use it differently depending on the different ways different projects work, and also different developmental preference, etc. Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ms-nospam-0306 at arcor.de Sun Feb 22 14:05:03 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 22 Feb 2004 15:05:03 +0100 Subject: RFC: Tripwire name change In-Reply-To: References: <20040222124029.5b44eceb.ms-nospam-0306@arcor.de> Message-ID: <20040222150503.025c26ef.ms-nospam-0306@arcor.de> On Sun, 22 Feb 2004 12:57:21 +0000, Keith G. Robertson-Turner wrote: > However, the above bug only serves to emphasise the fact that specspo is > a (essentially upstream) problem. Currently, if I were to follow that > advice and move the reference to twinstall.sh/tripwire-setup-keyfiles out > of the description, nobody would see the change ... instead they'd see > line 17720 of /usr/share/doc/specspo-9.0.92/dist.pot (translated in one of > the "mo" files), which reads: > > "After installing this package, run /etc/tripwire/twinstall.sh to\n" > > The *real* irony is ... there *is* no translation for Tripwire anyway ... > it's all in English in the "mo" files, so why is it in there at all? > > I'm loath to change the name, but I don't feel comfortable squeezing out > other people's packages either, however in this case I might have to make > an exception. I'm with Warren for making specspo a "Conflicts". It does not conflict [*]. The tripwire package can co-exist with specspo just fine. It is a really minor annoyance that querying the package description returns something wrong if specspo is installed. Unless you receive bug reports about that frequently, don't change it. Don't expect package users to look for documentation in %description. And if they do, then that's the problem. [*] "Conflicts:" is for much more serious issues such as file based conflicts, run-time conflicts (e.g. alternative implementations of the same library or application), known or expected incompatibilities (e.g. "Requires: foo >= 1.0, Conflicts: foo >= 2.0"). -- From leonard at den.ottolander.nl Sun Feb 22 14:07:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 15:07:40 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: <1077455512.6344.37.camel@laptop> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> Message-ID: <1077458859.4749.55.camel@athlon.localdomain> Hi Marc, > I'm trying to figure out what you think doing it this way would achieve > ... I may be missing something here, you know :-) Closing bugs as UPSTREAM is ambiguous if you close both bugs that are fixed and not yet fixed upstream. That is why I think the tag UPSTREAM should be reserved for bugs that have not yet been fixed (upstream), and thus need tracking upstream. Bugs that are already fixed upstream and for which patches flow back into the distro can be tagged as CURRENTRELEASE (or NEXTRELEASE if the patch only gets applied in the next release (currently FC 2)). So what I want to achieve is to avoid this ambiguity. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sun Feb 22 14:12:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 15:12:29 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> Message-ID: <1077459149.4749.60.camel@athlon.localdomain> Hello Mike, > CURRENTRELEASE means you filed a bug report for an older version > of the OS, which is fixed in the current version of the OS, or in > an erratum update for the new OS, but it is not fixed in any > erratum for the OS release that you filed it for, and there is no > plan to do so. If the https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114498 had been filed against FC1 the way to resolve it would be ERRATA (as soon as the update is made available). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mharris at redhat.com Sun Feb 22 14:35:38 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 09:35:38 -0500 (EST) Subject: RFC: Tripwire name change In-Reply-To: References: <20040222061251.GA7055@devserv.devel.redhat.com> Message-ID: On Sun, 22 Feb 2004, Keith G. Robertson-Turner wrote: >locale translations, is abhorrent, and I must say, very un-Linux. At the >very least, the catalog entries should have been hard locked to a specific >version of each package, that way if the versions don't match, then the >contents of the specspo catalog are ignored. That particular omission is >what amazes me most ... it defies belief, but then I guess that's an RPM >bug, not specspo which is, after all, only data files. That would not work because then every single time a new rpm package is built, one would have to edit specspo to update all the version numbers. Since the description text is something that rarely if ever changes in most packages, having to manually update specspo every time would not be very convenient. It would be annoying to the point that developers would probably refrain from building packages as often, and instead wait much longer between updates to avoid the specspo update penalty. >Anyway, I'll wait a few days, then if there are no major issues, >I'll go ahead and change the name of the Tripwire package >(actually it's done already, I just haven't posted to bugzilla >yet). Since we do not ship tripwire anymore, and haven't since RHL9, if it isn't already removed from specspo, it would make a lot of sense for us to remove it IMHO. /me who hates mixed case package names, including XFree86 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Feb 22 14:37:42 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 09:37:42 -0500 (EST) Subject: RFC: Tripwire name change In-Reply-To: <33458.66.91.85.198.1077441767.squirrel@togami.com> References: <20040222061251.GA7055@devserv.devel.redhat.com> <33458.66.91.85.198.1077441767.squirrel@togami.com> Message-ID: On Sat, 21 Feb 2004, Warren Togami wrote: >> Anyway, I'll wait a few days, then if there are no major issues, I'll go >> ahead and change the name of the Tripwire package (actually it's done >> already, I just haven't posted to bugzilla yet). >> > >It seems like an extremely ugly way to avoid the specspo problem. If this >package needs a name change to avoid it, that would mean that this is an >acceptable solution for other packages too. There MUST be a better way. >Perhaps... > >BuildConflicts: specspo >Conflicts: specspo > >... Yeah I am half kidding... but you think of a better solution. Have the %post automatically strip the tripwire entries out of the specspo files. Not nice, but then it's not nice to have them in there in the first place if the package isn't in the distribution. IMHO... -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From wrrhdev at riede.org Sun Feb 22 14:41:06 2004 From: wrrhdev at riede.org (Willem Riede) Date: Sun, 22 Feb 2004 09:41:06 -0500 Subject: Closing bugs UPSTREAM In-Reply-To: <1077458859.4749.55.camel@athlon.localdomain> (from leonard@den.ottolander.nl on Sun, Feb 22, 2004 at 09:07:40 -0500) References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> Message-ID: <20040222144106.GI4957@serve.riede.org> On 2004.02.22 09:07, Leonard den Ottolander wrote: > Hi Marc, > > > I'm trying to figure out what you think doing it this way would achieve > > ... I may be missing something here, you know :-) > > Closing bugs as UPSTREAM is ambiguous if you close both bugs that are > fixed and not yet fixed upstream. That is why I think the tag UPSTREAM > should be reserved for bugs that have not yet been fixed (upstream), and > thus need tracking upstream. > > Bugs that are already fixed upstream and for which patches flow back > into the distro can be tagged as CURRENTRELEASE (or NEXTRELEASE if the > patch only gets applied in the next release (currently FC 2)). > > So what I want to achieve is to avoid this ambiguity. And what if it gets fixed the next day upstream? You expect every bug owner to follow that and requalify the local bug? A lot of work for very little value, I'd say. I think it is OK if UPSTREAM is used to mean "I won't do anything about this bug myself, it is reported to the upstream bug database, and if and when they fix it, it will eventually propagate into a next release". If the bug is serious enough to warrant that a specific test for it is done during QA of new releases, then when the fix is confirmed, change status to CURRENTRELEASE. Closing bugs means (local) work on it stops. Closing UPSTREAM means that you need to go look in that bug database to see what the real status is. What's the problem? Regards, Willem Riede. From mharris at redhat.com Sun Feb 22 14:42:33 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 09:42:33 -0500 (EST) Subject: Closing bugs UPSTREAM In-Reply-To: <1077458859.4749.55.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> Message-ID: On Sun, 22 Feb 2004, Leonard den Ottolander wrote: >Date: Sun, 22 Feb 2004 15:07:40 +0100 >From: Leonard den Ottolander >To: Fedora Devel List >Content-Type: text/plain >List-Id: Development discussions related to Fedora Core > >Subject: Re: Closing bugs UPSTREAM > >Hi Marc, > >> I'm trying to figure out what you think doing it this way would achieve >> ... I may be missing something here, you know :-) > >Closing bugs as UPSTREAM is ambiguous if you close both bugs that are >fixed and not yet fixed upstream. That is why I think the tag UPSTREAM >should be reserved for bugs that have not yet been fixed (upstream), and >thus need tracking upstream. > >Bugs that are already fixed upstream and for which patches flow back >into the distro can be tagged as CURRENTRELEASE (or NEXTRELEASE if the >patch only gets applied in the next release (currently FC 2)). The current release is Fedora Core 1, so closing a bug CURRENTRELEASE that is not fixed in Fedora Core 1, is incorrect. If a bug is flagged UPSTREAM, and is fixed upstream, then it is valid to reopen it IMHO. Then if the bug is too late in the development cycle to consider, or if the developer has no time to investigate the upstream fix right away, DEFERRED or NEXTRELEASE or some other status change is more appropriate. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Feb 22 14:47:03 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 09:47:03 -0500 (EST) Subject: Closing bugs UPSTREAM In-Reply-To: <1077459149.4749.60.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077459149.4749.60.camel@athlon.localdomain> Message-ID: On Sun, 22 Feb 2004, Leonard den Ottolander wrote: >> CURRENTRELEASE means you filed a bug report for an older version >> of the OS, which is fixed in the current version of the OS, or in >> an erratum update for the new OS, but it is not fixed in any >> erratum for the OS release that you filed it for, and there is no >> plan to do so. > >If the https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114498 had >been filed against FC1 the way to resolve it would be ERRATA (as soon as >the update is made available). Yes, if a bug is filed against FC1, and is fixed in an FC1 erratum (yes, I know how to properly use latin in singular form, unlike bugzilla), then it should be closed as "ERRATA" when the erratum is released. If the bug was filed against RHL9, and is fixed in FC1 erratum, but not in RHL 9 erratum, then IMHO, the correct closure is either: - CURRENTRELEASE (indicating it is fixed in FC1 erratum) or - ERRATA (indicating in a comment it is fixed only in Fedora Core 1 erratum, requiring an OS upgrade, and updating the system to latest packages) or - WONTFIX (indicating we will not fix this bug in this OS release, however it is fixed in the current OS release if you upgrade) I prefer the first one above, but either should be fine IMHO. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From leonard at den.ottolander.nl Sun Feb 22 15:10:30 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 16:10:30 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> Message-ID: <1077462630.4749.83.camel@athlon.localdomain> Hello Mike, > The current release is Fedora Core 1, so closing a bug > CURRENTRELEASE that is not fixed in Fedora Core 1, is incorrect. Yes. This is not what I was suggesting. > If a bug is flagged UPSTREAM, and is fixed upstream, then it is > valid to reopen it IMHO. The bug in question (#114498) is fixed upstream and will be fixed in the soon coming update of gnome-panel. Since it was filed against RawHide it can be closed CURRENTRELEASE (or ERRATA) as soon as the update is in the main tree. To rephrase one last time: Imo UPSTREAM is a tag that should only be applied to *open* issues, (a bit like DEFERRED,) which #114498 is not. #112469 is. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sun Feb 22 15:13:55 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 16:13:55 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: <20040222144106.GI4957@serve.riede.org> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> <20040222144106.GI4957@serve.riede.org> Message-ID: <1077462834.4749.89.camel@athlon.localdomain> Hallo Willem, > And what if it gets fixed the next day upstream? You expect every bug > owner to follow that and requalify the local bug? A lot of work for > very little value, I'd say. In this case the bugs are part of my triage effort for which you can find details at http://www.ottolander.nl/gnome-panel/ , which means they are being actively tracked. This particular issue (#114498) has already been solved upstream. Thus this bug could have remained open and be closed with an appropriate tag as soon as the gnome-panel update gets in the main tree. As Mike says, (at least in his eyes) bugs that are fixed upstream can be reopened and closed more appropriately. This of course can be done by people other than the maintainer. (As I did not file this particular bug report I can not reopen it, only make a request.) > I think it is OK if UPSTREAM is used to mean "I won't do anything about > this bug myself, it is reported to the upstream bug database, and if and > when they fix it, it will eventually propagate into a next release". Yes. But this one has already been fixed (check the bug report). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ms-nospam-0306 at arcor.de Sun Feb 22 16:25:50 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 22 Feb 2004 17:25:50 +0100 Subject: RFC: Tripwire name change In-Reply-To: References: <20040222061251.GA7055@devserv.devel.redhat.com> <33458.66.91.85.198.1077441767.squirrel@togami.com> Message-ID: <20040222172550.26426900.ms-nospam-0306@arcor.de> On Sun, 22 Feb 2004 09:37:42 -0500 (EST), Mike A. Harris wrote: > On Sat, 21 Feb 2004, Warren Togami wrote: > > >> Anyway, I'll wait a few days, then if there are no major issues, I'll go > >> ahead and change the name of the Tripwire package (actually it's done > >> already, I just haven't posted to bugzilla yet). > >> > > > >It seems like an extremely ugly way to avoid the specspo problem. If this > >package needs a name change to avoid it, that would mean that this is an > >acceptable solution for other packages too. There MUST be a better way. > >Perhaps... > > > >BuildConflicts: specspo > >Conflicts: specspo > > > >... Yeah I am half kidding... but you think of a better solution. > > Have the %post automatically strip the tripwire entries out of > the specspo files. Not nice, but then it's not nice to have them > in there in the first place if the package isn't in the > distribution. > > IMHO... What is this? First episode of "Battle of the Packages"? Actually, at fedora.us, a package which modifies the files included within another package in %post would be unacceptable for me and a "blocker "criterion [*]. Surely the Fedora Project will find the proper solution for this very minor "tripwire vs. specspo" issue. And that is either to remove the tripwire entries from the specspo package or to fix them together with the %description in the tripwire package. If the tripwire package doesn't have any worse issues, great! -- [*] Not that you would depend on my approval, though. ;) From mharris at redhat.com Sun Feb 22 16:59:38 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 11:59:38 -0500 (EST) Subject: Closing bugs UPSTREAM In-Reply-To: <1077462630.4749.83.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> <1077462630.4749.83.camel@athlon.localdomain> Message-ID: On Sun, 22 Feb 2004, Leonard den Ottolander wrote: >> If a bug is flagged UPSTREAM, and is fixed upstream, then it is >> valid to reopen it IMHO. > >The bug in question (#114498) is fixed upstream and will be fixed in the >soon coming update of gnome-panel. Since it was filed against RawHide it >can be closed CURRENTRELEASE (or ERRATA) as soon as the update is in the >main tree. No, that is not using CURRENTRELEASE or ERRATA resolution properly. Please read the bugzilla online help located at: https://bugzilla.redhat.com/bugzilla/bug_status.cgi CURRENTRELEASE The problem described has already been fixed and can be obtained in the latest version of our product. ERRATA The problem described has been fixed and will be available as an errata update from our support web site. Please check the site to see if it is currently available for download. Rawhide is not a product release, it is an ongoing development effort. If a bug gets filed against rawhide (or fedora devel, same thing really), and it gets fixed and put into rawhide there is only one proper resolution - CLOSED->RAWHIDE Likewise, if a bug gets reported in an older OS release, and get's fixed in a new package in rawhide: CLOSED->RAWHIDE >To rephrase one last time: Imo UPSTREAM is a tag that should >only be applied to *open* issues, (a bit like DEFERRED,) which >#114498 is not. #112469 is. I don't disagree. However once a developer marks a bug as UPSTREAM, it will remain marked that way even if the upstream bug report gets closed, because the upstream bug tracker has no automated way of reopening bugs between bugzilla databases. It requires human intervention, which means either someone polls all bugs and updates them periodically, or they get updated over time when someone gets around to it. 'Someone' in this case includes both Red Hat developers, upstream developers, volunteers, reporters, and users. HTH -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Feb 22 17:03:02 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 12:03:02 -0500 (EST) Subject: RFC: Tripwire name change In-Reply-To: <20040222172550.26426900.ms-nospam-0306@arcor.de> References: <20040222061251.GA7055@devserv.devel.redhat.com> <33458.66.91.85.198.1077441767.squirrel@togami.com> <20040222172550.26426900.ms-nospam-0306@arcor.de> Message-ID: On Sun, 22 Feb 2004, Michael Schwendt wrote: >> Have the %post automatically strip the tripwire entries out of >> the specspo files. Not nice, but then it's not nice to have them >> in there in the first place if the package isn't in the >> distribution. >> >> IMHO... > >What is this? First episode of "Battle of the Packages"? Actually, at >fedora.us, a package which modifies the files included within another >package in %post would be unacceptable for me and a "blocker "criterion >[*]. Surely the Fedora Project will find the proper solution for this >very minor "tripwire vs. specspo" issue. And that is either to remove the >tripwire entries from the specspo package or to fix them together with the >%description in the tripwire package. If the tripwire package doesn't >have any worse issues, great! I don't purport that it is a /good/ solution, but it is an alternative nonetheless. Another alternative, is to have the tripwire package "Require: bugzuki" (bugzuki is a commandline based bugzilla frontend client which uses XMLRPC). Then you could have the tripwire package installation automatically detect if specspo contains the bad tripwire entries and have it automatically file a bug report via XMLRPC into bugzilla. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 17:09:03 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 17:09:03 +0000 Subject: RFC: Tripwire name change References: <20040222061251.GA7055@devserv.devel.redhat.com> Message-ID: On Sun, 22 Feb 2004 09:35:38 -0500, Mike A. Harris wrote: > On Sun, 22 Feb 2004, Keith G. Robertson-Turner wrote: > >>locale translations, is abhorrent, and I must say, very un-Linux. At the >>very least, the catalog entries should have been hard locked to a >>specific version of each package, that way if the versions don't match, >>then the contents of the specspo catalog are ignored. That particular >>omission is what amazes me most ... it defies belief, but then I guess >>that's an RPM bug, not specspo which is, after all, only data files. > > That would not work because then every single time a new rpm package is > built, one would have to edit specspo to update all the version numbers. Which is exactly why the centralised system, that specspo employs, doesn't work. Packages should contain their own translation (including the package summary and description). The translation is done once, as it is now, by whoever it is that is responsible for such things (i18n.redhat.com?), and merged with the SRPM by the build process. If the packager changes either the summary or description (albeit once every ten years), then he either has to wait for translation (BLOCKER) or publish without translation. In this way, the summary and description is always up to date, although maybe sometimes only available in one language, depending on what stage the translation is at. I'd rather have an accurate description in one language, than a (perhaps dangerously) misleading or out of date description in twenty. > Since the description text is something that rarely if ever changes in > most packages Rare, yes, but should it happen at all ... ever ... if there is a better way. This is not the slow, steady release of Red Hat boxed sets era, this is the fast and furious, new kernel a week, 20 new packages a day, apt repo's springing up like mushrooms, era. Specspo is based on an assumption ... that, basically, package summaries and descriptions never change, and that the package base remains static. This is wrong. Specspo is broken, and in the worst possible way, in a way that simultaneously breaks (or potentially breaks) every other package in a distro (in however trivial a manner). > having to manually update specspo every time would not be very > convenient. It would be annoying to the point that developers would > probably refrain from building packages as often, and instead wait much > longer between updates to avoid the specspo update penalty. I think you're putting the cart before the horse. Packagers would release as often as they liked. *If* and *when* translations became available, then they would be merged in by the build process ... until then, the package would remain un-translated. Unless the packager him/her-self decided to BLOCK while awaiting translation (or seek assistance from elsewhere to do the translation). The point is, let's get away from monstrous, centralised, totalitarian methods, and employ distributed, modular, flexible methods instead. > Since we do not ship tripwire anymore, and haven't since RHL9, if it > isn't already removed from specspo, it would make a lot of sense for us > to remove it IMHO. Might as well, since the "translations" for it are not translations at all, but just the original text copied verbatim. > /me who hates mixed case package names, including XFree86 /me too ;' From redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 17:12:08 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 17:12:08 +0000 Subject: RFC: Tripwire name change References: <20040222061251.GA7055@devserv.devel.redhat.com> <33458.66.91.85.198.1077441767.squirrel@togami.com> Message-ID: On Sun, 22 Feb 2004 09:37:42 -0500, Mike A. Harris wrote: > On Sat, 21 Feb 2004, Warren Togami wrote: >>BuildConflicts: specspo >>Conflicts: specspo > Have the %post automatically strip the tripwire entries out of > the specspo files. Not nice, but then it's not nice to have them > in there in the first place if the package isn't in the > distribution. Sigh! Now I've got to go and learn about gettext. I need a vacation ... but I'll settle for a good strong cup of coffee. - K. From redhat-forums at genesis-x.nildram.co.uk Sun Feb 22 17:23:37 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 22 Feb 2004 17:23:37 +0000 Subject: RFC: Tripwire name change References: <20040222061251.GA7055@devserv.devel.redhat.com> <33458.66.91.85.198.1077441767.squirrel@togami.com> <20040222172550.26426900.ms-nospam-0306@arcor.de> Message-ID: On Sun, 22 Feb 2004 12:03:02 -0500, Mike A. Harris wrote: > On Sun, 22 Feb 2004, Michael Schwendt wrote: >>What is this? First episode of "Battle of the Packages"? > > I don't purport that it is a /good/ solution, but it is an > alternative nonetheless. Another alternative, is to have the > tripwire package "Require: bugzuki" (bugzuki is a commandline > based bugzilla frontend client which uses XMLRPC). Then you > could have the tripwire package installation automatically detect > if specspo contains the bad tripwire entries and have it > automatically file a bug report via XMLRPC into bugzilla. Eegads ... 20 pages of "bug #12345 is a duplicate of bug #34567" I'll finish up a minor change to the spec (%description), build, publish (local), announce, and then go file a buggyzilla about specspo ... one to add to the list. Then I'm taking at least a weeks break from Tripwire. If you need me, I'll be sleeping. - K. From mharris at redhat.com Sun Feb 22 17:40:18 2004 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 22 Feb 2004 12:40:18 -0500 (EST) Subject: RFC: Tripwire name change In-Reply-To: References: <20040222061251.GA7055@devserv.devel.redhat.com> Message-ID: On Sun, 22 Feb 2004, Keith G. Robertson-Turner wrote: >> That would not work because then every single time a new rpm package is >> built, one would have to edit specspo to update all the version numbers. > >Which is exactly why the centralised system, that specspo employs, doesn't >work. I never claimed it did. In fact, the current specspo method does /not/ work. I'm only claiming that replacing one broken method of doing description translations that is problematic, with another equally broken (or morseo) method, is not a good solution at all. >Packages should contain their own translation (including the >package summary and description). The translation is done once, >as it is now, by whoever it is that is responsible for such >things (i18n.redhat.com?), and merged with the SRPM by the build >process. And if a translator breaks something, and your package that took 6 hours to build fails due to a broken translation, who fixes it? >> Since the description text is something that rarely if ever changes in >> most packages > >Rare, yes, but should it happen at all ... ever ... if there is >a better way. This is not the slow, steady release of Red Hat >boxed sets era, this is the fast and furious, new kernel a week, >20 new packages a day, apt repo's springing up like mushrooms, >era. Specspo is based on an assumption ... that, basically, >package summaries and descriptions never change, and that the >package base remains static. This is wrong. Specspo is broken, >and in the worst possible way, in a way that simultaneously >breaks (or potentially breaks) every other package in a distro >(in however trivial a manner). Again, I do not disagree. >> having to manually update specspo every time would not be very >> convenient. It would be annoying to the point that developers would >> probably refrain from building packages as often, and instead wait much >> longer between updates to avoid the specspo update penalty. > >I think you're putting the cart before the horse. Packagers >would release as often as they liked. *If* and *when* >translations became available, then they would be merged in by >the build process ... until then, the package would remain >un-translated. Unless the packager him/her-self decided to BLOCK >while awaiting translation (or seek assistance from elsewhere to >do the translation). I'm not putting any cart before the horse. I'm stating a clear fact that replacing one broken way of doing translation with another equally if not more broken method does not accomplish anything. It would move the irritation from one place to another, and move the burden to fix it from one group of people to another. There would be an additional irritation as well. If the package descriptions did not change at all, and you build a new version/release, and that invalidates specspo, but nothing actually needs to be done - and that causes translations to be disabled until someone edits something and bumps the version number, that person will be irritated 200 times a week. Again, that does not solve the problem. >The point is, let's get away from monstrous, centralised, >totalitarian methods, and employ distributed, modular, flexible >methods instead. I totally agree with you. But the method you prescribe is _not_ the answer as it solves one ugly problem by making another equally ugly problem. What might work, is having specspo keep just the translations, and have package builds automatically trigger a 'test' of some sort that tests for any changes in the description or other translateable fields in the spec file. If any actual text changes compared to the last build, then some automated process invalidates the specspo entries for that translation and notifies the translators via bugzilla XMLRPC. That way, not only is the burden removed from package maintainers, but it is also not shoved on to translators to edit something rediculously just to bump a version number to say "nothing changed, so please keep including translations". Instead, the massive amount of computing power we have at our disposal is doing something useful and notifying the people who need to do any work only when there is work to do. The added bonus, is that it has full bugzilla defect tracking and can be flagged as blockers of a string-freeze-date bug, and go through normal triage process, etc. The only thing left to do, is get someone to do the work. No, before anyone asks, I'm not volunteering - I came up with the idea, I did my part already. ;o) Hmmm... Sopwith is pretty familiar with the buildsystem code and post build test harnesses... and Adrian and Dave know bugzilla XMLRPC pretty good... hmmm.... ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ghenry at suretecsystems.com Sun Feb 22 17:49:34 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 22 Feb 2004 17:49:34 +0000 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: References: <200402202323.24851.ghenry@suretecsystems.com> Message-ID: <200402221749.36290.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 22 February 2004 01:13, Dag Wieers wrote: > On Fri, 20 Feb 2004, Gavin Henry wrote: > > Dag Wieers if you have a second, could you look these over? Or anyone > > else :-) > > > > http://www.suretecsystems.com/putty/putty.spec > > Obviously what I would do is already in my SPEC file. Let me tell you why > I do some things differently. > > > First of all you seem to want to format everything the way you do. And it > looks pretty nice, but I don't think it is very useful. Aligning ':' is a > nobel thing but apart from being very time consuming it doesn't gain you > anything. And I even think it is more difficult to read. (Does vi even > color-highlight this correctly ??) Yeah, looking at it again, it really has no benefit and takes too long to do. > > Formatting however is mostly a personal preference anyway. > > > Then putting a line between sections is something that fedora.us thought > was a very good idea (no arguing about it back then!) and after a few > months abandoned unanimously... > > > Adding a BuildRequirement for desktop-file-utils makes sense if you're > limiting yourself to distributions that have it. RHEL2.1 doesn't and is > supported until 2006 IIRC. Perl for me belongs to the standard build > environment and therefor doesn't need mentioning. I do like the way you have done it, rather than have another file in the src rpm, make the desktop in the specfile, keeps it all together. > > > You seem to 'quiet' the %setup output, which is something I _want_ to have > in my buildlogs. If people are building my source-package I want them to > be able to even compare the content of a tarball. It also helps to > identify extra documentation or other files after inspection a buildlog > when you go over your buildlog one last time. (part of the methodology, in > the end this saves a lot of time as you don't have to re-release a package > because you omitted something by mistake) I never paid attention to the -q part, thanks for this tid bit. :-) > > > You've put my perl one-liner on one-line ;)) But you're doing 3 > substitutions in one go and it becomes less obvious what you're doing if > you make it unreadable this way. > > eg. > %{__perl} -pi -e ' > s,-O2,$RPM_OPT_FLAGS,g;s,/usr/local,%{_prefix},g;s,^(\t\$\(INSTALL_DATA\) > -m 644 ps.+)$, ,' unix/Makefile.gtk > > vs. > %{__perl} -pi.orig -e ' > s|-O2|%{optflags}|g; > s|/usr/local|%{_prefix}|g; > s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; > ' unix/Makefile.gtk > > Simplicity comes first, readability second. Putting a perl one-liner on a > single line you're not making this more simple, but sure less readable. Agreed. > (Remember that when it gets fixed upstream you should verify that it can > be removed, if it takes you 1 minute to understand what it did...) Understood. > > > Some of the stuff was already mentioned. You're not using > %{_datadir}/applications, you're adding yet another vendor. Yeah, I will take Michel's advise on board as well. Nice learning curve for me :-) But its the only way to learn. > > > I would add the desktop-file inline so that it is one less extra source > which greatly enhances your ability to have a clear overview of > everything. In your case to evaluate the package you need to look at at > least another file. I now agree. > > > I also noticed you're repeating the package-name in your description, eg. > > Summary: PuTTY - A Free Telnet/SSH Client, plus utilities > > There's no added value by doing so. What's even more people don't know > exactly what to expect. If you have alternative software packaged, the > summary should indicate what the difference is. > > Look at: > > openssh - The OpenSSH implementation of SSH protocol versions 1 and 2. > telnet - The client program for the telnet remote login protocol. > putty - GUI SSH, Telnet and Rlogin client. > rsh - Clients for remote access (rsh, rlogin, rcp). > > At least you can tell from the summary putty is a GUI program, which is > essential information for someone who needs to choose. I also try to avoid > using GNOME/GTK/KDE directly as it shouldn't matter to the end-user. Point taken.. > > I also end a summary with a dot, which is often done by Red Hat too. Once > again it may be a personal preference. Ok. > > > Also you're using $RPM_BUILD_ROOT instead of %{buildroot} and although > there's no real difference, you're mostly using macros everywhere else. > This has been discussed at fedora.us also and I'm not sure if they have a > valid reason to use a shell variable instead of the macro. (I know jbj > made a statement about it and I don't think it adds to the equation) > > To me (personally) the macro fits better and makes it easier for the eyes. > (FOR THE SAME PEOPLE THINK THAT I'M NOW SHOUTING AND IT HURTS THE EYES ;-) I have just been following the fedora.us site for all this info. I forgot to check the fedora.redhat developer guide, which has an rpm section and basically does it how you do it. So I think I will give that a good read over. > > > Well, those are my suggestions and some go directly against fedora.us > guidelines. So be it. :-) Lastly, I would really like to thank you for your time. It is much appreciated. Oh, how do you find the time to do all those rpms anyway? Have you a shell script to do it like on rpmpan?? Hopefully this thread will help others out, and I won't feel like I have been making a fool of myself :) Cheers again Dag. My next tasks are reading more docs, updating these and I want to do OTRS (I have one rough one done) and Mamboserver. Look out for more rubbish specfiles :-) - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFAOOuueWseh9tzvqgRAlqDAJwLL4D37ewU08XRcHwDaPglehda4QCXae6t C7qE6AfkcmFzwYj6w4HiHQ== =WqDy -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Sun Feb 22 17:50:51 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 22 Feb 2004 17:50:51 +0000 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: References: <200402202323.24851.ghenry@suretecsystems.com> Message-ID: <200402221750.53613.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 22 February 2004 01:23, Dag Wieers wrote: > On Sun, 22 Feb 2004, Dag Wieers wrote: > > You've put my perl one-liner on one-line ;)) But you're doing 3 > > substitutions in one go and it becomes less obvious what you're doing if > > you make it unreadable this way. > > > > eg. > > %{__perl} -pi -e ' > > s,-O2,$RPM_OPT_FLAGS,g;s,/usr/local,%{_prefix},g;s,^(\t\$\(INSTALL_DATA\) > > -m 644 ps.+)$, ,' unix/Makefile.gtk > > > > vs. > > %{__perl} -pi.orig -e ' > > s|-O2|%{optflags}|g; > > s|/usr/local|%{_prefix}|g; > > s|^(\t\$\(INSTALL_DATA\) -m 644 ps.+)$|#$1|; > > ' unix/Makefile.gtk > > > > Simplicity comes first, readability second. Putting a perl one-liner on a > > single line you're not making this more simple, but sure less readable. > > (Remember that when it gets fixed upstream you should verify that it can > > be removed, if it takes you 1 minute to understand what it did...) > > I forgot to add that you removed my comment: > > ### FIXME: Disable missing pscp.1 and psftp.1. (Please fix upstream) > > Of course you understand the 3rd substitution when you're reading it now, > but there's no guarantee that the next time you're upgrading this package > you'd still remember. Especially because it doesn't say that in fact > you're diasbling 2 lines with the substitution. > > Removing the comment will have a penalty the next time you want to upgrade > it. The comments are there to help you (or anyone else) to remember things > without having to go once again through the code to see what it is > substituting. > > (The FIXME comments are special in my case as they're indicated on the > website so that other people now why they're missing and it may get fixed > upstream too.) Sorry about that. I will put that back in. Thanks again, I will Post a link with my version latter this week. > > -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- > [Any errors in spelling, tact or fact are transmission errors] - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAOOv7eWseh9tzvqgRAtfeAJ9Ys1Xim/OaTqrpb5HO+xcfEvi1MwCbBUwc OO9rBA/OrfgHB9zK0OrMyQs= =tCRJ -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Sun Feb 22 18:04:35 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 22 Feb 2004 19:04:35 +0100 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: References: <200402202323.24851.ghenry@suretecsystems.com> Message-ID: <20040222190435.39d93f74.ms-nospam-0306@arcor.de> On Sun, 22 Feb 2004 02:13:48 +0100 (CET), Dag Wieers wrote: > > http://www.suretecsystems.com/putty/putty.spec > Then putting a line between sections is something that fedora.us thought > was a very good idea (no arguing about it back then!) It has never been mandatory to insert or delete such lines. Spec file formatting and indentation remains packager's personal preference. > and after a few months abandoned unanimously... Because such separator-lines when placed after the scriplet sections break -p /sbin/ldconfig scripts as of Fedora Core 1. -- From buildsys at redhat.com Sun Feb 22 19:02:33 2004 From: buildsys at redhat.com (Build System) Date: Sun, 22 Feb 2004 14:02:33 -0500 Subject: rawhide report: 20040222 changes Message-ID: <200402221902.i1MJ2Xu01159@porkchop.devel.redhat.com> Updated Packages: binutils-2.14.90.0.8-8 ---------------------- * Sat Feb 21 2004 Jakub Jelinek 2.14.90.0.8-8 - with -z now without --enable-new-dtags create DT_BIND_NOW dynamic entry in addition to DT_FLAGS_1 with DF_1_NOW bit set bluez-pan-1.1-4 --------------- * Sat Feb 14 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d coreutils-5.2.0-4 ----------------- * Sat Feb 21 2004 Tim Waugh 5.2.0-4 - Reinstate kill binary, just not its man page (bug #116463). * Sat Feb 21 2004 Tim Waugh 5.2.0-3 - Updated ls-stat patch. distcache-0.4.2-11 ------------------ * Sat Feb 21 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d gkrellm-2.1.24-3 ---------------- * Sat Feb 21 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d kdebase-3.2.0-1.7 ----------------- * Sat Feb 21 2004 Dan Walsh 6:3.2.0-1.7 - add selinux support to kde pam file kernel-2.6.3-1.97 ----------------- * Sat Feb 21 2004 Dave Jones - Update to 2.6.3-bk3 * Fri Feb 20 2004 Dave Jones - Update to 2.6.3-bk2 - Fix up typo in amd64 MSR defines (Will Cohen) * Thu Feb 19 2004 Dave Jones - Update to 2.6.3bk1 - Enable support for IA32E - Compile in EVDEV - Disable the background MCE checker. - Fix up printing of longs in ext3-resize patch. - Rework the changefd patch. - Kill off init_etherdev kernel-utils-2.4-9.1.120 ------------------------ libgcrypt-1.1.12-3 ------------------ * Sat Feb 21 2004 Florian La Roche - add symlinks to shared libs at compile time libraw1394-0.10.0-2 ------------------- * Sat Feb 21 2004 Florian La Roche - add symlinks to shared libs already at install time libtiff-3.5.7-16 ---------------- * Sat Feb 21 2004 Florian La Roche - really add symlink to shared lib by running ldconfig at compile time openCryptoki-2.1.3-8 -------------------- * Sat Feb 21 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d policy-1.6-1 ------------ rpmdb-fedora-1.90-0.20040222 ---------------------------- texinfo-4.6-3 ------------- * Sat Feb 21 2004 Tim Waugh 4.6-3 - Build requires zlib-devel (bug #116436). udev-016-3 ---------- * Sat Feb 21 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d util-linux-2.12-3 ----------------- * Fri Feb 20 2004 Dan Walsh 2.12-3 - rebuilt From leonard at den.ottolander.nl Sun Feb 22 19:04:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 20:04:43 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> <1077462630.4749.83.camel@athlon.localdomain> Message-ID: <1077476682.4752.3.camel@athlon.localdomain> Hello Mike, > >soon coming update of gnome-panel. Since it was filed against RawHide it > >can be closed CURRENTRELEASE (or ERRATA) as soon as the update is in the > >main tree. Of Fedora Core 1 that is. > No, that is not using CURRENTRELEASE or ERRATA resolution > properly. The bug will soon be fixed for FC 1, not RawHide. How should it be closed in that case? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From markmc at redhat.com Sun Feb 22 19:05:53 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sun, 22 Feb 2004 19:05:53 +0000 Subject: Closing bugs UPSTREAM In-Reply-To: <1077458859.4749.55.camel@athlon.localdomain> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> Message-ID: <1077476752.4075.9.camel@laptop> Hi, On Sun, 2004-02-22 at 14:07, Leonard den Ottolander wrote: > Hi Marc, Its Mark. > > I'm trying to figure out what you think doing it this way would achieve > > ... I may be missing something here, you know :-) > > Closing bugs as UPSTREAM is ambiguous if you close both bugs that are > fixed and not yet fixed upstream. I don't understand. Why is it ambiguous? Why does it matter? Thanks, Mark. From leonard at den.ottolander.nl Sun Feb 22 19:20:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 22 Feb 2004 20:20:41 +0100 Subject: Closing bugs UPSTREAM In-Reply-To: <1077476752.4075.9.camel@laptop> References: <1077386675.4746.15.camel@athlon.localdomain> <1077388973.5259.13.camel@laptop> <1077391079.4921.8.camel@athlon.localdomain> <1077436475.17222.3.camel@bushido.mshome.net> <1077454610.4749.9.camel@athlon.localdomain> <1077455512.6344.37.camel@laptop> <1077458859.4749.55.camel@athlon.localdomain> <1077476752.4075.9.camel@laptop> Message-ID: <1077477641.4752.16.camel@athlon.localdomain> Hi Mark, > > Hi Marc, > > Its Mark. Oops. Sorry for that. Must have been the Mc that confused me :) . > > Closing bugs as UPSTREAM is ambiguous if you close both bugs that are > > fixed and not yet fixed upstream. > > I don't understand. Why is it ambiguous? Why does it matter? Because if you also tag already fixed bugs as UPSTREAM it is unclear that they actually got fixed in the distribution. Which is what will happen with #114498 as soon as the update to gnome-panel-2.4.2 has happened. Since this issue will be fixed so soon I felt it to be unnecessary to close that particular bug as UPSTREAM at this time. Had it happened two months ago it would have been different. I'll leave it at this for this thread. I get the feeling this thread gets somewhat Babylonian. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dag at wieers.com Sun Feb 22 19:32:44 2004 From: dag at wieers.com (Dag Wieers) Date: Sun, 22 Feb 2004 20:32:44 +0100 (CET) Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: <200402221749.36290.ghenry@suretecsystems.com> References: <200402202323.24851.ghenry@suretecsystems.com> <200402221749.36290.ghenry@suretecsystems.com> Message-ID: On Sun, 22 Feb 2004, Gavin Henry wrote: > Lastly, I would really like to thank you for your time. It is much > appreciated. Oh, how do you find the time to do all those rpms anyway? Have > you a shell script to do it like on rpmpan?? Well, I have a shell script (ugly but efficient) that helps me build and manage builds. It is called DAR and can be found at: http://dag.wieers.com/home-made/dar/ It's build only for me and with a few adjustments it might be used by others but since I'm moving to use mach soon it probably is only relevant for reference if you want to do it properly. > My next tasks are reading more docs, updating these and I want to do OTRS (I > have one rough one done) and Mamboserver. Actually I have an OTRS package too, but it hasn't been very well tested. I was planning to replace our own installation by this package, but the person responsible didn't have the time. You may want to poke that one and send over any suggestions. I applied your fix for the StartUpNotify problem with the GTK+ program. The next release will have it fixed (not really important to make a new release for it). Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Sun Feb 22 19:34:50 2004 From: dag at wieers.com (Dag Wieers) Date: Sun, 22 Feb 2004 20:34:50 +0100 (CET) Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: <20040222190435.39d93f74.ms-nospam-0306@arcor.de> References: <200402202323.24851.ghenry@suretecsystems.com> <20040222190435.39d93f74.ms-nospam-0306@arcor.de> Message-ID: On Sun, 22 Feb 2004, Michael Schwendt wrote: > On Sun, 22 Feb 2004 02:13:48 +0100 (CET), Dag Wieers wrote: > > > Then putting a line between sections is something that fedora.us thought > > was a very good idea (no arguing about it back then!) > > It has never been mandatory to insert or delete such lines. Spec file > formatting and indentation remains packager's personal preference. Well, IIRC the template used to have it and most SPEC files were formatted after the template. Of course I never looked at all the SPEC files so I can only remember what I got to see of it. > > and after a few months abandoned unanimously... > > Because such separator-lines when placed after the scriplet sections > break -p /sbin/ldconfig scripts as of Fedora Core 1. Yes, that was eventually the reason why it had to be removed ;) Quite funny actually. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ghenry at suretecsystems.com Sun Feb 22 20:31:38 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 22 Feb 2004 20:31:38 +0000 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: References: <200402202323.24851.ghenry@suretecsystems.com> <200402221749.36290.ghenry@suretecsystems.com> Message-ID: <200402222031.40785.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 22 February 2004 19:32, Dag Wieers wrote: > On Sun, 22 Feb 2004, Gavin Henry wrote: > > Lastly, I would really like to thank you for your time. It is much > > appreciated. Oh, how do you find the time to do all those rpms anyway? > > Have you a shell script to do it like on rpmpan?? > > Well, I have a shell script (ugly but efficient) that helps me build and > manage builds. It is called DAR and can be found at: > > http://dag.wieers.com/home-made/dar/ > > It's build only for me and with a few adjustments it might be used by > others but since I'm moving to use mach soon it probably is only relevant > for reference if you want to do it properly. how would you use mach in mass production ie mach build *.spec I use it to, but it never downloads the source from what is in Source: > > > My next tasks are reading more docs, updating these and I want to do OTRS > > (I have one rough one done) and Mamboserver. > > Actually I have an OTRS package too, but it hasn't been very well tested. > I was planning to replace our own installation by this package, but the > person responsible didn't have the time. > > You may want to poke that one and send over any suggestions. I will do. Is it in your main repository? > I applied > your fix for the StartUpNotify problem with the GTK+ program. The next > release will have it fixed (not really important to make a new release for > it). Again I will clean up my one. Oh, with respect to Michel Alexandre Salim comments, if these adjustments are made, will this enable a desktop entry in both gnome and kde? I haven't had chance to look at freedesktop.org, so the answer is probably there. Thanks again Dag. - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAORGqeWseh9tzvqgRAm9NAJ9NiAAqjKQVViD8sR2Wujhg+JQkRwCfcdIh +sDMWDOMcUowHIfkMfuS7nk= =B6TY -----END PGP SIGNATURE----- From pauln at truemesh.com Sun Feb 22 22:16:02 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Sun, 22 Feb 2004 22:16:02 +0000 Subject: evdev was Re: rawhide report: 20040222 changes In-Reply-To: <200402221902.i1MJ2Xu01159@porkchop.devel.redhat.com> References: <200402221902.i1MJ2Xu01159@porkchop.devel.redhat.com> Message-ID: <20040222221601.GE21947@lichen.truemesh.com> On Sun, Feb 22, 2004 at 02:02:33PM -0500, Build System wrote: > kernel-2.6.3-1.97 > ----------------- > * Sat Feb 21 2004 Dave Jones > > - Update to 2.6.3-bk3 > > * Fri Feb 20 2004 Dave Jones > > - Update to 2.6.3-bk2 > - Fix up typo in amd64 MSR defines (Will Cohen) > > * Thu Feb 19 2004 Dave Jones > > - Update to 2.6.3bk1 > - Enable support for IA32E > - Compile in EVDEV I was going to RFE this anyway - cheers. Is this likely to stay compiled in? > - Disable the background MCE checker. > - Fix up printing of longs in ext3-resize patch. > - Rework the changefd patch. > - Kill off init_etherdev Paul From peter.backlund at home.se Sun Feb 22 22:36:32 2004 From: peter.backlund at home.se (Peter Backlund) Date: Sun, 22 Feb 2004 23:36:32 +0100 Subject: Premptible kernel Message-ID: <40392EF0.9040906@home.se> If I remember correctly, preemption isn't enabled in the kernel due to problems with SMP. Is that still true? If so, would it be possible to build the UP kernel with preemption enabled? /Peter Backlund From felipe_alfaro at linuxmail.org Sun Feb 22 23:05:48 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 23 Feb 2004 00:05:48 +0100 Subject: Premptible kernel In-Reply-To: <40392EF0.9040906@home.se> References: <40392EF0.9040906@home.se> Message-ID: <1077491147.2135.4.camel@teapot.felipe-alfaro.com> On Sun, 2004-02-22 at 23:36, Peter Backlund wrote: > If I remember correctly, preemption isn't enabled in the kernel due to > problems with SMP. Is that still true? If so, would it be possible to > build the UP kernel with preemption enabled? I don't think preempt is disabled due to problems with SMP. IIRC preemption basically represents the efforts of the kernel hackers to improve kernel reentrancy and remove the Big Kernel Lock to increase scalability on SMP systems. I think preemption is disabled since there are some drivers which do not work well enough when used with preemtion enabled. I have also heard there is some hard-to-reproduce bug which is triggered more easily when preemp is enabled. However, you can compile the kernel yourself and enable preemption on UP systems In fact, I've been running preemptible kernels since 2.5.48 or so and they have always worked neatly for me. From davej at redhat.com Mon Feb 23 01:23:19 2004 From: davej at redhat.com (Dave Jones) Date: Mon, 23 Feb 2004 01:23:19 +0000 Subject: evdev was Re: rawhide report: 20040222 changes In-Reply-To: <20040222221601.GE21947@lichen.truemesh.com> References: <200402221902.i1MJ2Xu01159@porkchop.devel.redhat.com> <20040222221601.GE21947@lichen.truemesh.com> Message-ID: <1077499398.31341.0.camel@delerium.codemonkey.org.uk> On Sun, 2004-02-22 at 22:16, Paul Nasrat wrote: > > - Compile in EVDEV > > I was going to RFE this anyway - cheers. Is this likely to stay compiled in? yeah. it makes Bill's life easier, and has no real downsides.. Dave From aoliva at redhat.com Mon Feb 23 02:26:22 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Feb 2004 23:26:22 -0300 Subject: DRAFT - Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO In-Reply-To: <40389659.20209@togami.com> References: <40389659.20209@togami.com> Message-ID: On Feb 22, 2004, Warren Togami wrote: > Any suggestions for improving the procedure Don't convert the first disk's partition types to raid before you actually make them raid members. Should they happen to contain raid control blocks, for any reason (such as having been raid members before) this might prevent the newly-created raid devices from being started. Yes, this has happened to me in the past :-) Create the raid devices with `missing /dev/hdc?', instead of the other way round, such that /dev/hda? is the master copy. This is particularly important for the boot partition. Should the boot partition happen to need a resync due to a crash, you'll be overwriting the GRUB boot info in /dev/hda with that in /dev/hdc. This may be bad, and leave you with a non-rebootable system. Yes, this has happened to me in the past :-) > mdadm manual start on RHEL3 failed would be appreciated. I wouldn't be surprised if the reason for the mdadm failure turns out to be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107988 -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From llch at redhat.com Mon Feb 23 04:06:30 2004 From: llch at redhat.com (Leon Ho) Date: Mon, 23 Feb 2004 14:06:30 +1000 Subject: Testers Required for Next Generation Input Method In-Reply-To: <1077373863.13557.5.camel@bushido.mshome.net> References: <1077373863.13557.5.camel@bushido.mshome.net> Message-ID: <1077509190.1349.14.camel@dhcp-101.brisbane.redhat.com> yum repositories are at http://iiimf.fedora.us/ now. Special thanks to Warren to give out his bandwidth for this testing project. Regards, Leon On Sun, 2004-02-22 at 00:31, Michel Alexandre Salim wrote: > On Sat, 2004-02-21 at 22:06 +1000, Leon Ho wrote: > > > IIIMF testing packages: > > http://apac.redhat.com/iiimftest/files > > Could you guys run yum-arch on the repository? Saves the hassle of > downloading individual RPMs. > > Thanks, > > Michel -- Leon Ho Team Leader of Engineering Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer From skvidal at phy.duke.edu Mon Feb 23 05:03:30 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 23 Feb 2004 00:03:30 -0500 Subject: yum and postinst In-Reply-To: <200402222226.05214.russell@coker.com.au> References: <200402222226.05214.russell@coker.com.au> Message-ID: <1077512609.22711.36.camel@binkley> On Sun, 2004-02-22 at 22:26 +1100, Russell Coker wrote: > When a package is installed and the scriptlet can't run, should the > installation of that package be considered complete, or should I be able to > run the scriptlet after fixing the problem? Good question - though it seems more like an rpm question. Any takers on rpm-list or rpm-devel? -sv From mark at mark.mielke.cc Mon Feb 23 05:27:16 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 23 Feb 2004 00:27:16 -0500 Subject: anybody notice fetchmail in daemon/poll mode doesn't seem to work? Message-ID: <20040223052716.GA12109@mark.mielke.cc> A few weeks ago, I updated fetchmail to devel-list, and ever since, my fetchmail configuration no longer functions properly in daemon mode. The symptoms seem to be that when fetchmail first starts up, it goes into the background, and fetches mail as expected, but then, once it has downloaded all new email, it never notices new email again. I "fetchmail -q" and then "fetchmail" before reading email as a work around. Is this working for anybody else (suggesting it is a configuration problem on my end)? My .fetchmailrc follows (with personal fields dotted out): -- CUT -- set logfile "/home/mark/.fetchmail.log" set postmaster "mark" set nobouncemail set properties "" set daemon 30 set invisible poll ... with protocol imap user "..." there with password "..." is mark here warnings 3600 mda "/usr/bin/procmail -d mark" antispam 571 550 501 554 fetchall poll ... with protocol pop3 user "..." there with password "..." is mark here warnings 3600 mda "/usr/bin/procmail -d mark" antispam 571 550 501 554 fetchall -- CUT -- This configuration file has been working for a few months now without any change to .fetchmailrc. I suppose it is possible that the imap server (dovecot) is messing it up somehow... Thanks, 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 naoki at valuecommerce.com Mon Feb 23 06:51:31 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 23 Feb 2004 15:51:31 +0900 Subject: Update errors, gnome panel XML + kernel module. Message-ID: <4039A2F3.4090205@valuecommerce.com> initscripts 100 % done 338/1136 chown: `root.utmp': invalid user kernel-smp 100 % done 339/1136 WARNING: /lib/modules/2.6.3-1.97smp/unsupported/fs/reiserfs/reiserfs.ko needs unknown symbol sleep_on kernel 100 % done 385/1136 WARNING: /lib/modules/2.6.3-1.97/unsupported/fs/reiserfs/reiserfs.ko needs unknown symbol sleep_on XML errors in Gnome Media and Printman : /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input is not proper UTF-8, indicate encoding ! Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ /usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 0x6E 0x20 0x4C Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ OMF file does not exist, is not readable, or is not well-formed XML: /usr/share/omf/gnome-panel/window-list-es.omf Unable to register /usr/share/omf/gnome-panel/window-list-es.omf gnome-applets 100 % done 520/1136 /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input is not proper UTF-8, indicate encoding ! Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ /usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 0x6E 0x20 0x4C Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ OMF file does not exist, is not readable, or is not well-formed XML: /usr/share/omf/gnome-panel/window-list-es.omf Unable to register /usr/share/omf/gnome-panel/window-list-es.omf file-roller 100 % done 521/1136 /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input is not proper UTF-8, indicate encoding ! Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ /usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 0x6E 0x20 0x4C Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ OMF file does not exist, is not readable, or is not well-formed XML: /usr/share/omf/gnome-panel/window-list-es.omf Unable to register /usr/share/omf/gnome-panel/window-list-es.omf ggv 100 % done 522/1136 /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input is not proper UTF-8, indicate encoding ! Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ /usr/share/omf/gnome-panel/window-list-es.omf:12: error: Bytes: 0xF3 0x6E 0x20 0x4C Manual de la miniaplicaic?n Lista de ventanas V2.6 ^ OMF file does not exist, is not readable, or is not well-formed XML: /usr/share/omf/gnome-panel/window-list-es.omf Unable to register /usr/share/omf/gnome-panel/window-list-es.omf From warren at togami.com Mon Feb 23 09:01:09 2004 From: warren at togami.com (Warren Togami) Date: Sun, 22 Feb 2004 23:01:09 -1000 Subject: DRAFT - Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO In-Reply-To: References: <40389659.20209@togami.com> Message-ID: <4039C155.3030909@togami.com> Alexandre Oliva wrote: > On Feb 22, 2004, Warren Togami wrote: > > >>Any suggestions for improving the procedure > > > Don't convert the first disk's partition types to raid before you > actually make them raid members. Should they happen to contain raid > control blocks, for any reason (such as having been raid members > before) this might prevent the newly-created raid devices from being > started. Yes, this has happened to me in the past :-) > > Create the raid devices with `missing /dev/hdc?', instead of the other > way round, such that /dev/hda? is the master copy. This is > particularly important for the boot partition. Should the boot > partition happen to need a resync due to a crash, you'll be > overwriting the GRUB boot info in /dev/hda with that in /dev/hdc. > This may be bad, and leave you with a non-rebootable system. Yes, > this has happened to me in the past :-) > Hmm, if I have a running system made this way now, is there anything I can do to switch the master copy? Thank you for the suggestions! > >>mdadm manual start on RHEL3 failed would be appreciated. > > > I wouldn't be surprised if the reason for the mdadm failure turns out > to be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107988 > Bingo, that seems to describe the behavior. Warren Togami wtogami at redhat.com From aoliva at redhat.com Mon Feb 23 09:41:05 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 23 Feb 2004 06:41:05 -0300 Subject: DRAFT - Remote Conversion to Linux Software RAID-1 for Crazy Sysadmins HOWTO In-Reply-To: <4039C155.3030909@togami.com> References: <40389659.20209@togami.com> <4039C155.3030909@togami.com> Message-ID: On Feb 23, 2004, Warren Togami wrote: > Hmm, if I have a running system made this way now, is there anything I > can do to switch the master copy? Since it's just the /boot filesystem, umount it, stop the raid device, then use mdadm to create it in the right order. It doesn't really matter for the others, so I'd just leave them alone. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From markmc at redhat.com Mon Feb 23 11:09:13 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 23 Feb 2004 11:09:13 +0000 Subject: Update errors, gnome panel XML + kernel module. In-Reply-To: <4039A2F3.4090205@valuecommerce.com> References: <4039A2F3.4090205@valuecommerce.com> Message-ID: <1077534552.3232.26.camel@laptop> Hi, The gnome-panel issue is being tracked here: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116475 Thanks, Mark. On Mon, 2004-02-23 at 06:51, Naoki wrote: > /usr/share/omf/gnome-panel/window-list-es.omf:12: parser error : Input > is not proper UTF-8, indicate encoding ! > Manual de la miniaplicaic?n Lista de ventanas V2.6 > ^ [snip] From tony at tgds.net Mon Feb 23 11:55:54 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 23 Feb 2004 12:55:54 +0100 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <1076957661.27602.27.camel@localhost.localdomain> References: <1076957661.27602.27.camel@localhost.localdomain> Message-ID: <1077537354.11992.12.camel@localhost.localdomain> Ok I am now trying to build my own 2.6.3 kernel to work around VMware 3.2.1 not working with the ones found on people.redhat.com And I have rediscovered the joys of the root device not being recognised on boot. My question : what is wrong with "mount -o loop initrd-2.6.3.img /mnt/tmp" ? I am asked for a file system type and... well none are recognised. Thanks for your time Tony Grant -- www.tgds.net Library management software toolkit From twaugh at redhat.com Mon Feb 23 12:14:16 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 23 Feb 2004 12:14:16 +0000 Subject: chown xxx.yyy is now rejected Message-ID: <20040223121416.GK6654@redhat.com> The 'chown xxx.yyy' syntax has been deprecated for several releases now, the correct syntax being 'chown xxx:yyy'. The newly released stable version of coreutils, 5.2.0, now rejects the old syntax unless _POSIX2_VERSION=199209 is found in the environment. I have updated the spec files (in CVS HEAD) for all of the RPM packages that I found using the old syntax, but I have not rebuilt them. They will be rebuilt shortly -- I have notified the package owners. Once everything is settled down, perhaps we will be able to remove the restriction that prevents user names containing '.'. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116536 Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkt at redhat.com Mon Feb 23 13:29:03 2004 From: jkt at redhat.com (Jay Turner) Date: Mon, 23 Feb 2004 08:29:03 -0500 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <1077537354.11992.12.camel@localhost.localdomain> References: <1076957661.27602.27.camel@localhost.localdomain> <1077537354.11992.12.camel@localhost.localdomain> Message-ID: <20040223132903.GN23631@redhat.com> On Mon, Feb 23, 2004 at 12:55:54PM +0100, Tony Grant wrote: > Ok I am now trying to build my own 2.6.3 kernel to work around VMware > 3.2.1 not working with the ones found on people.redhat.com > > And I have rediscovered the joys of the root device not being recognised > on boot. > > My question : what is wrong with "mount -o loop initrd-2.6.3.img > /mnt/tmp" ? I am asked for a file system type and... well none are > recognised. initrd images are actually gzip'd, so you'll actually need to unzip it before you will be able to mount it. 'file' will generally point you in the right direction in these cases: [heisey (root):~]# file /boot/initrd-2.4.21-9.0.1.EL.img /boot/initrd-2.4.21-9.0.1.EL.img: gzip compressed data, from Unix, max compression Anyway, you'll want to do something like this: zcat /boot/initrd-2.6.3.img > /tmp/foo mount -o loop /tmp/foo /mnt/tmp You can then view the contents of the initrd via the /mnt/tmp mountpoint. - 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 buildsys at redhat.com Mon Feb 23 13:49:21 2004 From: buildsys at redhat.com (Build System) Date: Mon, 23 Feb 2004 08:49:21 -0500 Subject: rawhide report: 20040223 changes Message-ID: <200402231349.i1NDnLn17114@porkchop.devel.redhat.com> Updated Packages: epiphany-1.1.9-1 ---------------- * Sun Feb 22 2004 Jeremy Katz 1.1.9-1 - update to 1.1.9 - reenable nautilus view expat-1.95.7-1 -------------- * Sun Feb 22 2004 Joe Orton 1.95.7-1 - update to 1.95.7, include COPYING file in main package fonts-ja-8.0-11 --------------- * Mon Feb 23 2004 Akira TAGOH 8.0-11 - fonts-ja-8.0-gcc-warnings.patch: applied to fix a gcc warning. (#116454) gcc34-3.4.0-0.5 --------------- * Sun Feb 22 2004 Jakub Jelinek 3.4.0-0.5 - fix profiled feedback race * Sat Feb 21 2004 Jakub Jelinek 3.4.0-0.4 - update from gcc-3_4-branch - PRs 12028, 12179, bootstrap/13617, bootstrap/14180, bootstrap/9249, c++/11295, c++/11326, c/12818, c++/12850, c++/13086, c++/13113, c++/13635, c++/13683, c++/13714, c++/13813, c++/13854, c++/13883, c++/13907, c++/13925, c++/13927, c++/13932, c++/13950, c++/13957, c++/13968, c++/13969, c++/13970, c++/13971, c++/13975, c++/13978, c++/13997, c++/14002, c++/14028, c++/14033, c++/14083, c++/14085, c++/14086, c/14088, c/14092, c++/14108, c++/14122, c++/14173, c++/14178, c++/14181, c++/14186, c++/14199, c/456, c++/9851, c++/9941, debug/12934, fortran/14129, inline-asm/6162, java/13824, libstdc++/11352, libstdc++/13731, libstdc++/13858, libstdc++/13976, libstdc++/14026, libstdc++/14071, libstdc++/14072, libstdc++/14078, libstdc++/14097, libstdc++/14098, libstdc++/5625, middle-end/13696, middle-end/13750, optimization/12147, optimization/13424, optimization/14119, other/10584, pch/13361, 13485, preprocessor/14103, preprocessor/14198, target/11475, target/12476, target/12898, target/12978, target/13721, target/13866, target/13914, target/14113, target/14201, target/1532 - avoid trailing space in instructions - ppc64 Java fixes (Alan Modra) - use push/pop in prologues/epilogues on P4 (Jan Hubicka) - avoid more than 4 jumps per cacheline on P4 (Jan Hubicka) * Thu Jan 29 2004 Jakub Jelinek 3.4.0-0.3 - update from gcc-3_4-branch - PRs target/7297, target/10904, target/13058, optimization/13567, target/13666, bootstrap/13853, target/13674, opt/12941, c/13814 - profiledbootstrap on IA-32/AMD64 - include libgcov.a - fix IA-32/AMD64 string operations (PR optimization/13424) kdebase-3.2.0-1.8 ----------------- * Sun Feb 22 2004 Than Ngo 3.2.0-1.8 - cleanup startkde - adapt a patch file to allow different icon size in kicker menu openoffice.org-1.1.0-28 ----------------------- * Thu Feb 19 2004 Dan Williams 1.1.0-28 - Flip symbol generation to do full symbols, enabling much more useful debuginfo RPMs php-4.3.4-10 ------------ * Wed Feb 18 2004 Joe Orton 4.3.4-10 - eliminate /usr/local/lib RPATH in odbc.so - really use system pcre library * Fri Feb 13 2004 Elliot Lee 4.3.4-9 - rebuilt * Mon Feb 02 2004 Bill Nottingham 4.3.4-8 - obsolete php-imap if we're not building it rpmdb-fedora-1.90-0.20040223 ---------------------------- From alan at redhat.com Mon Feb 23 17:46:10 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Feb 2004 12:46:10 -0500 Subject: chown xxx.yyy is now rejected In-Reply-To: <20040223121416.GK6654@redhat.com> References: <20040223121416.GK6654@redhat.com> Message-ID: <20040223174610.GB23075@devserv.devel.redhat.com> On Mon, Feb 23, 2004 at 12:14:16PM +0000, Tim Waugh wrote: > The 'chown xxx.yyy' syntax has been deprecated for several releases > now, the correct syntax being 'chown xxx:yyy'. Doesn't this add a new restriction about ":" in usernames ? From ivg2 at cornell.edu Mon Feb 23 19:30:16 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 23 Feb 2004 14:30:16 -0500 Subject: Athlon Incompatible Packages Message-ID: <403A54C8.3010701@cornell.edu> Is there any reason why those packages restrict arch to 386 and are not compatible with athlon, or is that a bug? I'd like to be able to rebuild them. Would you like me to file a bugzilla on each one? acpid-1.0.2-6.src.rpm dietlibc-0.24-3.src.rpm epiphany-1.0.7-1.src.rpm fedora-release-1.90-11.src.rpm festival-1.4.2-20.src.rpm gaim-0.75-2.1.0.src.rpm grub-0.94-2.src.rpm libunwind-0.96-2.src.rpm ltrace-0.3.29-2.src.rpm memtest86-3.0-4.src.rpm mkbootdisk-1.5.1-1.src.rpm mozilla-1.6-1.src.rpm openCryptoki-2.1.3-3.src.rpm prelink-0.3.0-21.src.rpm redhat-lsb-1.3-1.src.rpm reiserfs-utils-3.6.11-2.src.rpm syslinux-2.08-2.src.rpm system-config-boot-0.2.1-1.1.src.rpm system-config-netboot-0.1.3-2.1.src.rpm From twaugh at redhat.com Mon Feb 23 19:54:48 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 23 Feb 2004 19:54:48 +0000 Subject: chown xxx.yyy is now rejected In-Reply-To: <20040223174610.GB23075@devserv.devel.redhat.com> References: <20040223121416.GK6654@redhat.com> <20040223174610.GB23075@devserv.devel.redhat.com> Message-ID: <20040223195448.GW6654@redhat.com> On Mon, Feb 23, 2004 at 12:46:10PM -0500, Alan Cox wrote: > On Mon, Feb 23, 2004 at 12:14:16PM +0000, Tim Waugh wrote: > > The 'chown xxx.yyy' syntax has been deprecated for several releases > > now, the correct syntax being 'chown xxx:yyy'. > > Doesn't this add a new restriction about ":" in usernames ? New since when exactly? When have ':' in usernames worked? SuS says: "The colon character was chosen as the replacement for the period character because it would never be allowed as a character in a user name or group name on historical implementations." Anyway, it turns out that the LSB still requires '.' to work, so (unless they change their minds before 2.0 is released) Fedora Core 2 will ship with a chown that still accepts '.' after all. Tim. */ -------------- 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 Mon Feb 23 19:56:27 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 23 Feb 2004 14:56:27 -0500 (EST) Subject: chown xxx.yyy is now rejected In-Reply-To: <20040223174610.GB23075@devserv.devel.redhat.com> References: <20040223121416.GK6654@redhat.com> <20040223174610.GB23075@devserv.devel.redhat.com> Message-ID: On Mon, 23 Feb 2004, Alan Cox wrote: >Date: Mon, 23 Feb 2004 12:46:10 -0500 >From: Alan Cox >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: Development discussions related to Fedora Core > >Subject: Re: chown xxx.yyy is now rejected > >On Mon, Feb 23, 2004 at 12:14:16PM +0000, Tim Waugh wrote: >> The 'chown xxx.yyy' syntax has been deprecated for several releases >> now, the correct syntax being 'chown xxx:yyy'. > >Doesn't this add a new restriction about ":" in usernames ? I want to use the greek letter pi in usernames personally. Also, the artist formerly known as "Prince" who I believe is now once again known as "Prince", might have wanted to have an account created using his interim name, of which I'll refer to as for my lack of knowledge of where that resides in Unicode. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alan at redhat.com Mon Feb 23 21:12:46 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Feb 2004 16:12:46 -0500 Subject: chown xxx.yyy is now rejected In-Reply-To: <20040223195448.GW6654@redhat.com> References: <20040223121416.GK6654@redhat.com> <20040223174610.GB23075@devserv.devel.redhat.com> <20040223195448.GW6654@redhat.com> Message-ID: <20040223211246.GA31346@devserv.devel.redhat.com> On Mon, Feb 23, 2004 at 07:54:48PM +0000, Tim Waugh wrote: > > Doesn't this add a new restriction about ":" in usernames ? > New since when exactly? When have ':' in usernames worked? Should work for non passwd format databases, but you are right, it breaks all sorts of stuff From alan at redhat.com Mon Feb 23 21:13:14 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Feb 2004 16:13:14 -0500 Subject: chown xxx.yyy is now rejected In-Reply-To: References: <20040223121416.GK6654@redhat.com> <20040223174610.GB23075@devserv.devel.redhat.com> Message-ID: <20040223211314.GB31346@devserv.devel.redhat.com> On Mon, Feb 23, 2004 at 02:56:27PM -0500, Mike A. Harris wrote: > I want to use the greek letter pi in usernames personally. This works correctly. Try it.. From timh at contentspace.demon.co.uk Mon Feb 23 23:19:10 2004 From: timh at contentspace.demon.co.uk (Tim Hawkins) Date: Mon, 23 Feb 2004 23:19:10 +0000 Subject: Bizzare FC2 test 1 networking issue Message-ID: <403A8A6E.9020002@contentspace.demon.co.uk> I have a DSL line terminated with a Netgear DG814 ADSL router/modem, which is then connected to my internal network . Im testing FC2 test1 on a Sharp PC-FS2518 laptop, that has a Socket Compact Flash Network Card in it. Everytime I boot the laptop, the Netgear router siezes up and stops routing, requiring a hard reset, once reset it is fine, and does not cause any problems, something during the FC2 boot is sending a network packet that kills the Router, FC1 on the same hardware does not do the same thing. Anybody seen the same behaviour. I have another FC1 box on the net, so if nobody has seen this before, I'll see if I can capture an ethereal trace of the startup. From alan at redhat.com Tue Feb 24 00:21:53 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Feb 2004 19:21:53 -0500 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <403A8A6E.9020002@contentspace.demon.co.uk> References: <403A8A6E.9020002@contentspace.demon.co.uk> Message-ID: <20040224002153.GA22995@devserv.devel.redhat.com> On Mon, Feb 23, 2004 at 11:19:10PM +0000, Tim Hawkins wrote: > I have another FC1 box on the net, so if nobody has seen this before, > I'll see if I can capture an ethereal trace of the startup. I'd really like to see a trace of this yes (as I suspect would the router vendor, bugtraq and some other people.. 8)) From dr at cluenet.de Tue Feb 24 01:38:04 2004 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 24 Feb 2004 02:38:04 +0100 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <403A8A6E.9020002@contentspace.demon.co.uk>; from timh@contentspace.demon.co.uk on Mon, Feb 23, 2004 at 11:19:10PM +0000 References: <403A8A6E.9020002@contentspace.demon.co.uk> Message-ID: <20040224023804.A28147@homebase.cluenet.de> On Mon, Feb 23, 2004 at 11:19:10PM +0000, Tim Hawkins wrote: > I have another FC1 box on the net, so if nobody has seen this before, > I'll see if I can capture an ethereal trace of the startup. Yes, a trace would be most interesting... Try to isolate the killer packet (if it's a single one). Best regards, Daniel From cra at WPI.EDU Tue Feb 24 02:03:51 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 23 Feb 2004 21:03:51 -0500 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <1077537354.11992.12.camel@localhost.localdomain> References: <1076957661.27602.27.camel@localhost.localdomain> <1077537354.11992.12.camel@localhost.localdomain> Message-ID: <20040224020351.GG27458@angus.ind.WPI.EDU> On Mon, Feb 23, 2004 at 12:55:54PM +0100, Tony Grant wrote: > My question : what is wrong with "mount -o loop initrd-2.6.3.img > /mnt/tmp" ? I am asked for a file system type and... well none are > recognised. You are asking this on the wrong mailing list. fedora-list or is the correct place for this. initrd's are gzipped, despite the missing .gz extension, so you need to gunzip it first. From daly at rio.sci.ccny.cuny.edu Tue Feb 24 01:38:58 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 23 Feb 2004 20:38:58 -0500 Subject: anybody notice fetchmail in daemon/poll mode doesn't seem to work? In-Reply-To: <20040223052716.GA12109@mark.mielke.cc> (message from Mark Mielke on Mon, 23 Feb 2004 00:27:16 -0500) References: <20040223052716.GA12109@mark.mielke.cc> Message-ID: <200402240138.UAA18713@springbok.sci.ccny.cuny.edu> > A few weeks ago, I updated fetchmail to devel-list, and ever since, my > fetchmail configuration no longer functions properly in daemon mode. This is probably off-topic for this list as it is likely a problem in fetchmail rather than an FC2 problem. I have seen similar behavior with fetchmail. The problem started when the partition filled up. Freeing up space on the partition did not solve the problem. Fetchmail was in a partial state that was not recovered by restart. It appears that it read some of the waiting POP mail but not all. Then it wouldn't re-read the mail. The solution was to telnet to port 110 at my POP host and dele the mail. Fetchmail is then restarted and works fine. Tim Daly axiom at tenkan.org daly at idsi.net From nathan at silverorange.com Tue Feb 24 03:47:57 2004 From: nathan at silverorange.com (Nathan Fredrickson) Date: Mon, 23 Feb 2004 22:47:57 -0500 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <403A8A6E.9020002@contentspace.demon.co.uk> References: <403A8A6E.9020002@contentspace.demon.co.uk> Message-ID: <1077594476.4708.278.camel@rocky> On Mon, 2004-02-23 at 18:19, Tim Hawkins wrote: > Everytime I boot the laptop, the Netgear router siezes up and stops > routing, requiring a hard reset, once reset it is fine, and does not > cause any problems, something during the FC2 boot is sending a network > packet that kills the Router, FC1 on the same hardware does not do the > same thing. Have you tried with ECN disabled? I have a netgear router that doesn't work with ECN... but mine doesn't freeze. ECN was enabled by default in FC2 and it took me awhile to figure out why only TCP was broken on my FC2 system. Disable ECN by running: echo 0 > /proc/sys/net/ipv4/tcp_ecn From jwboyer at charter.net Tue Feb 24 04:17:01 2004 From: jwboyer at charter.net (Josh Boyer) Date: Mon, 23 Feb 2004 22:17:01 -0600 Subject: yum ignore? Message-ID: <200402232217.01779.jwboyer@charter.net> Is there a way to tell yum to ignore specific packages when doing an update? I am thinking something like: yum update --ignore foo* which would be the equivalent of unchecking a package in the up2date GUI. This would be useful when there are lots of updates available, but one or two have dependencies that can't be resolved. Didn't see anything in the man page though... josh From skvidal at phy.duke.edu Tue Feb 24 04:23:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 23 Feb 2004 23:23:40 -0500 Subject: yum ignore? In-Reply-To: <200402232217.01779.jwboyer@charter.net> References: <200402232217.01779.jwboyer@charter.net> Message-ID: <1077596620.2323.6.camel@binkley> > Is there a way to tell yum to ignore specific packages when doing an update? > I am thinking something like: > > yum update --ignore foo* > > which would be the equivalent of unchecking a package in the up2date GUI. > > This would be useful when there are lots of updates available, but one or two > have dependencies that can't be resolved. Didn't see anything in the man > page though... > Hi, If you want to get me to notice a mail, don't cc me directly on the message. That will just really annoy me. go read yum list messages or my blog for the last day or so - I just added some functionality to that effect. -sv From warren at togami.com Tue Feb 24 04:55:02 2004 From: warren at togami.com (Warren Togami) Date: Mon, 23 Feb 2004 18:55:02 -1000 (HST) Subject: Athlon Incompatible Packages In-Reply-To: <403A54C8.3010701@cornell.edu> References: <403A54C8.3010701@cornell.edu> Message-ID: <1298.66.91.85.198.1077598502.squirrel@togami.com> > Is there any reason why those packages restrict arch to 386 and are not > compatible with athlon, or is that a bug? I'd like to be able to rebuild > them. Would you like me to file a bugzilla on each one? > > acpid-1.0.2-6.src.rpm > dietlibc-0.24-3.src.rpm > epiphany-1.0.7-1.src.rpm > fedora-release-1.90-11.src.rpm > festival-1.4.2-20.src.rpm > gaim-0.75-2.1.0.src.rpm > grub-0.94-2.src.rpm > libunwind-0.96-2.src.rpm > ltrace-0.3.29-2.src.rpm > memtest86-3.0-4.src.rpm > mkbootdisk-1.5.1-1.src.rpm > mozilla-1.6-1.src.rpm > openCryptoki-2.1.3-3.src.rpm > prelink-0.3.0-21.src.rpm > redhat-lsb-1.3-1.src.rpm > reiserfs-utils-3.6.11-2.src.rpm > syslinux-2.08-2.src.rpm > system-config-boot-0.2.1-1.1.src.rpm > system-config-netboot-0.1.3-2.1.src.rpm This has been repeated many times in the past. The vast majority of software have zero or negligible performance benefit from compiling to athlon. The compiler flags used to build all packages are already set for i686 optimization. Generally it is a very inefficient use of time to rebuild packages for your specific arch as it takes far more time to do so than any speed benefit you will gain. This being said however, nothing stops you from taking the SRPMS and doing what you wish to them. You have the freedom of choice with Open Source. I would suggest against reporting this kind of "problem" to Bugzilla as there are already thousands real issues there that are actual problems. Warren From ivg2 at cornell.edu Tue Feb 24 05:09:01 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 24 Feb 2004 00:09:01 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <1298.66.91.85.198.1077598502.squirrel@togami.com> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> Message-ID: <403ADC6D.3050906@cornell.edu> > This has been repeated many times in the past. The vast majority of > software have zero or negligible performance benefit from compiling to > athlon. The compiler flags used to build all packages are already set for > i686 optimization. Generally it is a very inefficient use of time to > rebuild packages for your specific arch as it takes far more time to do so > than any speed benefit you will gain. This being said however, nothing > stops you from taking the SRPMS and doing what you wish to them. You have > the freedom of choice with Open Source. > > I would suggest against reporting this kind of "problem" to Bugzilla as > there are already thousands real issues there that are actual problems. I think you're avoiding my question, which is whether this is a bug or not. It seems to me though, that this is a bug... and all bugs have to be fixed, correct? As far as the real issues go, I'll get to those too... - I have 67 additional packages that will not build on fedora. From tdiehl at rogueind.com Tue Feb 24 05:23:12 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 24 Feb 2004 00:23:12 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <403ADC6D.3050906@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> Message-ID: On Tue, 24 Feb 2004, Ivan Gyurdiev wrote: > > > This has been repeated many times in the past. The vast majority of > > software have zero or negligible performance benefit from compiling to > > athlon. The compiler flags used to build all packages are already set for > > i686 optimization. Generally it is a very inefficient use of time to > > rebuild packages for your specific arch as it takes far more time to do so > > than any speed benefit you will gain. This being said however, nothing > > stops you from taking the SRPMS and doing what you wish to them. You have > > the freedom of choice with Open Source. > > > > I would suggest against reporting this kind of "problem" to Bugzilla as > > there are already thousands real issues there that are actual problems. > > I think you're avoiding my question, which is whether this is a bug or > not. It seems to me though, that this is a bug... and all bugs have to > be fixed, correct? As far as the real issues go, I'll get to those > too... - I have 67 additional packages that will not build on fedora. Why would you think it was a bug? AFAIK, it is done on purpose. As you quoted above there are no signifigant performance gains to be realized by doing that and it would be a lot of work to do that and maintain it. IOW the cure is worse than the disease. Tom From cra at WPI.EDU Tue Feb 24 05:24:35 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 24 Feb 2004 00:24:35 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <403ADC6D.3050906@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> Message-ID: <20040224052435.GI27458@angus.ind.WPI.EDU> On Tue, Feb 24, 2004 at 12:09:01AM -0500, Ivan Gyurdiev wrote: > I think you're avoiding my question, which is whether this is a bug or > not. It seems to me though, that this is a bug... and all bugs have to > be fixed, correct? As far as the real issues go, I'll get to those > too... - I have 67 additional packages that will not build on fedora. It is not a bug. rpmbuild --rebuild --target=i386. From ivg2 at cornell.edu Tue Feb 24 05:30:17 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 24 Feb 2004 00:30:17 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <20040224052435.GI27458@angus.ind.WPI.EDU> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> Message-ID: <403AE169.3040300@cornell.edu> Charles R. Anderson wrote: > On Tue, Feb 24, 2004 at 12:09:01AM -0500, Ivan Gyurdiev wrote: > >>I think you're avoiding my question, which is whether this is a bug or >>not. It seems to me though, that this is a bug... and all bugs have to >>be fixed, correct? As far as the real issues go, I'll get to those >>too... - I have 67 additional packages that will not build on fedora. > > > It is not a bug. rpmbuild --rebuild --target=i386. But shouldn't the athlon arch be compatible with 386? In which case shouldn't the packages also allow athlon? Excuse my total ignorance on this... If in fact, the packages in question will not work correctly on athlon, and fedora is unwilling to support athlon, then I can see how this is not a bug. From 64bit_fedora at comcast.net Tue Feb 24 05:38:13 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Mon, 23 Feb 2004 23:38:13 -0600 Subject: Athlon Incompatible Packages In-Reply-To: <403A54C8.3010701@cornell.edu> References: <403A54C8.3010701@cornell.edu> Message-ID: <20040224053813.GA27005@comcast.net> On Mon, Feb 23, 2004 at 02:30:16PM -0500, Ivan Gyurdiev wrote: > Is there any reason why those packages restrict arch to 386 and are not > compatible with athlon, or is that a bug? I'd like to be able to rebuild > them. Would you like me to file a bugzilla on each one? > Seems to me that this is not a bug, but an intentional decision. Either way, outside of the fact that any efficiencies you got from the recompile would probably never make up the number of CPU cycles required for the build, you obviously have a special interest, which is outside of the intended purpose of said SRPMS. That is great, just add the arch to the spec file, and rebuild. IF for some reason they wont build, it may merit further discussion, but if all we are talking about is a spec file change, it would take you much less time to make the change, than it would to file the bug, and since it is fairly unlikely that most users would be interested in doing such a rebuild themselves, it is work that would not be repeated too often. Developers can focus on things which have more of an impact to users. Justin From 64bit_fedora at comcast.net Tue Feb 24 05:40:24 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Mon, 23 Feb 2004 23:40:24 -0600 Subject: Athlon Incompatible Packages In-Reply-To: <403AE169.3040300@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> Message-ID: <20040224054024.GB27005@comcast.net> On Tue, Feb 24, 2004 at 12:30:17AM -0500, Ivan Gyurdiev wrote: > > But shouldn't the athlon arch be compatible with 386? > In which case shouldn't the packages also allow athlon? > Excuse my total ignorance on this... If in fact, the packages in > question will not work correctly on athlon, and fedora is unwilling to > support athlon, then I can see how this is not a bug. > In fact the athlon arch is not compatible with i386, however i386 IS compatible with athlon. IE a build which is optimized for athlon can actually contain features that i386 cannot support, but the reverse should not be true. Justin From ivg2 at cornell.edu Tue Feb 24 05:53:13 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 24 Feb 2004 00:53:13 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <20040224053813.GA27005@comcast.net> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> Message-ID: <403AE6C9.5070201@cornell.edu> > Seems to me that this is not a bug, but an intentional decision. Either > way, outside of the fact that any efficiencies you got from the recompile > would probably never make up the number of CPU cycles required for the > build, Why do gentoo users make such a huge deal out of this? > you obviously have a special interest, which is outside of the > intended purpose of said SRPMS. That is great, just add the arch to the > spec file, and rebuild. IF for some reason they wont build, it may merit > further discussion, but if all we are talking about is a spec file change, > it would take you much less time to make the change, than it would to file > the bug, and since it is fairly unlikely that most users would be > interested in doing such a rebuild themselves, it is work that would not be > repeated too often. Developers can focus on things which have more of an > impact to users. Would you be interested in adding the athlon arch if everything builds correctly? I can check all those packages. Basically, I am interested to know whether the packages in question really do *require* i386 and i386 only to work correctly, or whether simply nobody has checked (or cares) whether this will work when compiled for athlon... From tdiehl at rogueind.com Tue Feb 24 05:55:26 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 24 Feb 2004 00:55:26 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <403AE169.3040300@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> Message-ID: On Tue, 24 Feb 2004, Ivan Gyurdiev wrote: > Charles R. Anderson wrote: > > On Tue, Feb 24, 2004 at 12:09:01AM -0500, Ivan Gyurdiev wrote: > > > >>I think you're avoiding my question, which is whether this is a bug or > >>not. It seems to me though, that this is a bug... and all bugs have to > >>be fixed, correct? As far as the real issues go, I'll get to those > >>too... - I have 67 additional packages that will not build on fedora. > > > > > > It is not a bug. rpmbuild --rebuild --target=i386. > > But shouldn't the athlon arch be compatible with 386? > In which case shouldn't the packages also allow athlon? > Excuse my total ignorance on this... If in fact, the packages in > question will not work correctly on athlon, and fedora is unwilling to > support athlon, then I can see how this is not a bug. Who said they would not work?? I am writing this on an athlon system and I recompiled nothing. They work just fine. Tom From tdiehl at rogueind.com Tue Feb 24 06:03:44 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 24 Feb 2004 01:03:44 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <403AE6C9.5070201@cornell.edu> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <403AE6C9.5070201@cornell.edu> Message-ID: On Tue, 24 Feb 2004, Ivan Gyurdiev wrote: > > Seems to me that this is not a bug, but an intentional decision. Either > > way, outside of the fact that any efficiencies you got from the recompile > > would probably never make up the number of CPU cycles required for the > > build, > > Why do gentoo users make such a huge deal out of this? I don't know, maybe they have too much free time on their hands?? ;) > > you obviously have a special interest, which is outside of the > > intended purpose of said SRPMS. That is great, just add the arch to the > > spec file, and rebuild. IF for some reason they wont build, it may merit > > further discussion, but if all we are talking about is a spec file change, > > it would take you much less time to make the change, than it would to file > > the bug, and since it is fairly unlikely that most users would be > > interested in doing such a rebuild themselves, it is work that would not be > > repeated too often. Developers can focus on things which have more of an > > impact to users. > > Would you be interested in adding the athlon arch if everything builds > correctly? I can check all those packages. Basically, I am interested to > know whether the packages in question really do *require* i386 and i386 > only to work correctly, or whether simply nobody has checked (or cares) > whether this will work when compiled for athlon... For the 3rd time IT IS NOT WORTH THE EFFORT. The packages that can see significant performance gains by compiling for Athlon are already available. The rest are compiled with i686 optimizations and that is good enough. Look at the kernel packages for instance. You have an Athlon kernel available. HTH, Tom From 64bit_fedora at comcast.net Tue Feb 24 06:19:37 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Tue, 24 Feb 2004 00:19:37 -0600 Subject: Athlon Incompatible Packages In-Reply-To: <403AE6C9.5070201@cornell.edu> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <403AE6C9.5070201@cornell.edu> Message-ID: <20040224061937.GC27005@comcast.net> On Tue, Feb 24, 2004 at 12:53:13AM -0500, Ivan Gyurdiev wrote: > > Why do gentoo users make such a huge deal out of this? > Most simply put, because they can. It is a geek thing, actually I like the concept as an excercise... But beyond that, the amount of time for arch specific builds is extensive and performance is actually worse in some cases... > Would you be interested in adding the athlon arch if everything builds > correctly? I can check all those packages. Basically, I am interested to > know whether the packages in question really do *require* i386 and i386 > only to work correctly, or whether simply nobody has checked (or cares) > whether this will work when compiled for athlon... > Personally I would have no interested in adding the arch, in all honesty, I would be very surprised if it made any difference at all in ability to build. It would take a rather specific bug in the code to trigger an athlon only error for build. All of the listed packages should build just fine. I am sure if a package maintainer were interested, they would add it. There is a big difference between adding the x86 equivs and some other arch. The former generally works... the later can break at times. Justin From tony at tgds.net Tue Feb 24 06:23:04 2004 From: tony at tgds.net (Tony Grant) Date: Tue, 24 Feb 2004 07:23:04 +0100 Subject: ongoing quest for vmware on Fedora Core 1 with 2.6.1 kernel In-Reply-To: <1076966823.27602.33.camel@localhost.localdomain> References: <1076957661.27602.27.camel@localhost.localdomain> <4031215E.7030500@redhat.com> <1076966823.27602.33.camel@localhost.localdomain> Message-ID: <1077603783.8914.15.camel@localhost.localdomain> Le lun 16/02/2004 ? 22:27, Tony Grant a ?crit : > > >>Do not use Fedora's prebuilt kernels with 3.2.1 > ^^^^^ > > I have total success running vmware workstation 4.0.5 within latest FC2 > > after using vmware-any-any-update50. > > vmware 4x does not run on the Epia-M CPU. That is why I run 3.2.1 which > works just fine for my daily needs. > > I stopped working after 2.6.0xxx series kernels. > What happened to /dev/mem between 2.6.0 and 2.6.1? This question went unanswered. But I have managed to compile my first 2.6 series kernel! 2.6.3 from kernel.org running on Fedora Core 1 _DOES WORK_ with VMware 3.2.1. The kernels in "testing" do not work. What is the problem? Tony Grant -- www.tgds.net Library management software toolkit From dennis at ausil.us Tue Feb 24 06:50:20 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 24 Feb 2004 16:50:20 +1000 Subject: Testers Required for Next Generation Input Method In-Reply-To: <1077373638.13557.2.camel@bushido.mshome.net> References: <1077373638.13557.2.camel@bushido.mshome.net> Message-ID: <200402241650.30253.dennis@ausil.us> Once upon a time Sunday 22 February 2004 12:27 am, Michel Alexandre Salim wrote: > On Sat, 2004-02-21 at 22:06 +1000, Leon Ho wrote: > > URLs are: > > > > Full invitation letter: > > http://apac.redhat.com/iiimftest/ > > Pity I can't write in any East Asian multibyte languages, but I'll try > and get some people I know to go over it. > > Where is Red Hat APAC based, incidentally? Singapore, Malaysia, RoC? > > - Michel Red Hats Asia Pacific base is Brisbane Australia. with oter offices around the region. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From paul at gear.dyndns.org Tue Feb 24 08:02:56 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 24 Feb 2004 18:02:56 +1000 Subject: Compiling iteraid driver for use at installation Message-ID: <403B0530.1080107@gear.dyndns.org> Hi folks, I've asked this on fedora-list, with no response, so please have pity on me for asking it here... :-) I'm trying to upgrade from Red Hat Linux 9 to Fedora Core 1 on my Gigabyte GA-7N400Pro motherboard. I'm using RAID 1 under the iteraid driver at present, and i need to make a module that i can load from floppy during installation (before anaconda searches for installations to upgrade). I'm compiling iteraid from the source at http://www.ite.com.tw/pc/LinuxSrc_it8212_092005-05.zip, but i keep running into one of two problems: 1. The module symbol versioning kicks in and complains of unresolved symbols (e.g. register_chrdev_R91ec41d1, scsi_register_Rc18333384). 2. I've tried to configure my kernel on another box to support compiling modules without symbol versioning, and i get kernel version mismatches (due to the "custom" on the end of the EXTRAVERSION). So my questions are: - If i install FC1 on a non-RAID hard disk in the same system, the iteraid driver i built from a running system works fine. So there must be something different about the installer kernel and the runtime kernel. What is it? - If i assuming rightly that the installation kernel doesn't use kernel versioning, how can i compile a module that will make the module correctly for use in the installer? I've gone through the "make mrproper, make config, make dep, make" routine on the default kernel, and i've come up with the same result. - If that is not likely the problem, is there another way i can get my system upgraded? I've heard yum can actually do OS upgrades - is this possible for going from RHL9 to FC1? Thanks in advance, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From czar at czarc.net Tue Feb 24 08:33:49 2004 From: czar at czarc.net (Gene C.) Date: Tue, 24 Feb 2004 03:33:49 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <403A54C8.3010701@cornell.edu> References: <403A54C8.3010701@cornell.edu> Message-ID: <200402240333.49339.czar@czarc.net> On Monday 23 February 2004 14:30, Ivan Gyurdiev wrote: > Is there any reason why those packages restrict arch to 386 and are not > compatible with athlon, or is that a bug? I'd like to be able to rebuild > them. Would you like me to file a bugzilla on each one? > > acpid-1.0.2-6.src.rpm > dietlibc-0.24-3.src.rpm > epiphany-1.0.7-1.src.rpm > fedora-release-1.90-11.src.rpm > festival-1.4.2-20.src.rpm > gaim-0.75-2.1.0.src.rpm > grub-0.94-2.src.rpm > libunwind-0.96-2.src.rpm > ltrace-0.3.29-2.src.rpm > memtest86-3.0-4.src.rpm > mkbootdisk-1.5.1-1.src.rpm > mozilla-1.6-1.src.rpm > openCryptoki-2.1.3-3.src.rpm > prelink-0.3.0-21.src.rpm > redhat-lsb-1.3-1.src.rpm > reiserfs-utils-3.6.11-2.src.rpm > syslinux-2.08-2.src.rpm > system-config-boot-0.2.1-1.1.src.rpm > system-config-netboot-0.1.3-2.1.src.rpm A good reason to restrict the package to i386 (besides the reasons that many other have cited) is that at least one of these packages (grub) contains i386 assembler code ... it will not build on a x86_64 target for example. -- Gene From thomas at apestaart.org Tue Feb 24 08:32:01 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 24 Feb 2004 09:32:01 +0100 Subject: Athlon Incompatible Packages In-Reply-To: <403AE169.3040300@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> Message-ID: <1077611513.4617.8.camel@otto.amantes> On Tue, 2004-02-24 at 06:30, Ivan Gyurdiev wrote: > Charles R. Anderson wrote: > > On Tue, Feb 24, 2004 at 12:09:01AM -0500, Ivan Gyurdiev wrote: > > > >>I think you're avoiding my question, which is whether this is a bug or > >>not. It seems to me though, that this is a bug... and all bugs have to > >>be fixed, correct? As far as the real issues go, I'll get to those > >>too... - I have 67 additional packages that will not build on fedora. > > > > > > It is not a bug. rpmbuild --rebuild --target=i386. > > But shouldn't the athlon arch be compatible with 386? > In which case shouldn't the packages also allow athlon? > Excuse my total ignorance on this... If in fact, the packages in > question will not work correctly on athlon, and fedora is unwilling to > support athlon, then I can see how this is not a bug. It's not a bug because Red Hat doesn't consider "you should be able to rebuild any package as you wish" as a feature. They provide binary RPMS so you can install the actual distro easily, and source RPMS because they sort of have to but also because they want you to be able to look at how the binaries are made. What they, AFAIK, have never done, is told us to rebuild src.rpm's for different architectures if we feel like it. IIRC they actually never advertise to rebuild their src.rpm's as they are. So, if you want to follow through your reasoning on the matter, it is in fact not a bug, because "being able to rebuild any package on any arch" is not a feature. All the packages already work very well on athlon ! Anyways, beside the fact that we just established it really is not a bug, it really doesn't help to rebuild those packages for athlon. What do you actually want to achieve ? If you really want a completely rebuilt system, install gentoo, not Red Hat/Fedora. As soon as you install a complete set of rebuilt packages anyway, you won't have a Red Hat/Fedora system anymore anyway. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I've got ladyfingers baby I've got kidgloves baby I got heart <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From timh at contentspace.demon.co.uk Tue Feb 24 09:05:46 2004 From: timh at contentspace.demon.co.uk (Tim Hawkins) Date: Tue, 24 Feb 2004 09:05:46 +0000 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <1077594476.4708.278.camel@rocky> References: <403A8A6E.9020002@contentspace.demon.co.uk> <1077594476.4708.278.camel@rocky> Message-ID: <403B13EA.4000606@contentspace.demon.co.uk> Nathan Fredrickson wrote: >On Mon, 2004-02-23 at 18:19, Tim Hawkins wrote: > > >>Everytime I boot the laptop, the Netgear router siezes up and stops >>routing, requiring a hard reset, once reset it is fine, and does not >>cause any problems, something during the FC2 boot is sending a network >>packet that kills the Router, FC1 on the same hardware does not do the >>same thing. >> >> > >Have you tried with ECN disabled? I have a netgear router that doesn't >work with ECN... but mine doesn't freeze. ECN was enabled by default in >FC2 and it took me awhile to figure out why only TCP was broken on my >FC2 system. Disable ECN by running: > >echo 0 > /proc/sys/net/ipv4/tcp_ecn > > > > > > Is that a permement change Nathan, or will I have to put that into the rc scripts to ensure its disabled on boot? From alan at redhat.com Tue Feb 24 09:24:01 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 24 Feb 2004 04:24:01 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <403AE6C9.5070201@cornell.edu> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <403AE6C9.5070201@cornell.edu> Message-ID: <20040224092401.GC6462@devserv.devel.redhat.com> On Tue, Feb 24, 2004 at 12:53:13AM -0500, Ivan Gyurdiev wrote: > >Seems to me that this is not a bug, but an intentional decision. Either > >way, outside of the fact that any efficiencies you got from the recompile > >would probably never make up the number of CPU cycles required for the > >build, > > Why do gentoo users make such a huge deal out of this? Because their systems are so busy building open office 24 hours a day they don't do serious benchmarking ? From a compiler point of view there isnt really a lot of difference between optimising for 686 and optimising for 686 using 686 only instructions. It primarily effects "cmov". On the kernel side its a bit different, as with glibc internals. The thing that makes the difference on many setups I've tried is -Os (optimise for size not speed) From paul at gear.dyndns.org Tue Feb 24 09:55:49 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 24 Feb 2004 19:55:49 +1000 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <403B13EA.4000606@contentspace.demon.co.uk> References: <403A8A6E.9020002@contentspace.demon.co.uk> <1077594476.4708.278.camel@rocky> <403B13EA.4000606@contentspace.demon.co.uk> Message-ID: <403B1FA5.1070309@gear.dyndns.org> Tim Hawkins wrote: > ... >> Have you tried with ECN disabled? I have a netgear router that doesn't >> work with ECN... but mine doesn't freeze. ECN was enabled by default in >> FC2 and it took me awhile to figure out why only TCP was broken on my >> FC2 system. Disable ECN by running: >> >> echo 0 > /proc/sys/net/ipv4/tcp_ecn >> ... >> > Is that a permement change Nathan, or will I have to put that into the > rc scripts to ensure its disabled on boot? To make those changes permanent, put a corresponding entry in /etc/sysctl.conf. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From NOS at Utel.no Tue Feb 24 10:08:44 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Tue, 24 Feb 2004 11:08:44 +0100 Subject: Athlon Incompatible Packages In-Reply-To: <000001c3fa9b$7d204e90$14aaa8c0@utelsystems.local> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <000001c3fa9b$7d204e90$14aaa8c0@utelsystems.local> Message-ID: <1077617324.19430.22.camel@localhost.localdomain> On Tue, 2004-02-24 at 07:00, Ivan Gyurdiev wrote: > > Seems to me that this is not a bug, but an intentional decision. Either > > way, outside of the fact that any efficiencies you got from the recompile > > would probably never make up the number of CPU cycles required for the > > build, > > Why do gentoo users make such a huge deal out of this? Do they have any _real_ benchmark telling the diffrence ? Note that comparing say FC1 directly with an optimized Gentoo is not a real benchmark, its probably not the same kernel with the same features. Diffrent version of lots-of-things. It's also interresting to find where the diffrence is. e.g. Gentoo have some kernel features enabled which is what makes the diffrence, you cannot say optimizing everything is what made Evolution a bit quicker. Or comparing a grep that's dog slow cause the user local is UTF-8 vs a locale of C.. Also beware of the placebo effect. Tell a user that this'n'that is much better/faster, and he thinks so. -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From warren at togami.com Tue Feb 24 10:13:54 2004 From: warren at togami.com (Warren Togami) Date: Tue, 24 Feb 2004 00:13:54 -1000 (HST) Subject: Athlon Incompatible Packages In-Reply-To: <1077617324.19430.22.camel@localhost.localdomain> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <000001c3fa9b$7d204e90$14aaa8c0@utelsystems.local> <1077617324.19430.22.camel@localhost.localdomain> Message-ID: <1314.66.91.85.198.1077617634.squirrel@togami.com> > On Tue, 2004-02-24 at 07:00, Ivan Gyurdiev wrote: >> > Seems to me that this is not a bug, but an intentional decision. >> Either >> > way, outside of the fact that any efficiencies you got from the >> recompile >> > would probably never make up the number of CPU cycles required for the >> > build, >> >> Why do gentoo users make such a huge deal out of this? > Do they have any _real_ benchmark telling the diffrence ? > > Note that comparing say FC1 directly with an optimized Gentoo > is not a real benchmark, its probably not the same kernel with > the same features. Diffrent version of lots-of-things. > > It's also interresting to find where the diffrence is. > e.g. Gentoo have some kernel features enabled which is what > makes the diffrence, you cannot say optimizing everything is > what made Evolution a bit quicker. > Or comparing a grep that's dog slow cause the user local is UTF-8 > vs a locale of C.. > > Also beware of the placebo effect. Tell a user that this'n'that is much > better/faster, and he thinks so. I remember reading some comparative benchmarks of gcc-2.95 and gcc-3.2.x somewhere that showed relative effects of compiling stuff for different architectures. IIRC, back during 2.95 compiling for athlon did make a large difference when compared to i386, but the gap narrowed significantly with gcc-3.2.x. So Gentoo was perhaps effective in optimization back then, but the reasons for doing so have quickly gone away. Note that I'm relying completely on my memory and I know nothing about the compiler. Warren From timh at contentspace.demon.co.uk Tue Feb 24 10:13:29 2004 From: timh at contentspace.demon.co.uk (Tim Hawkins) Date: Tue, 24 Feb 2004 10:13:29 +0000 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <403B1FA5.1070309@gear.dyndns.org> References: <403A8A6E.9020002@contentspace.demon.co.uk> <1077594476.4708.278.camel@rocky> <403B13EA.4000606@contentspace.demon.co.uk> <403B1FA5.1070309@gear.dyndns.org> Message-ID: <403B23C9.8060004@contentspace.demon.co.uk> Paul Gear wrote: >Tim Hawkins wrote: > > >>... >> >> >>>Have you tried with ECN disabled? I have a netgear router that doesn't >>>work with ECN... but mine doesn't freeze. ECN was enabled by default in >>>FC2 and it took me awhile to figure out why only TCP was broken on my >>>FC2 system. Disable ECN by running: >>> >>>echo 0 > /proc/sys/net/ipv4/tcp_ecn >>>... >>> >>> >>> >>Is that a permement change Nathan, or will I have to put that into the >>rc scripts to ensure its disabled on boot? >> >> > >To make those changes permanent, put a corresponding entry in >/etc/sysctl.conf. > > That seems to fix the problem Paul, laptop boots ok now without killing router I'll get onto Netgear and findout why tcp_ecn cause the router so much distress. Im running the latest firmware on the box, and its a very popular brand/model. From jakub at redhat.com Tue Feb 24 10:33:29 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 24 Feb 2004 05:33:29 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <1314.66.91.85.198.1077617634.squirrel@togami.com> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <000001c3fa9b$7d204e90$14aaa8c0@utelsystems.local> <1077617324.19430.22.camel@localhost.localdomain> <1314.66.91.85.198.1077617634.squirrel@togami.com> Message-ID: <20040224103329.GZ31589@devserv.devel.redhat.com> On Tue, Feb 24, 2004 at 12:13:54AM -1000, Warren Togami wrote: > I remember reading some comparative benchmarks of gcc-2.95 and gcc-3.2.x > somewhere that showed relative effects of compiling stuff for different > architectures. IIRC, back during 2.95 compiling for athlon did make a > large difference when compared to i386, but the gap narrowed significantly > with gcc-3.2.x. So Gentoo was perhaps effective in optimization back > then, but the reasons for doing so have quickly gone away. Plus Fedora is compiled (tuned) for i686, not i386 (just doesn't use i486+ only instructions, from which only cmov* is important for compiler generated code unless you use SSE2 math (the rest are just atomic instructions)). cmov is a win on some CPUs and for some programs, but is a slight lose on others, so unless you want to spend huge time not only rebuilding, but also benchmarking every single application to see what options are best, you are just wasting your time with rebuilding. Athlons generally run i686 tuned code very quickly, the differences between -mtune=i686 and -mtune=athlon will be minimal (and nothing guarantees you that for some program you actually don't loose performance with -mtune=athlon compared to -mtune=i686). Jakub From arekm at pld-linux.org Tue Feb 24 11:20:11 2004 From: arekm at pld-linux.org (Arkadiusz Miskiewicz) Date: Tue, 24 Feb 2004 12:20:11 +0100 Subject: Athlon Incompatible Packages In-Reply-To: <200402240333.49339.czar@czarc.net> References: <403A54C8.3010701@cornell.edu> <200402240333.49339.czar@czarc.net> Message-ID: <200402241220.11410.arekm@pld-linux.org> Dnia Tuesday 24 of February 2004 09:33, Gene C. napisa?: > A good reason to restrict the package to i386 (besides the reasons that > many other have cited) is that at least one of these packages (grub) > contains i386 assembler code ... it will not build on a x86_64 target for > example. -- Then restrict them to %{ix86} not i386. See rpm --showrc. > Gene -- Arkadiusz Mi?kiewicz CS at FoE, Wroclaw University of Technology arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux From jkt at redhat.com Tue Feb 24 12:36:16 2004 From: jkt at redhat.com (Jay Turner) Date: Tue, 24 Feb 2004 07:36:16 -0500 Subject: Compiling iteraid driver for use at installation In-Reply-To: <403B0530.1080107@gear.dyndns.org> References: <403B0530.1080107@gear.dyndns.org> Message-ID: <20040224123616.GY23631@redhat.com> On Tue, Feb 24, 2004 at 06:02:56PM +1000, Paul Gear wrote: > So my questions are: > > - If i install FC1 on a non-RAID hard disk in the same system, the > iteraid driver i built from a running system works fine. So there must > be something different about the installer kernel and the runtime > kernel. What is it? > > - If i assuming rightly that the installation kernel doesn't use > kernel versioning, how can i compile a module that will make the > module correctly for use in the installer? I've gone through the "make > mrproper, make config, make dep, make" routine on the default kernel, > and i've come up with the same result. > > - If that is not likely the problem, is there another way i can get my > system upgraded? I've heard yum can actually do OS upgrades - is this > possible for going from RHL9 to FC1? Have a look at the Device Driver Update Disk stuff which Doug Ledford has put together. It can be found at http://people.redhat.com/dledford. This will explain how to create a driver disk which is utilized as part of the installation process, which sounds like is just what you need. - 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 jwboyer at charter.net Tue Feb 24 12:39:55 2004 From: jwboyer at charter.net (Josh Boyer) Date: Tue, 24 Feb 2004 06:39:55 -0600 Subject: yum ignore? In-Reply-To: <1077596620.2323.6.camel@binkley> References: <200402232217.01779.jwboyer@charter.net> <1077596620.2323.6.camel@binkley> Message-ID: <200402240639.55201.jwboyer@charter.net> On Monday 23 February 2004 10:23 pm, seth vidal wrote: > If you want to get me to notice a mail, don't cc me directly on the > message. That will just really annoy me. ok, point taken. > go read yum list messages or my blog for the last day or so - I just > added some functionality to that effect. will do. thanks. josh From jkt at redhat.com Tue Feb 24 12:45:52 2004 From: jkt at redhat.com (Jay Turner) Date: Tue, 24 Feb 2004 07:45:52 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <1077611513.4617.8.camel@otto.amantes> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> Message-ID: <20040224124552.GZ23631@redhat.com> On Tue, Feb 24, 2004 at 09:32:01AM +0100, Thomas Vander Stichele wrote: > What they, AFAIK, have never done, is told us to rebuild src.rpm's for > different architectures if we feel like it. IIRC they actually never > advertise to rebuild their src.rpm's as they are. Point of order here. We do actually try our best to make sure that every SRPM which leaves the building can recompile successfully. From time to time, we hit a particularily difficult package (OpenOffice for a little while) which won't recompile, but we work to fix those issues (and OpenOffice nows compiles again.) - 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 jorton at redhat.com Tue Feb 24 13:25:50 2004 From: jorton at redhat.com (Joe Orton) Date: Tue, 24 Feb 2004 13:25:50 +0000 Subject: anybody notice fetchmail in daemon/poll mode doesn't seem to work? In-Reply-To: <20040223052716.GA12109@mark.mielke.cc> References: <20040223052716.GA12109@mark.mielke.cc> Message-ID: <20040224132550.GA26963@redhat.com> On Mon, Feb 23, 2004 at 12:27:16AM -0500, Mark Mielke wrote: > A few weeks ago, I updated fetchmail to devel-list, and ever since, my > fetchmail configuration no longer functions properly in daemon mode. > > The symptoms seem to be that when fetchmail first starts up, it goes into > the background, and fetches mail as expected, but then, once it has downloaded > all new email, it never notices new email again. I "fetchmail -q" and then > "fetchmail" before reading email as a work around. Yes, backing down to fetchmail-6.2.0-6 fixed it for me, this is the bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115474 joe From salimma at fastmail.fm Tue Feb 24 13:41:14 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Tue, 24 Feb 2004 20:41:14 +0700 Subject: Athlon Incompatible Packages In-Reply-To: References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <403AE6C9.5070201@cornell.edu> Message-ID: <1077630074.16412.18.camel@bushido.mshome.net> On Tue, 2004-02-24 at 01:03 -0500, Tom Diehl wrote: [snip] > > For the 3rd time IT IS NOT WORTH THE EFFORT. The packages that can see > significant performance gains by compiling for Athlon are already available. > The rest are compiled with i686 optimizations and that is good enough. > > Look at the kernel packages for instance. You have an Athlon kernel available. > Ehm, not anymore; 2.6 kernels are available in i386 and i686 variants only. IIRC some runtime CPU detection is being done, similar to what MPlayer does. 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 buildsys at redhat.com Tue Feb 24 14:13:43 2004 From: buildsys at redhat.com (Build System) Date: Tue, 24 Feb 2004 09:13:43 -0500 Subject: rawhide report: 20040224 changes Message-ID: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> New package tomcat Java Servlet container Updated Packages: MAKEDEV-3.3.13-1 ---------------- * Mon Feb 23 2004 Nalin Dahyabhai 3.3.13-1 - Make MAKEDEV use ":" to separate user and group names in output created when invoked with the -S flag (patch by Tim Waugh). ORBit2-2.9.8-1 -------------- * Mon Feb 23 2004 Alexander Larsson 2.9.8-1 - update to 2.9.8 anaconda-9.91-0.20040223193935 ------------------------------ * Mon Feb 23 2004 Anaconda team - built new version from CVS * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 arts-1.2.0-1.5 -------------- * Mon Feb 23 2004 Than Ngo 8:1.2.0-1.5 - add patch file from CVS, fix mcop warning - fix glib2 issue balsa-2.0.16-1 -------------- * Tue Feb 24 2004 Bill Nottingham - rebuilt * Tue Dec 23 2003 Bill Nottingham - pull in some 64-bit fixes from the mandrake package checkpolicy-1.6-1 ----------------- * Tue Feb 24 2004 Dan Walsh 1.6-1 - Upgrade to the latest from NSA coreutils-5.2.0-6 ----------------- * Mon Feb 23 2004 Tim Waugh 5.2.0-6 - Apply Paul Eggert's chown patch (bug #116536). - Merged chdir patch into pam patch where it belongs. * Mon Feb 23 2004 Tim Waugh 5.2.0-5 - Fixed i18n patch bug causing sort -M not to work (bug #116575). cyrus-imapd-2.2.3-4 ------------------- * Mon Feb 23 2004 Dan Walsh - Change su within init script to get input from /dev/null - This prevents hang when running in SELinux desktop-printing-0.1.10-25 -------------------------- * Mon Feb 23 2004 Tim Waugh 0.1.10-25 - eggcups: Don't exit on disconnection from the message bus. docbook-dtds-1.0-24 ------------------- * Mon Feb 23 2004 Tim Waugh 1.0-24 - Use ':' instead of '.' as separator for chown. freeciv-1.14.1-3 ---------------- * Mon Feb 23 2004 Karsten Hopp 1.14.1-3 - rebuild with new chown syntax * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. g-wrap-1.3.4-5 -------------- * Fri Feb 13 2004 Elliot Lee - rebuilt gnome-vfs2-2.5.8-1 ------------------ * Mon Feb 23 2004 Alexander Larsson 2.5.8-1 - update to 2.5.8 - fix smb filelist - add devel docs * Fri Feb 13 2004 Elliot Lee - rebuilt gnomemeeting-1.0-0.pre2.0 ------------------------- * Mon Feb 23 2004 Alexander Larsson 1.0-0.pre2.0 - update to 1.0pre2 * Fri Feb 13 2004 Elliot Lee - rebuilt gnucash-1.8.8-3 --------------- * Fri Feb 13 2004 Elliot Lee - rebuilt * Tue Dec 23 2003 Bill Nottingham - add a 64-bit patch from mandrake hpoj-0.91-4 ----------- * Mon Feb 23 2004 Tim Waugh 0.91-4 - Apply Till Kamppeter's patch for 2.6 kernel support. httpd-2.0.48-16 --------------- * Mon Feb 23 2004 Joe Orton 2.0.48-16 - fix apxs -q installbuilddir - really update to ab from HEAD - remove check that accept() returns an fd < FD_SETSIZE * Fri Feb 13 2004 Elliot Lee 2.0.48-15 - rebuilt * Tue Feb 03 2004 Joe Orton 2.0.48-14 - mod_dav: fix 401 on destination and reject unescaped fragment in URI - remove redundant ldconfig invocation from mod_ssl %post - remove unnecessary -headusage patch hwdata-0.109-1 -------------- * Mon Feb 23 2004 Bill Nottingham 0.109-1 - pci.ids and other updates * Thu Feb 19 2004 Mike A. Harris 0.108-1 - Added Shamrock C407L to MonitorsDB for bug (#104920) im-sdk-11.4-16 -------------- * Tue Feb 24 2004 Akira TAGOH 1:11.4-16 - im-sdk-11.4-canna-support-bs-and-del.patch: hopefully applied to fix #112291. ipsec-tools-0.2.4-1 ------------------- * Mon Feb 23 2004 Bill Nottingham - update to 0.2.4, fix racoon install location (#116374, ) * Fri Feb 13 2004 Elliot Lee - rebuilt kernel-2.6.3-1.100 ------------------ * Mon Feb 23 2004 Dave Jones - Update to 2.6.3-bk5 libbonobo-2.5.4-1 ----------------- * Mon Feb 23 2004 Alexander Larsson 2.5.4-1 - update to 2.5.4 libselinux-1.4-11 ----------------- * Mon Feb 23 2004 Dan Walsh 1.4-11 - add matchpathcon libxml2-2.6.7-1 --------------- * Mon Feb 23 2004 Daniel Veillard - upstream release 2.6.7 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems libxslt-1.1.4-1 --------------- * Mon Feb 23 2004 Daniel Veillard - upstream release 1.1.4 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems modutils-2.4.26-6 ----------------- * Mon Feb 23 2004 Bill Nottingham 2.4.26-6 - update module-init-tools to 3.0pre10 - fix modinfo (#116305) - always include /etc/modprobe.conf.dist (don't require the line in modprobe.conf) - ship a static modprobe.conf.dist, don't generate it at build time - clean up modprobe.conf.dist a little (#113772, #113768) openh323-1.13.2-0.pre1.1 ------------------------ * Mon Feb 23 2004 Alexander Larsson 1.13.2-0.pre1.1 - better ia64 workaround openssh-3.6.1p2-29 ------------------ * Mon Feb 23 2004 Daniel Walsh 3.6.1p2-29 - Eliminate selinux code and use pam_selinux pam_krb5-2.0.5-3 ---------------- * Tue Feb 24 2004 Harald Hoyer - 2.0.5-3 - rebuilt * Tue Nov 25 2003 Nalin Dahyabhai 2.0.5-2 - actually changelog the update to 2.0.5 * Tue Nov 25 2003 Nalin Dahyabhai 2.0.5-1 - update to 2.0.5 policy-1.6-6 ------------ * Mon Feb 23 2004 Dan Walsh 1.6-6 - Add Udev policy * Mon Feb 23 2004 Jeremy Katz 1.6-5 - Fix for depmod to auto-transition when run from rpm scriptlet - Make /usr/lib/locale locale_t instead of lib_t - Fixes to allow more domain transitions from anaconda_t - grpconv, pwunconv and grpunconv also need to be admin_passwd_exec_t * Mon Feb 23 2004 Dan Walsh 1.6-4 - More fixes from test machines postfix-2.0.16-12 ----------------- * Wed Feb 18 2004 John Dennis - set sasl back to v2 for mainline, this is good for fedora and beyond, for RHEL3, we'll branch and set set sasl to v1 and turn off ipv6 * Tue Feb 17 2004 John Dennis - revert back to v1 of sasl because LDAP still links against v1 and we can't - bump revision for build have two different versions of the sasl library loaded in one load image at the same time. How is that possible? Because the sasl libraries have different names (libsasl.so & libsasl2.so) but export the same symbols :-( Fixes bugs 115249 and 111767 * Fri Feb 13 2004 Elliot Lee - rebuilt privoxy-3.0.3-3 --------------- * Mon Feb 23 2004 Karsten Hopp 3.0.3-3 - rebuild with sane release number pychecker-0.8.13-3 ------------------ * Mon Feb 23 2004 Jeremy Katz - 0.8.13-3 - rebuild rpm-4.3-0.14 ------------ * Sun Feb 22 2004 Jeff Johnson 4.3-0.14 - add ia32e arch. - stable sort for policy specifications, patterns before paths. - set "rpm_script_t" exec type for scriptlets iff /bin/sh, else default. - force FD_CLOEXEC on 1st 100 inherited fdno's. rpmdb-fedora-1.90-0.20040224 ---------------------------- subversion-1.0.0-1 ------------------ * Mon Feb 23 2004 Joe Orton 1.0.0-1 - update to one-dot-oh * Fri Feb 13 2004 Elliot Lee 0.37.0-2 - rebuilt * Sat Jan 24 2004 Joe Orton 0.37.0-1 - update to 0.37.0 udev-016-4 ---------- * Mon Feb 23 2004 Dan Walsh - Add selinux support usermode-1.69-5 --------------- * Sat Feb 21 2004 Dan Walsh 1.69-5 - Change to fall back to root auth if selinux user does not exist utempter-0.5.4-1 ---------------- * Mon Feb 23 2004 Mike A. Harris 0.5.4-1 - Rewrote post install script to be a bit cleaner and rebuilt in rawhide to pick up twaugh's chown change - Added 'srpm-x' target to Makefile for package maintainer SRPM building * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. * Fri May 30 2003 Mike A. Harris 0.5.3-1 - Bump version and release and rebuild to strip debug info into .debuginfo package, as the Red Hat Linux 9 package shipped unstripped (#91664) - Updated license field to reflect dual license MIT style + LGPL - Changed spec file Copyright tag to proper License tag - Removed stupid crackrock "version" macro define xmms-1.2.9-5.p -------------- * Mon Feb 23 2004 Than Ngo 1:1.2.9-5.p - enable arts plugin, it should work with arts-1.2.0-1.5 or newer. yum-2.0.5.20040223-1 -------------------- * Mon Feb 23 2004 Jeremy Katz - 2.0.5.20040223-1 - update to current snapshot per skvidal's request - add retries=20 to yum.conf From toshio at tiki-lounge.com Tue Feb 24 14:18:46 2004 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 24 Feb 2004 09:18:46 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <20040224124552.GZ23631@redhat.com> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> Message-ID: <1077632323.3889.43.camel@Madison.badger.com> On Tue, 2004-02-24 at 07:45, Jay Turner wrote: > Point of order here. We do actually try our best to make sure that every > SRPM which leaves the building can recompile successfully. From time to > time, we hit a particularily difficult package (OpenOffice for a little > while) which won't recompile, but we work to fix those issues (and > OpenOffice nows compiles again.) If I understand this thread correctly, we have one person asking whether it's a bug that certain arches are being specifically excluded from being targetted. Other people are answering that the potential gain is so small no one is going to put effort into it. So far I don't see that there's a big conflict in the two views. It _would_ take a little effort to remove the exclusions from the spec files, true. But if it is intended that SRPMs will recompile successfully outside of Redhat and there's no good reason an arch is disallowed then it seems like it's a (low priority) bug to me. If someone who actually cares about the (possibly psychological) gains they can get by devoting their time to testing and submitting patches to build targetting other arches, doesn't it benefit everyone to apply those patches? Are we talking about reviewing three line patches here, or fifty? -Toshio -- Toshio From davej at redhat.com Tue Feb 24 15:11:32 2004 From: davej at redhat.com (Dave Jones) Date: Tue, 24 Feb 2004 15:11:32 +0000 Subject: rawhide report: 20040224 changes In-Reply-To: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> Message-ID: <1077635491.24605.1.camel@delerium.codemonkey.org.uk> On Tue, 2004-02-24 at 14:13, Build System wrote: > kernel-2.6.3-1.100 > ------------------ > * Mon Feb 23 2004 Dave Jones > > - Update to 2.6.3-bk5 This should also have working reiserfs again. ( I dropped the sleep_on conversion, and reexported sleep_on()) Dave From tdiehl at rogueind.com Tue Feb 24 15:13:58 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 24 Feb 2004 10:13:58 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <1077630074.16412.18.camel@bushido.mshome.net> References: <403A54C8.3010701@cornell.edu> <20040224053813.GA27005@comcast.net> <403AE6C9.5070201@cornell.edu> <1077630074.16412.18.camel@bushido.mshome.net> Message-ID: On Tue, 24 Feb 2004, Michel Alexandre Salim wrote: > On Tue, 2004-02-24 at 01:03 -0500, Tom Diehl wrote: > > [snip] > > > > For the 3rd time IT IS NOT WORTH THE EFFORT. The packages that can see > > significant performance gains by compiling for Athlon are already available. > > The rest are compiled with i686 optimizations and that is good enough. > > > > Look at the kernel packages for instance. You have an Athlon kernel available. > > > Ehm, not anymore; 2.6 kernels are available in i386 and i686 variants > only. IIRC some runtime CPU detection is being done, similar to what > MPlayer does. Ok, I stand corrected, but if the detection is being done at runtime then this is still accomplishing the same thing much more efficiently. I do not think anyone can complain if they have one less kernel to compile. :-) Tom From ivg2 at cornell.edu Tue Feb 24 15:14:17 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 24 Feb 2004 10:14:17 -0500 Subject: [Packages depending on qt-3.2 ] In-Reply-To: <20040224124552.GZ23631@redhat.com> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> Message-ID: <403B6A49.7000109@cornell.edu> > Point of order here. We do actually try our best to make sure that every > SRPM which leaves the building can recompile successfully. From time to > time, we hit a particularily difficult package (OpenOffice for a little > while) which won't recompile, but we work to fix those issues (and > OpenOffice nows compiles again.) Speaking of which, the following do not compile, because of incorrect qt path (now that qt has been upgraded from 3.2 to 3.3). Perhaps the path is correct, and they just don't work with qt-3.3... but either way... they won't build. old-qt/kdbg-1.2.9-4.src.rpm old-qt/kdeaddons-3.2.0-1.4.src.rpm old-qt/kdeartwork-3.2.0-1.3.src.rpm old-qt/kdeedu-3.2.0-1.3.src.rpm old-qt/kdegraphics-3.2.0-1.3.src.rpm old-qt/kdelibs-3.2.0-0.4.src.rpm old-qt/kdenetwork-3.2.0-1.3.src.rpm old-qt/kdesdk-3.2.0-1.3.src.rpm old-qt/kdeutils-3.2.0-1.1.src.rpm old-qt/qtparted-0.3.2-0.fdr.5.1.src.rpm old-qt/quanta-3.2.0-1.1.src.rpm old-qt/redhat-artwork-0.92-1.src.rpm ../../requires/kdeadmin-3.2.0-1.3.src.rpm ../../requires/kdebase-3.2.0-0.4.src.rpm ../../requires/kdebindings-3.2.0-1.3.src.rpm ../../requires/kdegames-3.2.0-1.3.src.rpm ../../requires/kde-i18n-3.2.0-1.3.src.rpm ../../requires/kdemultimedia-3.2.0-1.3.src.rpm ../../requires/kdepim-3.2.0-1.3.src.rpm ../../requires/kdetoys-3.2.0-1.3.src.rpm From ms-nospam-0306 at arcor.de Tue Feb 24 16:27:22 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 24 Feb 2004 17:27:22 +0100 Subject: [Packages depending on qt-3.2 ] In-Reply-To: <403B6A49.7000109@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> <403B6A49.7000109@cornell.edu> Message-ID: <20040224172722.4002d02e.ms-nospam-0306@arcor.de> On Tue, 24 Feb 2004 10:14:17 -0500, Ivan Gyurdiev wrote: > Speaking of which, the following do not compile, because of incorrect qt > path (now that qt has been upgraded from 3.2 to 3.3). Perhaps the path > is correct, and they just don't work with qt-3.3... but either way... > they won't build. > > old-qt/kdbg-1.2.9-4.src.rpm > old-qt/kdeaddons-3.2.0-1.4.src.rpm -snip- Can you be a little bit more specific please on how they depend on a Qt path? Don't they pull in the Qt root path via /etc/profile.d/qt.sh? -- From d.jacobfeuerborn at conversis.de Tue Feb 24 16:29:33 2004 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 24 Feb 2004 17:29:33 +0100 Subject: Kernel lockup problems Message-ID: <403B7BED.5050009@conversis.de> Hi, I have been running the kernel-2.6.1-1.65 package on my Fedora Core 1 box now for quite a while without any problems but yesterday I updated to kernel-2.6.3-1.97 and since then my machine keeps locking up after roughly 30-60 minutes. Since I have an nforce2 based board and read on the lkml that there have been problems with nforce and apic combinations I also tried using the noapic option but that didn't help. I'm going to try the new 1.100 package now but what is the proper way to find out what the problem is in this case? Right now I'm not running any proprietary kernel modules so I don't have any idea what might cause this problem. Regards, Dennis From jeffrey.d.kowing at nasa.gov Tue Feb 24 17:00:20 2004 From: jeffrey.d.kowing at nasa.gov (Jeff Kowing) Date: Tue, 24 Feb 2004 11:00:20 -0600 Subject: yum rpms in os and stable Message-ID: <16443.33572.869565.287421@igor.jsc.nasa.gov> I'm confused as to why at fedora.us there is a http://download.fedora.us/fedora/fedora/1/i386/RPMS.os/yum-2.0.4-2.noarch.rpm and a http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/yum-2.0.3-0.fdr.1.1.noarch.rpm How did that happen? I understood the fedora.us package naming guidelines to mean that the "0.fdr" portion of the release tag indicates that the yum package is not in the core distribution, but clearly yum-2.0.4-2.noarch.rpm is in the core distribution. Further, since yum-2.0.4-2.noarch.rpm is in the core os repository, why is a lower version, i.e. yum-2.0.3-0.fdr.1.1.noarch.rpm, even in the stable repository? Just curious and trying to learn. Thanks. -- Jeff Kowing All opinions expressed are my own and not of my employer. From ms-nospam-0306 at arcor.de Tue Feb 24 17:12:14 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 24 Feb 2004 18:12:14 +0100 Subject: yum rpms in os and stable In-Reply-To: <16443.33572.869565.287421@igor.jsc.nasa.gov> References: <16443.33572.869565.287421@igor.jsc.nasa.gov> Message-ID: <20040224181214.0b25cfe6.ms-nospam-0306@arcor.de> On Tue, 24 Feb 2004 11:00:20 -0600, Jeff Kowing wrote: > I'm confused as to why at fedora.us there is a > http://download.fedora.us/fedora/fedora/1/i386/RPMS.os/yum-2.0.4-2.noarch.rpm > > and a > http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/yum-2.0.3-0.fdr.1.1.noarch.rpm > > How did that happen? I understood the fedora.us package naming > guidelines to mean that the "0.fdr" portion of the release tag > indicates that the yum package is not in the core distribution, It does not mean that. > but > clearly yum-2.0.4-2.noarch.rpm is in the core distribution. Fedora.us packaged yum as an add-on for Red Hat Linux. Later, yum was included within Fedora Core 1. > Further, > since yum-2.0.4-2.noarch.rpm is in the core os repository, why is a > lower version, i.e. yum-2.0.3-0.fdr.1.1.noarch.rpm, even in the stable > repository? Because it has been published first. > Just curious and trying to learn. Thanks. No problem. -- From alan at redhat.com Tue Feb 24 17:32:39 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 24 Feb 2004 12:32:39 -0500 Subject: Athlon Incompatible Packages In-Reply-To: <200402241220.11410.arekm@pld-linux.org> References: <403A54C8.3010701@cornell.edu> <200402240333.49339.czar@czarc.net> <200402241220.11410.arekm@pld-linux.org> Message-ID: <20040224173239.GA7412@devserv.devel.redhat.com> On Tue, Feb 24, 2004 at 12:20:11PM +0100, Arkadiusz Miskiewicz wrote: > Dnia Tuesday 24 of February 2004 09:33, Gene C. napisa?: > > > A good reason to restrict the package to i386 (besides the reasons that > > many other have cited) is that at least one of these packages (grub) > > contains i386 assembler code ... it will not build on a x86_64 target for > > example. -- > Then restrict them to %{ix86} not i386. See rpm --showrc. Ok now I understand what you were getting at - packages that have old restrictions. Yes those do want fixing From salimma at fastmail.fm Tue Feb 24 17:36:23 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 25 Feb 2004 00:36:23 +0700 Subject: Building 2.6 kernels on FC1 Message-ID: <1077644183.21413.20.camel@bushido.mshome.net> Hi all, I have been trying to track down the problems with my Firewire external drive unit, and thought I would try building a 2.6.3 kernel using Red Hat's spec for UP i686 on FC1, using gcc32 and gcc 3.3, and copy the result over. The result, simply said, is interesting. This is taken using 2.6.3-mm3 with gcc 3.3, but other results are similar. /lib/modules/linux-2.6.3-mm3: 376 MB linux-2.6.3-mm3 build directory: 1.4G linux-2.6.3-mm3/arch/i386/boot/bzImage: 1.5M saying those were a bit on the large size would be a bit of an understatement.. it turns out make modules_install is doing bizarre things; a listing of kernel/drivers/acpi does this for instance: total 1768 -rw-r--r-- 1 root root 7938 Feb 24 23:58 ac.c -rw-r--r-- 1 root root 185294 Feb 24 23:58 ac.ko -rw-r--r-- 1 root root 33213 Feb 24 23:58 asus_acpi.c -rw-r--r-- 1 root root 204759 Feb 24 23:58 asus_acpi.ko -rw-r--r-- 1 root root 20347 Feb 24 23:58 battery.c -rw-r--r-- 1 root root 194175 Feb 24 23:58 battery.ko -rw-r--r-- 1 root root 13126 Feb 24 23:58 button.c -rw-r--r-- 1 root root 187411 Feb 24 23:58 button.ko -rw-r--r-- 1 root root 6658 Feb 24 23:58 fan.c -rw-r--r-- 1 root root 183526 Feb 24 23:58 fan.ko -rw-r--r-- 1 root root 61229 Feb 24 23:59 processor.c -rw-r--r-- 1 root root 240387 Feb 24 23:59 processor.ko -rw-r--r-- 1 root root 35245 Feb 25 00:00 thermal.c -rw-r--r-- 1 root root 206273 Feb 25 00:00 thermal.ko -rw-r--r-- 1 root root 13610 Feb 25 00:00 toshiba_acpi.c -rw-r--r-- 1 root root 189128 Feb 25 00:00 toshiba_acpi.ko 1) .c source files are installed 2) size bloat of an order of magnitude I will try rebuilding the Fedora kernel next - on FC1 and FC2-devel, gcc32 and gcc 3.3. Which reminds me - why does the kernel Makefile define both HOSTCC and HOSTCXX ? IIRC the kernel contains zero LOC of C+ +. Thanks, - 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 mharris at redhat.com Tue Feb 24 17:57:34 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 24 Feb 2004 12:57:34 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <1298.66.91.85.198.1077598502.squirrel@togami.com> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> Message-ID: On Mon, 23 Feb 2004, Warren Togami wrote: >> Is there any reason why those packages restrict arch to 386 and are not >> compatible with athlon, or is that a bug? I'd like to be able to rebuild >> them. Would you like me to file a bugzilla on each one? >> >> syslinux-2.08-2.src.rpm >> system-config-boot-0.2.1-1.1.src.rpm >> system-config-netboot-0.1.3-2.1.src.rpm > >This has been repeated many times in the past. The vast majority of >software have zero or negligible performance benefit from compiling to >athlon. The compiler flags used to build all packages are already set for >i686 optimization. Generally it is a very inefficient use of time to >rebuild packages for your specific arch as it takes far more time to do so >than any speed benefit you will gain. This being said however, nothing >stops you from taking the SRPMS and doing what you wish to them. You have >the freedom of choice with Open Source. While I certainly agree with your prognosis that most software will not at all benefit by being recompiled with --target=athlon, I totally disagree with you that the problem being reported is not a real issue. Looking at the package list, my assumption is that all of the above packages have a hard coded: Exclusivearch: i386 or similar in them, and do not add the athlon architecture there. It is most likely an oversight on the part of the package maintainer than any attentional blocking of the ability to recompile it for athlon architecture. >I would suggest against reporting this kind of "problem" to Bugzilla as >there are already thousands real issues there that are actual problems. And I would advise otherwise. Unless there is a specific reason that a package forcibly denies the ability to be rebuilt on the athlon architecture, then there should be no restriction on doing so if someone desires to do so. If anyone finds a package that wont rebuild with --target=athlon, I suggest filing a bug in bugzilla. It is VERY unlikely that fixing the problem takes more than 2 minutes for the given package, and is probably a one line edit of the spec file. After I send this email, I will have a look at some of the packages spec files, and commit fixes to any simple problems I find. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 24 18:01:26 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 24 Feb 2004 13:01:26 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> Message-ID: On Tue, 24 Feb 2004, Tom Diehl wrote: >> > This has been repeated many times in the past. The vast majority of >> > software have zero or negligible performance benefit from compiling to >> > athlon. The compiler flags used to build all packages are already set for >> > i686 optimization. Generally it is a very inefficient use of time to >> > rebuild packages for your specific arch as it takes far more time to do so >> > than any speed benefit you will gain. This being said however, nothing >> > stops you from taking the SRPMS and doing what you wish to them. You have >> > the freedom of choice with Open Source. >> > >> > I would suggest against reporting this kind of "problem" to Bugzilla as >> > there are already thousands real issues there that are actual problems. >> >> I think you're avoiding my question, which is whether this is a bug or >> not. It seems to me though, that this is a bug... and all bugs have to >> be fixed, correct? As far as the real issues go, I'll get to those >> too... - I have 67 additional packages that will not build on fedora. > >Why would you think it was a bug? AFAIK, it is done on purpose. As you quoted >above there are no signifigant performance gains to be realized by doing that >and it would be a lot of work to do that and maintain it. IOW the cure is worse >than the disease. It depends on _why_ the package fails. My unconfirmed assumption is that most of them are due to broken Exclusivearch being used in spec files, that does not use %{ix86}. If an excludearch can be fixed to build athlon packages, and the compile succeeds after doing so, it is a bug that should IMHO be fixed, and takes next to zero effort on the part of the package maintainer. If, on the other hand, a package fails to compile when using --target=athlon somewhere in the actual compilation (rather than rpm refusing to build it), then it might take more than a one line fix to fix it, and in this case the package owner may very well not want to bother looking into the issue themselves. If that turns out to be the case however, Fedora Project is an open project and volunteers are more than welcome to submit patches that make athlon recompiled packages compile properly if they desire. I don't think anyone should oppose volunteer contributions of patches to fix things. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mail.sw.rh.rhl.devel at spam.fi.basen.net Tue Feb 24 18:02:18 2004 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J. Niemi) Date: Tue, 24 Feb 2004 20:02:18 +0200 Subject: include php-imap in FC2 (bug #115535) Message-ID: <20040224180218.GA11418@basen.net> > I'm also able to package the c-client library based on the previous imap > rpm if that is the conclusion of this discussion. Attached is a suggestion for libc-client.spec. It is based on the imap-2002d package. A shared library is built in addition to the static library. The build code was borrowed from FreeBSD's ports collection mail/cclient where it has been working well. In the base package we install just the shared library while the header files and the static library gets saved for -devel. The .spec and the .src.rpm can be found at . Comments are welcome. // kaj -------------- next part -------------- %define soname c-client %define somajver 0 %define shlibname lib%{soname}.so.%{somajver} Summary: C-client mail access routines for IMAP and POP protocols Name: libc-client Version: 2002e Release: 0.1 Epoch: 0 License: University of Washington Free-Fork License Group: System Environment/Daemons URL: http://www.washington.edu/imap/ Source0: imap-%{version}.tar.Z Source1: flock.c Patch0: imap-2002e-redhat-ssl.patch Patch1: imap-2000-linux.patch Patch2: imap-2001a-mbox-disable.patch Patch3: imap-2002b-krbpath.patch Patch4: imap-2000c-redhat-flock.patch Patch5: imap-2001a-overflow.patch Patch6: imap-2002e-redhat-version.patch Patch7: imap-2002d-ssltype.patch Patch8: imap-2002e-cclient-only.patch Patch9: imap-2002e-shared.patch Buildroot: %{_tmppath}/%{name}-%{version}-root BuildPrereq: krb5-devel, openssl-devel # DO NOT REMOVE THIS PAM HEADER DEPENDANCY OR FACE THE WRATH BuildPreReq: /usr/include/security/pam_modules.h Requires: pam >= 0.59 %description C-client is a common API for accessing mailboxes. It is used internally by the popular PINE mail reader, the University of Washington's IMAP server and PHP. %package devel Summary: Development tools for programs which will use the IMAP library. Group: Development/Libraries %description devel The c-client-devel package contains the header files and static libraries for developing programs which will use the C-client common API. %prep %setup -q -n imap-%{version} chmod -R u+w . %patch0 -p1 -b .redhat-ssl-patch %patch1 -p1 -b .linux-patch %patch2 -p0 -b .mbox-disable-patch %patch3 -p1 -b .gssapi-patch %patch4 -p1 -b .redhat-flock %patch5 -p1 -b .overflow %patch6 -p1 -b .redhat-version %patch7 -p1 -b .ssltype %patch8 -p1 -b .cclient-only %patch9 -p1 -b .shared cp %{SOURCE1} src/osdep/unix/ %build # Set EXTRACFLAGS here instead of in imap-2000-redhat.patch (#20760) EXTRACFLAGS="$EXTRACFLAGS -DDISABLE_POP_PROXY=1 -DIGNORE_LOCK_EACCES_ERRORS=1" EXTRACFLAGS="$EXTRACFLAGS -I/usr/include/openssl" %ifnarch sparc make RPM_OPT_FLAGS="$RPM_OPT_FLAGS -fPIC" lnp \ %else make RPM_OPT_FLAGS="" lnp \ %endif EXTRACFLAGS="$EXTRACFLAGS" \ EXTRALDFLAGS="$EXTRALDFLAGS" \ EXTRAAUTHENTICATORS=gss \ SSLTYPE=unix \ SHLIBBASE=%{soname} \ SHLIBNAME=%{shlibname} # This line needs to be here. %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_libdir} install -m 644 ./c-client/c-client.a $RPM_BUILD_ROOT%{_libdir}/ ln -s c-client.a $RPM_BUILD_ROOT%{_libdir}/libc-client.a install -m 644 ./c-client/%{shlibname} $RPM_BUILD_ROOT%{_libdir}/ ln -s %{shlibname} $RPM_BUILD_ROOT%{_libdir}/lib%{soname}.so mkdir -p $RPM_BUILD_ROOT%{_includedir}/imap install -m 644 ./c-client/*.h $RPM_BUILD_ROOT%{_includedir}/imap # Added linkage.c to fix (#34658) install -m 644 ./c-client/linkage.c $RPM_BUILD_ROOT%{_includedir}/imap install -m 644 ./src/osdep/tops-20/shortsym.h $RPM_BUILD_ROOT%{_includedir}/imap #mkdir -p $RPM_BUILD_ROOT/%{_datadir}/ssl/certs %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root) %doc CPYRIGHT README WARNING docs/RELNOTES docs/*.txt %doc docs/CONFIG docs/SSLBUILD %{_libdir}/lib%{soname}.so.* %files devel %defattr(-,root,root) %doc docs/* %{_includedir}/imap %{_libdir}/c-client.a %{_libdir}/libc-client.a %{_libdir}/lib%{soname}.so %changelog * Tue Feb 24 2004 Kaj J. Niemi - Name change from c-client to libc-client * Sat Feb 14 2004 Kaj J. Niemi 0:2002e-0.1 - c-client 2002e is based on imap-2002d - Build shared version, build logic is copied from FreeBSD net/cclient From mharris at redhat.com Tue Feb 24 18:07:30 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 24 Feb 2004 13:07:30 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <403AE169.3040300@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> Message-ID: On Tue, 24 Feb 2004, Ivan Gyurdiev wrote: >>>I think you're avoiding my question, which is whether this is a bug or >>>not. It seems to me though, that this is a bug... and all bugs have to >>>be fixed, correct? As far as the real issues go, I'll get to those >>>too... - I have 67 additional packages that will not build on fedora. >> >> >> It is not a bug. rpmbuild --rebuild --target=i386. > >But shouldn't the athlon arch be compatible with 386? >In which case shouldn't the packages also allow athlon? >Excuse my total ignorance on this... If in fact, the packages in >question will not work correctly on athlon, and fedora is unwilling to >support athlon, then I can see how this is not a bug. Exactly.. That's the difference. If the rpm package is wrongly excluding athlon, it should be fixed. However, if the rpm package allows rpm recompilation with athlon and the compile fails, or even if it succeeds and then fails at runtime, then that is up to some volunteer to fix really as it isn't supported. Bugs being reported that end up being something unsupported, however in which the bug reporter supplies a patch to fix the bug, which is clean and correct, and isn't likely to regress builds for official architectures, should certainly be considered by package maintainers at least. I know if someone filed a "XFree86 wont recompile with --target==athlon" bug report to me, I would probably try to rebuild it myself, just to see what the failure is and wether it is a simple fix or not. If it required more involvement, I'd probably add a comment to the report something like: "I've reproduced that, and at a first non-detailed examination, it appears to require more attention than I'm willing to give it since that is not something that we officially support. However if you or someone else is willing to investigate the matter and fix it voluntarily, and supply a patch, I'd be more than happy to review your patch and consider it for inclusion in future builds." Just because we (Red Hat) might not support something does not mean we should outright reject things that volunteers might be willing to fix on their own IMHO. Remember, it's a community project, so external contributions are welcome. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 24 18:25:05 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 24 Feb 2004 13:25:05 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <200402240333.49339.czar@czarc.net> References: <403A54C8.3010701@cornell.edu> <200402240333.49339.czar@czarc.net> Message-ID: On Tue, 24 Feb 2004, Gene C. wrote: >> Is there any reason why those packages restrict arch to 386 and are not >> compatible with athlon, or is that a bug? I'd like to be able to rebuild >> them. Would you like me to file a bugzilla on each one? >> >> acpid-1.0.2-6.src.rpm >> dietlibc-0.24-3.src.rpm >> epiphany-1.0.7-1.src.rpm >> fedora-release-1.90-11.src.rpm >> festival-1.4.2-20.src.rpm >> gaim-0.75-2.1.0.src.rpm >> grub-0.94-2.src.rpm >> libunwind-0.96-2.src.rpm >> ltrace-0.3.29-2.src.rpm >> memtest86-3.0-4.src.rpm >> mkbootdisk-1.5.1-1.src.rpm >> mozilla-1.6-1.src.rpm >> openCryptoki-2.1.3-3.src.rpm >> prelink-0.3.0-21.src.rpm >> redhat-lsb-1.3-1.src.rpm >> reiserfs-utils-3.6.11-2.src.rpm >> syslinux-2.08-2.src.rpm >> system-config-boot-0.2.1-1.1.src.rpm >> system-config-netboot-0.1.3-2.1.src.rpm > >A good reason to restrict the package to i386 (besides the reasons that many >other have cited) is that at least one of these packages (grub) contains i386 >assembler code ... it will not build on a x86_64 target for example. Indeed. But it _will_, or at least should build on "athlon" target. After reading the entire thread about a seemingly TRIVIAL problem in a subset of rpms, I am now sickened by the attitude of some people about this type of problem. I have decided to personally go through each and every rpm package, and determine if it is a simple trivial one liner problem to fix (as I assume it is), and to just go ahead and fix the ones that are trivial. There is really no valid rational reason for anyone to oppose fixing this problem if it is indeed a trivial one liner fix, be they external contributors or internal Red Hatters. Once I'm done, I will post a list of fixed packages. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From davej at redhat.com Tue Feb 24 18:40:19 2004 From: davej at redhat.com (Dave Jones) Date: Tue, 24 Feb 2004 18:40:19 +0000 Subject: Building 2.6 kernels on FC1 In-Reply-To: <1077644183.21413.20.camel@bushido.mshome.net> References: <1077644183.21413.20.camel@bushido.mshome.net> Message-ID: <1077648018.7905.1.camel@delerium.codemonkey.org.uk> On Tue, 2004-02-24 at 17:36, Michel Alexandre Salim wrote: > -rw-r--r-- 1 root root 33213 Feb 24 23:58 asus_acpi.c > -rw-r--r-- 1 root root 204759 Feb 24 23:58 asus_acpi.ko > -rw-r--r-- 1 root root 20347 Feb 24 23:58 battery.c > -rw-r--r-- 1 root root 194175 Feb 24 23:58 battery.ko > -rw-r--r-- 1 root root 13126 Feb 24 23:58 button.c > -rw-r--r-- 1 root root 187411 Feb 24 23:58 button.ko > -rw-r--r-- 1 root root 6658 Feb 24 23:58 fan.c > -rw-r--r-- 1 root root 183526 Feb 24 23:58 fan.ko > -rw-r--r-- 1 root root 61229 Feb 24 23:59 processor.c > -rw-r--r-- 1 root root 240387 Feb 24 23:59 processor.ko > -rw-r--r-- 1 root root 35245 Feb 25 00:00 thermal.c > -rw-r--r-- 1 root root 206273 Feb 25 00:00 thermal.ko > -rw-r--r-- 1 root root 13610 Feb 25 00:00 toshiba_acpi.c > -rw-r--r-- 1 root root 189128 Feb 25 00:00 toshiba_acpi.ko > > 1) .c source files are installed in /lib/modules/2.6.3/... ? I've no idea how you managed that. > 2) size bloat of an order of magnitude Disable CONFIG_DEBUG_INFO. Dave From mharris at redhat.com Tue Feb 24 19:24:12 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 24 Feb 2004 14:24:12 -0500 (EST) Subject: chown xxx.yyy is now rejected In-Reply-To: <20040223211314.GB31346@devserv.devel.redhat.com> References: <20040223121416.GK6654@redhat.com> <20040223174610.GB23075@devserv.devel.redhat.com> <20040223211314.GB31346@devserv.devel.redhat.com> Message-ID: On Mon, 23 Feb 2004, Alan Cox wrote: >> I want to use the greek letter pi in usernames personally. > >This works correctly. Try it.. Ok, I'll take your word for that, however... What about the artist formerly known as Prince? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Feb 24 19:33:08 2004 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 24 Feb 2004 14:33:08 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: <1077632323.3889.43.camel@Madison.badger.com> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> <1077632323.3889.43.camel@Madison.badger.com> Message-ID: On Tue, 24 Feb 2004, Toshio wrote: >> Point of order here. We do actually try our best to make sure that every >> SRPM which leaves the building can recompile successfully. From time to >> time, we hit a particularily difficult package (OpenOffice for a little >> while) which won't recompile, but we work to fix those issues (and >> OpenOffice nows compiles again.) > >If I understand this thread correctly, we have one person asking whether >it's a bug that certain arches are being specifically excluded from >being targetted. Other people are answering that the potential gain is >so small no one is going to put effort into it. Exactly. >So far I don't see that there's a big conflict in the two views. It >_would_ take a little effort to remove the exclusions from the spec >files, true. But if it is intended that SRPMs will recompile >successfully outside of Redhat and there's no good reason an arch is >disallowed then it seems like it's a (low priority) bug to me. I disagree. It would take me personally about 15 minutes to make the changes in CVS to all of the relevant packages, and then a small amount of time beyond that to submit the new packages to beehive for building. Assuming nothing fails, it is a very trivial amount of work. In fact, it would have been completed since my last email except I do not modify other people's packages without asking them for permission first, so I sent an email directly to each affected package owner rather than commiting fixes myself. A few packages have since been fixed by their owners, more will likely follow. >If someone who actually cares about the (possibly psychological) >gains they can get by devoting their time to testing and >submitting patches to build targetting other arches, doesn't it >benefit everyone to apply those patches? Are we talking about >reviewing three line patches here, or fifty? Not even. It's a one line change to the spec file in every one of the packages listed. 2 of the packages are architecture specific to non-x86, one is ia64-only, the other s390-only, the rest are cross architecture, and just had an incorrect Exclusivearch line, just as I suspected originally. It is interesting though how a pointless debate about the merits of recompiling for athlon came out of this, since while it is true that recompiling for athlon doesn't buy you anything - that is totally aside from the fact that these packages contained an unintentional bug in their Exclusivearch lines. ;o) The problem should disappear within the next week likely as packages get updated. In the future, if someone detects a problem like this, it's best to file it in bugzilla along with a brief note to use %{ix86} instead of i386/i686 in Exclusivearch or Excludearch tags. Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From tdiehl at rogueind.com Tue Feb 24 19:33:13 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 24 Feb 2004 14:33:13 -0500 (EST) Subject: Athlon Incompatible Packages In-Reply-To: References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> Message-ID: On Tue, 24 Feb 2004, Mike A. Harris wrote: > On Tue, 24 Feb 2004, Tom Diehl wrote: > > >Why would you think it was a bug? AFAIK, it is done on purpose. As you quoted > >above there are no signifigant performance gains to be realized by doing that > >and it would be a lot of work to do that and maintain it. IOW the cure is worse > >than the disease. > > I don't think anyone should oppose volunteer contributions of > patches to fix things. Just for the record I am not opposed in any way to "volunteer contributions of patches to fix things." When this thread first started it appeared to me that he thought there should be athlon along with i386, i686, etc. packages. I now see I was wrong about where this was headed. Sorry, Tom From peter.backlund at home.se Tue Feb 24 19:46:21 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 24 Feb 2004 20:46:21 +0100 Subject: Buglet list from FC2t1 Message-ID: <403BAA0D.4050003@home.se> Hi. Here's list of (mostly) minor issues I've encountered on FC2test1. I'm not 100% rawhide yet, so some things may even be fixed right now. Anyway, if there's anything here that's not known about or already fixed, I'll add it to BZ. - Rhythmbox opens mp3 by default, but has no license problem dialogue. - GNOME Print Manager asks if you want to run printer config tool no first run, and shows alternatives "OK/Cancel" instead of "Yes/No". - system-settings:/// is empty. - The icon for Computer (on the desktop) should be /usr/share/icons/Bluecurve/48x48/apps/icon-computer.png - gnome-terminal sometimes has the entire view "selected" (i.e. black background) when opening a new tab, at least with ctrl-shit-t. ctrl-l fixes that. - The icon for opened folder in Nautilus is not from BC (I think)? - Sometimes, when selecting icons on the desktop and the un-selecting them, a small trace of the blue shade is left to the left of the text, about 1 pixel wide and as high as the text. Reproducible at least on the "Start here" icon. - RFE: Metacity should focus on a window, if there is one, when switching desktops. Right now, it focuses on the panel by default. - If KDE is installed, the "Other" meny item (in GNOME) is waaaaaaaay to crowded. - GNOME control center has a launcher for itself (which it shouldn't), and it doesn't even work :-) - Opening a .spec file in Nautilus pops up the file association question, but gnome-file-types-properties segfaults if you choose "yes". Running g-f-t-p from the meny works fine. - system-config-securitylevel does not strech very nicely, if the window is resized vertically. - The Mozilla Mail icon is horrible. Use the redhat-email icon instead, and skip the "mozilla mail message" launcher altogether. - OOo flickers a lot when resizing, especially the file dialogue (upstream issue?). - The panel sometimes stops responding to clicks on the main menu and launcher icons, related to when a gnome app fails to launch (gpdf for example). restarting the panel fixes the launcher icons, but not the main menu. logging out and in again fixes the main menu. And the some more serious issues: ================================= - The directory /etc/lvm was not created by anaconda (I created one LVM group on install), which b0rked the first boot completely. Running the lvm2 part of rc.sysinit fixed that. - s-c-display hides my mouse cursor after running it, even if no changes were made. The mouse still works, but the pointer is invisible. (geforce2, logitech usb mouse). - s-c-soundcard fails with the following error message: ** (system-config-soundcard.py:28986): WARNING **: `GtkTextSearchFlags' is not an enum type Traceback (most recent call last): File "/usr/share/system-config-soundcard/system-config-soundcard.py", line 47, in ? app = soundcard.childWindow() File "/usr/share/system-config-soundcard/soundcard.py", line 160, in __init__ self.primaryDeviceMenu.set_active(self.cardList.index(self.soundcardBackend.getDefaultCard())) ValueError: list.index(x): x not in list From markmc at redhat.com Tue Feb 24 20:04:09 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 24 Feb 2004 20:04:09 +0000 Subject: Buglet list from FC2t1 In-Reply-To: <403BAA0D.4050003@home.se> References: <403BAA0D.4050003@home.se> Message-ID: <1077653048.27445.13.camel@laptop> Hi Peter, On Tue, 2004-02-24 at 19:46, Peter Backlund wrote: > Hi. > > Here's list of (mostly) minor issues I've encountered on FC2test1. I'm > not 100% rawhide yet, so some things may even be fixed right now. > Anyway, if there's anything here that's not known about or already > fixed, I'll add it to BZ. This is a great list. Please do make sure to bugzilla all of them - logging a duplicate bug is worse than never logging a bug IMHO :) But obviously, if you have the time please do look for an existing bug before logging a new one. Thanks, Mark. From peter.backlund at home.se Tue Feb 24 20:08:58 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 24 Feb 2004 21:08:58 +0100 Subject: Buglet list from FC2t1 In-Reply-To: <1077653048.27445.13.camel@laptop> References: <403BAA0D.4050003@home.se> <1077653048.27445.13.camel@laptop> Message-ID: <403BAF5A.9070405@home.se> Mark McLoughlin wrote: > Hi Peter, > > On Tue, 2004-02-24 at 19:46, Peter Backlund wrote: > >>Hi. >> >>Here's list of (mostly) minor issues I've encountered on FC2test1. I'm >>not 100% rawhide yet, so some things may even be fixed right now. >>Anyway, if there's anything here that's not known about or already >>fixed, I'll add it to BZ. > > > This is a great list. Please do make sure to bugzilla all of them - > logging a duplicate bug is worse than never logging a bug IMHO :) > > But obviously, if you have the time please do look for an existing bug > before logging a new one. > > Thanks, > Mark. That was the plan, I just thought I'd throw in a mail here to see if any developer recognized any of it as fixed and/or "known-working on it". Anything that doesn't fall into either of those two categories will be BZ-ed. /Peter From paul at gear.dyndns.org Tue Feb 24 20:25:56 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Wed, 25 Feb 2004 06:25:56 +1000 Subject: Compiling iteraid driver for use at installation In-Reply-To: <20040224123616.GY23631@redhat.com> References: <403B0530.1080107@gear.dyndns.org> <20040224123616.GY23631@redhat.com> Message-ID: <403BB354.8000709@gear.dyndns.org> Jay Turner wrote: > On Tue, Feb 24, 2004 at 06:02:56PM +1000, Paul Gear wrote: > >>So my questions are: >> >>- If i install FC1 on a non-RAID hard disk in the same system, the >>iteraid driver i built from a running system works fine. So there must >>be something different about the installer kernel and the runtime >>kernel. What is it? >> >>- If i assuming rightly that the installation kernel doesn't use >>kernel versioning, how can i compile a module that will make the >>module correctly for use in the installer? I've gone through the "make >>mrproper, make config, make dep, make" routine on the default kernel, >>and i've come up with the same result. >>... > Have a look at the Device Driver Update Disk stuff which Doug Ledford has > put together. It can be found at http://people.redhat.com/dledford. This > will explain how to create a driver disk which is utilized as part of the > installation process, which sounds like is just what you need. Thanks - i'll check it out. I'd settle for just the right compile flags so i can insmod the driver from the shell, though. ;-) -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From warren at togami.com Tue Feb 24 20:44:15 2004 From: warren at togami.com (Warren Togami) Date: Tue, 24 Feb 2004 10:44:15 -1000 Subject: rawhide report: 20040224 changes In-Reply-To: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> Message-ID: <403BB79F.2020205@togami.com> Build System wrote: > > kernel-2.6.3-1.100 > ------------------ > * Mon Feb 23 2004 Dave Jones > > - Update to 2.6.3-bk5 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116724 This kernel seems to have broke Radeon. 2.6.3-1.97 was the last kernel that works for me. Warren From ivg2 at cornell.edu Tue Feb 24 21:07:25 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 24 Feb 2004 16:07:25 -0500 Subject: [Packages depending on qt-3.2 ] In-Reply-To: <20040224172722.4002d02e.ms-nospam-0306@arcor.de> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> <403B6A49.7000109@cornell.edu> <20040224172722.4002d02e.ms-nospam-0306@arcor.de> Message-ID: <403BBD0D.9040905@cornell.edu> Michael Schwendt wrote: > On Tue, 24 Feb 2004 10:14:17 -0500, Ivan Gyurdiev wrote: > > >>Speaking of which, the following do not compile, because of incorrect qt >>path (now that qt has been upgraded from 3.2 to 3.3). Perhaps the path >>is correct, and they just don't work with qt-3.3... but either way... >>they won't build. >> >>old-qt/kdbg-1.2.9-4.src.rpm >>old-qt/kdeaddons-3.2.0-1.4.src.rpm > > > -snip- > > Can you be a little bit more specific please on how they depend on a Qt > path? Don't they pull in the Qt root path via /etc/profile.d/qt.sh? > Well, you're right it seems like my rebuild script was not running in a login shell. NOTABUG From ivg2 at cornell.edu Tue Feb 24 21:12:02 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 24 Feb 2004 16:12:02 -0500 Subject: [Packages depending on qt-3.2 ] In-Reply-To: <403BBD0D.9040905@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> <403B6A49.7000109@cornell.edu> <20040224172722.4002d02e.ms-nospam-0306@arcor.de> <403BBD0D.9040905@cornell.edu> Message-ID: <403BBE22.1070907@cornell.edu> > Well, you're right it seems like my rebuild script was not running in a > login shell. NOTABUG Actually no - I don't know what's going on. In any case, it seems like it might be my problem instead of a bug. Are you the maintainer for the kde stuff? I can mail you when I figure it out.. From ellson at research.att.com Tue Feb 24 21:13:29 2004 From: ellson at research.att.com (John Ellson) Date: Tue, 24 Feb 2004 16:13:29 -0500 Subject: rawhide report: 20040224 changes In-Reply-To: <403BB79F.2020205@togami.com> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> <403BB79F.2020205@togami.com> Message-ID: <403BBE79.30306@research.att.com> Warren Togami wrote: > Build System wrote: > >> >> kernel-2.6.3-1.100 >> ------------------ >> * Mon Feb 23 2004 Dave Jones >> >> - Update to 2.6.3-bk5 > > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116724 > > This kernel seems to have broke Radeon. 2.6.3-1.97 was the last > kernel that works for me. > > Warren > > FWIW, it broke the NVIDIA-Linux-x86-1.0-5336 drivers too. Something about SVIPC? Shared Memory? John From nando at ccrma.Stanford.EDU Tue Feb 24 21:39:37 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 24 Feb 2004 13:39:37 -0800 Subject: workaround for 116299? ("Obsoletes:" problem in rpm) Message-ID: <1077658777.2194.24.camel@cmn37.stanford.edu> Hi all... anyone has any idea on how I could work around bug 116299? (see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116299) Basically (in FC1), in certain instances the "Obsoletes:" tag is being ignored by rpm in such a way that I cannot change the naming of a package (ie: if I try to install the new package, which "Obsoletes:" another older package with almost the same contents but a different name, the rpm process fails with a "conflicting files" message instead of replacing the old package with the new one). Maybe I'm making some packaging mistake, but the exact same thing works fine in RedHat 7.3/8.0/9... -- Fernando From alan at redhat.com Tue Feb 24 21:41:49 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 24 Feb 2004 16:41:49 -0500 Subject: Buglet list from FC2t1 In-Reply-To: <403BAA0D.4050003@home.se> References: <403BAA0D.4050003@home.se> Message-ID: <20040224214149.GA10728@devserv.devel.redhat.com> On Tue, Feb 24, 2004 at 08:46:21PM +0100, Peter Backlund wrote: > - RFE: Metacity should focus on a window, if there is one, when > switching desktops. Right now, it focuses on the panel by default. Depends on your focus mode. In sloppy focus it gets even more confused it seems > - The panel sometimes stops responding to clicks on the main menu and > launcher icons, related to when a gnome app fails to launch (gpdf for Try the updates - that one went away for me at least when I up2dated the gnome bits With regards to the graphics errors - what video card and if you specify "NoAccel" options does it go away ? From pertusus at free.fr Tue Feb 24 22:41:26 2004 From: pertusus at free.fr (pertusus at free.fr) Date: Tue, 24 Feb 2004 23:41:26 +0100 Subject: Buglet list from FC2t1 In-Reply-To: <403BAA0D.4050003@home.se> References: <403BAA0D.4050003@home.se> Message-ID: <1077662486.403bd316d3f92@imp1-q.free.fr> > - s-c-soundcard fails with the following error message: > ** (system-config-soundcard.py:28986): WARNING **: `GtkTextSearchFlags' > is not an enum type > > Traceback (most recent call last): > File "/usr/share/system-config-soundcard/system-config-soundcard.py", > line 47, in ? > app = soundcard.childWindow() > File "/usr/share/system-config-soundcard/soundcard.py", line 160, in > __init__ > > self.primaryDeviceMenu.set_active(self.cardList.index(self.soundcardBackend.getDefaultCard())) > ValueError: list.index(x): x not in list I closed a bug similar with this one, maybe you could reopen it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115198 And maybe you have 2 sound cards ? Pat From aoliva at redhat.com Tue Feb 24 23:03:52 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Feb 2004 20:03:52 -0300 Subject: Building 2.6 kernels on FC1 In-Reply-To: <1077644183.21413.20.camel@bushido.mshome.net> References: <1077644183.21413.20.camel@bushido.mshome.net> Message-ID: On Feb 24, 2004, Michel Alexandre Salim wrote: > I have been trying to track down the problems with my Firewire external > drive unit FWIW, kenrel-2.6.3-1.91 was the last one I could get installed on my laptop that recognized the Firewire external drive (Maxtor 5000DV). After that (tested up to 1.100), the module will load but it won't associate a scsi device with the disk. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From aoliva at redhat.com Tue Feb 24 23:07:41 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Feb 2004 20:07:41 -0300 Subject: Buglet list from FC2t1 In-Reply-To: <403BAA0D.4050003@home.se> References: <403BAA0D.4050003@home.se> Message-ID: On Feb 24, 2004, Peter Backlund wrote: > - gnome-terminal sometimes has the entire view "selected" (i.e. black > background) when opening a new tab, at least with ctrl-shit-t. ctrl-l > fixes that. This has been in bugzilla since pre-FC1. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org} Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist Professional serial bug killer From i.pilcher at comcast.net Wed Feb 25 02:15:26 2004 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 24 Feb 2004 20:15:26 -0600 Subject: chown xxx.yyy is now rejected In-Reply-To: References: <20040223121416.GK6654@redhat.com> <20040223174610.GB23075@devserv.devel.redhat.com> <20040223211314.GB31346@devserv.devel.redhat.com> Message-ID: Mike A. Harris wrote: > > Ok, I'll take your word for that, however... What about the > artist formerly known as Prince? ;o) > I guess now we know why he changed back. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From d.lesca at solinos.it Wed Feb 25 02:29:16 2004 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 25 Feb 2004 03:29:16 +0100 (CET) Subject: plugins for pppd (pppoatm) In-Reply-To: <35780.213.45.198.9.1077675827.squirrel@www.solinos.it> References: <35780.213.45.198.9.1077675827.squirrel@www.solinos.it> Message-ID: <35860.213.45.198.9.1077676156.squirrel@www.solinos.it> Hi, I have add to ppp-2.4.1-15.src.rpm some plugins, like the PPPoATM plugins, useful for xDSL modem The src.rpm is here: http://www.solinos.it/pubblica/rpms-x-fc1/ Do you think that it is useful to insert it in FC2 (mandrake 9.0 have it) If you think that I must modify some part (like dependencies whit linux-atm-2.4.1-1), pleas tell mi. I have also make (amd use!) a rpm driver for modem adsl usb conexant (like Atlantis I-Storm) ... if someone is interess to it, please tell mi.... Thank for attention ... and sorry for my bad english Dario Lesca d.lesca at solinos.it From jspaleta at princeton.edu Wed Feb 25 05:22:25 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 25 Feb 2004 00:22:25 -0500 Subject: Fedora Bug Day Tomorrow: Feb 25th 2004: Eat bugs before the bugs eat you Message-ID: <1077686545.21407.39.camel@goober.localdomain> What: Fedora Bug Day: making bugzilla cry uncle Tomorrow is a general effort to triage Fedora Core bugs, I'm sure there are some bugs against the fc2 test release that can use a group hug from community triaging, a hug or a baseball bat in the form of a well crafted patch. Interested in helping out trying to close bug reports out or marking them up, show up on the #fedora-bugs irc channel tomorrow, and get you feet wet in the triage discussions, And if wading into Fedora Core's bugzilla looking for bugreports to try to help close, isn't you cup of tea, you might find helping with the fedora.us addon package QA process is something you want to start getting involved in. 330+ packages waiting for peer review in the QA que ( http://www.fedora.us/QA ). If you are interested in helping out with that fedora.us QA effort, but don't really know how to get started, pick a package in that list you like, and drop in on the irc channel and hopefully someone an find some time to answer your questions about how you go about helping out with QA. I'm feeling bad about not having enough time to be around last week, so I have deliberately broken the equipment I'm responsible for at work, so that I can have enough time tomorrow to shepherd the volunteers for a Fedora Bug Day. Well, i didn't really deliberately break the equipment. It's sort of their fault for tying me to my desk with a critical high voltage power cable not expecting me to chew through it to get to the coffee machine. Anyways... When: Feb 25th, starting at 14:00 UTC (09:00 EST), Where: #fedora-bugs channel on freenode irc network Who: Pretty much everyone. If you have a little time to spare, and want to help make it easier for the developers by helping organize the untamed sea of bugreports in bugzilla, then triage just might be for you. You don't need to code(though if you can, patch submissions are always welcome), you just need a web browser and an account at bugzilla.redhat. com. An irc client or email client would help too...since you probably want to try to communicate to the other triagers either on irc on the fedora-bugs channel at freenode, or in the mailinglist at duke. https://lists.dulug.duke.edu/pipermail/fedora-triage-list/ Huh: No Clue What I'm talking about when I say the phrase Fedora Triage? Take a quick look at the fedora-triage-list archives: https://lists.dulug.duke.edu/pipermail/fedora-triage-list/ These messages should hopefully tell you what its all about in more detail: http://tinyurl.com/ywma3 - Summary of my vision for Fedora Triage http://tinyurl.com/23alw - My short term goals and long term plan -jef"tungsten splinters under your finger nails, are not as bad you might think"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 hattenator at imapmail.org Wed Feb 25 05:25:22 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Tue, 24 Feb 2004 21:25:22 -0800 Subject: rawhide report: 20040224 changes In-Reply-To: <403BBE79.30306@research.att.com> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> <403BB79F.2020205@togami.com> <403BBE79.30306@research.att.com> Message-ID: <403C31C2.4060506@imapmail.org> John Ellson wrote: > Warren Togami wrote: > >> Build System wrote: >> >>> >>> kernel-2.6.3-1.100 >>> ------------------ >>> * Mon Feb 23 2004 Dave Jones >>> >>> - Update to 2.6.3-bk5 >> > > > FWIW, it broke the NVIDIA-Linux-x86-1.0-5336 drivers too. Something > about SVIPC? Shared Memory? > My 5336 is working fine. I did have to reinstall it even from the -96, though. So if you reinstalled it, there must be something different about our configurations. 21:21 eric|/sbin/lsmod|grep nvi nvidia 2073096 12 21:21 eric|uname -a Linux Eric 2.6.3-1.97 #1 Sat Feb 21 20:56:10 EST 2004 i686 athlon i386 GNU/Linux Ps. My prompt is more obviously a prompt if you look at it in color. -Eric Hattemer From hvdkooij at vanderkooij.org Wed Feb 25 06:32:43 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Wed, 25 Feb 2004 07:32:43 +0100 (CET) Subject: rawhide report: 20040224 changes In-Reply-To: <403C31C2.4060506@imapmail.org> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> <403BB79F.2020205@togami.com> <403BBE79.30306@research.att.com> <403C31C2.4060506@imapmail.org> Message-ID: On Tue, 24 Feb 2004, Eric Hattemer wrote: > John Ellson wrote: > > FWIW, it broke the NVIDIA-Linux-x86-1.0-5336 drivers too. Something > > about SVIPC? Shared Memory? > > > My 5336 is working fine. I did have to reinstall it even from the -96, > though. So if you reinstalled it, there must be something different > about our configurations. To the best of my knowledge you have to rebuild your module to match the exact kernel. Something I do after each kernel update patch to get X running again. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From wtogami at redhat.com Wed Feb 25 07:07:31 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 24 Feb 2004 21:07:31 -1000 Subject: rawhide report: 20040224 changes In-Reply-To: References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> <403BB79F.2020205@togami.com> <403BBE79.30306@research.att.com> <403C31C2.4060506@imapmail.org> Message-ID: <403C49B3.2000600@redhat.com> Hugo van der Kooij wrote: > On Tue, 24 Feb 2004, Eric Hattemer wrote: > > >>John Ellson wrote: > > >>>FWIW, it broke the NVIDIA-Linux-x86-1.0-5336 drivers too. Something >>>about SVIPC? Shared Memory? >>> >> >>My 5336 is working fine. I did have to reinstall it even from the -96, >>though. So if you reinstalled it, there must be something different >>about our configurations. > > > To the best of my knowledge you have to rebuild your module to match the > exact kernel. > > Something I do after each kernel update patch to get X running again. > > Hugo. > I'm using kernel-2.6.3-1.106 right now, and it seems to have fixed the "X dies immediately with signal 11" problem with my Radeon 7500 in my IBM Thinkpad T41. It should hit FC/development tomorrow. Warren From naoki at valuecommerce.com Wed Feb 25 07:36:23 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 25 Feb 2004 16:36:23 +0900 Subject: USB Storage device not working. Message-ID: <403C5077.2000300@valuecommerce.com> I plug it in and get this : usbaudio: dma timed out?? loop: loaded (max 8 devices) usb 2-1: new full speed USB device using address 2 Initializing USB Mass Storage driver... scsi2 : SCSI emulation for USB Mass Storage devices Vendor: Generic Model: Generic CF Rev: 2.5D Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi2, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 drivers/usb/core/usb.c: registered new driver usb-storage USB Mass Storage support registered. updfstab: numerical sysctl 1 23 is obsolete. I can't mount /dev/sda* ( no media found ). [naoki at host naoki]$ sudo mount /dev/sda1 /mnt/flash/ mount: No medium found Any ideas? From mr700 at globalnet.bg Wed Feb 25 10:24:15 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Wed, 25 Feb 2004 12:24:15 +0200 Subject: workaround for 116299? ("Obsoletes:" problem in rpm) In-Reply-To: <1077658777.2194.24.camel@cmn37.stanford.edu> References: <1077658777.2194.24.camel@cmn37.stanford.edu> Message-ID: <200402251224.17431@-mr700> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 24 February 2004 23:39, Fernando Pablo Lopez-Lezcano wrote: > Hi all... anyone has any idea on how I could work around bug 116299? > (see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116299) > > Basically (in FC1), in certain instances the "Obsoletes:" tag is being > ignored by rpm in such a way that I cannot change the naming of a > package (ie: if I try to install the new package, which "Obsoletes:" > another older package with almost the same contents but a different > name, the rpm process fails with a "conflicting files" message instead > of replacing the old package with the new one). > I think... $ rpm -e oldpackage --nodeps $ rpm -ihv newpackage should work... > Maybe I'm making some packaging mistake, but the exact same thing works > fine in RedHat 7.3/8.0/9... > > -- Fernando > > > - -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAPHfPoInLFdpFT3kRAnBGAKCT49R0Hxlh812l5wbsxwmRYD0dtwCfZ8x1 UDBWp3QvLQbU1LKbyhKQzk8= =AwUo -----END PGP SIGNATURE----- From georg at georgs.org Wed Feb 25 12:31:08 2004 From: georg at georgs.org (Georg E Schneider) Date: Wed, 25 Feb 2004 13:31:08 +0100 Subject: plugins for pppd (pppoatm) In-Reply-To: <35860.213.45.198.9.1077676156.squirrel@www.solinos.it> References: <35780.213.45.198.9.1077675827.squirrel@www.solinos.it> <35860.213.45.198.9.1077676156.squirrel@www.solinos.it> Message-ID: <403C958C.8080604@georgs.org> Dario Lesca schrieb: >Hi, >I have add to ppp-2.4.1-15.src.rpm some plugins, like the PPPoATM plugins, >useful for xDSL modem > >The src.rpm is here: http://www.solinos.it/pubblica/rpms-x-fc1/ > >Do you think that it is useful to insert it in FC2 (mandrake 9.0 have it) > >If you think that I must modify some part (like dependencies whit >linux-atm-2.4.1-1), pleas tell mi. > > It's not official but: - depends on ... done - and /sbin/ldconfig after install see the diff-file see: http://www.georgs.org/pppd/ > >Thank for attention ... and sorry for my bad english > > does not matter Works fine for me tanti saluti Georg E Schneider From ellson at research.att.com Wed Feb 25 13:52:58 2004 From: ellson at research.att.com (John Ellson) Date: Wed, 25 Feb 2004 08:52:58 -0500 Subject: rawhide report: 20040224 changes In-Reply-To: <403C31C2.4060506@imapmail.org> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> <403BB79F.2020205@togami.com> <403BBE79.30306@research.att.com> <403C31C2.4060506@imapmail.org> Message-ID: <403CA8BA.7070004@research.att.com> Eric Hattemer wrote: > John Ellson wrote: > >> Warren Togami wrote: >> >>> Build System wrote: >>> >>>> >>>> kernel-2.6.3-1.100 >>>> ------------------ >>>> * Mon Feb 23 2004 Dave Jones >>>> >>>> - Update to 2.6.3-bk5 >>> >>> >> >> >> FWIW, it broke the NVIDIA-Linux-x86-1.0-5336 drivers too. Something >> about SVIPC? Shared Memory? >> > My 5336 is working fine. I did have to reinstall it even from the > -96, though. So if you reinstalled it, there must be something > different about our configurations. > 21:21 eric|/sbin/lsmod|grep nvi > nvidia 2073096 12 > 21:21 eric|uname -a > Linux Eric 2.6.3-1.97 #1 Sat Feb 21 20:56:10 EST 2004 i686 athlon i386 > GNU/Linux > > Ps. My prompt is more obviously a prompt if you look at it in color. > -Eric Hattemer > > My box is dual processor i686, so athlon and smp are different? (Did you revert kernels for some other reason? I note your uname shows 1.97, which worked OK for me too.) Anyway, sounds like there is a 1.106 to try soon. John From csm at redhat.com Wed Feb 25 14:27:04 2004 From: csm at redhat.com (Chuck Mead) Date: Wed, 25 Feb 2004 09:27:04 -0500 Subject: MrProject is now Planner Message-ID: <403CB0B8.8070107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ...and there has been an updated release! (.11) Any chance we can see the updated release in FC2? It fixes a number of outstanding bugs. - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAPLC3Zfy0juH51WsRAnltAKCDa2MMdnA3bS7Uc0Qi1kplSmi60QCfXa4Q QqVYo7/4sLIj2TecF8Dk0FY= =ikP0 -----END PGP SIGNATURE----- From d.lesca at solinos.it Wed Feb 25 15:31:15 2004 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 25 Feb 2004 16:31:15 +0100 Subject: plugins for pppd (pppoatm) In-Reply-To: <403C958C.8080604@georgs.org> References: <35780.213.45.198.9.1077675827.squirrel@www.solinos.it> <35860.213.45.198.9.1077676156.squirrel@www.solinos.it> <403C958C.8080604@georgs.org> Message-ID: <1077723075.2436.9.camel@lesca.home.solinos.it> Il mer, 2004-02-25 alle 13:31, Georg E Schneider ha scritto: > It's not official but: > - depends on ... done > - and /sbin/ldconfig after install > see the diff-file > > see: http://www.georgs.org/pppd/ Now I download and use your package! Another question, it is possible that this package becomes that definitive one in FC2? And .... would not be better to publish also one official version for FC* of linux-atm? ... which have used you? Many thanks -- Dario Lesca From yui at mariana.u-aizu.ac.jp Wed Feb 25 14:37:40 2004 From: yui at mariana.u-aizu.ac.jp (Yui Hiroaki) Date: Wed, 25 Feb 2004 23:37:40 +0900 Subject: participate Message-ID: <403CB334.9010102@mariana.u-aizu.ac.jp> HI! I would like to participate in Fedora Project QA. How can I participate? And if I am busy druring project, how can I stop the project of Fedora. Regards, Yui From georg at georgs.org Wed Feb 25 15:11:26 2004 From: georg at georgs.org (Georg E Schneider) Date: Wed, 25 Feb 2004 16:11:26 +0100 Subject: plugins for pppd (pppoatm) In-Reply-To: <1077723075.2436.9.camel@lesca.home.solinos.it> References: <35780.213.45.198.9.1077675827.squirrel@www.solinos.it> <35860.213.45.198.9.1077676156.squirrel@www.solinos.it> <403C958C.8080604@georgs.org> <1077723075.2436.9.camel@lesca.home.solinos.it> Message-ID: <403CBB1E.3060008@georgs.org> Dario Lesca schrieb: >Il mer, 2004-02-25 alle 13:31, Georg E Schneider ha scritto: > > > >>It's not official but: >>- depends on ... done >>- and /sbin/ldconfig after install >>see the diff-file >> >>see: http://www.georgs.org/pppd/ >> >> >Now I download and use your package! > >Another question, it is possible that this package becomes >that definitive one in FC2? > > Can not say I'm not a maintainer. But I would like it because I need it for my internet connection. >And .... would not be better to publish also one official version for FC* >of linux-atm? ... which have used you? > > > > http://sourceforge.net/projects/linux-atm/ there is a rpm Package too. salute Georg E Schneider From salimma at fastmail.fm Wed Feb 25 15:46:02 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 25 Feb 2004 22:46:02 +0700 Subject: Building 2.6 kernels on FC1 In-Reply-To: <1077648018.7905.1.camel@delerium.codemonkey.org.uk> References: <1077644183.21413.20.camel@bushido.mshome.net> <1077648018.7905.1.camel@delerium.codemonkey.org.uk> Message-ID: <1077723962.2143.9.camel@bushido.mshome.net> On Tue, 2004-02-24 at 18:40 +0000, Dave Jones wrote: > [snip] > > > > 1) .c source files are installed > > in /lib/modules/2.6.3/... ? I've no idea how you managed that. > No idea either; it could not have anything to do with gcc32 could it? > > 2) size bloat of an order of magnitude > > Disable CONFIG_DEBUG_INFO. > How does RH keep the size of kernel packages down then? Are the debug info stripped to a kernel-debug package which is not published? Running 'file' on /lib/modules .ko files show that they are not stripped. Thanks, 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 davej at redhat.com Wed Feb 25 15:55:32 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 25 Feb 2004 15:55:32 +0000 Subject: Building 2.6 kernels on FC1 In-Reply-To: <1077723962.2143.9.camel@bushido.mshome.net> References: <1077644183.21413.20.camel@bushido.mshome.net> <1077648018.7905.1.camel@delerium.codemonkey.org.uk> <1077723962.2143.9.camel@bushido.mshome.net> Message-ID: <1077724532.1357.12.camel@delerium.codemonkey.org.uk> On Wed, 2004-02-25 at 15:46, Michel Alexandre Salim wrote: > On Tue, 2004-02-24 at 18:40 +0000, Dave Jones wrote: > > > 1) .c source files are installed > > in /lib/modules/2.6.3/... ? I've no idea how you managed that. > No idea either; it could not have anything to do with gcc32 could it? shouldn't do. > > > 2) size bloat of an order of magnitude > > Disable CONFIG_DEBUG_INFO. > > > How does RH keep the size of kernel packages down then? Are the debug > info stripped to a kernel-debug package which is not published? There's a debuginfo package. > Running 'file' on /lib/modules .ko files show that they are not stripped. the debug info is stripped, but not the symbols etc. Dave From redhat-forums at genesis-x.nildram.co.uk Wed Feb 25 15:58:24 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Wed, 25 Feb 2004 15:58:24 +0000 Subject: Prelink success story :) Message-ID: Guess I've been lucky, but I never really suffered much from the various prelink related problems that have been reported. A total of 2 applications (out of 1603 packages) were b?rked by prelink on my system, since FC1 was released, namely k3b and kdepim (in fact they still get b?rked even now by prelink). Being rather pleased with myself for having a 99.88% perfect system, I took the (maybe) risky step of chasing after the other 0.12%. I got prelink-0.3.0-21 from (Fedora devel) rawhide, but it needs SELinux. After getting the SRPM and looking at the spec, I don't see SELinux listed? Anyway, after some minor modification to the spec (mainly to satisfy rpmlint) I rebuilt on a clean mach chroot and installed. Of course the whole purpose of the exercise was to get blacklist support, so I edited prelink.conf and added twenty or so files that I'd flagged as problem files (all part of the above two apps). I ran a full prelink and crossed my finger. Result: no problems at all. No segfaults and no b?rked apps. Also, and maybe this is my imagination, but everything seems to be running a *lot* faster ... even more than after previous prelinking. Even the log file was relatively clear (just a few complaints about "x" can't be prelinked because it depends on "y" which also can't be prelinked ... etc. Normal stuff. Now for some questions ... not gripes ... just curiosity: 1) ... Is Jakub Jelinek really the *only* guy working on this? 2) ... Other than in the SRPM, where's the source Luke :) prelink-20040216.tar.bz2 is missing from people.redhat.com/jakub/prelink 3) ... Why was macros.prelink hard coded into the spec as a text block, rather than as a SourceX file? 4) ... Why isn't there a logrotate file to accompany the included log file, and come to that, why *package* a log file? Or am I missing something obvious? Other minor (rpmlint) observations: Use of "Copyright" instead of "License" Weird 555 and 444 perms Ghost-without-post errors Use of "/etc" instead of %{_sysconfdir} Use of %{buildroot} instead of $RPM_BUILD_ROOT (although that seems to be a point of contention these days, personally I prefer %{buildroot}, since it is more consistent with the other spec conventions. Anyway, I'm just really pleased to have blacklist support in prelink finally, which I guess leads me to one final question ... why hasn't this version been officially released yet? (Although maybe I've answered this already above, but the cleaned up version looks pretty good). Oh, and ... thank you Jakub. - K. From alan at redhat.com Wed Feb 25 16:12:44 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 25 Feb 2004 11:12:44 -0500 Subject: participate In-Reply-To: <403CB334.9010102@mariana.u-aizu.ac.jp> References: <403CB334.9010102@mariana.u-aizu.ac.jp> Message-ID: <20040225161244.GB31462@devserv.devel.redhat.com> On Wed, Feb 25, 2004 at 11:37:40PM +0900, Yui Hiroaki wrote: > HI! > I would like to participate in Fedora Project QA. How can I > participate? And if I am busy druring project, how can I stop the > project of Fedora. Download it, test it and add any bugs you find to http://bugzilla.redhat.com and if you are busy, just stop. There is no commitment to keep testing Fedora. BTW I believe there is also a fedora japanese language list somewhere which may be of interest to you From salimma at fastmail.fm Wed Feb 25 16:13:54 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Wed, 25 Feb 2004 23:13:54 +0700 Subject: [Packages depending on qt-3.2 ] In-Reply-To: <403BBE22.1070907@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> <403B6A49.7000109@cornell.edu> <20040224172722.4002d02e.ms-nospam-0306@arcor.de> <403BBD0D.9040905@cornell.edu> <403BBE22.1070907@cornell.edu> Message-ID: <1077725633.2143.17.camel@bushido.mshome.net> On Tue, 2004-02-24 at 16:12 -0500, Ivan Gyurdiev wrote: > > Well, you're right it seems like my rebuild script was not running in a > > login shell. NOTABUG > > Actually no - I don't know what's going on. > In any case, it seems like it might be my problem instead of a bug. > Are you the maintainer for the kde stuff? I can mail you when I figure > it out.. > That would be Ngo Than - 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 buildsys at redhat.com Wed Feb 25 16:44:11 2004 From: buildsys at redhat.com (Build System) Date: Wed, 25 Feb 2004 11:44:11 -0500 Subject: rawhide report: 20040225 changes Message-ID: <200402251644.i1PGiB706018@porkchop.devel.redhat.com> Removed package mrproject Removed package libmrproject Updated Packages: GConf2-2.5.90-1 --------------- * Tue Feb 24 2004 Mark McLoughlin 2.5.90-1 - Update to 2.5.90 anaconda-9.91-0.20040224191432 ------------------------------ * Tue Feb 24 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) balsa-2.0.16-2 -------------- coreutils-5.2.0-7 ----------------- * Tue Feb 24 2004 Tim Waugh 5.2.0-7 - Ship the real '[', not a symlink. dia-0.92.2-3 ------------ * Tue Feb 24 2004 Alexander Larsson 1:0.92.2-3 - fix freetype issue eel2-2.5.8-1 ------------ * Tue Feb 24 2004 Alexander Larsson 2.5.8-1 - update to 2.5.8 * Fri Feb 13 2004 Elliot Lee - rebuilt ethereal-0.10.2-1 ----------------- * Tue Feb 24 2004 Phil Knirsch 0.10.2-1 - Update to latest upstream version 0.10.2. exim-4.30-6.1 ------------- * Tue Feb 24 2004 Thomas Woerner 4.30-6.1 - rebuilt * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. finger-0.17-21 -------------- * Wed Feb 25 2004 Phil Knirsch 0.17-21 - rebuilt - Made fingerd PIE. * Fri Feb 13 2004 Elliot Lee - rebuilt freeradius-0.9.3-3.2 -------------------- * Tue Feb 24 2004 Thomas Woerner 0.9.3-3.2 - added sql scripts for rlm_sql to documentation (#116435) gconf-editor-2.5.4-1 -------------------- * Tue Feb 24 2004 Mark McLoughlin 2.5.4-1 - Update to 2.5.4 - Remove extraneous fontconfig BuildRequires - Package manpages gnome-desktop-2.5.90-1 ---------------------- * Tue Feb 24 2004 Mark McLoughlin 2.5.90-1 - Update to 2.5.90 - Remove hack to get rid of GNOME_COMPILE_WARNINGS and use --disable-compile-warnings instead. - Package the (L)GPL/FDL and gnome-feedback docs gnome-icon-theme-1.1.8-1 ------------------------ * Mon Feb 23 2004 Alexander Larsson 1.1.8-1 - update to 1.1.8 gnome-keyring-0.1.4-1 --------------------- * Tue Feb 24 2004 Alexander Larsson 0.1.4-1 - update to 0.1.4 gnome-session-2.5.90-1 ---------------------- * Tue Feb 24 2004 Mark McLoughlin 2.5.90-1 - Update to 2.5.90 - Remove extraneous fontconfig BuildRequires - Resolve conflicts with the icons and splash-repaint patches gnome-vfs2-2.5.8-2 ------------------ * Wed Feb 25 2004 Alexander Larsson 2.5.8-2 - fix some packaging issues (#115807) groff-1.18.1-32 --------------- * Wed Feb 25 2004 Thomas Woerner 1.18.1-32 - fixed nroff script input (#116596) isdn4k-utils-3.2-13.p1 ---------------------- * Wed Feb 25 2004 Than Ngo 3.2-13.p1 - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Feb 11 2004 Than Ngo 3.2-11.p1 - add fix to get isdnlog working with Fritz!Card PCI V2.0, bug #115205 kdeaddons-3.2.0-1.6 ------------------- * Tue Feb 24 2004 Than Ngo 3.2.0-1.6 - gcc 3.4 build problem * Tue Feb 17 2004 Than Ngo 3.2.0-1.5 - fix typo bug, _smp_mflags instead smp_mflags kdeedu-3.2.0-1.5 ---------------- * Tue Feb 24 2004 Than Ngo 3.2.0-1.5 - gcc 3.4 build problem kdegames-3.2.0-1.4 ------------------ * Tue Feb 24 2004 Than Ngo 6:3.2.0-1.4 - gcc 3.4 build problem kdenetwork-3.2.0-1.5 -------------------- * Tue Feb 24 2004 Than Ngo 7:3.2.0-1.5 - gcc 3.4 build problem * Tue Feb 17 2004 Than Ngo 7:3.2.0-1.4 - use _smp_mflags kdepim-3.2.0-1.4 ---------------- * Tue Feb 24 2004 Than Ngo 6:3.2.0-1.4 - some critical bugs in kmail, #116080 kdesdk-3.2.0-1.4 ---------------- * Tue Feb 24 2004 Than Ngo 2:3.2.0-1.4 - add BuildPrereq on db4-devel kernel-2.6.3-1.106 ------------------ * Tue Feb 24 2004 Dave Jones - Update to 2.6.3-bk6 - Enable lots of ISDN config options. - Several E1000 net driver fixes. - Disable ACARD SCSI driver. (It's very broken right now) kudzu-1.1.46-1 -------------- * Wed Feb 25 2004 Bill Nottingham 1.1.46-1 - write more correct audio lines for 2.6 - fix pcmcia probe to only report the class you asked for * Fri Feb 20 2004 Bill Nottingham 1.1.45-1 - fix various bogosities in new and improved PS/2 probe * Wed Feb 11 2004 Bill Nottingham 1.1.44-1 - new and improved PS/2 probe - requires a 2.6 kernel libbonoboui-2.5.3-1 ------------------- * Tue Feb 24 2004 Mark McLoughlin 2.5.3-1 - Update to 2.5.3 - Remove unused bonoboui-fixed-ltmain.sh libgnome-2.5.90-1 ----------------- * Tue Feb 24 2004 Alexander Larsson 2.5.90-1 - update to 2.5.90 libgnomeui-2.5.90-1 ------------------- * Tue Feb 24 2004 Alexander Larsson 2.5.90-1 - update to 2.5.90 libselinux-1.6-1 ---------------- libwnck-2.5.90-1 ---------------- * Tue Feb 24 2004 Mark McLoughlin 2.5.90-1 - Update to 2.5.90 m2crypto-0.09-5 --------------- * Tue Feb 24 2004 Harald Hoyer - 0.09-5 - changed pythonver from 2.2 to 2.3 - patched setup.py to cope with include path * Fri Feb 13 2004 Elliot Lee - rebuilt metacity-2.7.0-1 ---------------- * Wed Feb 25 2004 Alexander Larsson 2.7.0-1 - update to 2.7.0 - removed reduced resouces patch (its now upstream) mysql-3.23.58-7 --------------- * Tue Feb 24 2004 Tom Lane - fix chown syntax in mysql.init - rebuild nautilus-2.5.8-1 ---------------- * Tue Feb 24 2004 Alexander Larsson 2.5.8-1 - update to 2.5.8 neon-0.24.4-3 ------------- * Wed Feb 25 2004 Joe Orton 0.24.4-3 - use BuildRequires not BuildPrereq, drop autoconf, libtool; -devel requires {openssl,zlib}-devel (#116744) * Fri Feb 13 2004 Elliot Lee 0.24.4-2 - rebuilt * Mon Feb 09 2004 Joe Orton 0.24.4-1 - update to 0.24.4 pciutils-2.1.99.test3-1 ----------------------- pkgconfig-0.15.0-1 ------------------ * Tue Feb 24 2004 Mark McLoughlin - Update to 0.15.0 - Fix datadir patch conflict policycoreutils-1.6-1 --------------------- * Tue Feb 24 2004 Dan Walsh 1.6-1 - Update to latest tarball from NSA postfix-2.0.16-13 ----------------- * Tue Feb 24 2004 John Dennis 2:2.0.16-13 - remove /etc/sysconfig/saslauthd from rpm, fixes bug 113975 postgresql-7.4-7 ---------------- * Tue Feb 24 2004 Tom Lane - Fix chown syntax in postgresql.init also. - Rebuilt * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. procps-3.2.0-1 -------------- * Tue Feb 24 2004 Dan Walsh 3.2.0-1 - New version from upstream rpmdb-fedora-1.90-0.20040225 ---------------------------- selinux-doc-1.6-1 ----------------- * Tue Feb 24 2004 Dan Walsh 1.6-1 - Update with NSA final 1.6 release system-config-display-1.0.8-1 ----------------------------- * Tue Feb 24 2004 Brent Fox 1.0.8-1 - start up metacity to make the windows look nice (bug #108206) system-config-soundcard-1.2.4-1 ------------------------------- * Wed Feb 25 2004 Bill Nottingham 1.2.4-1 - write alsactl lines for 2.6, use amixer to unmute tomcat-4.1.27-10 ---------------- * Tue Feb 24 2004 Gary Benson 4.1.27-10 - Remove mod_webapp and fix mod_jk2 installion. - Temporarily remove the test subpackage's JDBC dependencies. xcdroast-0.98a15-1 ------------------ * Tue Feb 24 2004 Harald Hoyer - 0.98a15-1 - version 0.98alpha15 xcdroast-0.98a15-2 ------------------ * Wed Feb 25 2004 Harald Hoyer - 0.98a15-2 - 64bit patch added - configure patch removing pcre req added * Tue Feb 24 2004 Harald Hoyer - 0.98a15-1 - version 0.98alpha15 xosview-1.8.0-18 ---------------- * Tue Feb 24 2004 Than Ngo 1.8.0-18 - get rid of rpath xsnow-1.42-14 ------------- * Tue Feb 24 2004 Than Ngo 1.42-14 - cleanup codes, #116665 ypbind-1.17.2-1 --------------- * Tue Feb 24 2004 Phil Knirsch 1.17.2-1 - Another updated to latest upstream version. ypserv-2.12.1-1 --------------- * Tue Feb 24 2004 Phil Knirsch 2.12.1-1 - Updated to latest upstream version. yum-2.0.5.20040224-1 -------------------- * Tue Feb 24 2004 Jeremy Katz - 2.0.5.20040224-1 - newer From ms-nospam-0306 at arcor.de Wed Feb 25 17:01:53 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 25 Feb 2004 18:01:53 +0100 Subject: [Packages depending on qt-3.2 ] In-Reply-To: <403BBE22.1070907@cornell.edu> References: <403A54C8.3010701@cornell.edu> <1298.66.91.85.198.1077598502.squirrel@togami.com> <403ADC6D.3050906@cornell.edu> <20040224052435.GI27458@angus.ind.WPI.EDU> <403AE169.3040300@cornell.edu> <1077611513.4617.8.camel@otto.amantes> <20040224124552.GZ23631@redhat.com> <403B6A49.7000109@cornell.edu> <20040224172722.4002d02e.ms-nospam-0306@arcor.de> <403BBD0D.9040905@cornell.edu> <403BBE22.1070907@cornell.edu> Message-ID: <20040225180153.125512e4.ms-nospam-0306@arcor.de> On Tue, 24 Feb 2004 16:12:02 -0500, Ivan Gyurdiev wrote: > > > Well, you're right it seems like my rebuild script was not running in a > > login shell. NOTABUG > > Actually no - I don't know what's going on. > In any case, it seems like it might be my problem instead of a bug. > Are you the maintainer for the kde stuff? I can mail you when I figure > it out.. No, I'm not the maintainer. And instead of e-mail, it would be better to report any findings at https://bugzilla.redhat.com -- From d.jacobfeuerborn at conversis.de Wed Feb 25 17:10:06 2004 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Wed, 25 Feb 2004 18:10:06 +0100 Subject: Kernel lockup problems In-Reply-To: <403B7BED.5050009@conversis.de> References: <403B7BED.5050009@conversis.de> Message-ID: <403CD6EE.3080401@conversis.de> Dennis Jacobfeuerborn wrote: > Hi, > I have been running the kernel-2.6.1-1.65 package on my Fedora Core 1 > box now for quite a while without any problems but yesterday I updated > to kernel-2.6.3-1.97 and since then my machine keeps locking up after > roughly 30-60 minutes. Since I have an nforce2 based board and read on > the lkml that there have been problems with nforce and apic combinations > I also tried using the noapic option but that didn't help. I'm going to > try the new 1.100 package now but what is the proper way to find out > what the problem is in this case? Right now I'm not running any > proprietary kernel modules so I don't have any idea what might cause > this problem. > No luck, the 1.100 package locks up my machine as well so I have to go back to 2.6.1-1.65 for now :( Regards, Dennis From bpm at ec-group.com Wed Feb 25 19:28:17 2004 From: bpm at ec-group.com (Brian Millett) Date: Wed, 25 Feb 2004 13:28:17 -0600 (CST) Subject: evolution ?? Message-ID: <52320.12.41.112.51.1077737297.squirrel@webmail.ec-group.com> I've read that you are rolling back to evolution-1.4.5. I'm currently using 1.5.4. Is there a srpm that has been fixed for the correct dependencies? If not, what packages to I need to roll back? Thanks. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From mgansser at ngi.de Wed Feb 25 20:32:06 2004 From: mgansser at ngi.de (Martin Gansser) Date: Wed, 25 Feb 2004 21:32:06 +0100 Subject: kernel-2.6.3-1.106: Badness in interruptible_sleep_on_timeout atkernel/sched.c:1937 Message-ID: <1077741126.3434.5.camel@gecko> kernel-2.6.3-1.106 reports the following error on dmesg, when the dvb modules are loaded: Linux video capture interface: v1.00 intel8x0_measure_ac97_clock: measured 49379 usecs intel8x0: clocking to 48000 saa7146: register extension 'dvb'. saa7146: found saa7146 @ mem e0a01e00 (revision 1, irq 12) (0x13c2,0x0003). DVB: registering new adapter (Technotrend/Hauppauge PCI rev2.1). probe_tuner: try to attach to Technotrend/Hauppauge PCI rev2.1 drivers/media/dvb/frontends/stv0299.c: setup for tuner BSRU6, TDQB-S00x DVB: registering frontend 0:0 (STV0299/TSA5059/SL1935 based)... Technotrend/Hauppauge PCI rev2.1 adapter 0 has MAC addr = 00:d0:5c:21:3f:ee DVB: AV7111(0) - firm f0240009, rtsl b0250018, vid 71010068, app 8000261b DVB: AV7111(0) - firmware supports CI link layer interface Badness in interruptible_sleep_on_timeout at kernel/sched.c:1937 Call Trace: [] interruptible_sleep_on_timeout+0x5d/0x23a [] default_wake_function+0x0/0xc [] daemonize+0xa1/0xa5 [] dvb_kernel_thread_setup+0xb5/0x154 [dvb_core] [] arm_thread+0x0/0x3a7 [dvb_ttpci] [] arm_thread+0x5e/0x3a7 [dvb_ttpci] [] arm_thread+0x0/0x3a7 [dvb_ttpci] [] kernel_thread_helper+0x5/0xb av7110(0): Crystal audio DAC detected videodev: "av7110" has no release callback. Please fix your driver for proper sysfs support, see http://lwn.net/Articles/36850/ saa7146_vv: saa7146 (0): registered device video0 [v4l2] av7110: found av7110-0. Badness in interruptible_sleep_on_timeout at kernel/sched.c:1937 the error is already reported on the dvb mailinglist http://www.mail-archive.com/linux-dvb linuxtv org/msg14852.html the only working kernel, without this messages is the 2.6.2-1.81 -- viele Gr??e Martin From jakub at redhat.com Wed Feb 25 20:58:21 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 25 Feb 2004 15:58:21 -0500 Subject: Prelink success story :) In-Reply-To: References: Message-ID: <20040225205820.GN31589@devserv.devel.redhat.com> On Wed, Feb 25, 2004 at 03:58:24PM +0000, Keith G. Robertson-Turner wrote: > Guess I've been lucky, but I never really suffered much from the various > prelink related problems that have been reported. > > A total of 2 applications (out of 1603 packages) were b?rked by prelink > on my system, since FC1 was released, namely k3b and kdepim (in fact they > still get b?rked even now by prelink). Even 2 packages being borked by prelink is something I don't like to see. But the question is if it isn't a bug in the applications themselves or libraries they are using. Recently I received a bunch of bugreports which turned out to be e.g. memory management bugs in the application, which just happened to work without prelinking with pure luck and prelinking changed the memory layout slightly and suddenly things started crashing. Can you run the apps under efence or valgrind to see if they don't have these kind of bugs? If they don't, then I'd be very much interested in reproduceable testcase ( tar cjhf `ldd the_binary | awk '{ print $3 }'` the_binary the_binary_unprelinked and steps how to get the crash with the_binary while it works with the_binary_unprelinked). > I got prelink-0.3.0-21 from (Fedora devel) rawhide, but it needs SELinux. It needs SELinux only for execstack (prelink is statically linked and thus has libselinux.a linked into it) and only if it is run on a SELinux capable distribution, so if you don't need the execstack program (most probably you don't), you can safely --nodeps. > 1) ... Is Jakub Jelinek really the *only* guy working on this? For now yes. Of course patches are welcome, if there are enough I might even put it into CVS. > 2) ... Other than in the SRPM, where's the source Luke :) > prelink-20040216.tar.bz2 is missing from people.redhat.com/jakub/prelink I'm usually lazy, so most often it is just the SRPM. From time to time I don't forget and copy it to the above URL. > 3) ... Why was macros.prelink hard coded into the spec as a text block, > rather than as a SourceX file? macros.prelink is rpm specific. The prelink sources attempt to be independent from any package management system. > 4) ... Why isn't there a logrotate file to accompany the included log > file, and come to that, why *package* a log file? Or am I missing > something obvious? The log file is %ghost and was added only because others complained no package owns the file. Logrotate is not used because I don't think it is very much interesting to look at older logs, but you can try to convince me otherwise ;) > Other minor (rpmlint) observations: > > Use of "Copyright" instead of "License" Changed (although, I'll need to tweak my other packages like gcc, glibc, binutils, ...). > Weird 555 and 444 perms Where? rpm -qplv SRPMS/prelink-0.3.0-21.src.rpm x86_64/prelink-0.3.0-21.x86_64.rpm -rw-r--r-- 1 root root 338790 Feb 16 07:34 prelink-20040216.tar.bz2 -rw-r--r-- 1 root root 738 Nov 18 06:42 prelink.conf -rw-rw-r-- 1 root root 1455 Oct 27 14:32 prelink.cron -rw-r--r-- 1 root root 17323 Feb 16 07:47 prelink.spec -rw-rw-r-- 1 root root 818 Sep 14 05:44 prelink.sysconfig -rwxr-xr-x 1 root root 1455 Oct 27 14:32 /etc/cron.daily/prelink -rw-r--r-- 1 root root 738 Nov 18 06:42 /etc/prelink.conf -rw-r--r-- 1 root root 297 Feb 16 09:23 /etc/rpm/macros.prelink -rw-r--r-- 1 root root 818 Sep 14 05:44 /etc/sysconfig/prelink -rwxr-xr-x 1 root root 147456 Feb 16 09:23 /usr/bin/execstack -rwxr-xr-x 1 root root 874720 Feb 16 09:23 /usr/sbin/prelink -rw-r--r-- 1 root root 1204 Feb 16 09:23 /usr/share/man/man8/execstack.8.gz -rw-r--r-- 1 root root 3473 Feb 16 09:23 /usr/share/man/man8/prelink.8.gz > Ghost-without-post errors Why is that an error? The files are %config missingok. > Use of "/etc" instead of %{_sysconfdir} Changed. > Use of %{buildroot} instead of $RPM_BUILD_ROOT (although that seems to be > a point of contention these days, personally I prefer %{buildroot}, since > it is more consistent with the other spec conventions. This is on purpose, %{buildroot} is more readable. > Anyway, I'm just really pleased to have blacklist support in prelink > finally, which I guess leads me to one final question ... why hasn't this > version been officially released yet? (Although maybe I've answered this By officially releasing you mean what exactly? Any release of prelink I do can be considered official... Jakub From nando at ccrma.Stanford.EDU Wed Feb 25 21:24:33 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 25 Feb 2004 13:24:33 -0800 Subject: workaround for 116299? ("Obsoletes:" problem in rpm) In-Reply-To: <200402251224.17431@-mr700> References: <1077658777.2194.24.camel@cmn37.stanford.edu> <200402251224.17431@-mr700> Message-ID: <1077744273.2242.7.camel@cmn37.stanford.edu> > > Hi all... anyone has any idea on how I could work around bug 116299? > > (see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116299) > > > > Basically (in FC1), in certain instances the "Obsoletes:" tag is being > > ignored by rpm in such a way that I cannot change the naming of a > > package (ie: if I try to install the new package, which "Obsoletes:" > > another older package with almost the same contents but a different > > name, the rpm process fails with a "conflicting files" message instead > > of replacing the old package with the new one). > > > > I think... > $ rpm -e oldpackage --nodeps > $ rpm -ihv newpackage > should work... Thanks but sorry, I should have added some context. The packages are coming from an apt repository (Planet CCRMA) and users should not need to do manual rpm operations to upgrade... There is a little bit more information in the bugzilla report now, apparently the file conflict only happens if the binaries that conflict are different (the new from the old). If they are _exactly_ the same the upgrade proceeds normally and the obsoleted package is erased. That would seem to suggest that the test for conflicting flies (inside rpm) is being done before rpm realizes that one package obsoletes the other. Weird. -- Fernando From tony at tgds.net Wed Feb 25 21:52:19 2004 From: tony at tgds.net (Tony Grant) Date: Wed, 25 Feb 2004 22:52:19 +0100 Subject: kernel-2.6.3-1.106: Badness in interruptible_sleep_on_timeout atkernel/sched.c:1937 In-Reply-To: <1077741126.3434.5.camel@gecko> References: <1077741126.3434.5.camel@gecko> Message-ID: <1077745938.23763.9.camel@localhost.localdomain> Le mer 25/02/2004 ? 21:32, Martin Gansser a ?crit : > kernel-2.6.3-1.106 reports the following error on dmesg, > when the dvb modules are loaded: > ...snip > the error is already reported on the dvb mailinglist > http://www.mail-archive.com/linux-dvb linuxtv org/msg14852.html > > the only working kernel, without this messages is the 2.6.2-1.81 Or you could roll your own and use a TechniSat SkyStar 2 Wonderful stable fast kernel 2.6.3 - xine dvb usage is much more stable Cheers Tony Grant -- www.tgds.net Library management software toolkit From devscott at charter.net Wed Feb 25 22:02:39 2004 From: devscott at charter.net (Scott Sloan) Date: Wed, 25 Feb 2004 16:02:39 -0600 Subject: evolution ?? Message-ID: <200402252202.i1PM2dfL051561@mxsf07.cluster1.charter.net> Why are we rolling back to 1.4.5? Scott > > From: "Brian Millett" > Date: 2004/02/25 Wed PM 01:28:17 CST > To: > Subject: evolution ?? > > > I've read that you are rolling back to evolution-1.4.5. I'm currently > using 1.5.4. Is there a srpm that has been fixed for the correct > dependencies? If not, what packages to I need to roll back? > > Thanks. > > -- > Brian Millett > Enterprise Consulting Group "Shifts in paradigms > (314) 205-9030 often cause nose bleeds." > bpmATec-groupDOTcom Greg Glenn > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From katzj at redhat.com Wed Feb 25 22:10:50 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 Feb 2004 17:10:50 -0500 Subject: evolution ?? In-Reply-To: <200402252202.i1PM2dfL051561@mxsf07.cluster1.charter.net> References: <200402252202.i1PM2dfL051561@mxsf07.cluster1.charter.net> Message-ID: <1077747050.11712.6.camel@isengard> On Wed, 2004-02-25 at 17:02, Scott Sloan wrote: > Why are we rolling back to 1.4.5? Evolution 2.0 isn't going to be released until June. The plan is for FC2 to go out in April. The two don't match very well :-) Jeremy From devscott at charter.net Wed Feb 25 22:20:52 2004 From: devscott at charter.net (Scott Sloan) Date: Wed, 25 Feb 2004 16:20:52 -0600 Subject: evolution ?? Message-ID: <200402252220.i1PMKqW8029702@mxsf10.cluster1.charter.net> I suppose that is a good reason, however i know I for one converted all my evolution stuff when I installed FC2. Do these new conversions work in 1.4.5? Scott > > From: Jeremy Katz > Date: 2004/02/25 Wed PM 04:10:50 CST > To: fedora-devel-list at redhat.com > Subject: Re: evolution ?? > > On Wed, 2004-02-25 at 17:02, Scott Sloan wrote: > > Why are we rolling back to 1.4.5? > > Evolution 2.0 isn't going to be released until June. The plan is for > FC2 to go out in April. The two don't match very well :-) > > Jeremy > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From salimma at fastmail.fm Thu Feb 26 00:13:12 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Thu, 26 Feb 2004 07:13:12 +0700 Subject: evolution ?? In-Reply-To: <200402252220.i1PMKqW8029702@mxsf10.cluster1.charter.net> References: <200402252220.i1PMKqW8029702@mxsf10.cluster1.charter.net> Message-ID: <1077754392.2106.1.camel@bushido.mshome.net> Latest Evo packages can be found at Jeremy's site, http://people.redhat.com/jkatz HTH :) - Michel On Wed, 2004-02-25 at 16:20 -0600, Scott Sloan wrote: > I suppose that is a good reason, however i know I for one converted all my evolution stuff when I installed FC2. Do these new conversions work in 1.4.5? > > Scott > > > > > > From: Jeremy Katz > > Date: 2004/02/25 Wed PM 04:10:50 CST > > To: fedora-devel-list at redhat.com > > Subject: Re: evolution ?? > > > > On Wed, 2004-02-25 at 17:02, Scott Sloan wrote: > > > Why are we rolling back to 1.4.5? > > > > Evolution 2.0 isn't going to be released until June. The plan is for > > FC2 to go out in April. The two don't match very well :-) > > > > Jeremy > > > > > > -- > > 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 cturner at redhat.com Thu Feb 26 02:37:08 2004 From: cturner at redhat.com (Chip Turner) Date: 25 Feb 2004 21:37:08 -0500 Subject: (fwd) Perl/mod_perl test update Message-ID: The perl update includes the virtual provides for perl modules to use to rely on when they are built against it as discussed a couple weeks ago. Anyone who can give this a whirl and let me know any breakages, I'd appreciate it; should be a fairly safe update but I want to get 5.8.3 on all supported RHL/RHEL/Fedora releases that are currently in the 5.8.x family. Thanks, Chip -------------- next part -------------- An embedded message was scrubbed... From: Chip Turner Subject: Perl/mod_perl test update Date: 25 Feb 2004 08:53:55 -0500 Size: 4483 URL: -------------- next part -------------- -- Chip Turner cturner at redhat.com Red Hat, Inc. From bill at noreboots.com Thu Feb 26 02:44:11 2004 From: bill at noreboots.com (Bill Anderson) Date: Wed, 25 Feb 2004 19:44:11 -0700 Subject: YUM's shortcomings In-Reply-To: <20040216172301.GD22506@server4.8080.it> References: <1076836918.1174.29.camel@agnes.fremen.dune> <20040216172301.GD22506@server4.8080.it> Message-ID: <403D5D7B.9030009@noreboots.com> Rudi Chiarito wrote: >(some might argue to have bash-completion in FC or even installed by >default) > > I'm one of them! From hvdkooij at vanderkooij.org Thu Feb 26 06:23:33 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Thu, 26 Feb 2004 07:23:33 +0100 (CET) Subject: evolution ?? In-Reply-To: <200402252220.i1PMKqW8029702@mxsf10.cluster1.charter.net> References: <200402252220.i1PMKqW8029702@mxsf10.cluster1.charter.net> Message-ID: On Wed, 25 Feb 2004, Scott Sloan wrote: > I suppose that is a good reason, however i know I for one converted all my evolution stuff when I installed FC2. Do these new conversions work in 1.4.5? Sounds like you try production work on a test release. The Dutch saying "Wie zijn billen brandt, moet op de blaren zitten" (translated roughly as "Whoever burns his bottom will have to sit on the blisters") applies here I guess. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From devscott at charter.net Thu Feb 26 06:40:20 2004 From: devscott at charter.net (Scott Sloan) Date: Thu, 26 Feb 2004 0:40:20 -0600 Subject: evolution ?? Message-ID: <200402260640.i1Q6eKjQ097087@mxsf23.cluster1.charter.net> I'll continue to use the 1.5.4 packages against FC2 until the release of Evolution 2. A.) This will allow me to help debug some of the problems with evolution and FC2. b.) it may not heal the blisters, but it will provide some relief. Scott Sloan ------------ devscott.org > > From: Hugo van der Kooij > Date: 2004/02/26 Thu AM 12:23:33 CST > To: fedora-devel-list at redhat.com > Subject: Re: Re: evolution ?? > > On Wed, 25 Feb 2004, Scott Sloan wrote: > > > I suppose that is a good reason, however i know I for one converted all my evolution stuff when I installed FC2. Do these new conversions work in 1.4.5? > > Sounds like you try production work on a test release. The Dutch saying > "Wie zijn billen brandt, moet op de blaren zitten" (translated roughly as > "Whoever burns his bottom will have to sit on the blisters") applies here > I guess. > > Hugo. > > -- > All email sent to me is bound to the rules described on my homepage. > hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ > Don't meddle in the affairs of sysadmins, > for they are subtle and quick to anger. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From redhat-forums at genesis-x.nildram.co.uk Thu Feb 26 06:49:36 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 26 Feb 2004 06:49:36 +0000 Subject: Prelink success story :) References: <20040225205820.GN31589@devserv.devel.redhat.com> Message-ID: On Wed, 25 Feb 2004 15:58:21 -0500, Jakub Jelinek wrote: > On Wed, Feb 25, 2004 at 03:58:24PM +0000, Keith G. Robertson-Turner > wrote: >> A total of 2 applications (out of 1603 packages) were b?rked by >> prelink > Can you run the apps under efence or valgrind to see if they don't have > these kind of bugs? If they don't, then I'd be very much interested in > reproduceable testcase Sure. Glad to help. I'll look it over later today. >> 3) ... Why was macros.prelink hard coded into the spec as a text block, >> rather than as a SourceX file? > > macros.prelink is rpm specific. The prelink sources attempt to be > independent from any package management system. Sorry, I didn't make that clear. I didn't mean why isn't macros.prelink in the tarball, I meant why isn't it provided as a separate file and listed in the spec as - e.g. - "Source5: macros.prelink". It cleans up the spec, and doesn't break vim's highlighting. >> 4) ... Why isn't there a logrotate file to accompany the included log >> file, and come to that, why *package* a log file? Or am I missing >> something obvious? > > The log file is %ghost and was added only because others complained no > package owns the file. Logrotate is not used because I don't think it > is very much interesting to look at older logs, but you can try to > convince me otherwise ;) OK here goes. First I think that it's a bit OTT for people to expect every file on the FSH to be "owned". /var/log/* is a good example. IMHO packages should not own logs, only root should own that, since removing a package doesn't necessarily mean that the logs are no longer needed. OTOH if the package *is* going to own the log then I think it should ensure that it is properly managed, which includes log rotation. The main thing (for me) about logrotate, is not that it creates log archives, but more the fact that it keeps the current log size manageable. >> Weird 555 and 444 perms > Where? Oops, different package, sorry. I was just quoting from memory, and I was thinking about the build logs from perl-Tk, not your package. >> Ghost-without-post errors > Why is that an error? The files are %config missingok. Beats me, I'm just quoting rpmlint. The two files it complained about are prelink.full and prelink.log. The other ghost file, prelink.force, is mentioned in %post (touch /var/lib/misc/prelink.force), but the other two are not. Putting them in there shuts up rpmlint. >> Use of %{buildroot} instead of $RPM_BUILD_ROOT > This is on purpose, %{buildroot} is more readable. Glad someone agrees with me on that. >> why hasn't this version been officially released yet? > By officially releasing you mean what exactly? Maybe I missed it, but I've been waiting for a "blacklist enabled" version to make it into stable (or is that updates-released), since that's where my up2date/yum/apt sources point to. Did I miss it? - K. From ms-nospam-0306 at arcor.de Thu Feb 26 10:11:26 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 11:11:26 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> Message-ID: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 06:49:36 +0000, Keith G. Robertson-Turner wrote: > >> Use of %{buildroot} instead of $RPM_BUILD_ROOT > > > This is on purpose, %{buildroot} is more readable. > > Glad someone agrees with me on that. In case this targets the fedora.us guidelines, they are due to the following comment from Jeff Johnson (see quoted part at the bottom), http://www.fedora.us/pipermail/fedora-devel/2003-April/001155.html who maybe was taken more serious than necessary. Though, if %buildroot were eliminated "without warning" actually, those who build rpms as root would have fun with the outcome. I can't believe something like that might be done, considering that most (all?) of the packages in Fedora Core use %buildroot. Basically, currently it _does not matter_ whether you use %buildroot or $RPM_BUILD_ROOT because neither one is deprecated. Just don't use both at once. -- From dag at wieers.com Thu Feb 26 11:30:14 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 12:30:14 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 06:49:36 +0000, Keith G. Robertson-Turner wrote: > > > >> Use of %{buildroot} instead of $RPM_BUILD_ROOT > > > > > This is on purpose, %{buildroot} is more readable. > > > > Glad someone agrees with me on that. > > Basically, currently it _does not matter_ whether you use %buildroot or > $RPM_BUILD_ROOT because neither one is deprecated. Just don't use both at > once. Be careful Michael, you're now questioning official fedora.us policy. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ms-nospam-0306 at arcor.de Thu Feb 26 11:52:58 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 12:52:58 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1077132969.9498.775.camel@bobcat.mine.nu> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> <1077049604.9498.613.camel@bobcat.mine.nu> <20040218050539.69608397.ms-nospam-0306@arcor.de> <1077132969.9498.775.camel@bobcat.mine.nu> Message-ID: <20040226125258.1a3b417e.ms-nospam-0306@arcor.de> Let's try out what a new bugzilla keyword will yield. Everyone, who has posted a positive review of a package request in the fedora.us queue, please add the REVIEWED keyword to "Keywords:" field of the bug ticket. That should help upon finding package requests which someone has reviewed already but which need a second review according to the publish criteria. It should also help upon building teams. -- From NOS at Utel.no Thu Feb 26 12:05:48 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Thu, 26 Feb 2004 13:05:48 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <000001c3fc60$365361c0$14aaa8c0@utelsystems.local> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> <1077049604.9498.613.camel@bobcat.mine.nu> <20040218050539.69608397.ms-nospam-0306@arcor.de> <1077132969.9498.775.camel@bobcat.mine.nu> <000001c3fc60$365361c0$14aaa8c0@utelsystems.local> Message-ID: <1077797148.30858.20.camel@localhost.localdomain> On Thu, 2004-02-26 at 13:01, Michael Schwendt wrote: > Let's try out what a new bugzilla keyword will yield. Everyone, who has > posted a positive review of a package request in the fedora.us queue, > please add the > > REVIEWED > > keyword to "Keywords:" field of the bug ticket. That should help upon > finding package requests which someone has reviewed already but which need > a second review according to the publish criteria. It should also help > upon building teams. So one should just set this when one have "voted" for PUBLISH ? Not add it on e.g. "I reviewd it, build failed.." -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From leonard at den.ottolander.nl Thu Feb 26 12:42:07 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Feb 2004 13:42:07 +0100 Subject: CURRENTRELEASE versus NEXTRELEASE Message-ID: <1077799325.4746.7.camel@athlon.localdomain> Hi, I am uncertain about the use of the tag NEXTRELEASE in bugzilla. How should an issue be closed if it was reported for RHL 8.0, but does not exist in FC 1? NEXTRELEASE or CURRENTRELEASE? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From davej at redhat.com Thu Feb 26 13:03:35 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 26 Feb 2004 13:03:35 +0000 Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077799325.4746.7.camel@athlon.localdomain> References: <1077799325.4746.7.camel@athlon.localdomain> Message-ID: <1077800615.30911.0.camel@delerium.codemonkey.org.uk> On Thu, 2004-02-26 at 12:42, Leonard den Ottolander wrote: > Hi, > > I am uncertain about the use of the tag NEXTRELEASE in bugzilla. How > should an issue be closed if it was reported for RHL 8.0, but does not > exist in FC 1? NEXTRELEASE or CURRENTRELEASE? CURRENTRELEASE is FC1 NEXTRELEASE is FC2. Go figure 8-) Dave From leonard at den.ottolander.nl Thu Feb 26 13:07:18 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Feb 2004 14:07:18 +0100 Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077800615.30911.0.camel@delerium.codemonkey.org.uk> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800615.30911.0.camel@delerium.codemonkey.org.uk> Message-ID: <1077800837.4746.9.camel@athlon.localdomain> Hi Dave, > CURRENTRELEASE is FC1 > NEXTRELEASE is FC2. > > Go figure 8-) Yeah, but for RHL 9 FC 1 is NEXTRELEASE. See my point? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ms-nospam-0306 at arcor.de Thu Feb 26 13:33:04 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 14:33:04 +0100 Subject: RFC: fedora.us bugzilla keywords In-Reply-To: <1077797148.30858.20.camel@localhost.localdomain> References: <20040210103220.31921878.ms-nospam-0306@arcor.de> <1076409176.3147.25.camel@localhost.localdomain> <1076437972.20592.41.camel@bobcat.mine.nu> <20040210222935.7b7a0586.ms-nospam-0306@arcor.de> <1076451930.13720.26.camel@bobcat.mine.nu> <20040211004511.52c94705.ms-nospam-0306@arcor.de> <20040213155142.6916307b.ms-nospam-0306@arcor.de> <1076706000.9498.110.camel@bobcat.mine.nu> <20040214005319.6242aee5.ms-nospam-0306@arcor.de> <1076763963.9498.169.camel@bobcat.mine.nu> <1076952688.3227.24.camel@Madison.badger.com> <20040216193710.7f1704f6.ms-nospam-0306@arcor.de> <1077049604.9498.613.camel@bobcat.mine.nu> <20040218050539.69608397.ms-nospam-0306@arcor.de> <1077132969.9498.775.camel@bobcat.mine.nu> <000001c3fc60$365361c0$14aaa8c0@utelsystems.local> <1077797148.30858.20.camel@localhost.localdomain> Message-ID: <20040226143304.569eb495.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 13:05:48 +0100, Nils O. wrote: > On Thu, 2004-02-26 at 13:01, Michael Schwendt wrote: > > Let's try out what a new bugzilla keyword will yield. Everyone, who has > > posted a positive review of a package request in the fedora.us queue, > > please add the > > > > REVIEWED > > > > keyword to "Keywords:" field of the bug ticket. That should help upon > > finding package requests which someone has reviewed already but which need > > a second review according to the publish criteria. It should also help > > upon building teams. > > So one should just set this when one have "voted" for PUBLISH ? Yes, that's what a "positive review" refers to. Not to be confused with the PUBLISH keyword, though. :) > Not add it on e.g. "I reviewd it, build failed.." Exactly. If you want to draw attention to failed builds, there's the NEEDSWORK keyword already as a flag or a call for help. -- From ms-nospam-0306 at arcor.de Thu Feb 26 13:34:50 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 14:34:50 +0100 Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077800837.4746.9.camel@athlon.localdomain> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800615.30911.0.camel@delerium.codemonkey.org.uk> <1077800837.4746.9.camel@athlon.localdomain> Message-ID: <20040226143450.5a139afa.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 14:07:18 +0100, Leonard den Ottolander wrote: > Hi Dave, > > > CURRENTRELEASE is FC1 > > NEXTRELEASE is FC2. > > > > Go figure 8-) > > Yeah, but for RHL 9 FC 1 is NEXTRELEASE. See my point? Isn't it more like "at the time you close the report, current release is FC 1, next release is FC 2"? -- From leonard at den.ottolander.nl Thu Feb 26 14:28:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Feb 2004 15:28:02 +0100 Subject: More gnome-panel issues Message-ID: <1077805682.4746.13.camel@athlon.localdomain> Hi, If I didn't make any mistakes the gnome-panel issues list at http://www.ottolander.nl/gnome-panel/ should now be complete. Let me know if I missed some bugs (FC 2 test 1 are listed but not in the overview) or made some mistake somewhere. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Feb 26 14:31:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Feb 2004 15:31:04 +0100 Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <20040226143450.5a139afa.ms-nospam-0306@arcor.de> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800615.30911.0.camel@delerium.codemonkey.org.uk> <1077800837.4746.9.camel@athlon.localdomain> <20040226143450.5a139afa.ms-nospam-0306@arcor.de> Message-ID: <1077805864.4746.15.camel@athlon.localdomain> Hi Michael, > Isn't it more like "at the time you close the report, current release > is FC 1, next release is FC 2"? Yeah, maybe I am complicating things a bit. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mitr at volny.cz Thu Feb 26 15:40:12 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 26 Feb 2004 16:40:12 +0100 Subject: EOLed products and CURRENTRELEASE Message-ID: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> Hello, Would anybody object to closing bugs in EOLed products (currently RHL < 9) that are fixed in FC1 as CURRENTRELEASE? Mirek From laroche at redhat.com Thu Feb 26 15:44:21 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 26 Feb 2004 16:44:21 +0100 Subject: EOLed products and CURRENTRELEASE In-Reply-To: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> Message-ID: <20040226154421.GA10561@dudweiler.stuttgart.redhat.com> On Thu, Feb 26, 2004 at 04:40:12PM +0100, Miloslav Trmac wrote: > Hello, > Would anybody object to closing bugs in EOLed products (currently > RHL < 9) that are fixed in FC1 as CURRENTRELEASE? That should be ok, Florian La Roche From david.paeme at belbone.net Thu Feb 26 15:47:08 2004 From: david.paeme at belbone.net (david paeme) Date: Thu, 26 Feb 2004 16:47:08 +0100 Subject: dhcp weirdness In-Reply-To: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> Message-ID: <1077810428.9923.4.camel@owsdavid> Hi again... is anybody seeing the strange dhcp stuff as i am? here's the is the problem: my notebook's eth0 is configured with a fixed ip address (from my home network). but when I do a dhcp (dhclient) query (dhcp-server is a big cisco), my interface gets a new address, but the loopback interface -- lo -- loses its address. lo stays up, but there's no 127.0.0.1 anymore on the system, with all problems that follow... anyone got an idea how this happens? dhcp spec that isn't followed properly? anybody seen this behaviour before? thanks, d. ps: fc1 running on that machine, latest updates From david.paeme at belbone.net Thu Feb 26 15:55:27 2004 From: david.paeme at belbone.net (david paeme) Date: Thu, 26 Feb 2004 16:55:27 +0100 Subject: dhcp weirdness In-Reply-To: <1077810428.9923.4.camel@owsdavid> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> <1077810428.9923.4.camel@owsdavid> Message-ID: <1077810927.9923.6.camel@owsdavid> sorry for disturbing the thread... d. On Thu, 2004-02-26 at 16:47, david paeme wrote: > Hi again... > > is anybody seeing the strange dhcp stuff as i am? > here's the is the problem: > > my notebook's eth0 is configured with a fixed ip address (from my home > network). but when I do a dhcp (dhclient) query (dhcp-server is a big > cisco), my interface gets a new address, but the loopback interface -- > lo -- loses its address. > > lo stays up, but there's no 127.0.0.1 anymore on the system, with all > problems that follow... > > > anyone got an idea how this happens? dhcp spec that isn't followed > properly? > > anybody seen this behaviour before? > > > thanks, > > > d. > > ps: fc1 running on that machine, latest updates > From pmatilai at welho.com Thu Feb 26 15:59:02 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 26 Feb 2004 17:59:02 +0200 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> Message-ID: <1077811141.8186.23.camel@chip.laiskiainen.org> On Thu, 2004-02-26 at 13:30, Dag Wieers wrote: > On Thu, 26 Feb 2004, Michael Schwendt wrote: > > > On Thu, 26 Feb 2004 06:49:36 +0000, Keith G. Robertson-Turner wrote: > > > > > >> Use of %{buildroot} instead of $RPM_BUILD_ROOT > > > > > > > This is on purpose, %{buildroot} is more readable. > > > > > > Glad someone agrees with me on that. > > > > Basically, currently it _does not matter_ whether you use %buildroot or > > $RPM_BUILD_ROOT because neither one is deprecated. Just don't use both at > > once. > > Be careful Michael, you're now questioning official fedora.us policy. Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT instead of %{buildroot} all the way and still am (simply because %{buildroot} is faster to type and also mixes better with all the %{_libdir} macros and such visually), and there were/are others as well. OTOH that's what a community project is about: you get to express your opinion and vote, doesn't mean your vote is the one that counts. Compromises, in other words. - Panu - From leonard at den.ottolander.nl Thu Feb 26 16:28:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Feb 2004 17:28:09 +0100 Subject: EOLed products and CURRENTRELEASE In-Reply-To: <20040226154421.GA10561@dudweiler.stuttgart.redhat.com> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> <20040226154421.GA10561@dudweiler.stuttgart.redhat.com> Message-ID: <1077812889.4746.17.camel@athlon.localdomain> Hi Florian, > > Would anybody object to closing bugs in EOLed products (currently > > RHL < 9) that are fixed in FC1 as CURRENTRELEASE? > > That should be ok, How about the case where the product is RHL 9? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dag at wieers.com Thu Feb 26 16:31:57 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 17:31:57 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <1077811141.8186.23.camel@chip.laiskiainen.org> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: On Thu, 26 Feb 2004, Panu Matilainen wrote: > On Thu, 2004-02-26 at 13:30, Dag Wieers wrote: > > On Thu, 26 Feb 2004, Michael Schwendt wrote: > > > > > On Thu, 26 Feb 2004 06:49:36 +0000, Keith G. Robertson-Turner wrote: > > > > > > > >> Use of %{buildroot} instead of $RPM_BUILD_ROOT > > > > > > > > > This is on purpose, %{buildroot} is more readable. > > > > > > > > Glad someone agrees with me on that. > > > > > > Basically, currently it _does not matter_ whether you use %buildroot or > > > $RPM_BUILD_ROOT because neither one is deprecated. Just don't use both at > > > once. > > > > Be careful Michael, you're now questioning official fedora.us policy. > > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT > instead of %{buildroot} all the way and still am (simply because > %{buildroot} is faster to type and also mixes better with all the > %{_libdir} macros and such visually), and there were/are others as well. I know you were and I've seen more people against that policy than in favor of it on the mailinglist. > OTOH that's what a community project is about: you get to express your > opinion and vote, doesn't mean your vote is the one that counts. > Compromises, in other words. Well, I'd like to see the votes again ;) As my impression was that decisions were made on IRC and/or mainly based on expressions by a famous Red Hat developer I dare not mention ;) We've got some others like the infamous 'Epoch must be included even if zero' decision, or the 'Source-tag may not have macros' decision, or the 'We dont like to mix repositories' decision and countless others. In the end I think those people that cared, didn't vote anymore. I know I didn't. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From laroche at redhat.com Thu Feb 26 16:32:52 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 26 Feb 2004 17:32:52 +0100 Subject: EOLed products and CURRENTRELEASE In-Reply-To: <1077812889.4746.17.camel@athlon.localdomain> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> <20040226154421.GA10561@dudweiler.stuttgart.redhat.com> <1077812889.4746.17.camel@athlon.localdomain> Message-ID: <20040226163252.GA11498@dudweiler.stuttgart.redhat.com> On Thu, Feb 26, 2004 at 05:28:09PM +0100, Leonard den Ottolander wrote: > Hi Florian, > > > > Would anybody object to closing bugs in EOLed products (currently > > > RHL < 9) that are fixed in FC1 as CURRENTRELEASE? > > > > That should be ok, > > How about the case where the product is RHL 9? I am myself closing smaller bugs where I know I will not make an update release available, but will only fix this in the current release. greetings, Florian La Roche From heinlein at madboa.com Thu Feb 26 16:44:34 2004 From: heinlein at madboa.com (Paul Heinlein) Date: Thu, 26 Feb 2004 08:44:34 -0800 (PST) Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: On Thu, 26 Feb 2004, Dag Wieers wrote: > the 'Source-tag may not have macros' decision I admittedly don't read every post on rpm-list, but I've never seen that discussion. Google isn't helping. Got a pointer? --Paul Heinlein From ville.skytta at iki.fi Thu Feb 26 16:45:35 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 Feb 2004 18:45:35 +0200 Subject: Prelink success story :) In-Reply-To: <1077811141.8186.23.camel@chip.laiskiainen.org> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: <1077813935.6550.13.camel@bobcat.mine.nu> On Thu, 2004-02-26 at 17:59, Panu Matilainen wrote: > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT It's not mandatory. It just happens to be in the specfile templates as well as recommended in the QA checklist because of its "official" status according to jbj's comments. From ghenry at suretecsystems.com Thu Feb 26 16:45:34 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 26 Feb 2004 16:45:34 +0000 Subject: Prelink success story :) In-Reply-To: References: <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: <200402261645.42671.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 February 2004 16:31, Dag Wieers wrote: > We've got some others like the infamous 'Epoch must be included even if > zero' decision, or the 'Source-tag may not have macros' decision, or the > 'We dont like to mix repositories' decision and countless others. > > In the end I think those people that cared, didn't vote anymore. I know I > didn't. > > -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- > [Any errors in spelling, tact or fact are transmission errors] Personally, I would like a concrete document so I know which way to do things. Dag has been kindly helping me a lot, and regarding submitting packages, I would like to be 100% sure that the way I am learning is the right way and will be accepted for submission (depending on the quality of the specfile obviously). I have changed to Dag's way at the moment ;-) Thanks again Dag. - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAPiKyeWseh9tzvqgRAnmRAJ0YSPR3IQqXogvwy/vYtC2VhfcCJwCgjQbH 3eQijr6WAuqebAj9qnO5rYI= =iV1K -----END PGP SIGNATURE----- From ville.skytta at iki.fi Thu Feb 26 16:55:12 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 Feb 2004 18:55:12 +0200 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: <1077814511.6550.23.camel@bobcat.mine.nu> On Thu, 2004-02-26 at 18:44, Paul Heinlein wrote: > On Thu, 26 Feb 2004, Dag Wieers wrote: > > > the 'Source-tag may not have macros' decision > > I admittedly don't read every post on rpm-list, but I've never seen > that discussion. Google isn't helping. Got a pointer? The discussion was on fedora.us lists but it has never been a "decision" or mandatory IIRC. Anyway many people doing QA prefer macroless URLs because it makes upstream source verification easier (think copy-paste). (On the other hand, proper upstream source verification is not IMO satisfied just by copy-pasting the URL and verifying the md5sum, but to also check that it's the expected, in some way official URL. And iff SourceX's are *not URLs*, I can't figure out why macros shouldn't be used as much as possible. So it really does not matter much. History has shown though that URLs with macros tend to bitrot, resulting in incorrect URLs every now and then. Not that it would be a huge deal or a "blocker" either :) From hvdkooij at vanderkooij.org Thu Feb 26 17:31:28 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Thu, 26 Feb 2004 18:31:28 +0100 (CET) Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: On Thu, 26 Feb 2004, Dag Wieers wrote: > Well, I'd like to see the votes again ;) > > As my impression was that decisions were made on IRC and/or mainly based > on expressions by a famous Red Hat developer I dare not mention ;) IRC is a bad thing to use for decisions. Anyone with any real world view of time differences knows you can't use real-time methods for important issues. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From dag at wieers.com Thu Feb 26 17:33:28 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 18:33:28 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <1077813935.6550.13.camel@bobcat.mine.nu> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> Message-ID: On Thu, 26 Feb 2004, Ville Skytt? wrote: > On Thu, 2004-02-26 at 17:59, Panu Matilainen wrote: > > > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT > > It's not mandatory. It just happens to be in the specfile templates as > well as recommended in the QA checklist because of its "official" status > according to jbj's comments. Well, it used to be mandatory and all the QA checklist still require it. It can't be more mandatory than that imo. I guess someone has to remove it from the Wiki then ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From pmatilai at welho.com Thu Feb 26 17:33:14 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 26 Feb 2004 19:33:14 +0200 Subject: Prelink success story :) In-Reply-To: <1077813935.6550.13.camel@bobcat.mine.nu> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> Message-ID: <1077816794.8186.68.camel@chip.laiskiainen.org> On Thu, 2004-02-26 at 18:45, Ville Skytt? wrote: > On Thu, 2004-02-26 at 17:59, Panu Matilainen wrote: > > > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT > > It's not mandatory. It just happens to be in the specfile templates as > well as recommended in the QA checklist because of its "official" status > according to jbj's comments. "should be replaced with $RPM_BUILD_ROOT", combined with QA complaining about %{buildroot} usage makes it mandatory in practise. If it's not supposed to be mandatory then the QA checklist should say "check for consistent use of %{buildroot} vs $RPM_BUILD_ROOT" instead of what's there now. It's not like things like this are the biggest deal in existence, it's just IMHO an arbitrary rule which to me are somewhat irritanting. - Panu - From dag at wieers.com Thu Feb 26 17:40:18 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 18:40:18 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <1077814511.6550.23.camel@bobcat.mine.nu> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> Message-ID: On Thu, 26 Feb 2004, Ville Skytt? wrote: > On Thu, 2004-02-26 at 18:44, Paul Heinlein wrote: > > On Thu, 26 Feb 2004, Dag Wieers wrote: > > > > > the 'Source-tag may not have macros' decision > > > > I admittedly don't read every post on rpm-list, but I've never seen > > that discussion. Google isn't helping. Got a pointer? > > The discussion was on fedora.us lists but it has never been a "decision" > or mandatory IIRC. Anyway many people doing QA prefer macroless URLs > because it makes upstream source verification easier (think copy-paste). Well, if it's not a macro, you may have the situation where someone changes the version, forgets to change the Source-tag and releases a newer version with older software. Would the QA person notice that ? > (On the other hand, proper upstream source verification is not IMO > satisfied just by copy-pasting the URL and verifying the md5sum, but to > also check that it's the expected, in some way official URL. And iff > SourceX's are *not URLs*, I can't figure out why macros shouldn't be > used as much as possible. So it really does not matter much. History > has shown though that URLs with macros tend to bitrot, resulting in > incorrect URLs every now and then. Not that it would be a huge deal or > a "blocker" either :) I'm not against automatic verification of URLs ;) On the contrary. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ms-nospam-0306 at arcor.de Thu Feb 26 17:43:49 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 18:43:49 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> Message-ID: <20040226184349.4eadb126.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 17:31:57 +0100 (CET), Dag Wieers wrote: > > > > Basically, currently it _does not matter_ whether you use %buildroot or > > > > $RPM_BUILD_ROOT because neither one is deprecated. Just don't use both at > > > > once. > > > > > > Be careful Michael, you're now questioning official fedora.us policy. > > > > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT > > instead of %{buildroot} all the way and still am (simply because > > %{buildroot} is faster to type and also mixes better with all the > > %{_libdir} macros and such visually), and there were/are others as well. > > I know you were and I've seen more people against that policy than in > favor of it on the mailinglist. Is it a policy? A policy as in "blocker criterion"? ;) Great. I tell you what: I don't care. Because it would mean that a src.rpm taken from Red Hat Enterprise Linux and modified slightly would be insufficient. That cannot be true, in particular not with regard to the "patches" repository. > > OTOH that's what a community project is about: you get to express your > > opinion and vote, doesn't mean your vote is the one that counts. > > Compromises, in other words. > > Well, I'd like to see the votes again ;) > > As my impression was that decisions were made on IRC and/or mainly based > on expressions by a famous Red Hat developer I dare not mention ;) As pointed out by me quite some time ago, I find some of the groundwork over-ambitious. But I haven't seen anyone blocking the release of a working package because it used %buildroot. Most packages have lots of other issues, real issues. > We've got some others like the infamous 'Epoch must be included even if > zero' decision, Which has had a good reason. > or the 'Source-tag may not have macros' decision, Macros in URLs simply don't work. If you want macros in Source tags, cut off everything up to the file name like Source0: %name-%version.tar.gz and put an example download URL as a comment, e.g. # ftp://ftp.foo.bar/foo/foo-1.0.tar.gz Source0: %name-%version.tar.gz Certainly much better than weird constructs like Source0: http://www.foo.bar/%name/%version/%name-%{version}rc1.tar.gz (note the ugly "rc1" hack) > or the > 'We dont like to mix repositories' decision and countless others. That's more of a "we cannot -- unless there would be very tight cooperation". -- From bart.martens at chello.be Thu Feb 26 17:55:31 2004 From: bart.martens at chello.be (Bart Martens) Date: Thu, 26 Feb 2004 18:55:31 +0100 Subject: EOLed products and CURRENTRELEASE In-Reply-To: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> Message-ID: <1077818131.3734.10.camel@localhost.localdomain> On Thu, 2004-02-26 at 16:40, Miloslav Trmac wrote: > Hello, > Would anybody object to closing bugs in EOLed products (currently > RHL < 9) that are fixed in FC1 as CURRENTRELEASE? > Mirek Some of these bugs may still be interesting for Fedora Legacy. For bugs in fedora.us bugzilla, add the keyword LEGACY, to have these bugs appear in the selection for Fedora Legacy. I don't know what to do with the bugs in redhat bugzilla. I'm having the impression that there are no references to redhat bugzilla on the Fedora Legacy website. Should these bugs be moved to the fedora.us bugzilla? Anyway, my point is, don't close these bugs too quickly. http://www.fedoralegacy.org/ http://www.fedora.us/LEGACY -------------- 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 bart.martens at chello.be Thu Feb 26 18:03:04 2004 From: bart.martens at chello.be (Bart Martens) Date: Thu, 26 Feb 2004 19:03:04 +0100 Subject: EOLed products and CURRENTRELEASE In-Reply-To: <1077812889.4746.17.camel@athlon.localdomain> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> <20040226154421.GA10561@dudweiler.stuttgart.redhat.com> <1077812889.4746.17.camel@athlon.localdomain> Message-ID: <1077818584.3734.17.camel@localhost.localdomain> On Thu, 2004-02-26 at 17:28, Leonard den Ottolander wrote: > Hi Florian, > > > Would anybody object to closing bugs in EOLed products (currently > > > RHL < 9) that are fixed in FC1 as CURRENTRELEASE? > > > > That should be ok, > > How about the case where the product is RHL 9? Good question. Rh9 will be end of life soon. So some bugs may fall into the scope of Fedora Legacy soon. Maybe it's a good idea to already mark these bugs for Fedora Legacy, if a solution and/or an update is not to be expected before the end of life. http://www.fedoralegacy.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Thu Feb 26 18:19:25 2004 From: buildsys at redhat.com (Build System) Date: Thu, 26 Feb 2004 13:19:25 -0500 Subject: rawhide report: 20040226 changes Message-ID: <200402261819.i1QIJPR21349@porkchop.devel.redhat.com> New package emacspeak emacspeak -- The Complete Audio Desktop New package tclx Extensions for Tcl and Tk Updated Packages: XFree86-4.3.0-60 ---------------- * Sun Feb 22 2004 Mike A. Harris 4.3.0-60 - Added XFree86-4.3.0-keyboard-disable-ioport-access-v2.patch to try to fix (#115769) - Changed mkxauth to call chown as foo:bar instead of foo.bar as the latter syntax has been deprecated - Added XFree86-4.3.0-minor-typo.patch to fix a trivial typo that I spotted in an error message in linux int10 code. - Remove Buildrequires kudzu-devel, pciutils-devel, both of which were added on Mar 21, 2001 when Glide3 was included in the XFree86 packaging, but are no longer necessary. I detected this when the buildsystem failed my build due to being unable to meet the dependancy on kudzu-devel, and further investigation showed that dependancy is no longer necessary. - Added XFree86-4.3.0-xcursorgen-check-malloc-return.patch to make xcursorgen check the return codes on malloc before referencing allocated memory - Added XFree86-4.3.0-redhat-xcursorgen-do-not-build-included-cursors.patch to stop building the XFree86 supplied Xcursor cursors as we do not ship them anaconda-9.91-0.20040225180009 ------------------------------ * Wed Feb 25 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) atk-1.5.5-1 ----------- * Wed Feb 25 2004 Mark McLoughlin 1.5.5-1 - Update to 1.5.5. audiofile-0.2.5-1 ----------------- * Wed Feb 25 2004 Alexander Larsson 1:0.2.5-1 - update to 0.2.5 bug-buddy-2.5.90-1 ------------------ * Thu Feb 26 2004 Alexander Larsson 1:2.5.90-1 - update to 2.5.90 control-center-2.5.3-1 ---------------------- * Wed Feb 25 2004 Alexander Larsson 1:2.5.3-1 - update to 2.5.3 coreutils-5.2.0-8 ----------------- * Wed Feb 25 2004 Tim Waugh 5.2.0-8 - kill(1) offloaded to util-linux altogether. dbus-0.20-4 ----------- * Wed Feb 25 2004 Bill Nottingham 0.20-4 - fix dbus error functions on x86-64 (#116324) - add prereq (#112027) devhelp-0.8.1-1 --------------- * Thu Feb 26 2004 Alexander Larsson 0.8.1-1 - update to 0.8.1 * Fri Feb 13 2004 Elliot Lee - rebuilt * Mon Dec 01 2003 Jonathan Blandford 0.7.0-1 - new version - Remove .la and .a files. doxygen-1.3.6-1 --------------- * Thu Feb 26 2004 Than Ngo 1:1.3.6-1 - update to 1.3.6 - added more buildrequires, #110752 eject-2.0.13-5 -------------- * Wed Feb 25 2004 Than Ngo 2.0.13-5 - don't use kernel headers directly, #116613 eog-2.5.6-1 ----------- * Thu Feb 26 2004 Alexander Larsson 2.5.6-1 - update to 2.5.6 fam-2.6.10-3 ------------ * Wed Feb 25 2004 Than Ngo 2.6.10-3 - fixed gcc 3.4 build problem file-roller-2.5.5-1 ------------------- * Thu Feb 26 2004 Alexander Larsson 2.5.5-1 - update to 2.5.5 gdm-2.5.90.1-1 -------------- * Thu Feb 26 2004 Alexander Larsson 1:2.5.90.1-1 - update to 2.5.90.1 ggv-2.5.4-1 ----------- * Thu Feb 26 2004 Alexander Larsson 2.5.4-1 - update to 2.5.4 gkrellm-2.1.26-1 ---------------- * Wed Feb 25 2004 Karsten Hopp 2.1.26-1 - update to 2.1.26, which fixes sensor data being 10x to high (#115850) - requires kernel >= 2.6.2 glib2-2.3.3-1 ------------- * Wed Feb 25 2004 Mark McLoughlin 2.3.3-1 - Update to 2.3.3 * Fri Feb 13 2004 Elliot Lee - rebuilt gnome-terminal-2.5.90-1 ----------------------- * Wed Feb 25 2004 Alexander Larsson 2.5.90-1 - update to 2.5.90 gnome-themes-2.5.4-1 -------------------- * Wed Feb 25 2004 Alexander Larsson 2.5.4-1 - update to 2.5.4 gnome-utils-2.5.2-3 ------------------- * Thu Feb 26 2004 Alexander Larsson 1:2.5.2-3 - update zenity, gcalctool, gucharmap gnomemeeting-1.0-1 ------------------ * Thu Feb 26 2004 Alexander Larsson 1.0-1 - update to 1.0 final gpdf-0.123-1 ------------ * Wed Feb 25 2004 Alexander Larsson 0.123-1 - update to 1.123 grub-0.94-3 ----------- * Wed Feb 25 2004 Jeremy Katz 0.94-3 - don't use initrd_max_address * Fri Feb 13 2004 Elliot Lee 0.94-2 - rebuilt * Thu Feb 12 2004 Jeremy Katz 0.94-1 - update to 0.94, patch merging and updating as necessary gthumb-2.3.1-1 -------------- * Wed Feb 25 2004 Alexander Larsson 2.3.1-1 - update to 2.3.1 gtkhtml2-2.5.5-1 ---------------- * Wed Feb 25 2004 Alexander Larsson 2.5.5-1 - update to 2.5.5 gtksourceview-0.9.1-1 --------------------- * Thu Feb 26 2004 Alexander Larsson 0.9.1-1 - update to 0.9.1 iiimf-le-inpinyin-0.2-2 ----------------------- * Wed Feb 25 2004 Yu Shao - a fix for wrongly commit last committed character when key event is interm * Wed Feb 25 2004 Yu Shao - enhanced preedit string handling, stronger input events filter im-sdk-11.4-18 -------------- * Thu Feb 26 2004 Akira TAGOH 1:11.4-18 - im-sdk-11.4-canna-user-init-file.patch: applied to allow to use user owned .canna file. - im-sdk-11.4-canna-draw-off-status.patch: applied to fix empty status window (#116444) - im-sdk-11.4-initscript.patch: use --user for htt daemon and don't use suid. (#116904) * Wed Feb 25 2004 Yu Shao - let htt, httx run as user htt instead of root(#116556) jfsutils-1.1.4-1 ---------------- * Thu Feb 26 2004 Jeff Garzik - Version 1.1.4 kdeutils-3.2.0-1.2 ------------------ * Wed Feb 25 2004 Than Ngo 6:3.2.0-1.2 - gcc 3.4 build problem kernel-2.6.3-1.109 ------------------ * Wed Feb 25 2004 Dave Jones - Update to 2.6.3-bk7 - Change a slew of config options to match those in arjanv's kernel. Lots of "surely no-one is using this anymore" options are now disabled, along with lots of "this is broken anyway" options. - Numerous fixes to various modules to fix panics on unload. kernel-utils-2.4-9.1.101.fedora ------------------------------- * Mon Oct 20 2003 Arjan van de Ven 2.4.8-39 - update smartmontools to version 5.21 * Thu Oct 16 2003 Arjan van de Ven 2.4.8-38 - add /usr/bin/hardlink * Mon Sep 08 2003 Arjan van de Ven 2.4.8-36 - update smartmontools to a 64 bit clean version - update irqbalance kernel-utils-2.4-9.1.121 ------------------------ koffice-1.3-5 ------------- * Wed Feb 25 2004 Than Ngo 4:1.3-5 - add patch files from CVS libgnomecanvas-2.5.90-1 ----------------------- * Wed Feb 25 2004 Alexander Larsson 2.5.90-1 - 2.5.90 libgnomeprint22-2.5.3-1 ----------------------- * Thu Feb 26 2004 Alexander Larsson 2.5.3-1 - update to 2.5.3 libgnomeprintui22-2.5.3-1 ------------------------- * Thu Feb 26 2004 Alexander Larsson 2.5.3-1 - update to 2.5.3 libgtop2-2.5.1-1 ---------------- * Wed Feb 25 2004 Alexander Larsson 2.5.1-1 - update to 2.5.1 magicdev-1.1.6-1 ---------------- * Wed Feb 25 2004 Alexander Larsson 1.1.6-1 - update to 1.1.6 ncurses-5.4-3 ------------- * Wed Feb 25 2004 Adrian Havill 5.4-3 - link "xterm" to "xterm-color" as temp fix for escape problem (#115448) - remove old zcat for PATCH1 openh323-1.13.2-1 ----------------- * Thu Feb 26 2004 Alexander Larsson 1.13.2-1 - update to 1.13.2 final pango-1.3.3-1 ------------- * Wed Feb 25 2004 Mark McLoughlin 1.3.3-1 - Update to 1.3.3 policy-1.6-8 ------------ * Tue Feb 24 2004 Dan Walsh 1.6-8 - Cleanup some of the merge * Tue Feb 24 2004 Dan Walsh 1.6-7 - Merge russell's changes. * Mon Feb 23 2004 Dan Walsh 1.6-6 - Add Udev policy postgresql-7.4.1-1 ------------------ * Wed Feb 25 2004 Tom Lane - Update to PostgreSQL 7.4.1. - Rebuilt pwlib-1.6.3-1 ------------- * Thu Feb 26 2004 Alexander Larsson 1.6.3-1 - update to 1.6.3 final radvd-0.7.2-7 ------------- * Tue Feb 24 2004 Elliot Lee 0.7.2-7 - Include COPYRIGHT to fix #115998 reiserfs-utils-3.6.11-3 ----------------------- * Thu Feb 26 2004 Jeff Garzik - Use %ix86 macro rpmdb-fedora-1.90-0.20040226 ---------------------------- rusers-0.17-37 -------------- * Wed Feb 25 2004 Phil Knirsch 0.17-37 - rebuilt against latest procps lib. - built stuff with PIE enabled. setarch-1.4-1 ------------- * Tue Feb 24 2004 Elliot Lee 1.4-1 - Fix man page - #115552 * Wed Jan 14 2004 Elliot Lee 1.3-2 - Rebuild * Tue Sep 02 2003 Elliot Lee 1.3-1 - Add linux32 alias system-config-boot-0.2.2-2 -------------------------- * Thu Nov 06 2003 Harald Hoyer 0.2.0-1 - changed python version * Thu Nov 06 2003 Harald Hoyer 0.1.7-1 - fixed #109266 * Thu Oct 30 2003 Harald Hoyer 0.1.6-1 - fixed #106796 - added exception handling udev-018-1 ---------- * Wed Feb 25 2004 Harald Hoyer - 018-1 - changes permissions and rules util-linux-2.12-4 ----------------- * Mon Feb 23 2004 Elliot Lee 2.12-4 - Remove /bin/kill for #116100 yelp-2.5.6-1 ------------ * Wed Feb 25 2004 Alexander Larsson 2.5.6-1 - update to 2.5.6 From ms-nospam-0306 at arcor.de Thu Feb 26 18:21:03 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 19:21:03 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> Message-ID: <20040226192103.10955e4e.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 18:40:18 +0100 (CET), Dag Wieers wrote: > > > > the 'Source-tag may not have macros' decision > > > > > > I admittedly don't read every post on rpm-list, but I've never seen > > > that discussion. Google isn't helping. Got a pointer? > > > > The discussion was on fedora.us lists but it has never been a "decision" > > or mandatory IIRC. Anyway many people doing QA prefer macroless URLs > > because it makes upstream source verification easier (think copy-paste). > > Well, if it's not a macro, you may have the situation where someone > changes the version, forgets to change the Source-tag and releases a newer > version with older software. Would the QA person notice that ? Yes, because the build would fail in %setup. And the QA person takes a look at the src.rpm diff against the previous release. -- From toshio at tiki-lounge.com Thu Feb 26 18:23:28 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 26 Feb 2004 13:23:28 -0500 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> Message-ID: <1077819807.4875.29.camel@Madison.badger.com> On Thu, 2004-02-26 at 12:40, Dag Wieers wrote: > > > > the 'Source-tag may not have macros' decision > > Well, if it's not a macro, you may have the situation where someone > changes the version, forgets to change the Source-tag and releases a newer > version with older software. Would the QA person notice that ? Uhmm... 1] Most of the time this will fail because the builder only has the new source in the SOURCE area. 2] If we have a messy SOURCE area, it will still fail because the tarball will create the directory foo-oldver and the rpmbuild process will try (and fail) to access foo-newver. 3] In the few cases where this doesn't fail (because someone decided to use %setup -n foo-oldver [I've never seen this construct, only %{name}-%{version} which will fail b/c #2] or the tarball doesn't include versions in its toplevel directory [I have seen this]) you do have to rely on your QA people. But it is pretty obvious to spot. (Why am I downloading the 0.12 tarball to build the 0.15 RPM?) -Toshio -- Toshio From ms-nospam-0306 at arcor.de Thu Feb 26 18:36:25 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 19:36:25 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> Message-ID: <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 18:33:28 +0100 (CET), Dag Wieers wrote: > On Thu, 26 Feb 2004, Ville Skytt? wrote: > > > On Thu, 2004-02-26 at 17:59, Panu Matilainen wrote: > > > > > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT > > > > It's not mandatory. It just happens to be in the specfile templates as > > well as recommended in the QA checklist because of its "official" status > > according to jbj's comments. > > Well, it used to be mandatory and all the QA checklist still require it. > It can't be more mandatory than that imo. I guess someone has to remove it > from the Wiki then ;) That infamous "QA checklist" is misunderstood frequently. It is hopelessly incomplete. If you go through it step by step upon reviewing a package, you can miss many other issues. If, however, the checklist were extended, it would grow *a lot* and increase the hurdle to QA significantly. The list in its current form just gives inspiration on what might be worth examining. -- From dag at wieers.com Thu Feb 26 18:39:31 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 19:39:31 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 18:33:28 +0100 (CET), Dag Wieers wrote: > > > On Thu, 26 Feb 2004, Ville Skytt? wrote: > > > > > On Thu, 2004-02-26 at 17:59, Panu Matilainen wrote: > > > > > > > Shrug, he's not alone in that. I was against *mandating* $RPM_BUILD_ROOT > > > > > > It's not mandatory. It just happens to be in the specfile templates as > > > well as recommended in the QA checklist because of its "official" status > > > according to jbj's comments. > > > > Well, it used to be mandatory and all the QA checklist still require it. > > It can't be more mandatory than that imo. I guess someone has to remove it > > from the Wiki then ;) > > That infamous "QA checklist" is misunderstood frequently. It is hopelessly > incomplete. If you go through it step by step upon reviewing a package, > you can miss many other issues. If, however, the checklist were extended, > it would grow *a lot* and increase the hurdle to QA significantly. The > list in its current form just gives inspiration on what might be worth > examining. Ok, then please remove the non mandatory steps from it, if you want to remove the hurdle. It would have made this discussion non-existing ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Thu Feb 26 18:45:17 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 19:45:17 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <1077819807.4875.29.camel@Madison.badger.com> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> Message-ID: On Thu, 26 Feb 2004, Toshio wrote: > On Thu, 2004-02-26 at 12:40, Dag Wieers wrote: > > > > > the 'Source-tag may not have macros' decision > > > > Well, if it's not a macro, you may have the situation where someone > > changes the version, forgets to change the Source-tag and releases a newer > > version with older software. Would the QA person notice that ? > > Uhmm... > 1] Most of the time this will fail because the builder only has the new > source in the SOURCE area. > > 2] If we have a messy SOURCE area, it will still fail because the > tarball will create the directory foo-oldver and the rpmbuild process > will try (and fail) to access foo-newver. > > 3] In the few cases where this doesn't fail (because someone decided > to use %setup -n foo-oldver [I've never seen this construct, only > %{name}-%{version} which will fail b/c #2] or the tarball doesn't > include versions in its toplevel directory [I have seen this]) you do > have to rely on your QA people. But it is pretty obvious to spot. > (Why am I downloading the 0.12 tarball to build the 0.15 RPM?) If it is non mandatory, why are we still discussing this ? Yes, in my situation it wouldn't be triggered by 1] I may not be your average builder 2] I have many packages that _have_ to change the %setup line, 230 of the 622 spec-files which is over 30% (remember perl-packages ?) 3] I don't rely on QA people as I'd rather automate and assume a QA person has better things to do. But since it's not mandatory, let's not go into this deeper. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From katmandu at fs.inf.br Thu Feb 26 18:50:40 2004 From: katmandu at fs.inf.br (Adriano Del Vigna de Almeida) Date: Thu, 26 Feb 2004 15:50:40 -0300 Subject: GNOME main menu sorting Message-ID: <1077821439.5698.9.camel@adriano.freesoftware> Hello there, I'm hacking at the GNOME main menu and have three questions: 1.) Is it possible to sort the GNOME main menu other than alphabetically? 2.) How to add separators to the main menu? 3.) Where is stored the data about "run app", "search files", "open recent", "lock screen", and "exit" GNOME main menu itens? I ask to the case I need to modifiy them. Thanks for the attention! Adriano Del Vigna de Almeida Free Software Bras?lia - Curitiba - Rio de Janeiro - S?o Paulo Email: katmandu at fs.inf.br ICQ#: 14898488 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From ms-nospam-0306 at arcor.de Thu Feb 26 19:04:24 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 20:04:24 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> Message-ID: <20040226200424.0eb11448.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 19:39:31 +0100 (CET), Dag Wieers wrote: > > > Well, it used to be mandatory and all the QA checklist still require it. > > > It can't be more mandatory than that imo. I guess someone has to remove it > > > from the Wiki then ;) > > > > That infamous "QA checklist" is misunderstood frequently. It is hopelessly > > incomplete. If you go through it step by step upon reviewing a package, > > you can miss many other issues. If, however, the checklist were extended, > > it would grow *a lot* and increase the hurdle to QA significantly. The > > list in its current form just gives inspiration on what might be worth > > examining. > > Ok, then please remove the non mandatory steps from it, if you want to > remove the hurdle. It would have made this discussion non-existing ;) What would that change? We've talked about it, criticism has been noted, and as I've tried to make clear, the checklist should not be misunderstood. There is no silver bullet. One could create a different checklist for every different type of package. The biggest hurdle to QA is lack of common sense. I don't want to spend a lot of time editing documentation in the Wiki to please a single individual (read "you") who runs his own independent repository and doesn't really care. I'd rather like to know how to lower the hurdle for other people who would like to help, but who still don't know where to start. And that would mean that they start talking about any problems they see. -- From ms-nospam-0306 at arcor.de Thu Feb 26 19:10:57 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 20:10:57 +0100 Subject: rpm2html (was: Re: Prelink success story :)) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> Message-ID: <20040226201057.1bafc459.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 19:45:17 +0100 (CET), Dag Wieers wrote: > 3] I don't rely on QA people as I'd rather automate and assume a > QA person has better things to do. Packagers should not "rely on" QA. But often a second pair of eyes helps. Let me add my bit of QA: please fix your rpm2html package. You don't know what's wrong? Then get inspiration here: http://riva.homelinux.org/users/ms/rpms/rpm2html-1.8.2-1.fedora.src.rpm ;o) -- From toshio at tiki-lounge.com Thu Feb 26 19:13:09 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 26 Feb 2004 14:13:09 -0500 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> Message-ID: <1077822786.4875.51.camel@Madison.badger.com> On Thu, 2004-02-26 at 13:45, Dag Wieers wrote: > On Thu, 26 Feb 2004, Toshio wrote: > > > On Thu, 2004-02-26 at 12:40, Dag Wieers wrote: > > > > > > the 'Source-tag may not have macros' decision > > > > > > Well, if it's not a macro, you may have the situation where someone > > > changes the version, forgets to change the Source-tag and releases a newer > > > version with older software. Would the QA person notice that ? > > > > Uhmm... > > 1] Most of the time this will fail because the builder only has the new > > source in the SOURCE area. > > > > 2] If we have a messy SOURCE area, it will still fail because the > > tarball will create the directory foo-oldver and the rpmbuild process > > will try (and fail) to access foo-newver. > > > > 3] In the few cases where this doesn't fail (because someone decided > > to use %setup -n foo-oldver [I've never seen this construct, only > > %{name}-%{version} which will fail b/c #2] or the tarball doesn't > > include versions in its toplevel directory [I have seen this]) you do > > have to rely on your QA people. But it is pretty obvious to spot. > > (Why am I downloading the 0.12 tarball to build the 0.15 RPM?) > > If it is non mandatory, why are we still discussing this ? > Possibly because someone won't admit when they're wrong? :-) Could be me, but you'll have to show me how. > Yes, in my situation it wouldn't be triggered by > > 1] I may not be your average builder > 2] I have many packages that _have_ to change the %setup line, > 230 of the 622 spec-files which is over 30% (remember perl-packages ?) Doesn't matter. I took a look at several of your perl spec's. They do: %setup -n %{rname}-%{version} which will get caught by #2 above. (Your complaint is that you can change version and forget to change source. But if you use the version macro in %setup, rpmbuild will still fail because the version and untar'd sourcedir name don't match.) > 3] I don't rely on QA people as I'd rather automate and assume a > QA person has better things to do. That's fine. But your question was whether the QA person would catch the problem... > But since it's not mandatory, let's not go into this deeper. > There was a John Wayne movie where he went down the river on a barge with a fiesty old lady and a gatling gun. At the end of the movie John Wayne says "Damn she always has to get the last word." -Toshio -- Toshio From dag at wieers.com Thu Feb 26 20:09:17 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 21:09:17 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <1077822786.4875.51.camel@Madison.badger.com> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> Message-ID: On Thu, 26 Feb 2004, Toshio wrote: > On Thu, 2004-02-26 at 13:45, Dag Wieers wrote: > > On Thu, 26 Feb 2004, Toshio wrote: > > > > > On Thu, 2004-02-26 at 12:40, Dag Wieers wrote: > > > > > > > the 'Source-tag may not have macros' decision > > > > > > > > Well, if it's not a macro, you may have the situation where someone > > > > changes the version, forgets to change the Source-tag and releases a newer > > > > version with older software. Would the QA person notice that ? > > > > > If it is non mandatory, why are we still discussing this ? > > Possibly because someone won't admit when they're wrong? :-) > Could be me, but you'll have to show me how. Then you clearly have much more time than I have. > > 2] I have many packages that _have_ to change the %setup line, > > 230 of the 622 spec-files which is over 30% (remember perl-packages ?) > Doesn't matter. I took a look at several of your perl spec's. > They do: > %setup -n %{rname}-%{version} > which will get caught by #2 above. And you said you hadn't seen any ocassions where %setup -n was needed and I gave you those that did. I understand you wanted to know the number of packages that have '-n' used and not %{version}. Still 87 do, about 13%. Although I must say I don't see why that would be of any value in the discussion. > > 3] I don't rely on QA people as I'd rather automate and assume a > > QA person has better things to do. > That's fine. But your question was whether the QA person would catch > the problem... Well, we will not know, would we. I'm just stating it's useless to ask this from a QA person if you can automate it. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From smoogen at lanl.gov Thu Feb 26 20:22:03 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 26 Feb 2004 13:22:03 -0700 Subject: How to Package Fedora RPMS Re: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> Message-ID: <1077826922.5873.21.camel@smoogen2.lanl.gov> Since this has very little to do with Prelink, I changed the subject On Thu, 2004-02-26 at 13:09, Dag Wieers wrote: > On Thu, 26 Feb 2004, Toshio wrote: > What I am wondering is what is the best method for packaging new items to be fedora compliant? Is there a step by step guide or a bunch of wiki articles? If not what is the Dag Wieers method as from what I have seen there is a neat bit of engineering done over and over again in those RPMS. -- 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 dag at wieers.com Thu Feb 26 20:37:53 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 21:37:53 +0100 (CET) Subject: rpm2html (was: Re: Prelink success story :)) In-Reply-To: <20040226201057.1bafc459.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <20040226201057.1bafc459.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 19:45:17 +0100 (CET), Dag Wieers wrote: > > > 3] I don't rely on QA people as I'd rather automate and assume a > > QA person has better things to do. > > Packagers should not "rely on" QA. But often a second pair of eyes > helps. I didn't say a QA person wouldn't be useful, did I ? Rather that we do things in such a way that it prevents extra QA, if it fails it fails with the packager and not a couple of hours/days later when it gets QA'd. I don't like switching context. > Let me add my bit of QA: please fix your rpm2html package. > You don't know what's wrong? Then get inspiration here: I don't know what's wrong except that I have an older version and missing BuildRequires (which I don't think matters that much). The new version builds without any modification to the spec and I really don't see what QA has to do with it. If there's something I missed I'm sure you would tell me. So thanks for letting me know there's a newer version. I should really script something that helps me find newer versions automatically. PS You don't need the CFLAGS="-O2" (anymore?), the %makeinstall macro works too and I would %config(noreplace) the config-file. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Thu Feb 26 20:48:55 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 21:48:55 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <20040226200424.0eb11448.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> <20040226200424.0eb11448.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 19:39:31 +0100 (CET), Dag Wieers wrote: > > > > That infamous "QA checklist" is misunderstood frequently. It is hopelessly > > > incomplete. If you go through it step by step upon reviewing a package, > > > you can miss many other issues. If, however, the checklist were extended, > > > it would grow *a lot* and increase the hurdle to QA significantly. The > > > list in its current form just gives inspiration on what might be worth > > > examining. > > > > Ok, then please remove the non mandatory steps from it, if you want to > > remove the hurdle. It would have made this discussion non-existing ;) > > What would that change? We've talked about it, criticism has been noted, > and as I've tried to make clear, the checklist should not be > misunderstood. There is no silver bullet. One could create a different > checklist for every different type of package. The biggest hurdle to QA is > lack of common sense. I don't want to spend a lot of time editing > documentation in the Wiki to please a single individual (read "you") who > runs his own independent repository and doesn't really care. I'd rather > like to know how to lower the hurdle for other people who would like to > help, but who still don't know where to start. And that would mean that > they start talking about any problems they see. I guess I don't understand anything you're saying in the context of this discussion and I'm leaving it for what it was. If the biggest hurdle to QA is lack of common sense I don't see why a non-mandatory rule is still in there. Especially if you can't do something wrong when both of 2 choices are allowed. Do you still wonder why I care less ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ms-nospam-0306 at arcor.de Thu Feb 26 20:50:16 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 21:50:16 +0100 Subject: rpm2html (was: Re: Prelink success story :)) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <20040226201057.1bafc459.ms-nospam-0306@arcor.de> Message-ID: <20040226215016.57ffa605.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 21:37:53 +0100 (CET), Dag Wieers wrote: > > Let me add my bit of QA: please fix your rpm2html package. > > You don't know what's wrong? Then get inspiration here: > > I don't know what's wrong except that I have an older version and missing > BuildRequires (which I don't think matters that much). Your %install section is completely broken in the for-loop, for instance. Most likely because you've taken over the spec from somewhere without reviewing it. > PS You don't need the CFLAGS="-O2" (anymore?), It is used deliberately, because more optflags break rpm2html and make it segfault real badly. > the %makeinstall macro works too Sure, but DESTDIR= install is the de facto standard and works in this case, too. > and I would %config(noreplace) the config-file. I disagree. It is an example only, and rpm2html power-users would run rpm2html with separate config files and as non-root anyway. YMMV. -- From ms-nospam-0306 at arcor.de Thu Feb 26 20:52:30 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 21:52:30 +0100 Subject: How to Package Fedora RPMS Re: Prelink success story :) In-Reply-To: <1077826922.5873.21.camel@smoogen2.lanl.gov> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077826922.5873.21.camel@smoogen2.lanl.gov> Message-ID: <20040226215230.5cfb47e4.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 13:22:03 -0700, Stephen Smoogen wrote: > What I am wondering is what is the best method for packaging new items > to be fedora compliant? Good question. Superficial answer: Whatever is necessary to create a package that builds, installs, works and erases, too. *What* is necessary exactly depends on the software to be packaged, e.g. whether it comes with a standard "configure" script, whether it accepts modified installation paths or compiler settings, whether additional integration work is needed (e.g. desktop entries, pre-configuration, helper scripts to finalize installation/removal), whether it must be patched for customization, and more things like that. "fedora compliant" == fedora.us compliant? Well, there are a couple of guidelines in the fedora.us Wiki. > Is there a step by step guide or a bunch of wiki articles? Step by step on what exactly? -- From ms-nospam-0306 at arcor.de Thu Feb 26 21:07:57 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 22:07:57 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> <20040226200424.0eb11448.ms-nospam-0306@arcor.de> Message-ID: <20040226220757.45fe901c.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 21:48:55 +0100 (CET), Dag Wieers wrote: > If the biggest hurdle to QA is lack of common sense I don't see why > a non-mandatory rule is still in there. Because the list doesn't say anywhere that it would be a list of mandatory items. > Especially if you can't do > something wrong when both of 2 choices are allowed. Do you see anything more serious in the list that ought to be changed? Or do we spend dozens of messages on just $RPM_BUILD_ROOT vs. %buildroot? The explanation, why $RPM_BUILD_ROOT is suggested, is linked in the checklist. Everybody can read where it comes from and judge by himself whether %buildroot might be killed without warning. > Do you still wonder why I care less ? No, I don't understand why you feel the need to discuss minor things like this and make a mountain out of a molehill. If not RPM_BUILD_ROOT, I'm sure you would find something else. I mean, even if someone modified the checklist today, you would not contribute any packages to fedora.us, because you're entirely happy with your own repository and full control over your own releases. Am I wrong? -- From smoogen at lanl.gov Thu Feb 26 21:13:20 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 26 Feb 2004 14:13:20 -0700 Subject: How to Package Fedora RPMS Re: Prelink success story :) In-Reply-To: <20040226215230.5cfb47e4.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077826922.5873.21.camel@smoogen2.lanl.gov> <20040226215230.5cfb47e4.ms-nospam-0306@arcor.de> Message-ID: <1077830000.2252.3.camel@smoogen2.lanl.gov> On Thu, 2004-02-26 at 13:52, Michael Schwendt wrote: > On Thu, 26 Feb 2004 13:22:03 -0700, Stephen Smoogen wrote: > > > What I am wondering is what is the best method for packaging new items > > to be fedora compliant? > > Good question. Superficial answer: Whatever is necessary to create > a package that builds, installs, works and erases, too. > > *What* is necessary exactly depends on the software to be packaged, > e.g. whether it comes with a standard "configure" script, whether it > accepts modified installation paths or compiler settings, whether > additional integration work is needed (e.g. desktop entries, > pre-configuration, helper scripts to finalize installation/removal), > whether it must be patched for customization, and more things like that. > > > "fedora compliant" == fedora.us compliant? Well, there are a couple > of guidelines in the fedora.us Wiki. > > > Is there a step by step guide or a bunch of wiki articles? > > Step by step on what exactly? > Here is a Spec file template with everything that should be defined in a way that is easily parsable by an automated service/QA_monkey_who_will_fling_dung_at_non_compliant_specfiles For things outside of this spec file, this is the order that we would like things to be in. Here are some good examples of SPEC files that you can use as reference when starting with something new. Here are things to avoid/not do because they make QA/maintainers lives heck and more likely that they will throw dung at you. > -- -- 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 dag at wieers.com Thu Feb 26 21:15:34 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 22:15:34 +0100 (CET) Subject: rpm2html (was: Re: Prelink success story :)) In-Reply-To: <20040226215016.57ffa605.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <20040226201057.1bafc459.ms-nospam-0306@arcor.de> <20040226215016.57ffa605.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 21:37:53 +0100 (CET), Dag Wieers wrote: > > > > Let me add my bit of QA: please fix your rpm2html package. > > > You don't know what's wrong? Then get inspiration here: > > > > I don't know what's wrong except that I have an older version and missing > > BuildRequires (which I don't think matters that much). > > Your %install section is completely broken in the for-loop, for instance. > Most likely because you've taken over the spec from somewhere without > reviewing it. Ah, I didn't see that because it wasn't needed anymore. Thanks for making that clear now that's not needed. I'm sure you were waiting for that to throw it in my face at the right moment ;) It would have been nicer without the allegations, but I didn't expect it otherwise in the heat of this discussion. > > PS You don't need the CFLAGS="-O2" (anymore?), > > It is used deliberately, because more optflags break rpm2html and make it > segfault real badly. It doesn't segfault here on RH80, RH90 and RHFC1. That's why I thought you had it in place for earlier versions. Aparantly not. No harm done. > > the %makeinstall macro works too > > Sure, but DESTDIR= install is the de facto standard and works in this > case, too. But you wouldn't be using the correct macros. On a x86_64 it would get installed in /usr/lib instead of /usr/lib64. (This example doesn't have libraries, but it would have been good practice to do it everywhere if possible). > > and I would %config(noreplace) the config-file. > > I disagree. It is an example only, and rpm2html power-users would run > rpm2html with separate config files and as non-root anyway. YMMV. Ok, then we agree to disagree. Minor issue. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From mharris at redhat.com Thu Feb 26 21:23:45 2004 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 26 Feb 2004 16:23:45 -0500 (EST) Subject: rawhide report: 20040224 changes In-Reply-To: <403BBE79.30306@research.att.com> References: <200402241413.i1OEDhW25394@porkchop.devel.redhat.com> <403BB79F.2020205@togami.com> <403BBE79.30306@research.att.com> Message-ID: On Tue, 24 Feb 2004, John Ellson wrote: >Date: Tue, 24 Feb 2004 16:13:29 -0500 >From: John Ellson >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >List-Id: Development discussions related to Fedora Core > >Subject: Re: rawhide report: 20040224 changes > >Warren Togami wrote: > >> Build System wrote: >> >>> >>> kernel-2.6.3-1.100 >>> ------------------ >>> * Mon Feb 23 2004 Dave Jones >>> >>> - Update to 2.6.3-bk5 >> >> >> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116724 >> >> This kernel seems to have broke Radeon. 2.6.3-1.97 was the last >> kernel that works for me. >> >> Warren >> >> > > >FWIW, it broke the NVIDIA-Linux-x86-1.0-5336 drivers too. Something >about SVIPC? Shared Memory? Yep, fixed in rawhide, upgrade kernel to latest. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=shmat -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Feb 26 21:32:22 2004 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 26 Feb 2004 16:32:22 -0500 (EST) Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077800615.30911.0.camel@delerium.codemonkey.org.uk> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800615.30911.0.camel@delerium.codemonkey.org.uk> Message-ID: On Thu, 26 Feb 2004, Dave Jones wrote: >Date: Thu, 26 Feb 2004 13:03:35 +0000 >From: Dave Jones >To: fedora-devel-list at redhat.com >Content-Type: text/plain >List-Id: Development discussions related to Fedora Core > >Subject: Re: CURRENTRELEASE versus NEXTRELEASE > >On Thu, 2004-02-26 at 12:42, Leonard den Ottolander wrote: >> Hi, >> >> I am uncertain about the use of the tag NEXTRELEASE in bugzilla. How >> should an issue be closed if it was reported for RHL 8.0, but does not >> exist in FC 1? NEXTRELEASE or CURRENTRELEASE? > >CURRENTRELEASE is FC1 >NEXTRELEASE is FC2. Generally we close bugs that are fixed in the Fedora Core development tree as "RAWHIDE", however "NEXTRELEASE" is probably just as valid, but not used as often. The main difference between the "RAWHIDE" and "NEXTRELEASE" closures, is that closing a RHEL 3 bug as "RAWHIDE" doesn't make sense IMHO, whereas "NEXTRELEASE" for RHEL3 bugs, means "will be fixed in RHEL4". For Fedora Core, both are more or less synonyms IMHO, however that's my own personal interpretation, not official policy of any sort. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Feb 26 21:34:08 2004 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 26 Feb 2004 16:34:08 -0500 (EST) Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077800837.4746.9.camel@athlon.localdomain> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800615.30911.0.camel@delerium.codemonkey.org.uk> <1077800837.4746.9.camel@athlon.localdomain> Message-ID: On Thu, 26 Feb 2004, Leonard den Ottolander wrote: >Date: Thu, 26 Feb 2004 14:07:18 +0100 >From: Leonard den Ottolander >To: Fedora Devel List >Content-Type: text/plain >List-Id: Development discussions related to Fedora Core > >Subject: Re: CURRENTRELEASE versus NEXTRELEASE > >Hi Dave, > >> CURRENTRELEASE is FC1 >> NEXTRELEASE is FC2. >> >> Go figure 8-) > >Yeah, but for RHL 9 FC 1 is NEXTRELEASE. See my point? "NEXTRELEASE" is not based on the version of the OS the bug was filed at, but is based upon current development. "NEXTRELEASE" is "The next official OS release to come out in the future", which is "Fedora Core 2" in the case of Fedora, or "Red Hat Enterprise Linux 4" in the case of RHEL. A bug in RHL 9, that is fixed in Fedora Core 1, or a Fedora Core 1 update, can be closed "CURRENTRELEASE" as Fedora Core 1 is the current release. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From dag at wieers.com Thu Feb 26 21:34:59 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 22:34:59 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <20040226220757.45fe901c.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> <20040226200424.0eb11448.ms-nospam-0306@arcor.de> <20040226220757.45fe901c.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 21:48:55 +0100 (CET), Dag Wieers wrote: > > > If the biggest hurdle to QA is lack of common sense I don't see why > > a non-mandatory rule is still in there. > > Because the list doesn't say anywhere that it would be a list of mandatory > items. > > > Especially if you can't do > > something wrong when both of 2 choices are allowed. > > Do you see anything more serious in the list that ought to be changed? Or > do we spend dozens of messages on just $RPM_BUILD_ROOT vs. %buildroot? The > explanation, why $RPM_BUILD_ROOT is suggested, is linked in the > checklist. Everybody can read where it comes from and judge by himself > whether %buildroot might be killed without warning. > > > Do you still wonder why I care less ? > > No, I don't understand why you feel the need to discuss minor things like > this and make a mountain out of a molehill. If not RPM_BUILD_ROOT, I'm > sure you would find something else. I mean, even if someone modified the > checklist today, you would not contribute any packages to fedora.us, > because you're entirely happy with your own repository and full control > over your own releases. Am I wrong? Michael, please calm down. This discussion started because someone corrected a Red Hat engineer when he used %{buildroot}. I was just stating that if it wasn't mandatory (what I learned from you after an ironic remark) than the fedora.us policy should change. And then suddenly all hell break loose. Sorry, I should have not answered your messages if I knew what would be the result. Please feel free to ignore me in future mails, I won't make this mistake twice. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From mharris at redhat.com Thu Feb 26 21:34:24 2004 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 26 Feb 2004 16:34:24 -0500 (EST) Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <20040226143450.5a139afa.ms-nospam-0306@arcor.de> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800615.30911.0.camel@delerium.codemonkey.org.uk> <1077800837.4746.9.camel@athlon.localdomain> <20040226143450.5a139afa.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: >Date: Thu, 26 Feb 2004 14:34:50 +0100 >From: Michael Schwendt >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=US-ASCII >List-Id: Development discussions related to Fedora Core > >Subject: Re: CURRENTRELEASE versus NEXTRELEASE > >On Thu, 26 Feb 2004 14:07:18 +0100, Leonard den Ottolander wrote: > >> Hi Dave, >> >> > CURRENTRELEASE is FC1 >> > NEXTRELEASE is FC2. >> > >> > Go figure 8-) >> >> Yeah, but for RHL 9 FC 1 is NEXTRELEASE. See my point? > >Isn't it more like "at the time you close the report, current release >is FC 1, next release is FC 2"? Yes. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Feb 26 21:35:31 2004 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 26 Feb 2004 16:35:31 -0500 (EST) Subject: EOLed products and CURRENTRELEASE In-Reply-To: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> Message-ID: On Thu, 26 Feb 2004, Miloslav Trmac wrote: >Date: Thu, 26 Feb 2004 16:40:12 +0100 >From: Miloslav Trmac >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: Development discussions related to Fedora Core > >Subject: EOLed products and CURRENTRELEASE > >Hello, >Would anybody object to closing bugs in EOLed products (currently >RHL < 9) that are fixed in FC1 as CURRENTRELEASE? I think that is a good idea, and is totally appropriate. If any particular bug isn't 100% certain though, best to post it here for review by others also. Thanks for the good idea. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Feb 26 21:36:35 2004 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 26 Feb 2004 16:36:35 -0500 (EST) Subject: EOLed products and CURRENTRELEASE In-Reply-To: <1077812889.4746.17.camel@athlon.localdomain> References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> <20040226154421.GA10561@dudweiler.stuttgart.redhat.com> <1077812889.4746.17.camel@athlon.localdomain> Message-ID: On Thu, 26 Feb 2004, Leonard den Ottolander wrote: >Date: Thu, 26 Feb 2004 17:28:09 +0100 >From: Leonard den Ottolander >To: Fedora Devel List >Content-Type: text/plain >List-Id: Development discussions related to Fedora Core > >Subject: Re: EOLed products and CURRENTRELEASE > >Hi Florian, > >> > Would anybody object to closing bugs in EOLed products (currently >> > RHL < 9) that are fixed in FC1 as CURRENTRELEASE? >> >> That should be ok, > >How about the case where the product is RHL 9? If the bug is in RHL 9, and fixed in Fedora Core 1, then it can either be left open for now, in case it gets fixed in RHL 9 in the future, or it can be closed "CURRENTRELEASE" indicating "it is fixed in Fedora Core 1, and we have no plan of fixing it in RHL 9, please upgrade OS." -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From surak at casa.surak.eti.br Thu Feb 26 21:45:44 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Thu, 26 Feb 2004 18:45:44 -0300 Subject: ARGOX Label printers Message-ID: <1077831506.13232.8.camel@casa> This nice label printers don't have any available driver for fedora... in fact, they don't have any driver at all in cups. Just filled a bugzilla on cups: http://cups.org/str.php?L600+P0+S0+C0+I0+E0+Q Should I fill it on redhat's bugzilla also? Here are those little beasts: http://www.argox.com.cn/ http://www.argox.com By the way, the lead the label printer market on Asia and South America, and most of those printers (even other brands) seems to share a common printer language, called PPLA and PPLB. I have access to the windows CD, which contains PPLA and PPLB language description... In case this interest someone. Anyway, it was sad to swith 60 machines back to windows (these machines are being used in events, like scientific meetings, government stuff, etc, to identificate participants) just because of a printer driver... I'll crosspost this message to fedora-list just in case someone has a alternative solution for me. -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From jgardner at jonathangardner.net Thu Feb 26 21:42:19 2004 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Thu, 26 Feb 2004 13:42:19 -0800 Subject: Using bit torrent to retrieve RPMs for updates Message-ID: <200402261342.19650.jgardner@jonathangardner.net> Has anyone given serious thought to changing Yum so that it uses the bittorrent protocol to retrieve RPMs? Especially in the case of updates, when everyone and their grandmother needs to get the RPMs right away, this would make a lot of sense. Yum could manage a repository of RPMs and constantly serve those up so other can download parts of them via bittorrent, all with permission, of course. -- Jonathan Gardner jgardner at jonathangardner.net From ms-nospam-0306 at arcor.de Thu Feb 26 21:56:20 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 22:56:20 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> <20040226200424.0eb11448.ms-nospam-0306@arcor.de> <20040226220757.45fe901c.ms-nospam-0306@arcor.de> Message-ID: <20040226225620.6f634523.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 22:34:59 +0100 (CET), Dag Wieers wrote: > > No, I don't understand why you feel the need to discuss minor things like > > this and make a mountain out of a molehill. If not RPM_BUILD_ROOT, I'm > > sure you would find something else. I mean, even if someone modified the > > checklist today, you would not contribute any packages to fedora.us, > > because you're entirely happy with your own repository and full control > > over your own releases. Am I wrong? > > Michael, please calm down. This discussion started because someone > corrected a Red Hat engineer when he used %{buildroot}. Yes, and the Red Hat engineer would not change that anyway unless there were good reason. The fedora.us documents don't say anywhere that $RPM_BUILD_ROOT would be "better than" or "more correct than" %buildroot. They just say that $RPM_BUILD_ROOT is preferred at fedora.us and give the reason why that is the case. > I was just stating that if it wasn't mandatory (what I learned from you > after an ironic remark) than the fedora.us policy should change. > > And then suddenly all hell break loose. With your early replies you started a not so friendly sounding policy debate, e.g. in Message-ID: and you didn't stop at $RPM_BUILD_ROOT vs. %buildroot. -- From rich+rhl at lafferty.ca Thu Feb 26 21:59:51 2004 From: rich+rhl at lafferty.ca (Rich Lafferty) Date: Thu, 26 Feb 2004 16:59:51 -0500 Subject: ARGOX Label printers In-Reply-To: <1077831506.13232.8.camel@casa> References: <1077831506.13232.8.camel@casa> Message-ID: <20040226215951.GC20592@lafferty.ca> On Thu, Feb 26, 2004 at 06:45:44PM -0300, Alexandre Strube wrote: > > By the way, the lead the label printer market on Asia and South America, > and most of those printers (even other brands) seems to share a common > printer language, called PPLA and PPLB. I have access to the windows CD, > which contains PPLA and PPLB language description... In case this > interest someone. My first reaction to this was that label-printing tends to be more specialized than page-printing, so CUPS might just be the wrong place to look. This might be of interest: http://www.nicelabel.com/nicelabel/nlbl_ver_linux.php Cheers, -Rich -- Rich Lafferty --------------+----------------------------------------------- Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html rich at lafferty.ca -----------+----------------------------------------------- From dag at wieers.com Thu Feb 26 22:09:34 2004 From: dag at wieers.com (Dag Wieers) Date: Thu, 26 Feb 2004 23:09:34 +0100 (CET) Subject: Prelink success story :) In-Reply-To: <20040226225620.6f634523.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> <20040226200424.0eb11448.ms-nospam-0306@arcor.de> <20040226220757.45fe901c.ms-nospam-0306@arcor.de> <20040226225620.6f634523.ms-nospam-0306@arcor.de> Message-ID: On Thu, 26 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 22:34:59 +0100 (CET), Dag Wieers wrote: > > > > No, I don't understand why you feel the need to discuss minor things like > > > this and make a mountain out of a molehill. If not RPM_BUILD_ROOT, I'm > > > sure you would find something else. I mean, even if someone modified the > > > checklist today, you would not contribute any packages to fedora.us, > > > because you're entirely happy with your own repository and full control > > > over your own releases. Am I wrong? > > > > Michael, please calm down. This discussion started because someone > > corrected a Red Hat engineer when he used %{buildroot}. > > Yes, and the Red Hat engineer would not change that anyway unless there > were good reason. > > The fedora.us documents don't say anywhere that $RPM_BUILD_ROOT would be > "better than" or "more correct than" %buildroot. They just say that > $RPM_BUILD_ROOT is preferred at fedora.us and give the reason why that is > the case. http://www.fedora.us/wiki/QAChecklist "Does the package have any %{buildroot} macros? If so, they should be replaced with $RPM_BUILD_ROOT. Ditto for %{optflags} -> $RPM_OPT_FLAGS. For more info, see http://www.fedora.us/pipermail/fedora-devel/2003-April/001155.html." The same for fedora.us legacy QAChecklist. > > I was just stating that if it wasn't mandatory (what I learned from you > > after an ironic remark) than the fedora.us policy should change. > > > > And then suddenly all hell break loose. > > With your early replies you started a not so friendly sounding > policy debate, e.g. in > > Message-ID: > > and you didn't stop at $RPM_BUILD_ROOT vs. %buildroot. Correct, because there were other such cases, of which some (after proper discussion) also were not mandatory anymore. So yes, it was valuable for me to ask and no, it didn't need the kind of response I got. That it didn't sound friendly was not intentional, I though my initial remark was actually funny and quite to the point. Little did I know the policy had changed and the documentation did lack behind. I guess more people want that document corrected, still I can't undo myself of the feeling you're against it because I brought it up. Well, I certainly will think twice now. You know where to find me ! -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ms-nospam-0306 at arcor.de Thu Feb 26 22:10:57 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 23:10:57 +0100 Subject: How to Package Fedora RPMS Re: Prelink success story :) In-Reply-To: <1077830000.2252.3.camel@smoogen2.lanl.gov> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077826922.5873.21.camel@smoogen2.lanl.gov> <20040226215230.5cfb47e4.ms-nospam-0306@arcor.de> <1077830000.2252.3.camel@smoogen2.lanl.gov> Message-ID: <20040226231057.0a4de9be.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 14:13:20 -0700, Stephen Smoogen wrote: > Here is a Spec file template with everything that should be defined in a > way that is easily parsable by an automated > service/QA_monkey_who_will_fling_dung_at_non_compliant_specfiles > > For things outside of this spec file, this is the order that we would > like things to be in. > > Here are some good examples of SPEC files that you can use as reference > when starting with something new. > > Here are things to avoid/not do because they make QA/maintainers lives > heck and more likely that they will throw dung at you. This is going too far, IMHO, because it comes close to the opposite of "common sense". ;) For examples on spec files of packages which somehow seem to have passed QA, simply check out existing spec files of what's in the repository already or what has been added to it recently. For instance, a snapshot of all spec files is linked from the main page at http://fedora.us. The packager ought to know his own package. The packager should not attempt at spec file beautification just to match a given template. It's the packager who maintains the package, not the reviewer. But it would be added value, if someone else doesn't need ages to understand the packaging. So, e.g. comments in some places of the spec can be helpful. Running rpmlint on the src.rpm (at least) can be helpful, but rpmlint's output ought to be verified as rpmlint is not bullet-proof. _From my memory, a few things that can drive a reviewer nuts: * A package update (with the UPDATE keyword) comes with a completely rewritten and reformatted spec file and even renames separate patch files, which makes the diff against the previous release overly complex. [similar thing applies to revisions during QA] * If a package does not even build, because it lacks obvious build requirements. Not everyone uses "mach", but fedora-rmdevelrpms does a pretty good job, too. * Missing %changelog comments. * If a src.rpm file has been adapated from some other distribution and the new packager appears to not have tried to understand the spec file. * Lots of explicit and redundant "Requires", but no or hardly any "Buildrequires". (both indicate the Wiki has been ignored) * If a packager changes his mind often and in one revision uses "rm" and "mkdir -p" and in another switches to %__rm and %__mkdir_p and vice versa. * Ugly and useless constructs which check whether buildroot is "/" prior to emptying it (and a packager who insists of leaving them in the spec file). * Upstream source location is difficult to find, URL is not in spec file. Source tarball has been recompressed or modified or fetched from some "hidden" location. -- From ms-nospam-0306 at arcor.de Thu Feb 26 22:19:44 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 23:19:44 +0100 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077813935.6550.13.camel@bobcat.mine.nu> <20040226193625.3dc23f46.ms-nospam-0306@arcor.de> <20040226200424.0eb11448.ms-nospam-0306@arcor.de> <20040226220757.45fe901c.ms-nospam-0306@arcor.de> <20040226225620.6f634523.ms-nospam-0306@arcor.de> Message-ID: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 23:09:34 +0100 (CET), Dag Wieers wrote: > > The fedora.us documents don't say anywhere that $RPM_BUILD_ROOT would be > > "better than" or "more correct than" %buildroot. They just say that > > $RPM_BUILD_ROOT is preferred at fedora.us and give the reason why that is > > the case. > > http://www.fedora.us/wiki/QAChecklist > > "Does the package have any %{buildroot} macros? If so, they should be > replaced with $RPM_BUILD_ROOT. Ditto for %{optflags} -> > $RPM_OPT_FLAGS. For more info, see > http://www.fedora.us/pipermail/fedora-devel/2003-April/001155.html." Again, $RPM_BUILD_ROOT is preferred at fedora.us as long as it is described as the "official supported" mechanism on getting access to buildroot. > The same for fedora.us legacy QAChecklist. Does such a thing exist? Isn't in work-in-progress still? > I guess more people want that document corrected, "Me too" comments as private replies to me would be appreciated. It would be important that people, who want to contribute, or potential contributors voice their opinion. > still I can't undo > myself of the feeling you're against it because I brought it up. Are you kidding? That's a completely unfounded suspicion. -- From rhallyx at mindspring.com Thu Feb 26 22:21:01 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Thu, 26 Feb 2004 17:21:01 -0500 Subject: latest update Message-ID: <1077831368.3240.2.camel@old1> what is the problem with the /development tree? see below: [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers Resolving dependencies .Package gnome-applets needs libgtop-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop-2.0.so.1, this is not available. Package gnome-applets needs libgtop_common-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not available. Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not available. [root at old1 root]# thanks for the help Richard Hally From ms-nospam-0306 at arcor.de Thu Feb 26 22:29:47 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 26 Feb 2004 23:29:47 +0100 Subject: rpm2html (was: Re: Prelink success story :)) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <20040226201057.1bafc459.ms-nospam-0306@arcor.de> <20040226215016.57ffa605.ms-nospam-0306@arcor.de> Message-ID: <20040226232947.71029ca5.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 22:15:34 +0100 (CET), Dag Wieers wrote: > > Your %install section is completely broken in the for-loop, for instance. > > Most likely because you've taken over the spec from somewhere without > > reviewing it. > > Ah, I didn't see that because it wasn't needed anymore. It "wasn't needed" in 1.8.1-0.dag and 1.7-0.dag either. ;) -- From surak at casa.surak.eti.br Thu Feb 26 22:31:53 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Thu, 26 Feb 2004 19:31:53 -0300 Subject: Using bit torrent to retrieve RPMs for updates In-Reply-To: <200402261342.19650.jgardner@jonathangardner.net> References: <200402261342.19650.jgardner@jonathangardner.net> Message-ID: <1077834713.13232.24.camel@casa> Em Qui, 2004-02-26 ?s 18:42, Jonathan Gardner escreveu: > Has anyone given serious thought to changing Yum so that it uses the > bittorrent protocol to retrieve RPMs? Especially in the case of updates, > when everyone and their grandmother needs to get the RPMs right away, this > would make a lot of sense. Yum could manage a repository of RPMs and > constantly serve those up so other can download parts of them via > bittorrent, all with permission, of course. I was talking about this for months, until I discovered fedora-devel, and realized that I was talking in the wrong place :-) -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From smoogen at lanl.gov Thu Feb 26 22:30:25 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 26 Feb 2004 15:30:25 -0700 Subject: How to Package Fedora RPMS Re: Prelink success story :) In-Reply-To: <20040226231057.0a4de9be.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077826922.5873.21.camel@smoogen2.lanl.gov> <20040226215230.5cfb47e4.ms-nospam-0306@arcor.de> <1077830000.2252.3.camel@smoogen2.lanl.gov> <20040226231057.0a4de9be.ms-nospam-0306@arcor.de> Message-ID: <1077834624.2250.13.camel@smoogen2.lanl.gov> On Thu, 2004-02-26 at 15:10, Michael Schwendt wrote: > On Thu, 26 Feb 2004 14:13:20 -0700, Stephen Smoogen wrote: > > > Here is a Spec file template with everything that should be defined in a > > way that is easily parsable by an automated > > service/QA_monkey_who_will_fling_dung_at_non_compliant_specfiles > > > > For things outside of this spec file, this is the order that we would > > like things to be in. > > > > Here are some good examples of SPEC files that you can use as reference > > when starting with something new. > > > > Here are things to avoid/not do because they make QA/maintainers lives > > heck and more likely that they will throw dung at you. > > This is going too far, IMHO, because it comes close to the opposite of > "common sense". ;) > Well I doubt that HIPAA or ISO9xxx (or other govt documentation processes) are long on common sense.. I have to come up with a set of methods for doing this to make sure that developers have a clear documented process... that they can then ignore :P -- 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 erik at totalcirculation.com Thu Feb 26 22:43:22 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 26 Feb 2004 17:43:22 -0500 Subject: Prelink success story :) Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> > What would that change? We've talked about it, criticism has been noted, > and as I've tried to make clear, the checklist should not be > misunderstood. There is no silver bullet. One could create a different > checklist for every different type of package. The biggest hurdle to QA is > lack of common sense. I don't want to spend a lot of time editing > documentation in the Wiki to please a single individual (read "you") who > runs his own independent repository and doesn't really care. I'd rather > like to know how to lower the hurdle for other people who would like to > help, but who still don't know where to start. And that would mean that > they start talking about any problems they see. > As a new-to-fedora.us prospective QA'er, I've been attempting to compose an email on this very subject for the last several days, but haven't managed to complete it. It's going to be long, so please forgive me As a longtime redhat user (4+ yrs) and not-entirely-new rpm packager (2 yrs) and professional system administrator / software engineer, it took me over 8 hours of work before I submitted my first QA review. This is partially because I hadn't been using GPG, partially because I didn't have a bugzilla account, partially due to general incompetence on my part, and partially due to the amount of material in the QA checklist. I'm happy to discuss this stuff in more detail, but I'm just going to throw out some "newbie observations" for you all to think about. I do think that the barrier for entry that I found was entirely too high. I'm just now beginning to understand what is going on after getting some feedback on some of my reviews. 1. Information how "how to do some useful qa" is scattered. Heres only some of the url's I had to look at to figure out whats going. None of them were complete in and of themselves, and my first two attempts at QA were still sub-optimal. http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/pipermail/fedora-devel/2003-March/000459.html http://www.fedora.us/wiki/QAChecklist http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires I also got some good mileage out of one of Jef Spaleta's bug triage messages to the list. 2. Too much detail. The QA checklist is great. However, as it turns out, a lot of the stuff being checked there aren't really showstoppers. I ended up turning it into a list 1. Does the package follow the Fedora Package Naming Guidelines? 2. Are the sources from upstream pristine and free from trojans? 3. Are the pre- and post(un)install scripts correct? 4. Epoch 5. Are there no missing BuildRequires? 6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS. 7. Are all paths within the .spec replaced with macros? 8. If the package has a DesktopEntry, are the VFolder categories ok? 9. Is the package free of any %{buildroot} macros? 10. Is the package free of unowned directories? 11. Is the License tag used rather than Copyright? 12. Is the package free of default passwords? 13. Are all daemon's which can be installed to run as non-root installed as such? 14. Does the package handle a parallel build cleanly? Now. Some of these items apparently are subject to contention. If there's any chance that they aren't showstoppers, lets get them off that list! There should be a template like I have above, that can be answered with simple yes or no answers, that covers all the showstoppers. That way a newbie can fill it in the blank with yes's or no's and no he's done something useful. Since all the checklist items are there, answered with yes or no questions, it's easy to know if they actually made a good faith effort to check the package. The non-showstoppers should be on a second list of "stuff to watch for". This could be far more detailed than the actual QA checklist, and as a newbie gets deeper into packaging lore, they would likely begin filling out more of it. Some critique of the list: 1. Does the package follow the Fedora Package Naming Guidelines? This is pretty darn complicated for a newbie QA'er. They should be allowed to opt out. A "senior developer" could look at the package in 10 seconds and understand whether or not the name is ok. 2. Are the sources from upstream pristine and free from trojans? This is important, but exceedingly difficult to do "properly"... At what point does this become a showstopper? At some point it becomes impossible to verify the source without actually being the author of the code and inspecting it line by line. For a newbie this is very intimidating My suggestion would be to have a set of no-fail, simple steps that result in a concrete answer, like the following: "verify the source url exists, and check to see that it is at the official distribution site for the software. Compare the md5 sums of their posted souce tarball and the one included in the SRPM. If it doesn't, please detail your findings". 3. Are the pre- and post(un)install scripts correct? Honestly. How the heck is a newbie supposed to know this? Again, concrete steps would be better. I'd suggest something like "are all pathnames in the pre/post(un) install scripts complete? Are macros used for all package files? Are all operations backed out? Is ldconfig being run if there are shared libraries installed? Maybe these should be a series of questions Also. Wheres the "does this package appear to work" line item? Do we QA packages and not actually run them? It seems like this is pretty basic criteria. 4. Epoch This appear to be subject to debate, and isn't included in a lot of upstream rpms. That being said it's easy to check so leave it in. Couldn't / doesn't rpmlint check this? 5. Are there no missing BuildRequires? This one took me a LONG time to check. The manual "remove all devel rpms" method is apparently deprecated according to the url above, however fedora.us doesn't even include a copy of mach. No less, mach is pretty complicated and you've got to figure out how to create a fedora.us enabled buildroot. After all that mach works great, except for I found out that it doesn't understand perl(Net::Lib) style depends, so it doesn't handle on buildrequires. There needs to be an official build environment. Mach works. Why not spend the hour it takes to get a copy of mach in the repo, with fc1+extras as the default buildroot? Then you can change this line to "Does the package build under mach". And the "how to build using mach" instructions can be yum install mach mach build mypackage.src.rpm 6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS. Not sure if this is relevant to anything, but again, it's easy to check. Couldn't rpmlint do this? 7. Are all paths within the .spec replaced with macros? Relatively easy to check, but I'd had to be tasked with this without having built a few rpms in the past. A howto for this process might be nice. 8. If the package has a DesktopEntry, are the VFolder categories ok? I don't have any idea what any of this stuff is. I don't build desktop software. Some documentation about it might be good. 9. Is the package free of any %{buildroot} macros? Apparently this is subject to debate. It's not a showstopper. Make it go away. 10. Is the package free of unowned directories? This is also very hard to check. You mean I have rpm -ivvh this package and then scroll through a whole pile of cruft to see the unowned directories? And then I have to know which ones it's "supposed" to own, and which ones it's now? The packages I checked didn't own /usr, /usr/lib, /usr/bin. I assume they aren't supposed to? This is a good thing to check, but theres gotta be a way to automate this, and if nothing else, explain what paths are ALLOWED to be unowned. 11. Is the License tag used rather than Copyright? Easy. Rpmlint should/can? Check this. 12. Is the package free of default passwords? Not necessarily easy to check, but easy to understand, and important. 13. Are all daemon's which can be installed to run as non-root installed as such? Same as 12. 14. Does the package handle a parallel build cleanly? Does this really matter? Seems like a nice thing to check but not a showstopper. Make it go away. Ok. So. Heres what I suggest to replace it all with Showstoppers: 1. Are the sources from upstream pristine and free from trojans? 2. Does the package build clean under mach? 3. Does the package follow the Fedora Package Naming Guidelines? 4. Does the package appear to work? 5. Is the package free of default passwords? 6. Are all daemon's which can be installed to run as non-root installed as such? Additional Critiques: 7. Are all paths within the .spec replaced with macros? 8. If the package has a DesktopEntry, are the VFolder categories ok? 9. Is the package free of unowned directories? <-- at least explain this 10. Does the package handle a parallel build cleanly? 11. Does it pass rpmlint cleanly? With good solid descriptions for 1-6 especially, I think it will become much easier to get useful information from would-be QA'ers. I'd like to see the how to help page say "Please do QA. Heres how" 1. Create bugzilla login 2. Follow this link to the list of packages needing QA. 3. Follow these instructions and fill out this checklist and post the results in a comment. Some additional notes: 1. Relax on the whole GPG thing. GPG is great. I figured it out. So can anybody else. But don't make it a barrier for entry. For a newbie, it's utterly unnecessary. The first thing you want people to do is to go through the package, create a bugzilla login, and post a completed checklist like I did above. When they first start, their input is going to be suspect anyway, so why slow down the process by an hour by figuring out how to use GPG? Bugzilla passwords aren't entirely insecure... 2. Provide some feedback. I QA'd some packages. I waited. And waited. A week later, AFTER I saw a discussion about bugzilla keywords and added "NEEDSWORK" to the packages I had QA'd, I got my first piece of feedback. This doesn't encourage repeat customers. It's a whole lot more rewarding when you submit something, and an hour later you get a message back from somebody saying "Hey, you messed up, but thanks for trying, can you please check a, b, and c?". I realize everybody's volunteering here, but there has GOT to be a way to detect when somebody new has posted to bugzilla and go check out what they did. If there were a "newbie comments" query available in bugzilla it might help. It's a set the hook sort of thing. 3. Provide a way for people to QA packages which have already been QA'd, so the 2 reviews happens. I think there has been some discussion about this. A link to an appropriate bugzilla query from the "How do I get started" page would be great. I think it's imperative that packages make it through the QA process. It doesn't do any good if packages never make it into the repo. Right now, they appear to just sit there. Then the packager gets fed up, doesn't respond if anybody checks his package, and starts a new repo. This is not building community. This process has GOT to be fast enough that when I submit a package for something that people actually use, it gets QA'd SOON, before I've lost all interest in it. In addition, there needs to be a way for a motivated packager to convince people to QA his work. Is sending email to fedora-devel saying "please QA my new widget package?" acceptable? Maybe a mailing list that automatically gets CC'd all new Fedora Meta New package Requests, NEEDSWORK, and REVIEWED keyword changes would help? Or maybe they should just go to fedora-devel? Anyway, just my $0.02. Hope you're still awake! --erik From katzj at redhat.com Thu Feb 26 22:47:13 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 26 Feb 2004 17:47:13 -0500 Subject: latest update In-Reply-To: <1077831368.3240.2.camel@old1> References: <1077831368.3240.2.camel@old1> Message-ID: <1077835633.8558.6.camel@mirkwood.boston.redhat.com> On Thu, 2004-02-26 at 17:21 -0500, Richard Hally wrote: > what is the problem with the /development tree? see below: It's the _development_ tree. GNOME packages are being updated and it's impossible to instantaneously update everything at once. The devel tree gets composed and pushed at 5 am eastern which is prime work time for Europe (which is where both Alex and Mark live) Cheers, Jeremy > [root at old1 root]# yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1.90 - i386 - Development > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package gnome-applets needs libgtop-2.0.so.1, this is not available. > Package gnome-system-monitor needs libgtop-2.0.so.1, this is not > available. > Package gnome-applets needs libgtop_common-2.0.so.1, this is not > available. > Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not > available. > Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not > available. > Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not > available. > [root at old1 root]# > > thanks for the help > Richard Hally > > > -- > 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 Thu Feb 26 23:12:37 2004 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Fri, 27 Feb 2004 00:12:37 +0100 Subject: Is menu editing in GNOME enabled in Fedora Core 2? Message-ID: <403E7D65.30207@haitsma.org> Hi, Menu editing for GNOME has always been disabled in Fedora Core 1 and Redhat 9 because of buggy gnome code. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81215 I always found this an annoying bug. I was wondering if this got fixed with the new GNOME packages? Jaap From toshio at tiki-lounge.com Thu Feb 26 23:25:03 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 26 Feb 2004 18:25:03 -0500 Subject: Prelink success story :) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> Message-ID: <1077837899.4875.163.camel@Madison.badger.com> On Thu, 2004-02-26 at 15:09, Dag Wieers wrote: > Then you clearly have much more time than I have. > Yep! I'm unemployed so there's no sense trying to out-talk me; only out-reasoning will do :-) > > > > 2] I have many packages that _have_ to change the %setup line, > > > 230 of the 622 spec-files which is over 30% (remember perl-packages ?) > > Doesn't matter. I took a look at several of your perl spec's. > > They do: > > %setup -n %{rname}-%{version} > > which will get caught by #2 above. > > And you said you hadn't seen any ocassions where %setup -n was needed What I said was: %setup -n foo-oldver [I've never seen this construct, only %{name}-%{version} which will fail b/c #2] or the tarball doesn't include versions in its toplevel directory [I have seen this]) I can see that you might have misinterpretted it. Mea Culpa. If I had written "I've never seen 'foo' and 'oldver' hardcoded into a %setup macro, only %setup -n %{name}-%{version} which will fail" it would have been clearer. > I understand you wanted to know the number of > packages that have '-n' used and not %{version}. Still 87 do, about 13%. > Excellent. Good data. So over 1 in 10 packages can potentially get past the packager and have to be caught by the QA people. Not trivial. > Although I must say I don't see why that would be of any value in the > discussion. > Because no other package will make it past the rpmbuild stage with mismatched version and Source0. So only these are potential QA problems. > > > 3] I don't rely on QA people as I'd rather automate and assume a > > > QA person has better things to do. > > That's fine. But your question was whether the QA person would catch > > the problem... > > Well, we will not know, would we. I'm just stating it's useless to ask > this from a QA person if you can automate it. True. Coupled with Ville's comment that package QA people really should be checking out web pages and so forth to make sure they have a canonical source rather than cut 'n paste, macros in Source: make more and more sense to me. (Although I'll definitely miss cut and paste when I'm QA'ing an update package and I already checked out the canonicalness in the previous version.) I suppose this is why this was good to continue even though it was not mandatory. I now have another reasoned out best practice to put to use. -Toshio -- Toshio From rhally at mindspring.com Thu Feb 26 23:34:27 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 26 Feb 2004 18:34:27 -0500 Subject: latest update In-Reply-To: <1077835633.8558.6.camel@mirkwood.boston.redhat.com> Message-ID: I understand it is "development" ! (eats babies) 8-). This just happened, ~ 5 PM eastern. I've been having very inconsistent results using yum. For example, it tells me "no packages available for update" when I know there are packages to update. If I try it with just download.fedora.Redhat.com the failover method sometimes fails, when I try it with several mirrors in addition to download.fedora.Redhat.com sometimes it works and some times it doesn't. My question is: is this normal? If not am I doing some thing wrong and what additional information will be useful in finding out what? Should I cut and paste terminal output with date and time and yum.conf? Thanks for the help Richard Hally On Thu, 2004-02-26 at 17:21 -0500, Richard Hally wrote: > what is the problem with the /development tree? see below: It's the _development_ tree. GNOME packages are being updated and it's impossible to instantaneously update everything at once. The devel tree gets composed and pushed at 5 am eastern which is prime work time for Europe (which is where both Alex and Mark live) Cheers, Jeremy > [root at old1 root]# yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1.90 - i386 - Development > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package gnome-applets needs libgtop-2.0.so.1, this is not available. > Package gnome-system-monitor needs libgtop-2.0.so.1, this is not > available. > Package gnome-applets needs libgtop_common-2.0.so.1, this is not > available. > Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not > available. > Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not > available. > Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not > available. > [root at old1 root]# > > thanks for the help > Richard Hally > > > -- > 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 ijuma82 at f2s.com Fri Feb 27 00:00:38 2004 From: ijuma82 at f2s.com (Ismael Juma) Date: Fri, 27 Feb 2004 00:00:38 +0000 Subject: latest update In-Reply-To: References: Message-ID: <403E88A6.5060705@f2s.com> Richard Hally wrote: >I've been having very inconsistent >results using yum. For example, it tells me "no packages available for >update" when I know there are packages to update. >If I try it with just download.fedora.Redhat.com the failover method >sometimes fails, when I try it with several mirrors in addition to >download.fedora.Redhat.com sometimes it works and some times it doesn't. > > AFAIK, the behaviour described above is usually a result of the time it takes for the mirrors to get in sync with the download.fedora.redhat.com server. I suggest either waiting for the mirror to get updated, or to choose a mirror that gets updated more frequently. Downloading directly from the download.fedora.redhat.com is usually not worth it because it is extremely slow. Regards, Ismael From surak at casa.surak.eti.br Fri Feb 27 00:03:46 2004 From: surak at casa.surak.eti.br (Alexandre Strube) Date: Thu, 26 Feb 2004 21:03:46 -0300 Subject: ARGOX Label printers In-Reply-To: <20040226215951.GC20592@lafferty.ca> References: <1077831506.13232.8.camel@casa> <20040226215951.GC20592@lafferty.ca> Message-ID: <1077840226.13232.102.camel@casa> Em Qui, 2004-02-26 ?s 18:59, Rich Lafferty escreveu: > > By the way, the lead the label printer market on Asia and South America, > > and most of those printers (even other brands) seems to share a common > > printer language, called PPLA and PPLB. I have access to the windows CD, > > which contains PPLA and PPLB language description... In case this > > interest someone. > My first reaction to this was that label-printing tends to be more > specialized than page-printing, so CUPS might just be the wrong place > to look. I'm aware of this. But can something be more specialized than 3d modelling? And there's blender :-) In fact, Linux used to be the homeland for specialized stuff - from scientific applications to ham-radio... > This might be of interest: > http://www.nicelabel.com/nicelabel/nlbl_ver_linux.php It doesn't work in Fedora as GUI, I already tried it. In fact, the only version they support is redhat 6.2. Sad to us. And oh yeah, one company which exports vegetable fibers (and was using redhat 9 and fedora) just switched back about 90% of their machines, because they do need thousands of labels printed a day (for the packages which go inside of ship containers), and most of the office's conputers prints at night... -- []s Alexandre Ganso 500 FOUR vermelha - Diretor Steel Goose Moto Group From rhallyx at mindspring.com Fri Feb 27 00:06:32 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Thu, 26 Feb 2004 19:06:32 -0500 Subject: Yum problems Message-ID: <1077840391.3240.10.camel@old1> Below is output from my attempts to get the latest updates from rawhide. Sorry for the long listing but this very frustrating. Can someone please help? [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers No Packages Available for Update No actions to take [root at old1 root]# vi /etc/yum.conf [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers Resolving dependencies .Package gnome-applets needs libgtop-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop-2.0.so.1, this is not available. Package gnome-applets needs libgtop_common-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not available. Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not available. [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers Resolving dependencies .Package gnome-applets needs libgtop-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop-2.0.so.1, this is not available. Package gnome-applets needs libgtop_common-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not available. Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not available. Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not available. [root at old1 root]# rpm -e gnome-applets [root at old1 root]# rpm -e gnome-system-monitor [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: kernel 2.6.3-1.109.i686] [install: kernel-source 2.6.3-1.109.i386] [update: pango 1.3.3-1.i386] [update: postgresql-libs 7.4.1-1.i386] [update: util-linux 2.12-4.i386] [update: magicdev 1.1.6-1.i386] [update: gtkhtml2-devel 2.5.5-1.i386] [update: rpmdb-fedora 1:1.90-0.20040226.i386] [update: XFree86-75dpi-fonts 4.3.0-60.i386] [update: gpdf 0.123-1.i386] [update: kdeutils-devel 6:3.2.0-1.2.i386] [update: postgresql-pl 7.4.1-1.i386] [update: finger 0.17-21.i386] [update: XFree86-doc 4.3.0-60.i386] [update: gnome-terminal 2.5.90-1.i386] [update: XFree86-ISO8859-14-100dpi-fonts 4.3.0-60.i386] [update: audiofile 1:0.2.5-1.i386] [update: policy-sources 1.6-8.noarch] [update: yelp 2.5.6-1.i386] [update: postgresql-devel 7.4.1-1.i386] [update: XFree86-Xvfb 4.3.0-60.i386] [update: XFree86-libs-data 4.3.0-60.i386] [update: XFree86-xfs 4.3.0-60.i386] [update: libgnomecanvas-devel 2.5.90-1.i386] [update: anaconda 9.91-0.20040225180009.i386] [update: koffice 4:1.3-5.i386] [update: pwlib 1.6.3-1.i386] [update: postgresql-python 7.4.1-1.i386] [update: gthumb 2.3.1-1.i386] [update: XFree86-ISO8859-2-100dpi-fonts 4.3.0-60.i386] [update: pango-devel 1.3.3-1.i386] [update: XFree86-sdk 4.3.0-60.i386] [update: XFree86-ISO8859-15-100dpi-fonts 4.3.0-60.i386] [update: kdeutils 6:3.2.0-1.2.i386] [update: XFree86-devel 4.3.0-60.i386] [update: pwlib-devel 1.6.3-1.i386] [update: XFree86-tools 4.3.0-60.i386] [update: postgresql-contrib 7.4.1-1.i386] [update: groff-gxditview 1.18.1-32.i386] [update: kernel-utils 1:2.4-9.1.121.i386] [update: dbus-glib 0.20-4.i386] [update: xcdroast 0.98a15-2.i386] [update: XFree86-Mesa-libGL 4.3.0-60.i386] [update: XFree86-Mesa-libGLU 4.3.0-60.i386] [update: rusers 0.17-37.i386] [update: dbus-x11 0.20-4.i386] [update: dbus-devel 0.20-4.i386] [update: glib2 2.3.3-1.i386] [update: fam 2.6.10-3.i386] [update: libgtop2-devel 2.5.1-1.i386] [update: libgtop2 2.5.1-1.i386] [update: groff-perl 1.18.1-32.i386] [update: postgresql 7.4.1-1.i386] [update: XFree86-ISO8859-9-100dpi-fonts 4.3.0-60.i386] [update: XFree86-ISO8859-15-75dpi-fonts 4.3.0-60.i386] [update: glib2-devel 2.3.3-1.i386] [update: setarch 1.4-1.i386] [update: XFree86-xauth 4.3.0-60.i386] [update: postgresql-jdbc 7.4.1-1.i386] [update: control-center 1:2.5.3-1.i386] [update: XFree86 4.3.0-60.i386] [update: postgresql-tcl 7.4.1-1.i386] [update: gkrellm 2.1.26-1.i386] [update: metacity 2.7.0-1.i386] [update: jfsutils 1.1.4-1.i386] [update: radvd 0.7.2-7.i386] [update: koffice-devel 4:1.3-5.i386] [update: libgnomecanvas 2.5.90-1.i386] [update: gtkhtml2 2.5.5-1.i386] [update: XFree86-xdm 4.3.0-60.i386] [update: coreutils 5.2.0-8.i386] [update: ncurses-devel 5.4-3.i386] [update: atk-devel 1.5.5-1.i386] [update: XFree86-100dpi-fonts 4.3.0-60.i386] [update: policy 1.6-8.noarch] [update: eject 2.0.13-5.i386] [update: grub 0.94-3.i386] [update: XFree86-cyrillic-fonts 4.3.0-60.i386] [update: XFree86-syriac-fonts 4.3.0-60.i386] [update: finger-server 0.17-21.i386] [update: XFree86-Xnest 4.3.0-60.i386] [update: postgresql-docs 7.4.1-1.i386] [update: XFree86-ISO8859-2-75dpi-fonts 4.3.0-60.i386] [update: gkrellm-daemon 2.1.26-1.i386] [update: fam-devel 2.6.10-3.i386] [update: XFree86-ISO8859-14-75dpi-fonts 4.3.0-60.i386] [update: postgresql-server 7.4.1-1.i386] [update: XFree86-truetype-fonts 4.3.0-60.i386] [update: XFree86-twm 4.3.0-60.i386] [update: gnome-themes 2.5.4-1.i386] [update: ncurses 5.4-3.i386] [update: anaconda-runtime 9.91-0.20040225180009.i386] [update: XFree86-libs 4.3.0-60.i386] [update: kernel-doc 2.6.3-1.109.i386] [update: XFree86-base-fonts 4.3.0-60.i386] [update: postgresql-test 7.4.1-1.i386] [update: XFree86-ISO8859-9-75dpi-fonts 4.3.0-60.i386] [update: dbus 0.20-4.i386] [update: groff 1.18.1-32.i386] [update: audiofile-devel 1:0.2.5-1.i386] [update: reiserfs-utils 2:3.6.11-3.i386] [update: atk 1.5.5-1.i386] [update: XFree86-font-utils 4.3.0-60.i386] [update: ncurses-c++-devel 5.4-3.i386] Is this ok [y/N]: y Downloading Packages Getting pango-1.3.3-1.i386.rpm pango-1.3.3-1.i386.rpm 100% |=========================| 244 kB 06:08 error: rpmts_HdrFromFdno: MD5 digest: BAD Expected (9b75c17760bcbc9b7d64221ff11b1944) != (827a27151d852a68dffc0f4d2b81621d) retrygrab() failed for: http://download.fedora.redhat.com/pub/fedora/linux/core/development/ i386//Fedora/RPMS/pango-1.3.3-1.i386.rpm Executing failover method failover: out of servers to try Error getting file http://download.fedora.redhat.com/pub/fedora/linux/ core/development/i386//Fedora/RPMS/pango-1.3.3-1.i386.rpm [Errno 7] HTTP Error (CannotSendRequest): [root at old1 root]# vi /etc/yum.conf [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers No Packages Available for Update No actions to take [root at old1 root]# vi /etc/yum.conf [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Damaged or Bad header.info from Fedora Core 1.90 - i386 - Development This is probably because of a downed server or an invalid header.info on a repository. [root at old1 root]# cat /etc/yum.conf [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 #[base] #name=Fedora Core $releasever - $basearch - Base #baseurl=http://fedora.redhat.com/releases/fedora-core-$releasever #[updates-released] #name=Fedora Core $releasever - $basearch - Released Updates #baseurl=http://fedora.redhat.com/updates/released/fedora-core- $releasever #[updates-testing] #name=Fedora Core $releasever - $basearch - Unreleased Updates #baseurl=http://fedora.redhat.com/updates/testing/fedora-core- $releasever [development] name=Fedora Core $releasever - $basearch - Development baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/ development/$basearch/ # ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/development/$basearch/ # ftp://ftp.net.usf.edu/pub/fedora/linux/core/development/$basearch/ # ftp://mirror.linux.duke.edu/pub/fedora/linux/core/development/ $basearch/ # http://mirror.linux.duke.edu/pub/fedora/linux/core/development/ $basearch/ # ftp://mirrors.kernel.org/fedora/core/development/$basearch/ #[SELinux] #name=SELinux - i386 - SELinux Repository #baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora/ [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: kernel 2.6.3-1.109.i686] [install: kernel-source 2.6.3-1.109.i386] [update: pango 1.3.3-1.i386] [update: postgresql-libs 7.4.1-1.i386] [update: util-linux 2.12-4.i386] [update: magicdev 1.1.6-1.i386] [update: gtkhtml2-devel 2.5.5-1.i386] [update: rpmdb-fedora 1:1.90-0.20040226.i386] [update: XFree86-75dpi-fonts 4.3.0-60.i386] [update: gpdf 0.123-1.i386] [update: kdeutils-devel 6:3.2.0-1.2.i386] [update: postgresql-pl 7.4.1-1.i386] [update: finger 0.17-21.i386] [update: XFree86-doc 4.3.0-60.i386] [update: gnome-terminal 2.5.90-1.i386] [update: XFree86-ISO8859-14-100dpi-fonts 4.3.0-60.i386] [update: audiofile 1:0.2.5-1.i386] [update: policy-sources 1.6-8.noarch] [update: yelp 2.5.6-1.i386] [update: postgresql-devel 7.4.1-1.i386] [update: XFree86-Xvfb 4.3.0-60.i386] [update: XFree86-libs-data 4.3.0-60.i386] [update: XFree86-xfs 4.3.0-60.i386] [update: libgnomecanvas-devel 2.5.90-1.i386] [update: anaconda 9.91-0.20040225180009.i386] [update: koffice 4:1.3-5.i386] [update: pwlib 1.6.3-1.i386] [update: postgresql-python 7.4.1-1.i386] [update: gthumb 2.3.1-1.i386] [update: XFree86-ISO8859-2-100dpi-fonts 4.3.0-60.i386] [update: pango-devel 1.3.3-1.i386] [update: XFree86-sdk 4.3.0-60.i386] [update: XFree86-ISO8859-15-100dpi-fonts 4.3.0-60.i386] [update: kdeutils 6:3.2.0-1.2.i386] [update: XFree86-devel 4.3.0-60.i386] [update: pwlib-devel 1.6.3-1.i386] [update: XFree86-tools 4.3.0-60.i386] [update: postgresql-contrib 7.4.1-1.i386] [update: groff-gxditview 1.18.1-32.i386] [update: kernel-utils 1:2.4-9.1.121.i386] [update: dbus-glib 0.20-4.i386] [update: xcdroast 0.98a15-2.i386] [update: XFree86-Mesa-libGL 4.3.0-60.i386] [update: XFree86-Mesa-libGLU 4.3.0-60.i386] [update: rusers 0.17-37.i386] [update: dbus-x11 0.20-4.i386] [update: dbus-devel 0.20-4.i386] [update: glib2 2.3.3-1.i386] [update: fam 2.6.10-3.i386] [update: libgtop2-devel 2.5.1-1.i386] [update: libgtop2 2.5.1-1.i386] [update: groff-perl 1.18.1-32.i386] [update: postgresql 7.4.1-1.i386] [update: XFree86-ISO8859-9-100dpi-fonts 4.3.0-60.i386] [update: XFree86-ISO8859-15-75dpi-fonts 4.3.0-60.i386] [update: glib2-devel 2.3.3-1.i386] [update: setarch 1.4-1.i386] [update: XFree86-xauth 4.3.0-60.i386] [update: postgresql-jdbc 7.4.1-1.i386] [update: control-center 1:2.5.3-1.i386] [update: XFree86 4.3.0-60.i386] [update: postgresql-tcl 7.4.1-1.i386] [update: gkrellm 2.1.26-1.i386] [update: metacity 2.7.0-1.i386] [update: jfsutils 1.1.4-1.i386] [update: radvd 0.7.2-7.i386] [update: koffice-devel 4:1.3-5.i386] [update: libgnomecanvas 2.5.90-1.i386] [update: gtkhtml2 2.5.5-1.i386] [update: XFree86-xdm 4.3.0-60.i386] [update: coreutils 5.2.0-8.i386] [update: ncurses-devel 5.4-3.i386] [update: atk-devel 1.5.5-1.i386] [update: XFree86-100dpi-fonts 4.3.0-60.i386] [update: policy 1.6-8.noarch] [update: eject 2.0.13-5.i386] [update: grub 0.94-3.i386] [update: XFree86-cyrillic-fonts 4.3.0-60.i386] [update: XFree86-syriac-fonts 4.3.0-60.i386] [update: finger-server 0.17-21.i386] [update: XFree86-Xnest 4.3.0-60.i386] [update: postgresql-docs 7.4.1-1.i386] [update: XFree86-ISO8859-2-75dpi-fonts 4.3.0-60.i386] [update: gkrellm-daemon 2.1.26-1.i386] [update: fam-devel 2.6.10-3.i386] [update: XFree86-ISO8859-14-75dpi-fonts 4.3.0-60.i386] [update: postgresql-server 7.4.1-1.i386] [update: XFree86-truetype-fonts 4.3.0-60.i386] [update: XFree86-twm 4.3.0-60.i386] [update: gnome-themes 2.5.4-1.i386] [update: ncurses 5.4-3.i386] [update: anaconda-runtime 9.91-0.20040225180009.i386] [update: XFree86-libs 4.3.0-60.i386] [update: kernel-doc 2.6.3-1.109.i386] [update: XFree86-base-fonts 4.3.0-60.i386] [update: postgresql-test 7.4.1-1.i386] [update: XFree86-ISO8859-9-75dpi-fonts 4.3.0-60.i386] [update: dbus 0.20-4.i386] [update: groff 1.18.1-32.i386] [update: audiofile-devel 1:0.2.5-1.i386] [update: reiserfs-utils 2:3.6.11-3.i386] [update: atk 1.5.5-1.i386] [update: XFree86-font-utils 4.3.0-60.i386] [update: ncurses-c++-devel 5.4-3.i386] Is this ok [y/N]: y Downloading Packages error: rpmts_HdrFromFdno: MD5 digest: BAD Expected (9b75c17760bcbc9b7d64221ff11b1944) != (827a27151d852a68dffc0f4d2b81621d) Damaged RPM /var/cache/yum/development/packages/pango-1.3.3-1.i386.rpm, removing. Getting pango-1.3.3-1.i386.rpm pango-1.3.3-1.i386.rpm 100% |=========================| 264 kB 00:06 Getting postgresql-libs-7.4.1-1.i386.rpm postgresql-libs-7.4.1-1.i 100% |=========================| 108 kB 05:05 error: rpmts_HdrFromFdno: MD5 digest: BAD Expected (d3ae589dcbf01c862aba8f5cb20527fd) != (5f2a04fc84ea84dbb6912e1050a0bd3f) retrygrab() failed for: http://download.fedora.redhat.com/pub/fedora/linux/core/development/ i386//Fedora/RPMS/postgresql-libs-7.4.1-1.i386.rpm Executing failover method failover: out of servers to try Error getting file http://download.fedora.redhat.com/pub/fedora/linux/ core/development/i386//Fedora/RPMS/postgresql-libs-7.4.1-1.i386.rpm [Errno 7] HTTP Error (CannotSendRequest): [root at old1 root]# date Thu Feb 26 18:39:06 EST 2004 [root at old1 root]# cat /etc/yum.conf [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 #[base] #name=Fedora Core $releasever - $basearch - Base #baseurl=http://fedora.redhat.com/releases/fedora-core-$releasever #[updates-released] #name=Fedora Core $releasever - $basearch - Released Updates #baseurl=http://fedora.redhat.com/updates/released/fedora-core- $releasever #[updates-testing] #name=Fedora Core $releasever - $basearch - Unreleased Updates #baseurl=http://fedora.redhat.com/updates/testing/fedora-core- $releasever [development] name=Fedora Core $releasever - $basearch - Development baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/ development/$basearch/ # ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/development/$basearch/ # ftp://ftp.net.usf.edu/pub/fedora/linux/core/development/$basearch/ # ftp://mirror.linux.duke.edu/pub/fedora/linux/core/development/ $basearch/ # http://mirror.linux.duke.edu/pub/fedora/linux/core/development/ $basearch/ # ftp://mirrors.kernel.org/fedora/core/development/$basearch/ #[SELinux] #name=SELinux - i386 - SELinux Repository #baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora/ [root at old1 root]# vi /etc/yum.conf [root at old1 root]# cat /etc/yum.conf [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 #[base] #name=Fedora Core $releasever - $basearch - Base #baseurl=http://fedora.redhat.com/releases/fedora-core-$releasever #[updates-released] #name=Fedora Core $releasever - $basearch - Released Updates #baseurl=http://fedora.redhat.com/updates/released/fedora-core- $releasever #[updates-testing] #name=Fedora Core $releasever - $basearch - Unreleased Updates #baseurl=http://fedora.redhat.com/updates/testing/fedora-core- $releasever [development] name=Fedora Core $releasever - $basearch - Development baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/ development/$basearch/ ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/development/$basearch/ ftp://ftp.net.usf.edu/pub/fedora/linux/core/development/$basearch/ ftp://mirror.linux.duke.edu/pub/fedora/linux/core/development/ $basearch/ http://mirror.linux.duke.edu/pub/fedora/linux/core/development/ $basearch/ ftp://mirrors.kernel.org/fedora/core/development/$basearch/ #[SELinux] #name=SELinux - i386 - SELinux Repository #baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora/ [root at old1 root]# date Thu Feb 26 18:42:47 EST 2004 [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers Resolving dependencies ....Unable to satisfy dependencies Package dbus-glib needs dbus = 0.20-4, this is not available. Package dbus-x11 needs dbus = 0.20-4, this is not available. Package XFree86-libs needs XFree86-libs-data = 4.3.0-60, this is not available. Package libgnomecanvas-devel needs libgnomecanvas = 2.5.3, this is not available. [root at old1 root]# date Thu Feb 26 18:58:59 EST 2004 [root at old1 root]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.90 - i386 - Development Finding updated packages Downloading needed headers No Packages Available for Update No actions to take [root at old1 root]# From ms-nospam-0306 at arcor.de Fri Feb 27 00:14:34 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 01:14:34 +0100 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> Message-ID: <20040227011434.7b24a4cd.ms-nospam-0306@arcor.de> [changed subject line!] On Thu, 26 Feb 2004 17:43:22 -0500, Erik LaBianca wrote: > As a longtime redhat user (4+ yrs) and not-entirely-new rpm packager (2 > yrs) and professional system administrator / software engineer, it took > me over 8 hours of work before I submitted my first QA review. This is > partially because I hadn't been using GPG, partially because I didn't > have a bugzilla account, partially due to general incompetence on my > part, and partially due to the amount of material in the QA checklist. ... and, of course, because you've realized that you take a big portion of responsibility with your approval of a package, so you wanted to aim at perfection, didn't you? ;) Yes, of course you wanted to avoid any mistakes. :) > 1. Information how "how to do some useful qa" is scattered. Remains the question whether you could really instruct newbies without the help of a book or a few courses. > 2. Too much detail. The QA checklist is great. However, as it turns out, > a lot of the stuff being checked there aren't really showstoppers. I > ended up turning it into a list I added an entry to the checklist yesterday. A show-stopper IMO. To check file permissions and ownership. Has happened several times, that a %defattr was missing or files/directories were inaccessible. > There should be a template like I have above, that can be answered > with simple yes or no answers, that covers all the showstoppers. That > way a newbie can fill it in the blank with yes's or no's and no he's > done something useful. But would that be useful? Do you expect someone to go through the list a newbie posted and check step by step whether he made a mistake? I think the checklist is for personal use only and should not be attached to package requests as a Yes/No answered list. Approvals should be short and to the point and concentrate on a few items. If I had to fill out a list of what I check, that would slow me down a lot unless some special software would aid me upon maintaining the list. > Since all the checklist items are there, answered > with yes or no questions, it's easy to know if they actually made a good > faith effort to check the package. Which increases the workload a lot, when many items are not needed for a particular package or when many more items are added to the list (because it isn't complete). Reviewers should develop a feeling for what is important and what is not. > Some critique of the list: > > 1. Does the package follow the Fedora Package Naming Guidelines? > This is pretty darn complicated for a newbie QA'er. They should be > allowed to opt out. A "senior developer" could look at the package in 10 > seconds and understand whether or not the name is ok. But package naming and versioning issues don't stop anyone from reviewing the rest of a package, do they? > 2. Are the sources from upstream pristine and free from trojans? > This is important, but exceedingly difficult to do "properly"... At what > point does this become a showstopper? At some point it becomes > impossible to verify the source without actually being the author of the > code and inspecting it line by line. For a newbie this is very > intimidating Of course. Still, the least someone can do is compare the MD5 checksums and also check packages from other distributions (not because they are trusted ultimately, but to fetch the source from multiple locations) and visit the home page (and e.g. directories like freshmeat.net) to check whether a release might be official. Asking upstream authors for MD5 checksums via e-mail doesn't work well. I've tried without luck to get some to post clearsigned checksums in the download area. > 3. Are the pre- and post(un)install scripts correct? > Honestly. How the heck is a newbie supposed to know this? Depends on how new he's to RPM. > Again, concrete steps would be better. Somebody would need to create such documentation. There are entire books about RPM. And you could fill more chapters with documentation on when a %pre/%post script can be considered "correct". > I'd suggest something like "are all > pathnames in the pre/post(un) install scripts complete? What does that mean? Macros in scripts are okay and are expanded at build-time. Environment variables are not okay because they are evaluated at run-time. > Are macros used for all package files? Depends on whether it makes sense. If the source code has some paths hardcoded, it doesn't make much sense to use corresponding macros in the spec file. > Also. Wheres the "does this package appear to work" line item? Do we QA > packages and not actually run them? It seems like this is pretty basic > criteria. Are step by step items on "does it build?", "does it install?", "does it upgrade?", "does it erase?" really necessary? > 4. Epoch > > This appear to be subject to debate, and isn't included in a lot of > upstream rpms. That being said it's easy to check so leave it in. > Couldn't / doesn't rpmlint check this? It does. > 5. Are there no missing BuildRequires? > > This one took me a LONG time to check. The manual "remove all devel > rpms" method is apparently deprecated according to the url above, > however fedora.us doesn't even include a copy of mach. No less, mach is > pretty complicated and you've got to figure out how to create a > fedora.us enabled buildroot. "mach" is not mandatory. I've tried it once, long ago. Use what works for you. It can be embarrassing if an approved package fails in the build system. > 6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS. > > Not sure if this is relevant to anything, but again, it's easy to check. > Couldn't rpmlint do this? AFAIK, rpmlint checks whether a group is known, but not whether a package is put into the proper category. > 8. If the package has a DesktopEntry, are the VFolder categories ok? > > I don't have any idea what any of this stuff is. I don't build desktop > software. Some documentation about it might be good. Documentation is linked (www.freedesktop.org). > 10. Is the package free of unowned directories? > > This is also very hard to check. You mean I have rpm -ivvh this package > and then scroll through a whole pile of cruft to see the unowned > directories? And then I have to know which ones it's "supposed" to own, > and which ones it's now? You can also "rpm -qlv |less" the package and make sure that it owns its _own_ directories. ;) > The packages I checked didn't own /usr, /usr/lib, /usr/bin. I assume > they aren't supposed to? $ rpm -qf /usr /usr/lib /usr/bin filesystem-2.2.1-5 filesystem-2.2.1-5 flash-plugin-6.0.79-2 filesystem-2.2.1-5 Ooops! :) Flash-plugin owns something it shouldn't. Lots of directories belong to the filesystem and major core packages (e.g. kdebase) already. > This is a good thing to check, but theres gotta be a way to automate > this, and if nothing else, explain what paths are ALLOWED to be unowned. This depends on a package's dependencies, e.g. whether the package adds files to the directory of a package it depends on. In that case it would not need to own the directory. > 14. Does the package handle a parallel build cleanly? > > Does this really matter? Seems like a nice thing to check but not a > showstopper. Make it go away. It is a showstopper, because a package which "make"s with %_smp_mflags in the spec file might break badly in the build system. It is not always obvious whether such breakage is due to SMP make flags. Defining "%_smp_mflags -j3" in your local ~/.rpmmacros file also on UP machines can help detect breakage. > 11. Does it pass rpmlint cleanly? Not always possible. :) > With good solid descriptions for 1-6 especially, I think it will become > much easier to get useful information from would-be QA'ers. I'd like to > see the how to help page say "Please do QA. Heres how" And when issues not covered in the list come up, those people are fed up. E.g. but not limited to: * build not accepting $RPM_OPT_FLAGS * build stripping binaries * bad -rpath found * archdependent files below %_datadir * not adhering to FHS * spec file sections in wrong order (e.g. builds in %install section) * libtool archives not deleted and not needed or wrong paths in libtool archives * *.so links in non-devel package and not needed there * python *.py{c,o} files not marked %ghost * perl modules installed into site location, not vendor location * macros in %changelog > 2. Provide some feedback. I QA'd some packages. I waited. And waited. A > week later, AFTER I saw a discussion about bugzilla keywords and added > "NEEDSWORK" to the packages I had QA'd, NEEDSWORK is to move packages out of the QA queue, because they don't build or need more work before they are moved back into the QA queue. This can also be set by the packager if major changes are planned. REVIEWED is the new keyword to flag reviewed packages, so they are easy to locate. > I got my first piece of > feedback. This doesn't encourage repeat customers. It's a whole lot more > rewarding when you submit something, and an hour later you get a message > back from somebody saying "Hey, you messed up, but thanks for trying, > can you please check a, b, and c?". Lack of man power. More reviewers are needed. Especially since we don't know how/what official Fedora Extras will change. > I think it's imperative that packages make it through the QA process. It > doesn't do any good if packages never make it into the repo. Right now, > they appear to just sit there. Then the packager gets fed up, doesn't > respond if anybody checks his package, and starts a new repo. Not every packager can work on his packages as soon as someone found issues. Sometimes you need to wait till the next weekend. If the packager doesn't respond, simply move the request out of the package queue by deleting the QA keyword and setting the NEEDSWORK keyword. > This is > not building community. This process has GOT to be fast enough that when > I submit a package for something that people actually use, it gets QA'd > SOON, before I've lost all interest in it. If there are people with interest in a package, surely there should be two reviewers, too? -- From leonard at den.ottolander.nl Fri Feb 27 00:17:20 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 01:17:20 +0100 Subject: EOLed products and CURRENTRELEASE In-Reply-To: References: <20040226154012.GA9566@popelka.ms.mff.cuni.cz> Message-ID: <1077841039.4774.7.camel@athlon.localdomain> Hi Mike, Milo, > >Would anybody object to closing bugs in EOLed products (currently > >RHL < 9) that are fixed in FC1 as CURRENTRELEASE? > > I think that is a good idea, and is totally appropriate. If any > particular bug isn't 100% certain though, best to post it here > for review by others also. Ok. In that case bugs 91655, 82303, 82302 and 78432 can be closed CURRENTRELEASE. 97783 almost certainly but 100407 turned out not to be solved with gnome-panel-2.4.2-1. 106673 is a FC1 test2 bug that has also been solved, and 101513 has also most probably been solved (needs verification by the reporter). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ms-nospam-0306 at arcor.de Fri Feb 27 00:20:02 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 01:20:02 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <1077837899.4875.163.camel@Madison.badger.com> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> Message-ID: <20040227012002.3283ea75.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 18:25:03 -0500, Toshio wrote: > Coupled with Ville's comment that package QA people really > should be checking out web pages and so forth to make sure they have > a canonical source rather than cut 'n paste, macros in Source: make more > and more sense to me. (Although I'll definitely miss cut and paste when > I'm QA'ing an update package and I already checked out the canonicalness > in the previous version.) Macros in URLs simply don't work. If you want macros in Source tags, cut off everything up to the file name like Source0: %name-%version.tar.gz and put an example download URL as a comment, e.g. # ftp://ftp.foo.bar/foo/foo-1.0.tar.gz Source0: %name-%version.tar.gz Certainly much better than weird constructs like Source0: http://www.foo.bar/%name/%version/%name-%{version}rc1.tar.gz (note the ugly "rc1" hack) Also note that only the expanded file name will appear in the RPM header, not the URL prefix. -- From redhat-forums at genesis-x.nildram.co.uk Fri Feb 27 00:27:32 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Fri, 27 Feb 2004 00:27:32 +0000 Subject: OMG! I've started a war! - Was:Prelink success story :) References: Message-ID: OMG ... I've started a war! Please believe that it was not my intention to do so. Feelings are obviously running high on these issues, so I guess it doesn't take much to set people off. Here's my take on the situation with regards Fedora policy. Fedora (as a distro) is still young enough to have major teething problems; let's not start fighting over issues that are still work-in-progress. As for this perception that those in charge at Fedora are overbearing ?bermeisters and that policy is set in stone, I'm sure that isn't true. Let's calm down and discuss things without slinging mud at each other. Lest we forget, it was these overbearing ?bermeisters who gave us a rock solid, bleeding edge, community based, distro in less than a year. My reason for getting involved with the project is simple. Like most of us, I'm an ex-Red-Hatter who migrated to Fedora. Where I discover I gap in the tools (or amusements) I need, I look for the source and package it. That's it. If I need bleeding edge enhancements in core components, I chase them up, help out where I can, and try to push through an updated release. I am filled with nothing but respect and admiration for those who work on these projects (I know from experience how time consuming and energy draining it is). I'm certainly not going to start arbitrarily cutting people up over trivial issues - if that's how I come across, then I'm sorry, and the best explanation I can offer is - when you've been burning the candle at both ends (like I very often do) then your tone comes off sounding, shall we say, a bit abrasive. It's not how I'm thinking. As for this fist fight between Micheal and Dag, let me just say that this is a real storm in a teacup. The amount of work that Dag must do to maintain his repo (single handed?) must be frightening, and his semi-automated packaging/build system is highly innovative (OK, maybe not perfect yet, but still brilliant). (Incidentally, if you're reading this Dag, I would appreciate some info on how you build your perl modules (ref: rpm macros and dependency checking), and also your kernel module packages.) I'm sure someone who works that hard without financial reward, surely cannot be described as someone who doesn't care. I package for Fedora, but I also package for Livna, but that doesn't mean that I am somehow being disloyal to the Fedora project. It isn't about picking sides, or about "them" and "us", it's about contributing towards something you believe in, and which gives you a degree of satisfaction and pleasure. I don't feel threatened by the existence of DAG-RPMS any more than I do about Livna, in fact I'm glad of having more choice. That is, after all, what "community" is all about. When I first started packaging for Fedora, despite years of experience in Unix, Linux and networking security, I simply didn't have a clue about RPM, and didn't pretend to. I was a bit taken-aback by, what I perceived as, Michael's abrasive nature. Having worked with him for the last 3 months, I can say that, although his tone is a bit dry, his attitude is very positive, and I wouldn't have reached anywhere near the level of competence I have now, without his input. Please do not mistake Michael's tone as sarcasm or arrogance, since I'm sure that he, of all people, has no interest in driving developers away from something he cares about so passionately. If Michael has a fault, it is that he is a perfectionist in the extreme, but that's his thing, and more power to him. There's little wrong with striving to protect and improve that which you believe in, and work so hard for. So please, people, let's get back to talking shop, before I start getting withdrawal symptoms from my daily fix of techno-jargon :) Oh, and yes ... I vote for keeping %{buildroot} and ditching $RPM_BUILD_ROOT. (Sorry - couldn't resist). - K. * The debuginfo package for my brain is available on my website. Please run it against gdb and forward any errors to the developer. From icon at linux.duke.edu Fri Feb 27 01:16:47 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Thu, 26 Feb 2004 20:16:47 -0500 Subject: Using bit torrent to retrieve RPMs for updates In-Reply-To: <200402261342.19650.jgardner@jonathangardner.net> References: <200402261342.19650.jgardner@jonathangardner.net> Message-ID: <403E9A7F.90504@linux.duke.edu> On 26.02.2004 16:42, Jonathan Gardner wrote: > Has anyone given serious thought to changing Yum so that it uses the > bittorrent protocol to retrieve RPMs? Especially in the case of updates, > when everyone and their grandmother needs to get the RPMs right away, this > would make a lot of sense. Yum could manage a repository of RPMs and > constantly serve those up so other can download parts of them via > bittorrent, all with permission, of course. We have pondered this solution many times here, but there are several important drawbacks: 1. Bittorrent is highly inefficient for a large collection of small files. You will have to start a separate tracker item for each rpm, and for some of them the amount of traffic generated just tracking the p2p clients will outweigh the savings of using bittorrent. I would imagine that several thousands of tracker items would also be quite processor-intensive. 2. You have to specifically punch holes in the firewall for bittorrent -- not one, but a range of ports, actually. Something most people will not do, so they will be constantly leeching. 3. Yum runs as root, so you suddenly have a very large amount of code (yum+bittorrent libs) listening as root for incoming connections. Yikes. Alternatively, you'd have to fork a downloader process and communicate with it using some methods. Either way is painful. As you see, bittorrent is not very beneficial. However, a bittorent-like system used by *mirrors* could be of benefit. E.g. the client-side connects to the main server and says "I want foo-1.0-1.i386.rpm". The server then returns: Checksum information for foo-1.0-1.i386.rpm: bytes 0...10000: chksum1 bytes 10000...20000: chksum2 .... bytes n-10000...n: chksum n The following servers claim to have it: mirror.fooland.foo mirror.barland.bar .... mirror.bazland.baz Go get it yourself. The client then connects to the mirrors and fetches the ranges specified in the server response, thus creating a primitive swarm. The fetching can be done via http, ftp, and file as they all support fetching by byte range. This would allow for auto-balancing the mirror load, though this solution is not without its own set of difficulties: 1. This still keeps thousands of trackers on the server, though having dedicated servers and limited tracker traffic compared to bittorent would theoretically be easier. 2. How to keep the list of mirrors current? Should they stay constantly connected to the main server a la bittorrent clients? Should they use some other bittorent-like protocol for syncing with each-other? 3. As tracker info per each package would be auto-generated, there's no way to sign it (this would require keeping key on the server, which is no-no). Attackers could potentially annoy a lot of people by publishing bogus mirror data pointing to odd places. Though this isn't really dangerous, as after all the final RPM fetched from various servers by bits and pieces would be still cryptographically signed. This could be a fun project to play with, if anyone likes to mess with things like that. :) -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE I am looking for a job in Canada! http://linux.duke.edu/~icon/cajob.ptml From toshio at tiki-lounge.com Fri Feb 27 01:20:41 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 26 Feb 2004 20:20:41 -0500 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227012002.3283ea75.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> Message-ID: <1077844839.4875.174.camel@Madison.badger.com> On Thu, 2004-02-26 at 19:20, Michael Schwendt wrote: > Macros in URLs simply don't work. If you want macros in Source tags, > cut off everything up to the file name like > I'm not sure I understand your first statement. Everything else you say makes sense. I'm just not making the last simple leap into enlightenment here. I guess I don't understand in what sense you mean "don't work". Sure your example Source: was ugly but is that the extent of the complaint or is there something further? > > Also note that only the expanded file name will appear in the RPM header, > not the URL prefix. Some simple testing shows that this is true whether or not macros are used in the Source: line. So your point is that using a URL in a Source line is purely for the benefit of the QA'er/packager anyhow? -Toshio -- Toshio From ms-nospam-0306 at arcor.de Fri Feb 27 01:24:42 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 02:24:42 +0100 Subject: OMG! I've started a war! - Was:Prelink success story :) In-Reply-To: References: Message-ID: <20040227022442.1cb028e8.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 00:27:32 +0000, Keith G. Robertson-Turner wrote: > OMG ... I've started a war! My impression is more that of a smouldering fire which hasn't been put out since the pre-fedora.us discussions, because nobody knows how to put it out. > Feelings are obviously running high on these issues, so I guess it > doesn't take much to set people off. Just don't read inbetween the lines. > As for this fist fight between Micheal and Dag, let me just say that this > is a real storm in a teacup. Wonder what makes it look like a "fight"? > I'm sure someone who works that hard without financial reward, surely > cannot be described as someone who doesn't care. You're extending the topic quite a bit now. "Doesn't care" as in "doesn't care about fedora.us". Dag runs his own show, and he has done so already during the fedora.us preparation talks. There is no reason to believe, that if the QA checklist were modified today, he would take over maintainership of some packages at fedora.us. So, it is beyond my comprehension why a fedora.us policy debate was started/refreshed on this list today by him (with a side-shot on "votes", "mandatory" things, "IRC decisions" and stuff like that). > I don't feel threatened by the existence of DAG-RPMS any more than I do > about Livna, in fact I'm glad of having more choice. That is, after all, > what "community" is all about. Imagine Dag would stop maintaining his hundreds of packages all of a sudden (without any particular reason). Or what happens if he's on vacation and a security issue needs to be fixed? And if he works on package A, he cannot work on package B. There are more reasons why it's important for the "community" to have an open community packaging project. > When I first started packaging for Fedora, despite years of experience in > Unix, Linux and networking security, I simply didn't have a clue about > RPM, and didn't pretend to. I was a bit taken-aback by, what I perceived > as, Michael's abrasive nature. *That* I hear for the first time. > Having worked with him for the last 3 > months, I can say that, although his tone is a bit dry, Here I would like to hear more details and suggestions on what I should change and how. > his attitude is > very positive, and I wouldn't have reached anywhere near the level of > competence I have now, without his input. Please do not mistake Michael's > tone as sarcasm or arrogance, since I'm sure that he, of all people, has > no interest in driving developers away from something he cares about so > passionately. If Michael has a fault, it is that he is a perfectionist in > the extreme, I think that doesn't match myself, as at fedora.us I've aimed at productivity, not perfectionism. Of course, I need to be careful as to not become sloppy in what I approve. Btw, nothing in the Wiki is from me. I only edited a few places yesterday. So, I really don't see where you've got the picture of an extreme perfectionist from. -- From ms-nospam-0306 at arcor.de Fri Feb 27 01:30:43 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 02:30:43 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <1077844839.4875.174.camel@Madison.badger.com> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> Message-ID: <20040227023043.15f11272.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 20:20:41 -0500, Toshio wrote: > On Thu, 2004-02-26 at 19:20, Michael Schwendt wrote: > > Macros in URLs simply don't work. If you want macros in Source tags, > > cut off everything up to the file name like > > > I'm not sure I understand your first statement. Everything else you say > makes sense. I'm just not making the last simple leap into > enlightenment here. I guess I don't understand in what sense you mean > "don't work". Sure your example Source: was ugly but is that the > extent of the complaint or is there something further? Is an URL which contains macros still an URL? What do you do with an URL that contains macros? You can't cut'n'paste it into a browser, because it contains macros. So why include protocol, hostname and path in Source fields at all? How does the packager fetch a new release? Does he visit the web page from bookmarks? Or does he reconstruct a valid URL from the macros? > > > > Also note that only the expanded file name will appear in the RPM header, > > not the URL prefix. > > Some simple testing shows that this is true whether or not macros are > used in the Source: line. So your point is that using a URL in a Source > line is purely for the benefit of the QA'er/packager anyhow? Yes, provided that it is free of macros. -- From cornette at insight.rr.com Fri Feb 27 01:58:24 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Thu, 26 Feb 2004 20:58:24 -0500 Subject: latest update In-Reply-To: <1077831368.3240.2.camel@old1> References: <1077831368.3240.2.camel@old1> Message-ID: <403EA440.1050405@insight.rr.com> Richard Hally wrote: > what is the problem with the /development tree? see below: > > [root at old1 root]# yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1.90 - i386 - Development > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package gnome-applets needs libgtop-2.0.so.1, this is not available. > Package gnome-system-monitor needs libgtop-2.0.so.1, this is not > available. > Package gnome-applets needs libgtop_common-2.0.so.1, this is not > available. > Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not > available. > Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not > available. > Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not > available. > [root at old1 root]# > > thanks for the help > Richard Hally > > I had the conflict with libgtop2 also. I just deselected it in up2date-gnome and everything else installed without issues. The conflict was due to this error message from up2date. (error dialog box) ------------------ There was a package dependency problem. The message was: Unresolvable chain of dependencies: gnome-applets 2.5.4-2 requires libgtop-2.0.so.1 gnome-applets 2.5.4-2 requires libgtop_common-2.0.so.1 gnome-applets 2.5.4-2 requires libgtop_sysdeps-2.0.so.1 gnome-system-monitor 2.5.2-2 requires libgtop-2.0.so.1 gnome-system-monitor 2.5.2-2 requires libgtop_common-2.0.so.1 gnome-system-monitor 2.5.2-2 requires libgtop_sysdeps-2.0.so.1 Please modify your package selections and try again. ---------------- Just unselect libgltop2 and try again. Jim From toshio at tiki-lounge.com Fri Feb 27 02:33:49 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 26 Feb 2004 21:33:49 -0500 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227023043.15f11272.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> Message-ID: <1077849223.4875.193.camel@Madison.badger.com> On Thu, 2004-02-26 at 20:30, Michael Schwendt wrote: > Is an URL which contains macros still an URL? What do you do with an URL > that contains macros? You can't cut'n'paste it into a browser, because it > contains macros. So why include protocol, hostname and path in Source > fields at all? How does the packager fetch a new release? Does he visit > the web page from bookmarks? Or does he reconstruct a valid URL from > the macros? > Thanks, Michael, that's a great explanation. I've got a new scenario to ask about: do any of the autobuilders the Fedora Project is going to use depend on being able to parse the Source: line into a URL? (I thought I read something about mach using the Source line, but on second read I see that's if you provide a bare spec, not the srpm.) -Toshio -- Toshio From notting at redhat.com Fri Feb 27 02:57:51 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Feb 2004 21:57:51 -0500 Subject: Fedora Core 2 Test 2 - delayed Message-ID: <20040227025751.GF29689@devserv.devel.redhat.com> We're encountering various issues that are causing us to delay the release of test2. We'd like to get as much exposure to SELinux as possible, and this means shipping test2 with SELinux in enforcing mode. However, there are still some subsystems that aren't quite ready for this, so we need to slide the release date some. The *current* projection is that the freeze will be on March 12, for availability on March 22. This date is only preliminary at this point, and may change. The schedule at: http://fedora.redhat.com/participate/schedule/ will be updated shortly. Bill From erik at totalcirculation.com Fri Feb 27 03:03:26 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 26 Feb 2004 22:03:26 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CD948@smith.interlink.local> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Michael Schwendt > Sent: Thursday, February 26, 2004 7:15 PM > To: fedora-devel-list at redhat.com > Subject: Fedora.us QA (was: Re: Prelink success story :)) > > > ... and, of course, because you've realized that you take a big portion of > responsibility with your approval of a package, so you wanted to aim > at perfection, didn't you? ;) Yes, of course you wanted to avoid any > mistakes. :) You got me there :) > > 1. Information how "how to do some useful qa" is scattered. > > Remains the question whether you could really instruct newbies without the > help of a book or a few courses. A good question it is. My belief is that it must be possible. At least, I like to think I made a useful contribution, and I read no books and took no courses. They'll not be packaging guru's overnight, but they'll be able to "get up to speed" doing something useful. > I added an entry to the checklist yesterday. A show-stopper IMO. > To check file permissions and ownership. Has happened several times, > that a %defattr was missing or files/directories were inaccessible. I agree on that one. File %defattr can make a nasty mess to be sure. > > > There should be a template like I have above, that can be answered > > with simple yes or no answers, that covers all the showstoppers. That > > way a newbie can fill it in the blank with yes's or no's and no he's > > done something useful. > > But would that be useful? Do you expect someone to go through the list a > newbie posted and check step by step whether he made a mistake? I think > the checklist is for personal use only and should not be attached to > package requests as a Yes/No answered list. Approvals should be short and > to the point and concentrate on a few items. If I had to fill out a list > of what I check, that would slow me down a lot unless some special > software would aid me upon maintaining the list. Well, honestly, yes, I do expect someone to go over a newbies work. That's what the "2 reviews" policy for, isn't it? For someone such as yourself, who clearly knows what makes a good package at a much deeper than just "did it pass the showstopper checklist", the need to fill out the checklist becomes less if at all. I don't know why it would take more than a few seconds to fill out a basic showstopper checklist. Obviously, the more skilled the QA'er, the more additional "value" they add beyond the checklist. But the checklist makes a good start, and allows someone without that "common sense" you referred to earlier today to make a meaningful contribution and get up to speed. Think of it as a pre-flight checklist. I think this sort of formalism is one of the area's where fedora.us / extra's has a chance to improve upon the single-maintainer policies, because theres a written down list of "showstoppers" which aren't allowed to pass QA. And if they do, the multiple reviews over time will eventually catch them. > > > Since all the checklist items are there, answered > > with yes or no questions, it's easy to know if they actually made a good > > faith effort to check the package. > > Which increases the workload a lot, when many items are not needed > for a particular package or when many more items are added to the list > (because it isn't complete). Reviewers should develop a feeling for > what is important and what is not. > How is a new reviewer supposed to develop that feeling? You've got to have a place to start. I'm sure there are people out there who have never seen a spec file before that would like to be able to help fedora. These people should be recommended to read maximum rpm, and then start qa'ing using the showstopper checklist. I'd say there shouldn't be more than a dozen or so show stoppers, which could easily be included in the preflight checklist. > > Some critique of the list: > > > > 1. Does the package follow the Fedora Package Naming Guidelines? > > This is pretty darn complicated for a newbie QA'er. They should be > > allowed to opt out. A "senior developer" could look at the package in 10 > > seconds and understand whether or not the name is ok. > > But package naming and versioning issues don't stop anyone from reviewing > the rest of a package, do they? > No they don't. However, as a newbie, my impression was that I was to review ALL aspects on the checklist. After doing some QA and looking at other peoples bugzilla reports I figured out that it would be ok if I just downloaded the package and made some comments about what I didn't like. However, people just making comments about what they like doesn't provide a deterministic path to REVIEWED status. > > 2. Are the sources from upstream pristine and free from trojans? > > This is important, but exceedingly difficult to do "properly"... At what > > point does this become a showstopper? At some point it becomes > > impossible to verify the source without actually being the author of the > > code and inspecting it line by line. For a newbie this is very > > intimidating > > Of course. Still, the least someone can do is compare the MD5 checksums > and also check packages from other distributions (not because they are > trusted ultimately, but to fetch the source from multiple locations) and > visit the home page (and e.g. directories like freshmeat.net) to check > whether a release might be official. > > Asking upstream authors for MD5 checksums via e-mail doesn't work > well. I've tried without luck to get some to post clearsigned checksums in > the download area. I'd have been happier about this item if I'd known this was somewhat optional, and not expected to be 100% possible. However, it needs to get done at some point. If it's on the checklist, then you know it got done. If I just make comments about broken things, and then submit an approval, how do you know I verified md5sums? > > I'd suggest something like "are all > > pathnames in the pre/post(un) install scripts complete? > > What does that mean? Macros in scripts are okay and are expanded at > build-time. Environment variables are not okay because they are evaluated > at run-time. These are tough. I don't think you can expect a newbie to really evaluate this very effectively. That being said, if they install the package and it works, the scripts can't be TOO bad. They can be improved later when somebody more knowledgeable looks at the code. Maybe this item is pedantic and should be instead included under "does it work?". > > > Are macros used for all package files? > > Depends on whether it makes sense. If the source code has some paths > hardcoded, it doesn't make much sense to use corresponding macros in the > spec file. Ditto as above. It's a tough call, but not exactly a showstopper. People will have differing opinions on it. If the package works, let it go or argue about it, but don't stall it in QA over this. > > > Also. Wheres the "does this package appear to work" line item? Do we QA > > packages and not actually run them? It seems like this is pretty basic > > criteria. > > Are step by step items on "does it build?", "does it install?", > "does it upgrade?", "does it erase?" really necessary? I think so, to a degree. This list needs to be basic, so people can get up to speed. Also, in the interests of formalism, knowing that the package builds properly, and appears to work after installing is important. Maybe the review just downloaded the srpm, made some complaints about the spec file syntax ($RPM_BUILD_ROOT vs %{buildroot} anyone) and moved on. I'm seriously concerned that packages be able to move through fedora quickly and efficiently, without compromising their quality. I'm not convinced the current process is getting that job done. > > 5. Are there no missing BuildRequires? > > > > This one took me a LONG time to check. The manual "remove all devel > > rpms" method is apparently deprecated according to the url above, > > however fedora.us doesn't even include a copy of mach. No less, mach is > > pretty complicated and you've got to figure out how to create a > > fedora.us enabled buildroot. > > "mach" is not mandatory. I've tried it once, long ago. Use what works for > you. It can be embarrassing if an approved package fails in the build > system. Ok so it's not mandatory but it seems the sanest way to check buildrequires. Is it used for the fedora.us buildsystem or not? It doesn't make much sense to me for packages to pass QA that can't be built properly on the build system. > > > 6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS. > > > > Not sure if this is relevant to anything, but again, it's easy to check. > > Couldn't rpmlint do this? > > AFAIK, rpmlint checks whether a group is known, but not whether > a package is put into the proper category. Point well made. I agree. A human will need to verify that the categorization makes sense. > > > 10. Is the package free of unowned directories? > > > > This is also very hard to check. You mean I have rpm -ivvh this package > > and then scroll through a whole pile of cruft to see the unowned > > directories? And then I have to know which ones it's "supposed" to own, > > and which ones it's now? > > You can also "rpm -qlv |less" the package and make sure that it owns > its _own_ directories. ;) > > This depends on a package's dependencies, e.g. whether the package adds > files to the directory of a package it depends on. In that case it would > not need to own the directory. These are good tips. Lets get them into the docs somewhere, along with a definition of "its own directories". This wasn't immediately obvious to me, and I would hope to be able to have people be able to contribute more easily than I did. > > 14. Does the package handle a parallel build cleanly? > > > > Does this really matter? Seems like a nice thing to check but not a > > showstopper. Make it go away. > > It is a showstopper, because a package which "make"s with %_smp_mflags in > the spec file might break badly in the build system. It is not always > obvious whether such breakage is due to SMP make flags. Defining > "%_smp_mflags -j3" in your local ~/.rpmmacros file also on UP machines > can help detect breakage. Ok. So we need everybody to put "%_smp_mflags -j3" in their ~/.rpmmacros, and then we can just ask them "does it build". Maybe what I'm getting at here is that it would be really helpful to have an easily duplicated (checked out from fedora.us!!), defined build environment... > > > 11. Does it pass rpmlint cleanly? > > Not always possible. :) > Ok true, but if it doesn't maybe that's time for a more knowledge person to approve that which doesn't pass rpmlint? > > With good solid descriptions for 1-6 especially, I think it will become > > much easier to get useful information from would-be QA'ers. I'd like to > > see the how to help page say "Please do QA. Heres how" > > And when issues not covered in the list come up, those people are fed up. > E.g. but not limited to: > > * build not accepting $RPM_OPT_FLAGS > * build stripping binaries > * bad -rpath found > * archdependent files below %_datadir > * not adhering to FHS > * spec file sections in wrong order (e.g. builds in %install section) > * libtool archives not deleted and not needed or wrong paths > in libtool archives > * *.so links in non-devel package and not needed there > * python *.py{c,o} files not marked %ghost > * perl modules installed into site location, not vendor location > * macros in %changelog I'm not sure I understand what you're saying here. Maybe I should have said "heres how to start" instead? I understand all those and many more can be possible problems, but expecting packages to be perfect before they pass QA is going to stall the process indefinitely. If those issues come up, the newbie may not be able to detect them. They'll get noticed sometime, and should get fixed then. > > > 2. Provide some feedback. I QA'd some packages. I waited. And waited. A > > week later, AFTER I saw a discussion about bugzilla keywords and added > > "NEEDSWORK" to the packages I had QA'd, > > NEEDSWORK is to move packages out of the QA queue, because they don't > build or need more work before they are moved back into the QA queue. > This can also be set by the packager if major changes are planned. > REVIEWED is the new keyword to flag reviewed packages, so they are > easy to locate. > OK. So at what point do I make the determination that the package has passed QA? The stuff I marked as needs work ended up being due to some stuff I saw on the "QA Checklist" which turns out not to really be a showstopper, or is it? With a showstopper checklist, I know that if there are no showstoppers it's safe to approve. If there are it's not. This way my likelihood of looking like an idiot is very low, if I followed the instructions properly. Not feeling like an idiot is what makes people come back and feel good about contributing. > > I got my first piece of > > feedback. This doesn't encourage repeat customers. It's a whole lot more > > rewarding when you submit something, and an hour later you get a message > > back from somebody saying "Hey, you messed up, but thanks for trying, > > can you please check a, b, and c?". > > Lack of man power. More reviewers are needed. Especially since we don't > know how/what official Fedora Extras will change. Agreed. And understood. And I'm trying to help make it easier to get new reviewers. I know several semi-serious linux users I might get QA some packages, but until the process is streamlined enough I can point them to a relatively straightforward set of tasks I'm very unlikely to get them to actually do it. > > I think it's imperative that packages make it through the QA process. It > > doesn't do any good if packages never make it into the repo. Right now, > > they appear to just sit there. Then the packager gets fed up, doesn't > > respond if anybody checks his package, and starts a new repo. > > Not every packager can work on his packages as soon as someone found > issues. Sometimes you need to wait till the next weekend. If the packager > doesn't respond, simply move the request out of the package queue by > deleting the QA keyword and setting the NEEDSWORK keyword. OK, that's fine, but in all reality I'm uninterested in removing the package from the QA queue. I want the package published! And now! At what point is it ok for me to just post my own version of the SRPM? Also, documentation of these keywords was not apparent to me in the web of pages I looked at while trying to figure this process out. > > This is > > not building community. This process has GOT to be fast enough that when > > I submit a package for something that people actually use, it gets QA'd > > SOON, before I've lost all interest in it. > > If there are people with interest in a package, surely there should be > two reviewers, too? > I'm sure they are out there, but we've got to make the process so darn straightforward they can't help but succeed once they decide to help out. I'm skeptical that it's that way now. I'm not sure if I succeeded yet, and I can assure you I attacked it unsuccessfully a few times before finally making it over the hump of actually posting a review comment. Just $0.02! --erik From rhally at mindspring.com Fri Feb 27 03:10:57 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 26 Feb 2004 22:10:57 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227025751.GF29689@devserv.devel.redhat.com> Message-ID: The thing that really got my attention was the "enforcing mode". I have SELinux installed from Rawhide and am getting a substantial number of avc denied messages when booting and shutting down not to mention others from doing ordinary things. Would it help if I sent some of these to someone to look at to at least tell me if I am doing something wrong or there is some other problem? Thanks, Richard Hally -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com] On Behalf Of Bill Nottingham Sent: Thursday, February 26, 2004 9:58 PM To: fedora-devel-list at redhat.com; fedora-test-list at redhat.com Subject: Fedora Core 2 Test 2 - delayed We're encountering various issues that are causing us to delay the release of test2. We'd like to get as much exposure to SELinux as possible, and this means shipping test2 with SELinux in enforcing mode. However, there are still some subsystems that aren't quite ready for this, so we need to slide the release date some. The *current* projection is that the freeze will be on March 12, for availability on March 22. This date is only preliminary at this point, and may change. The schedule at: http://fedora.redhat.com/participate/schedule/ will be updated shortly. Bill -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From salimma at fastmail.fm Thu Feb 26 13:00:19 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Thu, 26 Feb 2004 20:00:19 +0700 Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077799325.4746.7.camel@athlon.localdomain> References: <1077799325.4746.7.camel@athlon.localdomain> Message-ID: <1077800418.3058.1.camel@bushido.mshome.net> On Thu, 2004-02-26 at 13:42 +0100, Leonard den Ottolander wrote: > Hi, > > I am uncertain about the use of the tag NEXTRELEASE in bugzilla. How > should an issue be closed if it was reported for RHL 8.0, but does not > exist in FC 1? NEXTRELEASE or CURRENTRELEASE? > Probably CURRENTRELEASE, since FC1 is the currently available release. Not to sure what the difference between NEXTRELEASE and RAWHIDE though. HTH, - 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 redhat-forums at genesis-x.nildram.co.uk Fri Feb 27 03:15:07 2004 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Fri, 27 Feb 2004 03:15:07 +0000 Subject: OMG! I've started a war! - Was:Prelink success story :) References: <20040227022442.1cb028e8.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004 02:24:42 +0100, Michael Schwendt wrote: > On Fri, 27 Feb 2004 00:27:32 +0000, Keith G. Robertson-Turner wrote: >> As for this fist fight between Micheal and Dag, let me just say that this >> is a real storm in a teacup. > > Wonder what makes it look like a "fight"? > >> I'm sure someone who works that hard without financial reward, surely >> cannot be described as someone who doesn't care. > > You're extending the topic quite a bit now. "Doesn't care" as in "doesn't > care about fedora.us". Well maybe I did stretch the context a bit, but even in the given context, I find it hard to believe that Dag doesn't care about fedora.us. If he didn't care, then he wouldn't keep questioning Fedora policy? Anyway, those are questions for him to answer himself. >> I don't feel threatened by the existence of DAG-RPMS any more than I do >> about Livna, in fact I'm glad of having more choice. That is, after all, >> what "community" is all about. > > Imagine Dag would stop maintaining his hundreds of packages all of a > sudden (without any particular reason). I think Livna would shut down without Dams, and if you and Warren went to the Bahamas for two weeks - fedora.us would be a very quiet place indeed. Let's not get too paranoid about what *might* happen, but lets concentrate on expanding what we *do* have. >>I was a bit taken-aback by, what I perceived as, Michael's abrasive >>nature. > > *That* I hear for the first time. Note the word "perceived". >> Having worked with him for the last 3 months, I can say that, although >> his tone is a bit dry, > > Here I would like to hear more details and suggestions on what I should > change and how. You see? Like right there, I don't know whether you're being serious or not. Maybe it's just me, or maybe it's a British "thing". We're an odd bunch :) Just watch a couple hours of Monty Python, and you'll know what I mean. >> If Michael has a fault, it is that he is a perfectionist in the >> extreme > Btw, nothing in the Wiki is from me. I only edited a few places > yesterday. So, I really don't see where you've got the picture of an > extreme perfectionist from. Actually it was more in reference to your exacting nature on package QA, but then a (relative) novice packager like me is bound to say something like that. - K. From salimma at fastmail.fm Thu Feb 26 13:14:39 2004 From: salimma at fastmail.fm (Michel Alexandre Salim) Date: Thu, 26 Feb 2004 20:14:39 +0700 Subject: New PuTTY 0.54-0.3 rpms for review. In-Reply-To: <200402222031.40785.ghenry@suretecsystems.com> References: <200402202323.24851.ghenry@suretecsystems.com> <200402221749.36290.ghenry@suretecsystems.com> <200402222031.40785.ghenry@suretecsystems.com> Message-ID: <1077801279.3058.5.camel@bushido.mshome.net> On Sun, 2004-02-22 at 20:31 +0000, Gavin Henry wrote: > Oh, with respect to Michel Alexandre Salim comments, if these adjustments are > made, will this enable a desktop entry in both gnome and kde? I haven't had > chance to look at freedesktop.org, so the answer is probably there. > Yep. Notice how KDE apps appear on GNOME's menu, and vice versa on Red Hat 9 and Fedora 1? (Can't remember what life was like under RH8, but IIRC it was the same). 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 russell at coker.com.au Fri Feb 27 04:06:32 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 27 Feb 2004 15:06:32 +1100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: References: Message-ID: <200402271506.32524.russell@coker.com.au> On Fri, 27 Feb 2004 14:10, "Richard Hally" wrote: > The thing that really got my attention was the "enforcing mode". I have > SELinux installed from Rawhide and am getting a substantial number of avc > denied messages when booting and shutting down not to mention others from > doing ordinary things. Would it help if I sent some of these to someone to > look at to at least tell me if I am doing something wrong or there is some > other problem? Yes, send the AVC messages to me. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Fri Feb 27 04:23:33 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 27 Feb 2004 15:23:33 +1100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <200402271506.32524.russell@coker.com.au> References: <200402271506.32524.russell@coker.com.au> Message-ID: <200402271523.33462.russell@coker.com.au> On Fri, 27 Feb 2004 15:06, Russell Coker wrote: > On Fri, 27 Feb 2004 14:10, "Richard Hally" wrote: > > The thing that really got my attention was the "enforcing mode". I have > > SELinux installed from Rawhide and am getting a substantial number of avc > > denied messages when booting and shutting down not to mention others from > > doing ordinary things. Would it help if I sent some of these to someone > > to look at to at least tell me if I am doing something wrong or there is > > some other problem? > > Yes, send the AVC messages to me. One thing that should be noted is that when in permissive mode you will see many messages that won't appear in enforcing mode. For example in enforcing mode user_t can not search many of the /proc/pid directories (and the search operations are not audited). But in permissive mode the search can proceed and then later operations will be audited. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From lowen at pari.edu Fri Feb 27 04:36:13 2004 From: lowen at pari.edu (Lamar Owen) Date: Thu, 26 Feb 2004 23:36:13 -0500 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227023043.15f11272.ms-nospam-0306@arcor.de> References: <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> Message-ID: <200402262336.13553.lowen@pari.edu> On Thursday 26 February 2004 8:30 pm, Michael Schwendt wrote: > Is an URL which contains macros still an URL? What do you do with an URL > that contains macros? You can't cut'n'paste it into a browser, because it > contains macros. So why include protocol, hostname and path in Source > fields at all? How does the packager fetch a new release? Does he visit > the web page from bookmarks? Or does he reconstruct a valid URL from > the macros? I have always used the pseudo-URL form as a reminder of where to get the source for PostgreSQL. It's not a true URL, and mine do contain macros. And will continue to contain macros. Not that I need much of a reminder anyway, since the URL in the spec is not how I get the source, since the real path via scp is not the URL. :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From toshio at tiki-lounge.com Fri Feb 27 05:02:28 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 27 Feb 2004 00:02:28 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> Message-ID: <1077858145.4875.333.camel@Madison.badger.com> FWIW: I only discovered fedora.us in December. Note: Heavily snipped. Please alert me to anything you think I took out of context. On Thu, 2004-02-26 at 17:43, Erik LaBianca wrote: > I do > think that the barrier for entry that I found was entirely too high. I'm > just now beginning to understand what is going on after getting some > feedback on some of my reviews. I think the need to get feedback _on_a_QA_ is the heart of the problem right now. QA'ers need mentoring to develop their skills. Jef, how would you feel if some bug day we had experienced QA'ers team with new QA'ers to nitpick packages? This could be a good first or second time QA experience: irc with a more experienced QA'er and pick apart the good and bad of a package. Or we could assemble a team of experienced QA'ers to do second reviews once a new user did the first one. This could be useful for a more advanced QA'er. Kinda have a short apprenticeship followed by a test what you know phase. > > 1. Information how "how to do some useful qa" is scattered. I agree that as a new QA'er this was hard to deal with. I felt like there were five or six or seven lists of things that I had to keep in mind. Nowadays I use my judgement, followed by a quick walkthrough of the major QAChecklist (and any sublists that that pulls in) and a run-through of rpmlint on the SRPM and Binary RPM. What I would like to see (for both QA and packager) is an RPM Best Practices Handbook. Accumulated wisdom about how to do things well organized by use cases with in depth justifications available as side passages for those who are curious why %{buildroot} and ${RPM_BUILD_ROOT} have such strong proponents on each side :-) > 2. [...QA Checklist in list form...] > There should be a template like I have above, that can be answered > with simple yes or no answers, that covers all the showstoppers. That > way a newbie can fill it in the blank with yes's or no's and no he's > done something useful. I ran across my first QA that had such a list in it the other day and it was pretty awful. Part of that's the way bugzilla's structured to make you scroll down, down, down. Another part's that it doesn't organize along good/needs-fixing/minor-quibble sections. And the third's that it tends to lead to a false sense of having finished the job when the checklist is complete. I wanted to write a fedora-qatemplate script that could generate a template complete with checklist. But I still haven't figured out how the template should be structured to address all the shortcomings I listed above. (My best thought so far has been to abandon the CLI and instead have an interactive GUI script with checklist that outputs certain security related boilerplate and whatever checklist items fail.) As QA stands (with all volunteer QA'ers) we can't depend on a newbie doing first review and a seasoned vet doing the second review to figure out what the newbie left out. Besides, the seasoned vet is likely to do the same things the newbie did to make sure those things really do check out so having the newbie _just_ run through a checklist isn't that useful. What is useful is if the new QA'er has the sense of responsibility to run through the checklist and the curiosity to test whatever looks broken, fragile, or otherwise could might need improvement. > > The non-showstoppers should be on a second list of "stuff to watch for". > This could be far more detailed than the actual QA checklist, and as a > newbie gets deeper into packaging lore, they would likely begin filling > out more of it. > In my mind I divide things into showstopper and stylistic. With the possible exception of the present wording of RPM_BUILD_ROOT, I think everything on the list is a showstopper. And as Michael lists, there are many more that aren't on the list (because they don't occur often enough? Because there isn't consensus yet? Because no one wanted to turn the Checklist into a pre-flight manual with seventy pages sixty-nine of which don't apply to this particular package?) > 1. Does the package follow the Fedora Package Naming Guidelines? > This is pretty darn complicated for a newbie QA'er. They should be > allowed to opt out. My problem with opting out was stated above: what if two QA'ers review the package and both opt-out? > 2. Are the sources from upstream pristine and free from trojans? I agree with your statements of importance, difficulty, and in general with your thought that we need to outline steps to take. This is the heaviest responsibility in the Checklist and it needs extra hints to show what can be done to attain a decent level of assurance. > 3. Are the pre- and post(un)install scripts correct? > ...Again, concrete steps would be better. ... I think this one exceeds the step-by-step. Way too many things could happen in the scriptlets to say definitively when it's done (more entries for a best practices book, OTOH...) > 5. Are there no missing BuildRequires? > I agree that this can be basically impossible as it now stands. I first tried fedora-rmdevelrpms but that made my machine close to unusable as a development environment (to QA or program.. Hmmmm...) I've been trying to get mach to work, but I seem to run from problem to problem with the damn thing. There should definitely be a fedora-mach HOWTO/FAQ/IRC forum.... So I'm reduced to reading the configure.in and watching the build output which leads to embarrasment when I miss something or mention an implicitly included dependency. Another solution is to move half of the BuildRequires to the autobuilder. (Humans still have to check for "optional" BuildRequires. But the autobuilder can check for required Requires.) > "Does the package build under mach". And the "how to build using mach" > instructions can be > > yum install mach [Remember to `mach clean` before subsequent runs] > mach build mypackage.src.rpm > > 1. Relax on the whole GPG thing. .... > When they [a new QA'er] first start, their input is going > to be suspect anyway, so why slow down the process > I might be a little attached to public key cryptography, but I think it's an important added protection. Bugzilla accounts can be traced to creation dates and email addresses. GPG keys add third party signatures. If crackers ever start trying to package compromised files and get them into Extras, we will have more information to scan on to try to figure out if we need to do more background checking on the packager/QA'ers of a package. OTOH, that might be completely emotional and the additional security might not be that great. > 2. Provide some feedback. I QA'd some packages. I waited. I agree that reviews of work done encourage learning. Perhaps the use of keywords needs to go on the QA Checklist page? Should people get used to changing keywords often? (Positive=REVIEWED; negative=NEEDSWORK; 2nd positive in a row=PUBLISH); And perhaps some of my ideas way back at the beginning of this message? (Mentoring new users...) [snippage] > I think it's imperative that packages make it through the QA process. It > doesn't do any good if packages never make it into the repo. Speaking as someone who responds when someone points out a packaging error but has never had a package make it through the queue: Sometimes you've got to accept it. I only package things I need. If it doesn't make it out the door, then not enough other people found it equally useful. *shrug* That said, the most frustrating packages are not the ones that sit there unreviewed, but the ones that sit there half reviewed (or with an older version reviewed but not a newer one.) It implies interest, but not enough among active QA'ers to make the push over the hump. Speaking as a fedora user/developer -- I don't care so much that packages wait in the QA queue. If I see something I want there, I download and review it and if it works well I start driving :-) I'm sure "normal" users that don't want to do QA would see this differently.... -Toshio -- Toshio From lowen at pari.edu Fri Feb 27 05:20:14 2004 From: lowen at pari.edu (Lamar Owen) Date: Fri, 27 Feb 2004 00:20:14 -0500 Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> Message-ID: <200402270020.14634.lowen@pari.edu> On Thursday 26 February 2004 5:19 pm, Michael Schwendt wrote: > Again, $RPM_BUILD_ROOT is preferred at fedora.us as long as it is > described as the "official supported" mechanism on getting access to > buildroot. FWIW %{buildroot} and $RPM_BUILD_ROOT are not the same due to the way macros are processed. IIRC, the build/install scriptlets can modify $RPM_BUILD_ROOT internally, but, again IIRC %{buildroot} gets the expanded buildroot not as an environment variable. In fact, a %dump reveals a couple of sets of definitions (for different uses: $RPM_BUILD_ROOT could vary between scriptlets depending upon you rpmmacros): You find in __build_pre: %{?buildroot:RPM_BUILD_ROOT="%{u2p:%{buildroot}}" export RPM_BUILD_ROOT} But in _preScriptEnvironment it's: %{?buildroot:RPM_BUILD_ROOT="%{buildroot}" export RPM_BUILD_ROOT } meaning that $RPM_BUILD_ROOT is derived from %buildroot. So the scriptlets cannot mung with the buildroot if you use %{buildroot}, but you can if you use $RPM_BUILD_ROOT (which means you can fix a bad buildroot using the envvar). Macro definitions/redefinitions are not part of the scriptlet, of course (just like C preprocessor directives are not part of the actual C code). Now, you CAN mung with %{buildroot} elsewhere, but that's beyond this. You just can't do it programmatically during build script execution. Some would say that's a good thing; others would vehemently disagree. However, if you need to use the value of buildroot in a macro definition you probably should use %buildroot, a'la %makeinstall (whose definition uses nearly as many %{buildroot}'s as it does {} pairs). Of course, there are exceptions to this; as long as you realize that the macro definition is substituted into the script as a string you can use envvars inside the macro definition, but the interpretation is up to the host scriptlet. %mdkicons for instance uses $RPM_BUILD_ROOT inside the macro. But a definition using %{buildroot} results in the static string that is the buildroot, and using the envvar results in the envvar, which might not be what it needs to be.... Of course, I do reserve the right to be wrong, but I think I verified this insome test specs I built up a long time ago. The point is that the $RPM_BUILD_ROOT recommendation isn't even consistently followed in the rpmmacros definitions themselves, meaning that every spec file is using a willy-nilly mix of %{buildroot} and $RPM_BUILD_ROOT even if those strings do not appear in your spec file itself. Thus the recommendation and checklist item is totally redundant and really deserves to be removed, Jeff's comments notwithstanding. If and when Jeff actually changes ${buildroot} basic core rpm build macros will break, and break badly, so the likelihood of that change happening is somewhere between slim and none, and Slim just left town. Of course, Jeff has surprised us before... :-) Each have their uses, and the spec file maintainer may intend %{buildroot} where it is specified; and $RPM_BUILD_ROOT might be better for another. But it is obvious that %{buildroot} is a little (marginally) easier to type and read. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From toshio at tiki-lounge.com Fri Feb 27 05:26:04 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 27 Feb 2004 00:26:04 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <1077858145.4875.333.camel@Madison.badger.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> Message-ID: <1077859563.4875.352.camel@Madison.badger.com> Hmm.... Not to say I haven't written enough for one day but my last message has got me thinking it's harder to QA than to package. (Not package perfectly... just package.) So maybe the assumption that QA is something easy for relative beginners to contribute to Fedora is All Wrong(TM). We should work on getting fedora-newrpmtemplate to a new state of enlightenment, then throw it at unsuspecting new packagers. When tons of pregenerated-spec packages start showing up in the QA Queue, we'll be able to write pseudo-code critiques for our favorite programs and have someone else do the actual work bwaa haa haa! Seriously, maybe it would make more sense for more seasoned people to concentrate on QA and leave good tools and new packagers to create the initial packages. There's a lot of boilerplate involved in creating a package but it takes a lot of "I've done this before and somehow the way it's done here makes my Spider Sense scream..." involved in checking those packages for quality. -Toshio -- Toshio From jrb at redhat.com Fri Feb 27 06:01:18 2004 From: jrb at redhat.com (Jonathan Blandford) Date: 27 Feb 2004 01:01:18 -0500 Subject: MrProject is now Planner In-Reply-To: <403CB0B8.8070107@redhat.com> References: <403CB0B8.8070107@redhat.com> Message-ID: Chuck Mead writes: > ...and there has been an updated release! (.11) > > Any chance we can see the updated release in FC2? It fixes a number of > outstanding bugs. Yeah. I have high hopes of building it today. Thanks, -Jonathan From pmatilai at welho.com Fri Feb 27 06:10:53 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 27 Feb 2004 08:10:53 +0200 Subject: OMG! I've started a war! - Was:Prelink success story :) In-Reply-To: References: <20040227022442.1cb028e8.ms-nospam-0306@arcor.de> Message-ID: <1077862252.12909.27.camel@chip.laiskiainen.org> On Fri, 2004-02-27 at 05:15, Keith G. Robertson-Turner wrote: > On Fri, 27 Feb 2004 02:24:42 +0100, Michael Schwendt wrote: > > > On Fri, 27 Feb 2004 00:27:32 +0000, Keith G. Robertson-Turner wrote: > > >> As for this fist fight between Micheal and Dag, let me just say that this > >> is a real storm in a teacup. > > > > Wonder what makes it look like a "fight"? > > > >> I'm sure someone who works that hard without financial reward, surely > >> cannot be described as someone who doesn't care. > > > > You're extending the topic quite a bit now. "Doesn't care" as in "doesn't > > care about fedora.us". > > Well maybe I did stretch the context a bit, but even in the given context, > I find it hard to believe that Dag doesn't care about fedora.us. If he > didn't care, then he wouldn't keep questioning Fedora policy? Anyway, > those are questions for him to answer himself. I can't speak for Dag or anybody else but I'm reading between the lines that he (and others) are interested in Fedora Extras which fedora.us is supposed to become/be merged with, and wants to discuss these things so that the official Fedora Extras can get rid of some of the issues that have kept him and other individual repository maintainers away from contributing to fedora.us. So please lets not get into the painful and tiresome fedora.us vs individual-repositories flamewars again but at least *try* to have a decent discussion what Fedora Extras rules should be, since the current fedora.us policies are more than obviously driving various people away from it. Having the kind of people who can maintain dozens or hundreds of packages themselves (like the individual repository maintainers now do) on board instead of everybody ignoring and denying each others existence would be an asset, not a bad thing. And no, I don't expect Dag, Matthias, Axel & co to push all of their packages into Fedora Extras no matter how things are arranged but anything reducing the ridiculous re-re-re-repackaging of the same stuff over and over again in 10 different repositories can be only a good thing, the current situation is just wasting a lot of time and effort of relatively scarce resources. Oh and before somebody points me to some of my own old comments about existence of individual repositories: yes they will continue to exist and there's nothing wrong with that, there's always market for specialized bleeding-edge/whatever repositories. The thing we should get rid of is the repackaging of same basic stuff (as in "everybody uses") over and over again. > > >> I don't feel threatened by the existence of DAG-RPMS any more than I do > >> about Livna, in fact I'm glad of having more choice. That is, after all, > >> what "community" is all about. > > > > Imagine Dag would stop maintaining his hundreds of packages all of a > > sudden (without any particular reason). > > I think Livna would shut down without Dams, and if you and Warren went to > the Bahamas for two weeks - fedora.us would be a very quiet place indeed. > Let's not get too paranoid about what *might* happen, but lets concentrate > on expanding what we *do* have. Dunno about Livna but at least fedora.us does have other "build masters" (whatever the exact term was escapes my mind right now) so things can get published in absence of Michael, Dams and Michael. OTOH absence of Michael would probably mean any QA work grinding to near halt - kudos to him for the enormous effort he puts there. Peace, love and lot of packages for all, eh? :) - Panu - From jkeating at j2solutions.net Fri Feb 27 06:09:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 26 Feb 2004 22:09:36 -0800 Subject: Prelink success story :) In-Reply-To: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> Message-ID: <200402262209.36378.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 February 2004 14:19, Michael Schwendt wrote: > Does such a thing exist? Isn't in work-in-progress still? Not only is it in progress, but it will live on our own wiki system, rather than Fedora.us'. I'm trying to limit the confusion of Fedora Legacy vs Fedora.us. Speaking of, anybody know how to DELETE a page in a wiki system? - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) 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.3 (GNU/Linux) iD8DBQFAPt8g4v2HLvE71NURApPRAJ4n0uQe9eWsxsyGWgcriPkz08a67wCfdN/o Pv6edpvhbPkWa801/F78d/s= =9z0/ -----END PGP SIGNATURE----- From mharris at redhat.com Fri Feb 27 06:59:57 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 01:59:57 -0500 (EST) Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227012002.3283ea75.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: >> Coupled with Ville's comment that package QA people really >> should be checking out web pages and so forth to make sure they have >> a canonical source rather than cut 'n paste, macros in Source: make more >> and more sense to me. (Although I'll definitely miss cut and paste when >> I'm QA'ing an update package and I already checked out the canonicalness >> in the previous version.) > >Macros in URLs simply don't work. If you want macros in Source tags, >cut off everything up to the file name like > > Source0: %name-%version.tar.gz Macros work fine for me in Source tags, with URLs and without. See the xchat spec file for an example. pts/34 mharris at porkchop:~/rpmbuild/rpms/xchat$ grep Source xchat.spec Source: http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Fri Feb 27 07:04:27 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 02:04:27 -0500 (EST) Subject: CURRENTRELEASE versus NEXTRELEASE In-Reply-To: <1077800418.3058.1.camel@bushido.mshome.net> References: <1077799325.4746.7.camel@athlon.localdomain> <1077800418.3058.1.camel@bushido.mshome.net> Message-ID: On Thu, 26 Feb 2004, Michel Alexandre Salim wrote: >Date: Thu, 26 Feb 2004 20:00:19 +0700 >From: Michel Alexandre Salim >To: fedora-devel-list at redhat.com >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="=-LCnFPAx/ojDWfsy/yRsl" >List-Id: Development discussions related to Fedora Core > >Subject: Re: CURRENTRELEASE versus NEXTRELEASE > >On Thu, 2004-02-26 at 13:42 +0100, Leonard den Ottolander wrote: > >> Hi, >> >> I am uncertain about the use of the tag NEXTRELEASE in bugzilla. How >> should an issue be closed if it was reported for RHL 8.0, but does not >> exist in FC 1? NEXTRELEASE or CURRENTRELEASE? >> >Probably CURRENTRELEASE, since FC1 is the currently available release. >Not to sure what the difference between NEXTRELEASE and RAWHIDE though. RAWHIDE used to be for Red Hat Linux releases, then for Fedora Core releases. We did not have a way of indicating for Red Hat Enterprise Linux the same thing though. NEXTRELEASE is a generic version of "RAWHIDE" which is in context to the OS product it pertains to. So for Red Hat Enterprise Linux bugs closed as "NEXTRELEASE", they will be fixed in the next version of Red Hat Enterprise Linux. For Fedora Core 1 bugs closed NEXTRELEASE, they will be fixed in the next version of Fedora Core, which is essentially the same as the RAWHIDE resolution. That's my understanding of it anyway. Someone else at Red Hat will correct me if I'm wrong and they know better. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From markmc at redhat.com Fri Feb 27 07:10:37 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 27 Feb 2004 07:10:37 +0000 Subject: GNOME main menu sorting In-Reply-To: <1077821439.5698.9.camel@adriano.freesoftware> References: <1077821439.5698.9.camel@adriano.freesoftware> Message-ID: <1077865836.19850.31.camel@laptop> Hi, Its not a good idea to cross-post to so many high traffic lists. And this isn't a development question. You're not going to like the answers I'm afraid. On Thu, 2004-02-26 at 18:50, Adriano Del Vigna de Almeida wrote: > Hello there, > > I'm hacking at the GNOME main menu and have three questions: > > 1.) Is it possible to sort the GNOME main menu other than > alphabetically? No. > 2.) How to add separators to the main menu? You can't > 3.) Where is stored the data about "run app", "search files", "open > recent", "lock screen", and "exit" GNOME main menu itens? I ask to the > case I need to modifiy them. Its hard coded. Good Luck, Mark. From markmc at redhat.com Fri Feb 27 07:12:03 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 27 Feb 2004 07:12:03 +0000 Subject: Is menu editing in GNOME enabled in Fedora Core 2? In-Reply-To: <403E7D65.30207@haitsma.org> References: <403E7D65.30207@haitsma.org> Message-ID: <1077865922.19850.33.camel@laptop> Hi, On Thu, 2004-02-26 at 23:12, Jaap A. Haitsma wrote: > Hi, > > Menu editing for GNOME has always been disabled in Fedora Core 1 and > Redhat 9 because of buggy gnome code. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81215 > > I always found this an annoying bug. I was wondering if this got fixed > with the new GNOME packages? No, sorry. Its a lovely tangled mess that's going to take some time to sort out :/ Cheers, Mark. From mharris at redhat.com Fri Feb 27 07:14:33 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 02:14:33 -0500 (EST) Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: <200402270020.14634.lowen@pari.edu> References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> <200402270020.14634.lowen@pari.edu> Message-ID: On Fri, 27 Feb 2004, Lamar Owen wrote: >The point is that the $RPM_BUILD_ROOT recommendation isn't even consistently >followed in the rpmmacros definitions themselves, meaning that every spec >file is using a willy-nilly mix of %{buildroot} and $RPM_BUILD_ROOT even if >those strings do not appear in your spec file itself. Thus the >recommendation and checklist item is totally redundant and really deserves to >be removed, Jeff's comments notwithstanding. If and when Jeff actually >changes ${buildroot} basic core rpm build macros will break, and break badly, >so the likelihood of that change happening is somewhere between slim and >none, and Slim just left town. Of course, Jeff has surprised us >before... :-) > >Each have their uses, and the spec file maintainer may intend %{buildroot} >where it is specified; and $RPM_BUILD_ROOT might be better for another. But >it is obvious that %{buildroot} is a little (marginally) easier to type and >read. I'm kindof rather amused by people arguing over "Which should be used $RPM_BUILD_ROOT or %{buildroot}?" so violently. It's very emacs versus vi'ish indeed. ;o) For the record, I use RPM_BUILD_ROOT exclusively myself, but only because that's what I started using way back when, and it just stuck. Considering the fact that there are a massive number of RPM packages in existance both inside the distribution and outside of it which use either one of the two, removal of either one of them would essentially break anywhere from 40-60% of all src.rpms in existance at a guess. The likelyhood of that major of a change happening to rpm *ever*, is very unrealistic IMHO, and so it really makes no difference which people use, so arguing vehemently about which one is more "correct" is a sheer and utter waste of time. ;o) That said, if there ever was an officially declared standard that was adopted by Red Hat, Mandrake, SuSE, all major 3rd party repositories, I would switch all my spec files in a heartbeat to comply, but the likelyhood of that ever actually happening is very small IMHO. Why not argue instead about why RPM's %if/%ifarch macros are not nestable? Or why there is no %elseif? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From markmc at redhat.com Fri Feb 27 07:14:22 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 27 Feb 2004 07:14:22 +0000 Subject: Yum problems In-Reply-To: <1077840391.3240.10.camel@old1> References: <1077840391.3240.10.camel@old1> Message-ID: <1077866061.19850.36.camel@laptop> Hi, 1) This is a development mailing list 2) Please don't post huge big long logs like that. On Fri, 2004-02-27 at 00:06, Richard Hally wrote: > .Package gnome-applets needs libgtop-2.0.so.1, this is not available. > Package gnome-system-monitor needs libgtop-2.0.so.1, this is not > available. This will be fixed by the next update to rawhide. The new libgtop package got pushed just before the gnome-applets and gnome-system-monitor ones. Good Luck, Mark. From markmc at redhat.com Fri Feb 27 07:25:56 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 27 Feb 2004 07:25:56 +0000 Subject: latest update In-Reply-To: References: Message-ID: <1077866756.19850.39.camel@laptop> Hi, On Thu, 2004-02-26 at 23:34, Richard Hally wrote: > I understand it is "development" ! (eats babies) 8-). > This just happened, ~ 5 PM eastern. I've been having very inconsistent > results using yum. For example, it tells me "no packages available for > update" when I know there are packages to update. > If I try it with just download.fedora.Redhat.com the failover method > sometimes fails, when I try it with several mirrors in addition to > download.fedora.Redhat.com sometimes it works and some times it doesn't. > > My question is: is this normal? If not am I doing some thing wrong and what > additional information will be useful in finding out what? Should I cut and > paste terminal output with date and time and yum.conf? It appears to be normal, but what I'm quite surprised about is that there appears to be no --just-do-the-best-you-can flag for yum? Thanks, Mark. From skvidal at phy.duke.edu Fri Feb 27 07:36:32 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 27 Feb 2004 02:36:32 -0500 Subject: latest update In-Reply-To: <1077866756.19850.39.camel@laptop> References: <1077866756.19850.39.camel@laptop> Message-ID: <1077867392.15891.4.camel@binkley> > > My question is: is this normal? If not am I doing some thing wrong and what > > additional information will be useful in finding out what? Should I cut and > > paste terminal output with date and time and yum.conf? > > It appears to be normal, but what I'm quite surprised about is that > there appears to be no --just-do-the-best-you-can flag for yum? B/c that works not so much at all when you're trying to resolve dependencies. -sv From russell at coker.com.au Fri Feb 27 07:36:59 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 27 Feb 2004 18:36:59 +1100 Subject: SE Linux Message-ID: <200402271836.59550.russell@coker.com.au> For discussions of SE Linux it would probably be best to go to #selinux on irc.freenode.net. In that channel you can expect to find at least one Red Hat employee who is working on SE Linux there at any time 24*7. Also on #selinux there are people from other Linux distributions who have a lot of experience with SE Linux, so if your question about SE Linux is not distribution specific then there are many other people who can help. Occasionally someone from the NSA joins the channel too. If you have a long question (such as "please tell me what went wrong to cause 100K of AVC messages") then email is best. But for mose SE Linux queries the IRC channel will give you the best result. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jspaleta at princeton.edu Fri Feb 27 07:37:20 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 27 Feb 2004 02:37:20 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) Message-ID: <1077867440.25962.33.camel@goober.localdomain> Toshio wrote: > Jef, how would you feel if some bug day we had experienced QA'ers team > with new QA'ers to nitpick packages? This could be a good first or > second time QA experience: irc with a more experienced QA'er and pick > apart the good and bad of a package. Or we could assemble a team of > experienced QA'ers to do second reviews once a new user did the first > one. This could be useful for a more advanced QA'er. Kinda have a > short apprenticeship followed by a test what you know phase. I strongly believe that a mentoring concept, can help the larger Fedora effort turn users into contributors, better than that, creating contributors and building a body of shared best practices through a process of continuous self-examination of the process. Who learns more about the subject when a lesson is taught...the teacher or the student? Often times it can be the teacher. At least that's what I think. But I am wary of doing exactly the sort of thing you have suggested.. prematurely. I really want to make sure there is a large enough group of DEDICATED apprentice QA'ers to make sure the veterans do not feel like making time to hold exactly that sort of irc session is a waste of their time. I want to make sure the first one i weasel people into participating in is worthwhile enough to build momentum and continued interest in holding such events. And frankly...i was waiting for someone else to suggest it.... because I don't think I have time to be the only community volunteer thinking about and heading up exactly these sorts of experiments in bridge building (and i would argue Red Hat as a managing entity needs to hire someone, actually trained in exactly this sort of volunteer management/coordination for these sorts of ideas to not fall through the cracks and get lost). Let me state an essential truth, a lot of how things are going to work in the new "fedora community" is about people taking the initiative to state an idea AND follow through with it. Basically...if you suggest an idea...you sort of own it..unless you are clever and sneaky enough to convince someone else to take ownership of the idea. I think your post proves I am clever and sneaky enough..... > What I would like to see (for both QA and packager) is an RPM Best > Practices Handbook. Accumulated wisdom about how to do things well > organized by use cases with in depth justifications available as side > passages for those who are curious why %{buildroot} and > ${RPM_BUILD_ROOT} have such strong proponents on each side :-) As interesting as this sounds as a historical non-fiction thriller novel that I'd buy at the bookstore...i don't know how useful this would be to a new QA'er. It would have some worth for the historical record....but not much use as a functional educational document that re-enforces a working process. Let me instead suggest that what might be instructive are SHORT... "anatomies of a QA review" case examples. A few good and a few bad reviews that can highlight common issues...and that can suggest a general flow of how things are suppose to work. A good example of this sort of thing..is the Gnome Bugsquads triage examples. http://developer.gnome.org/projects/bugsquad/triage/examples.html I'd point to fedora triage examples...but we haven't gotten that far yet. In fact, i could probably argue that building a set of case examples would be VERY instructive to a small group apprentice QA'ers almost as instructive as an active irc session with old-timers. And I would argue that working on such a set of case examples would show a level of dedication that might encourage established QA'ers to spend time communicating more closely...which is what you sort of wanted in the first place. -jef"things would just go smoother if everyone would just agree now to do my bidding without question or comment"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 rhally at mindspring.com Fri Feb 27 07:49:29 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 27 Feb 2004 02:49:29 -0500 Subject: Yum problems In-Reply-To: <1077866061.19850.36.camel@laptop> Message-ID: -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com] On Behalf Of Mark McLoughlin Sent: Friday, February 27, 2004 2:14 AM To: fedora-devel-list at redhat.com Subject: Re: Yum problems Hi, 1) This is a development mailing list Sorry, I get both the devel list and the testing list. I guess that pointing out that the packages in rawhide are in an inconsistent state needs to be reported on the testing list? 2) Please don't post huge big long logs like that. OK On Fri, 2004-02-27 at 00:06, Richard Hally wrote: > .Package gnome-applets needs libgtop-2.0.so.1, this is not available. > Package gnome-system-monitor needs libgtop-2.0.so.1, this is not > available. This will be fixed by the next update to rawhide. The new libgtop package got pushed just before the gnome-applets and gnome-system-monitor ones. Thanks for the help. Richard Hally From rhally at mindspring.com Fri Feb 27 08:00:35 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 27 Feb 2004 03:00:35 -0500 Subject: latest update In-Reply-To: <1077866756.19850.39.camel@laptop> Message-ID: -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com] On Behalf Of Mark McLoughlin Sent: Friday, February 27, 2004 2:26 AM To: fedora-devel-list at redhat.com Subject: RE: latest update Hi, On Thu, 2004-02-26 at 23:34, Richard Hally wrote: > I understand it is "development" ! (eats babies) 8-). > This just happened, ~ 5 PM eastern. I've been having very inconsistent > results using yum. For example, it tells me "no packages available for > update" when I know there are packages to update. > If I try it with just download.fedora.Redhat.com the failover method > sometimes fails, when I try it with several mirrors in addition to > download.fedora.Redhat.com sometimes it works and some times it doesn't. > > My question is: is this normal? If not am I doing some thing wrong and what > additional information will be useful in finding out what? Should I cut and > paste terminal output with date and time and yum.conf? It appears to be normal, but what I'm quite surprised about is that there appears to be no --just-do-the-best-you-can flag for yum? Yikes! It is surprising that yum operates so inconsistently. If you do the same thing twice one right after the other you can get different results. The thing that bothers me is the "false negative" saying that there is nothing to update when in fact there is. But that kind of stuff is for the "yum list" isn't it. Richard Hally From skvidal at phy.duke.edu Fri Feb 27 08:04:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 27 Feb 2004 03:04:48 -0500 Subject: latest update In-Reply-To: References: Message-ID: <1077869087.15891.6.camel@binkley> > Yikes! It is surprising that yum operates so inconsistently. If you do the > same thing twice one right after the other you can get different results. > The thing that bothers me is the "false negative" saying that there is > nothing to update when in fact there is. But that kind of stuff is for the > "yum list" isn't it. You should note that the mirror(s) you're connecting to are probably actively changing state under you. So please, instead of saying yum is operating so inconsistently you might want to be aware of the inconsistent state of the repositories. -sv From markmc at redhat.com Fri Feb 27 08:27:02 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 27 Feb 2004 08:27:02 +0000 Subject: latest update In-Reply-To: <1077867392.15891.4.camel@binkley> References: <1077866756.19850.39.camel@laptop> <1077867392.15891.4.camel@binkley> Message-ID: <1077870421.19850.44.camel@laptop> Hi Seth, Note - I'm not blaming yum for these problems. Its not yum's fault we have inconsitent versions of packages in the tree. On Fri, 2004-02-27 at 07:36, seth vidal wrote: > > > My question is: is this normal? If not am I doing some thing wrong and what > > > additional information will be useful in finding out what? Should I cut and > > > paste terminal output with date and time and yum.conf? > > > > It appears to be normal, but what I'm quite surprised about is that > > there appears to be no --just-do-the-best-you-can flag for yum? > > B/c that works not so much at all when you're trying to resolve > dependencies. I'm just curious, though. If the standard practice to work around such problems is for people to do --exclude=broken-package, why couldn't we not have a --exclude-broken-packages flag? Thanks, Mark. From fedora at warmcat.com Fri Feb 27 09:16:23 2004 From: fedora at warmcat.com (Andy Green) Date: Fri, 27 Feb 2004 09:16:23 +0000 Subject: OMG! I've started a war! - Was:Prelink success story :) In-Reply-To: <1077862252.12909.27.camel@chip.laiskiainen.org> References: <1077862252.12909.27.camel@chip.laiskiainen.org> Message-ID: <200402270916.23924.fedora@warmcat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 27 February 2004 06:10, Panu Matilainen wrote: > I can't speak for Dag or anybody else but I'm reading between the lines > that he (and others) are interested in Fedora Extras which fedora.us is > supposed to become/be merged with, and wants to discuss these things so > that the official Fedora Extras can get rid of some of the issues that > have kept him and other individual repository maintainers away from > contributing to fedora.us. Why not make "Fedora Extras" a metarepository which is capable to redirect seamlessly across official and any third-party repo. Then if for example a package becomes unmaintained at the original place, it can taken up at a new place with a new packager without the user noticing the change. (BTW all you packagers are heroes, the amount of niggling trouble you remove from the world is huge). - -Andy - -- Find your answer without waiting for replies.... Searchable list archives at http://marc.theaimsgroup.com/?l=fedora-list&r=1&w=2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAPwrnjKeDCxMJCTIRAgIvAJ9qLoRp5DshCxKp9/t4O7JJdkWArACfY2z7 4w8HKqKNnlr+l06Q6QbwCXg= =yNeV -----END PGP SIGNATURE----- From jaap at haitsma.org Fri Feb 27 10:16:20 2004 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Fri, 27 Feb 2004 11:16:20 +0100 (CET) Subject: Is menu editing in GNOME enabled in Fedora Core 2? In-Reply-To: <1077865922.19850.33.camel@laptop> References: <403E7D65.30207@haitsma.org> <1077865922.19850.33.camel@laptop> Message-ID: <19772.194.171.252.100.1077876980.squirrel@mail.haitsma.org> > Hi, > > On Thu, 2004-02-26 at 23:12, Jaap A. Haitsma wrote: >> Hi, >> >> Menu editing for GNOME has always been disabled in Fedora Core 1 and >> Redhat 9 because of buggy gnome code. >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81215 >> >> I always found this an annoying bug. I was wondering if this got fixed >> with the new GNOME packages? > > No, sorry. Its a lovely tangled mess that's going to take some time to > sort out :/ > :-( Strange that this still isn't solved. I would think that all the companies pushing the GNOME desktop as an alternative to Windows would be very eager to solve this bug. Or is the problem just Fedora specific because Fedora uses both KDE and Gnome to read the same menus Jaap From bart.martens at chello.be Fri Feb 27 10:22:33 2004 From: bart.martens at chello.be (Bart Martens) Date: Fri, 27 Feb 2004 11:22:33 +0100 Subject: Is menu editing in GNOME enabled in Fedora Core 2? In-Reply-To: <19772.194.171.252.100.1077876980.squirrel@mail.haitsma.org> References: <403E7D65.30207@haitsma.org> <1077865922.19850.33.camel@laptop> <19772.194.171.252.100.1077876980.squirrel@mail.haitsma.org> Message-ID: <1077877353.5573.1.camel@localhost.localdomain> On Fri, 2004-02-27 at 11:16, Jaap A. Haitsma wrote: > > On Thu, 2004-02-26 at 23:12, Jaap A. Haitsma wrote: > >> Menu editing for GNOME has always been disabled in Fedora Core 1 and > >> Redhat 9 because of buggy gnome code. > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81215 > Strange that this still isn't solved. I would think that all the companies > pushing the GNOME desktop as an alternative to Windows would be very eager > to solve this bug. Maybe these companies don't want their personnel customizing their desktops. There's a quite restrictive policy on that where I work. -------------- 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 Fri Feb 27 10:25:38 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 11:25:38 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> Message-ID: <20040227112538.087e956e.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 01:59:57 -0500 (EST), Mike A. Harris wrote: > On Fri, 27 Feb 2004, Michael Schwendt wrote: > > >> Coupled with Ville's comment that package QA people really > >> should be checking out web pages and so forth to make sure they have > >> a canonical source rather than cut 'n paste, macros in Source: make more > >> and more sense to me. (Although I'll definitely miss cut and paste when > >> I'm QA'ing an update package and I already checked out the canonicalness > >> in the previous version.) > > > >Macros in URLs simply don't work. If you want macros in Source tags, > >cut off everything up to the file name like > > > > Source0: %name-%version.tar.gz > > Macros work fine for me in Source tags, with URLs and without. > See the xchat spec file for an example. > > pts/34 mharris at porkchop:~/rpmbuild/rpms/xchat$ grep Source xchat.spec > Source: http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 You haven't payed attention to the detail: $ wget http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 ERROR 404: Not Found. And upon building source and binary rpm, the http://www.xchat.org/files/source/2.0/ is stripped off, and only the expanded xchat-%version.tar.bz2 is included in the RPM header. So, what works "fine" for you? That you can obfuscate URLs with macros? Or do you cut'n'paste part of the URL to visit the download directory in a browser? -- From ms-nospam-0306 at arcor.de Fri Feb 27 10:27:14 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 11:27:14 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <1077849223.4875.193.camel@Madison.badger.com> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <1077849223.4875.193.camel@Madison.badger.com> Message-ID: <20040227112714.694ffffa.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 21:33:49 -0500, Toshio wrote: > On Thu, 2004-02-26 at 20:30, Michael Schwendt wrote: > > Is an URL which contains macros still an URL? What do you do with an URL > > that contains macros? You can't cut'n'paste it into a browser, because it > > contains macros. So why include protocol, hostname and path in Source > > fields at all? How does the packager fetch a new release? Does he visit > > the web page from bookmarks? Or does he reconstruct a valid URL from > > the macros? > > > Thanks, Michael, that's a great explanation. > > I've got a new scenario to ask about: do any of the autobuilders the > Fedora Project is going to use depend on being able to parse the Source: > line into a URL? I doubt that. -- From ms-nospam-0306 at arcor.de Fri Feb 27 10:33:21 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 11:33:21 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <200402262336.13553.lowen@pari.edu> References: <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <200402262336.13553.lowen@pari.edu> Message-ID: <20040227113321.3e86433c.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 23:36:13 -0500, Lamar Owen wrote: > On Thursday 26 February 2004 8:30 pm, Michael Schwendt wrote: > > Is an URL which contains macros still an URL? What do you do with an URL > > that contains macros? You can't cut'n'paste it into a browser, because it > > contains macros. So why include protocol, hostname and path in Source > > fields at all? How does the packager fetch a new release? Does he visit > > the web page from bookmarks? Or does he reconstruct a valid URL from > > the macros? > > I have always used the pseudo-URL form as a reminder of where to get the > source for PostgreSQL. It's not a true URL, and mine do contain macros. And > will continue to contain macros. Not that I need much of a reminder anyway, > since the URL in the spec is not how I get the source, since the real path > via scp is not the URL. :-) This is not about voting how to do it. All that has been pointed out is that reviewers appreciate ready-to-use URLs, which they can cut'n'paste into console or browser to fetch a tarball from upstream. It has been pointed out that some packagers tend to obfuscate URLs with macros to a degree that is far from smart, e.g. Source0: http://foo.bar/%{name}/%{version}/%{name}-%{version}rc1.tar.gz and that is bad taste and bad style. Or it turns out, the URL hasn't been updated or verified in a longer time and is not true anymore. -- From pmatilai at welho.com Fri Feb 27 10:37:17 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 27 Feb 2004 12:37:17 +0200 (EET) Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227112714.694ffffa.ms-nospam-0306@arcor.de> References: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <1077849223.4875.193.camel@Madison.badger.com> <20040227112714.694ffffa.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: > On Thu, 26 Feb 2004 21:33:49 -0500, Toshio wrote: > > > On Thu, 2004-02-26 at 20:30, Michael Schwendt wrote: > > > Is an URL which contains macros still an URL? What do you do with an URL > > > that contains macros? You can't cut'n'paste it into a browser, because it > > > contains macros. So why include protocol, hostname and path in Source > > > fields at all? How does the packager fetch a new release? Does he visit > > > the web page from bookmarks? Or does he reconstruct a valid URL from > > > the macros? > > > > > Thanks, Michael, that's a great explanation. > > > > I've got a new scenario to ask about: do any of the autobuilders the > > Fedora Project is going to use depend on being able to parse the Source: > > line into a URL? > > I doubt that. IIRC mach can parse Source and Patch entries (even in presence of macros), fetch what's needed and build based on that. Actually if those entries aren't URL's it's going to fail, unless you use rebuild (to rebuild from existing src.rpm) - Panu - From ms-nospam-0306 at arcor.de Fri Feb 27 10:38:50 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 11:38:50 +0100 Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: <200402270020.14634.lowen@pari.edu> References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> <200402270020.14634.lowen@pari.edu> Message-ID: <20040227113850.5c356402.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 00:20:14 -0500, Lamar Owen wrote: > The point is that the $RPM_BUILD_ROOT recommendation isn't even consistently > followed in the rpmmacros definitions themselves, meaning that every spec > file is using a willy-nilly mix of %{buildroot} and $RPM_BUILD_ROOT even if > those strings do not appear in your spec file itself. Thus the > recommendation and checklist item is totally redundant and really deserves to > be removed, Jeff's comments notwithstanding. If and when Jeff actually > changes ${buildroot} basic core rpm build macros will break, and break badly, > so the likelihood of that change happening is somewhere between slim and > none, and Slim just left town. Of course, Jeff has surprised us > before... :-) Which -- except for the low-level investigation on where the rpmbuild core uses %buildroot as opposed to $RPM_BUILD_ROOT -- is what I've written earlier, albeit with different words. There is no reason to believe that %buildroot would be killed without a warning. But please don't expect me to edit a Wiki before I haven't heard more voices as it is not me who decides on the fate of such guidelines. There are so many writings in the Wiki one can improve/enhance/modify, I could stop reviewing packages and switch to become a documentation dude. Which I don't want. -- From ms-nospam-0306 at arcor.de Fri Feb 27 10:41:25 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 11:41:25 +0100 Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> <200402270020.14634.lowen@pari.edu> Message-ID: <20040227114125.67798bc6.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 02:14:33 -0500 (EST), Mike A. Harris wrote: > I'm kindof rather amused by people arguing over "Which should be > used $RPM_BUILD_ROOT or %{buildroot}?" so violently. I don't see any violence here. You should not have skipped the messages. if want to build an opinion. > The likelyhood of that major of a change happening to rpm *ever*, > is very unrealistic IMHO, and so it really makes no difference > which people use, so arguing vehemently about which one is more > "correct" is a sheer and utter waste of time. ;o) Which matches what I've written much earlier. But then the thread has drifted into a general fedora.us policy debate. -- From jos at xos.nl Fri Feb 27 10:46:06 2004 From: jos at xos.nl (Jos Vos) Date: Fri, 27 Feb 2004 11:46:06 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227113321.3e86433c.ms-nospam-0306@arcor.de>; from ms-nospam-0306@arcor.de on Fri, Feb 27, 2004 at 11:33:21AM +0100 References: <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <200402262336.13553.lowen@pari.edu> <20040227113321.3e86433c.ms-nospam-0306@arcor.de> Message-ID: <20040227114606.A9247@xos037.xos.nl> On Fri, Feb 27, 2004 at 11:33:21AM +0100, Michael Schwendt wrote: > All that has been pointed out is that reviewers appreciate ready-to-use > URLs, which they can cut'n'paste into console or browser to fetch a > tarball from upstream. It has been pointed out that some packagers > tend to obfuscate URLs with macros to a degree that is far from smart, > e.g. > > Source0: http://foo.bar/%{name}/%{version}/%{name}-%{version}rc1.tar.gz > > and that is bad taste and bad style. Or it turns out, the URL hasn't been > updated or verified in a longer time and is not true anymore. Absolutely true. This is the reason I *always* check URL, Source* and Patch* fields for every new version of my own rpm's by copying/pasting into a browser and/or wget/curl, so I avoid macros in those fields too. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ms-nospam-0306 at arcor.de Fri Feb 27 11:10:19 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 12:10:19 +0100 Subject: OMG! I've started a war! - Was:Prelink success story :) In-Reply-To: <1077862252.12909.27.camel@chip.laiskiainen.org> References: <20040227022442.1cb028e8.ms-nospam-0306@arcor.de> <1077862252.12909.27.camel@chip.laiskiainen.org> Message-ID: <20040227121019.5fc6ee5a.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 08:10:53 +0200, Panu Matilainen wrote: > I can't speak for Dag or anybody else but I'm reading between the lines > that he (and others) are interested in Fedora Extras which fedora.us is > supposed to become/be merged with, and wants to discuss these things so > that the official Fedora Extras can get rid of some of the issues that > have kept him and other individual repository maintainers away from > contributing to fedora.us. I agree with the first half of that long sentence, but not with the second half. > So please lets not get into the painful and tiresome fedora.us vs > individual-repositories flamewars again but at least *try* to have a > decent discussion what Fedora Extras rules should be, since the current > fedora.us policies are more than obviously driving various people away > from it. But when I've asked before what set of rules would be "better", there has been silence as response. Obviously, some packagers would contribute only * if they had access to the build system, * could release whenever they like, * could perform version upgrades whenever they like, * and if they did not depend on other people to review/approve their "work". And with that we're back at the general fedora.us policy debate, because it has been found that the average package needs some work before it is considered ready. And that has been true for some packages adapted from 3rd party repositories, too. (At fedora.us, a package with incomplete build requirements will either fail in the build system or build with an incomplete set of features, so "smart'n'lazy" building of binary rpms doesn't work.) > Having the kind of people who can maintain dozens or hundreds > of packages themselves (like the individual repository maintainers now > do) on board instead of everybody ignoring and denying each others > existence would be an asset, not a bad thing. No, but it is far from a realistic vision, and we haven't had any discussions that give reason to believe otherwise. Come on, buildroot and epoch are no blockers, are they? > The thing we should get rid of is the repackaging of same basic stuff > (as in "everybody uses") over and over again. "We should" is easy to say. I've said a similar thing about duplication of efforts a long time ago. The question is how to achieve it? -- From erik at totalcirculation.com Fri Feb 27 11:21:48 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 27 Feb 2004 06:21:48 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CD949@smith.interlink.local> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Toshio > Sent: Friday, February 27, 2004 12:02 AM > To: fedora-devel-list at redhat.com > Subject: Fedora.us QA (was: Re: Prelink success story :)) > > I think the need to get feedback _on_a_QA_ is the heart of the problem > right now. QA'ers need mentoring to develop their skills. Jef, how > would you feel if some bug day we had experienced QA'ers team with new > QA'ers to nitpick packages? This could be a good first or second time > QA experience: irc with a more experienced QA'er and pick apart the good > and bad of a package. Or we could assemble a team of experienced QA'ers > to do second reviews once a new user did the first one. This could be > useful for a more advanced QA'er. Kinda have a short apprenticeship > followed by a test what you know phase. > I like this idea in principal. I'm not sure if expecting people to meet up on IRC is likely to happen or not, but having an experienced reviewer mentoring the new reviewers work would help to ensure that it's done right, and provide feedback to the new reviewer so that they can feel like something is happening and they're making a valuable contribution. Obviously they'll learn a lot from it too. > > What I would like to see (for both QA and packager) is an RPM Best > Practices Handbook. Accumulated wisdom about how to do things well > organized by use cases with in depth justifications available as side > passages for those who are curious why %{buildroot} and > ${RPM_BUILD_ROOT} have such strong proponents on each side :-) > This is a good idea too, although I think it would require a central collection authority to really get up to speed. Maybe redhat will hire someone to do this sometime? Perhaps the wiki could be coerced into holding some of this info in the form of a vastly glorified QA checklist? > > I wanted to write a fedora-qatemplate script that could generate a > template complete with checklist. But I still haven't figured out how > the template should be structured to address all the shortcomings I > listed above. (My best thought so far has been to abandon the CLI and > instead have an interactive GUI script with checklist that outputs > certain security related boilerplate and whatever checklist items fail.) A tool to help generate QA reviews certainly wouldn't hurt, although it seems like the showstoppers could be covered in a list short enough that it could be easily cut'n'pasted. > > As QA stands (with all volunteer QA'ers) we can't depend on a newbie > doing first review and a seasoned vet doing the second review to figure > out what the newbie left out. Besides, the seasoned vet is likely to do > the same things the newbie did to make sure those things really do check > out so having the newbie _just_ run through a checklist isn't that > useful. What is useful is if the new QA'er has the sense of > responsibility to run through the checklist and the curiosity to test > whatever looks broken, fragile, or otherwise could might need > improvement. > What's to prevent a seasoned vet from reviewing newbie reviewed packages? It seems to me that that's the idea behind the 2 reviews policy. Somewhere I read that those "trusted" by the project were given authority to approve QA on their own anyway. Maybe that should be amended so that they are the only ones to actually APPROVE a project, so then all reviews NOT made by a "trusted member" would need a second approval before going live. I suppose this depends on how open the project is to granting people "committer privileges" or "trusted status". > > > > The non-showstoppers should be on a second list of "stuff to watch for". > > This could be far more detailed than the actual QA checklist, and as a > > newbie gets deeper into packaging lore, they would likely begin filling > > out more of it. > > > In my mind I divide things into showstopper and stylistic. With the > possible exception of the present wording of RPM_BUILD_ROOT, I think > everything on the list is a showstopper. And as Michael lists, there > are many more that aren't on the list (because they don't occur often > enough? Because there isn't consensus yet? Because no one wanted to > turn the Checklist into a pre-flight manual with seventy pages > sixty-nine of which don't apply to this particular package?) I like that distinction. However, I don't think unowned directories, incorrect file permissions or lack of macros in paths qualify as show stoppers. Why is fedora.us / extras held to a higher standard of quality than redhat themselves? There is plenty of time to improve packages with time, and getting stuck on perfection before passing QA is going to prevent anyone from posting or reviewing packages. As time goes by, we'll have automated tools to check for this stuff and be able to improve it incrementally > > > 1. Does the package follow the Fedora Package Naming Guidelines? > > This is pretty darn complicated for a newbie QA'er. They should be > > allowed to opt out. > My problem with opting out was stated above: what if two QA'ers review > the package and both opt-out? > OK. Point well made. However, if there's a checklist, you'll know if somebody opted out. Changing the name is painful, so it should be right the first time. A newbie can probably be expected to devote 15 minutes to figuring out the naming conventions. However, if we aim for allowing someone to contribute meaningfully in 1 hour, for instance, that leaves 45 minutes for them to get up to speed on everything else. I believe that if we get the time required to get up to speed down under an hour, there will be a VAST influx of QA information and new blood to the project. Just think of it: "How to help the Fedora Project in 1 hour!" > > 3. Are the pre- and post(un)install scripts correct? > > ...Again, concrete steps would be better. ... > I think this one exceeds the step-by-step. Way too many things could > happen in the scriptlets to say definitively when it's done (more > entries for a best practices book, OTOH...) > Personally I think this should be included under "does it install". QA needs to check if it installs and seems to work. Expecting the QA'er to analyze the scripts in detail is prohibitive and nebulous. If there's a problem, somebody will notice it and file a bug report eventually. It's important to check the scripts for grossly abusive things like rm -rf /, but beyond that the test should be no more complex than whether or not it appears to work on the target distro. This is the packagers job. > > 5. Are there no missing BuildRequires? > > > I agree that this can be basically impossible as it now stands. I first > tried fedora-rmdevelrpms but that made my machine close to unusable as a > development environment (to QA or program.. Hmmmm...) > A fully functional and preconfigured mach build included in fedora.us would essentially solve this particular problem. Then this step can be called "Does it build" on the QA checklist and be left at that. > > 1. Relax on the whole GPG thing. .... > > When they [a new QA'er] first start, their input is going > > to be suspect anyway, so why slow down the process > > > I might be a little attached to public key cryptography, but I think > it's an important added protection. Bugzilla accounts can be traced to > creation dates and email addresses. GPG keys add third party > signatures. If crackers ever start trying to package compromised files > and get them into Extras, we will have more information to scan on to > try to figure out if we need to do more background checking on the > packager/QA'ers of a package. OTOH, that might be completely emotional > and the additional security might not be that great. > I don't think there's anything wrong with GPG, and I agree it adds a great measure of security. However, I do think stressing its importance to new QA'ers is time wasted. Once they get more involved they'll see the value, and want to figure it out on their own. Again, think of reducing the barrier for entry. > [snippage] > > I think it's imperative that packages make it through the QA process. It > > doesn't do any good if packages never make it into the repo. > > Speaking as someone who responds when someone points out a packaging > error but has never had a package make it through the queue: Sometimes > you've got to accept it. I only package things I need. If it doesn't > make it out the door, then not enough other people found it equally > useful. *shrug* > > That said, the most frustrating packages are not the ones that sit there > unreviewed, but the ones that sit there half reviewed (or with an older > version reviewed but not a newer one.) It implies interest, but not > enough among active QA'ers to make the push over the hump. I disagree. I don't think the problem is lack of interest, but a too high barrier for entry. QA as it stands is a nebulous beast. There are a few guru's who know what is expected by fedora.us, and if they take an interest in your package it will get QA'd. Otherwise, the other 5000 users such as myself might make it as far as the QA list and download your package, but are HIGHLY unlikely to invest the 8 hours I did just to see possible failure. This process has got to get streamlined enough that we can get critical mass. I'm not positive of this, but it seems as if the number of submitted and un-QA'd packages is increasing, not decreasing. That's a sign that the QA system is not doing its job. QA is never going to be attractive to "super-star coders", and I'm of the opinion that most of those doing it right now fall into that category. These are the same type of people who manage to maintain repositories of 300+ packages single-handedly. These type of people generally don't like checklists, and see them as the oversimplification which they are. It's GREAT to have these kind of people involved with the project, but for fedora / fedora.us / extra's to draw on it's potential it needs to attract input from people who don't make packages fulltime, but instead want to use them. Instead, QA is going to be attractive to some poor sysadmin who needs amavis (or one of the other 300+ packages sitting in the QA queue), and wants to know it will work well with fedora, and that it will upgrade cleanly in the future. The same guy who right now points his yum.conf at atrpms, dagrpms and freshrpms because THEY have packages that he can download NOW, and usually work. He may not know much about rpm, but if he's got a simple how to start guide and a checklist to fill out he'll be happy to spend an hour or two auditing the spec file to the best of his ability (on company time) so that he can stop maintaining his own RPM or worrying about future incompatibilities in other peoples repo's. The fact that fedora.us is a single repository, with multiple people responsible for it will be enough of a reason for him to devote a little bit of his time to QA rather than using the other repo's if it's straightforward and he can expect results. In addition, I'm of the opinion that a lot of the independent packagers would start submitting packages to fedora.us / extra's IF they felt they would get approved in a timely manner. Right now, QA is WAY too complicated and fraught with pseudo policies that just turn people away and confuse matters. Just my $0.02. --erik From mharris at redhat.com Fri Feb 27 11:26:57 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 06:26:57 -0500 (EST) Subject: (fwd) Perl/mod_perl test update In-Reply-To: References: Message-ID: On Wed, 25 Feb 2004, Chip Turner wrote: >Date: 25 Feb 2004 21:37:08 -0500 >From: Chip Turner >To: fedora-devel-list at redhat.com >Content-Type: multipart/mixed; boundary="=-=-=" >List-Id: Development discussions related to Fedora Core > >Subject: (fwd) Perl/mod_perl test update > > >The perl update includes the virtual provides for perl modules to use >to rely on when they are built against it as discussed a couple weeks >ago. Anyone who can give this a whirl and let me know any breakages, >I'd appreciate it; should be a fairly safe update but I want to get >5.8.3 on all supported RHL/RHEL/Fedora releases that are currently in >the 5.8.x family. Chip, I just released a new xchat release for Fedora Core 1 today. Is this perl update going to require another xchat update? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ms-nospam-0306 at arcor.de Fri Feb 27 11:34:16 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 12:34:16 +0100 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <1077858145.4875.333.camel@Madison.badger.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> Message-ID: <20040227123416.2f4c37b1.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 00:02:28 -0500, Toshio wrote: > I think the need to get feedback _on_a_QA_ is the heart of the problem > right now. QA'ers need mentoring to develop their skills. Jef, how > would you feel if some bug day we had experienced QA'ers team with new > QA'ers to nitpick packages? This could be a good first or second time > QA experience: irc with a more experienced QA'er and pick apart the good > and bad of a package. Or we could assemble a team of experienced QA'ers > to do second reviews once a new user did the first one. This could be > useful for a more advanced QA'er. Kinda have a short apprenticeship > followed by a test what you know phase. The approach with the REVIEWED keyword belongs to a plan like this. Still, it will need some to time to develop. Because we have upgrades to process, too, and can't neglect them. And unfortunately, upgrades are not trivial to approve, as either they fail somewhere or break something. I've offered "team reviews" before, where someone would add me to Cc after the first review and I would take a second look and be there if a second publish vote is needed. I still offer being added to Cc in case of any questions, too. > What I would like to see (for both QA and packager) is an RPM Best > Practices Handbook. Accumulated wisdom about how to do things well > organized by use cases with in depth justifications available as side > passages for those who are curious why %{buildroot} and > ${RPM_BUILD_ROOT} have such strong proponents on each side :-) You have misunderstood the buildroot discussion. The reason why $RPM_BUILD_ROOT is recommended is linked from within the QA checklist. > As QA stands (with all volunteer QA'ers) we can't depend on a newbie > doing first review and a seasoned vet doing the second review to figure > out what the newbie left out. So why is there no second newbie who joins the first newbie? As I put it, both newbies can approve a package but still would need to get pass the build system and the release manager. And if the package has bugs, what's so wrong about learning from mistakes and bug reports? Hey, there are even bug reports about missing desktop menu icons. ;) > > 2. Provide some feedback. I QA'd some packages. I waited. > > I agree that reviews of work done encourage learning. Yeah, but rather than waiting silently, why not post to fedora-devel-list and request comments? More communication can help. -- From mharris at redhat.com Fri Feb 27 11:51:02 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 06:51:02 -0500 (EST) Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227112538.087e956e.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <20040227112538.087e956e.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: >> Macros work fine for me in Source tags, with URLs and without. >> See the xchat spec file for an example. >> >> pts/34 mharris at porkchop:~/rpmbuild/rpms/xchat$ grep Source xchat.spec >> Source: http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 > >You haven't payed attention to the detail: > > $ wget http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 > ERROR 404: Not Found. Why on earth would you wget on the commandline with an rpm macro embedded into the commandline? That is user-error. Do not cut and paste the URL from the spec file to the commandline. First of all, if you have the src.rpm installed, you _have_ the source code already, and do not need to download it. If you want to anyway for some reason, you have the URL where it is located and can hand edit it to be useable if desired, or can cut and paste the directory and go from there. I believe you can also query the spec file using --specfile to get the Source and Patch lines, however I'd have to confirm that. There are numerous places in a given spec file that you can't just cut and paste it into the commandline and use for some purpose. The intent of the specfile is to build the software and package it, not to facilitate cut and pasting things. >And upon building source and binary rpm, the >http://www.xchat.org/files/source/2.0/ is stripped off, and only >the expanded xchat-%version.tar.bz2 is included in the RPM >header. $ rpm -qp --qf '%{source}\n' /mnt/redhat/beehive/comps/dist/fc2/xchat/2.0.7-3/SRPMS/xchat-2.0.7-3.src.rpm xchat-2.0.7.tar.bz2 >So, what works "fine" for you? That you can obfuscate URLs with >macros? Huh? The macro is there, for the same reason people use macro's in the C programming language, and other programming languages, as well as scripting languages. So that you can update a constant in one single location, and have that constant propagate throughout the file(s) that it is relevant to. By updating the single field "Version" in the spec file, that causes the %version macro to be created with the value that was supplied in the Version tag, and that value gets replaced throughout the spec file, thus making a single change propagate through everywhere necessary without requiring the developer to manually update a single constant in 50 locations. >Or do you cut'n'paste part of the URL to visit the download >directory in a browser? No I do not. I go to the xchat homepage located at http://www.xchat.org, find out what the latest version of it is, download all versions since the current rpm release, then create unified diffs between each release, and review them. Once I've chosen the new version to update to, I edit the spec file and modify the Version: field to match the release. That one change makes the version propagate through the spec file via macro expansion. The Source field(s) in the spec file exists for 2 main purposes: 1) To indicate to RPM, the source files it should include in the spec file. Some or all of these will either be expanded by the %setup macro later on, or will be referenced directly via %{SOURCEnn} tags somewhere in the spec file. All text leading up to the final "/" character is stripped from the filenames prior to accessing the files at build time. 2) To store the URL (if any given) in the Source field of the RPM header, for people querying the src.rpm from the commandline with rpm. 3) To provide a hint to the package maintainer or others, of where the file was obtained from. Anyone sensible can easily cut and paste the directory name, and ftp/http to that location to find out what the current source is. If all you want is the source code tarball that is in the src.rpm, then you have it already in the SOURCES directory. I'm not about to change the Source fields in any of my own spec files to hard code the version and remove the existing macro usage, which is correct, howver feel free to edit your own spec files and change the version number in 10 places every time a new version of the software you're maintaining comes out, and ensure every location is updated, and track down the bugs/problems caused if you forget in some location. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Fri Feb 27 11:57:48 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 06:57:48 -0500 (EST) Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: <20040227114125.67798bc6.ms-nospam-0306@arcor.de> References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> <200402270020.14634.lowen@pari.edu> <20040227114125.67798bc6.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: >> I'm kindof rather amused by people arguing over "Which should be >> used $RPM_BUILD_ROOT or %{buildroot}?" so violently. > >I don't see any violence here. You should not have skipped the messages. >if want to build an opinion. I haven't skipped any messages. I have however formed an opinion. My opinion is that a lot of people like to argue endlessly about very pointless and trive details of rpm packaging, to extreme pedantism. Most of the arguments being purely of preferential nature, with no real right or wrong way, although both sides will generally declare their way right, and the other way totally and insanely wrong. The other side then argues back with a similar but inverted argument, pointing out equally preferential arguments to prove the first person (or people) are wrong and they are right. In the end, nothing actually happens other than 2 groups of people arguing with each other, neither of whom is going to convince the other group to change their mind. Nobody changes their mind, and each group goes on doing things the way that they think is best, and then attacking each other once every n days/weeks/months whenever another person brings up the same topic. It really is very much like vi vs. emacs. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ms-nospam-0306 at arcor.de Fri Feb 27 12:43:51 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 13:43:51 +0100 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CD948@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD948@smith.interlink.local> Message-ID: <20040227134351.7e71c791.ms-nospam-0306@arcor.de> On Thu, 26 Feb 2004 22:03:26 -0500, Erik LaBianca wrote: > > Reviewers should develop a feeling for > > what is important and what is not. > > > > How is a new reviewer supposed to develop that feeling? You've got to > have a place to start. You do. What's in the Wiki and what you run into upon reviewing packages. For instance, you take a look at a package which contains a spec file with multiple scriplets. That's something not covered by the current checklist, and it would raise your interest, wouldn't it? In particular, because programs executed in the scriplets may need explicit dependencies. Or if a package fails to build, wouldn't you want to find out why it fails? Because if you didn't, the packager might reply "works for me", and you'd be in a loop if it is non-obvious breakage. Or you see lots of explicit dependencies, "Obsoletes:" or "Conflicts:" (not covered by the checklist either). > No they don't. However, as a newbie, my impression was that I was to > review ALL aspects on the checklist. After doing some QA and looking at > other peoples bugzilla reports I figured out that it would be ok if I > just downloaded the package and made some comments about what I didn't > like. Sure, as long as you feel good about it. Notice that the packager doesn't need to agree with what you don't like. ;o) > However, people just making comments about what they like doesn't > provide a deterministic path to REVIEWED status. No, that's why there are the publish criteria. A section in the Wiki mentions what a clearsigned review must contain. > If I just make comments about broken things, and then submit an > approval, how do you know I verified md5sums? Never. How would I know whether you visited upstream actually and not just ran md5sum on the included tarball? > If the package works, let it go or > argue about it, but don't stall it in QA over this. That's why I point out that reviewers' comments usually are a mixture of must-fix and should-change items. > I'm seriously concerned that packages be able to move through fedora > quickly and efficiently, without compromising their quality. I'm not > convinced the current process is getting that job done. It's not due to the process but due to lack of reviewers. > > > 11. Does it pass rpmlint cleanly? > > > > Not always possible. :) > > > > Ok true, but if it doesn't maybe that's time for a more knowledge person > to approve that which doesn't pass rpmlint? Depends on what rpmlint reports. We package for Fedora Core, not to make rpmlint happy. > but > expecting packages to be perfect before they pass QA is going to stall > the process indefinitely. If those issues come up, the newbie may not be > able to detect them. They'll get noticed sometime, and should get fixed > then. But we face an all-or-nothing mentality. People don't review because they want to avoid mistakes. > > NEEDSWORK is to move packages out of the QA queue, because they don't > > build or need more work before they are moved back into the QA queue. > > This can also be set by the packager if major changes are planned. > > REVIEWED is the new keyword to flag reviewed packages, so they are > > easy to locate. > > > > OK. So at what point do I make the determination that the package has > passed QA? When you feel good about it. ;) > This way my likelihood of looking like an idiot is very low, if I > followed the instructions properly. Not feeling like an idiot is what > makes people come back and feel good about contributing. There is no silver bullet. I don't understand why/when you would feel like an idiot. > > issues. Sometimes you need to wait till the next weekend. If the packager > > doesn't respond, simply move the request out of the package queue by > > deleting the QA keyword and setting the NEEDSWORK keyword. > > > OK, that's fine, but in all reality I'm uninterested in removing the > package from the QA queue. I want the package published! And now! At > what point is it ok for me to just post my own version of the SRPM? That cannot be covered with a rule. Talk to the packager, i.e. the current maintainer or the one who submitted the package. You build a team with him as soon as you comment on the package. If he doesn't mind someone else taking over the package, you switch roles, and then you would be the packager who needs reviews. :) But if either party has no time to work on a package/review, patience is needed. Or additional reviewers who help. > Also, documentation of these keywords was not apparent to me in the web > of pages I looked at while trying to figure this process out. Some of the keywords don't really belong to a "process", but just help upon classifying and locating bugzilla tickets. > > If there are people with interest in a package, surely there should be > > two reviewers, too? > > > > I'm sure they are out there, but we've got to make the process so darn > straightforward they can't help but succeed once they decide to help > out. I'm skeptical that it's that way now. I'm not sure if I succeeded > yet, and I can assure you I attacked it unsuccessfully a few times > before finally making it over the hump of actually posting a review > comment. We need more reviewers and more feedback. -- From leonard at den.ottolander.nl Fri Feb 27 12:54:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 13:54:06 +0100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227025751.GF29689@devserv.devel.redhat.com> References: <20040227025751.GF29689@devserv.devel.redhat.com> Message-ID: <1077886446.4747.11.camel@athlon.localdomain> Hello Bill, > We're encountering various issues that are causing us to delay > the release of test2. We'd like to get as much exposure to SELinux > as possible, and this means shipping test2 with SELinux in > enforcing mode. However, there are still some subsystems that > aren't quite ready for this, so we need to slide the release > date some. Good. I can see this SELinux stuff needs a lot of testing before it is ready for prime time. Some user education on how to use this is also welcome, as you wouldn't want large amounts of users to lock themselves out of their own systems once this gets released. Personally I wouldn't mind the final only to come out somewhere around the 31st of June. How well scrutinized is this NSA code actually? Everybody can see they won't slip in an obvious backdoor, but how about nasty little overflows, tucked away deep inside the code, for which they already have exploits in their drawer? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ms-nospam-0306 at arcor.de Fri Feb 27 13:08:23 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 14:08:23 +0100 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CD949@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD949@smith.interlink.local> Message-ID: <20040227140823.51090b88.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 06:21:48 -0500, Erik LaBianca wrote: > I like that distinction. However, I don't think unowned directories, > incorrect file permissions or lack of macros in paths qualify as show > stoppers. Depending on root's umask, unowned directories would be created inaccessibly for ordinary users. Incorrect file permissions (e.g. missing %defattr) would give an arbitrary ordinary user write-access to those files. And when such issues are found during QA, why not fix them? > Why is fedora.us / extras held to a higher standard of quality > than redhat themselves? Because Red Hat have an established distribution already. Fedora.us is in the process of building a reliable base which other packages can build upon. > There is plenty of time to improve packages with > time, and getting stuck on perfection before passing QA is going to > prevent anyone from posting or reviewing packages. Again, *when* such issues are discovered during the review phase, why not fix them sooner rather than later? > Instead, QA is going to be attractive to some poor sysadmin who needs > amavis (or one of the other 300+ packages sitting in the QA queue), and > wants to know it will work well with fedora, and that it will upgrade > cleanly in the future. The same guy who right now points his yum.conf at > atrpms, dagrpms and freshrpms because THEY have packages that he can > download NOW, and usually work. But if he's entirely happy with those repositories, he doesn't have any interest in getting the same software included in another repository. He must recognize the additional benefits of an open community project like fedora.us or Fedora Extras before he would choose to support it. -- From russell at coker.com.au Fri Feb 27 13:09:58 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 28 Feb 2004 00:09:58 +1100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077886446.4747.11.camel@athlon.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> Message-ID: <200402280009.58802.russell@coker.com.au> On Fri, 27 Feb 2004 23:54, Leonard den Ottolander wrote: > How well scrutinized is this NSA code actually? Everybody can see they > won't slip in an obvious backdoor, but how about nasty little overflows, > tucked away deep inside the code, for which they already have exploits > in their drawer? If you create an account on a free mail service and send in a patch to Linus that looks good there's a chance that it will get accepted. If the NSA people were going to do something nasty why would they do it in code that's got their name on it when they could send in code from random_user at hotmail.com? Also the SE Linux kernel code is written in a clearer style than most kernel code. If you want to audit code for correct operation the SE Linux code will be easier than most. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at epoch.ncsc.mil Fri Feb 27 13:15:36 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 27 Feb 2004 08:15:36 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077886446.4747.11.camel@athlon.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> Message-ID: <1077887736.26543.10.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-02-27 at 07:54, Leonard den Ottolander wrote: > How well scrutinized is this NSA code actually? Everybody can see they > won't slip in an obvious backdoor, but how about nasty little overflows, > tucked away deep inside the code, for which they already have exploits > in their drawer? The SELinux kernel module went through the usual review process on lkml. Further code audit of the SELinux userland patches and new userland packages is certainly welcome; we are certainly capable of making mistakes too, but no, there is no intentional introduction of vulnerabilities. -- Stephen Smalley National Security Agency From ms-nospam-0306 at arcor.de Fri Feb 27 13:18:37 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 14:18:37 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <20040227112538.087e956e.ms-nospam-0306@arcor.de> Message-ID: <20040227141837.4cea7e78.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 06:51:02 -0500 (EST), Mike A. Harris wrote: > On Fri, 27 Feb 2004, Michael Schwendt wrote: > > >> Macros work fine for me in Source tags, with URLs and without. > >> See the xchat spec file for an example. > >> > >> pts/34 mharris at porkchop:~/rpmbuild/rpms/xchat$ grep Source xchat.spec > >> Source: http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 > > > >You haven't payed attention to the detail: > > > > $ wget http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 > > ERROR 404: Not Found. > > Why on earth would you wget on the commandline with an rpm macro > embedded into the commandline? That is user-error. Do not cut > and paste the URL from the spec file to the commandline. Do not put macros into web URLs. > First of all, if you have the src.rpm installed, you _have_ the > source code already, and do not need to download it. I do have to compare the included tarball MD5 with upstream MD5. Alternatively, I need to visit the web page, find the download section and download manually from there. > If you want > to anyway for some reason, you have the URL where it is located > and can hand edit it to be useable if desired, or can cut and > paste the directory and go from there. Often doesn't work because directory indexing is not allowed. > I believe you can also query the spec file using --specfile to > get the Source and Patch lines, however I'd have to confirm that. Only to find out the URL is no longer valid because the packager has a working one in his own private bookmarks. > >And upon building source and binary rpm, the > >http://www.xchat.org/files/source/2.0/ is stripped off, and only > >the expanded xchat-%version.tar.bz2 is included in the RPM > >header. > > $ rpm -qp --qf '%{source}\n' /mnt/redhat/beehive/comps/dist/fc2/xchat/2.0.7-3/SRPMS/xchat-2.0.7-3.src.rpm > xchat-2.0.7.tar.bz2 Proves what I write above. :) > 2) To store the URL (if any given) in the Source field of the RPM > header, for people querying the src.rpm from the commandline > with rpm. See above, didn't work for you. > I'm not about to change the Source fields in any of my own spec > files to hard code the version and remove the existing macro > usage, which is correct, No one requires you do to that. You have misunderstood what all this is about. *sigh* > howver feel free to edit your own spec > files and change the version number in 10 places every time a new Why 10 places? Two places is enough. "Version:" and "Source:", everywhere else %{version} is fine. > version of the software you're maintaining comes out, and ensure > every location is updated, and track down the bugs/problems > caused if you forget in some location. If I forgot to updated the version in Source tag, the package would not even build. We've discussed this earlier. Sorry for cutting off much of your message, but I don't understand what you're aiming at. I don't want another heated thread based on misunderstandings. -- From ms-nospam-0306 at arcor.de Fri Feb 27 13:20:58 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 14:20:58 +0100 Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> <200402270020.14634.lowen@pari.edu> <20040227114125.67798bc6.ms-nospam-0306@arcor.de> Message-ID: <20040227142058.738f3e87.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 06:57:48 -0500 (EST), Mike A. Harris wrote: > On Fri, 27 Feb 2004, Michael Schwendt wrote: > > >> I'm kindof rather amused by people arguing over "Which should be > >> used $RPM_BUILD_ROOT or %{buildroot}?" so violently. > > > >I don't see any violence here. You should not have skipped the messages. > >if want to build an opinion. > > I haven't skipped any messages. I have however formed an opinion. > > My opinion is that a lot of people like to argue endlessly about > very pointless and trive details of rpm packaging, to extreme > pedantism. Sorry to say that, but apparently you have misunderstood the messages. You make it worse by pushing it into a wrong direction. -- From pmatilai at welho.com Fri Feb 27 13:47:16 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 27 Feb 2004 15:47:16 +0200 (EET) Subject: OMG! I've started a war! - Was:Prelink success story :) In-Reply-To: <20040227121019.5fc6ee5a.ms-nospam-0306@arcor.de> References: <20040227022442.1cb028e8.ms-nospam-0306@arcor.de> <1077862252.12909.27.camel@chip.laiskiainen.org> <20040227121019.5fc6ee5a.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: > On Fri, 27 Feb 2004 08:10:53 +0200, Panu Matilainen wrote: > > > I can't speak for Dag or anybody else but I'm reading between the lines > > that he (and others) are interested in Fedora Extras which fedora.us is > > supposed to become/be merged with, and wants to discuss these things so > > that the official Fedora Extras can get rid of some of the issues that > > have kept him and other individual repository maintainers away from > > contributing to fedora.us. > > I agree with the first half of that long sentence, but not with the second > half. You're probably reading too much into that... > > > So please lets not get into the painful and tiresome fedora.us vs > > individual-repositories flamewars again but at least *try* to have a > > decent discussion what Fedora Extras rules should be, since the current > > fedora.us policies are more than obviously driving various people away > > from it. > > But when I've asked before what set of rules would be "better", there has > been silence as response. Obviously, some packagers would contribute only > > * if they had access to the build system, > * could release whenever they like, > * could perform version upgrades whenever they like, > * and if they did not depend on other people to > review/approve their "work". > > And with that we're back at the general fedora.us policy debate, because > it has been found that the average package needs some work before it is > considered ready. And that has been true for some packages adapted from > 3rd party repositories, too. (At fedora.us, a package with incomplete > build requirements will either fail in the build system or build with an > incomplete set of features, so "smart'n'lazy" building of binary rpms > doesn't work.) Sure, and I'm not advocating removing the QA process from the system or anything like that. I guess I'm mostly trying to say "keep down the flames" - fedora.us policies were discussed at length (mildly put) but that doesn't mean there isn't room for improvement, if somebody outside current fedora.us community suggests something it shouldn't be just shot down "because you don't care anyway". OTOH I'm curiously waiting what's RH's stand on the Extras thing (or are they going to say anything other than tell "fedora.us IS Extras"). > > > Having the kind of people who can maintain dozens or hundreds > > of packages themselves (like the individual repository maintainers now > > do) on board instead of everybody ignoring and denying each others > > existence would be an asset, not a bad thing. > > No, but it is far from a realistic vision, and we haven't had any > discussions that give reason to believe otherwise. Come on, buildroot > and epoch are no blockers, are they? Maybe not, but being over pedantic about some artificial rules can be, for somebody with 300 packages. If the packages work then why should the packager tweak their specs to match some artificial rules when it already works? Note the *if* in there - those 300 packages should be peer-reviewed just like anything else to see that they're ok. I'm just repeating what I've said before: fedora.us QA can be incredible nitpicking, whether it's the intention or not and that can be awfully irritating if the package already "just works" but maybe doesn't win the annual spec beauty contest :) > > > The thing we should get rid of is the repackaging of same basic stuff > > (as in "everybody uses") over and over again. > > "We should" is easy to say. I've said a similar thing about duplication > of efforts a long time ago. The question is how to achieve it? I don't hold the silver bullet but open-mindness (trying to mentally clear off the old flamewars, meaning everybody involved, not you or anybody else specifically) would be a start I suppose. - Panu - From toshio at tiki-lounge.com Fri Feb 27 14:03:51 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 27 Feb 2004 09:03:51 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <20040227123416.2f4c37b1.ms-nospam-0306@arcor.de> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> <20040227123416.2f4c37b1.ms-nospam-0306@arcor.de> Message-ID: <1077890630.4875.378.camel@Madison.badger.com> On Fri, 2004-02-27 at 06:34, Michael Schwendt wrote: > I've offered "team reviews" before, where someone would add me to Cc after > the first review and I would take a second look and be there if a second > publish vote is needed. I still offer being added to Cc in case of any > questions, too. > Great! If we had something written about "Michael Schwendt has a standing invitation to ask him to do a second review to help you figure out what you've missed (and incidentally get the package 100% reviewed)" would be great. Getting other people to sign on to do this would be great too. > > What I would like to see (for both QA and packager) is an RPM Best > > Practices Handbook. Accumulated wisdom about how to do things well > > organized by use cases with in depth justifications available as side > > passages for those who are curious why %{buildroot} and > > ${RPM_BUILD_ROOT} have such strong proponents on each side :-) > > You have misunderstood the buildroot discussion. The reason why > $RPM_BUILD_ROOT is recommended is linked from within the QA checklist. > Nope. I've read that, including the part where Jef says that he's not likely to change it anytime soon even though it's a mis-feature (paraphrased.) Added to that is the fact that it's a _build_ problem. Already created binary RPMS have no problems. If Jef announces that %{buildroot} is deprecated we can start making this a showstopper and kill all references as an evolutionary process. > > As QA stands (with all volunteer QA'ers) we can't depend on a newbie > > doing first review and a seasoned vet doing the second review to figure > > out what the newbie left out. > > So why is there no second newbie who joins the first newbie? As I put it, > both newbies can approve a package but still would need to get pass the > build system and the release manager. And if the package has bugs, what's > so wrong about learning from mistakes and bug reports? Hey, there are even > bug reports about missing desktop menu icons. ;) > True. Maybe I'm the perfectionist on this list :-) > > > 2. Provide some feedback. I QA'd some packages. I waited. > > > > I agree that reviews of work done encourage learning. > > Yeah, but rather than waiting silently, why not post to fedora-devel-list > and request comments? More communication can help. But what if you and dag get into another shouting match? :-) Seriously, this is a good point. We should document it, though. I wasn't sure this would be an appropriate thing to post here until recently. -Toshio -- Toshio From csm at redhat.com Fri Feb 27 14:31:03 2004 From: csm at redhat.com (Chuck Mead) Date: Fri, 27 Feb 2004 09:31:03 -0500 Subject: MrProject is now Planner In-Reply-To: References: <403CB0B8.8070107@redhat.com> Message-ID: <403F54A7.3080005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Blandford wrote: | Chuck Mead writes: | | |>...and there has been an updated release! (.11) |> |>Any chance we can see the updated release in FC2? It fixes a number of |>outstanding bugs. | | | Yeah. I have high hopes of building it today. Excellent... I have a source build tossed into /usr/local on both i386 and x86_64 so I know it builds but the included spec file appears to be a hash and I have no time to fix it! - -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAP1SmZfy0juH51WsRApuQAKCZMw0Kvfb7dwwnn0pRuW9pGXjV+wCePbH9 UmmdZ+LVWVsM2rDZFqdW8Sc= =CJmv -----END PGP SIGNATURE----- From buildsys at redhat.com Fri Feb 27 14:35:50 2004 From: buildsys at redhat.com (Build System) Date: Fri, 27 Feb 2004 09:35:50 -0500 Subject: rawhide report: 20040227 changes Message-ID: <200402271435.i1REZoq03766@porkchop.devel.redhat.com> Updated Packages: anaconda-9.91-0.20040226192747 ------------------------------ * Thu Feb 26 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) at-spi-1.3.13-1 --------------- * Thu Feb 26 2004 Alexander Larsson 1.3.13-1 - update to 1.3.13 * Fri Feb 13 2004 Elliot Lee - rebuilt * Fri Jan 30 2004 Jonathan Blandford 1.3.11-1 - new version cyrus-imapd-2.2.3-5 ------------------- * Thu Feb 26 2004 Dan Walsh - Fix location of < /dev/null gedit-2.5.90-1 -------------- * Wed Feb 25 2004 Dan Williams 1:2.5.90-1 - fix dumbness in the egg-recent file locking patch - Remove the autotools-1.8 patch because it is no longer needed - Require gtksourceview-devel >= 0.9 due to update to 2.5.90 - Update to gedit-2.5.90 gnome-games-2.5.7-1 ------------------- * Thu Feb 26 2004 Alexander Larsson 1:2.5.7-1 - update to 2.5.7 gnome-mag-0.10.7-1 ------------------ * Thu Feb 26 2004 Alexander Larsson 0.10.7-1 - update to 0.10.7 gnome-speech-0.3.1-1 -------------------- * Thu Feb 26 2004 Alexander Larsson 0.3.1-1 - update to 0.3.1 gnome-system-monitor-2.5.3-1 ---------------------------- * Thu Feb 26 2004 Alexander Larsson 2.5.3-1 - update to 2.5.3 gnome-user-docs-2.5.0-1 ----------------------- * Thu Feb 26 2004 Alexander Larsson 2.5.0-1 - update to 2.5.0 gnopernicus-0.7.5-1 ------------------- * Thu Feb 26 2004 Alexander Larsson 0.7.5-1 - update to 0.7.5 gok-0.9.8-1 ----------- * Thu Feb 26 2004 Alexander Larsson 0.9.8-1 - update to 0.9.8 * Fri Feb 13 2004 Elliot Lee - rebuilt * Tue Sep 09 2003 Jonathan Blandford - update for GNOME 2.4 gpm-1.20.1-43 ------------- * Thu Feb 26 2004 Adrian Havill 1.20.1-43 - add event device (for 2.6 kernel) superpatch-- includes all patches up to release 38; thanks to Dmitry Torokhov - change default mouse device over to /dev/input/mice - set mouse type to Intellimouse Explorer (exps2), which is what the 2.6 kernel exports by default grep-2.5.1-26 ------------- * Thu Feb 26 2004 Tim Waugh 2.5.1-26 - Fix fgrep (bug #116909). gstreamer-0.7.5-1 ----------------- * Tue Feb 24 2004 Alexander Larsson 0.7.5-1 - update to 0.7.5 - clean up specfile some - enable docs htdig-3.2.0b5-6 --------------- * Thu Feb 26 2004 Phil Knirsch 3.2.0b5-6 - Removed buildroot cruft from HtFileFype (#116442). - Use mktemp in HtFileFype to create temporary file (#116443). iiimf-le-inpinyin-0.2-3 ----------------------- * Thu Feb 26 2004 Yu Shao - to switch off lookup table when preedit string is empty iiimf-le-xcin-0.1-5 ------------------- * Fri Feb 27 2004 Leon Ho 0.1-5 - rebuilt * Thu Feb 26 2004 Leon Ho 0.1-4 - install cin2tab with 755 (#116892) - install .so files with executable (#116554) - fixed '0' commit to preedit problem - added 'esc' clean preedit - fixed candidates non-empty problems iptables-1.2.9-2.3 ------------------ * Thu Feb 26 2004 Thomas Woerner 1.2.9-2.3 - fixed iptables-restore -c fault if there are no counters (#116421) kbd-1.12-1 ---------- * Thu Feb 26 2004 Adrian Havill - update to 1.12 kernel-2.6.3-1.110 ------------------ * Thu Feb 26 2004 Dave Jones - Fix unresolved smp_num_siblings symbol on x86-64 * Wed Feb 25 2004 Dave Jones - Update to 2.6.3-bk7 - Change a slew of config options to match those in arjanv's kernel. Lots of "surely no-one is using this anymore" options are now disabled, along with lots of "this is broken anyway" options. - Numerous fixes to various modules to fix panics on unload. * Tue Feb 24 2004 Dave Jones - Update to 2.6.3-bk6 - Enable lots of ISDN config options. - Several E1000 net driver fixes. - Disable ACARD SCSI driver. (It's very broken right now) libpng-1.2.2-19 --------------- * Fri Feb 27 2004 Mark McLoughlin 2:1.2.2-19 - rebuild with changed bits/setjmp.h on ppc mdadm-1.5.0-2 ------------- * Thu Feb 26 2004 Doug Ledford 1.5.0-2 - Add a default MAILADDR line to the mdadm.conf file installed by default (Bugzilla #92447) - Make it build with gcc-3.4 * Mon Feb 23 2004 Doug Ledford 1.5.0-1 - Update to 1.5.0 (from Matthew J. Galgoci ) * Sun Nov 16 2003 Doug Ledford 1.4.0-1 - fix problem with recovery thread sleeping in mdmpd ncurses-5.4-4 ------------- * Thu Feb 26 2004 Adrian Havill 5.4-3 - xterm-color is wrong for rh; inverted bs/del (#115499) openssh-3.6.1p2-31 ------------------ * Thu Feb 26 2004 Daniel Walsh 3.6.1p2-31 - Add restorecon to startup scripts * Thu Feb 26 2004 Daniel Walsh 3.6.1p2-30 - Add multiple qualified to openssh patchutils-0.2.27-1 ------------------- * Thu Feb 26 2004 Tim Waugh 0.2.27-1 - 0.2.27. policy-1.6-12 ------------- * Thu Feb 26 2004 Dan Walsh 1.6-12 - Fix fd inheritance * Thu Feb 26 2004 Dan Walsh 1.6-11 - fix locate * Thu Feb 26 2004 Dan Walsh 1.6-10 - Add Russells latest policycoreutils-1.6-4 --------------------- * Thu Feb 26 2004 Dan Walsh 1.6-4 - exit out when selinux is not enabled * Thu Feb 26 2004 Dan Walsh 1.6-3 - Fix minor bugs in restorecon * Thu Feb 26 2004 Dan Walsh 1.6-2 - Add restorecon c program rhpl-0.128-1 ------------ * Thu Feb 26 2004 Brent Fox 0.128-1 - add some hooks to xhwstate.py to get PCI bus ID info rpmdb-fedora-1.90-0.20040227 ---------------------------- From mharris at redhat.com Fri Feb 27 14:38:46 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 09:38:46 -0500 (EST) Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227141837.4cea7e78.ms-nospam-0306@arcor.de> References: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <20040227112538.087e956e.ms-nospam-0306@arcor.de> <20040227141837.4cea7e78.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: Ok, I've snipped the entire message just to focus on the one issue at hand. >> howver feel free to edit your own spec >> files and change the version number in 10 places every time a new > >Why 10 places? Two places is enough. "Version:" and "Source:", >everywhere else %{version} is fine. One place is enough. "Version:" However, to show I am open minded team player type of guy, I am willing to accept this change and change all of my own packages to meet this request if: - All major users of RPM, including Red Hat, SuSE, Mandrake, Conectiva, all major rpm repositories such as freshrpms.net, fedora.us, etc. agree upon making it an official standard which will go into the official rpm documentation. - Red Hat decides to adopt this internally as a standard, either defacto or official. Unless it is declared an official standard however, I do not see any net increase of benefit to me as a developer to do it the way that you suggest, and I do see some real world disadvantages to doing it the way you suggest. By using macros in the spec file on source lines, the package maintainer gets the following benefits: - It makes it easy to update the version throughout the spec file in one single location, and without having to remember there are two locations, which is the entire point of using a macro. - It removes an element of human error, in which you can update one of the locations and forget to update the other, possibly introducing a bug into the package where new code doesn't actually get used because both are sitting in the current directory. Additionally, the spec file syntax supports a URL tag, which generally should point to the project's official homepage. If there is no homepage, the closest thing to that should be pointed to, which sometimes is nothing more than an ftp or http directory link or similar. By following the URL link, which is unlikely to contain any macros, you can follow the links from there to download the software. This works both from the commandline using links/lynx, or mozilla or some other GUI browser. Another point, is that the number of people who actually look in the spec file is relatively small. The number of those who are likely to cut and paste any of the Source: line URLs onto the commandline for wget, is very likely much smaller than that. Since the source code is already present there already, very few people are going to want to actually go to the full URL directly and redownload the identical file that they already have. There may be a few such as yourself who have special purposes, however my main point here, is that the number of people will be extremely small, possibly one. In this case, the suggestion turns a very very slight inconvenience to someone such who rarely will ever be looking at the particular spec file or verifying it's contents and their origins, etc., and trades that in for a larger inconvenience directly upon the package maintainer, having to update the version number in 2 places constantly every time he updates the RPM package. IMHO, it isn't worth it for a package maintainer to inconvenience himself for such a small benefit to a very very small number of people out there. Additionally, it is no more difficult for the person who wants that URL, to cut and paste it in fragments to put it together, than it is for the maintainer to put the version number in 2 places. What's more, is that it could be rather easily scripted to parse the Source lines out of a spec file and reconstruct the full URLs. It might even be possible to do this by querying the specfile with the --specfile commandline switch, although I don't know what the appropriate syntax might be. Anyhow, in closing, count me in for updating my packages to do what you want, once it is a widely accepted and documented standard that is being widely adhered to by the rpm packaging populace. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From leonard at den.ottolander.nl Fri Feb 27 14:42:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 15:42:50 +0100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <200402280009.58802.russell@coker.com.au> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> <200402280009.58802.russell@coker.com.au> Message-ID: <1077892969.5315.22.camel@athlon.localdomain> Hello Russell, > If the NSA people were going to do something nasty why would they do it in > code that's got their name on it when they could send in code from > random_user at hotmail.com? Because such a large patch coming from random_user would raise some eyebrows, and small patches are not easy to hide such nasty buglets in. All it takes is a single overflow in the right location... The Trojan horse was also a "friendly gift". It's just you can't be careful enough with respect to trusting (foreign) security agencies ;-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mharris at redhat.com Fri Feb 27 14:46:10 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 09:46:10 -0500 (EST) Subject: $RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :)) In-Reply-To: <20040227142058.738f3e87.ms-nospam-0306@arcor.de> References: <20040226231944.3bc2ab21.ms-nospam-0306@arcor.de> <200402270020.14634.lowen@pari.edu> <20040227114125.67798bc6.ms-nospam-0306@arcor.de> <20040227142058.738f3e87.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Michael Schwendt wrote: >> I haven't skipped any messages. I have however formed an opinion. >> >> My opinion is that a lot of people like to argue endlessly about >> very pointless and trive details of rpm packaging, to extreme >> pedantism. > >Sorry to say that, but apparently you have misunderstood the >messages. You make it worse by pushing it into a wrong >direction. I really don't want to push it in any direction though. I'm just voicing an opinion that some of the debates people have over things are over very trivial things that don't really matter much. ;o) My own opinion may also be in that category. ;o) I myself use and prefer RPM_BUILD_ROOT over %{buildroot} due to nothing more than personal preference and years of usage. I wouldn't argue one was better than the other though. I have read jbj's mails in which he claims people should use RPM_BUILD_ROOT because he may decide to change the meaning of buildroot some day, however I don't think it's a big problem either way personally, because I know despite any such warnings, there will be a large number of packages out there anyway which would break if %{buildroot} was to get changed. A rather simple shell script can easily update such spec files some day down the road should Jeff come true on this. I'm perfectly happy with packages that use either method, despite my personal preference. Some packages even use *both*. ;o) Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ms-nospam-0306 at arcor.de Fri Feb 27 15:00:58 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 27 Feb 2004 16:00:58 +0100 Subject: OMG! I've started a war! - Was:Prelink success story :) In-Reply-To: References: <20040227022442.1cb028e8.ms-nospam-0306@arcor.de> <1077862252.12909.27.camel@chip.laiskiainen.org> <20040227121019.5fc6ee5a.ms-nospam-0306@arcor.de> Message-ID: <20040227160058.1a0b62b9.ms-nospam-0306@arcor.de> On Fri, 27 Feb 2004 15:47:16 +0200 (EET), Panu Matilainen wrote: > fedora.us policies were discussed at length (mildly put) but > that doesn't mean there isn't room for improvement, if somebody outside > current fedora.us community suggests something it shouldn't be just shot > down "because you don't care anyway". No, but everytime someone from the 3rd party people criticizes the current content in the Wiki, criticism stops at very minor things like RPM_BUILD_ROOT, explicit Epoch or disttags. > Maybe not, but being over pedantic about some artificial rules can be, for > somebody with 300 packages. If the packages work then why should the > packager tweak their specs to match some artificial rules when it already > works? Let's stop this here. It's useless to discuss virtual packages. The requirements of the fedora.us build system are different than those of an individual. Almost every submitted package (a few from 3rd party repositories included) needs fixes before it would build correctly. And *if* someone takes a deeper look, more issues are found. QA is the chance to fix them sooner than later. I stick to my offer of reviewing in teams... -- From mharris at redhat.com Fri Feb 27 15:02:09 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 10:02:09 -0500 (EST) Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077886446.4747.11.camel@athlon.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> Message-ID: On Fri, 27 Feb 2004, Leonard den Ottolander wrote: >How well scrutinized is this NSA code actually? Everybody can see they >won't slip in an obvious backdoor, but how about nasty little overflows, >tucked away deep inside the code, for which they already have exploits >in their drawer? Aside from rejecting SElinux merely due to conspiracy theories alone, what would be your suggestion to ensure that this is not the case? If you really think about it, you can apply the same conspiracy theory to the Linux kernel, XFree86, and every other piece of software in the system. There are quite a few security vulnerabilities found and fixed in OSS source code. How can you truely be sure that a given vulnerability wasn't planted there intentionally? Take the recent XFree86 security update which contains fixes for libXfont. Do we really know for sure that when Keith Packard wrote that 14 or so years ago, that he didn't intentionally put the buffer overflows in there, so that he could 0wn all machines running the X Window System 15 years later? ;o) You did upgrade X to the latest version right? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alan at redhat.com Fri Feb 27 15:14:10 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 27 Feb 2004 10:14:10 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077886446.4747.11.camel@athlon.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> Message-ID: <20040227151410.GI10772@devserv.devel.redhat.com> On Fri, Feb 27, 2004 at 01:54:06PM +0100, Leonard den Ottolander wrote: > How well scrutinized is this NSA code actually? Everybody can see they Very 8) > won't slip in an obvious backdoor, but how about nasty little overflows, > tucked away deep inside the code, for which they already have exploits > in their drawer? Occams razor suggests they just pop down to the local x86 chip manufacturers and ask them for a magic MTRR register. Several governments policy of not using US x86 processors for really critical systems lends credence. The NSA code has actually demonstrated one thing about open source very nicely - every large foreign government considering using it will have reviewed the code carefully. Without that openness nobody would trust it except the NSA From pmatilai at welho.com Fri Feb 27 15:14:20 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 27 Feb 2004 17:14:20 +0200 (EET) Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: References: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <20040227112538.087e956e.ms-nospam-0306@arcor.de> <20040227141837.4cea7e78.ms-nospam-0306@arcor.de> Message-ID: On Fri, 27 Feb 2004, Mike A. Harris wrote: > On Fri, 27 Feb 2004, Michael Schwendt wrote: > > Ok, I've snipped the entire message just to focus on the one > issue at hand. > > >> howver feel free to edit your own spec > >> files and change the version number in 10 places every time a new > > > >Why 10 places? Two places is enough. "Version:" and "Source:", > >everywhere else %{version} is fine. > > One place is enough. "Version:" [snip] > In this case, the suggestion turns a very very slight > inconvenience to someone such who rarely will ever be looking at > the particular spec file or verifying it's contents and their > origins, etc., and trades that in for a larger inconvenience > directly upon the package maintainer, having to update the > version number in 2 places constantly every time he updates the > RPM package. IMHO, it isn't worth it for a package maintainer to > inconvenience himself for such a small benefit to a very very > small number of people out there. Additionally, it is no more > difficult for the person who wants that URL, to cut and paste it > in fragments to put it together, than it is for the maintainer to > put the version number in 2 places. > > What's more, is that it could be rather easily scripted to parse > the Source lines out of a spec file and reconstruct the full > URLs. It might even be possible to do this by querying the > specfile with the --specfile commandline switch, although I don't > know what the appropriate syntax might be. Seconded. Don't make the hardworking packager make extra work, fix the tools so the macro constructs can be parsed and downloaded by QA where appropriate. The "no macros in sources" is one of my favorite love-to-hate rules in fedora.us, but one I actually do appreciate when doing QA. We need a spec parser, not more boring human work (and yes it IS easy to forget to update the source entry to match version). - Panu - From leonard at den.ottolander.nl Fri Feb 27 15:31:05 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 16:31:05 +0100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> Message-ID: <1077895865.5315.44.camel@athlon.localdomain> Hi Mike, > Aside from rejecting SElinux merely due to conspiracy theories > alone, what would be your suggestion to ensure that this is not > the case? I am not rejecting anything, just inquiring. And I am not very in to conspiracy theories, but the source of this patch is an intelligence agency, right? I have no suggestions apart from the code being minutely scrutinized by people who know how to do that. > There are quite a few security vulnerabilities found and fixed in > OSS source code. How can you truely be sure that a given > vulnerability wasn't planted there intentionally? I agree that this could be the case with any code, but in this case the source raises some suspicion. I seem to remember the CIA was involved in a coup against a democratically elected president only two years ago. Now who would have expected that in the 21st century? But I am drifting OT. > You did upgrade X to the latest version right? ;o) I was the one that somewhat prematurely polled you about it in bugzilla. (Sorry for that, it's just some developers are not as responsive and fast with releasing security updates as others. And FYI, I am currently busy downloading the xchat update. It's a pity my mirror (ftp.nluug.nl) is somewhat slow.) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jaap at haitsma.org Fri Feb 27 15:42:33 2004 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Fri, 27 Feb 2004 16:42:33 +0100 (CET) Subject: Is menu editing in GNOME enabled in Fedora Core 2? In-Reply-To: <1077877353.5573.1.camel@localhost.localdomain> References: <403E7D65.30207@haitsma.org> <1077865922.19850.33.camel@laptop> <19772.194.171.252.100.1077876980.squirrel@mail.haitsma.org> <1077877353.5573.1.camel@localhost.localdomain> Message-ID: <15689.194.171.252.100.1077896553.squirrel@mail.haitsma.org> > On Fri, 2004-02-27 at 11:16, Jaap A. Haitsma wrote: >> > On Thu, 2004-02-26 at 23:12, Jaap A. Haitsma wrote: >> >> Menu editing for GNOME has always been disabled in Fedora Core 1 and >> >> Redhat 9 because of buggy gnome code. >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81215 >> Strange that this still isn't solved. I would think that all the >> companies >> pushing the GNOME desktop as an alternative to Windows would be very >> eager >> to solve this bug. > > Maybe these companies don't want their personnel customizing their > desktops. There's a quite restrictive policy on that where I work. > > I was actually referring to companies like RedHat, Novell and Sun selling the software. It's handy to be able to disable menu editing but not be able to do it is even a pain for companies using Linux desktops. From gteale at cmedltd.com Fri Feb 27 15:47:27 2004 From: gteale at cmedltd.com (Geoff Teale) Date: Fri, 27 Feb 2004 15:47:27 +0000 Subject: Is menu editing in GNOME enabled in Fedora Core 2? In-Reply-To: <15689.194.171.252.100.1077896553.squirrel@mail.haitsma.org> References: <403E7D65.30207@haitsma.org> <1077865922.19850.33.camel@laptop> <19772.194.171.252.100.1077876980.squirrel@mail.haitsma.org> <1077877353.5573.1.camel@localhost.localdomain> <15689.194.171.252.100.1077896553.squirrel@mail.haitsma.org> Message-ID: <1077896847.25421.40.camel@dubya.devel.cmedltd.com> On Fri, 2004-02-27 at 16:42 +0100, Jaap A. Haitsma wrote: > I was actually referring to companies like RedHat, Novell and Sun selling > the software. It's handy to be able to disable menu editing but not be > able to do it is even a pain for companies using Linux desktops. To be clear - you can do it through the "Start Here->Application" folder on the desktop. This isn't immediately obvious of course - maybe the developers will read ESR's latest publication and take note. -- Geoff Teale Cmed Technology Free Software Foundation From mharris at redhat.com Fri Feb 27 15:49:43 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 27 Feb 2004 10:49:43 -0500 (EST) Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077895865.5315.44.camel@athlon.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> <1077895865.5315.44.camel@athlon.localdomain> Message-ID: On Fri, 27 Feb 2004, Leonard den Ottolander wrote: >> Aside from rejecting SElinux merely due to conspiracy theories >> alone, what would be your suggestion to ensure that this is not >> the case? > >I am not rejecting anything, just inquiring. And I am not very in to >conspiracy theories, but the source of this patch is an intelligence >agency, right? Right. >I have no suggestions apart from the code being minutely scrutinized by >people who know how to do that. It's been scrutinized fairly heavily from what I understand. One of the beautiful things about open source is that anyone can scrutinize the source, so it is much more likely to have any security holes found and fixed in it. That's irrespective of wether they would be planted or accidental of course. >> You did upgrade X to the latest version right? ;o) > >I was the one that somewhat prematurely polled you about it in >bugzilla. (Sorry for that, it's just some developers are not as >responsive and fast with releasing security updates as others. No problem at all. It's always a good thing when people report security vulnerabilities to us, even if we're aware of them already, because an external person doesn't necessarily have a way to pre-determine wether we're aware of a given issue yet or not. Also, if it is public, and we've not released erratum yet, it's to be expected that someone is likely to report the issue to us, and that's always welcome too. ;o) Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From riel at redhat.com Fri Feb 27 15:59:31 2004 From: riel at redhat.com (Rik van Riel) Date: Fri, 27 Feb 2004 10:59:31 -0500 (EST) Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077886446.4747.11.camel@athlon.localdomain> Message-ID: On Fri, 27 Feb 2004, Leonard den Ottolander wrote: > How well scrutinized is this NSA code actually? Everybody can see they > won't slip in an obvious backdoor, but how about nasty little overflows, > tucked away deep inside the code, for which they already have exploits > in their drawer? I think your tinfoil hat has a government back-door ;) But seriously, the selinux code that's in the kernel now looks completely differently from the original code a few years ago. Every bit of the code has been looked at by many people and changed a number of times until it was acceptable to the upstream kernel developers. Also, because selinux was (partially) written by the NSA I expect the code to be scrutinised more than any other code in the kernel... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From leonard at den.ottolander.nl Fri Feb 27 16:07:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 17:07:09 +0100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227151410.GI10772@devserv.devel.redhat.com> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> <20040227151410.GI10772@devserv.devel.redhat.com> Message-ID: <1077898029.5315.47.camel@athlon.localdomain> Hi Alan, > Occams razor suggests they just pop down to the local x86 chip manufacturers > and ask them for a magic MTRR register. Several governments policy of not > using US x86 processors for really critical systems lends credence. Not entirely sure how that would work, but I seem to remember a C'T article about remotely reenabling the CPU-ID on Pentiums. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Fri Feb 27 16:34:57 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 17:34:57 +0100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: References: Message-ID: <1077899697.5315.52.camel@athlon.localdomain> Hi Rick, > I think your tinfoil hat has a government back-door ;) Nah. It's made in Holland, so I don't have to worry about that. It's more likely the Mossad is listening in on my telephone calls, thanks to the Dutch government. You know what they are like when it comes to sensitive technology/information. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Fri Feb 27 16:36:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 17:36:06 +0100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: References: Message-ID: <1077899766.5315.54.camel@athlon.localdomain> Rik. Sorry for that. I seem to have some problems with cs and ks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From skvidal at phy.duke.edu Fri Feb 27 16:41:05 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 27 Feb 2004 11:41:05 -0500 Subject: latest update In-Reply-To: <1077870421.19850.44.camel@laptop> References: <1077866756.19850.39.camel@laptop> <1077867392.15891.4.camel@binkley> <1077870421.19850.44.camel@laptop> Message-ID: <1077900065.15891.14.camel@binkley> > I'm just curious, though. If the standard practice to work around such > problems is for people to do --exclude=broken-package, why couldn't we > not have a --exclude-broken-packages flag? b/c you won't know it's broken until after you try to get it. Also b/c it's not always obvious which package it is that's broken in the case. Often times you'll see an error about foo not being available when it is really that bar is broken. So do I exclude bar or foo or both - and when that causes a cascade? -sv From sopwith at redhat.com Fri Feb 27 17:21:09 2004 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 27 Feb 2004 12:21:09 -0500 (EST) Subject: How to help with SELinux Message-ID: Since FC2t2 was just delayed due to SELinux, no doubt you're wondering "How do I help with SELinux hacking so I can get my hands on test2?" The simplest way is to install from rawhide, use the system in as many ways as you can, and file bug reports against the 'policy' package for any 'avc: denied' messages that show up in the system logs. Please make sure to check that the bug hasn't already been filed. Try to include all the information on the problem: The 'avc: denied' messages themselves. How to reproduce them: Which program to run or actions to take What environment to reproduce in - root login or regular user login, su session, sudo session, graphical or text environment, etc. Whether SELinux in enforcing mode What file system type (ext3, NFS) might be involved in the bug Whether or not you have rebooted since last upgrading your policy package. What version of the policy package you have installed ('rpm -q policy') If you want to go beyond just reporting problems, an even better thing to do is to write policy to fix the problems you find, and then submit the policy changes. There are tons of things we have never tried and are almost guaranteed to blow up. If we have to write policy for all of them, it will take a very long time. The audit2allow utility (part of the policycoreutils package) may be useful here. If you want to know more about SELinux and writing policies for it, you can visit http://www.tresys.com/selinux/selinux-course-outline.html Another tack to take when writing policies is to look at existing policies for similar programs. For example, if you're writing a policy for rshd, the policy for sshd might make a good start. (Kudos to Dan Walsh for all the content here) -- Elliot From sds at epoch.ncsc.mil Fri Feb 27 17:42:57 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 27 Feb 2004 12:42:57 -0500 Subject: How to help with SELinux In-Reply-To: References: Message-ID: <1077903777.26543.61.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-02-27 at 12:21, Elliot Lee wrote: > If you want to know more about SELinux and writing policies for it, you > can visit http://www.tresys.com/selinux/selinux-course-outline.html > Another tack to take when writing policies is to look at existing policies > for similar programs. For example, if you're writing a policy for rshd, > the policy for sshd might make a good start. I'd also suggest the report available in PDF, PS, or HTML from http://www.nsa.gov/selinux/papers/policy2-abs.cfm. It isn't entirely up-to-date, but should still be helpful. We'll be including it (with the DocBook SGML sources) in selinux-doc in the future. There are also other papers and reports available from http://www.nsa.gov/selinux/docs.cfm. -- Stephen Smalley National Security Agency From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 27 18:11:22 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Feb 2004 19:11:22 +0100 Subject: Prelink success story :) In-Reply-To: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> References: <20040225205820.GN31589@devserv.devel.redhat.com> <20040226111126.4e955b25.ms-nospam-0306@arcor.de> Message-ID: <20040227191122.0dc58bfd@localhost> Michael Schwendt wrote : > In case this targets the fedora.us guidelines, they are due to the > following comment from Jeff Johnson (see quoted part at the bottom), > > http://www.fedora.us/pipermail/fedora-devel/2003-April/001155.html > > who maybe was taken more serious than necessary. Though, if %buildroot > were eliminated "without warning" actually, those who build rpms as root > would have fun with the outcome. I can't believe something like that might > be done, considering that most (all?) of the packages in Fedora Core use > %buildroot. Indeed, I think this reply by Jeff has been the most quoted rpm-related post of all times. Now just think for 2 seconds. What was the last thing anyone can think of that got deprecated and removed from rpm over the past year? Sure, the split off of rpmbuild could be considered one, but there are real technical considerations behind it (having to maintain all those ugly popt rewrites). What I mean is that something "simple" and "widely used" as well as "documented" in rpm can safely be considered something that can be used. Sure, if it's clearly a side-effect or a bug being (ab)used as a feature, then it's another story, but if it's an rpm macro vs. a shell variable with the exact same content, then we're just splitting hairs. Back to the %{buildroot} vs. $RPM_BUILD_ROOT issue : I'm not in a position to enforce the usage of one over the other on anyone, and even if I were, I just wouldn't. Heck, go for the one you think is more readable, consistent, short, long, lowercase, uppercase, fun, fancy, blue, w4rL0rDz... who cares? Well, not me. This was my last word on the subject, ever. Want to quote me? I'd prefer not, as it would mean the issue is being raised again, and again, and again, and again... > Basically, currently it _does not matter_ whether you use %buildroot or > $RPM_BUILD_ROOT because neither one is deprecated. Just don't use both at > once. Now, we're getting somewhere... What the world needs even more than organization is a little more common sense. (sorry if there's already been "prior art" on this one) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.18 0.22 0.26 From jamesaharrisonuk at yahoo.co.uk Fri Feb 27 18:19:13 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 27 Feb 2004 10:19:13 -0800 (PST) Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227025751.GF29689@devserv.devel.redhat.com> Message-ID: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> Hi, Can we have two kernels - one with SELinux and one without. Anaconda should install it by default, but there should be an option to not install SELinux. Its up to the user how secure he/she wants to make their systems. I read the wonderful news article about SELinux and how the NSA have inserted their "security" code into Linux, but I cant see any technical detail. Maybe if someone were to explain what they actually did then I might change my mind or point me in the right direction. Thanks James --- Bill Nottingham wrote: > We're encountering various issues that are causing us to delay > the release of test2. We'd like to get as much exposure to SELinux > as possible, and this means shipping test2 with SELinux in > enforcing mode. However, there are still some subsystems that > aren't quite ready for this, so we need to slide the release > date some. > > The *current* projection is that the freeze will be on March 12, > for availability on March 22. This date is only preliminary at > this point, and may change. The schedule at: > > http://fedora.redhat.com/participate/schedule/ > > will be updated shortly. > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools From sds at epoch.ncsc.mil Fri Feb 27 18:25:46 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 27 Feb 2004 13:25:46 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> Message-ID: <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-02-27 at 13:19, James Harrison wrote: > Can we have two kernels - one with SELinux and one without. Boot with selinux=0, and the SELinux code is disabled. > Anaconda should install it by default, but there should be an option to not > install SELinux. > > Its up to the user how secure he/she wants to make their systems. > > I read the wonderful news article about SELinux and how the NSA have inserted > their "security" code into Linux, but I cant see any technical detail. > > Maybe if someone were to explain what they actually did then I might change my > mind or point me in the right direction. http://www.nsa.gov/selinux. Technical reports and published papers available under http://www.nsa.gov/selinux/docs.cfm. -- Stephen Smalley National Security Agency From leonard at den.ottolander.nl Fri Feb 27 18:31:35 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Feb 2004 19:31:35 +0100 Subject: Announce: Updated Speedtouch rpm Message-ID: <1077906695.5315.84.camel@athlon.localdomain> Hi, A new speedtouch rpm for use with Red Hat 9 and Fedora Core 1 is available at http://www.ottolander.nl/opensource/speedtouch/speedtouch.html . This version is built from CVS (2004/02/20) and should work with the silver 330 rev.4 version of the modem. Binaries are built on RH9 but should probably be usable on Fedora Core 1 as well. On FC1 you probably want to use the kernel mode driver anyway, but you can probably use the modem_run binary from the RH9 rpm. If not, rebuild from the source rpm (and notify me). Please report any issues you are having to speedtouch at ml.free.fr (subscribe via http://speedtouch.sourceforge.net/index.php/contacts.html). Don't forget to concatenate the two firmware parts when using this version. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From thomas at apestaart.org Fri Feb 27 18:38:16 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 27 Feb 2004 19:38:16 +0100 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <1077858145.4875.333.camel@Madison.badger.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> Message-ID: <1077907096.5196.25.camel@otto.amantes> Hi, > > 5. Are there no missing BuildRequires? > > > I agree that this can be basically impossible as it now stands. I first > tried fedora-rmdevelrpms but that made my machine close to unusable as a > development environment (to QA or program.. Hmmmm...) I agree, fedora-rmdevelrpms was a broken concept right from the start. > I've been trying to get mach to work, but I seem to run from problem to > problem with the damn thing. There should definitely be a fedora-mach > HOWTO/FAQ/IRC forum.... The README of mach serves as a quite ok HOWTO for a first encounter. There's no FAQ because nobody asks me questions :) As for irc, #fedora-devel ? I'm there all the time. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you want love we'll make it <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 27 18:43:20 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Feb 2004 19:43:20 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: References: <20040226111126.4e955b25.ms-nospam-0306@arcor.de> <1077811141.8186.23.camel@chip.laiskiainen.org> <1077814511.6550.23.camel@bobcat.mine.nu> <1077819807.4875.29.camel@Madison.badger.com> <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <1077849223.4875.193.camel@Madison.badger.com> <20040227112714.694ffffa.ms-nospam-0306@arcor.de> Message-ID: <20040227194320.5c4a9347@localhost> Panu Matilainen wrote : > On Fri, 27 Feb 2004, Michael Schwendt wrote: > > > On Thu, 26 Feb 2004 21:33:49 -0500, Toshio wrote: > > > > > On Thu, 2004-02-26 at 20:30, Michael Schwendt wrote: > > > > Is an URL which contains macros still an URL? What do you do with an URL > > > > that contains macros? You can't cut'n'paste it into a browser, because it > > > > contains macros. So why include protocol, hostname and path in Source > > > > fields at all? How does the packager fetch a new release? Does he visit > > > > the web page from bookmarks? Or does he reconstruct a valid URL from > > > > the macros? > > > > > > > Thanks, Michael, that's a great explanation. > > > > > > I've got a new scenario to ask about: do any of the autobuilders the > > > Fedora Project is going to use depend on being able to parse the Source: > > > line into a URL? > > > > I doubt that. > > IIRC mach can parse Source and Patch entries (even in presence of macros), > fetch what's needed and build based on that. Actually if those entries > aren't URL's it's going to fail, unless you use rebuild (to rebuild from > existing src.rpm) Let me add on this one. Yes, mach parses source and patch tags, expands them and searches the current directory for a matching file name, then searches for an already downloaded file in the chroot, and if none are found, tries to download the file. This is a feature Thomas (mach's author) implemented upon my suggestion. It makes things ("IMHO" required here, these threads about who is right or wrong when no one is either are getting boring) very easy, readable and quickly maintainable. Yes, I just update the version in the version tag when a new release is out, then launch a build, and finally inspect things. It can be as simple as that. My personal taste is to actually like tags like these : Source: http://dl.sf.net/projectname/%{name}-%{version}.tar.gz Of course, YTMV(*), and that's perfectly normal. Matthias * YTMV : Your Taste May Vary -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.09 0.19 0.22 From ellson at research.att.com Fri Feb 27 18:56:25 2004 From: ellson at research.att.com (John Ellson) Date: Fri, 27 Feb 2004 13:56:25 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <403F92D9.3010302@research.att.com> Stephen Smalley wrote: >On Fri, 2004-02-27 at 13:19, James Harrison wrote: > > >>Can we have two kernels - one with SELinux and one without. >> >> > >Boot with selinux=0, and the SELinux code is disabled. > > [as he rudely jumps in with a different question....] Booting with selinux=0 is working well for me. Are there any special steps to be taken when removing selinux=0, i.e. when I'm ready to try selinux again? There are some unreadable instructions that scroll by in boot messages to the console, then disappear with the login prompt, that I fear might be telling me something important??? John From jamesaharrisonuk at yahoo.co.uk Fri Feb 27 19:03:48 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 27 Feb 2004 11:03:48 -0800 (PST) Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <403F92D9.3010302@research.att.com> Message-ID: <20040227190348.92453.qmail@web25102.mail.ukl.yahoo.com> > >Boot with selinux=0, and the SELinux code is disabled. That dont cut it for me. Two distinct kernels one with SELinux and one without. >that I fear might be > telling me something important??? what about running: dmesg | more Is it there? --- John Ellson wrote: > Stephen Smalley wrote: > > >On Fri, 2004-02-27 at 13:19, James Harrison wrote: > > > > > >>Can we have two kernels - one with SELinux and one without. > >> > >> > > > >Boot with selinux=0, and the SELinux code is disabled. > > > > > > [as he rudely jumps in with a different question....] > > Booting with selinux=0 is working well for me. > > Are there any special steps to be taken when removing selinux=0, i.e. when > I'm ready to try selinux again? > > There are some unreadable instructions that scroll by in boot messages > to the console, then disappear with the login prompt, that I fear might be > telling me something important??? > > John > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list ===== James Harrison __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools From alan at redhat.com Fri Feb 27 19:10:50 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 27 Feb 2004 14:10:50 -0500 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227194320.5c4a9347@localhost> References: <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <1077849223.4875.193.camel@Madison.badger.com> <20040227112714.694ffffa.ms-nospam-0306@arcor.de> <20040227194320.5c4a9347@localhost> Message-ID: <20040227191050.GA14097@devserv.devel.redhat.com> On Fri, Feb 27, 2004 at 07:43:20PM +0100, Matthias Saou wrote: > Yes, mach parses source and patch tags, expands them and searches the > current directory for a matching file name, then searches for an already > downloaded file in the chroot, and if none are found, tries to download > the file. Has mach added an sha sum to the source spec file so that the download is known to be correct, otherwise this seems slightly umm dangerous ? From notting at redhat.com Fri Feb 27 19:15:54 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Feb 2004 14:15:54 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227190348.92453.qmail@web25102.mail.ukl.yahoo.com> References: <403F92D9.3010302@research.att.com> <20040227190348.92453.qmail@web25102.mail.ukl.yahoo.com> Message-ID: <20040227191554.GH22139@devserv.devel.redhat.com> James Harrison (jamesaharrisonuk at yahoo.co.uk) said: > > >Boot with selinux=0, and the SELinux code is disabled. > That dont cut it for me. Two distinct kernels one with SELinux and one > without. No, that's an unmaintainable situation, aside from the bloat it introduces into the OS. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 27 19:19:39 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Feb 2004 20:19:39 +0100 Subject: Using mach (was: Re: Fedora.us QA (was: Re: Prelink success story :))) In-Reply-To: <1077907096.5196.25.camel@otto.amantes> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> <1077907096.5196.25.camel@otto.amantes> Message-ID: <20040227201939.4d0a9200@localhost> Thomas Vander Stichele wrote : > > I've been trying to get mach to work, but I seem to run from problem to > > problem with the damn thing. There should definitely be a fedora-mach > > HOWTO/FAQ/IRC forum.... > > The README of mach serves as a quite ok HOWTO for a first encounter. > There's no FAQ because nobody asks me questions :) As for irc, > #fedora-devel ? I'm there all the time. Nobody asks you questions? I did, and I must say that they usually ended in new features being added, which is simply perfect from my stand point :-) Today, mach does all I expect, and clearly became my most used tool after rpm, as _all_ current freshrpms.net packages, may it be for Fedora Core or Yellow Dog Linux, are built using it. I can only advise rpm packagers to give it a try, poke Thomas with ideas, discuss missing features on the (quite silent) mailing-list, submit patches... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.39 0.18 0.11 From sds at epoch.ncsc.mil Fri Feb 27 19:25:17 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 27 Feb 2004 14:25:17 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <403F92D9.3010302@research.att.com> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> <403F92D9.3010302@research.att.com> Message-ID: <1077909915.26543.103.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-02-27 at 13:56, John Ellson wrote: > Booting with selinux=0 is working well for me. > > Are there any special steps to be taken when removing selinux=0, i.e. when > I'm ready to try selinux again? You'll need to relabel your filesystems. Install policy-sources, cd /etc/security/selinux/src/policy && make relabel. Not sure about the corresponding rpm file contexts state. > There are some unreadable instructions that scroll by in boot messages > to the console, then disappear with the login prompt, that I fear might be > telling me something important??? dmesg is your friend. -- Stephen Smalley National Security Agency From jspaleta at princeton.edu Fri Feb 27 19:26:12 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 27 Feb 2004 14:26:12 -0500 Subject: Fedora Core 2 Test 2 - delayed Message-ID: <1077909971.9330.28.camel@spatula.pppl.gov> James Harrison wrote: > That dont cut it for me. Two distinct kernels one with SELinux > and one without. Then i suggest you build your own custom kernel 2.4.x kernel. The momentum upstream is against you. I also suggest you become more actively involved with following all relevant kernel development communication channels while development decisions like this are on-going...instead of trying to second guess them after the fact. Oh and by the way...everyone is out to get you...don't doubt it for a second. -jef"is rotating jamming frequencies profiles on his rf spectrum broadband whitenoise helmet based on a quantum interference randomization algorithm to keep the thought control rays out"spaleta From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 27 19:31:53 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Feb 2004 20:31:53 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227113321.3e86433c.ms-nospam-0306@arcor.de> References: <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <200402262336.13553.lowen@pari.edu> <20040227113321.3e86433c.ms-nospam-0306@arcor.de> Message-ID: <20040227203153.031905d0@localhost> Michael Schwendt wrote : > All that has been pointed out is that reviewers appreciate ready-to-use > URLs, which they can cut'n'paste into console or browser to fetch a > tarball from upstream. It has been pointed out that some packagers > tend to obfuscate URLs with macros to a degree that is far from smart, > e.g. > > Source0: http://foo.bar/%{name}/%{version}/%{name}-%{version}rc1.tar.gz > > and that is bad taste and bad style. Or it turns out, the URL hasn't been > updated or verified in a longer time and is not true anymore. I get the point for the reviewers, but have to disagree about "far from smart" as well as "bad taste" and "bad style". RPM building is architectured around macros and macro expansions, and I find it to be what gives the real interest in creating spec files, then RPM packages. Take out the "rc1" from the above URL, and I find it to be very smart, plain taste (well, what do you expect, we're dealing with computers here) and typical spec file style. Oh, yes, I have some of those. Why? I just change the version tag above when i know a new version is available, and don't even need to go get the source file manually with an http or ftp client, not even a single copy/paste is required. And as an extra added goody, I get to be sure the URL is still correct (see my previous email about mach). Of course, YTMV(*), and that's perfectly normal. Matthias * YTMV : Well, see previous mail too :-) -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.17 0.21 0.14 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 27 20:07:08 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Feb 2004 21:07:08 +0100 Subject: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227191050.GA14097@devserv.devel.redhat.com> References: <1077822786.4875.51.camel@Madison.badger.com> <1077837899.4875.163.camel@Madison.badger.com> <20040227012002.3283ea75.ms-nospam-0306@arcor.de> <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <1077849223.4875.193.camel@Madison.badger.com> <20040227112714.694ffffa.ms-nospam-0306@arcor.de> <20040227194320.5c4a9347@localhost> <20040227191050.GA14097@devserv.devel.redhat.com> Message-ID: <20040227210708.34f13446@localhost> Alan Cox wrote : > On Fri, Feb 27, 2004 at 07:43:20PM +0100, Matthias Saou wrote: > > Yes, mach parses source and patch tags, expands them and searches the > > current directory for a matching file name, then searches for an already > > downloaded file in the chroot, and if none are found, tries to download > > the file. > > Has mach added an sha sum to the source spec file so that the download > is known to be correct, otherwise this seems slightly umm dangerous ? One could add that inside the spec file after checking. But my point here was that copy/pasting a source tag to download it (i.e. with wget) was even more complicated than what mach is able to do. Now, in any case, if one wants checking to be done, it needs to be done "manually" with some reviewing, or something specific needs to be set up, for example checking the signature of the downloaded tarball from an asc file against a trusted key. Although this is important, it's beyond the point I was trying to make ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.96 0.97 0.74 From ellson at research.att.com Fri Feb 27 20:34:48 2004 From: ellson at research.att.com (John Ellson) Date: Fri, 27 Feb 2004 15:34:48 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077909915.26543.103.camel@moss-spartans.epoch.ncsc.mil> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> <403F92D9.3010302@research.att.com> <1077909915.26543.103.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <403FA9E8.1040804@research.att.com> Stephen Smalley wrote: >On Fri, 2004-02-27 at 13:56, John Ellson wrote: > > >>Booting with selinux=0 is working well for me. >> >>Are there any special steps to be taken when removing selinux=0, i.e. when >>I'm ready to try selinux again? >> >> > >You'll need to relabel your filesystems. Install policy-sources, cd >/etc/security/selinux/src/policy && make relabel. Not sure about the >corresponding rpm file contexts state. > > Thanks for your reponse. Do I do that before or after rebooting with selinux enabled? If after, do I log in as a conventional root user, or do I need a different login procedure? What are "corresponding rpm file contexts state" ? What should I look for? > > >>There are some unreadable instructions that scroll by in boot messages >>to the console, then disappear with the login prompt, that I fear might be >>telling me something important??? >> >> > >dmesg is your friend. > > > I know about dmesg, but these messages are not recorded in dmesg, nor in /var/log/messages. John From davej at redhat.com Fri Feb 27 20:33:45 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 27 Feb 2004 20:33:45 +0000 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227190348.92453.qmail@web25102.mail.ukl.yahoo.com> References: <20040227190348.92453.qmail@web25102.mail.ukl.yahoo.com> Message-ID: <1077914025.32216.12.camel@delerium.codemonkey.org.uk> On Fri, 2004-02-27 at 19:03, James Harrison wrote: > > >Boot with selinux=0, and the SELinux code is disabled. > That dont cut it for me. Two distinct kernels one with SELinux and one > without. Nothing stopping you maintaining such a kernel yourself, and providing it to the world through a yum repo for other folks similarly paranoid. But *gasp*, what if the evil NSA code still runs if you disable the kernel config option? Oh wait, you can review the code to find out this, just as you can to also disprove any other delusions you may have about backdoors and such. Honestly, this code has been scrutinised every step of the way to inclusion. Before it went into mainline kernel it was looked over by many kernel folks just to get it into a state where it was acceptable. Then it got further review when it was ready for inclusion. Then it got more review when the commits when by the kernel commits mailing list. Bringing us right up to date, there's folks hammering on this code from multiple distro vendors trying to get bugs out in 2.6. If there was anything sinister in there, don't you think it would have been found by now ? Dave From skvidal at phy.duke.edu Fri Feb 27 20:39:39 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 27 Feb 2004 15:39:39 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077914025.32216.12.camel@delerium.codemonkey.org.uk> References: <20040227190348.92453.qmail@web25102.mail.ukl.yahoo.com> <1077914025.32216.12.camel@delerium.codemonkey.org.uk> Message-ID: <1077914379.6408.2.camel@opus> > If there was anything sinister in there, don't you think it would have > been found by now ? Unless you're ALL involved!!! /me hears maniacal laughter receding into the darkness. -sv From hvdkooij at vanderkooij.org Fri Feb 27 20:49:24 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Fri, 27 Feb 2004 21:49:24 +0100 (CET) Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077892969.5315.22.camel@athlon.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> <200402280009.58802.russell@coker.com.au> <1077892969.5315.22.camel@athlon.localdomain> Message-ID: On Fri, 27 Feb 2004, Leonard den Ottolander wrote: > Because such a large patch coming from random_user would raise some > eyebrows, and small patches are not easy to hide such nasty buglets in. > All it takes is a single overflow in the right location... The Trojan > horse was also a "friendly gift". For purposes of historical accuracy. The trojan horse was a part of the spoils of war. Much like that booby trap under a left helmet on the WW2 batlefield. I have seen some amzing gifts during my work at various network locations. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From sds at epoch.ncsc.mil Fri Feb 27 20:49:55 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 27 Feb 2004 15:49:55 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <403FA9E8.1040804@research.att.com> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> <403F92D9.3010302@research.att.com> <1077909915.26543.103.camel@moss-spartans.epoch.ncsc.mil> <403FA9E8.1040804@research.att.com> Message-ID: <1077914995.26543.127.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-02-27 at 15:34, John Ellson wrote: > Do I do that before or after rebooting with selinux enabled? It should work even with selinux=0, as the xattr handlers will still be present in the kernel. The only issue is that a file might get left unlabeled if it is created after the 'make relabel' would have touched it but before you've rebooted with selinux enabled, e.g. files that get created on shutdown. I think that Dan may have plans to catch common cases of that situation using restorecon in init scripts, but I'm not sure. > If after, do I log in as a conventional root user, or do I need a > different login procedure? You'll also need to be in the sysadm_r role. Login should prompt you for a context, and you can also login as a regular user and then su as usual (su should also prompt for a context). > What are "corresponding rpm file contexts state" ? What should I > look for? rpm is now aware of file security contexts, so I'm not sure if the rpm database needs to be rebuilt if you run with selinux=0 for a while (and install some rpms on that non-SELinux system) and then later enable SELinux. Jeff? -- Stephen Smalley National Security Agency From russell at coker.com.au Fri Feb 27 21:39:56 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 28 Feb 2004 08:39:56 +1100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200402280839.56912.russell@coker.com.au> On Sat, 28 Feb 2004 05:25, Stephen Smalley wrote: > On Fri, 2004-02-27 at 13:19, James Harrison wrote: > > Can we have two kernels - one with SELinux and one without. > > Boot with selinux=0, and the SELinux code is disabled. Also note that the selinux=0 code was written by James Morris not the NSA. ;) On Sat, 28 Feb 2004 05:19, James Harrison wrote: > I read the wonderful news article about SELinux and how the NSA have > inserted their "security" code into Linux, but I cant see any technical > detail. SE Linux implements the "domain type" security model. Every object that can be accessed by a process (dir, file, socket, etc) has a type. Every process has a domain. You have a database of rules specifying which domains can access each type loaded by the kernel. When any access is requested first standard Unix checks are performed (IE UID/GID etc), then after those checks are passed SE Linux checks are performed. If the Unix checks deny an operation then the core SE Linux code will never even see it. There is talk of making changes to this at some future time, however the impression is that the main kernel people don't like such ideas. Also the current operation is good for the time when SE Linux is becoming popular. Lots of people can be expected to stuff up their policy, and with the current setup they can't make things any less secure than a regular Linux system. The domain that a process runs in can be determined by the type of the executable (EG /sbin/init has type init_exec_t and when kernel_t exec's it the domain transitions to init_t). The domain can also be specified by the process calling exec (so that /bin/login and sshd can specify the correct context for a shell). There is a lot more than that, roles, identities, constraints, assertions, and MLS (which we have no immediate plans to put in Fedora). But when you first start using SE Linux you don't have to worry too much about that. On Sat, 28 Feb 2004 02:49, "Mike A. Harris" wrote: > It's been scrutinized fairly heavily from what I understand. ?One > of the beautiful things about open source is that anyone can > scrutinize the source, so it is much more likely to have any > security holes found and fixed in it. ?That's irrespective of > wether they would be planted or accidental of course. I know several people who have read through all the SE Linux kernel code and looked for bugs/trojans/etc. Last time I spoke to them about such issues none of them were willing to publically announce this. Claiming to be good enough at kernel coding to find any back-doors written by experts would be a significant boast. But I think that having a number of people look through the code gives a good degree of assurance, maybe one or two people might miss a bug, but someone would find it. Finally, there are lots of people who are trying to make a career in computer security by finding vulnerabilities. If they could find a bug in SE Linux (either deliberate or accidental) then they would become quite famous very quickly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From ellson at research.att.com Fri Feb 27 21:56:15 2004 From: ellson at research.att.com (John Ellson) Date: Fri, 27 Feb 2004 16:56:15 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077914995.26543.127.camel@moss-spartans.epoch.ncsc.mil> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077906346.26543.85.camel@moss-spartans.epoch.ncsc.mil> <403F92D9.3010302@research.att.com> <1077909915.26543.103.camel@moss-spartans.epoch.ncsc.mil> <403FA9E8.1040804@research.att.com> <1077914995.26543.127.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <403FBCFF.1080508@research.att.com> Stephen Smalley wrote: >On Fri, 2004-02-27 at 15:34, John Ellson wrote: > > >>Do I do that before or after rebooting with selinux enabled? >> >> > >It should work even with selinux=0, as the xattr handlers will still be >present in the kernel. The only issue is that a file might get left >unlabeled if it is created after the 'make relabel' would have touched >it but before you've rebooted with selinux enabled, e.g. files that get >created on shutdown. I think that Dan may have plans to catch common >cases of that situation using restorecon in init scripts, but I'm not >sure. > > > OK. A progress indicator and/or a warning that "make relabel" takes a long long time would be nice! Also a warning that nothing else works while it is running would be good. (I tried to fire up another gnome-terminal, but nothing happened. ) >>If after, do I log in as a conventional root user, or do I need a >>different login procedure? >> >> > >You'll also need to be in the sysadm_r role. Login should prompt you >for a context, and you can also login as a regular user and then su as >usual (su should also prompt for a context). > > So I ran "make relabel" with selinux=0, and then immediately rebooted with selinux=1 There are thousands of "avc denied" messages in /var/log/message. Should I be worried? gdm didn't prompt me for any role information for my regular userid. Running "su -" in a gnome terminal got me to root also without any request for role information. Is this right for the default Fedora config, or is something not working? Logging in as root from a text console did offer an opportunity to select a different role, but it allowed me to accept a default. John From russell at coker.com.au Fri Feb 27 22:20:42 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 28 Feb 2004 09:20:42 +1100 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <403FBCFF.1080508@research.att.com> References: <20040227181913.8664.qmail@web25110.mail.ukl.yahoo.com> <1077914995.26543.127.camel@moss-spartans.epoch.ncsc.mil> <403FBCFF.1080508@research.att.com> Message-ID: <200402280920.42333.russell@coker.com.au> On Sat, 28 Feb 2004 08:56, John Ellson wrote: > So I ran "make relabel" with selinux=0, and then immediately rebooted > with selinux=1 > > There are thousands of "avc denied" messages in /var/log/message. > Should I be worried? No, but send me a copy of the messages and I'll help you fix any configuration problems you may have, or write policy to support what you are trying to do. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From walters at verbum.org Fri Feb 27 22:38:48 2004 From: walters at verbum.org (Colin Walters) Date: Fri, 27 Feb 2004 17:38:48 -0500 Subject: Buglet list from FC2t1 In-Reply-To: <403BAA0D.4050003@home.se> References: <403BAA0D.4050003@home.se> Message-ID: <1077921528.29763.29.camel@nexus.verbum.private> On Tue, 2004-02-24 at 14:46, Peter Backlund wrote: > - Rhythmbox opens mp3 by default, but has no license problem dialogue. * committed rhythmbox-devel at gnome.org--2004/rhythmbox--main--0.6--patch-21 I solved this in the 0.6 branch by simply not advertising the audio/x-mp3 MIME type in rhythmbox.applications if it was compiled without MP3 support. Solving it in 0.7 is harder, because we use GStreamer to dynamically load and play files. So as soon as you install say a GStreamer mp3 plugin, you get Rhythmbox support for it. But as far as I can see, bthe gnome-vfs .applications framework is entirely static. There's no way for Rhythmbox to start advertising e.g. audio/x-mp3 support only if you have the GStreamer plugin. It's a very messy layer-crossing problem. A start at solving it correctly might be to have an application include in its .applications: mime_types_dynamic=rhythmbox --list-mime-types This would generate the keys at runtime, and then we'd need a program to go through all the applications and cache the output of the dynamic mime types listings. But even then it's difficult to implement --list-mime-types in Rhythmbox, because 1) GStreamer presently has no way to enumerate which audio MIME types it supports 2) GStreamer MIME types and GNOME MIME types may not necessarily correspond Yeah, it's a messy problem...ideas welcome! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Fri Feb 27 23:24:59 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 28 Feb 2004 00:24:59 +0100 Subject: Let us please all stop the whining, was: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <20040227203153.031905d0@localhost> References: <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <200402262336.13553.lowen@pari.edu> <20040227113321.3e86433c.ms-nospam-0306@arcor.de> <20040227203153.031905d0@localhost> Message-ID: <1077924298.31846.10.camel@wombat.tiptoe.de> Now that I have your attention, to put an end to this discussion I have coded a small perl script which is able to download or (human-legibly) list the sources and patches in a spec file, even if they contain macros, well even if they're conditionalized beyond all recognition. It does this by using RPM for the parsing of the macros etc. and so should be able to cope with most spec files. Options (which unfortunately aren't listed by the script): -l|--list: only list expanded sources/patches -D|--dummy: don't retrieve stuff, just do as if (for testing) -d|--define: to define macros just like with RPM (use as often as you want to) -v|--verbose: increase verbosity level, useful with --dummy It accepts as arguments: - the spec file - optionally what to list/retrieve: "sources", "patches", "all", "source0", "patch5", you get the idea. Good night, 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: rpm-retrieve.pl Type: text/x-perl Size: 3180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kir at darnet.ru Fri Feb 27 23:44:59 2004 From: kir at darnet.ru (Kir Kolyshkin) Date: Sat, 28 Feb 2004 02:44:59 +0300 Subject: Let us please all stop the whining, was: Macros in Source fields (was: Re: Prelink success story :)) In-Reply-To: <1077924298.31846.10.camel@wombat.tiptoe.de> References: <1077844839.4875.174.camel@Madison.badger.com> <20040227023043.15f11272.ms-nospam-0306@arcor.de> <200402262336.13553.lowen@pari.edu> <20040227113321.3e86433c.ms-nospam-0306@arcor.de> <20040227203153.031905d0@localhost> <1077924298.31846.10.camel@wombat.tiptoe.de> Message-ID: <403FD67B.6080907@darnet.ru> Actually I thought that something like rpm -q --queryformat "%{SOURCE}\n" --specfile path/to/specfile.spec will do the job, but it seems that doesn't work. Nils Philippsen wrote: >Now that I have your attention, > >to put an end to this discussion I have coded a small perl script which >is able to download or (human-legibly) list the sources and patches in a >spec file, even if they contain macros, well even if they're >conditionalized beyond all recognition. It does this by using RPM for >the parsing of the macros etc. and so should be able to cope with most >spec files. > > From ville.skytta at iki.fi Fri Feb 27 23:53:40 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 28 Feb 2004 01:53:40 +0200 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CD948@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD948@smith.interlink.local> Message-ID: <1077926020.6550.119.camel@bobcat.mine.nu> On Fri, 2004-02-27 at 05:03, Erik LaBianca wrote: > > "mach" is not mandatory. I've tried it once, long ago. Use what works > for > > you. It can be embarrassing if an approved package fails in the build > > system. > > Ok so it's not mandatory but it seems the sanest way to check > buildrequires. Is it used for the fedora.us buildsystem or not? Yes. And no :) A patched version of mach is a part of that beast, documentation, patches etc about the current system are at http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/ > It > doesn't make much sense to me for packages to pass QA that can't be > built properly on the build system. As pointed out elsewhere, fedora-rmdevelrpms from the fedora-rpmdevtools package does a fairly good job (from the QA POV, not necessarily otherwise) as well. From pros-n-cons at bak.rr.com Sat Feb 28 00:39:55 2004 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 27 Feb 2004 16:39:55 -0800 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> Message-ID: <20040227163955.67adbee8.pros-n-cons@bak.rr.com> On Fri, 27 Feb 2004 10:02:09 -0500 (EST) "Mike A. Harris" wrote: > On Fri, 27 Feb 2004, Leonard den Ottolander wrote: > > >How well scrutinized is this NSA code actually? Everybody can see they > >won't slip in an obvious backdoor, but how about nasty little overflows, > >tucked away deep inside the code, for which they already have exploits > >in their drawer? > > Aside from rejecting SElinux merely due to conspiracy theories > alone, what would be your suggestion to ensure that this is not > the case? > > If you really think about it, you can apply the same conspiracy > theory to the Linux kernel, XFree86, and every other piece of > software in the system. > > There are quite a few security vulnerabilities found and fixed in > OSS source code. How can you truely be sure that a given > vulnerability wasn't planted there intentionally? > > Take the recent XFree86 security update which contains fixes for > libXfont. Do we really know for sure that when Keith Packard > wrote that 14 or so years ago, that he didn't intentionally put > the buffer overflows in there, so that he could 0wn all machines > running the X Window System 15 years later? ;o) > > You did upgrade X to the latest version right? ;o) > > > > -- > Mike A. Harris ftp://people.redhat.com/mharris > OS Systems Engineer - XFree86 maintainer - Red Hat > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list I thought Fedora wasn't vulnerable to that bug due to exec-shield. Packard never saw that one comming! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cornette at insight.rr.com Sat Feb 28 00:54:12 2004 From: cornette at insight.rr.com (Jim Cornette) Date: Fri, 27 Feb 2004 19:54:12 -0500 Subject: latest update In-Reply-To: <403EA440.1050405@insight.rr.com> References: <1077831368.3240.2.camel@old1> <403EA440.1050405@insight.rr.com> Message-ID: <403FE6B4.7070208@insight.rr.com> > > I had the conflict with libgtop2 also. I just deselected it in > up2date-gnome and everything else installed without issues. > > The conflict was due to this error message from up2date. (error dialog box) > > ------------------ > > There was a package dependency problem. The message was: > > Unresolvable chain of dependencies: > gnome-applets 2.5.4-2 requires libgtop-2.0.so.1 > gnome-applets 2.5.4-2 requires libgtop_common-2.0.so.1 > gnome-applets 2.5.4-2 requires libgtop_sysdeps-2.0.so.1 > gnome-system-monitor 2.5.2-2 requires libgtop-2.0.so.1 > gnome-system-monitor 2.5.2-2 requires libgtop_common-2.0.so.1 > gnome-system-monitor 2.5.2-2 requires libgtop_sysdeps-2.0.so.1 > > > Please modify your package selections and try again. > > ---------------- > > Just unselect libgltop2 and try again. > > > Jim > > Gnome-system-monitor is there. gnome-applets still causes conflicts and neither gnome-system-monitor or libgtop2 can be installed. Unresolvable chain of dependencies: gnome-applets 2.5.4-2 requires libgtop-2.0.so.1 gnome-applets 2.5.4-2 requires libgtop_common-2.0.so.1 gnome-applets 2.5.4-2 requires libgtop_sysdeps-2.0.so.1 Jim -- I really hate this damned machine I wish that they would sell it. It never does quite what I want But only what I tell it. Except when selinux is activated. Then it works perfectly. From toshio at tiki-lounge.com Sat Feb 28 00:54:50 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 27 Feb 2004 19:54:50 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <1077907096.5196.25.camel@otto.amantes> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> <1077907096.5196.25.camel@otto.amantes> Message-ID: <1077929689.4875.380.camel@Madison.badger.com> On Fri, 2004-02-27 at 13:38, Thomas Vander Stichele wrote: > The README of mach serves as a quite ok HOWTO for a first encounter. > There's no FAQ because nobody asks me questions :) As for irc, > #fedora-devel ? I'm there all the time. > Cool! I'll give you a holler next time I make a mach attempt. -Toshio -- Toshio From jpo at di.uminho.pt Sat Feb 28 01:16:11 2004 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 28 Feb 2004 01:16:11 +0000 Subject: Self-Introduction: Jose Pedro Oliveira Message-ID: <403FEBDB.7040104@di.uminho.pt> 1. Full Legal Name: Jos? Pedro Garcia de Oliveira 2. Country, City: Portugal, Braga 3. Profession: Teaching Assistant 4. University: Universidade do Minho 5. Goals in the Fedora Project Maintain the syslog-ng/libol specfiles. - Which packages do you want to see published? Network and system administration related (eg: Nagios, Snort, ...) - Do you want to do QA? Yes. 6. Historical qualifications Worked as a Software Engineer in the industry. - Computer languages: Present: Perl, C Past: SqlWindows, Visual Basic, Pascal, C++, Assembly (80x86, Z80, 8051), Prolog, - Other skills: System administration 7. GPG KEYID and fingerprint pub 1024D/91BD851B 2003-08-07 Jose Pedro Oliveira Key fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B jpo -- Jos? Pedro Oliveira * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From blocke at shivan.org Sat Feb 28 04:39:50 2004 From: blocke at shivan.org (Bruce A. Locke) Date: Fri, 27 Feb 2004 23:39:50 -0500 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <20040227163955.67adbee8.pros-n-cons@bak.rr.com> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> <20040227163955.67adbee8.pros-n-cons@bak.rr.com> Message-ID: <1077943189.3656.1.camel@localhost.localdomain> On Fri, 2004-02-27 at 19:39, Vincent wrote: > I thought Fedora wasn't vulnerable to that bug due to exec-shield. Packard never > saw that one comming! This comment makes me curious. Has anyone been testing the recent user space vulnerabilities and seeing if exec-shield + prelink randomization prevented at least some of them from being exploited? Just curious... -- ------------------------------------------------------------------ Bruce A. Locke blocke at shivan.org From pros-n-cons at bak.rr.com Sat Feb 28 08:07:58 2004 From: pros-n-cons at bak.rr.com (Vincent) Date: Sat, 28 Feb 2004 00:07:58 -0800 Subject: Fedora Core 2 Test 2 - delayed In-Reply-To: <1077943189.3656.1.camel@localhost.localdomain> References: <20040227025751.GF29689@devserv.devel.redhat.com> <1077886446.4747.11.camel@athlon.localdomain> <20040227163955.67adbee8.pros-n-cons@bak.rr.com> <1077943189.3656.1.camel@localhost.localdomain> Message-ID: <20040228000758.5fd76f75.pros-n-cons@bak.rr.com> On Fri, 27 Feb 2004 23:39:50 -0500 "Bruce A. Locke" wrote: > On Fri, 2004-02-27 at 19:39, Vincent wrote: > > > I thought Fedora wasn't vulnerable to that bug due to exec-shield. Packard never > > saw that one comming! > > This comment makes me curious. Has anyone been testing the recent user > space vulnerabilities and seeing if exec-shield + prelink randomization > prevented at least some of them from being exploited? > > Just curious... > > -- > ------------------------------------------------------------------ > Bruce A. Locke > blocke at shivan.org > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list Yes _some_ have been tested behind the scenes but the results aren't public yet from what I gather. All I've heard is that X wasn't vuln. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Sat Feb 28 10:21:39 2004 From: warren at togami.com (Warren Togami) Date: Sat, 28 Feb 2004 00:21:39 -1000 Subject: Fedora.us QA In-Reply-To: <1077858145.4875.333.camel@Madison.badger.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CD947@smith.interlink.local> <1077858145.4875.333.camel@Madison.badger.com> Message-ID: <40406BB3.4040709@togami.com> Toshio wrote: >>>1. Does the package follow the Fedora Package Naming Guidelines? >>This is pretty darn complicated for a newbie QA'er. They should be >>allowed to opt out. > > My problem with opting out was stated above: what if two QA'ers review > the package and both opt-out? > This is a total non-issue, because the elders will at a glance notice a problem and suggest a solution. Most new packagers got it wrong at least once or twice, but after being corrected they almost never made a mistake again. > Speaking as a fedora user/developer -- I don't care so much that > packages wait in the QA queue. If I see something I want there, I > download and review it and if it works well I start driving :-) There are PLENTY of other users capable of doing this, but what has happened in the past year is people bitch, abandon ship, or create their own boat (3rd party repositories) rather than put time into the collaborative project. A collaborative project only scales if labor scales. Then there are a multitude of other users who do not understand the system well enough to do the above. Some in this category expect lots of quality work to be done and contribute nothing but noise themselves. It makes matters worse when they think they know better and bitch about things going slowly. This is why I personally almost totally burned out and avoid #fedora and even #fedora-devel most of the time these days. This is the only way I can keep any sanity. Constructive criticism is appreciated, but otherwise I will need to start using a personal killfile in order to get anything productive done. (Note that this response is not targeted at you, but certain others.) Warren From peter.backlund at home.se Sat Feb 28 10:28:53 2004 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 28 Feb 2004 11:28:53 +0100 Subject: Buglet list from FC2t1 In-Reply-To: <20040224214149.GA10728@devserv.devel.redhat.com> References: <403BAA0D.4050003@home.se> <20040224214149.GA10728@devserv.devel.redhat.com> Message-ID: <40406D65.5030607@home.se> Alright, all bugs in the list are either fixed in Rawhide, already in BZ or have been opened by me. I also discovered a few dupes. Here are a few more: - Several of the system-config utilities do not have a cancel button (s-c-keyboard for example). - The default serif font is perhaps one size too small compared to the default sans serif font, when used in Mozilla. www.gnomedesktop.org is not very readable when using Serif font, size 16, minimum size < 13. I need to set minimum size to 13, but then the sans font is a bit too big. This is no a monitor with values dimensions: 1024x768 pixels (321x241 millimeters) resolution: 81x81 dots per inch from xdpyinfo. - Also, the Slashdot test (view slashdot.org in Moz with default settings) reveals that the italic version of the default serif font has a problem with the letter 'e'. xmag shows that it draws two pixels below the baseline. This is what might call a /minor/ issue :-) /Peter Backlund From buildsys at redhat.com Sat Feb 28 14:50:38 2004 From: buildsys at redhat.com (Build System) Date: Sat, 28 Feb 2004 09:50:38 -0500 Subject: rawhide report: 20040228 changes Message-ID: <200402281450.i1SEocP12574@porkchop.devel.redhat.com> New package gnome-netstatus Network status applet New package perl-RPM-Specfile RPM-Specfile Perl module New package perl-XML-LibXML-Common XML-LibXML-Common Perl module Updated Packages: XFree86-4.3.0-61 ---------------- * Fri Feb 27 2004 Mike A. Harris 4.3.0-61 - Added XFree86-4.3.0-keyboard-disable-ioport-access-v3.patch as a final patch without debug logging enabled, to fix (#115769) - Added spec file macro 'with_savetemps' for debugging purposes, disabling it by default. When used, it is set up to only get used on x86 for build_rawhide and build_psyche builds - Added XFree86-4.3.0-ati-ia64-no-nonpci-ioport-access.patch to fix ati driver issue on ia64 which causes IBM x455 system to machine check. Also added "#define ATIAvoidNonPCI YES" to host.def to activate this fix only on ia64 builds (#112175) * Wed Feb 25 2004 Mike A. Harris 4.3.0-60 - Added XFree86-4.3.0-keyboard-disable-ioport-access-v2.patch to try to fix (#115769) - Changed mkxauth to call chown as foo:bar instead of foo.bar as the latter syntax has been deprecated - Added XFree86-4.3.0-minor-typo.patch to fix a trivial typo that I spotted in an error message in linux int10 code. - Remove Buildrequires kudzu-devel, pciutils-devel, both of which were added on Mar 21, 2001 when Glide3 was included in the XFree86 packaging, but are no longer necessary. I detected this when the buildsystem failed my build due to being unable to meet the dependancy on kudzu-devel, and further investigation showed that dependancy is no longer necessary. - Added XFree86-4.3.0-xcursorgen-check-malloc-return.patch to make xcursorgen check the return codes on malloc before referencing allocated memory - Added XFree86-4.3.0-redhat-xcursorgen-do-not-build-included-cursors.patch to stop building the XFree86 supplied Xcursor cursors as we do not ship them * Thu Feb 19 2004 Mike A. Harris 4.3.0-59 - Added XFree86-4.3.0-xrandr-manpage-typo-fix.patch to fix manpage (#83702) - Added XFree86-4.3.0-radeon-9200-dvi-snow.patch to fix issue on Radeon 9200 when using DVI panel and encountering snow and other artifacts (#112073) - Updated XFree86-4.3.0-debug-logging-ioport-based-rate-setting.patch to have it patch both lnx_kbd.c and lnx_io.c because both files insanely contain identical cut and pasted copies of the exact same source code, so nothing shows up in the X server log when testing with previous patch as the calls never got invoked in lnx_kbd.c (#115769) gail-1.5.6-1 ------------ * Wed Feb 25 2004 Alexander Larsson 1.5.6-1 - update to 2.5.6 gimp-print-4.2.6-8 ------------------ * Fri Feb 27 2004 Tim Waugh 4.2.6-8 - Fixed dither algorithm selection (bug #116516). - Fixed another plug-in crash. glibc-2.3.3-12 -------------- * Fri Feb 27 2004 Jakub Jelinek 2.3.3-12 - update from CVS * Fri Feb 27 2004 Jakub Jelinek 2.3.3-11 - update from CVS - fix ld.so when vDSO is randomized gnome-applets-2.5.6-1 --------------------- * Thu Feb 26 2004 Alexander Larsson 1:2.5.6-1 - update to 2..5.6 gnome-panel-2.5.90-1 -------------------- * Fri Feb 27 2004 Mark McLoughlin 2.5.90-1 - Update to 2.5.90 - Resolve conflicts with the lockf patch and re-work slightly gstreamer-plugins-0.7.5-1 ------------------------- * Fri Feb 27 2004 Alexander Larsson 0.7.5-1 - update to 0.7.5 * Fri Feb 13 2004 Elliot Lee - rebuilt gtk2-2.3.4-1 ------------ * Wed Feb 25 2004 Mark McLoughlin 2.3.4-1 - Update to 2.3.4 - Remove the xft-prefs patch, its upstream now - Don't kill libtool's hardcode_libdir_flag_spec anymore im-sdk-11.4-19 -------------- * Fri Feb 27 2004 Akira TAGOH 1:11.4-19 - im-sdk-11.4-canna-no-process-unrelated-keys.patch: applied to allow working unrelated keys during no preediting. (#114002) - im-sdk-11.4-canna-draw-off-status.patch: fixed crash issue. kernel-2.6.3-1.116 ------------------ * Fri Feb 27 2004 Dave Jones - Update to 2.6.4-rc1 - Re-enable Future Domain SCSI controller. libaio-0.3.98-2 --------------- * Thu Feb 26 2004 Jeff Moyer 0.3.98-2 - bah. fix version nr in changelog. * Thu Feb 26 2004 Jeff Moyer 0.3.98-1 - fix compiler warnings. * Thu Feb 26 2004 Jeff Moyer 0.3.97-2 - make srpm was using rpm to do a build. changed that to use rpmbuild if it exists, and fallback to rpm if it doesn't. pam-0.77-36 ----------- * Thu Feb 26 2004 Dan Walsh 0.77-36 - fix tty handling * Thu Feb 26 2004 Dan Walsh 0.77-35 - remove tty closing and opening from pam_selinux, it does not work. * Fri Feb 13 2004 Elliot Lee - rebuilt policy-1.6-13 ------------- * Fri Feb 27 2004 Dan Walsh 1.6-13 - Add Russell etc_domain stuff * Thu Feb 26 2004 Dan Walsh 1.6-12 - Fix fd inheritance * Thu Feb 26 2004 Dan Walsh 1.6-11 - fix locate rpm-4.3-0.16 ------------ * Wed Feb 25 2004 Jeff Johnson 4.3-0.15 - serialize rpmtsRun() using fcntl on /var/lock/rpm/transaction. rpmdb-fedora-1.90-0.20040228 ---------------------------- sound-juicer-0.5.10.1-3 ----------------------- * Fri Feb 27 2004 Brent Fox 0.5.10.1-3 - rebuild From timh at contentspace.demon.co.uk Sat Feb 28 18:15:11 2004 From: timh at contentspace.demon.co.uk (Tim Hawkins) Date: Sat, 28 Feb 2004 18:15:11 +0000 Subject: Bizzare FC2 test 1 networking issue In-Reply-To: <403B23C9.8060004@contentspace.demon.co.uk> References: <403A8A6E.9020002@contentspace.demon.co.uk> <1077594476.4708.278.camel@rocky> <403B13EA.4000606@contentspace.demon.co.uk> <403B1FA5.1070309@gear.dyndns.org> <403B23C9.8060004@contentspace.demon.co.uk> Message-ID: <4040DAAF.3080207@contentspace.demon.co.uk> Tim Hawkins wrote: > Paul Gear wrote: > >> Tim Hawkins wrote: >> >> >>> ... >>> >>> >>>> Have you tried with ECN disabled? I have a netgear router that >>>> doesn't >>>> work with ECN... but mine doesn't freeze. ECN was enabled by >>>> default in >>>> FC2 and it took me awhile to figure out why only TCP was broken on my >>>> FC2 system. Disable ECN by running: >>>> >>>> echo 0 > /proc/sys/net/ipv4/tcp_ecn >>>> ... >>>> >>>> >>> >>> Is that a permement change Nathan, or will I have to put that into the >>> rc scripts to ensure its disabled on boot? >>> >> >> >> To make those changes permanent, put a corresponding entry in >> /etc/sysctl.conf. >> >> > That seems to fix the problem Paul, laptop boots ok now without > killing router > I'll get onto Netgear and findout why tcp_ecn cause the router so much > distress. Im running > the latest firmware on the box, and its a very popular brand/model. > > > I spoke too soon, its better but the problem still exists I have narrowed it down to DHCP negotiation which is strange as the netgear router is not configured to operate as a DHCP server. Its not the network card driver as I have now switched to a wireless lan card and the problem is the same . I get the following in the system log just as the router dies. Feb 28 17:27:45 timslaptop kernel: Uniform CD-ROM driver Revision: 3.20 Feb 28 17:27:45 timslaptop udev[3296]: creating device node '/udev/hdc' Feb 28 17:28:40 timslaptop kernel: ip_tables: (C) 2000-2002 Netfilter core team Feb 28 17:28:40 timslaptop kernel: eth1: error -110 reading info frame. Frame dropped. Feb 28 17:28:40 timslaptop kernel: eth1: Error -110 setting multicast list. Feb 28 17:28:40 timslaptop last message repeated 2 times Feb 28 17:28:40 timslaptop dhclient: sit0: unknown hardware address type 776 Feb 28 17:28:40 timslaptop kernel: eth1: New link status: Connected (0001) Feb 28 17:28:41 timslaptop dhclient: sit0: unknown hardware address type 776 Feb 28 17:28:43 timslaptop dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Feb 28 17:28:43 timslaptop dhclient: DHCPACK from 192.168.0.242 Feb 28 17:28:43 timslaptop dhclient: bound to 192.168.0.163 -- renewal in 100950 seconds. Feb 28 17:33:51 timslaptop kernel: spurious 8259A interrupt: IRQ7. Feb 28 17:34:33 timslaptop nmbd[2422]: [2004/02/28 17:34:33, 0] nmbd/nmbd_become_lmb.c 192.168.0.242 is an NT box operating as a DHCP server, the reason for that is complicated, to do with limitations in the netgear DHCP server, I need to be able to set the DNS servers for the DHCP reponse, so that I can have local copies of my domains on an internal DNS with internal addresses, rather than the external addreses on the external ISP DNS. netgear assumes they are the uptream ISP servers it has DHCP'd from the adsl provider. the DHCP server is disable on the netgear router. If I set the ip's, DNS's staticaly, then the system is stable. From jurgen at botz.org Sat Feb 28 21:38:43 2004 From: jurgen at botz.org (=?ISO-8859-1?Q?J=FCrgen_Botz?=) Date: Sat, 28 Feb 2004 13:38:43 -0800 Subject: more borken deps Message-ID: <40410A63.9040706@botz.org> In current development dir... * redhat-lsb requires /usr/bin/kill, which no longer exists because it has been moved from coreutils to util-linux where it seems to be /bin/kill * gstreamer lib is updated but gnome-media, nautilus-media and rhythmbox still require the old lib -- J?rgen Botz | While differing widely in the various jurgen at botz.org | little bits we know, in our infinite | ignorance we are all equal. -Karl Popper From toshio at tiki-lounge.com Sat Feb 28 21:51:46 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 28 Feb 2004 16:51:46 -0500 Subject: Fedora.us QA (was: Re: Prelink success story :)) In-Reply-To: <1077867440.25962.33.camel@goober.localdomain> References: <1077867440.25962.33.camel@goober.localdomain> Message-ID: <1078005101.28946.441.camel@Madison.badger.com> On Fri, 2004-02-27 at 02:37, Jef Spaleta wrote: > Let me instead [of the best pactices book] > suggest that what might be instructive are SHORT... > "anatomies of a QA review" case examples. A few good and a few bad > reviews that can highlight common issues...and that can suggest a > general flow of how things are suppose to work. A good example of this > sort of thing..is the Gnome Bugsquads triage examples. > http://developer.gnome.org/projects/bugsquad/triage/examples.html Hmmm.... I sort of want to aim at this content with a Best Practices book... it's just the organization of the triage examples I can't stand. For instance, in one of your Fedora Triage emails you had to categorize the examples so they provide a sense to others of what's going on. I want a reference where that categorization is already done. I also don't like the three page format (two of which are essentially the same bugzilla with one added entry.) So I just want to devote more human time into making a good reference, rather than an unorganized list of examples. I hereby officially volunteer to edit, format, organize, and compile such a reference (I've been waiting five years for someone else to suggest one so I guess it's about time I did something.) Open request for others to point out examples of things to put in! And Jef"you mentioned it so you own it"Spaleta: since you mentioned the list of bugzilla examples: if you mail me some good ones, I'll snip, quote, organize, and otherwise create organization from the chaos :-) -Toshio"carefully avoided mentioning the whole mentoring of new QA'ers as he knows better than to handle two babies at one time so you'll have to find another sucker to do it"Kuratomi PS. I threw in the "historical arguments" because otherwise there would continue to be these long, emotional discussions of which way was better. My [naive] notion is that if people don't like a particular recommendation (A Best Practices Book is not policy) they can read the Pro/Con arguments and make their own decision rather than state the same arguments on a public forum. (New arguments would be welcome in the book and perhaps lead to changes in the recomendations.) -- Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alexluca at inwind.it Sat Feb 28 22:31:53 2004 From: alexluca at inwind.it (Luca Ferrari) Date: Sat, 28 Feb 2004 23:31:53 +0100 Subject: HI! New Project In-Reply-To: <1077960917.4009.6.camel@laptop.kamaleonte> References: <20040227184601.15892.63907.Mailman@listman.back-rdu.redhat.com> <1077960917.4009.6.camel@laptop.kamaleonte> Message-ID: <1078007512.3584.2.camel@laptop.kamaleonte> Hi guy! I'm Luca Ferrari, an Italian fedora translator. Using Fedora and its desktop-oriented I think one thing: why don't we create an animated introduction that runs at the first boot, where you can look the news, the features, the principal functions... of Fedora (a little bit like WindowsXP or Lindows)? I think that it will a great surprise! What do you think? I had a reviews: go to http://luka4e.fedoraitalia.org/ and look: what do you think about it? There is a preview with a firstboot style at http://luka4e.fedoraitalia.org/intro BYE!!!!!! And answer! From aboyce at conduit-it.com Sun Feb 29 00:33:28 2004 From: aboyce at conduit-it.com (Andrew Boyce-Lewis) Date: Sat, 28 Feb 2004 19:33:28 -0500 Subject: Adaptec aic79xx driver on x86_64 support Message-ID: <1078014808.1433.4.camel@bacon> Has there been any progress on this issue? The bugzilla for this problem (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113938) has had no activity for a while. There is supposedly "quite a bit of work" to clean the driver up for x86_64, has anyone started on that work yet? -Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Sun Feb 29 12:15:59 2004 From: buildsys at redhat.com (Build System) Date: Sun, 29 Feb 2004 07:15:59 -0500 Subject: rawhide report: 20040229 changes Message-ID: <200402291215.i1TCFxT31121@porkchop.devel.redhat.com> Updated Packages: bind-9.2.3-8 ------------ * Sat Feb 28 2004 Florian La Roche - run ldconfig for libs subrpm * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. im-sdk-11.4-21 -------------- * Sun Feb 29 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d * Fri Feb 27 2004 Jens Petersen - 1:11.4-20 - make iiimf-server obsolete im-sdk rpmdb-fedora-1.90-0.20040229 ---------------------------- udev-018-2 ---------- * Sun Feb 29 2004 Florian La Roche - move chkconv to preun - nicer url yum-2.0.5.20040224-2 -------------------- * Thu Feb 26 2004 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d From dpw2atox at yahoo.com Sun Feb 29 16:30:16 2004 From: dpw2atox at yahoo.com (David Wagoner) Date: Sun, 29 Feb 2004 08:30:16 -0800 (PST) Subject: up2date, system-config-packages and synaptic Message-ID: <20040229163016.65130.qmail@web40412.mail.yahoo.com> My question here is why is the fedora team wasting so much time developing up2date and system-config-packages when synaptic is already an excellent replacement. Even though it uses apt, worst case would be to get the latest source and code in support for yum then. I have had nothing but problems with up2date. I have had packages fail to install and yet appear to be installed as far as up2date is concerned, system-config-packages though its getting better still has a ways to go before it has the features that synaptic has. If the developers choose to continue to use up2date and system-config-packages, I will continue to use the products during the rest of the test phase but when Fedora Core 2 is released I plan on switching to synaptic. Synaptic is full of features, stable and fast. I look foward to seeing what everyone has to say on this subject. __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools From llim at redhat.com Fri Feb 20 06:07:22 2004 From: llim at redhat.com (Lawrence Lim) Date: Fri, 20 Feb 2004 16:07:22 +1000 (EST) Subject: Testers Required for Next Generation Input Method Message-ID: The Fedora Project will be adopting a revolutionary new Input Method system in the upcoming release of the Fedora Core 2. We would like to extend an invitation at this time to East Asian users in particular to test this preliminary release and provide us with feedback so we can improve the software and ensure that the Input Methods will be easier, more efficient and pleasant to use. Intranet/Internet Input Method Framework (IIIMF) is the next generation Input Method Framework set to replace the legacy X Window System Input Method (XIM) used by existing Input Methods such as chinput, xcin, kinput2, ami and many others. As the technology is still at its infancy, wider testing effort by community is needed to expediate the maturity of the technology. IIIMF server loads Language Engines (LE) dynamically at runtime as requested by clients. In this first round of testing, four LEs are available: + iiimf-le-inpinyin for Simplified Chinese (zh_CN.UTF-8) + iiimf-le-xcin for Traditional Chinese (zh_TW.UTF-8) + iiimf-le-canna for Japanese (ja_JP.UTF-8) + iiimf-le-hangul for Korean (ko_KR.UTf-8) If you wish to participate in this first round of testing, a Testing Guide is now available at . It will give you the necessary information in setting up the IIIMF and using the LE specific to your locale. Input Method Testing Discussion Mailing List: fedora-i18n-list at redhat.com Subscribe at: https://www.redhat.com/mailman/listinfo/fedora-i18n-list IRC: Channel #fedora-i18n on irc.freenode.net Best Regards, Fedora I18N Team