From enrico.scholz at informatik.tu-chemnitz.de Tue Feb 1 00:00:48 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 01 Feb 2005 01:00:48 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <41FEC3AC.10306@nc.rr.com> (Jeff Johnson's message of "Mon, 31 Jan 2005 18:47:56 -0500") References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107212145.30653.174.camel@shahms.mesd.k12.or.us> <87mzupch6k.fsf@kosh.ultra.csn.tu-chemnitz.de> <41FEC3AC.10306@nc.rr.com> Message-ID: <87fz0hcfnz.fsf@kosh.ultra.csn.tu-chemnitz.de> n3npq at nc.rr.com (Jeff Johnson) writes: >> | $ rpm -qpC --nodigest --nosignature *.rpm |LANG=C wc | 511863 >> 2364195 15619260 > ... > Um, you might try --changelog instead: ouch... 'rpm --changelog' is one of the most used rpm commands, so I assumed that everybody would have | # cat /etc/popt | rpm alias -C --changelog on his system. Enrico From skvidal at phy.duke.edu Tue Feb 1 00:09:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 19:09:21 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050131223729.GA30385@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> Message-ID: <1107216561.25100.2.camel@cutter> > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > If changelogs are bloating the headers yum has to download, then > strip them out when generating the yum headers. it's not bloating the headers - well not JUST that. I'm also thinking of decreasing the useles space eaten up by them on the cd isos. -sv From skvidal at phy.duke.edu Tue Feb 1 00:09:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 19:09:49 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107212228.17531.6.camel@one.myworld> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107212228.17531.6.camel@one.myworld> Message-ID: <1107216590.25100.4.camel@cutter> On Mon, 2005-01-31 at 23:57 +0100, F?liciano Matias wrote: > Le lundi 31 janvier 2005 ? 17:37 -0500, Eric S. Raymond a ?crit : > > > > If changelogs are bloating the headers yum has to download, then > > strip them out when generating the yum headers. > > changelogs are in repodata/other.xml (seems yum does not use this file). > other.xml.gz = 5 Mo > FC3 = 2.3 Go > yum can use this file: yum generate-rss uses it. -sv From thuforuk at yahoo.co.uk Tue Feb 1 00:19:57 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Tue, 01 Feb 2005 00:19:57 +0000 Subject: radical suggestion for fc4 release In-Reply-To: <41FEB494.3030703@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> Message-ID: <41FECB2D.6040408@yahoo.co.uk> On 01/31/2005 10:43 PM, Jeff Johnson wrote: > Jeff Johnson wrote: > >> seth vidal wrote: >>> how about if we kill all rpm spec file changelog entries OLDER than 2 >>> years. >>> >>> they'll still live on in older srpms and rpms but it'd be a useful >>> reduction and it would make the specfiles that much smaller, along with >>> the rpm headers. >> >> +1 > > In fact, it's silly to carry changelogs in packages, since packaging > changes are > far more easily read from e-mail, or from a web-site, or just about any > other > way than > rpm -q --changelog pkg Hmmm... I must be different then ;-) Seriously, recently I used this command to find out whhat's changed in NetworkManager when apt decided to grab bind with it. [And that was also when I decided to 'rpm -e NetworkManager' and manage my net manually (it's simple enough: no wireless, no plugging/unplugging, just two ethernet cards and dhcp).] > With no offense whatsoever to anyone, I humbly submit that the comments in > the changelog are of rather limited use to any non-redhat developer, and > are > totally useless to any end-user. Well, I consider myself mostly end-user... > So perhaps changelogs should be nuked entirely, and handled ouside of > package content, instead. Perhaps. Just a note that it *may* sometimes be useful even to end-user. Regards, Dariusz From rc040203 at freenet.de Tue Feb 1 00:32:27 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 01:32:27 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107209076.5291.26.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> Message-ID: <1107217948.5389.223.camel@mccallum.corsepiu.local> On Mon, 2005-01-31 at 17:04 -0500, seth vidal wrote: > Hi folks, > this is a touch silly but possibly useful and it would definitely cut > down on the old crap blocking up cdroms. > > how about if we kill all rpm spec file changelog entries OLDER than 2 > years. > > they'll still live on in older srpms and rpms but it'd be a useful > reduction and it would make the specfiles that much smaller, along with > the rpm headers. > > thoughts? +1 I never understood their usefulness, but with *.specs in CVS they have become even more useless. Ralf From rc040203 at freenet.de Tue Feb 1 00:35:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 01:35:01 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107216561.25100.2.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> Message-ID: <1107218101.5389.227.camel@mccallum.corsepiu.local> On Mon, 2005-01-31 at 19:09 -0500, seth vidal wrote: > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > If changelogs are bloating the headers yum has to download, then > > strip them out when generating the yum headers. > > it's not bloating the headers - well not JUST that. > > I'm also thinking of decreasing the useles space eaten up by them on the > cd isos. Switching the rpm payload to bzip2 would probably give you much more space FWIW: AFAIK, SuSE uses bzip2 payloads. Ralf From n3npq at nc.rr.com Tue Feb 1 00:47:53 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 19:47:53 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107218101.5389.227.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> Message-ID: <41FED1B9.3010804@nc.rr.com> Ralf Corsepius wrote: >On Mon, 2005-01-31 at 19:09 -0500, seth vidal wrote: > > >>>Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. >>> >>>If changelogs are bloating the headers yum has to download, then >>>strip them out when generating the yum headers. >>> >>> >>it's not bloating the headers - well not JUST that. >> >>I'm also thinking of decreasing the useles space eaten up by them on the >>cd isos. >> >> > >Switching the rpm payload to bzip2 would probably give you much more >space > >FWIW: AFAIK, SuSE uses bzip2 payloads. > > Yep, and so does PLD. Very very very foolish imho, as rpm is rate limited by decompression, and bzip2 uncompress is known 5-7 times slower than gzip. BUt feel free to change Fedora Core to "Be just like SuSE" if you want. PLD (my favorite distro, they are quiet and sensible in Poland ;-), is considering reverting to gzip when I pointed out that bzip2 was 5-7 times slower. Add --stats, any install, run your own benchmark. Personally, I think LZO might be preferable to either gzip of bzip2. And the real issue is that zlib/bzip2/LZO are known not to rsync very well. Well, that is known for gzip fer sure, I believe also true for bzip2/LZO ... 73 de Jeff From rc040203 at freenet.de Tue Feb 1 00:51:08 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 01:51:08 +0100 Subject: redhat abe In-Reply-To: <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1107219068.5389.239.camel@mccallum.corsepiu.local> On Mon, 2005-01-31 at 23:09 +0100, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: > > > This renders "apt-get source" and "apt-get build-dep" non-applicable > > to fedora.us hosted apt-repositories and therefore voids at least > > these aspects where apt is superior to yum. > > Although I love apt for its powerful configuration, I have to admit that > 'apt-get build-dep' is not very usefully in the rpm-world: > > * it detects only the requirements which were used to build the src.rpm, > but not the deps which will be required True, but ??? apt-get build-deps is useful for chasing bugs in rpms, e.g. when having notices something suspicious when using a binary rpm and trying to fix the cause. Typical scenario: 1. Use a binary rpm, notice a problem. 2. su; apt-get build-dep 3. apt-get source 4. rpm -U .src.rpm 5. edit .spec| 6. rpmbuild -ba Edit and rebuild the package. As run-time deps of the binary rpm and build-time deps of the package do not necessarily have to match, this is very convenient. > * extending functionality is a non-trivial task, a the dep-resolving > should happen as non-root while the final package removal/installation > must happen as root Also true, but ... using a simple chroot is sufficient for the case above. Ralf From nando at ccrma.Stanford.EDU Tue Feb 1 01:04:13 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: 31 Jan 2005 17:04:13 -0800 Subject: radical suggestion for fc4 release In-Reply-To: <1107216561.25100.2.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> Message-ID: <1107219853.12849.162.camel@cmn37.stanford.edu> On Mon, 2005-01-31 at 16:09, seth vidal wrote: > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > If changelogs are bloating the headers yum has to download, then > > strip them out when generating the yum headers. > > it's not bloating the headers - well not JUST that. > > I'm also thinking of decreasing the useles space eaten up by them on the > cd isos. how much space do they eat currently? -- Fernando From skvidal at phy.duke.edu Tue Feb 1 01:10:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 20:10:17 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107219853.12849.162.camel@cmn37.stanford.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107219853.12849.162.camel@cmn37.stanford.edu> Message-ID: <1107220217.25100.28.camel@cutter> On Mon, 2005-01-31 at 17:04 -0800, Fernando Lopez-Lezcano wrote: > On Mon, 2005-01-31 at 16:09, seth vidal wrote: > > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > > > If changelogs are bloating the headers yum has to download, then > > > strip them out when generating the yum headers. > > > > it's not bloating the headers - well not JUST that. > > > > I'm also thinking of decreasing the useles space eaten up by them on the > > cd isos. > > how much space do they eat currently? > -- Fernando well they're stored in at LEAST 3 different places on the cds: 1. the packages 2. the srpms 3. the rpmdb-fedora 4. maybe in hdlist2? 5. the metadata I think that's more than enough locations :) -sv From enrico.scholz at informatik.tu-chemnitz.de Tue Feb 1 01:07:27 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 01 Feb 2005 02:07:27 +0100 Subject: redhat abe In-Reply-To: <1107219068.5389.239.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 01 Feb 2005 01:51:08 +0100") References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> <1107219068.5389.239.camel@mccallum.corsepiu.local> Message-ID: <87acqpcckw.fsf@kosh.ultra.csn.tu-chemnitz.de> rc040203 at freenet.de (Ralf Corsepius) writes: >> > This renders "apt-get source" and "apt-get build-dep" non-applicable >> > to fedora.us hosted apt-repositories and therefore voids at least >> > these aspects where apt is superior to yum. >> >> Although I love apt for its powerful configuration, I have to admit that >> 'apt-get build-dep' is not very usefully in the rpm-world: >> >> * it detects only the requirements which were used to build the src.rpm, >> but not the deps which will be required > True, but ??? Ok, an example: | $ cat foo.spec | ... | %if 0%{?_with_foo:1} | BuildRequires: foo-devel | %else | BuildRequires: bar-devel | %endif | ... | | $ rpmbuild -bs foo.spec --with foo | --> foo-*.src.rpm | | $ rpm -qR foo | foo-devel 'apt-get build-dep foo-*.src.rpm' will now try to install 'foo-devel', but 'rpmbuild --rebuild foo-*.src.rpm' will need 'bar-devel'. Simple rpm-header examination of the src.rpm is not sufficient (or better: is wrong) for build-dep calculation. (things get really strange when you have something like | %define _with_foo %(test -e /usr/lib/foo && echo 1 || echo 0) which will be built in a chroot environment) Enrico From n3npq at nc.rr.com Tue Feb 1 01:16:50 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 20:16:50 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107220217.25100.28.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107219853.12849.162.camel@cmn37.stanford.edu> <1107220217.25100.28.camel@cutter> Message-ID: <41FED882.6020304@nc.rr.com> seth vidal wrote: >On Mon, 2005-01-31 at 17:04 -0800, Fernando Lopez-Lezcano wrote: > > >>On Mon, 2005-01-31 at 16:09, seth vidal wrote: >> >> >>>>Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. >>>> >>>>If changelogs are bloating the headers yum has to download, then >>>>strip them out when generating the yum headers. >>>> >>>> >>>it's not bloating the headers - well not JUST that. >>> >>>I'm also thinking of decreasing the useles space eaten up by them on the >>>cd isos. >>> >>> >>how much space do they eat currently? >>-- Fernando >> >> > >well they're stored in at LEAST 3 different places on the cds: > >1. the packages >2. the srpms >3. the rpmdb-fedora >4. maybe in hdlist2? >5. the metadata > >I think that's more than enough locations :) > Let's move changelogs to specspo so that developers can write in their native language! 73 de Jeff, still in denial about changelog encoding rules. From Axel.Thimm at ATrpms.net Tue Feb 1 01:25:55 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 Feb 2005 02:25:55 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107212228.17531.6.camel@one.myworld> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107212228.17531.6.camel@one.myworld> Message-ID: <20050201012555.GC11090@neu.nirvana> On Mon, Jan 31, 2005 at 11:57:08PM +0100, F?liciano Matias wrote: > Le lundi 31 janvier 2005 ? 17:37 -0500, Eric S. Raymond a ?crit : > > > > If changelogs are bloating the headers yum has to download, then > > strip them out when generating the yum headers. > > changelogs are in repodata/other.xml (seems yum does not use this file). > other.xml.gz = 5 Mo > FC3 = 2.3 Go If yum is not affected then this discusion is about saving <= 0.5% (someone quoted ISO file size)? A bit silly IMO. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Feb 1 01:36:24 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 02:36:24 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <41FED1B9.3010804@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> Message-ID: <1107221785.5389.261.camel@mccallum.corsepiu.local> On Mon, 2005-01-31 at 19:47 -0500, Jeff Johnson wrote: > Ralf Corsepius wrote: > > >On Mon, 2005-01-31 at 19:09 -0500, seth vidal wrote: > > > > > >>>Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > >>> > >>>If changelogs are bloating the headers yum has to download, then > >>>strip them out when generating the yum headers. > >>> > >>> > >>it's not bloating the headers - well not JUST that. > >> > >>I'm also thinking of decreasing the useles space eaten up by them on the > >>cd isos. > >> > >> > > > >Switching the rpm payload to bzip2 would probably give you much more > >space > > > >FWIW: AFAIK, SuSE uses bzip2 payloads. > > > > > > Yep, and so does PLD. > > Very very very foolish imho, as rpm is rate limited by decompression, > and bzip2 uncompress is known 5-7 times slower than gzip. Well, people are complaining about sizes, bandwidth and diskspace ... ... not about installation speed. OK, people are used to using gzip-payloads and probably would start to complain when installing bzip'ed rpms (I recall me having complained about SuSE when installing bzip'ed rpms on my ancient i586 notebook). > BUt feel free to change Fedora Core to "Be just like SuSE" if you want. No, that's not my intention. It's just that I can't deny nor ignore having used SuSE for ~8 years. > PLD (my favorite distro, they are quiet and sensible in Poland ;-), is > considering > reverting to gzip when I pointed out that bzip2 was 5-7 times slower. > > Add --stats, any install, run your own benchmark. I did some checks comparing gzip vs. bzip on metadata repositories sometime last year. IIRC, I posted the results to this list. The result was not as eye-striking as one might expect. Ralf From skvidal at phy.duke.edu Tue Feb 1 01:45:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 20:45:06 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107221785.5389.261.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <1107221785.5389.261.camel@mccallum.corsepiu.local> Message-ID: <1107222306.25100.34.camel@cutter> > I did some checks comparing gzip vs. bzip on metadata repositories > sometime last year. IIRC, I posted the results to this list. > > The result was not as eye-striking as one might expect. I remember those benchmarks - and on slower machines the difference is HUGE. 45s difference on a slower machine, iirc. I may not be remembering correctly, though. -sv From n3npq at nc.rr.com Tue Feb 1 01:48:02 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 20:48:02 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107221785.5389.261.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <1107221785.5389.261.camel@mccallum.corsepiu.local> Message-ID: <41FEDFD2.1050907@nc.rr.com> Ralf Corsepius wrote: >>Add --stats, any install, run your own benchmark. >> >> >I did some checks comparing gzip vs. bzip on metadata repositories >sometime last year. IIRC, I posted the results to this list. > >The result was not as eye-striking as one might expect. > > Benchmarks are in the eye of the beholder. My 5-7x slower was done in rpm-3.0.5, immediately after putting bzip2 into rpm. I have had no reason to go back and recheck the data. But --stats is in rpm, specifically for the purpose of measuring payload unpacking speed in situ (and identifying other bottlenecks) I will believe that benchmark and no other. Have fun! 73 de Jeff From pbrobinson at gmail.com Tue Feb 1 01:55:09 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 1 Feb 2005 09:55:09 +0800 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <20050131222016.GA9816@thacker.dyndns.org> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> Message-ID: <5256d0b05013117553d84adc7@mail.gmail.com> > > > Can we also get rid / move to extras all the non > > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > > 1 cruft as well? > > > > Need specific package nominations. > > nmap-frontend is one. > gnucash we're waiting on the port to gtk2 Can't it go into extras in the mean time as extras isn't suppose to be second class but rather 'extras' that way all the GNOME 1.x stuff listed above can go with it. Those that need it can then just do an 'up2date -i gnucash' and get all the deps that go with it. It seems its easier to get rid of all the GNOME 1 stuff than the gtk/glib 1 stuff as its used by the likes of imlib and a few others. I seem to remember that sylpheed was also mentioned a while a go as part of the move to extras. P From esr at thyrsus.com Tue Feb 1 02:38:54 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 31 Jan 2005 21:38:54 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107218101.5389.227.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> Message-ID: <20050201023854.GA32755@thyrsus.com> Ralf Corsepius : > > I'm also thinking of decreasing the useles space eaten up by them on the > > cd isos. > > Switching the rpm payload to bzip2 would probably give you much more > space Yes. That would be attacking the problem at the right level. -- Eric S. Raymond From esr at thyrsus.com Tue Feb 1 02:44:21 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 31 Jan 2005 21:44:21 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <41FED1B9.3010804@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> Message-ID: <20050201024420.GB32755@thyrsus.com> Jeff Johnson : > Very very very foolish imho, as rpm is rate limited by decompression, > and bzip2 uncompress is known 5-7 times slower than gzip. Is that a problem? Processors are speeding up faster than media are getting larger -- thus, trdsing clocks for space seems like the right thing. I'm open to counterargument here -- I just want to be sure you've thought through the tradeoffs completely. -- Eric S. Raymond From toshio at tiki-lounge.com Tue Feb 1 02:55:29 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 31 Jan 2005 21:55:29 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <5256d0b05013117553d84adc7@mail.gmail.com> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <5256d0b05013117553d84adc7@mail.gmail.com> Message-ID: <1107226531.14459.7.camel@Madison.badger.com> On Tue, 2005-02-01 at 09:55 +0800, Peter Robinson wrote: > > > > Can we also get rid / move to extras all the non > > > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > > > 1 cruft as well? > > > > > > Need specific package nominations. > > > > nmap-frontend is one. > > gnucash we're waiting on the port to gtk2 > > Can't it go into extras in the mean time as extras isn't suppose to be > second class but rather 'extras' that way all the GNOME 1.x stuff > listed above can go with it. Those that need it can then just do an > 'up2date -i gnucash' and get all the deps that go with it. If people are going to continue to say that "one app to perform a function" in Core is a goal, then gnucash ought to stay. Gnucash is the only package in Core that is a full-featured financial app. There are two things that can be done to help rectify the gnucash situation: sample grisbi and other financial apps to see if any of them are capable of taking gnucash's place or take a look at what needs to be done to finish porting gnucash to Gtk2 and help out:: http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus -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 n3npq at nc.rr.com Tue Feb 1 03:03:22 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 22:03:22 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050201024420.GB32755@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> Message-ID: <41FEF17A.30005@nc.rr.com> Eric S. Raymond wrote: >Jeff Johnson : > > >>Very very very foolish imho, as rpm is rate limited by decompression, >>and bzip2 uncompress is known 5-7 times slower than gzip. >> >> > >Is that a problem? Processors are speeding up faster than media are >getting larger -- thus, trdsing clocks for space seems like the >right thing. > >I'm open to counterargument here -- I just want to be sure you've >thought through the tradeoffs completely. > > Is memory a bigger problem than cpu? How about broadband vs. dialup? I have no clue where the balance points are. My rpm job is objective measurements through insturmentation, and as reliable and stable an implementation as possible. Go make up your own answers. 73 de Jeff From rc040203 at freenet.de Tue Feb 1 03:09:18 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 04:09:18 +0100 Subject: redhat abe In-Reply-To: <87acqpcckw.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> <1107219068.5389.239.camel@mccallum.corsepiu.local> <87acqpcckw.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1107227358.5389.320.camel@mccallum.corsepiu.local> On Tue, 2005-02-01 at 02:07 +0100, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: > > >> > This renders "apt-get source" and "apt-get build-dep" non-applicable > >> > to fedora.us hosted apt-repositories and therefore voids at least > >> > these aspects where apt is superior to yum. > >> > >> Although I love apt for its powerful configuration, I have to admit that > >> 'apt-get build-dep' is not very usefully in the rpm-world: > >> > >> * it detects only the requirements which were used to build the src.rpm, > >> but not the deps which will be required > > True, but ??? > > Ok, an example: [conditionals in RPM specs] Well, IMO, any rpm which is part of a distribution should be rebuildable by any arbitrary user/semi-newbie using rpmbuild --rebuild ... without having to provide any specific flags. I.e. I consider rpm specs to be broken, which require special conditionals to match those setting having been used by the distributor. Ralf From aoliva at redhat.com Tue Feb 1 03:56:18 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 01 Feb 2005 01:56:18 -0200 Subject: radical suggestion for fc4 release In-Reply-To: <604aa7910501311507711f4e9a@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <20050131235826.A28641@xos037.xos.nl> <604aa7910501311507711f4e9a@mail.gmail.com> Message-ID: On Jan 31, 2005, Jeff Spaleta wrote: > On Mon, 31 Jan 2005 23:58:26 +0100, Jos Vos wrote: >> On Mon, Jan 31, 2005 at 05:43:32PM -0500, Jeff Johnson wrote: >> >> > So perhaps changelogs should be nuked entirely, and handled ouside of >> > package content, instead. >> >> Why not just removing the changelog from the rpm header and having them >> only accessible via the spec file in the src.rpm. There it is useful >> for packagers (inside and outside RH) and doesn't bother "normal users". > and prevents duplication of the changelog across all the binary > subpackages from the same srpm, which F?liciano Matias brings up in > this thread. Hmmm.... i think i like this. And if the metadata generator could somehow easily extract the changelog from the srpm and provide it in a separately-downloadable file, we could still have a simple command-line tool to get to the same info. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Tue Feb 1 04:09:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 23:09:26 -0500 Subject: radical suggestion for fc4 release In-Reply-To: References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <20050131235826.A28641@xos037.xos.nl> <604aa7910501311507711f4e9a@mail.gmail.com> Message-ID: <1107230966.25100.44.camel@cutter> > And if the metadata generator could somehow easily extract the > changelog from the srpm and provide it in a separately-downloadable > file, we could still have a simple command-line tool to get to the > same info. Well it does. other.xml.gz is all changelog information right now. but it can't REMOVE it from the srpm/rpm afterward, though. yum generate-rss uses that info - where do you think the info at: http://fedoraproject.org/infofeed/ comes from? -sv From aoliva at redhat.com Tue Feb 1 05:01:26 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 01 Feb 2005 03:01:26 -0200 Subject: radical suggestion for fc4 release In-Reply-To: <1107230966.25100.44.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <20050131235826.A28641@xos037.xos.nl> <604aa7910501311507711f4e9a@mail.gmail.com> <1107230966.25100.44.camel@cutter> Message-ID: On Feb 1, 2005, seth vidal wrote: >> And if the metadata generator could somehow easily extract the >> changelog from the srpm and provide it in a separately-downloadable >> file, we could still have a simple command-line tool to get to the >> same info. > Well it does. > other.xml.gz is all changelog information right now. Right. Because this info is in the rpms and the srpms headers. If it was removed from them, as suggested in the e-mail upthread I responded to, even in the portion I quoted in my e-mail, createrepo would need changes to get the data from elsewhere. /me hands seth a pair of glasses :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Tue Feb 1 05:12:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 00:12:12 -0500 Subject: radical suggestion for fc4 release In-Reply-To: References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <20050131235826.A28641@xos037.xos.nl> <604aa7910501311507711f4e9a@mail.gmail.com> <1107230966.25100.44.camel@cutter> Message-ID: <1107234732.25100.52.camel@cutter> > > other.xml.gz is all changelog information right now. > > Right. Because this info is in the rpms and the srpms headers. If it > was removed from them, as suggested in the e-mail upthread I responded > to, even in the portion I quoted in my e-mail, createrepo would need > changes to get the data from elsewhere. > > /me hands seth a pair of glasses :-) > I must have misread then. I thought you were saying the opposite. Sorry about that. But we're going to have to start dealing with metadata that doesn't exist in the package header soon, anyway. we need to store all sorts of stuff in the metadata, actually. For example: - security alert information - urls of CVE notices - maybe relationships of packages or sets, etc. so createrepo is going to have to learn how to get information from other places. -sv From esr at thyrsus.com Tue Feb 1 05:30:53 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 1 Feb 2005 00:30:53 -0500 Subject: Space-time tradeoffs (was: Re: radical suggestion for fc4 release) In-Reply-To: <41FEF17A.30005@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> <41FEF17A.30005@nc.rr.com> Message-ID: <20050201053053.GB13501@thyrsus.com> Jeff Johnson : > Is memory a bigger problem than cpu? How about broadband vs. dialup? > > I have no clue where the balance points are. My rpm job is objective > measurements through insturmentation, and as reliable and stable an > implementation as possible. > > Go make up your own answers. OK, here is an answer. We don't know exactly what the "right" tradeoff between space efficiency and decompression time is. But we *do* know which direction that tradeoff is heading. Processor clocks are getting cheaper faster than memory is. Memory is getting cheaper faster than disk is. Disk is getting cheaper a *lot* faster than bits-per-second of bandwidth. The "right" tradeoff is to use lots of cheap resources in order to be able to use fewer expensive resources. Therefore, as these trends continue, we want to spend processor clocks to decrease use of bandwidth. Thus, bzip2 wins over gzip. -- Eric S. Raymond From felipe_alfaro at linuxmail.org Tue Feb 1 07:09:18 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 1 Feb 2005 08:09:18 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107215124.21178.41.camel@localhost.localdomain> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107215124.21178.41.camel@localhost.localdomain> Message-ID: <8cb89a60a94f88741f0d4e8b2228134d@linuxmail.org> On 1 Feb 2005, at 00:45, Owen Taylor wrote: > On Mon, 2005-01-31 at 17:04 -0500, seth vidal wrote: >> Hi folks, >> this is a touch silly but possibly useful and it would definitely cut >> down on the old crap blocking up cdroms. >> >> how about if we kill all rpm spec file changelog entries OLDER than 2 >> years. >> >> they'll still live on in older srpms and rpms but it'd be a useful >> reduction and it would make the specfiles that much smaller, along >> with >> the rpm headers. > > I like having the full changelogs in the spec files. Perhaps with > the new CVS setup we could switch to having external changelogs > and the same benefits.I wouldn't like to just go through all > the packages and lop them off. Perhaps you could leave the full ChangeLog in the .spec file, but instruct rpmbuild to completely remove the ChangeLog except the last 10 entries. From symbiont at berlios.de Tue Feb 1 07:50:43 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 1 Feb 2005 15:50:43 +0800 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> <200501311201.25752.symbiont@berlios.de> Message-ID: <200502011550.45103.symbiont@berlios.de> On Monday 31 January 2005 12:27, Alexandre Oliva wrote: > On Jan 31, 2005, Jeff Pitman wrote: > > This could be driven by an optional parameter to createrepo, which > > provides a list of packages to create a delta with. > > Err... Why? We already have repodata/, and we're creating the new > version in .repodata. We can use repodata/ however we like, I think. Because, the way I'd implement it would not use a binary diff, such as xdelta. See, you're thinking at the level of createrepo crunching on the entire thing over again. I'm not. I'm thinking about it from a certain subset of packages driven by a parameter. >From a gcc/make analogy viewpoint, you can view this as updating one or two specs and running make on the whole source tree. Since you already have objects built, you rebuild the few you don't have, and relink at the very end. Here, the maintainer of the repo wins. Now, if we deferred the re-link to the user-end, then the download for the user would win, too. > > I would rather not utilize xdelta, because you're still > > regenerating the entire thing. Having xmlets that virtually > > add/substract as a delta against primary.xml.gz would be optimal > > for both sides of the equation. > > But then Seth rejects the idea because it makes for unmaintainable > code. And I sort of agree with him now that I see a simpler way to > accomplish the same bandwidth savings. You got me. Not sure how the level of difficulty has changed at all. But, a couple of implementations wouldn't hurt. Shoot, it all might not save *anything*. Doing it first, then throwing it out is what we need now. If it works, great. If not, *shrug*, we live and learn. > > Another advantage of the delta method, is that the on-disk pickled > > objects (or whatever back-end store is used) could be updated > > incrementally based on xml snippets coming in. Instead of > > regenerating the whole thing over again. > > This is certainly a good point, but it is also trickier to get right. > And it might also turn out to be bigger: if you have to list what > went away, you're probably emitting more information than xdelta's > `skip these many bytes'. I would never go to this level of madness. My proposal is connected with generating Xml necessary for the job, not a low-level binary diff between two runs of createrepo. Before doing it like this, I'd explore the librsync option and just run createrepo once as usual and rsync transfer the diff across the line. Keeping track of two runs is, although a bit novel, a little too much. thanks, -- -jeff From mpeters at mac.com Tue Feb 1 08:03:51 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 01 Feb 2005 08:03:51 +0000 Subject: radical suggestion for fc4 release In-Reply-To: <8cb89a60a94f88741f0d4e8b2228134d@linuxmail.org> (from felipe_alfaro@linuxmail.org on Mon Jan 31 23:09:18 2005) References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107215124.21178.41.camel@localhost.localdomain> <8cb89a60a94f88741f0d4e8b2228134d@linuxmail.org> Message-ID: <1107245031l.6399l.2l@devel.mpeters.us> On 01/31/2005 11:09:18 PM, Felipe Alfaro Solana wrote: > > Perhaps you could leave the full ChangeLog in the .spec file, but > instruct rpmbuild to completely remove the ChangeLog except the last > 10 entries. or last two years - which sometimes is less than 10 entries. I find them useful - to see how packagers dealt with specific changes in the distro layout/functionallity in the past. But over two years is not that useful. From mpeters at mac.com Tue Feb 1 08:11:38 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 01 Feb 2005 08:11:38 +0000 Subject: radical suggestion for fc4 release In-Reply-To: <1107209076.5291.26.camel@opus.phy.duke.edu> (from skvidal@phy.duke.edu on Mon Jan 31 14:04:36 2005) References: <1107209076.5291.26.camel@opus.phy.duke.edu> Message-ID: <1107245498l.6399l.3l@devel.mpeters.us> Would commenting out the older changelogs just be enough to keep them out of the headers but still keep them in the spec file? From enrico.scholz at informatik.tu-chemnitz.de Tue Feb 1 08:58:11 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 01 Feb 2005 09:58:11 +0100 Subject: redhat abe In-Reply-To: <1107227358.5389.320.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 01 Feb 2005 04:09:18 +0100") References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> <1107219068.5389.239.camel@mccallum.corsepiu.local> <87acqpcckw.fsf@kosh.ultra.csn.tu-chemnitz.de> <1107227358.5389.320.camel@mccallum.corsepiu.local> Message-ID: <87651cd5cs.fsf@kosh.ultra.csn.tu-chemnitz.de> rc040203 at freenet.de (Ralf Corsepius) writes: >> >> Although I love apt for its powerful configuration, I have to admit that >> >> 'apt-get build-dep' is not very usefully in the rpm-world: >> >> >> >> * it detects only the requirements which were used to build the src.rpm, >> >> but not the deps which will be required >> > True, but ??? >> >> Ok, an example: > [conditionals in RPM specs] > > Well, IMO, any rpm which is part of a distribution should be rebuildable > by any arbitrary user/semi-newbie using > rpmbuild --rebuild ... > without having to provide any specific flags. The example does not violate that (e.g. think of using MySQL vs. PostgreSQL where MySQL is the default option). Or, there are lot of rpms with BuildRequires: influenced by the content of /etc/redhat-release... I just said that BuildRequires: must not be determined by the header of the src.rpm package. Enrico From mjc at redhat.com Tue Feb 1 09:28:45 2005 From: mjc at redhat.com (Mark J Cox) Date: Tue, 1 Feb 2005 09:28:45 +0000 (GMT) Subject: radical suggestion for fc4 release In-Reply-To: <604aa79105013114531c42b2c1@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> Message-ID: <0502010922400.21123@dell1.moose.awe.com> > Changelog entries that refer to specific bug numbers or CAN numbers can > be quite helpful in this regard. What would be incredibly useful is to move (to being a Provides) the CVE names for issues that we're including a backported fix for. Where we've moved to an upstream version that contains fixes those CVE names are less important as they can be deduced by a simple NV check. Just before each FC release the security team here go through a few years of security issues normalized to CVE names and make a list of how each FC package fixed it ("not vulnerable due to upstream version" or "contains backported fix"). It helps catch any missing fixes too ;) (This is something I'm thinking we'll try to do after our FC4 audit). Cheers, Mark From alexl at redhat.com Tue Feb 1 10:05:46 2005 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 01 Feb 2005 11:05:46 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1107200811.3777.41.camel@nexus.verbum.private> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> Message-ID: <1107252347.8471.135.camel@greebo> On Mon, 2005-01-31 at 14:46 -0500, Colin Walters wrote: > On Mon, 2005-01-31 at 13:42 -0600, Chris Adams wrote: > > Once upon a time, Bill Nottingham said: > > > Kyrre Ness Sjobak (kyrre at solution-forge.net) said: > > > > What about simple "play that .mp3, i want to know what's in it" kind of > > > > use? I must admit that i still use XMMS for that - it just works. Having > > > > a libary isn't always what you want. So i have xmms as my default player > > > > for all audio files. When i want to listen to an album i ripped (etc), i > > > > fire up rythmbox, import the files if neccessary, and play it. > > > > > > Commandline? madplay or similar. > > > > > > I'd assume in the filemanager there would be something small that > > > would launch on doubleclick. But I could be wrong. > > > > In FC3 (with MP3 support added via livna for xmms and gstreamer)), I > > opened nautilus and double clicked on an MP3. It brought up the Helix > > Player Setup Assistant. That just goes through the release notes (kind > > of dumb), then brings up a box that says that there is a "component > > missing" with a "Get RealPlayer" button. > > This is a complex issue, but basically what it boils down to is > that /usr/share/applications/defaults.list can only contain one > application for each MIME type. Once we fix that, we can ensure that > e.g. if you don't have HelixPlayer installed but do have totem, you get > totem. This is supported since gnome-vfs 2.8.3. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an underprivileged white trash cowboy with a winning smile and a way with the ladies. She's a scantily clad green-skinned single mother from a different time and place. They fight crime! From lowen at pari.edu Tue Feb 1 10:07:09 2005 From: lowen at pari.edu (Lamar Owen) Date: Tue, 1 Feb 2005 05:07:09 -0500 (EST) Subject: radical suggestion for fc4 release In-Reply-To: <1107245031l.6399l.2l@devel.mpeters.us> References: <1107209076.5291.26.camel@opus.phy.duke.edu><1107215124.21178.41.camel@localhost.localdomain><8cb89a60a94f88741f0d4e8b2228134d@linuxmail.org> <1107245031l.6399l.2l@devel.mpeters.us> Message-ID: <1316.64.53.29.127.1107252429.squirrel@mail.pari.edu> > On 01/31/2005 11:09:18 PM, Felipe Alfaro Solana wrote: >> Perhaps you could leave the full ChangeLog in the .spec file, but >> instruct rpmbuild to completely remove the ChangeLog except the last >> 10 entries. > or last two years - which sometimes is less than 10 entries. > I find them useful - to see how packagers dealt with specific changes > in the distro layout/functionallity in the past. But over two years is > not that useful. For the PostgreSQL RPMs I only kept the changelog for the current major version. I put a pointer at the bottom to look at the previous versions. Otherwise it would be over a thousand lines of changelog by now. This makes sense for PostgreSQL, which typically has had quite significant spec file revisions between major versions, things like entire subpackages being removed, added, etc. The build process has had to be completely started from scratch before due to improvements in the build (versions prior to 7.1 took significant steps to fully build all the various pieces; beginning with 7.1 the build was simplified somewhat. The 6.3.x builds can only be described as baroque.) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From fedora at wir-sind-cool.org Tue Feb 1 10:40:14 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 1 Feb 2005 11:40:14 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050131230157.GE29819@rogers.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> Message-ID: <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> On Mon, 31 Jan 2005 18:01:57 -0500, Dimitrie O. Paun wrote: > On Mon, Jan 31, 2005 at 05:37:29PM -0500, Eric S. Raymond wrote: > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > No, it's a *good* idea IMO. Problem is it does't go all the way. > WTH are changelogs doing in .spec files?!? This is the job of the version > control system, not of packaging specifications. Uhm, they document package changes. Ever taken a look at rpm --query --changelog kernel | less ? > It probably comes from the (misguided) school of thought that includes > $Log$ in source files... No. From rahulsundaram at gmail.com Tue Feb 1 10:44:45 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 1 Feb 2005 16:14:45 +0530 Subject: Starting sshd errors In-Reply-To: <1107207855.32622.6.camel@scrappy.netlyncs.com> References: <1107207855.32622.6.camel@scrappy.netlyncs.com> Message-ID: On Mon, 31 Jan 2005 15:44:15 -0600, Mike Chambers wrote: > Up until a few weeks (couple I guess) openssh was working fine. But now > when trying to start it, I get "initlog not found", which is around line > 107, when the /etc/init.d/sshd file has "initlog -c blah blah". you are probably running rawhide. in that case try updating to the latest version of initscripts and openssh packages -- Regards, Rahul Sundaram From rc040203 at freenet.de Tue Feb 1 11:13:27 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 12:13:27 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> Message-ID: <1107256407.5389.330.camel@mccallum.corsepiu.local> On Tue, 2005-02-01 at 11:40 +0100, Michael Schwendt wrote: > On Mon, 31 Jan 2005 18:01:57 -0500, Dimitrie O. Paun wrote: > > > On Mon, Jan 31, 2005 at 05:37:29PM -0500, Eric S. Raymond wrote: > > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > No, it's a *good* idea IMO. Problem is it does't go all the way. > > WTH are changelogs doing in .spec files?!? This is the job of the version > > control system, not of packaging specifications. > > Uhm, they document package changes. Do you document your changes inside of the source code? In my understanding, *specs are one part of rpm's sources. > > It probably comes from the (misguided) school of thought that includes > > $Log$ in source files... > > No. I disagree. Adding %changelogs to specs is not any different from $Log$. Having an entry in an rpm-header containing the last change might be useful for users being interested in the reason for a new rpm release, but I fail to understand why having a full %changelog-history inside of rpms or metadata files is useful. Ralf From fedora at wir-sind-cool.org Tue Feb 1 12:00:35 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 1 Feb 2005 13:00:35 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107256407.5389.330.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> Message-ID: <20050201130035.49c264cd.fedora@wir-sind-cool.org> On Tue, 01 Feb 2005 12:13:27 +0100, Ralf Corsepius wrote: > On Tue, 2005-02-01 at 11:40 +0100, Michael Schwendt wrote: > > On Mon, 31 Jan 2005 18:01:57 -0500, Dimitrie O. Paun wrote: > > > > > On Mon, Jan 31, 2005 at 05:37:29PM -0500, Eric S. Raymond wrote: > > > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > > > No, it's a *good* idea IMO. Problem is it does't go all the way. > > > WTH are changelogs doing in .spec files?!? This is the job of the version > > > control system, not of packaging specifications. > > > > Uhm, they document package changes. > Do you document your changes inside of the source code? > In my understanding, *specs are one part of rpm's sources. With RPM there is no other place where you can document package changes and make the same document appear also in the binary rpms. It is a matter of convenience. You can download a package, take a look at the package changes, then extract the ChangeLog file, if included, and if you want to look at software changes, too. The spec changelog is even more important when already installed software doesn't work as expected and you need access to the package changelog quickly. > > > It probably comes from the (misguided) school of thought that includes > > > $Log$ in source files... > > > > No. > I disagree. Adding %changelogs to specs is not any different from $Log$. Depends on what $Log$ expands to. You can put very useful comments in there which make a good reading. And everyone without immediate access to CVS would benefit from such comments, because they are included in source tarballs. > Having an entry in an rpm-header containing the last change might be > useful for users being interested in the reason for a new rpm release, > but I fail to understand why having a full %changelog-history inside of > rpms or metadata files is useful. Because not seldomly there are several package revisions between the "new rpm release" and the previous one. For instance, during steps from FC3 to FC4. From twaugh at redhat.com Tue Feb 1 12:11:39 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 1 Feb 2005 12:11:39 +0000 Subject: system-config-printer Message-ID: <20050201121139.GR5322@redhat.com> The tool we provide for configuring printers needs to change. The one we have works as designed, but unfortunately the design was that: * print queue configuration is stored in an XML file * a front-end interface allows the user to manipulate the XML file * a back-end program, which runs at spooler start-up time, writes out spooler-specific configuration based on the XML file There are several bad consequences of this: * the XML file format was and is inflexible * the configuration options are limited to those common to both spoolers we were shipping at the time the XML format was decided * it is VERY SLOW: you can't *modify* configuration, only write out entirely new configurations (i.e. trigger the back-end) * again, due to the XML format chosen, we are tied to the foomatic database in such as way that we absolutely require foomatic to know about the printer before we can configure it. Even if you have the manufacturer's PPD file, there is very little you can do to get your printer working. * changes made using the CUPS configuration interface (http://localhost:631/), or any other method external to system-config-printer, are not reflected in the XML file and so cannot be modified. * changes made using system-config-printer cannot be modified using other tools, since changes will be overwritten. and so on. Does anyone have ideas for how system-config-printer should be re-written? Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at welho.com Tue Feb 1 13:07:47 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 1 Feb 2005 15:07:47 +0200 (EET) Subject: radical suggestion for fc4 release In-Reply-To: <604aa79105013114531c42b2c1@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> Message-ID: On Mon, 31 Jan 2005, Jeff Spaleta wrote: > On Mon, 31 Jan 2005 17:43:32 -0500, Jeff Johnson wrote: >> With no offense whatsoever to anyone, I humbly submit that the comments in >> the changelog are of rather limited use to any non-redhat developer, and are >> totally useless to any end-user. > > I don't know about totally useless. I've refered to changelogs in the > past to track down issues when troubleshooting issues concerned when a > certain bugfix or security fix have been applied. Changelog entries > that refer to specific bug numbers or CAN numbers can be quite helpful > in this regard. Limited, but not totally useless value. I will conceed > that I could probably use a web lookup for all this information if it > were made the primary means of access to changelogs. And I would be > more at ease with losing the changelogs in the package completely if > package update notification texts containing the information were more > closely aligned with package update mechanisms. Package changelogs are anything but useless, I refer to them all the time. Dunno if others have noticed but I think the rpm changelogs have become much more useful and informative now that the rawhide changelog deltas are mailed to a public list :) Sure, go ahead and nuke ancient entries from specs. The info is available in cvs and old packages for archeologists to dig if interested, a normal user is only interested in the few last changes, eg "this update broke my xxxx - what changed?". I personally wouldn't mind if rpm -q --changelog just fetched the changelog info directly from cvs (or web, or whatever) either, just as long as the information is handily available. - Panu - From buildsys at redhat.com Tue Feb 1 13:11:17 2005 From: buildsys at redhat.com (Build System) Date: Tue, 1 Feb 2005 08:11:17 -0500 Subject: rawhide report: 20050201 changes Message-ID: <200502011311.j11DBHX32618@porkchop.devel.redhat.com> From rahulsundaram at gmail.com Tue Feb 1 13:26:16 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 1 Feb 2005 18:56:16 +0530 Subject: system-config-printer In-Reply-To: <20050201121139.GR5322@redhat.com> References: <20050201121139.GR5322@redhat.com> Message-ID: Hi > > Does anyone have ideas for how system-config-printer should be > re-written? IMO gnome system tools or something similar are the way forward. a whole lot of system-config* only takes care of very basic configuration details. we need better cross distro gui tools -- Regards, Rahul Sundaram From alan at redhat.com Tue Feb 1 13:32:46 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 1 Feb 2005 08:32:46 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050201024420.GB32755@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> Message-ID: <20050201133246.GG32566@devserv.devel.redhat.com> On Mon, Jan 31, 2005 at 09:44:21PM -0500, Eric S. Raymond wrote: > Is that a problem? Processors are speeding up faster than media are > getting larger -- thus, trdsing clocks for space seems like the > right thing. Processors are close to stopped on growth. 1990 386DX40 150Mb 2005 AMD64@~3GHz 400Gb Its actually not clear that this is true, especially as bzip2 performance is heavily RAM not cache dependant and RAM hasnt scaled at all well (damned speed of light is just too low...) Alan From dpaun at rogers.com Tue Feb 1 13:37:03 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Tue, 1 Feb 2005 08:37:03 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050201130035.49c264cd.fedora@wir-sind-cool.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> Message-ID: <20050201133703.GN5673@rogers.com> On Tue, Feb 01, 2005 at 01:00:35PM +0100, Michael Schwendt wrote: > > I disagree. Adding %changelogs to specs is not any different from $Log$. > > Depends on what $Log$ expands to. You can put very useful comments in > there which make a good reading. And everyone without immediate access to > CVS would benefit from such comments, because they are included in source > tarballs. See, same argument people give for $Log$. As I initially said, just like the $Log$ comments are misguided, so are complete changelogs in .spec files. Useful comments that are akin to comments in a regular source files are commonly included in .spec files. Those are fine, nobody argues agaist them. Changelog entries are something else, and they just don't belong there. If they are needed, they should just be in a separate file, but I suspect a link to a cvsweb/viewcvs for the CVS repository of the .spec file would be enough. -- Dimi. From rc040203 at freenet.de Tue Feb 1 14:46:58 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Feb 2005 15:46:58 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050201130035.49c264cd.fedora@wir-sind-cool.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> Message-ID: <1107269219.5389.345.camel@mccallum.corsepiu.local> On Tue, 2005-02-01 at 13:00 +0100, Michael Schwendt wrote: > On Tue, 01 Feb 2005 12:13:27 +0100, Ralf Corsepius wrote: > > > On Tue, 2005-02-01 at 11:40 +0100, Michael Schwendt wrote: > > > On Mon, 31 Jan 2005 18:01:57 -0500, Dimitrie O. Paun wrote: > > > > > > > On Mon, Jan 31, 2005 at 05:37:29PM -0500, Eric S. Raymond wrote: > > > > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > > > > > No, it's a *good* idea IMO. Problem is it does't go all the way. > > > > WTH are changelogs doing in .spec files?!? This is the job of the version > > > > control system, not of packaging specifications. > > > > > > Uhm, they document package changes. > > Do you document your changes inside of the source code? > > In my understanding, *specs are one part of rpm's sources. > > With RPM there is no other place where you can document package changes > and make the same document appear also in the binary rpms. A matter of design and policy ... this is fedora-devel@ ... so to me your sentence is nothing but evidence for a deficiency either in rpm's implementation or RH's policy ... > It is a matter > of convenience. You can download a package, take a look at the package > changes, then extract the ChangeLog file, if included, and if you want to > look at software changes, too. The spec changelog is even more important > when already installed software doesn't work as expected and you need > access to the package changelog quickly. No, you are missing up a package's contents ChangeLog with the rpm's changelog. The only reason to look into an rpm's changelog is to find answers questions related to "Why has this rpm been released?". Normally you won't find answers to "What has changed inside of the package's contents." > > > > It probably comes from the (misguided) school of thought that includes > > > > $Log$ in source files... > > > > > > No. > > I disagree. Adding %changelogs to specs is not any different from $Log$. > > Depends on what $Log$ expands to. Here you say it: It's all about packaging policy. Seth said he wants to feed rss from rpm changelogs, and wants to reduce the size of changelog entries in other.xml, you want to see the changelogs from the rpm, I don't see any use for changelog histories. => Implement a reasonable %changelog policy. E.g. Add only those %changelogs to an rpm.spec that reach back to the preceding release and remove everything else. Frankly speaking, the only situation I have found rpm.specs useful sofar, was to dig out the responsible maintainer of a package to get in direct contact to him. Using a dedicated rpm-header for this purpose (e.g. packager) would seem much more reasonable to me, but I am not in a position to change RH nor to enforce this policy. > > Having an entry in an rpm-header containing the last change might be > > useful for users being interested in the reason for a new rpm release, > > but I fail to understand why having a full %changelog-history inside of > > rpms or metadata files is useful. > > Because not seldomly there are several package revisions between the "new > rpm release" and the previous one. For instance, during steps from FC3 to > FC4. Again, this is just a matter of policy. Ralf From jspaleta at gmail.com Tue Feb 1 14:50:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 Feb 2005 09:50:02 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <0502010922400.21123@dell1.moose.awe.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> Message-ID: <604aa79105020106504267a7bb@mail.gmail.com> On Tue, 1 Feb 2005 09:28:45 +0000 (GMT), Mark J Cox wrote: > What would be incredibly useful is to move (to being a Provides) the CVE > names for issues that we're including a backported fix for. Where we've > moved to an upstream version that contains fixes those CVE names are less > important as they can be deduced by a simple NV check. I look forward to building pathological packages that have a requires on a CVE name provides. -jef From katzj at redhat.com Tue Feb 1 14:52:04 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 Feb 2005 09:52:04 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <0502010922400.21123@dell1.moose.awe.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> Message-ID: <1107269524.25433.10.camel@bree.local.net> On Tue, 2005-02-01 at 09:28 +0000, Mark J Cox wrote: > > Changelog entries that refer to specific bug numbers or CAN numbers can > > be quite helpful in this regard. > > What would be incredibly useful is to move (to being a Provides) the CVE > names for issues that we're including a backported fix for. Where we've > moved to an upstream version that contains fixes those CVE names are less > important as they can be deduced by a simple NV check. This really feels like the wrong place to put this information. Then, if we're not vulnerable for whatever reason, the provides isn't there and people think that it is. So, now we have to do an update to add a provides. And even if we say that newer versions don't need it, people will want it because doing a two-step process of "check version, check CAN" means they'll only do one step ;) This just feels like metadata that doesn't belong in the package to me... Jeremy From arjanv at redhat.com Tue Feb 1 15:02:25 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 01 Feb 2005 16:02:25 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <604aa79105020106504267a7bb@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> Message-ID: <1107270145.4208.119.camel@laptopd505.fenrus.org> On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote: > On Tue, 1 Feb 2005 09:28:45 +0000 (GMT), Mark J Cox wrote: > > What would be incredibly useful is to move (to being a Provides) the CVE > > names for issues that we're including a backported fix for. Where we've > > moved to an upstream version that contains fixes those CVE names are less > > important as they can be deduced by a simple NV check. > > I look forward to building pathological packages that have a requires > on a CVE name provides. fedora-secure-system could require all the CVE's that are ciritical to be fixed yum update fedora-secure-system would then only pull security updates down.... -------------- next part -------------- A 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 1 15:10:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 10:10:02 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107270145.4208.119.camel@laptopd505.fenrus.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> Message-ID: <1107270602.25100.86.camel@cutter> On Tue, 2005-02-01 at 16:02 +0100, Arjan van de Ven wrote: > On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote: > > On Tue, 1 Feb 2005 09:28:45 +0000 (GMT), Mark J Cox wrote: > > > What would be incredibly useful is to move (to being a Provides) the CVE > > > names for issues that we're including a backported fix for. Where we've > > > moved to an upstream version that contains fixes those CVE names are less > > > important as they can be deduced by a simple NV check. > > > > I look forward to building pathological packages that have a requires > > on a CVE name provides. > > fedora-secure-system > > could require all the CVE's that are ciritical to be fixed > yum update fedora-secure-system > would then only pull security updates down.... I agree with Jeremy. I think this is data that should be housed outside of the package. We're going to need to figure out how to do this anyway. -sv From Nigel.Metheringham at dev.intechnology.co.uk Tue Feb 1 15:28:34 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Tue, 01 Feb 2005 15:28:34 +0000 Subject: radical suggestion for fc4 release In-Reply-To: <1107270145.4208.119.camel@laptopd505.fenrus.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> Message-ID: <1107271714.11449.27.camel@angua.localnet> On Tue, 2005-02-01 at 16:02 +0100, Arjan van de Ven wrote: > On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote: > > I look forward to building pathological packages that have a requires > > on a CVE name provides. > > fedora-secure-system > > could require all the CVE's that are ciritical to be fixed > yum update fedora-secure-system > would then only pull security updates down.... This sort of requires a way to handle packages that you don't install - for example package flurble needs an empty package not-flurble (which conflicts with flurble) so that when CAN-9999-999 is issued for flurble, which then means fedora-secure-system now requires CAN-9999-999, a new empty not-flurble can also provide the CVE name. The alternative is that following a CVE issue everyone's box gets a (hopefully fixed) version of the vulnerable package even if they were not running in previously. This makes my head hurt. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From johnp at redhat.com Tue Feb 1 15:43:00 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 01 Feb 2005 10:43:00 -0500 Subject: system-config-printer In-Reply-To: References: <20050201121139.GR5322@redhat.com> Message-ID: <1107272580.32198.99.camel@remedyz.boston.redhat.com> On Tue, 2005-02-01 at 18:56 +0530, Rahul Sundaram wrote: > Hi > > > > Does anyone have ideas for how system-config-printer should be > > re-written? > > IMO gnome system tools or something similar are the way forward. a > whole lot of system-config* only takes care of very basic > configuration details. we need better cross distro gui tools A quick glance at gnome-system-tools web page and we see that it doesn't have a printing capplet. Even then I believe that GST isn't the right way to go as a whole since it makes us a lot less flexible in certain ways. Basically I feel we should be looking forward ask ourselves how should a system be configured five years from now. Then again I look at printer configuration from the users perspective where I just want things to work without the user configuring anything. A good sysadmin tool is needed also but it must work seamlessly with the user tools. I have a bunch of ideas and wants for system-config-printer that I will post later. Colin Walters and I were discussing the whole printer mess with Jody from Novell at last years Gnome Summit and we came up with GUP (Grand Unified Printing) which I believe has a CVS module in Gnome but it kind of fizzled from there. Perhaps this is a good time to resurrect it and do all the work upstream. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From n3npq at nc.rr.com Tue Feb 1 15:47:51 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 01 Feb 2005 10:47:51 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107269524.25433.10.camel@bree.local.net> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <1107269524.25433.10.camel@bree.local.net> Message-ID: <41FFA4A7.7000802@nc.rr.com> Jeremy Katz wrote: >On Tue, 2005-02-01 at 09:28 +0000, Mark J Cox wrote: > > >>>Changelog entries that refer to specific bug numbers or CAN numbers can >>>be quite helpful in this regard. >>> >>> >>What would be incredibly useful is to move (to being a Provides) the CVE >>names for issues that we're including a backported fix for. Where we've >>moved to an upstream version that contains fixes those CVE names are less >>important as they can be deduced by a simple NV check. >> >> > >This really feels like the wrong place to put this information. Then, >if we're not vulnerable for whatever reason, the provides isn't there >and people think that it is. So, now we have to do an update to add a >provides. And even if we say that newer versions don't need it, people >will want it because doing a two-step process of "check version, check >CAN" means they'll only do one step ;) > Unlike, say Provides: shared-library or Provides: kernel-abi = 2.6 or Provide: LSB a CAN or CVE marker usually has a patch to package sources. Since a patch forces a rebuild, adding the Provides: is no additional work. Yes, retrofiiting the scheme will involve arbitrary additions to existing packages, but that can't be helped. What still would be lacking is a hard, well defined, test that, indeed, that the Provides: is accurate. In other words, there is the risk of false comfort if onl the Provides: is checked, any package might supply a false Provides:. So the package or header signature check is a necessary part of verifying a CAN or CVE Provides: Distributing the exploit with the Provides: would be one way to insure that the CAN or CVE Provides: could be tested widely (but distributing exploits has other issues of course ;-) >This just feels like metadata that doesn't belong in the package to >me... > > I'd say that a CAN/CVE marker belongs in a package because it is indicating that the package includeds the appropriate and approved patch. Any other scheme to attach meta-metadata with a package will be harder to vet and maintain. 73 de Jeff From mjc at redhat.com Tue Feb 1 16:12:14 2005 From: mjc at redhat.com (Mark J Cox) Date: Tue, 1 Feb 2005 16:12:14 +0000 (GMT) Subject: radical suggestion for fc4 release In-Reply-To: <1107271714.11449.27.camel@angua.localnet> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> Message-ID: <0502011602480.23728@dell1.moose.awe.com> > The alternative is that following a CVE issue everyone's box gets a > (hopefully fixed) version of the vulnerable package even if they were > not running in previously. The real point of using Provides is simply to give a definitive label that a package contains a backported fix for a particular named security issue - not that a package is or isn't vulnerable to an issue, and not to help keep a system up to date with security issues, or help enforce any security policies - Project like OVAL (http://oval.mitre.org) are designed to do that sort of thing. The Provides would go away once the backported patch was removed (due to moving to a newer upstream version etc) Right now to determine if a particular issue is fixed you need to search the changelog, and if nothing is mentioned, unpack the SRPM, then look in each of the patches to see if the CVE name is mentioned, and if not if the patches included vaugely matches the patch for the issue. We do this in our pre-release audit - packages are horribly inconsistant. Mark From jspaleta at gmail.com Tue Feb 1 16:21:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 Feb 2005 11:21:12 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <0502011602480.23728@dell1.moose.awe.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <0502011602480.23728@dell1.moose.awe.com> Message-ID: <604aa79105020108213eee2c47@mail.gmail.com> On Tue, 1 Feb 2005 16:12:14 +0000 (GMT), Mark J Cox wrote: > Right now to determine if a particular issue is fixed you need to search > the changelog, and if nothing is mentioned, unpack the SRPM, then look in > each of the patches to see if the CVE name is mentioned, and if not if the > patches included vaugely matches the patch for the issue. We do this in > our pre-release audit - packages are horribly inconsistant. I'm not sure how turning this into a provides garuntees consistency. It still comes down whether or not a packager sticks the provides in manually.. not much different than sticking in a note in the changelog. Either one is easily forgotten by a packager. Bugzilla is riddled with bugs about missing provides and requires that are manually created by the packager. I don't see how moving it out of the changelog creates a consistency win. But please consider that by encoding this information into a provides you are polluting the provides namespace that depsolvers are using with information that you have no intention of using like a dependancy. This will lead to unexpected problems.. when 'some' packagers get the bright idea to actually do a dependancy on this, that depsolves will have to negotiated. Maybe if the intent of the provides doesn't include using it as part of depsolving.. maybe this is the wrong place to encode this information. -jef From riel at redhat.com Tue Feb 1 16:25:09 2005 From: riel at redhat.com (Rik van Riel) Date: Tue, 1 Feb 2005 11:25:09 -0500 (EST) Subject: Space-time tradeoffs (was: Re: radical suggestion for fc4 release) In-Reply-To: <20050201053053.GB13501@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> <41FEF17A.30005@nc.rr.com> <20050201053053.GB13501@thyrsus.com> Message-ID: On Tue, 1 Feb 2005, Eric S. Raymond wrote: > OK, here is an answer. Here's another one ;) > Processor clocks are getting cheaper faster than memory is. Memory is > getting cheaper faster than disk is. Disk is getting cheaper a *lot* > faster than bits-per-second of bandwidth. Memory is getting bigger a lot faster than it is getting faster. Disk is getting bigger a lot faster than it is getting faster. No matter at which part of a computer system you look, space increases more than speed does. > The "right" tradeoff is to use lots of cheap resources in order to be > able to use fewer expensive resources. Therefore, as these trends > continue, ... we no longer need to care as much about the size of files, since the real bottleneck is how fast we can get at the data. I know my ADSL can download bzip2 files faster than I can decompress them... There is no perfect answer, but gzip seems to provide a good compromise between fast and small. -- "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 eli.carter at inet.com Tue Feb 1 16:27:56 2005 From: eli.carter at inet.com (Eli Carter) Date: Tue, 01 Feb 2005 10:27:56 -0600 Subject: radical suggestion for fc4 release In-Reply-To: <1107271714.11449.27.camel@angua.localnet> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> Message-ID: <41FFAE0C.5000705@inet.com> Nigel Metheringham wrote: > On Tue, 2005-02-01 at 16:02 +0100, Arjan van de Ven wrote: > >>On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote: >> >>>I look forward to building pathological packages that have a requires >>>on a CVE name provides. >> >>fedora-secure-system >> >>could require all the CVE's that are ciritical to be fixed >>yum update fedora-secure-system >>would then only pull security updates down.... > > > This sort of requires a way to handle packages that you don't install - > for example package flurble needs an empty package not-flurble (which > conflicts with flurble) so that when CAN-9999-999 is issued for flurble, > which then means fedora-secure-system now requires CAN-9999-999, a new > empty not-flurble can also provide the CVE name. ... > This makes my head hurt. How about fedora-secure-system have Conflicts: flurble <= # CAN-9999-999 If a package is known to be vulnerable, it conflicts with a secure system. Wouldn't that accomplish what you want? It will install in the absence of flurble, but if a vulnerable version is installed, it will (should?) cause an upgrade. Hmm.... And if there is no upgrade available, maybe a remove... In fact, I kind of like that idea. Update fedora-secure-system immediately upon disclosure of a problem, even in absense of a fix. Sysadmins can decide to uninstall or remain insecure based on whatever their constraints are. Thoughts? Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Tektronix Texas, LLC formerly Inet Technologies, Inc. ------------------------------------------------------------------------ From n3npq at nc.rr.com Tue Feb 1 16:29:28 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 01 Feb 2005 11:29:28 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <604aa79105020108213eee2c47@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <0502011602480.23728@dell1.moose.awe.com> <604aa79105020108213eee2c47@mail.gmail.com> Message-ID: <41FFAE68.8070407@nc.rr.com> Jeff Spaleta wrote: >On Tue, 1 Feb 2005 16:12:14 +0000 (GMT), Mark J Cox wrote: > > >>Right now to determine if a particular issue is fixed you need to search >>the changelog, and if nothing is mentioned, unpack the SRPM, then look in >>each of the patches to see if the CVE name is mentioned, and if not if the >>patches included vaugely matches the patch for the issue. We do this in >>our pre-release audit - packages are horribly inconsistant. >> >> > > >I'm not sure how turning this into a provides garuntees consistency. >It still comes down whether or not a packager sticks the provides in >manually.. not much different than sticking in a note in the >changelog. Either one is easily forgotten by a packager. Bugzilla is >riddled with bugs about missing provides and requires that are >manually created by the packager. I don't see how moving it out of the >changelog creates a consistency win. > > A packager who choses not to add the Provides: changes nothing, the audit will be done. Notes in changelogs are not easily automated, nor does rpm have keyword indices for changelogs. Bugzilla is riddle with missing Requires:, not missing Provides:, as packagers only notice what is obvious, and an unmatched Requires: is invariably full stop. That is not the mechanism being suggested for CAN/CVE entries. >But please consider that by encoding this information into a provides >you are polluting the provides namespace that depsolvers are using >with information that you have no intention of using like a >dependancy. This will lead to unexpected problems.. when 'some' >packagers get the bright idea to actually do a dependancy on this, >that depsolves will have to negotiated. Maybe if the intent of the >provides doesn't include using it as part of depsolving.. maybe this >is the wrong place to encode this information. > > The provides name space is there to be used, "polluting" is bottom trolling. 73 de Jeff From eli.carter at inet.com Tue Feb 1 16:39:23 2005 From: eli.carter at inet.com (Eli Carter) Date: Tue, 01 Feb 2005 10:39:23 -0600 Subject: radical suggestion for fc4 release In-Reply-To: <41FFAE0C.5000705@inet.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <41FFAE0C.5000705@inet.com> Message-ID: <41FFB0BB.3090109@inet.com> Eli Carter wrote: > How about fedora-secure-system have > Conflicts: flurble <= # CAN-9999-999 > > If a package is known to be vulnerable, it conflicts with a secure system. Some other ideas: fedora-secure-system Requires: fedora-secure-remote-root Requires: fedora-secure-local-root Requires: fedora-secure-remote-user Requires: fedora-secure-other # ? fedora-secure-remote-root would conflict with all packages vulnerable to remote root exploits fedora-secure-local-root would conflict with all packages vulnerable to local root exploits. ... etc. That would allow a sysadmin to take the approach of: "I trust all my users, but I can't afford to have any remote exploits, and I need minimal change" => install fedora-secure-remote-root and fedora-secure-remote-user, but not fedora-secure-local-root. Thoughts? Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Tektronix Texas, LLC formerly Inet Technologies, Inc. ------------------------------------------------------------------------ From n3npq at nc.rr.com Tue Feb 1 16:41:26 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 01 Feb 2005 11:41:26 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <41FFAE0C.5000705@inet.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <41FFAE0C.5000705@inet.com> Message-ID: <41FFB136.7040904@nc.rr.com> Eli Carter wrote: > Nigel Metheringham wrote: > >> On Tue, 2005-02-01 at 16:02 +0100, Arjan van de Ven wrote: >> >>> On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote: >>> >>>> I look forward to building pathological packages that have a requires >>>> on a CVE name provides. >>> >>> >>> fedora-secure-system >>> could require all the CVE's that are ciritical to be fixed yum >>> update fedora-secure-system would then only pull security updates >>> down.... >> >> >> >> This sort of requires a way to handle packages that you don't install - >> for example package flurble needs an empty package not-flurble (which >> conflicts with flurble) so that when CAN-9999-999 is issued for flurble, >> which then means fedora-secure-system now requires CAN-9999-999, a new >> empty not-flurble can also provide the CVE name. > > ... > >> This makes my head hurt. > > > How about fedora-secure-system have > Conflicts: flurble <= # CAN-9999-999 > > If a package is known to be vulnerable, it conflicts with a secure > system. > > Wouldn't that accomplish what you want? It will install in the > absence of flurble, but if a vulnerable version is installed, it will > (should?) cause an upgrade. > > Hmm.... And if there is no upgrade available, maybe a remove... In > fact, I kind of like that idea. Update fedora-secure-system > immediately upon disclosure of a problem, even in absense of a fix. > Sysadmins can decide to uninstall or remain insecure based on whatever > their constraints are. Package metadata is not sufficiently reliable to be trusted to automagically insturment package choices based on security tags. Who *exactly* determines the reliability of the tags that are in Conflict:? On my systems, that answer is: Me and me alone. 73 de Jeff From fedora at wir-sind-cool.org Tue Feb 1 16:44:02 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 1 Feb 2005 17:44:02 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107269219.5389.345.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> Message-ID: <20050201174402.3b977bd5.fedora@wir-sind-cool.org> On Tue, 01 Feb 2005 15:46:58 +0100, Ralf Corsepius wrote: > > It is a matter > > of convenience. You can download a package, take a look at the package > > changes, then extract the ChangeLog file, if included, and if you want to > > look at software changes, too. The spec changelog is even more important > > when already installed software doesn't work as expected and you need > > access to the package changelog quickly. > No, you are missing up a package's contents ChangeLog with the rpm's changelog. > ? > The only reason to look into an rpm's changelog is to find answers > questions related to "Why has this rpm been released?". As in whether any bugs were fixed, features added/removed, default configuration changed, important files relocated or dropped, ... there's a lot that makes sense to be mentioned in an rpm package %changelog. > Normally you won't find answers to "What has changed inside of the > package's contents." No, for that you see what %doc files are included and take a look at those. "rpm --query --docfiles ..." From jos at xos.nl Tue Feb 1 16:47:00 2005 From: jos at xos.nl (Jos Vos) Date: Tue, 01 Feb 2005 17:47:00 +0100 Subject: 802.1X support for Fedora Message-ID: <200502011647.j11Gl0Z00730@xos037.xos.nl> Hi, What is the status of 802.1X support (open1x/xsupplicant?) in Fedora? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From green at redhat.com Tue Feb 1 16:42:39 2005 From: green at redhat.com (Anthony Green) Date: Tue, 01 Feb 2005 08:42:39 -0800 Subject: Building subversion javahl bindings In-Reply-To: <41E7CB99.1050804@mndfck.org> References: <41E7CB99.1050804@mndfck.org> Message-ID: <1107276159.5448.23.camel@to-dhcp29.toronto.redhat.com> On Fri, 2005-01-14 at 11:39 -0200, Pedro Lamar?o wrote: > I've got this patch to subversion.spec that allows optional building of > javahl bindings with a variable-specified JDK path. > I've built it as I need Subclipse to work. > What do you all think? I modified this patch to build javahl unconditionally with java-gcj- compat. I hit a couple of stumbling blocks. I think fitzsim is fixing one of them in java-gcj-compat (symlinking GCC's jni.h into java-gcj-compat's JAVA_HOME), and this one in gcjh: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19742 Otherwise, it builds just fine. Hopefully both of these will be taken care of in short order. AG From jspaleta at gmail.com Tue Feb 1 17:02:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 Feb 2005 12:02:32 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <41FFAE68.8070407@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <0502011602480.23728@dell1.moose.awe.com> <604aa79105020108213eee2c47@mail.gmail.com> <41FFAE68.8070407@nc.rr.com> Message-ID: <604aa791050201090277fc613f@mail.gmail.com> On Tue, 01 Feb 2005 11:29:28 -0500, Jeff Johnson wrote: > The provides name space is there to be used, "polluting" is bottom trolling. I think the discussion already generated in this thread about fedora-secure-system is an indication of the ploblematic nature of casting this information into the provides of Core packages. Provides are there to be used... surely.. and easily misused. Using this provides for internal audit sure seems like a slick solution for internal needs... but at the same time exposing this information to external users in a way that makes it quite easy to misuse as mechanism in depsolving. As soon as Core drops these provides in, packagers will start playing with providing fedora-secure-system like metapackages that use these provides. If the original intent for creating the provides is solely for internal auditing needs, is it appropriate to expose to everyone in this way? -jef From rahulsundaram at yahoo.co.in Tue Feb 1 16:10:43 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Tue, 1 Feb 2005 08:10:43 -0800 (PST) Subject: system-config-printer In-Reply-To: <1107272580.32198.99.camel@remedyz.boston.redhat.com> Message-ID: <20050201161043.31684.qmail@web8509.mail.in.yahoo.com> Hi > > A quick glance at gnome-system-tools web page and we > see that it doesn't > have a printing capplet. it doesnt. since a rewrite is planned, we could use gst framework for the new tool. Even then I believe that > GST isn't the right > way to go as a whole since it makes us a lot less > flexible in certain > ways. can you expand on that? Basically I feel we should be looking forward > ask ourselves how > should a system be configured five years from now. > Then again I look at > printer configuration from the users perspective > where I just want > things to work without the user configuring > anything. A good sysadmin > tool is needed also but it must work seamlessly with > the user tools. I > have a bunch of ideas and wants for > system-config-printer that I will > post later. Colin Walters and I were discussing the > whole printer mess > with Jody from Novell at last years Gnome Summit and > we came up with GUP > (Grand Unified Printing) which I believe has a CVS > module in Gnome but > it kind of fizzled from there. Perhaps this is a > good time to resurrect > it and do all the work upstream. yep. upstream cross distro tools was the kind of approach I was talking about ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From mjc at redhat.com Tue Feb 1 17:15:32 2005 From: mjc at redhat.com (Mark J Cox) Date: Tue, 1 Feb 2005 17:15:32 +0000 (GMT) Subject: radical suggestion for fc4 release In-Reply-To: <604aa791050201090277fc613f@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <0502011602480.23728@dell1.moose.awe.com> <604aa79105020108213eee2c47@mail.gmail.com> <41FFAE68.8070407@nc.rr.com> <604aa791050201090277fc613f@mail.gmail.com> Message-ID: <0502011713010.24056@dell1.moose.awe.com> > metapackages that use these provides. If the original intent for > creating the provides is solely for internal auditing needs, is it > appropriate to expose to everyone in this way? Actually it's to assert that we're providing a backported patch for a security issue in a package. This is incredibly useful to end users, especially those who have to respond to auditors (we get many requests along these lines, where a customer wants to be able to show an auditor that the old version of, say, OpenSSH, contains a fix for some particular named issue). Cheers, Mark From ronny-vlug at vlugnet.org Tue Feb 1 18:00:22 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Tue, 1 Feb 2005 19:00:22 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106437234.4047.1.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <20050122165044.GE2898@devserv.devel.redhat.com> <1106437234.4047.1.camel@localhost.localdomain> Message-ID: <200502011900.22684.ronny-vlug@vlugnet.org> On Sunday 23 January 2005 00:40, Kyrre Ness Sjobak wrote: > But what about mtools? Isn't that "dos-style handling of floppyes"? +1 the linux way of handling removable media is just fine, we don't need drive letters -- http://LinuxWiki.org/RonnyBuchmann From michael.favia at insitesinc.com Tue Feb 1 18:09:20 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 01 Feb 2005 12:09:20 -0600 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <41FB6D1E.2040203@www.linux.org.uk> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <1106949449.25801.36.camel@rousalka.dyndns.org> <41FB6D1E.2040203@www.linux.org.uk> Message-ID: <41FFC5D0.8060407@insitesinc.com> Mike A. Harris wrote: > > Ok, rest your eyes now before reading any more email. > > ;) Thank you for the concise and well written summary of development. I was always a little confused about it's mixed origins. -mf From czar at czarc.net Tue Feb 1 18:47:30 2005 From: czar at czarc.net (Gene C.) Date: Tue, 1 Feb 2005 13:47:30 -0500 Subject: FC1/FC3/FC4 e2fs compatibility Message-ID: <200502011347.30764.czar@czarc.net> I recently noticed that e2fsck running on a FC1 system would not run against a partition created under FC3. If I rebuilt the e2fsprogs package from FC3 on FC1, that would work. So my question: Assume that selinux is disabled, are there any problems accessing partitions created and used by a FC1, FC2 or FC4(rawhide) system with another FC1, FC3 or FC4 system. Would everything be OK? Would anything be corrupted? -- Gene From Nicolas.Mailhot at laPoste.net Tue Feb 1 18:58:50 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 19:58:50 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <604aa791050131144466ce7ed7@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <604aa791050131144466ce7ed7@mail.gmail.com> Message-ID: <1107284330.21078.27.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 17:44 -0500, Jeff Spaleta a ?crit : > On Mon, 31 Jan 2005 17:37:29 -0500, Eric S. Raymond wrote: > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > If changelogs are bloating the headers yum has to download, then > > strip them out when generating the yum headers. > > they bloat the packages as well... which means they bloat the install > media and bloat the download times over the network. > > I'm hard pressed to think of a real-world situation where 2 year old > package changelog notations in the packages are needed. Shouldn't > access to the cvs server suffice for deep-diving into package > changelogs? Aren't changelogs compressed yet ? I'm very surprised simple flat text data can make such a significant difference these days (the yum problem OTOH is real but can't yum truncat the changelogs it exports all by itself ?) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Feb 1 19:03:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 14:03:20 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107284330.21078.27.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <604aa791050131144466ce7ed7@mail.gmail.com> <1107284330.21078.27.camel@rousalka.dyndns.org> Message-ID: <1107284600.25100.107.camel@cutter> > Aren't changelogs compressed yet ? > I'm very surprised simple flat text data can make such a significant > difference these days (the yum problem OTOH is real but can't yum > truncat the changelogs it exports all by itself ?) 1. we're not just talking about it for yum. 2. I could truncate them in createrepo, sure but the question is why are we keeping all this stuff on cds in 5 different places and why are we keeping it AT ALL on the cds. -sv From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:02:24 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:02:24 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107256407.5389.330.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> Message-ID: <1107284544.21078.31.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 12:13 +0100, Ralf Corsepius a ?crit : > I disagree. Adding %changelogs to specs is not any different from $Log$. > > Having an entry in an rpm-header containing the last change might be > useful for users being interested in the reason for a new rpm release, > but I fail to understand why having a full %changelog-history inside of > rpms or metadata files is useful. All that means is you never maintained a complex RH/FC system for a long period. rpm changelogs are the first line of defense to understand what the heck happened to hose a long-working system. On Raw Hide they are as vital as the admin coffee. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:03:38 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:03:38 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050201133703.GN5673@rogers.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <20050201133703.GN5673@rogers.com> Message-ID: <1107284618.21078.33.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 08:37 -0500, Dimitrie O. Paun a ?crit : > If they are needed, they should just be in a separate file, but I > suspect a link to a cvsweb/viewcvs for the CVS repository of the > .spec file would be enough. Much good it will do you if the problem rpm killed your network link. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Feb 1 19:07:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 14:07:09 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107284544.21078.31.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> Message-ID: <1107284829.25100.109.camel@cutter> > All that means is you never maintained a complex RH/FC system for a long > period. > > rpm changelogs are the first line of defense to understand what the heck > happened to hose a long-working system. On Raw Hide they are as vital as > the admin coffee. And keeping the last 6 months or a year of them is fine. but cmon - do we really need 7 yrs or more worth of changelogs IN the rpm? -sv From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:06:24 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:06:24 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107269219.5389.345.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> Message-ID: <1107284784.21078.37.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 15:46 +0100, Ralf Corsepius a ?crit : > => Implement a reasonable %changelog policy. > > E.g. Add only those %changelogs to an rpm.spec that reach back to the > preceding release and remove everything else. A lot of production systems are not upgraded continuously but when the admin has time to spend in front of them - ie version jump is *very* common (in some cases multi-year cross release rebuilds to accommodate an old workhorse nobody wants to reinstall from scratch) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:09:45 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:09:45 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107284829.25100.109.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> Message-ID: <1107284985.21078.40.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 14:07 -0500, seth vidal a ?crit : > > All that means is you never maintained a complex RH/FC system for a long > > period. > > > > rpm changelogs are the first line of defense to understand what the heck > > happened to hose a long-working system. On Raw Hide they are as vital as > > the admin coffee. > > And keeping the last 6 months or a year of them is fine. > > but cmon - do we really need 7 yrs or more worth of changelogs IN the > rpm? Well, there are still people that to focused Raw Hide upgrades on systems partially upgraded from RH 7.1 to 7.3 (not kidding at all, really) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Feb 1 19:14:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 14:14:13 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107284985.21078.40.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> Message-ID: <1107285253.25100.111.camel@cutter> > > And keeping the last 6 months or a year of them is fine. > > > > but cmon - do we really need 7 yrs or more worth of changelogs IN the > > rpm? > > Well, there are still people that to focused Raw Hide upgrades on > systems partially upgraded from RH 7.1 to 7.3 > (not kidding at all, really) > And why exactly do we care about them for purposes of this dicussion? -sv From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:26:40 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:26:40 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107210964.5291.52.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> Message-ID: <1107286000.21078.53.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 17:36 -0500, seth vidal a ?crit : > On Mon, 2005-01-31 at 17:34 -0500, Nick Bargnesi wrote: > > On Mon, 31 Jan 2005 17:04:36 -0500, seth vidal wrote: > > > Hi folks, > > > this is a touch silly but possibly useful and it would definitely cut > > > down on the old crap blocking up cdroms. > > > > > > how about if we kill all rpm spec file changelog entries OLDER than 2 > > > years. > > > > > > they'll still live on in older srpms and rpms but it'd be a useful > > > reduction and it would make the specfiles that much smaller, along with > > > the rpm headers. > > > > > > thoughts? > > > > It'd be interesting to see how much space something like this would save first. > > Why first? What's the loss in doing it and moving along? > the changelogs would be in cvs FOR EVER and in old srpms and on old isos > and... and... and... Meet you in the server room where outbound access is disabled for security reasons and cvs is not installed on fileservers anyway. Stop thinking like a developer with full software support infrastructure and net access. Field people rely on simple console text editors for a reason - shit happens, and complex systems fail more often than simple ones. Just assume no convenience will be available and you're be not far from the reality you have today in countless enterprise or home premises. %changelog is perfectly adapted to rpm usage. This is not one of the "features" like rpm groups no one ever found a serious use for. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Feb 1 19:33:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 14:33:08 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107286000.21078.53.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> Message-ID: <1107286388.25100.118.camel@cutter> > Meet you in the server room where outbound access is disabled for > security reasons and cvs is not installed on fileservers anyway. > > Stop thinking like a developer with full software support infrastructure > and net access. Field people rely on simple console text editors for a > reason - shit happens, and complex systems fail more often than simple > ones. Just assume no convenience will be available and you're be not far > from the reality you have today in countless enterprise or home > premises. > > %changelog is perfectly adapted to rpm usage. This is not one of the > "features" like rpm groups no one ever found a serious use for. > I'm not talking about removing ALL of them. Just the REALLY old ones. tell me - when was the last time you needed, in your server room, to know what changes were made in 1998 to a package? -sv From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:31:14 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:31:14 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107285253.25100.111.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> Message-ID: <1107286274.21078.56.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 14:14 -0500, seth vidal a ?crit : > > > And keeping the last 6 months or a year of them is fine. > > > > > > but cmon - do we really need 7 yrs or more worth of changelogs IN the > > > rpm? > > > > Well, there are still people that to focused Raw Hide upgrades on > > systems partially upgraded from RH 7.1 to 7.3 > > (not kidding at all, really) > > > > And why exactly do we care about them for purposes of this dicussion? Because they are real users. A few megs of cd space savings are not sufficient to justify putting part of our users in deep s*t. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Feb 1 19:36:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 14:36:52 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107286274.21078.56.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> Message-ID: <1107286612.25100.123.camel@cutter> > > > > And why exactly do we care about them for purposes of this dicussion? > > Because they are real users. A few megs of cd space savings are not > sufficient to justify putting part of our users in deep s*t. > Which part of the users would this be? The people using fedora in 'mission critical environments'? I coulda sworn there was something about fedora core not be intended for those environments on the front page. Maybe I'm mistaken - but why are we planning and making adjustments for folks that the distro is EXPLICITLY not intended for? -sv From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:41:56 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:41:56 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107286388.25100.118.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> Message-ID: <1107286916.21078.63.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 14:33 -0500, seth vidal a ?crit : > > Meet you in the server room where outbound access is disabled for > > security reasons and cvs is not installed on fileservers anyway. > > > > Stop thinking like a developer with full software support infrastructure > > and net access. Field people rely on simple console text editors for a > > reason - shit happens, and complex systems fail more often than simple > > ones. Just assume no convenience will be available and you're be not far > > from the reality you have today in countless enterprise or home > > premises. > > > > %changelog is perfectly adapted to rpm usage. This is not one of the > > "features" like rpm groups no one ever found a serious use for. > > > > I'm not talking about removing ALL of them. Just the REALLY old ones. > > tell me - when was the last time you needed, in your server room, to > know what changes were made in 1998 to a package? 2000/2001 ? Really, this is very package dependent - some subsystems are very tied to a particular distribution release (because they depend on very specific features), others packages can happily be dropped in 5-years- old systems after just a rebuild. As a matter of fact, since a RHEL lifetime is 5 years truncating anything older than that would probably be ok. But there *will* be people who install a first-gen RHEL2.1 (because that's the version their OS dpt validated) near RHEL2.1 end-of-life who'll then update it partially or completely to the latest updates. So in some cases, 5y is a reasonable minimum. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Tue Feb 1 19:44:11 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 20:44:11 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107286612.25100.123.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> <1107286612.25100.123.camel@cutter> Message-ID: <1107287051.21078.66.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 14:36 -0500, seth vidal a ?crit : > > > > > > And why exactly do we care about them for purposes of this dicussion? > > > > Because they are real users. A few megs of cd space savings are not > > sufficient to justify putting part of our users in deep s*t. > > > > Which part of the users would this be? The people using fedora in > 'mission critical environments'? I coulda sworn there was something > about fedora core not be intended for those environments on the front > page. Well you should know that once you release a software in the wild some people will put it to interesting uses (I'm sure you have a found remembrance of when people started yuming Raw Hide;) 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 ville.skytta at iki.fi Tue Feb 1 19:46:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Feb 2005 21:46:13 +0200 Subject: radical suggestion for fc4 release In-Reply-To: <1107269219.5389.345.camel@mccallum.corsepiu.local> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> Message-ID: <1107287173.4018.555.camel@bobcat.mine.nu> On Tue, 2005-02-01 at 15:46 +0100, Ralf Corsepius wrote: > Frankly speaking, the only situation I have found rpm.specs useful > sofar, was to dig out the responsible maintainer of a package to get in > direct contact to him. On the other hand, this is the very reason I have sometimes considered leaving out my email address entirely from the specfile changelogs. I cannot promise personal individual support for users of the packages I maintain. Bugzillas and mailing lists are much better for that. Back to the original topic: I think it is ok to remove the changelogs from the packages altogether provided that a equally easily accessible and working replacement to "rpm -q --changelog" is provided. But I don't have ideas how to implement that right now, sorry. From pri.rhl3 at iadonisi.to Tue Feb 1 19:46:44 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Tue, 01 Feb 2005 14:46:44 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107287051.21078.66.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> <1107286612.25100.123.camel@cutter> <1107287051.21078.66.camel@rousalka.dyndns.org> Message-ID: <1107287205.11171.2.camel@tuxpaq> On Tue, 2005-02-01 at 20:44 +0100, Nicolas Mailhot wrote: > Le mardi 01 f?vrier 2005 ? 14:36 -0500, seth vidal a ?crit : [snip] > Well you should know that once you release a software in the wild some > people will put it to interesting uses (I'm sure you have a found > remembrance of when people started yuming Raw Hide;) And The Fedora Project most definitely does not need to make adjustments for these 'interesting uses' if those uses go directly against the warnings from the very inception of the project. -- -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 bos at serpentine.com Tue Feb 1 19:54:03 2005 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 01 Feb 2005 11:54:03 -0800 Subject: radical suggestion for fc4 release In-Reply-To: <20050201024420.GB32755@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> Message-ID: <1107287643.12273.9.camel@serpentine.pathscale.com> On Mon, 2005-01-31 at 21:44 -0500, Eric S. Raymond wrote: > Is that a problem? Processors are speeding up faster than media are > getting larger -- thus, trdsing clocks for space seems like the > right thing. Processors are not speeding up at all, to a first approximation. Haven't you noticed? Moore's law stopped operating about two years ago. References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> <1107286916.21078.63.camel@rousalka.dyndns.org> Message-ID: <1107288295.25100.127.camel@cutter> > > I'm not talking about removing ALL of them. Just the REALLY old ones. > > > > tell me - when was the last time you needed, in your server room, to > > know what changes were made in 1998 to a package? > > 2000/2001 ? Right! But look what year it is now. I'm talking about deleting changelog entries OLDER than a certain point. > Really, this is very package dependent - some subsystems are very tied > to a particular distribution release (because they depend on very > specific features), others packages can happily be dropped in 5-years- > old systems after just a rebuild. then like owen suggested: how about the most recent year or the last 10, whichever is more? > As a matter of fact, since a RHEL lifetime is 5 years truncating > anything older than that would probably be ok. But there *will* be > people who install a first-gen RHEL2.1 (because that's the version their > OS dpt validated) near RHEL2.1 end-of-life who'll then update it > partially or completely to the latest updates. So in some cases, 5y is a > reasonable minimum. > This is not a discussion of rhel. this is fedora-devel-list. -sv From skvidal at phy.duke.edu Tue Feb 1 20:05:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 15:05:28 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107287051.21078.66.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> <1107286612.25100.123.camel@cutter> <1107287051.21078.66.camel@rousalka.dyndns.org> Message-ID: <1107288328.25100.129.camel@cutter> > Well you should know that once you release a software in the wild some > people will put it to interesting uses (I'm sure you have a found > remembrance of when people started yuming Raw Hide;) > Sure -but I can't plan or count on whatever someone might do. I have to plan on intended use. -sv From jspaleta at gmail.com Tue Feb 1 20:03:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 Feb 2005 15:03:24 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107286916.21078.63.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> <1107286916.21078.63.camel@rousalka.dyndns.org> Message-ID: <604aa791050201120323bbd51b@mail.gmail.com> On Tue, 01 Feb 2005 20:41:56 +0100, Nicolas Mailhot wrote: > As a matter of fact, since a RHEL lifetime is 5 years truncating > anything older than that would probably be ok. But there *will* be > people who install a first-gen RHEL2.1 (because that's the version their > OS dpt validated) near RHEL2.1 end-of-life who'll then update it > partially or completely to the latest updates. So in some cases, 5y is a > reasonable minimum. RHEL users and the timescales invovled there might be a valid concern, if the fedora package histories are deeply mingled with the RHEL package histories. If Red Hat packagers end up stripping items from fedora packages and them just needing to put the items back for rhel packages, that seems a bit wasteful concerning the small amount of data that has been quantified so far in this list. Depends on what Red Hat does internally as to whether chopping the changelogs in fedora will affect rhel users later on. -jef From skvidal at phy.duke.edu Tue Feb 1 20:07:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 15:07:22 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107287173.4018.555.camel@bobcat.mine.nu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> <1107287173.4018.555.camel@bobcat.mine.nu> Message-ID: <1107288442.25100.132.camel@cutter> On Tue, 2005-02-01 at 21:46 +0200, Ville Skytt? wrote: > On Tue, 2005-02-01 at 15:46 +0100, Ralf Corsepius wrote: > > > Frankly speaking, the only situation I have found rpm.specs useful > > sofar, was to dig out the responsible maintainer of a package to get in > > direct contact to him. > > On the other hand, this is the very reason I have sometimes considered > leaving out my email address entirely from the specfile changelogs. I > cannot promise personal individual support for users of the packages I > maintain. Bugzillas and mailing lists are much better for that. > > Back to the original topic: I think it is ok to remove the changelogs > from the packages altogether provided that a equally easily accessible > and working replacement to "rpm -q --changelog" is provided. But I > don't have ideas how to implement that right now, sorry. May have a solution to that for you. Panu worked up a script using the xml metadata to be able to do simple queries of the metadata like you would with rpm -q repoquery --changelog yum worked for me. -sv From Nicolas.Mailhot at laPoste.net Tue Feb 1 20:15:26 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Feb 2005 21:15:26 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107287205.11171.2.camel@tuxpaq> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> <1107286612.25100.123.camel@cutter> <1107287051.21078.66.camel@rousalka.dyndns.org> <1107287205.11171.2.camel@tuxpaq> Message-ID: <1107288926.21078.81.camel@rousalka.dyndns.org> Le mardi 01 f?vrier 2005 ? 14:46 -0500, Paul Iadonisi a ?crit : > On Tue, 2005-02-01 at 20:44 +0100, Nicolas Mailhot wrote: > > Le mardi 01 f?vrier 2005 ? 14:36 -0500, seth vidal a ?crit : > > [snip] > > > Well you should know that once you release a software in the wild some > > people will put it to interesting uses (I'm sure you have a found > > remembrance of when people started yuming Raw Hide;) > > And The Fedora Project most definitely does not need to make > adjustments for these 'interesting uses' if those uses go directly > against the warnings from the very inception of the project. There was no "inception of Fedora project" FC is a Red Hat Linux child, it has benefited a lot from this fact, writing off all this history like this is very bad form. Some form of Red Hat Linux continuity was a very big unwritten Fedora objective. And till recently (as lwn.net pointed out) there was precious little of anything else going on (not that people weren't working hard behind the scenes, but a large number of FC1/FC2/FC3 users weren't there for the yet-to-happen extras repository) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jspaleta at gmail.com Tue Feb 1 20:16:59 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 Feb 2005 15:16:59 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <0502011713010.24056@dell1.moose.awe.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> <1107271714.11449.27.camel@angua.localnet> <0502011602480.23728@dell1.moose.awe.com> <604aa79105020108213eee2c47@mail.gmail.com> <41FFAE68.8070407@nc.rr.com> <604aa791050201090277fc613f@mail.gmail.com> <0502011713010.24056@dell1.moose.awe.com> Message-ID: <604aa7910502011216cb45485@mail.gmail.com> On Tue, 1 Feb 2005 17:15:32 +0000 (GMT), Mark J Cox wrote: > Actually it's to assert that we're providing a backported patch for a > security issue in a package. This is incredibly useful to end users, > especially those who have to respond to auditors (we get many requests > along these lines, where a customer wants to be able to show an auditor > that the old version of, say, OpenSSH, contains a fix for some particular > named issue). I relent. -jef From esr at thyrsus.com Tue Feb 1 20:15:58 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 1 Feb 2005 15:15:58 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107287643.12273.9.camel@serpentine.pathscale.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> <1107287643.12273.9.camel@serpentine.pathscale.com> Message-ID: <20050201201558.GA7237@thyrsus.com> Bryan O'Sullivan : > On Mon, 2005-01-31 at 21:44 -0500, Eric S. Raymond wrote: > > > Is that a problem? Processors are speeding up faster than media are > > getting larger -- thus, trdsing clocks for space seems like the > > right thing. > > Processors are not speeding up at all, to a first approximation. > Haven't you noticed? Moore's law stopped operating about two years ago. Pedantry... Yes, speed increases in single processors have stalled. Which is why there are a lot more SMP and multicore systems deployed now. Clocks per dollar seems to be continuing to rise on a roughly 2^n curve, even though clocks per processor aren't. -- Eric S. Raymond From pri.rhl3 at iadonisi.to Tue Feb 1 20:33:16 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Tue, 01 Feb 2005 15:33:16 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107288926.21078.81.camel@rousalka.dyndns.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> <1107286612.25100.123.camel@cutter> <1107287051.21078.66.camel@rousalka.dyndns.org> <1107287205.11171.2.camel@tuxpaq> <1107288926.21078.81.camel@rousalka.dyndns.org> Message-ID: <1107289996.11171.17.camel@tuxpaq> On Tue, 2005-02-01 at 21:15 +0100, Nicolas Mailhot wrote: > > There was no "inception of Fedora project" > FC is a Red Hat Linux child, it has benefited a lot from this fact, > writing off all this history like this is very bad form. Interesting rewriting or re-interpretation of history, there. Are you implying that there is, was, or should be no difference between Fedora Core and it's predecessor, Red Hat Linux from the project/product perspective? Or that White Box Enterprise Linux had no inception because it is *also* a child of Red Hat Linux? Puh-leez. There most *certainly* *was* an inception of the Fedora Project. Or are you just playing semantic games? Honest question, there. > Some form of Red Hat Linux continuity was a very big unwritten Fedora > objective. Sez who? To paraphrase the bugzilla mantra (if it ain't in bugzilla, it doesn't exist): If it ain't written, it ain't an objective. It's a 'nice to have' but not a 'must have'. And as far as support goes for use in mission critical roles or any enterprise usage of it, it's basically this: you're on your own. If it breaks, you get to keep both pieces. That doesn't happen often (arguably less than RHEL updates have caused in the past year or so), and we're all here on this list, I presume, to help make sure it doesn't happen often, but set your expectations accordingly. > And till recently (as lwn.net pointed out) there was precious > little of anything else going on (not that people weren't working hard > behind the scenes, but a large number of FC1/FC2/FC3 users weren't there > for the yet-to-happen extras repository) Eh? What exactly are you talking about? -- -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 pri.rhl3 at iadonisi.to Tue Feb 1 20:38:17 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Tue, 01 Feb 2005 15:38:17 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050201201558.GA7237@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> <1107287643.12273.9.camel@serpentine.pathscale.com> <20050201201558.GA7237@thyrsus.com> Message-ID: <1107290298.11171.21.camel@tuxpaq> On Tue, 2005-02-01 at 15:15 -0500, Eric S. Raymond wrote: [snip] > > Processors are not speeding up at all, to a first approximation. > > Haven't you noticed? Moore's law stopped operating about two years ago. > > Pedantry... > > Yes, speed increases in single processors have stalled. Which is why > there are a lot more SMP and multicore systems deployed now. Clocks > per dollar seems to be continuing to rise on a roughly 2^n curve, even > though clocks per processor aren't. But... Unless rpm and yum are multi-threaded, this makes little difference. Are they? Seth? Jeff? -- -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 ville.skytta at iki.fi Tue Feb 1 21:01:41 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Feb 2005 23:01:41 +0200 Subject: redhat abe In-Reply-To: <87651cd5cs.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> <1107219068.5389.239.camel@mccallum.corsepiu.local> <87acqpcckw.fsf@kosh.ultra.csn.tu-chemnitz.de> <1107227358.5389.320.camel@mccallum.corsepiu.local> <87651cd5cs.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1107291701.11702.28.camel@bobcat.mine.nu> On Tue, 2005-02-01 at 09:58 +0100, Enrico Scholz wrote: > I just said that BuildRequires: must not be determined by the header of > the src.rpm package. "Must not" is a bit strong expression, the correctness of the build deps retrieved that way depends on what one wants to achieve. The SRPM header contains the build dependencies resolved one way or the another at the time the SRPM was built, that's it. Depending on the use case, that may or may not meet the requirements. For the vast majority of packages (most do not do any conditionals/scripting mentioned earlier in this thread) the SRPM header info is "correct" in the same-as-in-the-specfile sense. Granted, that's not enough for eg. build systems having certain requirements. But that doesn't make the data completely useless, one just has to be aware of the limitations. From commonlaw at vtlink.net Tue Feb 1 22:03:54 2005 From: commonlaw at vtlink.net (James Sylvester) Date: Tue, 1 Feb 2005 17:03:54 -0500 (EST) Subject: system-config-printer Message-ID: <32975.64.30.50.167.1107295434.squirrel@mail.vtlink.net> I can only agree with Tim. Having, for 5 months attempted to configure a new scx4600 Epson printer/scanner to operate in Fedora 3. I have yet to accomplish this feat in the way that the printer designers and the Epson Kowa Company (a third party Japanese linux driver software company) intended the printer/scanner to operate. If a printer is not in the Xml, Gnome, KDE, Cups, Gimp, or Ghost driver database, the current system will defeat a third party linux printer driver from operating at its designed capacity. I believe that it will take time to review and integrate any solution into Core 4. Core 5, possibly? A beginning may be to allow the current system-config-printer to permit brand x software to be inserted into Gnome or Cups without waiting for these installers to place in there database the specific printer. All good things come with time. Unfortunately, diligent input is a necessary partner for "good things". Jim Sylvester From hp at redhat.com Tue Feb 1 22:05:14 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 01 Feb 2005 17:05:14 -0500 Subject: system-config-printer In-Reply-To: <20050201121139.GR5322@redhat.com> References: <20050201121139.GR5322@redhat.com> Message-ID: <1107295514.4232.23.camel@localhost.localdomain> On Tue, 2005-02-01 at 12:11 +0000, Tim Waugh wrote: > > Does anyone have ideas for how system-config-printer should be > re-written? The interaction designers are probably more than willing to help, that's my suggestion for how to start. I think they've already done a design for the "desktop user" case which is eggcups, HAL, etc. - there's work left in some of the details, mclasen can probably give you more info. The remaining design would be the sysadmin UI, primarily for configuring a print *server*. There's a general problem here that we need to define a uniform approach for sysadmin tools, maybe some idea of "sysadmin console" - [insert long thread here] - anyway, totally ignoring the question of how that works, I question whether it's worthwhile to rewrite the system-config-* stuff with an admin target before we have some kind of big picture plan on the sysadmin front. What we can definitely do immediately though is address the desktop user UI (for printing and the rest of system-config-*). We already have a substantial start on this in the form of NetworkManager, printing stuff in FC3, etc. Trying to write one tool for both admins and desktop users is totally wrong IMO and perhaps the biggest reason why system-config-* is problematic. Remember also the goal that the desktop user UI doesn't involve su to root or modifying the root filesystem... that bit is already working for printing so not too hard. Havoc From johnp at redhat.com Tue Feb 1 22:11:31 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 01 Feb 2005 17:11:31 -0500 Subject: system-config-printer In-Reply-To: <1107295514.4232.23.camel@localhost.localdomain> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> Message-ID: <1107295891.32198.111.camel@remedyz.boston.redhat.com> On Tue, 2005-02-01 at 17:05 -0500, Havoc Pennington wrote: > On Tue, 2005-02-01 at 12:11 +0000, Tim Waugh wrote: > Trying to write one tool for both admins and desktop users is totally > wrong IMO and perhaps the biggest reason why system-config-* is > problematic. > Ah, but we do want a common backend. I was stuck in errata hell today but we did discuss this in the core desktop group. I am going to try and get a synopsis out on how the current desktop printer config works by tomorrow and then follow up on how I would like to tie in the system configuration tools with the user configuration tools. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From mike at netlyncs.com Tue Feb 1 22:47:42 2005 From: mike at netlyncs.com (Mike Chambers) Date: Tue, 01 Feb 2005 16:47:42 -0600 Subject: Starting sshd errors In-Reply-To: References: <1107207855.32622.6.camel@scrappy.netlyncs.com> Message-ID: <1107298063.1034.0.camel@scrappy.netlyncs.com> On Tue, 2005-02-01 at 16:14 +0530, Rahul Sundaram wrote: > On Mon, 31 Jan 2005 15:44:15 -0600, Mike Chambers wrote: > > Up until a few weeks (couple I guess) openssh was working fine. But now > > when trying to start it, I get "initlog not found", which is around line > > 107, when the /etc/init.d/sshd file has "initlog -c blah blah". > > you are probably running rawhide. in that case try updating to the > latest version of initscripts and openssh packages For some reason I didn't think of it until you said something, but I noticed openssh-server wasn't installed, as it also installed a newer /etc/init.d/sshd file, which seems to have fixed the problem. Thanks for the hint, -- Mike Chambers Madisonville, KY "It's always better to hurt a little now, than to hurt a lot later!" From pmatilai at welho.com Tue Feb 1 22:50:35 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 02 Feb 2005 00:50:35 +0200 Subject: radical suggestion for fc4 release In-Reply-To: <1107288442.25100.132.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> <1107287173.4018.555.camel@bobcat.mine.nu> <1107288442.25100.132.camel@cutter> Message-ID: <1107298236.27820.28.camel@chip.laiskiainen.org> On Tue, 2005-02-01 at 15:07 -0500, seth vidal wrote: > On Tue, 2005-02-01 at 21:46 +0200, Ville Skytt? wrote: > > Back to the original topic: I think it is ok to remove the changelogs > > from the packages altogether provided that a equally easily accessible > > and working replacement to "rpm -q --changelog" is provided. But I > > don't have ideas how to implement that right now, sorry. > > May have a solution to that for you. Panu worked up a script using the > xml metadata to be able to do simple queries of the metadata like you > would with rpm -q Except that where does the changelog info get into the metadata? The packages, so if the info is removed from the packages... oops. :) Of course the changelog metada could be generated from cvs or such. > > repoquery --changelog yum > > worked for me. Oh well, since you advertised it publically I guess I could just as well make the blasted thing available finally :) It haven't touched it in quite a while but what little is there seems to still work: http://laiskiainen.org/repoquery/repoquery.py Note that you need to run "yum makecache" first for it to work (and without that you'd grow old waiting anyway) - Panu - From mattdm at mattdm.org Tue Feb 1 23:06:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 Feb 2005 18:06:06 -0500 Subject: system-config-printer In-Reply-To: <1107295514.4232.23.camel@localhost.localdomain> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> Message-ID: <20050201230606.GA20438@jadzia.bu.edu> On Tue, Feb 01, 2005 at 05:05:14PM -0500, Havoc Pennington wrote: > The remaining design would be the sysadmin UI, primarily for configuring > a print *server*. There's a general problem here that we need to define Don't forget an easy way to distribute configurations to client systems. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From cmadams at hiwaay.net Tue Feb 1 23:32:56 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 1 Feb 2005 17:32:56 -0600 Subject: radical suggestion for fc4 release In-Reply-To: <1107288442.25100.132.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> <1107287173.4018.555.camel@bobcat.mine.nu> <1107288442.25100.132.camel@cutter> Message-ID: <20050201233256.GA961554@hiwaay.net> Once upon a time, seth vidal said: > May have a solution to that for you. Panu worked up a script using the > xml metadata to be able to do simple queries of the metadata like you > would with rpm -q > > repoquery --changelog yum > > worked for me. That's nice if you are working on a network-connected computer. Also, where will the changelog data come from? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Tue Feb 1 23:37:54 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 1 Feb 2005 17:37:54 -0600 Subject: radical suggestion for fc4 release In-Reply-To: <1107288295.25100.127.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> <1107286916.21078.63.camel@rousalka.dyndns.org> <1107288295.25100.127.camel@cutter> Message-ID: <20050201233754.GB961554@hiwaay.net> Once upon a time, seth vidal said: > This is not a discussion of rhel. Fedora Core objective #13: Form the basis of Red Hat's commercially supported operating system products. What goes into RHEL is relevant to FC. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ghenry at suretecsystems.com Tue Feb 1 23:37:08 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 1 Feb 2005 23:37:08 +0000 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <1107066142.4770.34.camel@rhbw.boston.redhat.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> <1107009143.4984.41.camel@erato.phig.org> <1107066142.4770.34.camel@rhbw.boston.redhat.com> Message-ID: <200502012337.15087.ghenry@suretecsystems.com> On Sunday 30 Jan 2005 06:22, Bryan Clark wrote: > Hi ~ > > Just some more questions to clarify. > > On Sat, 2005-01-29 at 06:32 -0800, Karsten Wade wrote: > > On Sat, 2005-01-29 at 06:35 -0500, Bryan Clark wrote: > > > What type of person do you think is looking for this information (a > > > developer, an office worker, a broker?). > > > > Any end-user on the system. > > So any user of our desktop or workstation product needs to be able to > find this information in order to be able to use it? No, but why should they require internet access to read the manuals? Why should look look in a million places just to find out an answer to there question? I recently had a conversation with some on the #fedora irc channel, and they said the reason they were trying Fedora, was because they had heard it had great documentation. The other irc users laughed at him. Let's make this come true, by creating a powerful help/document feature. > > > > What is this person trying to accomplish by searching this information? > > > Why do they need it? > > > > Currently, the best way to search for Fedora documentation is via > > google.com. That in fact is how I search Red Hat docs, using > > site:redhat.com. Again, why should every user require internet access to read about something in front of them? > > Just a thought, but would it be a good idea to integrate Red Hat docs on > the web with Fedora. That would mean there is one less indexing program > that possibly destroys my system (updatedb) and less packaging / > development work. Although if this is an incremental updater it should > use less resources. Why doesn't RH just donate the docs, and we can update those? This has been discussed millions of times too, on this list. > > You could still allow for people to install the docs locally, but > perhaps we could integrate an online search system for everyone that Red > Hat indexes. Could you re-word this? > > > Right now, if you install locally all the documentation available, you > > might have everything you'd be searching Google for but are unable to > > find locally. Package docs go into /usr/share/doc and the man pages, > > Red Hat docs packages also go into /usr/share/doc and may have an entry > > in the 'Foot/'Hat menu. Fedora docs are small enough that an Everything > > install _could_ include docs packages. That is a *tonne* of local, > > online documentation. > > > > All of this is nearly impossible to search through without an index and > > search tool. Very much so. We could modfiy swish-e etc. to allow the user to select, developer results, beginners, advanced etc. > > What specific information do you find when you search for this? Help on > using an application? What application is that? Again, a drop down selection option. > > > > Assuming they need it. How are they going to search for this > > > information? Yelp? Web Browser? Something else? Are the mechanisms > > > for searching and reviewing this type of information already built into > > > those things? > > > > IMO, Yelp. We need to settle on a common help interface and (ab)use it. This would be fine, although, I would like to see the default web page changed for this. > > > > For example, a document on using kickstart to automate installation > > might be at the forefront when Yelp is called from system-config- > > kickstart. If an indexer can do this well, it seems better than hand > > coding docs to be associated with certain apps and actions. > > Context sensitive help would be a great thing and I know the Yelp > maintainer (Shaun M) is interested in doing that but short on time. Great. > > > > If we had more of an overview of how this project is going to help > > > people we could possibly look at a way of integrating it's > > > functionality better into our system. Hopefully we then won't be just > > > adding another piece to the stack of tools we have, but an answer to a > > > problem people are having. > > > > I definitely think integrating indexed documentation into Yelp is a good > > idea for corporate-type end-users. People _used_ to use the local help > > system more extensively, until Internet search engines proved more > > useful. The downside of relying upon the Internet is, what do you do > > when the doc you need is the one that will get your networking going > > again? Better hope you have a second machine that has connectivity, or > > that you know how to dig through /usr/share/doc by hand. > > Ok. This sounds really interesting, I think I'm getting a bigger > picture of what's happening. Maybe with a little more clarification I > can see what we're aiming at. > > Thanks, > ~ Bryan -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1467 624141 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dsteven at bigpond.net.au Tue Feb 1 23:19:18 2005 From: dsteven at bigpond.net.au (Darren Steven) Date: Wed, 02 Feb 2005 10:19:18 +1100 Subject: radical suggestion for fc4 release In-Reply-To: <1107290298.11171.21.camel@tuxpaq> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107218101.5389.227.camel@mccallum.corsepiu.local> <41FED1B9.3010804@nc.rr.com> <20050201024420.GB32755@thyrsus.com> <1107287643.12273.9.camel@serpentine.pathscale.com> <20050201201558.GA7237@thyrsus.com> <1107290298.11171.21.camel@tuxpaq> Message-ID: <42000E76.3000206@bigpond.net.au> Paul Iadonisi wrote: >On Tue, 2005-02-01 at 15:15 -0500, Eric S. Raymond wrote: > >[snip] > > > >>>Processors are not speeding up at all, to a first approximation. >>>Haven't you noticed? Moore's law stopped operating about two years ago. >>> >>> >>Pedantry... >> >>Yes, speed increases in single processors have stalled. Which is why >>there are a lot more SMP and multicore systems deployed now. Clocks >>per dollar seems to be continuing to rise on a roughly 2^n curve, even >>though clocks per processor aren't. >> >> > > But... > > Unless rpm and yum are multi-threaded, this makes little difference. >Are they? Seth? Jeff? > > > > Hi, Just , FYI, yum, being python based might have issues with multi threaded operation. >From what I have seen in my zope digging is that python has a thing called the GIL (or similar?), that for most applications prevents efficient use of SMP. For a while, SMP could make things slower, but I believe now that threaded python apps behave OK on most SMP platforms. According to the info, a complete re-hash of the python interpreter would be required to give it the ability to scale well using threads on SMP architectures. Most folk seem to recommend using a multi process model for python to exploit SMP. Regards, Darren Steven From toshio at tiki-lounge.com Wed Feb 2 01:37:43 2005 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 01 Feb 2005 20:37:43 -0500 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <200502012337.15087.ghenry@suretecsystems.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> <1107009143.4984.41.camel@erato.phig.org> <1107066142.4770.34.camel@rhbw.boston.redhat.com> <200502012337.15087.ghenry@suretecsystems.com> Message-ID: <1107308264.23753.12.camel@Madison.badger.com> On Tue, 2005-02-01 at 23:37 +0000, Gavin Henry wrote: > > > > Assuming they need it. How are they going to search for this > > > > information? Yelp? Web Browser? Something else? Are the mechanisms > > > > for searching and reviewing this type of information already built into > > > > those things? > > > > > > IMO, Yelp. We need to settle on a common help interface and (ab)use it. > GNOME Storage :-) http://www.gnome.org/~seth/storage I don't know that it is actually ready for this type of (ab)use but Seth mentions some other, less ambitious (or possibly, just as ambitious but targeted more towards document indexing and less towards all the other fun stuff storage is intended to allow) on his blog:: http://www.gnome.org/~seth/blog/document-indexing I haven't looked hard at any of these yet but if people are actually thinking of doing something ambitious and new with the plethora of documentation in /usr/share/doc, perhaps this is something to explore. -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 skvidal at phy.duke.edu Wed Feb 2 04:56:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Feb 2005 23:56:57 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107298236.27820.28.camel@chip.laiskiainen.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <20050201130035.49c264cd.fedora@wir-sind-cool.org> <1107269219.5389.345.camel@mccallum.corsepiu.local> <1107287173.4018.555.camel@bobcat.mine.nu> <1107288442.25100.132.camel@cutter> <1107298236.27820.28.camel@chip.laiskiainen.org> Message-ID: <1107320217.25100.189.camel@cutter> > Except that where does the changelog info get into the metadata? The > packages, so if the info is removed from the packages... oops. :) Of > course the changelog metada could be generated from cvs or such. Details! :) But to be clear, getting the changelog and other metadata from non-pkg sources is probably going to have to happen. > Oh well, since you advertised it publically I guess I could just as well > make the blasted thing available finally :) It haven't touched it in > quite a while but what little is there seems to still work: > http://laiskiainen.org/repoquery/repoquery.py > > Note that you need to run "yum makecache" first for it to work (and > without that you'd grow old waiting anyway) it's only a year and a day you'd have to wait. sheesh, you act like that's a long time :) -sv From ruwabi at yahoo.com Wed Feb 2 06:01:20 2005 From: ruwabi at yahoo.com (Ranjitsinh Wable) Date: Tue, 1 Feb 2005 22:01:20 -0800 (PST) Subject: Compilation error using cross compiler In-Reply-To: <20050201230606.GA20438@jadzia.bu.edu> Message-ID: <20050202060120.48163.qmail@web54107.mail.yahoo.com> Hi All, I have trouble when doing make zImage. I am using the cross compiler. The last few lines I got when I did "make zImage" follow: : : arm_v4t_le-objcopy -O binary -R .note -R .comment -S /home/sanjoy/sanjoy/vmlinux piggy BFD: Warning: Writing section `.init' to huge (ie negative) file offset 0xc0002cf8. BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xc0012cf8. BFD: Warning: Writing section `.kstrtab' to huge (ie negative) file offset 0xc0159b68. BFD: Warning: Writing section `__ex_table' to huge (ie negative) file offset 0xc015eab8. BFD: Warning: Writing section `__ksymtab' to huge (ie negative) file offset 0xc015f480. BFD: Warning: Writing section `.data' to huge (ie negative) file offset 0xc0162cf8. arm_v4t_le-objcopy: piggy: File truncated make[2]: *** [piggy.o] Error 1 make[1]: *** [compressed/vmlinux] Error 2 make: *** [zImage] Error 2 Looking forward for ur inputs regarding this. Thanks in Advance. Regards, Wabs --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' -------------- next part -------------- An HTML attachment was scrubbed... URL: From twaugh at redhat.com Wed Feb 2 10:49:40 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 2 Feb 2005 10:49:40 +0000 Subject: system-config-printer In-Reply-To: <20050201230606.GA20438@jadzia.bu.edu> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> <20050201230606.GA20438@jadzia.bu.edu> Message-ID: <20050202104940.GT5322@redhat.com> On Tue, Feb 01, 2005 at 06:06:06PM -0500, Matthew Miller wrote: > On Tue, Feb 01, 2005 at 05:05:14PM -0500, Havoc Pennington wrote: > > The remaining design would be the sysadmin UI, primarily for configuring > > a print *server*. There's a general problem here that we need to define > > Don't forget an easy way to distribute configurations to client systems. That certainly was important before we switched to CUPS, but is it now? Doesn't browsing solve that problem? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Wed Feb 2 11:39:15 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 2 Feb 2005 12:39:15 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107288295.25100.127.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> <1107286916.21078.63.camel@rousalka.dyndns.org> <1107288295.25100.127.camel@cutter> Message-ID: <20050202113915.GA10424@dudweiler.stuttgart.redhat.com> > I'm talking about deleting changelog entries OLDER than a certain point. I think this is a reasonable request. Delete everything older than 2/3 years from being copied into binary rpm packages. Otherwise we add this as additional overhead to each package maintainer to remove old lines and move them to some "history file" within the src.rpm. greetings, Florian La Roche From arjanv at redhat.com Wed Feb 2 11:08:16 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 02 Feb 2005 12:08:16 +0100 Subject: system-config-printer In-Reply-To: <20050202104940.GT5322@redhat.com> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> <20050201230606.GA20438@jadzia.bu.edu> <20050202104940.GT5322@redhat.com> Message-ID: <1107342496.4143.81.camel@laptopd505.fenrus.org> On Wed, 2005-02-02 at 10:49 +0000, Tim Waugh wrote: > On Tue, Feb 01, 2005 at 06:06:06PM -0500, Matthew Miller wrote: > > > On Tue, Feb 01, 2005 at 05:05:14PM -0500, Havoc Pennington wrote: > > > The remaining design would be the sysadmin UI, primarily for configuring > > > a print *server*. There's a general problem here that we need to define > > > > Don't forget an easy way to distribute configurations to client systems. > > That certainly was important before we switched to CUPS, but is it > now? Doesn't browsing solve that problem? it would be nice if there was a zeroconf (or whatever that is called this week) thing that advertized a "I have the master printer list for cups HERE". All clients would then, without sysadmin work, use this list. List would include prefered printer etc etc -------------- next part -------------- A 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 harald at redhat.com Wed Feb 2 11:57:05 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Feb 2005 12:57:05 +0100 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <20050131222016.GA9816@thacker.dyndns.org> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> Message-ID: <4200C011.30809@redhat.com> John Thacker wrote: > On Mon, Jan 31, 2005 at 04:57:57PM -0500, Elliot Lee wrote: > >>>Peter Robinson: >>> Can we also get rid / move to extras all the non >>> GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK >>> 1 cruft as well? >> >>Need specific package nominations. > > > nmap-frontend is one. porting to gtk2 should not be too hard... From ndbecker2 at verizon.net Wed Feb 2 12:26:32 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Wed, 02 Feb 2005 07:26:32 -0500 Subject: ntpd startup too early + hangs Message-ID: In FC3 ntpd has 2 problems 1) Starts too early 2) hangs Especially if you want to use NetworkManager (which starts very late), ntpd should be started later. ntpd failing to start hangs the startup for about 10-15 seconds. This shouldn't happen. From dcbw at redhat.com Wed Feb 2 12:59:12 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 2 Feb 2005 07:59:12 -0500 (EST) Subject: ntpd startup too early + hangs In-Reply-To: References: Message-ID: On Wed, 2 Feb 2005, Neal Becker wrote: > In FC3 ntpd has 2 problems > > 1) Starts too early > 2) hangs > > Especially if you want to use NetworkManager (which starts very late), ntpd > should be started later. > > ntpd failing to start hangs the startup for about 10-15 seconds. This > shouldn't happen. Problem is that ntpd is too dumb to know when you have a network connecction and when you don't. NetworkManager can't be started earlier because dbus & hal aren't started early, because they are installed in /usr and that's not guaranteed to be mounted until somewhere in the middle of the boot process. ntpd needs to be smarter about when it does & does not look for servers based on whether or not there's a connection. Dan From nphilipp at redhat.com Wed Feb 2 13:12:13 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Feb 2005 14:12:13 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107220217.25100.28.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <1107216561.25100.2.camel@cutter> <1107219853.12849.162.camel@cmn37.stanford.edu> <1107220217.25100.28.camel@cutter> Message-ID: <1107349933.10061.18.camel@wombat.tiptoe.de> On Mon, 2005-01-31 at 20:10 -0500, seth vidal wrote: > On Mon, 2005-01-31 at 17:04 -0800, Fernando Lopez-Lezcano wrote: > > On Mon, 2005-01-31 at 16:09, seth vidal wrote: > > > > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > > > > > > > If changelogs are bloating the headers yum has to download, then > > > > strip them out when generating the yum headers. > > > > > > it's not bloating the headers - well not JUST that. > > > > > > I'm also thinking of decreasing the useles space eaten up by them on the > > > cd isos. > > > > how much space do they eat currently? > > -- Fernando > > well they're stored in at LEAST 3 different places on the cds: > > 1. the packages > 2. the srpms > 3. the rpmdb-fedora I've checked one of my "longer running" packages (gimp, changelog since 1999) and it accounts for about 10K uncompressed (ungzipped) and 3K gzipped in packages that are roughly 10MB in size, even for the kernel it would be only 28/10K vs. 30M. This tiny amount of space saved just doesn't warrant the effort IMO, sorry. Even if it's just a few K * (1 srpm + n * (binary rpms + rpmdb)). > 4. maybe in hdlist2? > 5. the metadata I don't think that changelogs should be stored at all in the (repo) metadata or hdlist2. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From buildsys at redhat.com Wed Feb 2 13:12:42 2005 From: buildsys at redhat.com (Build System) Date: Wed, 2 Feb 2005 08:12:42 -0500 Subject: rawhide report: 20050202 changes Message-ID: <200502021312.j12DCgT20334@porkchop.devel.redhat.com> From harald at redhat.com Wed Feb 2 13:15:33 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Feb 2005 14:15:33 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050202113915.GA10424@dudweiler.stuttgart.redhat.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> <1107286916.21078.63.camel@rousalka.dyndns.org> <1107288295.25100.127.camel@cutter> <20050202113915.GA10424@dudweiler.stuttgart.redhat.com> Message-ID: <4200D275.9050904@redhat.com> Florian La Roche wrote: >>I'm talking about deleting changelog entries OLDER than a certain point. > > > I think this is a reasonable request. Delete everything older than 2/3 years > from being copied into binary rpm packages. Otherwise we add this as additional > overhead to each package maintainer to remove old lines and move them to some > "history file" within the src.rpm. > > greetings, > > Florian La Roche > I would say, that rpm can strip everything but the last, say ten, entries from the binary rpms. From nphilipp at redhat.com Wed Feb 2 13:19:28 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Feb 2005 14:19:28 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107212547.17531.10.camel@one.myworld> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> Message-ID: <1107350368.10061.23.camel@wombat.tiptoe.de> On Tue, 2005-02-01 at 00:02 +0100, F?liciano Matias wrote: > The "problem" I have about changelog is its duplications. > > [fmatias at one i386]$ rpm -q --changelog xorg-x11 | wc > 5369 35773 250956 <= big changelog > [fmatias at one i386]$ rpm -q -a | grep xorg-x11 | xargs rpm -q --changelog > | wc > 75166 500822 3513384 <= very very big changelog (several times the same changelog). Then the question is: why is the same changelog, i.e. the changelog of sub packages with the same source package, stored for each package individually? It could be stored once and be referenced from each sub package. It gets deleted once all references on it vanish. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Wed Feb 2 13:29:12 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Feb 2005 14:29:12 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107270145.4208.119.camel@laptopd505.fenrus.org> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <604aa79105013114531c42b2c1@mail.gmail.com> <0502010922400.21123@dell1.moose.awe.com> <604aa79105020106504267a7bb@mail.gmail.com> <1107270145.4208.119.camel@laptopd505.fenrus.org> Message-ID: <1107350952.10061.31.camel@wombat.tiptoe.de> On Tue, 2005-02-01 at 16:02 +0100, Arjan van de Ven wrote: > On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote: > > On Tue, 1 Feb 2005 09:28:45 +0000 (GMT), Mark J Cox wrote: > > > What would be incredibly useful is to move (to being a Provides) the CVE > > > names for issues that we're including a backported fix for. Where we've > > > moved to an upstream version that contains fixes those CVE names are less > > > important as they can be deduced by a simple NV check. > > > > I look forward to building pathological packages that have a requires > > on a CVE name provides. > > fedora-secure-system > > could require all the CVE's that are ciritical to be fixed > yum update fedora-secure-system > would then only pull security updates down.... This scheme just doesn't cut it because: - you might need more than one package to fix a certain CVE - you might think you have fixed a certain CVE with one package revision, but you didn't, you'll have to issue an update but now the old package still claims to fix this particular CVE To get it right, we have to keep this separate from the individual packages IMO. We could think of a fedora-secure-system package that grabs CVEs and which packages are believed to fix them at build time, then just conflicts with every "%name < %{?epoch:%{epoch}:}%{version}%{release}" of the involved packages. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From rahulsundaram at yahoo.co.in Wed Feb 2 12:30:50 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Wed, 2 Feb 2005 04:30:50 -0800 (PST) Subject: ntpd startup too early + hangs In-Reply-To: Message-ID: <20050202123050.37406.qmail@web8505.mail.in.yahoo.com> --- Neal Becker wrote: > In FC3 ntpd has 2 problems > > 1) Starts too early > 2) hangs bugzilla.redhat.com is the best place to report bugs in fedora ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From laroche at redhat.com Wed Feb 2 14:13:07 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 2 Feb 2005 15:13:07 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107350368.10061.23.camel@wombat.tiptoe.de> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> Message-ID: <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> > Then the question is: why is the same changelog, i.e. the changelog of > sub packages with the same source package, stored for each package > individually? It could be stored once and be referenced from each sub > package. It gets deleted once all references on it vanish. People might be able to install only one of the sub-packages. greetings, Florian La Roche From tiemann at redhat.com Wed Feb 2 13:45:23 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 02 Feb 2005 08:45:23 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <604aa791050201120323bbd51b@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> <1107286000.21078.53.camel@rousalka.dyndns.org> <1107286388.25100.118.camel@cutter> <1107286916.21078.63.camel@rousalka.dyndns.org> <604aa791050201120323bbd51b@mail.gmail.com> Message-ID: <1107351923.4278.7.camel@localhost.localdomain> On Tue, 2005-02-01 at 15:03, Jeff Spaleta wrote: > On Tue, 01 Feb 2005 20:41:56 +0100, Nicolas Mailhot > wrote: > > As a matter of fact, since a RHEL lifetime is 5 years truncating > > anything older than that would probably be ok. But there *will* be > > people who install a first-gen RHEL2.1 (because that's the version their > > OS dpt validated) near RHEL2.1 end-of-life who'll then update it > > partially or completely to the latest updates. So in some cases, 5y is a > > reasonable minimum. > > RHEL users and the timescales invovled there might be a valid concern, > if the fedora package histories are deeply mingled with the RHEL > package histories. If Red Hat packagers end up stripping items from > fedora packages and them just needing to put the items back for rhel > packages, that seems a bit wasteful concerning the small amount of > data that has been quantified so far in this list. Depends on what > Red Hat does internally as to whether chopping the changelogs in > fedora will affect rhel users later on. RHEL users also have something that many fedora developers don't: the ability to use support (in one of at least 15 languages) to help answer questions that may or may not be covered by a truncated, full, or non-existent changelog, and to expect an answer that meets their satisfaction in a defined amount of time. I think it's best (especially on this list) to focus on what best supports the fedora community--users, developers, and those who provide bandwidth. If Fedora works better on the whole by changing changelog policy, I'm all for it. And if we find ourselves creating other mechanisms to help users support their systems (with or without paid support) that doesn't mean we failed. It means we're evolving. M From felipe_alfaro at linuxmail.org Wed Feb 2 14:01:14 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 2 Feb 2005 15:01:14 +0100 Subject: system-config-printer In-Reply-To: <1107342496.4143.81.camel@laptopd505.fenrus.org> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> <20050201230606.GA20438@jadzia.bu.edu> <20050202104940.GT5322@redhat.com> <1107342496.4143.81.camel@laptopd505.fenrus.org> Message-ID: <73d168c9bca290321daf4b4a60932d2c@linuxmail.org> On 2 Feb 2005, at 12:08, Arjan van de Ven wrote: > On Wed, 2005-02-02 at 10:49 +0000, Tim Waugh wrote: >> On Tue, Feb 01, 2005 at 06:06:06PM -0500, Matthew Miller wrote: >> >>> On Tue, Feb 01, 2005 at 05:05:14PM -0500, Havoc Pennington wrote: >>>> The remaining design would be the sysadmin UI, primarily for >>>> configuring >>>> a print *server*. There's a general problem here that we need to >>>> define >>> >>> Don't forget an easy way to distribute configurations to client >>> systems. >> >> That certainly was important before we switched to CUPS, but is it >> now? Doesn't browsing solve that problem? > > it would be nice if there was a zeroconf (or whatever that is called > this week) thing that advertized a "I have the master printer list for > cups HERE". All clients would then, without sysadmin work, use this > list. List would include prefered printer etc etc Why a master printer list would ever be needed? CUPS support automatic printer advertising, so I don't understand the need of a master printer list. From linux_4ever at yahoo.com Wed Feb 2 14:03:24 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 2 Feb 2005 06:03:24 -0800 (PST) Subject: Change to bzip2? Message-ID: <20050202140325.73643.qmail@web50610.mail.yahoo.com> Hi, With the discussion about trimming specfile changelogs to save space and improve downloads...why not go one step further? Mandrake has been using bzip2 for a while and it works just as well and files are significantly smaller. The conversion could be done in several steps: 1) man pages - less already handles bzipped man pages 2) info pages - I submited patch in bz #128637 to try to get it working 3) tar 4) rpms - I'm sure the patch is in Mandrake's version Thoughts? -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From shiva at sewingwitch.com Wed Feb 2 14:03:58 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 02 Feb 2005 06:03:58 -0800 Subject: ntpd startup too early + hangs In-Reply-To: References: Message-ID: <672F9B1A002B51BEA2769E1C@[10.0.0.4]> --On Wednesday, February 02, 2005 7:59 AM -0500 Dan Williams wrote: > Problem is that ntpd is too dumb to know when you have a network > connecction and when you don't. NetworkManager can't be started earlier > because dbus & hal aren't started early, because they are installed in > /usr and that's not guaranteed to be mounted until somewhere in the > middle of the boot process. ntpd needs to be smarter about when it does > & does not look for servers based on whether or not there's a connection. Best place to discuss changes to that program would be the ntp newsgroup, comp.protocols.time.ntp. I was going to suggest bringing up ntpd with the network ifup script, but you want ntpd to run with no connections to compensate for drift in the native hardware clock. Some setups may not use the network for time but would use a local source like a GPS receiver, and only act as servers to other systems. From symbiont at berlios.de Wed Feb 2 14:05:12 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 2 Feb 2005 22:05:12 +0800 Subject: ntpd startup too early + hangs In-Reply-To: References: Message-ID: <200502022205.12933.symbiont@berlios.de> On Wednesday 02 February 2005 20:59, Dan Williams wrote: > > ntpd failing to start hangs the startup for about 10-15 seconds. > > ?This shouldn't happen. > > Problem is that ntpd is too dumb to know when you have a network > connecction and when you don't. It's actually ntpdate, executed by the startup script with a sampling of 8 packets (-p 8). ntpdate is actually supposed to be a deprecated utility. Remove /etc/ntp/step-servers to skip the ntpdate step, which will block the bootup process. ntpd will then be executed with the -g parameter, which will perform ntpdate type functionality on a first synchronization with the time servers. Subsequent syncs will use slew/step corrections instead. This *should* be bugzilla'd. have fun, -- -jeff From laroche at redhat.com Wed Feb 2 14:45:50 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 2 Feb 2005 15:45:50 +0100 Subject: Change to bzip2? In-Reply-To: <20050202140325.73643.qmail@web50610.mail.yahoo.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> Message-ID: <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> On Wed, Feb 02, 2005 at 06:03:24AM -0800, Steve G wrote: > Hi, > > With the discussion about trimming specfile changelogs to save space and improve > downloads...why not go one step further? Mandrake has been using bzip2 for a > while and it works just as well and files are significantly smaller. The > conversion could be done in several steps: > > 1) man pages - less already handles bzipped man pages > 2) info pages - I submited patch in bz #128637 to try to get it working > 3) tar > 4) rpms - I'm sure the patch is in Mandrake's version > > Thoughts? bzip2 is only used for the cpio-packed file-data, the rpm-header is not compressed. For the repo-data the changelog can also be trimmed, only if you need to copy the rpm header unmodified this is actually getting a problem (e.g. if you later-on want to verify the md5sum to be the same as in full rpms you download or similar things). I think staying with gzip is ok as it really is a good middle ground between speed and disk compression ratio. bzip2 "feels" noticable slower. greetings, Florian la Roche From jspaleta at gmail.com Wed Feb 2 14:50:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 2 Feb 2005 09:50:06 -0500 Subject: system-config-printer In-Reply-To: <73d168c9bca290321daf4b4a60932d2c@linuxmail.org> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> <20050201230606.GA20438@jadzia.bu.edu> <20050202104940.GT5322@redhat.com> <1107342496.4143.81.camel@laptopd505.fenrus.org> <73d168c9bca290321daf4b4a60932d2c@linuxmail.org> Message-ID: <604aa791050202065024f2febe@mail.gmail.com> On Wed, 2 Feb 2005 15:01:14 +0100, Felipe Alfaro Solana wrote: > Why a master printer list would ever be needed? CUPS support automatic > printer advertising, so I don't understand the need of a master printer > list. On a tightly controlled network.. where linux is officially supported... the advertising mechanism as implemented now in fedora probably works rather well. On less centralized networks (some universities or research facilities.. places where small groups self-manage their own computing infrastructure inside an encompassing facility network).. or where linux isn't officially supported by the central IT department but is tolerated so long as its not interfering with the windows machines, simple application of cups advertising mechanism can be somewhat problematic. Without some sort of mechanism to whitelist/blacklist good/bad cups printer servers that are detectable you can end up with a lot of clutter from other linux boxes that are being user admined on the network which are advertising 'rogue' printers. Maybe Arjan was talking about a central master list approach as a mechanism to address this sort of issue. -jef"then again maybe not"spaleta From mattdm at mattdm.org Wed Feb 2 15:07:53 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Feb 2005 10:07:53 -0500 Subject: system-config-printer In-Reply-To: <20050202104940.GT5322@redhat.com> References: <20050201121139.GR5322@redhat.com> <1107295514.4232.23.camel@localhost.localdomain> <20050201230606.GA20438@jadzia.bu.edu> <20050202104940.GT5322@redhat.com> Message-ID: <20050202150753.GA16097@jadzia.bu.edu> On Wed, Feb 02, 2005 at 10:49:40AM +0000, Tim Waugh wrote: > > Don't forget an easy way to distribute configurations to client systems. > That certainly was important before we switched to CUPS, but is it > now? Doesn't browsing solve that problem? Why should people have to browse anywhere? They just want their systems to come set up so that when they print something, it comes out on the right printer, with the right duplexing options and so on -- just like it's always been. And what about those printers/print queues that don't support the browsing protocol? And how do we keep rogue (perhaps fake) printers off the network? -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From shiva at sewingwitch.com Wed Feb 2 15:15:47 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 02 Feb 2005 07:15:47 -0800 Subject: ntpd startup too early + hangs In-Reply-To: <200502022205.12933.symbiont@berlios.de> References: <200502022205.12933.symbiont@berlios.de> Message-ID: <605EB8053F731506DE6D8F63@[10.0.0.4]> --On Wednesday, February 02, 2005 10:05 PM +0800 Jeff Pitman wrote: > It's actually ntpdate, executed by the startup script with a sampling of > 8 packets (-p 8). ntpdate is actually supposed to be a deprecated > utility. Remove /etc/ntp/step-servers to skip the ntpdate step, which > will block the bootup process. ntpd will then be executed with the -g > parameter, which will perform ntpdate type functionality on a first > synchronization with the time servers. Subsequent syncs will use > slew/step corrections instead. > > This *should* be bugzilla'd. I don't see anything that matches. Is this still true in FC3? (I'm still using FC2.) From shiva at sewingwitch.com Wed Feb 2 15:17:22 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 02 Feb 2005 07:17:22 -0800 Subject: ntpd startup too early + hangs In-Reply-To: <672F9B1A002B51BEA2769E1C@[10.0.0.4]> References: <672F9B1A002B51BEA2769E1C@[10.0.0.4]> Message-ID: --On Wednesday, February 02, 2005 6:03 AM -0800 Kenneth Porter wrote: > Best place to discuss changes to that program would be the ntp newsgroup, > comp.protocols.time.ntp. I just found that NTP has a wiki: It also has a Bugzilla: From shiva at sewingwitch.com Wed Feb 2 15:28:47 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 02 Feb 2005 07:28:47 -0800 Subject: Change to bzip2? In-Reply-To: <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> Message-ID: --On Wednesday, February 02, 2005 3:45 PM +0100 Florian La Roche wrote: > I think staying with gzip is ok as it really is a good middle ground > between speed and disk compression ratio. bzip2 "feels" noticable slower. Is that true on extraction or only on creation? From n3npq at nc.rr.com Wed Feb 2 15:31:41 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 10:31:41 -0500 Subject: Change to bzip2? In-Reply-To: References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> Message-ID: <4200F25D.7080805@nc.rr.com> Kenneth Porter wrote: > --On Wednesday, February 02, 2005 3:45 PM +0100 Florian La Roche > wrote: > >> I think staying with gzip is ok as it really is a good middle ground >> between speed and disk compression ratio. bzip2 "feels" noticable >> slower. > > > Is that true on extraction or only on creation? Add --stats to any rpm command that does whatever you want to benchmark, and make your own measurement. 73 de Jeff From elanthis at awesomeplay.com Wed Feb 2 15:32:41 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 02 Feb 2005 10:32:41 -0500 Subject: Change to bzip2? In-Reply-To: References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> Message-ID: <1107358361.5418.11.camel@support02.civic.twp.ypsilanti.mi.us> On Wed, 2005-02-02 at 07:28 -0800, Kenneth Porter wrote: > --On Wednesday, February 02, 2005 3:45 PM +0100 Florian La Roche > wrote: > > > I think staying with gzip is ok as it really is a good middle ground > > between speed and disk compression ratio. bzip2 "feels" noticable slower. > > Is that true on extraction or only on creation? Both. I wonder how much time has been spent by assembler-gods trying to optimize bzip2 for various architectures, though... From jnovy at redhat.com Wed Feb 2 16:00:04 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 02 Feb 2005 17:00:04 +0100 Subject: Change to bzip2? In-Reply-To: <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> Message-ID: <1107360004.22153.18.camel@obelix.redhat.usu> On Wed, 2005-02-02 at 15:45 +0100, Florian La Roche wrote: > On Wed, Feb 02, 2005 at 06:03:24AM -0800, Steve G wrote: > > Hi, > > > > With the discussion about trimming specfile changelogs to save space and improve > > downloads...why not go one step further? Mandrake has been using bzip2 for a > > while and it works just as well and files are significantly smaller. The > > conversion could be done in several steps: > > > > 1) man pages - less already handles bzipped man pages > > 2) info pages - I submited patch in bz #128637 to try to get it working > > 3) tar > > 4) rpms - I'm sure the patch is in Mandrake's version > > > > Thoughts? > > bzip2 is only used for the cpio-packed file-data, the rpm-header is > not compressed. For the repo-data the changelog can also be trimmed, > only if you need to copy the rpm header unmodified this is actually > getting a problem (e.g. if you later-on want to verify the md5sum to > be the same as in full rpms you download or similar things). > > I think staying with gzip is ok as it really is a good middle ground > between speed and disk compression ratio. bzip2 "feels" noticable slower. In my opinion a conversion to bzip2 is a right thing to do. I'm also trying to keep almost everything compressed to bzip2 because of its significantly better compression scheme and performance. I'll illustrate this on the mc tarball: -rw-rw-r-- 1 jnovy jnovy 2831562 Jan 28 09:52 mc-4.6.1-pre3.tar.bz2 -rw-rw-r-- 1 jnovy jnovy 3956127 Feb 2 15:26 mc-4.6.1-pre3.tar.gz where we can see that the gzipped tarball is larger of more than 1/3 in comparison with the bzipped one. Decompression times are: gunzip decompression: real 0m0.257s user 0m0.198s sys 0m0.059s bunzip2 decompression: real 0m1.665s user 0m1.567s sys 0m0.098s so a conclusion could be that bunzip2 is about 6-7 times slower than gunzip. This is unfortunately a common myth among developers because bzip2 uses the best compression (-9, so 900k blocks for BWT) by default and gzip uses compromised performance (-6), but that means something different compared to bzip2 since gzip is LZ77 based. bzip2 is scalable enough to use even better compression times or performance. If you consider that for the fastest (and worst) -1 compression with bzip2 you'll get: -rw-rw-r-- 1 jnovy jnovy 3592894 Feb 2 16:08 mc-4.6.1-pre3.tar.bz2 what is even better than the best compression (-9) with gzip and decompression time is: real 0m1.076s user 0m1.003s sys 0m0.073s so about 4 times slower than gzip. The question is what is the priority at the moment, if a space consumed by the file or a decompression time. There are also some projects such as pbzip2 (http://compression.ca/pbzip2/) that uses a fact that bzip2 actually compresses parts of large files in separated blocks, so that the BWT and Huffman encoding phase can be performed separately on these blocks simultaneously in multiple threads what speeds compression/decompression times significantly up on smp machines. Further if you consider scalability of bzip2 which has a compression range: best (-9): 2831562, worst (-1): 3592894 and gzip: best (-9): 3931362, worst (-1): 4634277 I think bzip2 is the winner at least from the future point of view. Cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From nutello at sweetness.com Wed Feb 2 16:04:07 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Wed, 2 Feb 2005 17:04:07 +0100 Subject: Change to bzip2? In-Reply-To: <1107358361.5418.11.camel@support02.civic.twp.ypsilanti.mi.us> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107358361.5418.11.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20050202160407.GA18565@plain.rackshack.net> On Wed, Feb 02, 2005 at 10:32:41AM -0500, Sean Middleditch wrote: > > > I think staying with gzip is ok as it really is a good middle ground > > > between speed and disk compression ratio. bzip2 "feels" noticable slower. > > Is that true on extraction or only on creation? > Both. Then there's LZMA, which is even slower than bzip2 on compression, but faster and less memory-hungry on decompression. It also tends to obtain higher compression ratios and has a multithreaded implementation. -- Rudi From harald at redhat.com Wed Feb 2 16:04:08 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Feb 2005 17:04:08 +0100 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <4200C011.30809@redhat.com> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <4200C011.30809@redhat.com> Message-ID: <4200F9F8.6080709@redhat.com> Harald Hoyer wrote: > John Thacker wrote: >> nmap-frontend is one. > porting to gtk2 should not be too hard... Ok, evil quickported nmapfe to gtk2. Maybe some gtk freak could look after it, so that it can compile without "-DGTK_ENABLE_BROKEN" (configure.ac) and runtime errors and warnings. From fedora-devel at camperquake.de Wed Feb 2 16:06:03 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 2 Feb 2005 17:06:03 +0100 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <4200F9F8.6080709@redhat.com>; from harald@redhat.com on Wed, Feb 02, 2005 at 05:04:08PM +0100 References: <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <4200C011.30809@redhat.com> <4200F9F8.6080709@redhat.com> Message-ID: <20050202170603.A18968@ryoko.camperquake.de> On Wed, Feb 02, 2005 at 05:04:08PM +0100, Harald Hoyer wrote: > Ok, evil quickported nmapfe to gtk2. Maybe some gtk freak could look after it, > so that it can compile without "-DGTK_ENABLE_BROKEN" (configure.ac) and > runtime errors and warnings. Do we actually care about runtime warnings? There hardly seems to be a gtk program that does not produce them. From cra at WPI.EDU Wed Feb 2 16:10:27 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 2 Feb 2005 11:10:27 -0500 Subject: ntpd startup too early + hangs In-Reply-To: References: Message-ID: <20050202161027.GH11938@angus.ind.WPI.EDU> On Wed, Feb 02, 2005 at 07:59:12AM -0500, Dan Williams wrote: > Problem is that ntpd is too dumb to know when you have a network connecction and > when you don't. NetworkManager can't be started earlier because dbus & hal > aren't started early, because they are installed in /usr and that's not > guaranteed to be mounted until somewhere in the middle of the boot process. > ntpd needs to be smarter about when it does & does not look for servers based on > whether or not there's a connection. How about switching to OpenNTPD? http://www.openntpd.org/ From n3npq at nc.rr.com Wed Feb 2 16:20:10 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 11:20:10 -0500 Subject: Change to bzip2? In-Reply-To: <1107360004.22153.18.camel@obelix.redhat.usu> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> Message-ID: <4200FDBA.5080107@nc.rr.com> Jindrich Novy wrote: >On Wed, 2005-02-02 at 15:45 +0100, Florian La Roche wrote: > > >>On Wed, Feb 02, 2005 at 06:03:24AM -0800, Steve G wrote: >> >> >>>Hi, >>> >>>With the discussion about trimming specfile changelogs to save space and improve >>>downloads...why not go one step further? Mandrake has been using bzip2 for a >>>while and it works just as well and files are significantly smaller. The >>>conversion could be done in several steps: >>> >>>1) man pages - less already handles bzipped man pages >>>2) info pages - I submited patch in bz #128637 to try to get it working >>>3) tar >>>4) rpms - I'm sure the patch is in Mandrake's version >>> >>>Thoughts? >>> >>> >>bzip2 is only used for the cpio-packed file-data, the rpm-header is >>not compressed. For the repo-data the changelog can also be trimmed, >>only if you need to copy the rpm header unmodified this is actually >>getting a problem (e.g. if you later-on want to verify the md5sum to >>be the same as in full rpms you download or similar things). >> >>I think staying with gzip is ok as it really is a good middle ground >>between speed and disk compression ratio. bzip2 "feels" noticable slower. >> >> > >In my opinion a conversion to bzip2 is a right thing to do. I'm also >trying to keep almost everything compressed to bzip2 because of its >significantly better compression scheme and performance. I'll illustrate >this on the mc tarball: > >-rw-rw-r-- 1 jnovy jnovy 2831562 Jan 28 09:52 mc-4.6.1-pre3.tar.bz2 >-rw-rw-r-- 1 jnovy jnovy 3956127 Feb 2 15:26 mc-4.6.1-pre3.tar.gz > >where we can see that the gzipped tarball is larger of more than 1/3 in >comparison with the bzipped one. Decompression times are: > >gunzip decompression: >real 0m0.257s >user 0m0.198s >sys 0m0.059s > >bunzip2 decompression: >real 0m1.665s >user 0m1.567s >sys 0m0.098s > >so a conclusion could be that bunzip2 is about 6-7 times slower than >gunzip. This is unfortunately a common myth among developers because >bzip2 uses the best compression (-9, so 900k blocks for BWT) by default >and gzip uses compromised performance (-6), but that means something >different compared to bzip2 since gzip is LZ77 based. > >bzip2 is scalable enough to use even better compression times or >performance. If you consider that for the fastest (and worst) -1 >compression with bzip2 you'll get: > >-rw-rw-r-- 1 jnovy jnovy 3592894 Feb 2 16:08 mc-4.6.1-pre3.tar.bz2 > >what is even better than the best compression (-9) with gzip and >decompression time is: > >real 0m1.076s >user 0m1.003s >sys 0m0.073s > >so about 4 times slower than gzip. > >The question is what is the priority at the moment, if a space consumed >by the file or a decompression time. > >There are also some projects such as pbzip2 >(http://compression.ca/pbzip2/) that uses a fact that bzip2 actually >compresses parts of large files in separated blocks, so that the BWT and >Huffman encoding phase can be performed separately on these blocks >simultaneously in multiple threads what speeds compression/decompression >times significantly up on smp machines. > >Further if you consider scalability of bzip2 which has a compression >range: > >best (-9): 2831562, worst (-1): 3592894 >and gzip: >best (-9): 3931362, worst (-1): 4634277 > >I think bzip2 is the winner at least from the future point of view. > > Nicely done. Now try to get the -9 changed in rpm. And it also makes little sense to bzip tarballs that end up in gzipped payloads imho. 73 de Jeff From harald at redhat.com Wed Feb 2 16:30:11 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Feb 2005 17:30:11 +0100 Subject: ntpd startup too early + hangs In-Reply-To: <20050202161027.GH11938@angus.ind.WPI.EDU> References: <20050202161027.GH11938@angus.ind.WPI.EDU> Message-ID: <42010013.9090800@redhat.com> Charles R. Anderson wrote: > How about switching to OpenNTPD? > > http://www.openntpd.org/ > Hmm, this is more a client and as a server, I think the HW support is lacking. So, no stratum 1 server is possible with openntpd. From pri.rhl3 at iadonisi.to Wed Feb 2 16:37:10 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Wed, 02 Feb 2005 11:37:10 -0500 Subject: Change to bzip2? In-Reply-To: <4200FDBA.5080107@nc.rr.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> <4200FDBA.5080107@nc.rr.com> Message-ID: <1107362231.14003.5.camel@tuxpaq> On Wed, 2005-02-02 at 11:20 -0500, Jeff Johnson wrote: [snip] > > > >I think bzip2 is the winner at least from the future point of view. > > > > > > Nicely done. > > Now try to get the -9 changed in rpm. Never mind that, he needs more than just one data point to prove the point. I just tried compressing and decompressing linux-2.6.10.tar with 'bzip2 -9' and 'gzip -9' and still get a seven-fold increase in performance for gzip. > And it also makes little sense to bzip tarballs that end up in gzipped > payloads imho. Which begs the question ... why has Red Hat (at least in some cases, historically), veered (admittedly only slightly) from the pristine source principle by uncompressing gzipped tarballs and recompressing them with bzip2 only to stuff them in into an rpm if rpm uses gzip? -- -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 philip at balister.org Wed Feb 2 17:02:21 2005 From: philip at balister.org (Philip Balister) Date: Wed, 02 Feb 2005 12:02:21 -0500 Subject: ntpd startup too early + hangs In-Reply-To: <42010013.9090800@redhat.com> References: <20050202161027.GH11938@angus.ind.WPI.EDU> <42010013.9090800@redhat.com> Message-ID: <1107363741.6242.29.camel@localhost.localdomain> Well, most of us are using ntp as a client. People running hi stratum servers and/or need hardware reference clocks should have no trouble installing xntpd. Philip On Wed, 2005-02-02 at 17:30 +0100, Harald Hoyer wrote: > Charles R. Anderson wrote: > > How about switching to OpenNTPD? > > > > http://www.openntpd.org/ > > > > Hmm, this is more a client and as a server, I think the HW support is lacking. > So, no stratum 1 server is possible with openntpd. > From cra at WPI.EDU Wed Feb 2 16:49:15 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 2 Feb 2005 11:49:15 -0500 Subject: ntpd startup too early + hangs In-Reply-To: <42010013.9090800@redhat.com> References: <20050202161027.GH11938@angus.ind.WPI.EDU> <42010013.9090800@redhat.com> Message-ID: <20050202164915.GI11938@angus.ind.WPI.EDU> On Wed, Feb 02, 2005 at 05:30:11PM +0100, Harald Hoyer wrote: > Charles R. Anderson wrote: > >How about switching to OpenNTPD? > > > >http://www.openntpd.org/ > > > > Hmm, this is more a client and as a server, I think the HW support is > lacking. So, no stratum 1 server is possible with openntpd. Server software vs. client software have differing goals. If we want to improve the desktop experience, we may need to provide different software... I'm going to take a look at this to see if it even solves this problem or not. From symbiont at berlios.de Wed Feb 2 16:54:48 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 3 Feb 2005 00:54:48 +0800 Subject: ntpd startup too early + hangs In-Reply-To: <20050202164915.GI11938@angus.ind.WPI.EDU> References: <42010013.9090800@redhat.com> <20050202164915.GI11938@angus.ind.WPI.EDU> Message-ID: <200502030054.48468.symbiont@berlios.de> On Thursday 03 February 2005 00:49, Charles R. Anderson wrote: > I'm going to take a look at this to see if it even solves this > problem or not. Take a look at: # rm /etc/ntp/step-tickers Don't break your back, because the fix isn't all that difficult. -- -jeff From n3npq at nc.rr.com Wed Feb 2 16:57:46 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 11:57:46 -0500 Subject: Change to bzip2? In-Reply-To: <1107362231.14003.5.camel@tuxpaq> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> <4200FDBA.5080107@nc.rr.com> <1107362231.14003.5.camel@tuxpaq> Message-ID: <4201068A.3080908@nc.rr.com> Paul Iadonisi wrote: >On Wed, 2005-02-02 at 11:20 -0500, Jeff Johnson wrote: > > > >>And it also makes little sense to bzip tarballs that end up in gzipped >>payloads imho. >> >> > > Which begs the question ... why has Red Hat (at least in some cases, >historically), veered (admittedly only slightly) from the pristine >source principle by uncompressing gzipped tarballs and recompressing >them with bzip2 only to stuff them in into an rpm if rpm uses gzip? > > > Well that's a different qestion. At the end of a release, there is invariably a fire drill to attempt to fit on one fewer CD's. Part of the exercise usually results in tarballs within *.src.rpm's being recompressed to save space. Not that it saves much, nor ar *.src.rpm's usually part of the primary battle. Certainly the contents are not changed. All depends on whether you consider recomprssing a modification to "pristine sources". 73 de Jeff From cra at WPI.EDU Wed Feb 2 16:59:53 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Wed, 2 Feb 2005 11:59:53 -0500 Subject: ntpd startup too early + hangs In-Reply-To: <200502030054.48468.symbiont@berlios.de> References: <42010013.9090800@redhat.com> <20050202164915.GI11938@angus.ind.WPI.EDU> <200502030054.48468.symbiont@berlios.de> Message-ID: <20050202165953.GJ11938@angus.ind.WPI.EDU> On Thu, Feb 03, 2005 at 12:54:48AM +0800, Jeff Pitman wrote: > On Thursday 03 February 2005 00:49, Charles R. Anderson wrote: > > I'm going to take a look at this to see if it even solves this > > problem or not. > > Take a look at: > > # rm /etc/ntp/step-tickers > > Don't break your back, because the fix isn't all that difficult. That isn't a fix. In fact, if you remove that, ntpd might not even start if your local clock is too far off. From linux_4ever at yahoo.com Wed Feb 2 17:05:14 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 2 Feb 2005 09:05:14 -0800 (PST) Subject: Change to bzip2? In-Reply-To: <4200FDBA.5080107@nc.rr.com> Message-ID: <20050202170514.81797.qmail@web50608.mail.yahoo.com> >Now try to get the -9 changed in rpm. brp-compress: @@ -8,8 +8,8 @@ cd $RPM_BUILD_ROOT # Compress man pages -COMPRESS="gzip -9 -n" -COMPRESS_EXT=.gz +COMPRESS="bzip2 -9 -n" +COMPRESS_EXT=.bz2 >And it also makes little sense to bzip tarballs that end up in >gzipped payloads imho. It does when you realize that loading a man page is milliseconds slower to bring up using bzip2. And downloading updates via a modem can be 10's of minutes faster when they are compressed with bzip2. Compare the size of virtually any tarball: kde, kernel, open office, tetex, .... You can fit more packages on an iso CD, too. Looking through the bzip2 source code, it looks like its been optimized pretty well. But, there is a little room for improvement - even in C and no assembler has been added. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From n3npq at nc.rr.com Wed Feb 2 17:06:28 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 12:06:28 -0500 Subject: Change to bzip2? In-Reply-To: <4200FDBA.5080107@nc.rr.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> <4200FDBA.5080107@nc.rr.com> Message-ID: <42010894.8050603@nc.rr.com> Jeff Johnson wrote: > >> >> >> I think bzip2 is the winner at least from the future point of view. >> >> > > Nicely done. > > Now try to get the -9 changed in rpm. > > And it also makes little sense to bzip tarballs that end up in gzipped > payloads imho. Which reminds me of another possible space saving in *.rpm packages: Package headers are not compressed at all. There are two issues: 1) legacy compatibility with existing deployed rpmlib. yawn ... 2) insuring that compression is applied to signed blobs, rather thatn signing compressed blobs. If compressed blobs are signed, then the compression cannot be changed without resigning, which is often logistically impossible. One of several fundamental design flaw in rpm's header+payload scheme imho. Anyways, getting headers compressed (which are typically 10-15% of package size), would presumably save 5-7.5% or so of package size, probably a bigger saving than anything else yet proposed. 73 de Jeff From pknirsch at redhat.com Wed Feb 2 17:09:49 2005 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 02 Feb 2005 18:09:49 +0100 Subject: Change to bzip2? In-Reply-To: <1107362231.14003.5.camel@tuxpaq> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> <4200FDBA.5080107@nc.rr.com> <1107362231.14003.5.camel@tuxpaq> Message-ID: <4201095D.4020208@redhat.com> Paul Iadonisi wrote: > > [snip] > > Which begs the question ... why has Red Hat (at least in some cases, > historically), veered (admittedly only slightly) from the pristine > source principle by uncompressing gzipped tarballs and recompressing > them with bzip2 only to stuff them in into an rpm if rpm uses gzip? > I think that compressing tarballs of source tars in srpms is a little different than compressing the payload in binary rpms. Because for the first you don't actually need the least itsybitsy of speed and using bzip2 safes quite a bit of storage for source tarballs. For binary rpms otoh it's different as there you want a quick installation, so uncompression speed does matter there, and the difference for the binary payload compress with bzip2 and gzip should be considerably less drastic than with source tarballs. As a test i've created a cpio archive of the current openoffice package in FC: [root at hamburg tmp]# ll foo.cpio -rw-r--r-- 1 root root 98993152 Feb 2 17:51 foo.cpio Now the different runtimes and sizes for gzip: [root at hamburg tmp]# /usr/bin/time gzip -9 foo.cpio 20.15user 0.31system 0:20.47elapsed 99%CPU [root at hamburg tmp]# ll foo.cpio.gz -rw-r--r-- 1 root root 34026424 Feb 2 17:51 foo.cpio.gz [root at hamburg tmp]# /usr/bin/time gunzip -9 foo.cpio.gz 1.19user 0.37system 0:01.65elapsed 94%CPU Now the same for bzip2: [root at hamburg tmp]# /usr/bin/time bzip2 -9 foo.cpio 52.49user 0.45system 0:53.05elapsed 99%CPU [root at hamburg tmp]# ll foo.cpio.bz2 -rw-r--r-- 1 root root 30408374 Feb 2 17:51 foo.cpio.bz2 [root at hamburg tmp]# /usr/bin/time bunzip2 foo.cpio.bz2 11.73user 0.69system 0:12.47elapsed 99%CPU So the speed difference in unpacking is about 1:10, size difference is about 1.12:1 which clearly demonstrates my point. I don't want my installation to take 10 times longer for the sake of 12% space saving in the binary rpms. My uncompressed $0.02 Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From linux_4ever at yahoo.com Wed Feb 2 17:10:20 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 2 Feb 2005 09:10:20 -0800 (PST) Subject: Change to bzip2? In-Reply-To: <42010894.8050603@nc.rr.com> Message-ID: <20050202171020.20766.qmail@web50601.mail.yahoo.com> >Anyways, getting headers compressed (which are typically 10-15% of package >size), would presumably save 5-7.5% or so of package size, probably a bigger >saving than anything else yet proposed. I like this idea, too. Would there be impacts to rpm querries? -Steve Grubb __________________________________ Do you Yahoo!? All your favorites on one personal page ? Try My Yahoo! http://my.yahoo.com From n3npq at nc.rr.com Wed Feb 2 17:15:21 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 12:15:21 -0500 Subject: Change to bzip2? In-Reply-To: <20050202170514.81797.qmail@web50608.mail.yahoo.com> References: <20050202170514.81797.qmail@web50608.mail.yahoo.com> Message-ID: <42010AA9.2020501@nc.rr.com> Steve G wrote: >>Now try to get the -9 changed in rpm. >> >> > >brp-compress: > >@@ -8,8 +8,8 @@ > cd $RPM_BUILD_ROOT > > # Compress man pages >-COMPRESS="gzip -9 -n" >-COMPRESS_EXT=.gz >+COMPRESS="bzip2 -9 -n" >+COMPRESS_EXT=.bz2 > > The patch is the easy part ;-) > > >>And it also makes little sense to bzip tarballs that end up in >>gzipped payloads imho. >> >> I was referring to *.src.rpm's, rather than man pages. Apologies for the confusion. >It does when you realize that loading a man page is milliseconds slower to bring >up using bzip2. And downloading updates via a modem can be 10's of minutes faster >when they are compressed with bzip2. Compare the size of virtually any tarball: >kde, kernel, open office, tetex, .... You can fit more packages on an iso CD, >too. > > Yep, user response time for man needs to be considered too. So does build startup times when uncompressing big honking tarballs from *.src.rpm's. >Looking through the bzip2 source code, it looks like its been optimized pretty >well. But, there is a little room for improvement - even in C and no assembler >has been added. > > The threading is prolly a bigger win than any optimize, as bulk data decompression is invariably i/o, not cpu, bound. Trickier when a serial stream is used to concatenate blocks, or blocks are chained, too. 73 de Jeff From riel at redhat.com Wed Feb 2 17:15:39 2005 From: riel at redhat.com (Rik van Riel) Date: Wed, 2 Feb 2005 12:15:39 -0500 (EST) Subject: ntpd startup too early + hangs In-Reply-To: References: Message-ID: On Wed, 2 Feb 2005, Dan Williams wrote: > ntpd needs to be smarter about when it does & does not look for servers > based on whether or not there's a connection. You could say that about every daemon we have, including eg. ypbind. Alternatively, we could look at the impact that networkmanager and other new desktop programs have on the order in which the various services should be started up, and correct that. -- "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 riel at redhat.com Wed Feb 2 17:21:16 2005 From: riel at redhat.com (Rik van Riel) Date: Wed, 2 Feb 2005 12:21:16 -0500 (EST) Subject: Change to bzip2? In-Reply-To: <1107358361.5418.11.camel@support02.civic.twp.ypsilanti.mi.us> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107358361.5418.11.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: On Wed, 2 Feb 2005, Sean Middleditch wrote: > I wonder how much time has been spent by assembler-gods trying to > optimize bzip2 for various architectures, though... I don't think that's going to matter, since bzip2 is cache unfriendly - meaning that on most consumer grade CPUs the window of data that's being accessed is too big to fit in the CPU cache. Because a cache miss (when data is fetched from RAM) can easily take 200-400 cpu cycles, there is no way for a program to both have a big cache footprint and run fast. Gzip, on the other hand, manipulates a compression dictionary that fits in the cpu cache, so the actual decompression can be done at full speed. -- "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 n3npq at nc.rr.com Wed Feb 2 17:26:00 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 12:26:00 -0500 Subject: Change to bzip2? In-Reply-To: <20050202171020.20766.qmail@web50601.mail.yahoo.com> References: <20050202171020.20766.qmail@web50601.mail.yahoo.com> Message-ID: <42010D28.2040400@nc.rr.com> Steve G wrote: >>Anyways, getting headers compressed (which are typically 10-15% of package >>size), would presumably save 5-7.5% or so of package size, probably a bigger >>saving than anything else yet proposed. >> >> > >I like this idea, too. Would there be impacts to rpm querries? > > Zero, I speak of headers in packages, not headers in the database, where speed of retrieval, not size, is clearly the operant metric. The legacy issues are show stoppers, however, and voiding header+payload signatures (which need to be abandoned for lots of reasons, 2 signatures schemes is worse than either) will put the kibosh on any change afaik. Oh well ... FWIW: Headers are gonna change in rpm-4.4.2 to permit use of xml to represent header content, and there's four or five other flaws that need addressing at the same time (like permitting an array of binary elements, and adding an ASN.1 like type to ease tertirary lookup of data embedded in tags (think: signature/pubkey fingerprints.) If I gotta break something in rpm package format, I might as well break everything, the degree of pain is exactly the same imho. 73 de Jeff From dcbw at redhat.com Wed Feb 2 17:31:45 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 02 Feb 2005 12:31:45 -0500 Subject: ntpd startup too early + hangs In-Reply-To: References: Message-ID: <1107365505.27197.21.camel@dcbw.boston.redhat.com> On Wed, 2005-02-02 at 12:15 -0500, Rik van Riel wrote: > On Wed, 2 Feb 2005, Dan Williams wrote: > > > ntpd needs to be smarter about when it does & does not look for servers > > based on whether or not there's a connection. > > You could say that about every daemon we have, including > eg. ypbind. Alternatively, we could look at the impact > that networkmanager and other new desktop programs have > on the order in which the various services should be > started up, and correct that. Remember though, that just because NetworkManager has started doesn't mean that you have an actual network connection, same as we've been discussing, where you start up with the cable unplugged and the 'network' script times out. So even if NetworkManager was started, the daemons that depend on "network" would _still_ need to be aware of whether or not there's a connection. NetworkManager provides that information through a client library, but that's written with glib right now (because its soooooo much easier to use dbus with a binding rather than 500 lines of select() and associated code to deal with threads and callbacks to the main thread). The plan is to write a non-glib, non-QT dependent client library in addition to the glib-based one, so that system services will not have to link against glib. To figure out whether you're connected, you would then simply do: libnm_ctx *nm_ctx = libnm_init (); switch (libnm_get_network_status (nm_ctx)) { LIBNM_NO_NETWORK_CONNECTION: have_network_connection = FALSE; break; LIBNM_NO_DBUS: LIBNM_NO_NETWORKMANAGER: LIBNM_ACTIVE_NETWORK_CONNECTION: default: have_network_connection = TRUE; break; } libnm_shutdown (nm_ctx);ctx); This assumes that if NetworkManager is not running, you want the previous behavior of simply assuming there is a network conneciton. libnm should (and does in the current glib implementation) have a callback interface to alert the application of network state changes without having to poll. The DBUS code runs in a separate thread and so does not block anything the app is doing. Dan From harald at redhat.com Wed Feb 2 17:35:05 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Feb 2005 18:35:05 +0100 Subject: ntpd startup too early + hangs In-Reply-To: <20050202165953.GJ11938@angus.ind.WPI.EDU> References: <42010013.9090800@redhat.com> <20050202164915.GI11938@angus.ind.WPI.EDU> <200502030054.48468.symbiont@berlios.de> <20050202165953.GJ11938@angus.ind.WPI.EDU> Message-ID: <42010F49.3060004@redhat.com> Charles R. Anderson wrote: > That isn't a fix. In fact, if you remove that, ntpd might not even > start if your local clock is too far off. > No, because then the -g option is added. -g Normally, ntpd exits if the offset exceeds the sanity limit, which is 1000 s by default. If the sanity limit is set to zero, no sanity checking is performed and any offset is acceptable. This option overrides the limit and allows the time to be set to any value without restriction; however, this can happen only once. After that, ntpd will exit if the limit is exceeded. This option can be used with the -q option. From kyrre at solution-forge.net Wed Feb 2 17:38:33 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 02 Feb 2005 18:38:33 +0100 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107204139.5316.6.camel@localhost.localdomain> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> <1107171161.5777.11.camel@angua.localnet> <1107177709.9022.17.camel@ulysse.olympe.o2t> <32901.81.191.130.121.1107179444.squirrel@81.191.130.121> <1107204139.5316.6.camel@localhost.localdomain> Message-ID: <1107365912.4152.61.camel@localhost.localdomain> man, 31.01.2005 kl. 21.42 skrev Rodd Clarkson: > On Mon, 2005-01-31 at 19:26 +0530, Rahul Sundaram wrote: > > Hi > > > > > Yes. But it isn't mandatory. They are broken, but they only look broken in > > > firefox at fc3 - so people believe that firefox is broken. > > > > it isnt mandatory. it is just a good design issue. firefox doesnt > > emulate IE quirks perfectly either. people believe firefox is broken > > on those IE specific websites too. thats a user education problem. > > > > > And yes, i do also remember that Mosaic had a gray background. 10 years ago. > > > > > > So, please, please set the *default* settings so that most pages doesn't > > > look broken. > > > if this is going to be done, change the gnome system colors on the > > whole to reflect this inorder to be consistent > > Actually, a web browser is a little like getting a ream of paper. While > you can get paper in a range of colors, when you ask your mate to grab a > ream of paper when he's at the office supplies, you expect him to come > back with a ream of 'white' paper, and almost all your documents are set > up for white paper unless you particularly wanted a different color. > > The same thing should happen with web-browsers. User's expect a white > background. Hell, a lot of bad web designers expect a white background. > > It might be worth asking the mozilla guys why the default background > color changed from grey to white. I suspect that it had something to do > with the fact that most users just went and changed the color to white > because the grey was annoying (they expected white). > > My point exactly. Now, can we fix this? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146907 From harald at redhat.com Wed Feb 2 17:39:59 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Feb 2005 18:39:59 +0100 Subject: ntpd startup too early + hangs In-Reply-To: <200502030054.48468.symbiont@berlios.de> References: <42010013.9090800@redhat.com> <20050202164915.GI11938@angus.ind.WPI.EDU> <200502030054.48468.symbiont@berlios.de> Message-ID: <4201106F.1050302@redhat.com> Jeff Pitman wrote: > On Thursday 03 February 2005 00:49, Charles R. Anderson wrote: > >>I'm going to take a look at this to see if it even solves this >>problem or not. > > > Take a look at: > > # rm /etc/ntp/step-tickers > > Don't break your back, because the fix isn't all that difficult. > Another solution would be to check in the initscript, if an IP is reachable via: # /sbin/ip -o route get to From symbiont at berlios.de Wed Feb 2 18:02:24 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 3 Feb 2005 02:02:24 +0800 Subject: ntpd startup too early + hangs In-Reply-To: <1107365505.27197.21.camel@dcbw.boston.redhat.com> References: <1107365505.27197.21.camel@dcbw.boston.redhat.com> Message-ID: <200502030202.25058.symbiont@berlios.de> On Thursday 03 February 2005 01:31, Dan Williams wrote: > Remember though, that just because NetworkManager has started doesn't > mean that you have an actual network connection, same as we've been > discussing, where you start up with the cable unplugged and the > 'network' script times out. ?So even if NetworkManager was started, > the daemons that depend on "network" would _still_ need to be aware > of whether or not there's a connection. Crazy idea: shut off all the daemons that need network (from normal init processing) and then only spawn them when appropriate from NetworkManager. -- -jeff From symbiont at berlios.de Wed Feb 2 18:06:07 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 3 Feb 2005 02:06:07 +0800 Subject: ntpd startup too early + hangs In-Reply-To: <20050202165953.GJ11938@angus.ind.WPI.EDU> References: <200502030054.48468.symbiont@berlios.de> <20050202165953.GJ11938@angus.ind.WPI.EDU> Message-ID: <200502030206.09159.symbiont@berlios.de> On Thursday 03 February 2005 00:59, Charles R. Anderson wrote: > That isn't a fix. Your right. The entire step-tickers kludge should be removed from init.d/ntpd and ntpdate should no longer be distributed. That would be the fix. ntpdate's retirement is clearly documented. -- -jeff From shiva at sewingwitch.com Wed Feb 2 18:10:15 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 02 Feb 2005 10:10:15 -0800 Subject: ntpd startup too early + hangs In-Reply-To: <200502030202.25058.symbiont@berlios.de> References: <1107365505.27197.21.camel@dcbw.boston.redhat.com> <200502030202.25058.symbiont@berlios.de> Message-ID: --On Thursday, February 03, 2005 2:02 AM +0800 Jeff Pitman wrote: > Crazy idea: shut off all the daemons that need network (from normal init > processing) and then only spawn them when appropriate from > NetworkManager. FYI, I just started a thread on this in comp.protocols.time.ntp, gateway'd to the ntp-questions mailing list: Look for the thread "ntpd, boot time, and hot plugging". From symbiont at berlios.de Wed Feb 2 18:21:14 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 3 Feb 2005 02:21:14 +0800 Subject: ntpd startup too early + hangs In-Reply-To: References: <200502030202.25058.symbiont@berlios.de> Message-ID: <200502030221.15148.symbiont@berlios.de> On Thursday 03 February 2005 02:10, Kenneth Porter wrote: > > Crazy idea: shut off all the daemons that need network (from normal > > init processing) and then only spawn them when appropriate from > > NetworkManager. > > FYI, I just started a thread on this in comp.protocols.time.ntp, > gateway'd to the ntp-questions mailing list: The idea was to come up with a generic solution rather than escalating it upstream to ntp. Sendmail has similar problems. Postfix doesn't start unless listed interfaces are active. All of these require a re-look at the relationships and dependancies of the scripts found in /etc/init.d/ NetworkManager or a similar tool would be beneficial to "guide" this portion of the bootup process. -- -jeff From tibbs at math.uh.edu Wed Feb 2 18:23:20 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 02 Feb 2005 12:23:20 -0600 Subject: ntpd startup too early + hangs In-Reply-To: <42010013.9090800@redhat.com> (Harald Hoyer's message of "Wed, 02 Feb 2005 17:30:11 +0100") References: <20050202161027.GH11938@angus.ind.WPI.EDU> <42010013.9090800@redhat.com> Message-ID: >>>>> "HH" == Harald Hoyer writes: HH> Hmm, this is more a client and as a server, I think the HW support HH> is lacking. So, no stratum 1 server is possible with openntpd. Which is fine for an occasionally connected laptop or a plain desktop, I'd think. Has anyone packaged it for extras? Everything else about OpenNTPD seems quite fantastic and I'd certainly replace the stock ntpd everywhere if testing shows it to work as well as advertised. - J< From ronny-vlug at vlugnet.org Wed Feb 2 18:43:11 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Wed, 2 Feb 2005 19:43:11 +0100 Subject: system-config-printer In-Reply-To: <1107342496.4143.81.camel@laptopd505.fenrus.org> References: <20050201121139.GR5322@redhat.com> <20050202104940.GT5322@redhat.com> <1107342496.4143.81.camel@laptopd505.fenrus.org> Message-ID: <200502021943.11645.ronny-vlug@vlugnet.org> On Wednesday 02 February 2005 12:08, Arjan van de Ven wrote: > On Wed, 2005-02-02 at 10:49 +0000, Tim Waugh wrote: > > On Tue, Feb 01, 2005 at 06:06:06PM -0500, Matthew Miller wrote: > > > On Tue, Feb 01, 2005 at 05:05:14PM -0500, Havoc Pennington wrote: > > > > The remaining design would be the sysadmin UI, primarily for > > > > configuring a print *server*. There's a general problem here that we > > > > need to define > > > > > > Don't forget an easy way to distribute configurations to client > > > systems. > > > > That certainly was important before we switched to CUPS, but is it > > now? Doesn't browsing solve that problem? > > it would be nice if there was a zeroconf (or whatever that is called > this week) thing that advertized a "I have the master printer list for > cups HERE". All clients would then, without sysadmin work, use this > list. List would include prefered printer etc etc There needs to be a way to have some kind of favourite printers, always seeing a list with several hundred printers in corporate environment would be far from user friendly. And I think many people are not in the lucky situation to have a CUPS print server. -- http://LinuxWiki.org/RonnyBuchmann From thacker at math.cornell.edu Wed Feb 2 18:50:34 2005 From: thacker at math.cornell.edu (John Thacker) Date: Wed, 2 Feb 2005 13:50:34 -0500 Subject: ntpd startup too early + hangs In-Reply-To: <200502030202.25058.symbiont@berlios.de> References: <1107365505.27197.21.camel@dcbw.boston.redhat.com> <200502030202.25058.symbiont@berlios.de> Message-ID: <20050202185034.GA22480@thacker.dyndns.org> On Thu, Feb 03, 2005 at 02:02:24AM +0800, Jeff Pitman wrote: > Crazy idea: shut off all the daemons that need network (from normal init > processing) and then only spawn them when appropriate from > NetworkManager. Definitely crazy until NetworkManager can actually handle all connections. For example, right now it can't handle any machine with multiple active connections, which includes machines that do connection sharing. (Among other things, it doesn't believe that you would have a static IP with no default gateway.) John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ollie.clive.ia.us Wed Feb 2 18:17:28 2005 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 02 Feb 2005 12:17:28 -0600 Subject: XML RPM Header (was: Re: Change to bzip2?) In-Reply-To: <42010D28.2040400@nc.rr.com> References: <20050202171020.20766.qmail@web50601.mail.yahoo.com> <42010D28.2040400@nc.rr.com> Message-ID: <1107368249.6844.13.camel@localhost.localdomain> On Wed, 2005-02-02 at 12:26 -0500, Jeff Johnson wrote: > > Headers are gonna change in rpm-4.4.2 to permit use of xml to represent > header content, and there's four or five other flaws that need addressing > at the same time (like permitting an array of binary elements, and adding > an ASN.1 like type to ease tertirary lookup of data embedded in tags > (think: signature/pubkey fingerprints.) Since the RPM headers are going to be in XML, what about using XML Signatures? http://www.w3.org/TR/xmldsig-core/ http://www.aleksey.com/xmlsec/ Jeff -------------- next part -------------- A 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 Wed Feb 2 19:39:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Feb 2005 14:39:40 -0500 Subject: Change to bzip2? In-Reply-To: <20050202170514.81797.qmail@web50608.mail.yahoo.com> References: <4200FDBA.5080107@nc.rr.com> <20050202170514.81797.qmail@web50608.mail.yahoo.com> Message-ID: <20050202193940.GE1359@nostromo.devel.redhat.com> Steve G (linux_4ever at yahoo.com) said: > # Compress man pages > -COMPRESS="gzip -9 -n" > -COMPRESS_EXT=.gz > +COMPRESS="bzip2 -9 -n" > +COMPRESS_EXT=.bz2 Of course, when you're talking about man and info pages, what are the chances that you actually save significant space when you take the filesystem block size into account? Bill From ronny-vlug at vlugnet.org Wed Feb 2 20:19:54 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Wed, 2 Feb 2005 21:19:54 +0100 Subject: Change to bzip2? In-Reply-To: <20050202160407.GA18565@plain.rackshack.net> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <1107358361.5418.11.camel@support02.civic.twp.ypsilanti.mi.us> <20050202160407.GA18565@plain.rackshack.net> Message-ID: <200502022119.54550.ronny-vlug@vlugnet.org> On Wednesday 02 February 2005 17:04, Rudi Chiarito wrote: > On Wed, Feb 02, 2005 at 10:32:41AM -0500, Sean Middleditch wrote: > > > > I think staying with gzip is ok as it really is a good middle ground > > > > between speed and disk compression ratio. bzip2 "feels" noticable > > > > slower. > > > > > > Is that true on extraction or only on creation? > > > > Both. > > Then there's LZMA, which is even slower than bzip2 on compression, but > faster and less memory-hungry on decompression. It also tends to > obtain higher compression ratios and has a multithreaded implementation. To show some numbers: this is the current binary kernel LZMA default [ronny at bserv tmp]$ /usr/bin/time ./lzma kernel.cpio.lzma 92.08user 0.31system 1:32.59elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+3809minor)pagefaults 0swaps [ronny at bserv tmp]$ ls -lh kernel.cpio.lzma -rw-rw-r-- 1 ronny ronny 12M 2. Feb 21:02 kernel.cpio.lzma [ronny at bserv tmp]$ /usr/bin/time ./lzma -d /dev/null 5.02user 0.02system 0:05.05elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+997minor)pagefaults 0swaps LZMA best compression [ronny at bserv tmp]$ /usr/bin/time ./lzma -x kernel.cpio.lzma 122.63user 0.29system 2:02.95elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+3809minor)pagefaults 0swaps [ronny at bserv tmp]$ ls -lh kernel.cpio.lzma -rw-rw-r-- 1 ronny ronny 12M 2. Feb 21:06 kernel.cpio.lzma [ronny at bserv tmp]$ /usr/bin/time ./lzma -d /dev/null 5.03user 0.01system 0:05.04elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+997minor)pagefaults 0swaps GZIP default [ronny at bserv tmp]$ /usr/bin/time gzip kernel.cpio.gz 5.52user 0.22system 0:05.76elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+162minor)pagefaults 0swaps [ronny at bserv tmp]$ ls -lh kernel.cpio.gz -rw-rw-r-- 1 ronny ronny 16M 2. Feb 21:07 kernel.cpio.gz [ronny at bserv tmp]$ /usr/bin/time gzip -d /dev/null 0.75user 0.00system 0:00.76elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+129minor)pagefaults 0swaps GZIP -9 [ronny at bserv tmp]$ /usr/bin/time gzip -9 kernel.cpio.gz 17.38user 0.21system 0:17.61elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+162minor)pagefaults 0swaps [ronny at bserv tmp]$ ls -lh kernel.cpio.gz -rw-rw-r-- 1 ronny ronny 16M 2. Feb 21:08 kernel.cpio.gz [ronny at bserv tmp]$ /usr/bin/time gzip -d /dev/null 0.74user 0.01system 0:00.75elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+129minor)pagefaults 0swaps BZIP2 default (-9) [ronny at bserv tmp]$ /usr/bin/time bzip2 kernel.cpio.bz2 16.79user 0.20system 0:17.04elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1741minor)pagefaults 0swaps [ronny at bserv tmp]$ ls -lh kernel.cpio.bz2 -rw-rw-r-- 1 ronny ronny 14M 2. Feb 21:09 kernel.cpio.bz2 [ronny at bserv tmp]$ /usr/bin/time bzip2 -d /dev/null 6.20user 0.04system 0:06.25elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1016minor)pagefaults 0swaps BZIP2 -1 [ronny at bserv tmp]$ /usr/bin/time bzip2 -1 kernel.cpio.bz2 13.78user 0.21system 0:14.00elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+395minor)pagefaults 0swaps [ronny at bserv tmp]$ ls -lh kernel.cpio.bz2 -rw-rw-r-- 1 ronny ronny 16M 2. Feb 21:12 kernel.cpio.bz2 [ronny at bserv tmp]$ /usr/bin/time bzip2 -d /dev/null 4.12user 0.03system 0:04.16elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+230minor)pagefaults 0swaps Looking at these numbers I think gzip is still the best compromise -- http://LinuxWiki.org/RonnyBuchmann From linux_4ever at yahoo.com Wed Feb 2 20:39:19 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 2 Feb 2005 12:39:19 -0800 (PST) Subject: Change to bzip2? In-Reply-To: <20050202193940.GE1359@nostromo.devel.redhat.com> Message-ID: <20050202203919.6028.qmail@web50601.mail.yahoo.com> >Of course, when you're talking about man and info pages, what >are the chances that you actually save significant space when >you take the filesystem block size into account? To me, its not just about diskspace. Its also about bandwidth. I don't know about how block size affects the following data, but here it is: Uncompressed man page: du -sh /usr/share/man/man? 26M /usr/share/man/man1 2.9M /usr/share/man/man2 52M /usr/share/man/man3 2.5M /usr/share/man/man4 3.7M /usr/share/man/man5 16K /usr/share/man/man6 1.7M /usr/share/man/man7 5.7M /usr/share/man/man8 8.0K /usr/share/man/man9 1.3M /usr/share/man/mann Using gzip: du -sh /usr/share/man/man? 17M /usr/share/man/man1 2.5M /usr/share/man/man2 40M /usr/share/man/man3 640K /usr/share/man/man4 2.2M /usr/share/man/man5 16K /usr/share/man/man6 1016K /usr/share/man/man7 4.2M /usr/share/man/man8 8.0K /usr/share/man/man9 684K /usr/share/man/mann Total 82M Using bzip2: du -sh /usr/share/man/man? 16M /usr/share/man/man1 2.5M /usr/share/man/man2 40M /usr/share/man/man3 588K /usr/share/man/man4 2.1M /usr/share/man/man5 16K /usr/share/man/man6 976K /usr/share/man/man7 4.2M /usr/share/man/man8 8.0K /usr/share/man/man9 680K /usr/share/man/mann Total 81M One thing that skews the results is that some files were not compressed with bzip2 because they were symlinked. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From nphilipp at redhat.com Wed Feb 2 20:57:22 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Feb 2005 21:57:22 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> Message-ID: <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> On Wed, 2005-02-02 at 15:13 +0100, Florian La Roche wrote: > > Then the question is: why is the same changelog, i.e. the changelog of > > sub packages with the same source package, stored for each package > > individually? It could be stored once and be referenced from each sub > > package. It gets deleted once all references on it vanish. > > People might be able to install only one of the sub-packages. Um, I expressed myself not clearly. Of course the package files all contain the changelog, the normalization would only happen on the RPM DB level. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From n3npq at nc.rr.com Wed Feb 2 21:00:32 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 16:00:32 -0500 Subject: Change to bzip2? In-Reply-To: <20050202203919.6028.qmail@web50601.mail.yahoo.com> References: <20050202203919.6028.qmail@web50601.mail.yahoo.com> Message-ID: <42013F70.4030601@nc.rr.com> Steve G wrote: >>Of course, when you're talking about man and info pages, what >>are the chances that you actually save significant space when >>you take the filesystem block size into account? >> >> > >To me, its not just about diskspace. Its also about bandwidth. I don't know about >how block size affects the following data, but here it is: > >Uncompressed man page: >du -sh /usr/share/man/man? >26M /usr/share/man/man1 >2.9M /usr/share/man/man2 >52M /usr/share/man/man3 >2.5M /usr/share/man/man4 >3.7M /usr/share/man/man5 >16K /usr/share/man/man6 >1.7M /usr/share/man/man7 >5.7M /usr/share/man/man8 >8.0K /usr/share/man/man9 >1.3M /usr/share/man/mann > >Using gzip: >du -sh /usr/share/man/man? >17M /usr/share/man/man1 >2.5M /usr/share/man/man2 >40M /usr/share/man/man3 >640K /usr/share/man/man4 >2.2M /usr/share/man/man5 >16K /usr/share/man/man6 >1016K /usr/share/man/man7 >4.2M /usr/share/man/man8 >8.0K /usr/share/man/man9 >684K /usr/share/man/mann >Total 82M > >Using bzip2: >du -sh /usr/share/man/man? >16M /usr/share/man/man1 >2.5M /usr/share/man/man2 >40M /usr/share/man/man3 >588K /usr/share/man/man4 >2.1M /usr/share/man/man5 >16K /usr/share/man/man6 >976K /usr/share/man/man7 >4.2M /usr/share/man/man8 >8.0K /usr/share/man/man9 >680K /usr/share/man/mann >Total 81M > >One thing that skews the results is that some files were not compressed with >bzip2 because they were symlinked. > > Calculating sizes may seem useful, but you're honking the wrong horn imho, if, for nother reason, with both payload *AND* man page compression settable, it really makes no difference counting man pages and summing sizes. What is really needed is to change package transport, not diddle with package guts, to use rsync like, rather than raw http transport. For starters, all the mirroring of distros is rather simple minded atm. So a new package is added. rsync is fired up, and the remote site does not have that path. What does rsync do? Copies the entire file. Each additional rsync invoccation verifies that, indeed, the client and server have identical content. Well, duh. There is a fuzzy patch to rsync that matches on path, looking at suffix like .rpm first, then choosing closest similar path as refence on remote. That patch (with whatever sanity hardening necessary to map the functionality to *only* rpm packages is needed, as the fuzzy patch is perhaps too risky as is) needs to be wired into the rsync package. Then -- since rsync is known to be sub-optimal with compressed payloads -- Rusty Russel's gzip.rsync.patch2 needs to be added to rpm. That patch was in rpm-4.0.4, but alas, got blown out of rpm sources by the zlib double free errata fire drill several years ago. The patch is now (again) in rpm-4.4.1 and later. There are quite promising hints of bandwidth savings (for apt, dunno rpm yet) https://svn.uhulinux.hu/packages/dev/zlib/patches/02-rsync.patch Explicit objective metrics of bandwidth savings for mirrors if both package payload end-points include Rusty Russell's voo-doo will only help stimulate development of better client transport protocols. Or keep honking man pages in comnpressed with either bzip2 or gzip if that floats your boat. 73 de Jeff From johnp at redhat.com Wed Feb 2 21:02:31 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 02 Feb 2005 16:02:31 -0500 Subject: system-config-printer In-Reply-To: <20050201121139.GR5322@redhat.com> References: <20050201121139.GR5322@redhat.com> Message-ID: <1107378151.1125.79.camel@remedyz.boston.redhat.com> Overview on how desktop printer configuration currently works: 1. Printer is plugged in 2. HAL is notified and calls the printer-update.hal shell script in /etc/hal/capability.d/ 3. hal_lpadmin from the hal_cups_utils package is called with the printer's udi (what HAL uses to identify devices). 4. hal_lpadmin checks to see if the device is a printer and if so gets the make and model of the device from HAL 5. A command is constructed to execute printconf's match-driver command 6. If a match is found we - construct printconf's add-local command to add the printer - execute printconf-backend --force-rebuild to output the cups configuration files - send a HUP signal to cups to reload its data 7. If a match is not found we - Ask the console user's session through eggcups if they have a driver match for the make and model in gconf - if no we then prompt the user to select the closest make and model that matches their printer and is in our foomatic database - The user selects a make an model which is then entered into gconf and a message is sent to cups-config-daemon which executes step 6 with the selected make and model - if yes we get the make and model returned by gconf and go back to step 6 * On session startup eggcups will loop through the list of printers in gconf and configure them if they exist in HAL What printconf does (I have limited knowledge of how printconf works so can you correct me here Tim?): * printconf's match-driver command will return the name of the driver given a make and model of a printer - if a driver is found go to step 6 above * printconf's add-local command sets up a local print queue in the sysconfig database using the make and model of the printer. * printconf-backend --force-rebuild outputs the queues it finds in the sysconf database into cups config files. - the make and model are looked up in foomatic - a PPD file is written out based on the config info in foomatic - printers.conf is updated with the new queue info - the queue is created in /var/spool/cups * The HUP signal to cups tells it to reload its config files and pick up the new printers That is the basics. A lot of the desktop configuration can be simplified by putting functionality into the backend. I will post a list of features and designs I would like to see go into a rewritten system-config-printer soon. On Tue, 2005-02-01 at 12:11 +0000, Tim Waugh wrote: > The tool we provide for configuring printers needs to change. > > The one we have works as designed, but unfortunately the design was > that: > > * print queue configuration is stored in an XML file > > * a front-end interface allows the user to manipulate the XML file > > * a back-end program, which runs at spooler start-up time, writes out > spooler-specific configuration based on the XML file > > There are several bad consequences of this: > > * the XML file format was and is inflexible > > * the configuration options are limited to those common to both > spoolers we were shipping at the time the XML format was decided > > * it is VERY SLOW: you can't *modify* configuration, only write out > entirely new configurations (i.e. trigger the back-end) > > * again, due to the XML format chosen, we are tied to the foomatic > database in such as way that we absolutely require foomatic to know > about the printer before we can configure it. > > Even if you have the manufacturer's PPD file, there is very little > you can do to get your printer working. > > * changes made using the CUPS configuration interface > (http://localhost:631/), or any other method external to > system-config-printer, are not reflected in the XML file and so > cannot be modified. > > * changes made using system-config-printer cannot be modified using > other tools, since changes will be overwritten. > > and so on. > > Does anyone have ideas for how system-config-printer should be > re-written? > > Thanks, > Tim. > */ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From n3npq at nc.rr.com Wed Feb 2 21:24:50 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 16:24:50 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42014522.3040409@nc.rr.com> Nils Philippsen wrote: >On Wed, 2005-02-02 at 15:13 +0100, Florian La Roche wrote: > > >>>Then the question is: why is the same changelog, i.e. the changelog of >>>sub packages with the same source package, stored for each package >>>individually? It could be stored once and be referenced from each sub >>>package. It gets deleted once all references on it vanish. >>> >>> >>People might be able to install only one of the sub-packages. >> >> > >Um, I expressed myself not clearly. Of course the package files all >contain the changelog, the normalization would only happen on the RPM DB >level. > Which cannot happen, because immutable header regions contain changelogs, and the blob is signature and/or digest verified. 73 de Jeff From nphilipp at redhat.com Wed Feb 2 21:57:32 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Feb 2005 22:57:32 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <42014522.3040409@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> Message-ID: <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> On Wed, 2005-02-02 at 16:24 -0500, Jeff Johnson wrote: > Nils Philippsen wrote: > > >On Wed, 2005-02-02 at 15:13 +0100, Florian La Roche wrote: > > > > > >>>Then the question is: why is the same changelog, i.e. the changelog of > >>>sub packages with the same source package, stored for each package > >>>individually? It could be stored once and be referenced from each sub > >>>package. It gets deleted once all references on it vanish. > >>> > >>> > >>People might be able to install only one of the sub-packages. > >> > >> > > > >Um, I expressed myself not clearly. Of course the package files all > >contain the changelog, the normalization would only happen on the RPM DB > >level. > > > > Which cannot happen, because immutable header regions contain changelogs, > and the blob is signature and/or digest verified. I'm fully aware of that this would need serious work and likely incompatible changes to the RPM DB. You can easily reconstruct that single blob as it is now from a split header + changelog and verify the resulting blob against the signature/digest. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From n3npq at nc.rr.com Wed Feb 2 22:07:23 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 17:07:23 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42014F1B.9090809@nc.rr.com> Nils Philippsen wrote: >On Wed, 2005-02-02 at 16:24 -0500, Jeff Johnson wrote: > > >>Nils Philippsen wrote: >> >> >> >>>On Wed, 2005-02-02 at 15:13 +0100, Florian La Roche wrote: >>> >>> >>> >>> >>>>>Then the question is: why is the same changelog, i.e. the changelog of >>>>>sub packages with the same source package, stored for each package >>>>>individually? It could be stored once and be referenced from each sub >>>>>package. It gets deleted once all references on it vanish. >>>>> >>>>> >>>>> >>>>> >>>>People might be able to install only one of the sub-packages. >>>> >>>> >>>> >>>> >>>Um, I expressed myself not clearly. Of course the package files all >>>contain the changelog, the normalization would only happen on the RPM DB >>>level. >>> >>> >>> >>Which cannot happen, because immutable header regions contain changelogs, >>and the blob is signature and/or digest verified. >> >> > >I'm fully aware of that this would need serious work and likely >incompatible changes to the RPM DB. You can easily reconstruct that >single blob as it is now from a split header + changelog and verify the >resulting blob against the signature/digest. > > You cannot reconstruct from missing information at all. Splitting information between package header and Something Else Instead is a rather awkward verify to develop trust in. Adding changelogs outside of packages is what was suggested, and removing or at least truncating, changelogs too. Either is trivially done, and requires zero changes to existing rpm or rpmdb. Or add changelogs to specspo, as that has been needed quite some time now, so that developers can describe changes in their native language. Only your blind expectation that packages contain changelogs forevermore is is preventing you from seeing the simplicity of it all imho. But, presumably, you are fully aware of that too. RFE in bugzilla to start getting your changes to RPMDB to normalize changelogs on installed client machines properly prioritized please., 73 de Jeff From twaugh at redhat.com Wed Feb 2 22:14:14 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 2 Feb 2005 22:14:14 +0000 Subject: system-config-printer In-Reply-To: <1107378151.1125.79.camel@remedyz.boston.redhat.com> References: <20050201121139.GR5322@redhat.com> <1107378151.1125.79.camel@remedyz.boston.redhat.com> Message-ID: <20050202221414.GB10885@redhat.com> On Wed, Feb 02, 2005 at 04:02:31PM -0500, John (J5) Palmieri wrote: > What printconf does (I have limited knowledge of how printconf works so > can you correct me here Tim?): No corrections needed. That's a good description of the current system. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jbarnes at sgi.com Wed Feb 2 23:13:49 2005 From: jbarnes at sgi.com (Jesse Barnes) Date: Wed, 2 Feb 2005 15:13:49 -0800 Subject: FC for ia64? Message-ID: <200502021513.49232.jbarnes@sgi.com> What would it take to make ia64 support in Fedora bit more official? I.e. part of core releases, part of the Extras build process, etc. I might be interested in taking it on if it's not something huge... FWIW, I've been using it pretty regularly on an Altix 350 I have here and it's working pretty well for the most part (at least as well as it does on my PowerBook). Thanks, Jesse From davej at redhat.com Wed Feb 2 23:33:04 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 2 Feb 2005 18:33:04 -0500 Subject: FC for ia64? In-Reply-To: <200502021513.49232.jbarnes@sgi.com> References: <200502021513.49232.jbarnes@sgi.com> Message-ID: <20050202233304.GB25074@redhat.com> On Wed, Feb 02, 2005 at 03:13:49PM -0800, Jesse Barnes wrote: > What would it take to make ia64 support in Fedora bit more official? I.e. > part of core releases, part of the Extras build process, etc. I might be > interested in taking it on if it's not something huge... The devel tree at least gets stuff built for IA64, along with a daily boot.iso. As for making it a tier1 release like x86 & co, I'm not convinced there's critical mass to justify it. Seriously, I've seen more people file s390 bugs than ia64 bugs for the Fedora kernel packages. Dave From pozsy at uhulinux.hu Thu Feb 3 00:00:26 2005 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Thu, 3 Feb 2005 01:00:26 +0100 Subject: Change to bzip2? In-Reply-To: <20050202140325.73643.qmail@web50610.mail.yahoo.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> Message-ID: <20050203000025.GA12428@unicorn.sch.bme.hu> On Wed, Feb 02, 2005 at 06:03:24AM -0800, Steve G wrote: > Hi, > > With the discussion about trimming specfile changelogs to save space and improve > downloads...why not go one step further? Mandrake has been using bzip2 for a > while and it works just as well and files are significantly smaller. The > conversion could be done in several steps: > > 1) man pages - less already handles bzipped man pages > 2) info pages - I submited patch in bz #128637 to try to get it working > 3) tar > 4) rpms - I'm sure the patch is in Mandrake's version If the rpm contains compressed man pages/info pages/whatever overall compression ratio (package size) will be _worse_. Nothing should be compressed _inside_ the rpm. -- pozsy From jbarnes at sgi.com Wed Feb 2 23:49:53 2005 From: jbarnes at sgi.com (Jesse Barnes) Date: Wed, 2 Feb 2005 15:49:53 -0800 Subject: FC for ia64? In-Reply-To: <20050202233304.GB25074@redhat.com> References: <200502021513.49232.jbarnes@sgi.com> <20050202233304.GB25074@redhat.com> Message-ID: <200502021549.53622.jbarnes@sgi.com> On Wednesday, February 2, 2005 3:33 pm, Dave Jones wrote: > On Wed, Feb 02, 2005 at 03:13:49PM -0800, Jesse Barnes wrote: > > What would it take to make ia64 support in Fedora bit more official? > > I.e. part of core releases, part of the Extras build process, etc. I > > might be interested in taking it on if it's not something huge... > > The devel tree at least gets stuff built for IA64, along with > a daily boot.iso. As for making it a tier1 release like x86 & co, > I'm not convinced there's critical mass to justify it. Yeah, but unfortunately the boot.iso is often broken (it is now). > Seriously, I've seen more people file s390 bugs > than ia64 bugs for the Fedora kernel packages. Well, that's one reason I asked. If no one wants it but me, then it's probably not worth it if there's a ton of work involved. Thanks, Jesse From pri.rhl3 at iadonisi.to Thu Feb 3 00:48:54 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Wed, 02 Feb 2005 19:48:54 -0500 Subject: FC for ia64? In-Reply-To: <20050202233304.GB25074@redhat.com> References: <200502021513.49232.jbarnes@sgi.com> <20050202233304.GB25074@redhat.com> Message-ID: <1107391734.12314.12.camel@md.local.linuxlobbyist.org> On Wed, 2005-02-02 at 18:33 -0500, Dave Jones wrote: [snip] > Seriously, I've seen more people file s390 bugs > than ia64 bugs for the Fedora kernel packages. Sheesh, seriously?! Now that's really sad. That probably explains at least *some* of the reason for HP stepping out of the partnership with Intel. We just got two loaner rx1600's in a week ago and I managed to get Whitebox Enterprise Linux (ported to ia64 and referenced on the Gelato website -- http://www.gelato.org/). While it's a funky platform (stupidly putting the so-called Extended Firmware Interface or EFI on *disk* making diskless systems an effort, if not impossible -- though it could be just my lack of experience with the platform), they're not that bad. It's definitely zippy for a dual 1GHz box, if not exorbitantly expensive. What was the reason for ditching Alpha again? Oh, well. I'm happy with my FC3 on my new dual Opteron 250 and happy that it's now a tier 1 platform. I'd be happy to be a beta tester for FC on ia64 if Jesse can get SGI to donate an Altix to me. ;-) -- -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 symbiont at berlios.de Thu Feb 3 00:49:12 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 3 Feb 2005 08:49:12 +0800 Subject: ntpd startup too early + hangs In-Reply-To: <20050202185034.GA22480@thacker.dyndns.org> References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> Message-ID: <200502030849.12524.symbiont@berlios.de> On Thursday 03 February 2005 02:50, John Thacker wrote: > On Thu, Feb 03, 2005 at 02:02:24AM +0800, Jeff Pitman wrote: > > Crazy idea: shut off all the daemons that need network (from normal > > init processing) and then only spawn them when appropriate from > > NetworkManager. > > Definitely crazy until NetworkManager can actually handle all > connections. For example, right now it can't handle any machine with > multiple active connections, which includes machines that do > connection sharing. (Among other things, it doesn't believe that you > would have a static IP with no default gateway.) And, it needs to handle virtuals: OpenVPN, VmWare, vpnc, etc. etc. -- -jeff From 777tahder at schlaegel.com Thu Feb 3 03:53:25 2005 From: 777tahder at schlaegel.com (Schlaegel) Date: Wed, 02 Feb 2005 19:53:25 -0800 Subject: radical suggestion for fc4 release In-Reply-To: <1107286612.25100.123.camel@cutter> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> <20050131230157.GE29819@rogers.com> <20050201114014.3ecf1eba.fedora@wir-sind-cool.org> <1107256407.5389.330.camel@mccallum.corsepiu.local> <1107284544.21078.31.camel@rousalka.dyndns.org> <1107284829.25100.109.camel@cutter> <1107284985.21078.40.camel@rousalka.dyndns.org> <1107285253.25100.111.camel@cutter> <1107286274.21078.56.camel@rousalka.dyndns.org> <1107286612.25100.123.camel@cutter> Message-ID: <4201A035.3010606@schlaegel.com> seth vidal wrote: >Which part of the users would this be? The people using fedora in >'mission critical environments'? I coulda sworn there was something >about fedora core not be intended for those environments on the front >page. > >Maybe I'm mistaken - but why are we planning and making adjustments for >folks that the distro is EXPLICITLY not intended for? > >-sv > > I agree. Fedora should follow its purposes. RPM Changelogs are important and should be supported for supported Fedora, maybe even the most recent entry into Fedora Legacy. Anyone upgrading from an ancient release expects to do a bit more research than `rpm -qi --changelog package`. Extremely historic Changelogs are a nuisance that just add noise to the important information-- what has changed since the last RPM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aoliva at redhat.com Thu Feb 3 03:54:47 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 03 Feb 2005 01:54:47 -0200 Subject: Change to bzip2? In-Reply-To: <4200FDBA.5080107@nc.rr.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> <4200FDBA.5080107@nc.rr.com> Message-ID: On Feb 2, 2005, Jeff Johnson wrote: > And it also makes little sense to bzip tarballs that end up in gzipped > payloads imho. It sure does. Already-compressed payload doesn't get further compressed. A bzip2ed file will still take less space than a gzip2ed one if you make it part of gzipped payload. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From n3npq at nc.rr.com Wed Feb 2 19:37:07 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 02 Feb 2005 14:37:07 -0500 Subject: XML RPM Header In-Reply-To: <1107368249.6844.13.camel@localhost.localdomain> References: <20050202171020.20766.qmail@web50601.mail.yahoo.com> <42010D28.2040400@nc.rr.com> <1107368249.6844.13.camel@localhost.localdomain> Message-ID: <42012BE3.9040303@nc.rr.com> Jeffrey C. Ollie wrote: >On Wed, 2005-02-02 at 12:26 -0500, Jeff Johnson wrote: > > >>Headers are gonna change in rpm-4.4.2 to permit use of xml to represent >>header content, and there's four or five other flaws that need addressing >>at the same time (like permitting an array of binary elements, and adding >>an ASN.1 like type to ease tertirary lookup of data embedded in tags >>(think: signature/pubkey fingerprints.) >> >> > >Since the RPM headers are going to be in XML, what about using XML >Signatures? > > Short answer: No way Jose. The longer answer can only be shared with someone who has actually attempted an OpenPGP implementation from scratch. Words escape me ... 73 de Jeff From nphilipp at redhat.com Thu Feb 3 08:49:24 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 03 Feb 2005 09:49:24 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <42014F1B.9090809@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> Message-ID: <1107420564.25624.19.camel@wombat.tiptoe.de> On Wed, 2005-02-02 at 17:07 -0500, Jeff Johnson wrote: > Nils Philippsen wrote: [...] > >I'm fully aware of that this would need serious work and likely > >incompatible changes to the RPM DB. You can easily reconstruct that > >single blob as it is now from a split header + changelog and verify the > >resulting blob against the signature/digest. Apologies for not labeling my posts "theoretical musings about how changelogs could be made less redundant in the DB". > You cannot reconstruct from missing information at all. If the header is now (everything else + changelog) and changelog gets split out I don't see how there is any missing information -- you just grab "everything else" and the changelog and have your blob again. > Splitting information between package header and Something Else Instead > is a rather awkward verify to develop trust in. If it were done (note the use of the subjunctive, theoretical discussion and all that) it would obviously have to be a two-way unique mapping from single blob to header plus split out redundant data (let's not talk about the changelog, as this only distracts) and vice versa. > Adding changelogs outside of packages is what was suggested, and removing > or at least truncating, changelogs too. Either is trivially done, and > requires zero changes to existing rpm or rpmdb. Agreed, but I guess the opinions on whether this is desirable or not differ quite dramatically. On the one hand there's the "remove unneeded cruft" argument and on the other the "I might need just that bit of info when I'm cut off the net". I guess we won't bring these two together unless there is an easy way to take the changelogs with you when doing an "offline" job and to easily get the right changelog for the packages taken with you, i.e. verification that this changelog belongs to that package would also need to be thought about. > Or add changelogs to specspo, as that has been needed quite some time > now, so that developers can describe changes in their native language. Hmm. If you have one isolated developer, then yes. But if you have multiple people working on one package, it will (sensibly) lead to the common denominator being used (which is English) as it is done with string to be translated in applications. > Only your blind expectation that packages contain changelogs forevermore is > is preventing you from seeing the simplicity of it all imho. As outlined above, your simplicity for rpm and rpmdb is bought by complication elsewhere. Not that that'd necessarily be a bad thing ;-). > But, presumably, you are fully aware of that too. RFE in bugzilla to start > getting your changes to RPMDB to normalize changelogs on installed client > machines properly prioritized please., Hey, don't take it personal, it's only a theoretical discussion from my side, which I should have said before. Sorry. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Thu Feb 3 08:49:24 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 03 Feb 2005 09:49:24 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <42014F1B.9090809@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> Message-ID: <1107420564.25624.19.camel@wombat.tiptoe.de> On Wed, 2005-02-02 at 17:07 -0500, Jeff Johnson wrote: > Nils Philippsen wrote: [...] > >I'm fully aware of that this would need serious work and likely > >incompatible changes to the RPM DB. You can easily reconstruct that > >single blob as it is now from a split header + changelog and verify the > >resulting blob against the signature/digest. Apologies for not labeling my posts "theoretical musings about how changelogs could be made less redundant in the DB". > You cannot reconstruct from missing information at all. If the header is now (everything else + changelog) and changelog gets split out I don't see how there is any missing information -- you just grab "everything else" and the changelog and have your blob again. > Splitting information between package header and Something Else Instead > is a rather awkward verify to develop trust in. If it were done (note the use of the subjunctive, theoretical discussion and all that) it would obviously have to be a two-way unique mapping from single blob to header plus split out redundant data (let's not talk about the changelog, as this only distracts) and vice versa. > Adding changelogs outside of packages is what was suggested, and removing > or at least truncating, changelogs too. Either is trivially done, and > requires zero changes to existing rpm or rpmdb. Agreed, but I guess the opinions on whether this is desirable or not differ quite dramatically. On the one hand there's the "remove unneeded cruft" argument and on the other the "I might need just that bit of info when I'm cut off the net". I guess we won't bring these two together unless there is an easy way to take the changelogs with you when doing an "offline" job and to easily get the right changelog for the packages taken with you, i.e. verification that this changelog belongs to that package would also need to be thought about. > Or add changelogs to specspo, as that has been needed quite some time > now, so that developers can describe changes in their native language. Hmm. If you have one isolated developer, then yes. But if you have multiple people working on one package, it will (sensibly) lead to the common denominator being used (which is English) as it is done with string to be translated in applications. > Only your blind expectation that packages contain changelogs forevermore is > is preventing you from seeing the simplicity of it all imho. As outlined above, your simplicity for rpm and rpmdb is bought by complication elsewhere. Not that that'd necessarily be a bad thing ;-). > But, presumably, you are fully aware of that too. RFE in bugzilla to start > getting your changes to RPMDB to normalize changelogs on installed client > machines properly prioritized please., Hey, don't take it personal, it's only a theoretical discussion from my side, which I should have said before. Sorry. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From hk at isphuset.no Thu Feb 3 09:16:49 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 03 Feb 2005 10:16:49 +0100 Subject: Change to bzip2? In-Reply-To: <4201095D.4020208@redhat.com> References: <20050202140325.73643.qmail@web50610.mail.yahoo.com> <20050202144550.GA6317@dudweiler.stuttgart.redhat.com> <1107360004.22153.18.camel@obelix.redhat.usu> <4200FDBA.5080107@nc.rr.com> <1107362231.14003.5.camel@tuxpaq> <4201095D.4020208@redhat.com> Message-ID: <1107422208.28996.5.camel@linux.local> On Wed, 2005-02-02 at 18:09, Phil Knirsch wrote: *snip* > For binary rpms otoh it's different as there you want a quick > installation, so uncompression speed does matter there, and the > difference for the binary payload compress with bzip2 and gzip should be > considerably less drastic than with source tarballs. *snip* > So the speed difference in unpacking is about 1:10, size difference is > about 1.12:1 which clearly demonstrates my point. I don't want my > installation to take 10 times longer for the sake of 12% space saving in > the binary rpms. *snip* In the last company I worked for, we rolled our own distro. Admittedly it did not use rpms, we just used tar files and extracted them into the right places during install. Now, difference between gzip -9 and bzip2 -9 was quite surprising. We had expected bzip2 to be slower to install but a big win in space. Actually it turned out that our iso went down from about 350MB to 200MB, and installtimes went from 7min to 5min (approx). We reallised that the install was not really cpu bound, but it was heavily cdrom-io bound. I don't have exact numbers since I dont work there anymore.. And that was my 2 cents. -HK From harald at redhat.com Thu Feb 3 10:08:26 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 03 Feb 2005 11:08:26 +0100 Subject: ntpd startup too early + hangs In-Reply-To: <200502030849.12524.symbiont@berlios.de> References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> <200502030849.12524.symbiont@berlios.de> Message-ID: <4201F81A.3080006@redhat.com> Jeff Pitman wrote: > On Thursday 03 February 2005 02:50, John Thacker wrote: > >>On Thu, Feb 03, 2005 at 02:02:24AM +0800, Jeff Pitman wrote: >> >>>Crazy idea: shut off all the daemons that need network (from normal >>>init processing) and then only spawn them when appropriate from >>>NetworkManager. >> >>Definitely crazy until NetworkManager can actually handle all >>connections. For example, right now it can't handle any machine with >>multiple active connections, which includes machines that do >>connection sharing. (Among other things, it doesn't believe that you >>would have a static IP with no default gateway.) > > > And, it needs to handle virtuals: OpenVPN, VmWare, vpnc, etc. etc. > Definetly a job for DBUS messaging... How about a general stub for (re-)starting all kinds of daemons, which listens on DBUS for a specific signal/message? NetworkManager and /etc/init.d/network could provide this message, after the network is up. From buildsys at redhat.com Thu Feb 3 13:02:23 2005 From: buildsys at redhat.com (Build System) Date: Thu, 3 Feb 2005 08:02:23 -0500 Subject: rawhide report: 20050203 changes Message-ID: <200502031302.j13D2N407479@porkchop.devel.redhat.com> From selinux at gmail.com Thu Feb 3 13:12:01 2005 From: selinux at gmail.com (Tom London) Date: Thu, 3 Feb 2005 05:12:01 -0800 Subject: rawhide report: 20050203 changes In-Reply-To: <200502031302.j13D2N407479@porkchop.devel.redhat.com> References: <200502031302.j13D2N407479@porkchop.devel.redhat.com> Message-ID: <4c4ba15305020305121df942c2@mail.gmail.com> more stealth packages? Any chance getting this fixed? From n3npq at nc.rr.com Thu Feb 3 13:19:49 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 03 Feb 2005 08:19:49 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107420564.25624.19.camel@wombat.tiptoe.de> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> <1107420564.25624.19.camel@wombat.tiptoe.de> Message-ID: <420224F5.3010602@nc.rr.com> Nils Philippsen wrote: >On Wed, 2005-02-02 at 17:07 -0500, Jeff Johnson wrote: > > >Hey, don't take it personal, it's only a theoretical discussion from my >side, which I should have said before. Sorry. > > NP. What needs to be done is to change rpmbuild, not rpm or thr rpmdb, to truncate changelogs at a certain point in time. That way you can have all changelogs in the spec file (so no mass *.spec churn needs to happen) and fewer changelogs in packages (which would be smaller). Normalization is trivial possible if changelogs were saved as keys, rather than values, as normalization automagically happens with keys. That can be easily done through configuration, adding "Changelogs" one place and doing --rebuilddb. Alas that normalizes, but saves no space, as headers still contain the original content. That is actually a feature, not a flaw, imho, because the indices can always be reconstructed by doing --rebuilddb at any time, the redundancy is more useful than whatever amount of space is saved. Historically, rpm used to have a a parameter that truncated changelogs at N when installing packages. That was a perfectly sensible optimization when disk space was less cheap, until header immutable regions came along. Whether changelogs should be part of an immutable region or not is an open question too. It is (and was) certainly possible to define a header immutable region without including changelogs content, which would permit truncation or other forms of normalization, editing header content while installing. I chose to put *all* tags into a header immutable region so that I would not have to have the discussion about which tags go where. For example, the content in changelogs, if not hardened by digest and/or signature, might be part of a socially engineered exploit to disguise a maliciously modified package. It's very hard not believe what you read. 73 de Jeff From pknirsch at redhat.com Thu Feb 3 13:27:48 2005 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 03 Feb 2005 14:27:48 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <420224F5.3010602@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> <1107420564.25624.19.camel@wombat.tiptoe.de> <420224F5.3010602@nc.rr.com> Message-ID: <420226D4.6040103@redhat.com> Jeff Johnson wrote: > > For example, the content in changelogs, if not hardened by digest and/or > signature, > might be part of a socially engineered exploit to disguise a maliciously > modified > package. It's very hard not believe what you read. > /subliminal messages on RPM IS GOOD FOR YOU, RPM IS GOOD FOR YOU, RPM IS GOOD FOR YOU... /subliminal messages off Sorry, couldn't resist. ;) Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From rms at 1407.org Thu Feb 3 14:05:21 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 03 Feb 2005 14:05:21 +0000 Subject: rawhide report: 20050203 changes In-Reply-To: <4c4ba15305020305121df942c2@mail.gmail.com> References: <200502031302.j13D2N407479@porkchop.devel.redhat.com> <4c4ba15305020305121df942c2@mail.gmail.com> Message-ID: <1107439522.3689.27.camel@roque> On Thu, 2005-02-03 at 05:12 -0800, Tom London wrote: > more stealth packages? > > Any chance getting this fixed? I think this happens because the repo is broken (ie, there are missing dependencies). 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 thomasz at hostmaster.org Thu Feb 3 14:11:02 2005 From: thomasz at hostmaster.org (Thomas Zehetbauer) Date: Thu, 03 Feb 2005 15:11:02 +0100 Subject: FC for ia64? In-Reply-To: <200502021513.49232.jbarnes@sgi.com> References: <200502021513.49232.jbarnes@sgi.com> Message-ID: <1107439862.4458.0.camel@hostmaster.org> Face the truth: IA64 is dead, more than dead, don't beat a dead horse! Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger thomasz at hostmaster.org for key The horizon of many people is a circle with a radius of zero. They call this their point of view. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part URL: From shiva at sewingwitch.com Thu Feb 3 14:26:30 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 03 Feb 2005 06:26:30 -0800 Subject: No announcement for kernel-2.6.10-1.12_FC2 Message-ID: <0F6DD42A2AF8186EEF93CE36@[10.0.0.4]> Saw this in my nightly "yum check-update" run. So what's new with this? (There's also a new squid in the repository with no announcement for it.) From linux_4ever at yahoo.com Thu Feb 3 14:29:29 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 3 Feb 2005 06:29:29 -0800 (PST) Subject: Change to bzip2? In-Reply-To: <42013F70.4030601@nc.rr.com> Message-ID: <20050203142929.55605.qmail@web50609.mail.yahoo.com> >What is really needed is to change package transport, not diddle with >package guts, to use rsync like, rather than raw http transport. I think you will always need to support http or ftp because of corporate firewalling rules. Therefore, decreasing the rpm file size needs to be considered. Mandrake srpms are almost always smaller than RH. That really helps downloading. And I'm sure that helps take the load off the servers, too. -Steve Grubb __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From jspaleta at gmail.com Thu Feb 3 14:36:17 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 3 Feb 2005 09:36:17 -0500 Subject: No announcement for kernel-2.6.10-1.12_FC2 In-Reply-To: <0F6DD42A2AF8186EEF93CE36@10.0.0.4> References: <0F6DD42A2AF8186EEF93CE36@10.0.0.4> Message-ID: <604aa79105020306366bb4eb37@mail.gmail.com> On Thu, 03 Feb 2005 06:26:30 -0800, Kenneth Porter wrote: > Saw this in my nightly "yum check-update" run. So what's new with this? > (There's also a new squid in the repository with no announcement for it.) While an important issue, discussion about released updates for fc2 and fc3 is generally off topic for this list. For missing annoucements your best course of action is to file a bug report in bugzilla to make the specific developer aware. -jef From n3npq at nc.rr.com Thu Feb 3 14:51:18 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 03 Feb 2005 09:51:18 -0500 Subject: Change to bzip2? In-Reply-To: <20050203142929.55605.qmail@web50609.mail.yahoo.com> References: <20050203142929.55605.qmail@web50609.mail.yahoo.com> Message-ID: <42023A66.5010001@nc.rr.com> Steve G wrote: >>What is really needed is to change package transport, not diddle with >>package guts, to use rsync like, rather than raw http transport. >> >> > >I think you will always need to support http or ftp because of corporate >firewalling rules. Therefore, decreasing the rpm file size needs to be >considered. Mandrake srpms are almost always smaller than RH. That really helps >downloading. And I'm sure that helps take the load off the servers, too. > > Yep, http fer sure, ftp doesn't even begin to be useful. So diddle with package guts if that floats your boat. I'm all in favor of lightly loaded servers, and I'm very happy that MDK packages are smaller than Red Hat's. Hint: rsync deltas using rdiff from librsync are easily transported across http. 73 de Jeff From walters at redhat.com Thu Feb 3 15:25:12 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 03 Feb 2005 10:25:12 -0500 Subject: ntpd startup too early + hangs In-Reply-To: <4201F81A.3080006@redhat.com> References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> <200502030849.12524.symbiont@berlios.de> <4201F81A.3080006@redhat.com> Message-ID: <1107444312.4458.7.camel@nexus.verbum.private> On Thu, 2005-02-03 at 11:08 +0100, Harald Hoyer wrote: > Jeff Pitman wrote: > > On Thursday 03 February 2005 02:50, John Thacker wrote: > > > >>On Thu, Feb 03, 2005 at 02:02:24AM +0800, Jeff Pitman wrote: > >> > >>>Crazy idea: shut off all the daemons that need network (from normal > >>>init processing) and then only spawn them when appropriate from > >>>NetworkManager. > >> > >>Definitely crazy until NetworkManager can actually handle all > >>connections. For example, right now it can't handle any machine with > >>multiple active connections, which includes machines that do > >>connection sharing. (Among other things, it doesn't believe that you > >>would have a static IP with no default gateway.) > > > > > > And, it needs to handle virtuals: OpenVPN, VmWare, vpnc, etc. etc. > > > > Definetly a job for DBUS messaging... How about a general stub for > (re-)starting all kinds of daemons, which listens on DBUS for a specific > signal/message? NetworkManager and /etc/init.d/network could provide this > message, after the network is up. Seth's thoughts on SystemServices are good: http://www.gnome.org/~seth/blog/2003/Sep/27 The Python part is irrelevant here; what's important is the idea of a "services manager" process which knows about service dependencies and when to restart them. So in this situation, NetworkManager wouldn't tell ntpd to start directly; instead, NetworkManager would tell ServiceManager that the "org.freedesktop.NetworkManager.Link" dependency was available. ServiceManager would then recheck its list of pending activations and start all services that were now runnable with this dependency. Likewise, when a dependency goes away, ServiceManager stops all services with that dependency. So dependencies can either be other services or they can be sub-components of a service, like "Link". From fedora-devel at camperquake.de Thu Feb 3 15:58:06 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 3 Feb 2005 16:58:06 +0100 Subject: ntpd startup too early + hangs In-Reply-To: <1107444312.4458.7.camel@nexus.verbum.private>; from walters@redhat.com on Thu, Feb 03, 2005 at 10:25:12AM -0500 References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> <200502030849.12524.symbiont@berlios.de> <4201F81A.3080006@redhat.com> <1107444312.4458.7.camel@nexus.verbum.private> Message-ID: <20050203165806.A31611@ryoko.camperquake.de> On Thu, Feb 03, 2005 at 10:25:12AM -0500, Colin Walters wrote: > was available. ServiceManager would then recheck its list of pending > activations and start all services that were now runnable with this > dependency. Likewise, when a dependency goes away, ServiceManager stops > all services with that dependency. So dependencies can either be other > services or they can be sub-components of a service, like "Link". OK, since postfix was mentioned earlier as aservice which would need this (binding to interfaces): changing the postfix config from "listen only on localhost" (similar to what sendmail does in it's default config) to "listen on an external network interface" would change it's dependency: in the first case it does not care about external networks (localhost is always available), in the second case it does. How is this supposed to be managed? From shiva at sewingwitch.com Thu Feb 3 16:09:33 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 03 Feb 2005 08:09:33 -0800 Subject: ntpd startup too early + hangs In-Reply-To: <20050203165806.A31611@ryoko.camperquake.de> References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> <200502030849.12524.symbiont@berlios.de> <4201F81A.3080006@redhat.com> <1107444312.4458.7.camel@nexus.verbum.private> <20050203165806.A31611@ryoko.camperquake.de> Message-ID: --On Thursday, February 03, 2005 4:58 PM +0100 Ralf Ertzinger wrote: > OK, since postfix was mentioned earlier as aservice which would need this > (binding to interfaces): changing the postfix config from "listen only > on localhost" (similar to what sendmail does in it's default config) > to "listen on an external network interface" would change it's dependency: > in the first case it does not care about external networks (localhost is > always available), in the second case it does. > > How is this supposed to be managed? This is going to be true of a lot of system services that pre-date the hot-plug paradigm and don't respond dynamically to changing prerequisites. BIND has the same issue. My guess is that until those services become hot-plug-aware, they'll have to be restarted with different configurations for each possible environment. That's yet another reason a clean generic solution isn't possible to retrofit non-intrusively. From kyrre at solution-forge.net Thu Feb 3 16:09:59 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 03 Feb 2005 17:09:59 +0100 Subject: rawhide report: 20050203 changes In-Reply-To: <1107439522.3689.27.camel@roque> References: <200502031302.j13D2N407479@porkchop.devel.redhat.com> <4c4ba15305020305121df942c2@mail.gmail.com> <1107439522.3689.27.camel@roque> Message-ID: <1107446999.2636.2.camel@localhost.localdomain> tor, 03.02.2005 kl. 15.05 skrev Rui Miguel Seabra: > On Thu, 2005-02-03 at 05:12 -0800, Tom London wrote: > > more stealth packages? > > > > Any chance getting this fixed? > > I think this happens because the repo is broken (ie, there are missing > dependencies). > And then *thud* it gets fixed, and everything get sent in one gigantic chunk? What about having some sort of "broken deps" section at the bottom of the mail? From fedora-devel at camperquake.de Thu Feb 3 16:12:56 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 3 Feb 2005 17:12:56 +0100 Subject: rawhide report: 20050203 changes In-Reply-To: <1107446999.2636.2.camel@localhost.localdomain>; from kyrre@solution-forge.net on Thu, Feb 03, 2005 at 05:09:59PM +0100 References: <200502031302.j13D2N407479@porkchop.devel.redhat.com> <4c4ba15305020305121df942c2@mail.gmail.com> <1107439522.3689.27.camel@roque> <1107446999.2636.2.camel@localhost.localdomain> Message-ID: <20050203171256.B31611@ryoko.camperquake.de> On Thu, Feb 03, 2005 at 05:09:59PM +0100, Kyrre Ness Sjobak wrote: > And then *thud* it gets fixed, and everything get sent in one gigantic > chunk? Well, there are packages being built every day. Just the notifications are broken. From Brian.Edginton at ge.com Thu Feb 3 16:41:32 2005 From: Brian.Edginton at ge.com (Edginton, Brian (GE Healthcare)) Date: Thu, 3 Feb 2005 10:41:32 -0600 Subject: rawhide report: 20050203 changes Message-ID: <42BB180FA5BC094B8859720526D89B6602ABCB37@MKEMLVEM04.e2k.ad.ge.com> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of > Ralf Ertzinger > Sent: Thursday, February 03, 2005 9:13 AM > To: Development discussions related to Fedora Core > Subject: Re: rawhide report: 20050203 changes > > > On Thu, Feb 03, 2005 at 05:09:59PM +0100, Kyrre Ness Sjobak wrote: > > > And then *thud* it gets fixed, and everything get sent in > one gigantic > > chunk? > > Well, there are packages being built every day. Just the notifications > are broken. How about just making the tinderbox available for us to view? ;) -edge From remco at beryllium.net Thu Feb 3 16:42:01 2005 From: remco at beryllium.net (Remco Poelstra) Date: Thu, 03 Feb 2005 17:42:01 +0100 Subject: My ideas for a new printing system Message-ID: <42025459.4040507@beryllium.net> Hi, Let me first introduce myself, sine you people probably never heard about me :). I'm a student at the Eindhoven University of Technology. With a team of 4 students we are responsible for Linux support at the faculty of Electrical Engineering. Tim Waugh asked me to help thinking about a new printing solution, as a reply on a mail of me on the config list. I read the posts here about that subject and I would like to share my opinion on this matter: First I would like to state that there won't be any solution if CUPS doesn't improve. The problem that eggcups tries to adress (authentication) isn't solved if there is a chain of CUPS servers involved. If CUPS can't communicate back, then the user still can't authenticate. So CUPS should implement a 2-way IPP protocol. Then eggcups can be reduced to listening to HAL messages in order to display the print queue and pop up authentication dialogs. By not implementing a full CUPS server, it has less system resource usage, which is a good thing I think. Second if CUPS supports signed browse packets, than we have an 'easy' solution of identifying fake printers on a large network. For the configuration part: gnome-cups-manager does quite a nice job on this. Than we only need some decend tool to configure the server itself. Just my 2 cents, Remco Poelstra From walters at redhat.com Thu Feb 3 16:56:58 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 03 Feb 2005 11:56:58 -0500 Subject: ntpd startup too early + hangs In-Reply-To: <20050203165806.A31611@ryoko.camperquake.de> References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> <200502030849.12524.symbiont@berlios.de> <4201F81A.3080006@redhat.com> <1107444312.4458.7.camel@nexus.verbum.private> <20050203165806.A31611@ryoko.camperquake.de> Message-ID: <1107449818.4458.32.camel@nexus.verbum.private> On Thu, 2005-02-03 at 16:58 +0100, Ralf Ertzinger wrote: > On Thu, Feb 03, 2005 at 10:25:12AM -0500, Colin Walters wrote: > > > was available. ServiceManager would then recheck its list of pending > > activations and start all services that were now runnable with this > > dependency. Likewise, when a dependency goes away, ServiceManager stops > > all services with that dependency. So dependencies can either be other > > services or they can be sub-components of a service, like "Link". > > OK, since postfix was mentioned earlier as aservice which would need this > (binding to interfaces): changing the postfix config from "listen only > on localhost" (similar to what sendmail does in it's default config) > to "listen on an external network interface" would change it's dependency: > in the first case it does not care about external networks (localhost is > always available), in the second case it does. > > How is this supposed to be managed? Longer term, perhaps Postfix could be modified to provide two services, org.postfix.LocalMTA and org.postfix.MTA, and only org.postfix.MTA depends on org.freedesktop.NetworkManager.Link or whatever. From sopwith at redhat.com Thu Feb 3 17:04:52 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 3 Feb 2005 12:04:52 -0500 (EST) Subject: FUDCon registration Message-ID: Hiya peeps, The first ever Fedora Users and Developers Conference is happening on Feb. 18th in Boston. If you're on this mailing list, you're definitely invited! If you're going to be there, please make sure to register ASAP, because space is limited. Greg's spiffy press release and registration information is up at http://fedoraproject.org/fudcon/ Cheers, -- Elliot From nphilipp at redhat.com Thu Feb 3 17:16:00 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 03 Feb 2005 18:16:00 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <420224F5.3010602@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> <1107420564.25624.19.camel@wombat.tiptoe.de> <420224F5.3010602@nc.rr.com> Message-ID: <1107450960.11167.11.camel@wombat.tiptoe.de> On Thu, 2005-02-03 at 08:19 -0500, Jeff Johnson wrote: > Whether changelogs should be part of an immutable region or not is an open > question too. It is (and was) certainly possible to define a header > immutable region > without including changelogs content, which would permit truncation or other > forms of normalization, editing header content while installing. > > I chose to put *all* tags into a header immutable region so that I > would not have to have the discussion about which tags go where. > > For example, the content in changelogs, if not hardened by digest and/or > signature, > might be part of a socially engineered exploit to disguise a maliciously > modified > package. It's very hard not believe what you read. Well, I didn't propose anything of that sort (i.e. changelog outside of what is digested/signed) ;-). What I meant was that it is irrelevant whether you sign/digest an actually existing stream of bytes which contains the changelog or the result of a function which puts together this stream from changelog and the remainder of the header. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From n3npq at nc.rr.com Thu Feb 3 17:39:01 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 03 Feb 2005 12:39:01 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107450960.11167.11.camel@wombat.tiptoe.de> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> <1107420564.25624.19.camel@wombat.tiptoe.de> <420224F5.3010602@nc.rr.com> <1107450960.11167.11.camel@wombat.tiptoe.de> Message-ID: <420261B5.4010905@nc.rr.com> Nils Philippsen wrote: >On Thu, 2005-02-03 at 08:19 -0500, Jeff Johnson wrote: > > > >>Whether changelogs should be part of an immutable region or not is an open >>question too. It is (and was) certainly possible to define a header >>immutable region >>without including changelogs content, which would permit truncation or other >>forms of normalization, editing header content while installing. >> >>I chose to put *all* tags into a header immutable region so that I >>would not have to have the discussion about which tags go where. >> >>For example, the content in changelogs, if not hardened by digest and/or >>signature, >>might be part of a socially engineered exploit to disguise a maliciously >>modified >>package. It's very hard not believe what you read. >> >> > >Well, I didn't propose anything of that sort (i.e. changelog outside of >what is digested/signed) ;-). What I meant was that it is irrelevant >whether you sign/digest an actually existing stream of bytes which >contains the changelog or the result of a function which puts together >this stream from changelog and the remainder of the header. > > Yep, one can reassemble a header from components, and verify blobs. That was the context of my previous comments: you cannot reassemble a blob unless the components are actually present, and there almost certainly will be some way for separate changelogs to go AWOL preventing reassembly. Splitting changelogs out, but not changing how digest/signature are performed on headers, adds complexity and additional failure modes where there are none now, that are hard to "trust" for no perceivable gain to verifiability other than compatibility with the exsisting mechanism. Move changelogs out of headers, or truncate to acceptable length, is better imho. Or RFE an explicit mechanism for moving changelogs out of headers and normalizing content. 73 de Jeff From fedora-devel at camperquake.de Thu Feb 3 18:09:30 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 3 Feb 2005 19:09:30 +0100 Subject: ntpd startup too early + hangs In-Reply-To: <1107449818.4458.32.camel@nexus.verbum.private> References: <200502030202.25058.symbiont@berlios.de> <20050202185034.GA22480@thacker.dyndns.org> <200502030849.12524.symbiont@berlios.de> <4201F81A.3080006@redhat.com> <1107444312.4458.7.camel@nexus.verbum.private> <20050203165806.A31611@ryoko.camperquake.de> <1107449818.4458.32.camel@nexus.verbum.private> Message-ID: <20050203190930.41363bf4@nausicaa.camperquake.de> Hi. Colin Walters wrote: > Longer term, perhaps Postfix could be modified to provide two services, > org.postfix.LocalMTA and org.postfix.MTA, and only org.postfix.MTA > depends on org.freedesktop.NetworkManager.Link or whatever. On the other hand I might be confused about the kind of problem we are trying to solve here. Taking postfix as an example again. If the system has fixed IP addresses, there is no need to delay the start of the service. ifconfig the interfaces, start postfix, done. If the interface is actually up (in the sense of "has a link") does not matter. If the system has a dynamic IP (via DHCP or something like that), who would configure a listening daemon on this machine which does _not_ bind to 0.0.0.0? Since you do not know your future address, you can not enter it in the config. And (unless I am mistaken), binding to 0.0.0.0 catches interfaces which are brought up later, too. This leaves the last case: static addresses via DHCP. Similar to case 1, unless the DHCP server fails. Are we talking about case 3 here? Or am I missing something? -- "If you are patient in one moment of anger, you will escape one hundred days of sorrow." -- Chinese Proverb From kmaraas at broadpark.no Thu Feb 3 11:55:31 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Thu, 03 Feb 2005 12:55:31 +0100 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <20050202170603.A18968@ryoko.camperquake.de> References: <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <4200C011.30809@redhat.com> <4200F9F8.6080709@redhat.com> <20050202170603.A18968@ryoko.camperquake.de> Message-ID: <1107431731.4805.4.camel@localhost.localdomain> ons, 02,.02.2005 kl. 17.06 +0100, skrev Ralf Ertzinger: > On Wed, Feb 02, 2005 at 05:04:08PM +0100, Harald Hoyer wrote: > > > Ok, evil quickported nmapfe to gtk2. Maybe some gtk freak could look after it, > > so that it can compile without "-DGTK_ENABLE_BROKEN" (configure.ac) and > > runtime errors and warnings. > > Do we actually care about runtime warnings? There hardly seems to be a > gtk program that does not produce them. > We should, and filing bugs about them in bugzilla.gnome.org gets them fixed some times depending on the severity of the warning. If we're fixing compile time warnings, why shouldn't we be fixing run- time ones? Cheers Kjartan From sopwith at redhat.com Thu Feb 3 18:51:31 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 3 Feb 2005 13:51:31 -0500 (EST) Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <20050131222016.GA9816@thacker.dyndns.org> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> Message-ID: On Mon, 31 Jan 2005, John Thacker wrote: > On Mon, Jan 31, 2005 at 04:57:57PM -0500, Elliot Lee wrote: > > > Peter Robinson: > > > Can we also get rid / move to extras all the non > > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > > 1 cruft as well? > > > > Need specific package nominations. > > nmap-frontend is one. > gnucash we're waiting on the port to gtk2 gnucash is staying in core for now because the maintainer says so. :) (I assume this means that the gtk2 port is forthcoming.) nmap-frontend in rawhide uses gtk2, so no worries there. Thanks, -- Elliot From davej at redhat.com Thu Feb 3 18:52:58 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 3 Feb 2005 13:52:58 -0500 Subject: No announcement for kernel-2.6.10-1.12_FC2 In-Reply-To: <0F6DD42A2AF8186EEF93CE36@[10.0.0.4]> References: <0F6DD42A2AF8186EEF93CE36@[10.0.0.4]> Message-ID: <20050203185258.GA16554@redhat.com> On Thu, Feb 03, 2005 at 06:26:30AM -0800, Kenneth Porter wrote: > Saw this in my nightly "yum check-update" run. So what's new with this? > (There's also a new squid in the repository with no announcement for it.) Will go out soon. Dave From kyrre at solution-forge.net Thu Feb 3 19:15:11 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 03 Feb 2005 20:15:11 +0100 Subject: My ideas for a new printing system In-Reply-To: <42025459.4040507@beryllium.net> References: <42025459.4040507@beryllium.net> Message-ID: <1107458111.2636.20.camel@localhost.localdomain> tor, 03.02.2005 kl. 17.42 skrev Remco Poelstra: > Hi, > > Let me first introduce myself, sine you people probably never heard > about me :). > I'm a student at the Eindhoven University of Technology. With a team of > 4 students we are responsible for Linux support at the faculty of > Electrical Engineering. > > Tim Waugh asked me to help thinking about a new printing solution, as a > reply on a mail of me on the config list. > I read the posts here about that subject and I would like to share my > opinion on this matter: > > First I would like to state that there won't be any solution if CUPS > doesn't improve. > > The problem that eggcups tries to adress (authentication) isn't solved > if there is a chain of CUPS servers involved. If CUPS can't communicate > back, then the user still can't authenticate. So CUPS should implement a > 2-way IPP protocol. > Then eggcups can be reduced to listening to HAL messages in order to > display the print queue and pop up authentication dialogs. By not > implementing a full CUPS server, it has less system resource usage, > which is a good thing I think. > Second if CUPS supports signed browse packets, than we have an 'easy' > solution of identifying fake printers on a large network. > > For the configuration part: gnome-cups-manager does quite a nice job on > this. > Than we only need some decend tool to configure the server itself. > > Just my 2 cents, > > Remco Poelstra Another part which would make it much easier to configure for smaller networks (ie. those without a local DNS server), and avoids disasters if hosts named "localhost" shares printers - do a test on a recived hostname immediatly after it is recived, check that it does look up the correct IP - or an IP at all. If it does not resolve - use IP adress directly instead. Kyrre From notting at redhat.com Thu Feb 3 19:26:51 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Feb 2005 14:26:51 -0500 Subject: rawhide report: 20050203 changes In-Reply-To: <4c4ba15305020305121df942c2@mail.gmail.com> References: <200502031302.j13D2N407479@porkchop.devel.redhat.com> <4c4ba15305020305121df942c2@mail.gmail.com> Message-ID: <20050203192651.GA11582@nostromo.devel.redhat.com> Tom London (selinux at gmail.com) said: > more stealth packages? Script bug. It's fixed now, will be reflected tomorrow. Bill From kevinverma at gmail.com Thu Feb 3 19:38:23 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Thu, 3 Feb 2005 23:38:23 +0400 Subject: scope of swsusp2, thinkpad module and bootsplash with fedora Message-ID: <200502032338.23240.kevinverma@gmail.com> I will like to know if some one is working on merging swsusp2, thinkpad module and bootsplash kernel patches with Fedora kernel, it would be great to know if there are patches available for current kernel of FC3. http://softwaresuspend.berlios.de/ http://bootsplash.org/ http://bootsplash.de Cheers, Kevin From dcbw at redhat.com Thu Feb 3 19:42:17 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 03 Feb 2005 14:42:17 -0500 Subject: scope of swsusp2, thinkpad module and bootsplash with fedora In-Reply-To: <200502032338.23240.kevinverma@gmail.com> References: <200502032338.23240.kevinverma@gmail.com> Message-ID: <1107459737.29739.53.camel@dcbw.boston.redhat.com> On Thu, 2005-02-03 at 23:38 +0400, Kevin Verma wrote: > I will like to know if some one is working on merging swsusp2, thinkpad module > and bootsplash kernel patches with Fedora kernel, it would be great to know > if there are patches available for current kernel of FC3. > > http://softwaresuspend.berlios.de/ > http://bootsplash.org/ > http://bootsplash.de The Fedora kernel more or less tracks the upstream kernel directly, and the general line is "its 99% likely to not be in Fedora's kernel unless it's in the official Linux kernel." So the best way to get stuff like this in the upstream kernel is to submit those patches to the appropriate lists (lkml, netdev, etc). If you're not the maintainer, then I'd email them and urge them to start submitting patches upstream. Dan From johnp at redhat.com Thu Feb 3 20:02:19 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 03 Feb 2005 15:02:19 -0500 Subject: system-config-printer In-Reply-To: <1107378151.1125.79.camel@remedyz.boston.redhat.com> References: <20050201121139.GR5322@redhat.com> <1107378151.1125.79.camel@remedyz.boston.redhat.com> Message-ID: <1107460939.1125.146.camel@remedyz.boston.redhat.com> Ok, Now that I have outlined the current process I would like to make some suggestions on what I would like to see in terms of a printer configuration architecture in the future. * Kill hal_lpadmin - I originally wrote this so I could create queues using IPP[1] and it worked up to the point that I needed to create an actual PPD[2] file. I ended up changing it to just exec printconf. In theory all the functionality in here should move to the new printing backend. * Eventually get rid of cups-config-daemon - We need to keep it for now since it takes up minimal resources. cups-config-daemon should become a liaison for translating dbus messages to the new printconf backend commands. Once system service activation is developed we can dump cups- config-daemon and place all the D-BUS functionality directly into the printconf backend. Activation will then be able to start up the backend which can in turn service D-BUS requests directly. Resource usage is less important when activation is in play because the resources can be returned after printconf services the request (unlike the situation now where cups-config-daemon need to run all time on the off chance it will be called upon to configure a printer). * Enhancements to the backend: - Make it more knowledgeable - have it use hal to track printers - Make it more intelligent - Give it one command to auto-configure a printer. - Have it determine if it has the drivers it needs and automatically create a queue and name it. - If it can't find the driver have it talk to the console session so that it can get the user configured driver. - Give it the ability to have queue's renamed and remember those queue names the next time the printer is plugged in. - Give it the ability to accept and install 3rd party PPD files and use that PPD file whenever the printer shows up again (How secure is this? Can PPD files execute code it shouldn't?) - Have the ability to lock down specific printers from being auto-configured and also the ability to not allow any printers to be auto-configured. - Have the ability to delete queues by name or hal udi - Have it talk CUPS' language - CUPS speaks IPP and since it will be hard to get D-BUS patches upstream we should just use IPP to do live configurations of auto-configured printers. I was successfully doing this in hal_lpadmin sans the PPD files. This works great because CUPS gets the configuration on the fly so it doesn't have to refresh its printer list like it does now when we send the HUP signal. We will use the D-BUS protocol where authentication is a problem (user session) and translate those D-BUS calls to IPP calls. - Allow an admin to change or add configuration to the foomatic database just in case things are wrong or nonexistent. Perhaps add a way to export these changes for attachment to a bug report. - Make sure the system-config tools and the desktop tools play nice with the queues. (i.e. the two should not step on each others feet. If a printer is already statically added via the admin tool auto-configure should not create a new queue. Also if the admin tool made changes to an auto-configured queue those changes should be honored the next time the printer is plugged in) - Figure out a way to have this all still work in a stateless environment (read only root) Ok, that is all I can think of for now. It is enough to discuss. Would like input on what everyone thinks about this and anything they would add, remove or tweak. [1] The Internet Printing Protocol (IPP) is a sanctioned Internet Engineering Task Force (IETF) standard for printing documents over the web. IPP defines basic handshaking and communication methods, but does not enforce the format of the print data stream. Typically, a standard page description language, such as HP PCL or Adobe PostScript, would be used. [2] PostScript Printer Description file. A file that contains information on screen angle, resolution, page size and device-specific information for a file to be printed on a PostScript device. On Wed, 2005-02-02 at 16:02 -0500, John (J5) Palmieri wrote: > Overview on how desktop printer configuration currently works: > > 1. Printer is plugged in > 2. HAL is notified and calls the printer-update.hal shell script > in /etc/hal/capability.d/ > 3. hal_lpadmin from the hal_cups_utils package is called with the > printer's udi (what HAL uses to identify devices). > 4. hal_lpadmin checks to see if the device is a printer and if so > gets the make and model of the device from HAL > 5. A command is constructed to execute printconf's match-driver command > 6. If a match is found we > - construct printconf's add-local command to add the printer > - execute printconf-backend --force-rebuild to output the cups > configuration files > - send a HUP signal to cups to reload its data > > 7. If a match is not found we > - Ask the console user's session through eggcups if they have a > driver match for the make and model in gconf > - if no we then prompt the user to select the closest > make and model that matches their printer and is in > our foomatic database > - The user selects a make an model which is then > entered into gconf and a message is sent to > cups-config-daemon which executes step 6 > with the selected make and model > - if yes we get the make and model returned by gconf > and go back to step 6 > > * On session startup eggcups will loop through the list of printers in > gconf and configure them if they exist in HAL > > What printconf does (I have limited knowledge of how printconf works so > can you correct me here Tim?): > > * printconf's match-driver command will return the name of the driver > given a make and model of a printer > - if a driver is found go to step 6 above > * printconf's add-local command sets up a local print queue in the > sysconfig database using the make and model of the printer. > * printconf-backend --force-rebuild outputs the queues it finds in > the sysconf database into cups config files. > - the make and model are looked up in foomatic > - a PPD file is written out based on the config info > in foomatic > - printers.conf is updated with the new queue info > - the queue is created in /var/spool/cups > * The HUP signal to cups tells it to reload its config files and pick > up the new printers > > That is the basics. A lot of the desktop configuration can be > simplified by putting functionality into the backend. I will post a > list of features and designs I would like to see go into a rewritten > system-config-printer soon. > > On Tue, 2005-02-01 at 12:11 +0000, Tim Waugh wrote: > > The tool we provide for configuring printers needs to change. > > > > The one we have works as designed, but unfortunately the design was > > that: > > > > * print queue configuration is stored in an XML file > > > > * a front-end interface allows the user to manipulate the XML file > > > > * a back-end program, which runs at spooler start-up time, writes out > > spooler-specific configuration based on the XML file > > > > There are several bad consequences of this: > > > > * the XML file format was and is inflexible > > > > * the configuration options are limited to those common to both > > spoolers we were shipping at the time the XML format was decided > > > > * it is VERY SLOW: you can't *modify* configuration, only write out > > entirely new configurations (i.e. trigger the back-end) > > > > * again, due to the XML format chosen, we are tied to the foomatic > > database in such as way that we absolutely require foomatic to know > > about the printer before we can configure it. > > > > Even if you have the manufacturer's PPD file, there is very little > > you can do to get your printer working. > > > > * changes made using the CUPS configuration interface > > (http://localhost:631/), or any other method external to > > system-config-printer, are not reflected in the XML file and so > > cannot be modified. > > > > * changes made using system-config-printer cannot be modified using > > other tools, since changes will be overwritten. > > > > and so on. > > > > Does anyone have ideas for how system-config-printer should be > > re-written? > > > > Thanks, > > Tim. > > */ > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- > John (J5) Palmieri > Associate Software Engineer > Desktop Group > Red Hat, Inc. > Blog: http://martianrock.com > -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From kevinverma at gmail.com Thu Feb 3 20:03:07 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 4 Feb 2005 00:03:07 +0400 Subject: scope of swsusp2, thinkpad module and bootsplash with fedora In-Reply-To: <1107459737.29739.53.camel@dcbw.boston.redhat.com> References: <200502032338.23240.kevinverma@gmail.com> <1107459737.29739.53.camel@dcbw.boston.redhat.com> Message-ID: <200502040003.07467.kevinverma@gmail.com> > The Fedora kernel more or less tracks the upstream kernel directly, and > the general line is "its 99% likely to not be in Fedora's kernel unless > it's in the official Linux kernel." So the best way to get stuff like > this in the upstream kernel is to submit those patches to the > appropriate lists (lkml, netdev, etc). If you're not the maintainer, > then I'd email them and urge them to start submitting patches upstream. > I am not a maintainer, yes it will be good if you can urge the maintainers of mentioned projects to start submitting patches upstream. From johnp at redhat.com Thu Feb 3 22:16:29 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 03 Feb 2005 17:16:29 -0500 Subject: system-config-printer In-Reply-To: <1107460939.1125.146.camel@remedyz.boston.redhat.com> References: <20050201121139.GR5322@redhat.com> <1107378151.1125.79.camel@remedyz.boston.redhat.com> <1107460939.1125.146.camel@remedyz.boston.redhat.com> Message-ID: <1107468989.1125.153.camel@remedyz.boston.redhat.com> Oh, one more thing I forgot: I would like to see an easy way for the backend to mark and configure a local queue for sharing. On Thu, 2005-02-03 at 15:02 -0500, John (J5) Palmieri wrote: > Ok, > > Now that I have outlined the current process I would like to make some > suggestions on what I would like to see in terms of a printer > configuration architecture in the future. > > * Kill hal_lpadmin - I originally wrote this so I could create queues > using IPP[1] and it worked up to the point that I needed to create an > actual PPD[2] file. I ended up changing it to just exec printconf. In > theory all the functionality in here should move to the new printing > backend. > > * Eventually get rid of cups-config-daemon - We need to keep it for now > since it takes up minimal resources. cups-config-daemon should become a > liaison for translating dbus messages to the new printconf backend > commands. Once system service activation is developed we can dump cups- > config-daemon and place all the D-BUS functionality directly into the > printconf backend. Activation will then be able to start up the > backend which can in turn service D-BUS requests directly. Resource > usage is less important when activation is in play because the resources > can be returned after printconf services the request (unlike the > situation now where cups-config-daemon need to run all time on the off > chance it will be called upon to configure a printer). > > * Enhancements to the backend: > - Make it more knowledgeable - have it use hal to track printers > > - Make it more intelligent > - Give it one command to auto-configure a printer. > > - Have it determine if it has the drivers it needs > and automatically create a queue and name it. > > - If it can't find the driver have it talk to the > console session so that it can get the user configured > driver. > > - Give it the ability to have queue's renamed and > remember those queue names the next time the printer > is plugged in. > > - Give it the ability to accept and install 3rd party > PPD files and use that PPD file whenever the printer > shows up again (How secure is this? Can PPD files > execute code it shouldn't?) > > - Have the ability to lock down specific printers from > being auto-configured and also the ability to not > allow any printers to be auto-configured. > > - Have the ability to delete queues by name or hal udi > > - Have it talk CUPS' language - CUPS speaks IPP and since it > will be hard to get D-BUS patches upstream we should just > use IPP to do live configurations of auto-configured > printers. I was successfully doing this in hal_lpadmin > sans the PPD files. This works great because CUPS gets > the configuration on the fly so it doesn't have to > refresh its printer list like it does now when we send > the HUP signal. We will use the D-BUS protocol where > authentication is a problem (user session) and translate > those D-BUS calls to IPP calls. > > - Allow an admin to change or add configuration to the foomatic > database just in case things are wrong or nonexistent. > Perhaps add a way to export these changes for attachment > to a bug report. > > - Make sure the system-config tools and the desktop tools play > nice with the queues. (i.e. the two should not step on each > others feet. If a printer is already statically added via the > admin tool auto-configure should not create a new queue. Also > if the admin tool made changes to an auto-configured queue > those changes should be honored the next time the printer is > plugged in) > > - Figure out a way to have this all still work in a stateless > environment (read only root) > > Ok, that is all I can think of for now. It is enough to discuss. Would > like input on what everyone thinks about this and anything they would > add, remove or tweak. > > [1] The Internet Printing Protocol (IPP) is a sanctioned Internet > Engineering Task Force (IETF) standard for printing documents over the > web. IPP defines basic handshaking and communication methods, but does > not enforce the format of the print data stream. Typically, a standard > page description language, such as HP PCL or Adobe PostScript, would be > used. > > [2] PostScript Printer Description file. A file that contains > information on screen angle, resolution, page size and device-specific > information for a file to be printed on a PostScript device. > -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From retracile at gmail.com Sat Feb 5 02:54:29 2005 From: retracile at gmail.com (Eli) Date: Sat, 5 Feb 2005 02:54:29 +0000 Subject: Request package of glabels for Fedora Core/Extras Message-ID: <200502050254.29678.retracile@gmail.com> Point me to the right list if this the wrong place for this... A program that allows the creation of labels such as CD labels and business cards is something I did a good bit of looking for and I couldn't find anything that worked well. Happily, I recently found glabels. Now I can finally label those stacks of CDRs... and make some personal business cards... and maybe label the drawers on my Lego collection. The lack of a good label program appears to be a major hole in the scope of FC. Can we get glabels packaged in Extras or something? http://glabels.sourceforge.net/ Eli From rodd at clarkson.id.au Fri Feb 4 04:48:51 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 04 Feb 2005 15:48:51 +1100 Subject: Firefox not starting properly Message-ID: <1107492531.3363.2.camel@trevally.redfishdemo.com> Firefox is not starting properly for me since updating (almost completely - control-center has a conflict so wont install) to the current development rpms When I try to run firefox I get nothing on the screen. A look at 'ps ax | grep firefox' shows: [rodd at trevally ~]$ ps ax | grep firefox 3394 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/firefox -UILocale en-US 3415 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/run-mozilla.sh /usr/lib/firefox-1.0/firefox-bin -UILocale en-US 3420 ? Sl 0:00 /usr/lib/firefox-1.0/firefox-bin -UILocale en-US 3523 pts/2 R+ 0:00 grep firefox [rodd at trevally ~]$ I can kill these processes, but it doesn't help. Any ideas? Rodd From rodd at clarkson.id.au Fri Feb 4 05:49:21 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 04 Feb 2005 16:49:21 +1100 Subject: Firefox not starting properly In-Reply-To: <1107492531.3363.2.camel@trevally.redfishdemo.com> References: <1107492531.3363.2.camel@trevally.redfishdemo.com> Message-ID: <1107496162.3958.2.camel@trevally.redfishdemo.com> Sorry, this should have been sent to fedora-test. My apologies. Rodd On Fri, 2005-02-04 at 15:48 +1100, Rodd Clarkson wrote: > Firefox is not starting properly for me since updating (almost > completely - control-center has a conflict so wont install) to the > current development rpms > > When I try to run firefox I get nothing on the screen. > > A look at 'ps ax | grep firefox' shows: > > [rodd at trevally ~]$ ps ax | grep firefox > 3394 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/firefox -UILocale en-US > 3415 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/run-mozilla.sh /usr/lib/firefox-1.0/firefox-bin -UILocale en-US > 3420 ? Sl 0:00 /usr/lib/firefox-1.0/firefox-bin -UILocale en-US > 3523 pts/2 R+ 0:00 grep firefox > [rodd at trevally ~]$ > > I can kill these processes, but it doesn't help. > > Any ideas? > > > Rodd > > > > -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From skvidal at phy.duke.edu Fri Feb 4 05:55:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 00:55:23 -0500 Subject: Request package of glabels for Fedora Core/Extras In-Reply-To: <200502050254.29678.retracile@gmail.com> References: <200502050254.29678.retracile@gmail.com> Message-ID: <1107496523.3568.1.camel@cutter> On Sat, 2005-02-05 at 02:54 +0000, Eli wrote: > Point me to the right list if this the wrong place for this... > > A program that allows the creation of labels such as CD labels and business > cards is something I did a good bit of looking for and I couldn't find > anything that worked well. Happily, I recently found glabels. > Now I can finally label those stacks of CDRs... and make some personal > business cards... and maybe label the drawers on my Lego collection. > > The lack of a good label program appears to be a major hole in the scope of > FC. Can we get glabels packaged in Extras or something? > > http://glabels.sourceforge.net/ > Post this to the fedora-extras-list. That's probably the best place to go. -sv From wes.shull at gmail.com Fri Feb 4 06:07:53 2005 From: wes.shull at gmail.com (Wes Shull) Date: Thu, 3 Feb 2005 23:07:53 -0700 Subject: Slab: in /proc/meminfo not corrent in recent kernels? Message-ID: Since sometime after build 1176 (IIRC), I've noticed that the KDE System Monitor tray applet (/usr/lib/kde3/ktimemon_panelapplet.*) has been reporting unbelievable amounts of memory used by the kernel. I finally got around to taking a gander at the source to figure it out... in KSample::readSample() in kdeaddons-3.3.2/kicker-applets/ktimemon/sample.cc, it adds the Slab: line (if it exists) to the Buffers: line to estimate kernel memory usage. Seems reasonable to me. So I compared those values as reported by two different kernels. Under 741 (current FC3 update), meminfo says: Buffers: 21676 kB Slab: 24252 kB Which I can believe. But under not too different usage, 1124 (latest rawhide) reports: Buffers: 8052 kB Slab: 116104 kB Which seems crazy (this is a 256 MB machine). So, has the meaning of the Slab: line changed, such that I need to bugzilla this for kdeaddons, or do I need to report this against the kernel? --wes From davej at redhat.com Fri Feb 4 06:23:29 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 4 Feb 2005 01:23:29 -0500 Subject: Slab: in /proc/meminfo not corrent in recent kernels? In-Reply-To: References: Message-ID: <20050204062329.GA7874@redhat.com> On Thu, Feb 03, 2005 at 11:07:53PM -0700, Wes Shull wrote: > Since sometime after build 1176 (IIRC), I've noticed that the KDE > System Monitor tray applet (/usr/lib/kde3/ktimemon_panelapplet.*) has > been reporting unbelievable amounts of memory used by the kernel. > > I finally got around to taking a gander at the source to figure it > out... in KSample::readSample() in > kdeaddons-3.3.2/kicker-applets/ktimemon/sample.cc, it adds the Slab: > line (if it exists) to the Buffers: line to estimate kernel memory > usage. Seems reasonable to me. So I compared those values as > reported by two different kernels. > > Under 741 (current FC3 update), meminfo says: > Buffers: 21676 kB > Slab: 24252 kB > > Which I can believe. But under not too different usage, 1124 (latest > rawhide) reports: > Buffers: 8052 kB > Slab: 116104 kB > > Which seems crazy (this is a 256 MB machine). > > So, has the meaning of the Slab: line changed, such that I need to > bugzilla this for kdeaddons, or do I need to report this against the > kernel? It depends. You just might have completely different things in slab cache. if you cat /proc/slabinfo (or run slabtop) you should see which slab has had the most growth between the two kernels. Dave From wes.shull at gmail.com Fri Feb 4 07:04:43 2005 From: wes.shull at gmail.com (Wes Shull) Date: Fri, 4 Feb 2005 00:04:43 -0700 Subject: Slab: in /proc/meminfo not corrent in recent kernels? In-Reply-To: <20050204062329.GA7874@redhat.com> References: <20050204062329.GA7874@redhat.com> Message-ID: Jeff wrote: > Make sure you have the most recent procps from Jan 24 2005. procps-3.2.5-1, which dates from Feb 1. Newer. (Bad?) Dave Jones wrote: > It depends. You just might have completely different things in > slab cache. if you cat /proc/slabinfo (or run slabtop) you should > see which slab has had the most growth between the two kernels. Well, it's like that as soon as my KDE session finishes loading when I log in, right after a reboot even. I'll do some slabinfo capture/comparison immediately on a fresh reboot, and just to single as well to see what kind of difference that makes. --wes From kzak at redhat.com Fri Feb 4 07:53:29 2005 From: kzak at redhat.com (Karel Zak) Date: Fri, 04 Feb 2005 08:53:29 +0100 Subject: Slab: in /proc/meminfo not corrent in recent kernels? In-Reply-To: References: Message-ID: <1107503609.26078.265.camel@petra> On Thu, 2005-02-03 at 23:07 -0700, Wes Shull wrote: > Since sometime after build 1176 (IIRC), I've noticed that the KDE > System Monitor tray applet (/usr/lib/kde3/ktimemon_panelapplet.*) has > been reporting unbelievable amounts of memory used by the kernel. > > I finally got around to taking a gander at the source to figure it > out... in KSample::readSample() in > kdeaddons-3.3.2/kicker-applets/ktimemon/sample.cc, it adds the Slab: Does it read data from /proc/slabinfo? Which kernel? The kernel 2.6.10 has a little different slabinfo format than old kernels. Karel -- Karel Zak From wes.shull at gmail.com Fri Feb 4 07:50:42 2005 From: wes.shull at gmail.com (Wes Shull) Date: Fri, 4 Feb 2005 00:50:42 -0700 Subject: Slab: in /proc/meminfo not corrent in recent kernels? In-Reply-To: References: <20050204062329.GA7874@redhat.com> Message-ID: I wrote: > I'll do some slabinfo > capture/comparison immediately on a fresh reboot, and just to single > as well to see what kind of difference that makes. Ok, done sooner than I thought. http://kuoi.asui.uidaho.edu/~wes/debug/ The runlevel 5 ones aren't from separate boots, I just telinit 5'ed after grabbing meminfo and slabinfo. And the dmesgs are really from /var/log/messages, but who's counting. (And yes, I know /dev/hdg is dying, no system stuff on there) Unfortunately, I don't know the significance of (m)any of the entries in the slabinfo, although I do note that dentry_cache accounts for roughly 10 MB of the difference... Hopefully some kernel gurus can tell if this behavior is a problem or not. Or maybe a side effect of debugging stuff? --wes From wes.shull at gmail.com Fri Feb 4 07:57:11 2005 From: wes.shull at gmail.com (Wes Shull) Date: Fri, 4 Feb 2005 00:57:11 -0700 Subject: Slab: in /proc/meminfo not corrent in recent kernels? In-Reply-To: <1107503609.26078.265.camel@petra> References: <1107503609.26078.265.camel@petra> Message-ID: Karel Zak wrote: > Does it read data from /proc/slabinfo? Which kernel? > The kernel 2.6.10 has a little different slabinfo format than old kernels. No, only /proc/meminfo. http://webcvs.kde.org/kdeaddons/kicker-applets/ktimemon/sample.cc?rev=1.23&view=auto if you want to browse the code online. (No patch differences in our rpm) Both kernels in question are 2.6.10: kernel-2.6.10-1.741_FC3 kernel-2.6.10-1.1124_FC4 741 is my current reference stable kernel (because rawhide has been exceptionally raw lately), but 1176 behaved identically to it (i.e. different than 1124) in this regard. --wes From mpeters at mac.com Fri Feb 4 08:20:09 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 04 Feb 2005 08:20:09 +0000 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: (from sopwith@redhat.com on Thu Feb 3 10:51:31 2005) References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> Message-ID: <1107505209l.7472l.3l@devel.mpeters.us> On 02/03/2005 10:51:31 AM, Elliot Lee wrote: > > gnucash we're waiting on the port to gtk2 > > gnucash is staying in core for now because the maintainer says so. :) > (I > assume this means that the gtk2 port is forthcoming.) Even if a gtk2 port is not forthcoming, it is really the only mature app that does what it does. From laroche at redhat.com Fri Feb 4 09:58:36 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 4 Feb 2005 10:58:36 +0100 Subject: Firefox not starting properly In-Reply-To: <1107492531.3363.2.camel@trevally.redfishdemo.com> References: <1107492531.3363.2.camel@trevally.redfishdemo.com> Message-ID: <20050204095836.GA29746@dudweiler.stuttgart.redhat.com> On Fri, Feb 04, 2005 at 03:48:51PM +1100, Rodd Clarkson wrote: > Firefox is not starting properly for me since updating (almost > completely - control-center has a conflict so wont install) to the > current development rpms > > When I try to run firefox I get nothing on the screen. > > A look at 'ps ax | grep firefox' shows: > > [rodd at trevally ~]$ ps ax | grep firefox > 3394 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/firefox -UILocale en-US > 3415 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/run-mozilla.sh /usr/lib/firefox-1.0/firefox-bin -UILocale en-US > 3420 ? Sl 0:00 /usr/lib/firefox-1.0/firefox-bin -UILocale en-US > 3523 pts/2 R+ 0:00 grep firefox > [rodd at trevally ~]$ > > I can kill these processes, but it doesn't help. > > Any ideas? I've downgraded to the previous version without language packs and that works fine for me. Bugzilla on this one is open AFAIK. greetings, Florian La Roche From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 4 09:58:18 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 4 Feb 2005 10:58:18 +0100 Subject: Including udftools Message-ID: <20050204105818.22b8a5ae@python2> Hi, I just received this email about udftools : -- Hi Matthias, At least the listinfo/mailman page says that's what your name is. ;-) I'm not a list subscriber, but I am also interested in seeing udftools get packaged for Fedora. As of kernel version 2.6.10 there is a new module called pktcdvd which supports packet writing(udf) to CD-RW media. I believe that is what Jon Roland is referring to in his post: http://lists.freshrpms.net/pipermail/freshrpms-list/2005-January/012130.html As it happens I have been trying to learn how to build rpms from scratch and this seemed(at first glance) to be a simple enough one to start with. Since I had already built the package from the source tarball with the patch from Peter Osterlund's website: http://web.telia.com/~u89404340/packet.html I decided to try and package it myself. The attached files contain the results of the first build that I've gotten to run to completion. It hasn't been tested yet and I'm sure the spec file needs work. I cobbled it(the spec file) together from an old Red Hat contrib package and a current Mandrake package. But, if you think others might be interested, please pass it along. Thank you, John Treacy -- So I was wondering... should udftools go into Extras, or into Core? Since support for packet writing has been included in the kernel, I'd favour Core (and this is why I'm posting here). Oh, and I've even found some old udftools packages made by someone @rh : http://people.redhat.com/twoerner/RPMS/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.12 0.42 0.45 From nphilipp at redhat.com Fri Feb 4 10:16:09 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 04 Feb 2005 11:16:09 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <420261B5.4010905@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> <1107420564.25624.19.camel@wombat.tiptoe.de> <420224F5.3010602@nc.rr.com> <1107450960.11167.11.camel@wombat.tiptoe.de> <420261B5.4010905@nc.rr.com> Message-ID: <1107512170.5946.7.camel@gibraltar.stuttgart.redhat.com> On Thu, 2005-02-03 at 12:39 -0500, Jeff Johnson wrote: > Nils Philippsen wrote: > > >On Thu, 2005-02-03 at 08:19 -0500, Jeff Johnson wrote: > > > > > > > >>Whether changelogs should be part of an immutable region or not is an open > >>question too. It is (and was) certainly possible to define a header > >>immutable region > >>without including changelogs content, which would permit truncation or other > >>forms of normalization, editing header content while installing. > >> > >>I chose to put *all* tags into a header immutable region so that I > >>would not have to have the discussion about which tags go where. > >> > >>For example, the content in changelogs, if not hardened by digest and/or > >>signature, > >>might be part of a socially engineered exploit to disguise a maliciously > >>modified > >>package. It's very hard not believe what you read. > >> > >> > > > >Well, I didn't propose anything of that sort (i.e. changelog outside of > >what is digested/signed) ;-). What I meant was that it is irrelevant > >whether you sign/digest an actually existing stream of bytes which > >contains the changelog or the result of a function which puts together > >this stream from changelog and the remainder of the header. > > > > > Yep, one can reassemble a header from components, and verify blobs. > > That was the context of my previous comments: you cannot reassemble a blob > unless the components are actually present, and there almost certainly > will beAWOL > some way for separate changelogs to go AWOL preventing reassembly. Agreed. > Splitting changelogs out, but not changing how digest/signature are > performed on headers, > adds complexity and additional failure modes where there are none now, > that are hard to "trust" > for no perceivable gain to verifiability other than compatibility with > the exsisting mechanism. > > Move changelogs out of headers, or truncate to acceptable length, is > better imho. > > Or RFE an explicit mechanism for moving changelogs out of headers and > normalizing content. Just musing ;-): Individual signatures on each header component, along with a signed list of components that should be present. That way, if something goes corrupt, you can find out what is broken ("URL not ok") unless the list gets damaged and a list should be a smaller target to be hit by random disaster than a complete header blob. This of course doesn't bring any more security where malice is involved, but I can as easily corrupt a complete header blob as I can the list or other single components, so nothing lost here. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From rdieter at math.unl.edu Fri Feb 4 12:55:06 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 4 Feb 2005 06:55:06 -0600 (CST) Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <1107505209l.7472l.3l@devel.mpeters.us> References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <20050131222016.GA9816@thacker.dyndns.org> <1107505209l.7472l.3l@devel.mpeters.us> Message-ID: On Fri, 4 Feb 2005, Michael A. Peters wrote: > On 02/03/2005 10:51:31 AM, Elliot Lee wrote: > >> > gnucash we're waiting on the port to gtk2 >> >> gnucash is staying in core for now because the maintainer says so. :) >> (I >> assume this means that the gtk2 port is forthcoming.) > > Even if a gtk2 port is not forthcoming, it is really the only mature app that > does what it does. kmymoney2 is pretty nice (I suppose I should submit it to extras now that I opened my mouth). -- Rex From jwboyer at jdub.homelinux.org Fri Feb 4 12:23:49 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 Feb 2005 06:23:49 -0600 Subject: CVS server down? Message-ID: <1107519829.20325.1.camel@jdub.homelinux.org> Seems CVS is down. A cvs co times out and I can't get to http://cvs.fedora.redhat.com. Any idea why? josh From buildsys at redhat.com Fri Feb 4 12:58:50 2005 From: buildsys at redhat.com (Build System) Date: Fri, 4 Feb 2005 07:58:50 -0500 Subject: rawhide report: 20050204 changes Message-ID: <200502041258.j14CwoD23502@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.3.3-1.cvs20050202.3.1 -------------------------------------- control-center-1:2.9.4-5 ------------------------ * Thu Feb 03 2005 Matthias Clasen - 2.9.4-5 - Fix the conflict to be against the actual packages gkrellm-2.2.4-2 --------------- * Thu Feb 03 2005 Karsten Hopp 2.2.4-2 - BuildRequires openssl-devel (#137548) gnome-panel-2.9.90-2 -------------------- * Thu Feb 03 2005 Matthias Clasen - 2.9.90-2 - Look for vendor-prefixed .desktop files gnomemeeting-1.2.0-4 -------------------- * Thu Feb 03 2005 Daniel Reed 1.2.0-4 - rebuild with evil patch to look for libebook-1.2.pc instead of libebook-1.0.pc (neither -2 nor -3 went through, but were tagged) * Thu Feb 03 2005 Matthias Clasen - 1.2.0-3 - rebuild * Fri Jan 28 2005 Florian La Roche - rebuild hicolor-icon-theme-0.7-1 ------------------------ * Fri Feb 04 2005 Alexander Larsson - 0.7-1 - Update to 0.7 mozplugger-1.7.1-2 ------------------ * Thu Feb 03 2005 Than Ngo 1.7.1-2 - drop xloadimage dependency redhat-menus-3.7.1-5 -------------------- * Thu Feb 03 2005 - 3.7.1-5 - Add settings.menu rpmdb-fedora-1:4-0.20050204 --------------------------- rsh-0.17-28 ----------- * Thu Feb 03 2005 Karel Zak 0.17-28 - malicious rcp server can cause rcp to write to arbitrary files (like scp CAN-2004-0175) (#146464) selinux-policy-strict-1.21.8-4 ------------------------------ * Thu Feb 03 2005 Dan Walsh 1.21.8-4 - Fix postfix handling in targeted with dovecot. - Stop transitioning to httpd_sys_script_t if httpd_disable_trans is set * Thu Feb 03 2005 Dan Walsh 1.21.8-2 - Allow syslogd to r_netlink_route - Dontaudit samba access to $1_file_types * Tue Feb 01 2005 Dan Walsh 1.21.6-1 - Update to latest from NSA - Fix cron transiton rules for targeted policy - Update to latest from NSA * Update access vectors selinux-policy-targeted-1.21.8-4 -------------------------------- * Thu Feb 03 2005 Dan Walsh 1.21.8-4 - Fix postfix handling in targeted with dovecot. - Stop transitioning to httpd_sys_script_t if httpd_disable_trans is set * Wed Feb 02 2005 Dan Walsh 1.21.8-2 - Allow syslogd to r_netlink_route - Dontaudit samba access to $1_file_types * Tue Feb 01 2005 Dan Walsh 1.21.7-1 - Update to latest from NSA * Add allow_execmem boolean stardict-2.4.4-1 ---------------- * Thu Feb 03 2005 Leon Ho 2.4.4-2 - Reupdate the spec file - Upgrade to 2.4.4 * Sun Nov 28 2004 Hu Zheng 2.4.4 - Public release of StarDict 2.4.4. * Thu Feb 19 2004 Hu Zheng 2.4.3 - Public release of StarDict 2.4.3. swig-1.3.24-1 ------------- * Thu Feb 03 2005 Karsten Hopp 1.3.24-1 - update system-config-printer-0.6.121-1 ------------------------------- * Thu Feb 03 2005 Tim Waugh 0.6.121-1 - 0.6.121: - Removed tests/.testpage.ps (bug #145418). - Try to avoid crashing even if perl does. - Don't write out bad confguration for IF(@eth0) and an IP address on that interface (bug #146794). - Fixed two mistake in backend.py. - Fixed option handling bug when changing printer models (bug #146908). texinfo-4.8-1 ------------- * Thu Feb 03 2005 Tim Waugh 4.8-1 - 4.8. unzip-5.51-8 ------------ * Thu Feb 03 2005 Ivana Varekova 5.51-7 - fix segfault with unpacking of zipfiles containing dangling symlinks (bug #134073) xfce4-panel-4.2.0-2 ------------------- * Thu Feb 03 2005 Than Ngo 4.2.0-2 - new sub package xfce4-panel-devel xfwm4-themes-4.2.0-1 -------------------- * Thu Feb 03 2005 Than Ngo 4.2.0-1 - 4.2.0 xorg-x11-6.8.1.904-1 -------------------- * Fri Feb 04 2005 Mike A. Harris 6.8.1.904-1 - Update main tarball to X.Org X11 6.8.1.904 (6.8.2 release candidate 4) via X.Org official tarball: xorg-x11-6.8.1.904.tar.gz - Removed xorg-x11-6.8.1.903-nls-pt_BR.UTF-8-fix.patch, as it is integrated into 6.8.1.904 already. * Fri Feb 04 2005 Mike A. Harris 6.8.1.903-4 - Added new with_alternate_projectroot macro, which will eventually allow the parallel installation of multiple versions of xorg-x11 in rpm format without conflicting with each other (theoretically). The feature is intended only for Red Hat X.Org developer usage, and will not be an officially supported installation method. It is an incomplete experimental work in progress, and should not be used by mortals. THIS WILL FRY YOUR SYSTEM, DO NOT USE IT. :o) * Wed Feb 02 2005 Soeren Sandmann 6.8.1.903-3 - Added patch to fix Composite gravity issue, recently added to xorg HEAD. (fdo#2230). From rahulsundaram at gmail.com Fri Feb 4 13:12:08 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 4 Feb 2005 18:42:08 +0530 Subject: CVS server down? In-Reply-To: <1107519829.20325.1.camel@jdub.homelinux.org> References: <1107519829.20325.1.camel@jdub.homelinux.org> Message-ID: On Fri, 04 Feb 2005 06:23:49 -0600, Josh Boyer wrote: > Seems CVS is down. A cvs co times out and I can't get to > http://cvs.fedora.redhat.com. > > Any idea why? fedora-devel might be a better choice for this question -- Regards, Rahul Sundaram From jwboyer at jdub.homelinux.org Fri Feb 4 13:15:45 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 Feb 2005 07:15:45 -0600 Subject: CVS server down? In-Reply-To: References: <1107519829.20325.1.camel@jdub.homelinux.org> Message-ID: <1107522945.21311.0.camel@jdub.homelinux.org> On Fri, 2005-02-04 at 18:42 +0530, Rahul Sundaram wrote: > On Fri, 04 Feb 2005 06:23:49 -0600, Josh Boyer > wrote: > > Seems CVS is down. A cvs co times out and I can't get to > > http://cvs.fedora.redhat.com. > > > > Any idea why? > > fedora-devel might be a better choice for this question Um... that's where I sent it... josh From guhvies at gmail.com Fri Feb 4 13:19:29 2005 From: guhvies at gmail.com (ne...) Date: Fri, 4 Feb 2005 08:19:29 -0500 Subject: CVS server down? In-Reply-To: References: <1107519829.20325.1.camel@jdub.homelinux.org> Message-ID: On Fri, 4 Feb 2005 18:42:08 +0530, Rahul Sundaram wrote: > On Fri, 04 Feb 2005 06:23:49 -0600, Josh Boyer > wrote: > > Seems CVS is down. A cvs co times out and I can't get to > > http://cvs.fedora.redhat.com. > > > > Any idea why? > > fedora-devel might be a better choice for this question Er, isn't this fedora-devel? I am on my third mug of black unsweetened coffee, so I might need a little clue stick here... N. Emile... -- Registered Linux User # 125653 (http://counter.li.org) Certified: 75% bastard, 42% of which is tard. http://www.thespark.com/bastardtest From ville.skytta at iki.fi Fri Feb 4 13:28:03 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 04 Feb 2005 15:28:03 +0200 Subject: CVS server down? In-Reply-To: <1107519829.20325.1.camel@jdub.homelinux.org> References: <1107519829.20325.1.camel@jdub.homelinux.org> Message-ID: <1107523683.30769.5.camel@bobcat.mine.nu> On Fri, 2005-02-04 at 06:23 -0600, Josh Boyer wrote: > Seems CVS is down. A cvs co times out and I can't get to > http://cvs.fedora.redhat.com. > > Any idea why? https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00125.html From rdieter at math.unl.edu Fri Feb 4 13:48:08 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 04 Feb 2005 07:48:08 -0600 Subject: rawhide report: 20050204 changes In-Reply-To: <200502041258.j14CwoD23502@porkchop.devel.redhat.com> References: <200502041258.j14CwoD23502@porkchop.devel.redhat.com> Message-ID: <42037D18.9090108@math.unl.edu> Build System wrote: > redhat-menus-3.7.1-5 > -------------------- > * Thu Feb 03 2005 - 3.7.1-5 > - Add settings.menu If this bug (that affects KDE users) *ever* going to get fixed? http://bugzilla.redhat.com/bugzilla/122181 http://bugzilla.redhat.com/bugzilla/137796 I even included a patch. -- Rex From jwboyer at jdub.homelinux.org Fri Feb 4 14:08:43 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 Feb 2005 08:08:43 -0600 Subject: CVS server down? In-Reply-To: <1107523683.30769.5.camel@bobcat.mine.nu> References: <1107519829.20325.1.camel@jdub.homelinux.org> <1107523683.30769.5.camel@bobcat.mine.nu> Message-ID: <1107526123.21487.0.camel@jdub.homelinux.org> On Fri, 2005-02-04 at 15:28 +0200, Ville Skytt? wrote: > On Fri, 2005-02-04 at 06:23 -0600, Josh Boyer wrote: > > Seems CVS is down. A cvs co times out and I can't get to > > http://cvs.fedora.redhat.com. > > > > Any idea why? > > https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00125.html Ah. Thanks. josh From n3npq at nc.rr.com Fri Feb 4 14:16:04 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Fri, 04 Feb 2005 09:16:04 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107512170.5946.7.camel@gibraltar.stuttgart.redhat.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <1107212547.17531.10.camel@one.myworld> <1107350368.10061.23.camel@wombat.tiptoe.de> <20050202141307.GA5670@dudweiler.stuttgart.redhat.com> <1107377842.8304.4.camel@gibraltar.stuttgart.redhat.com> <42014522.3040409@nc.rr.com> <1107381452.8304.17.camel@gibraltar.stuttgart.redhat.com> <42014F1B.9090809@nc.rr.com> <1107420564.25624.19.camel@wombat.tiptoe.de> <420224F5.3010602@nc.rr.com> <1107450960.11167.11.camel@wombat.tiptoe.de> <420261B5.4010905@nc.rr.com> <1107512170.5946.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: <420383A4.4090903@nc.rr.com> Nils Philippsen wrote: >On Thu, 2005-02-03 at 12:39 -0500, Jeff Johnson wrote: > > > >Just musing ;-): Individual signatures on each header component, along >with a signed list of components that should be present. That way, if > Smells too much like DNSSec to me. Ever tried to babysit a DNSSEC config? PITA ... >something goes corrupt, you can find out what is broken ("URL not ok") >unless the list gets damaged and a list should be a smaller target to be >hit by random disaster than a complete header blob. This of course >doesn't bring any more security where malice is involved, but I can as >easily corrupt a complete header blob as I can the list or other single >components, so nothing lost here. > > Hint: encrypted/signed files and certificate management are far more interesting problems. So is exploding header meatadata into LDAP or WebDAV attributes. 73 de Jeff From niemeyer at conectiva.com Fri Feb 4 14:13:54 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Fri, 4 Feb 2005 12:13:54 -0200 Subject: Smart resources Message-ID: <20050204141354.GE7903@burma.localdomain> Greetings, Now it's official: thanks to python-hosting.com, Smart Package Manager has a new home (still at http://smartpm.org), using a Trac system which includes Wiki, Ticket system, public Subversion repository, and more. I'd also like to announce that we have fresh new mailing list at: http://groups-beta.google.com/group/smartpm Join us! ;-) -- Gustavo Niemeyer http://niemeyer.net From rahulsundaram at yahoo.co.in Fri Feb 4 13:22:19 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 4 Feb 2005 05:22:19 -0800 (PST) Subject: CVS server down? In-Reply-To: Message-ID: <20050204132219.12555.qmail@web8506.mail.in.yahoo.com> --- "ne..." wrote: > On Fri, 4 Feb 2005 18:42:08 +0530, Rahul Sundaram > wrote: > > On Fri, 04 Feb 2005 06:23:49 -0600, Josh Boyer > > wrote: > > > Seems CVS is down. A cvs co times out and I > can't get to > > > http://cvs.fedora.redhat.com. > > > > > > Any idea why? > > > > fedora-devel might be a better choice for this > question > Er, isn't this fedora-devel? I am on my third mug of > black unsweetened > coffee, so I might need a little clue stick here... ok. I am the one who goofed up here. sorry ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? All your favorites on one personal page ? Try My Yahoo! http://my.yahoo.com From davej at redhat.com Fri Feb 4 14:36:13 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 4 Feb 2005 09:36:13 -0500 Subject: Slab: in /proc/meminfo not corrent in recent kernels? In-Reply-To: References: <20050204062329.GA7874@redhat.com> Message-ID: <20050204143613.GA5114@redhat.com> On Fri, Feb 04, 2005 at 12:50:42AM -0700, Wes Shull wrote: > The runlevel 5 ones aren't from separate boots, I just telinit 5'ed > after grabbing meminfo and slabinfo. And the dmesgs are really from > /var/log/messages, but who's counting. (And yes, I know /dev/hdg is > dying, no system stuff on there) Unfortunately, I don't know the > significance of (m)any of the entries in the slabinfo, although I do > note that dentry_cache accounts for roughly 10 MB of the difference... > Hopefully some kernel gurus can tell if this behavior is a problem or > not. Or maybe a side effect of debugging stuff? On a quick look, it actually seems you use more slabs on the 741 kernel, the only big difference being in the number of size-32 elements allocated, but this is likely just due to the slab-debug stuff being enabled. If you look at the size of the objects (3rd number) you'll see that in the 1124 kernel they grow a little, and after size-64, they're a minimum of 4kb due to the extra overhead of the checking. This means that in the debugging kernels, we're actually running slightly different allocation patterns than we see in normal life, but the potential for catching more serious bugs is an acceptable tradeoff. Let us know if things don't go back to normal after debugging is switched back off (usually its on up until the final test release). Dave From fedora-devel at camperquake.de Fri Feb 4 16:07:05 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 4 Feb 2005 17:07:05 +0100 Subject: Fedora PPC things... In-Reply-To: <1106835536.19262.92.camel@hades.cambridge.redhat.com> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> <20050127150624.2b668980@nausicaa.camperquake.de> <20050127141109.GC21442@redhat.com> <1106835536.19262.92.camel@hades.cambridge.redhat.com> Message-ID: <20050204170705.604e3ed8@nausicaa.camperquake.de> Hi. David Woodhouse wrote: > Yeah. I poked it last week and sent patches upstream to fix everything > that broke. They'll trickle through. I assumed it wasn't worth giving > you the patches directly for inclusion in the interim. I just wanted to report that 2.6.10-1.1124_FC4 successfully boots on my iBook2. -- "...or you could just download NT Perl. OTOH, learning programming using perl is like learning chemistry using live grenades." -- Richard Watts From jorton at redhat.com Fri Feb 4 16:25:12 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 4 Feb 2005 16:25:12 +0000 Subject: SSL certificate management/storage Message-ID: <20050204162512.GA23731@redhat.com> There was a brief thread on this at the end of last year; obviously "certificate management" is a problem of vast scope but it would be good to sort out at least some simple filesystem conventions for FC4. Some simple problems I'd like to solve: 1. certificate storage is split between /etc/httpd/conf/ssl.* for mod_ssl-specific stuff, and and /usr/share/ssl for system-wide 2. ... and /usr/share/ssl is Very Wrong for "config data" like certs 3. increasing number of daemon packages are creating self-signed certs in %post scripts; could/should this be unified? Any comments? joe From thacker at math.cornell.edu Fri Feb 4 16:59:05 2005 From: thacker at math.cornell.edu (John Thacker) Date: Fri, 4 Feb 2005 11:59:05 -0500 Subject: nautilus-media obsolete Message-ID: <20050204165905.GA4970@thacker.dyndns.org> So it appears that: 1) nautilus-media isn't being updated, 2) it doesn't build against the new nautilus releases, and therefore 3) it's being dropped from GNOME 2.10 http://mail.gnome.org/archives/release-team/2005-February/msg00020.html http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00035.html However, it's blocking upgrades of nautilus in devel. It can be easily removed, but there needs to be an Obsoletes: added to the nautilus package to get rid of nautilus-media on upgrades. John Thacker -------------- 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 Fri Feb 4 17:18:14 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 4 Feb 2005 12:18:14 -0500 Subject: Smart resources In-Reply-To: <20050204141354.GE7903@burma.localdomain> References: <20050204141354.GE7903@burma.localdomain> Message-ID: <20050204171814.GG11938@angus.ind.WPI.EDU> On Fri, Feb 04, 2005 at 12:13:54PM -0200, Gustavo Niemeyer wrote: > I'd also like to announce that we have fresh new mailing list at: > > http://groups-beta.google.com/group/smartpm Is it possible to join this through e-mail without having an account on the Google web site? From Axel.Thimm at ATrpms.net Fri Feb 4 18:15:41 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 4 Feb 2005 19:15:41 +0100 Subject: New kernels: xen config breaking rpmbuild --target noarch? Message-ID: <20050204181541.GD20901@neu.nirvana> Hi, the new kernels have xen configs (nice :), but rpmbuild -bp --target noarch breaks on FC2. Since there are noarch builds published for FC2, I guess that maybe something is different in Dave's build environment? Error is below. Thanks. + cp .config configs/kernel-2.6.10-i686-smp.config + mv kernel-2.6.10-i686-xen0.config .config ++ echo kernel-2.6.10-i686-xen0.config ++ cut -d- -f3 ++ cut -d. -f1 ++ sed -e s/i.86/i386/ -e s/s390x/s390/ -e s/ppc64.series/ppc64/ + make ARCH=i386 nonint_oldconfig .config:39: trying to assign nonexistent symbol PREEMPT_BKL .config:62: trying to assign nonexistent symbol PCIEPORTBUS .config:94: trying to assign nonexistent symbol INFINIBAND .config:95: trying to assign nonexistent symbol INFINIBAND_MTHCA .config:96: trying to assign nonexistent symbol INFINIBAND_MTHCA_SSE_DOORBELL .config:97: trying to assign nonexistent symbol INFINIBAND_MTHCA_DEBUG .config:98: trying to assign nonexistent symbol INFINIBAND_IPOIB .config:99: trying to assign nonexistent symbol INFINIBAND_IPOIB_DEBUG .config:134: trying to assign nonexistent symbol MTD_BLOCK2MTD .config:203: trying to assign nonexistent symbol MTD_NAND_NANDSIM .config:208: trying to assign nonexistent symbol MTD_REDBOOT_DIRECTORY_BLOCK .config:210: trying to assign nonexistent symbol MTD_XIP .config:241: trying to assign nonexistent symbol ACPI_CONTAINER .config:381: trying to assign nonexistent symbol SCSI_ISCSI_ATTRS .config:750: trying to assign nonexistent symbol BRIDGE_EBT_ULOG .config:808: trying to assign nonexistent symbol CLS_U32_MARK [...] .config:4601: trying to assign nonexistent symbol XEN_BLKDEV_BACKEND .config:4602: trying to assign nonexistent symbol XEN_NETDEV_BACKEND .config:4603: trying to assign nonexistent symbol XEN_BLKDEV_FRONTEND .config:4604: trying to assign nonexistent symbol XEN_NETDEV_FRONTEND .config:4605: trying to assign nonexistent symbol XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER CONFIG_X86_HZ CONFIG_PCMCIA_OBSOLETE CONFIG_BLK_DEV_DELKIN CONFIG_BLK_DEV_IT821X CONFIG_SCSI_QLA6322 CONFIG_IP_NF_NAT_LOCAL CONFIG_IP_NF_COMPAT_IPCHAINS CONFIG_IP_NF_COMPAT_IPFWADM CONFIG_TUX CONFIG_TUX_EXTCGI CONFIG_TUX_EXTENDED_LOG CONFIG_TUX_DEBUG CONFIG_EEPRO100_PIO CONFIG_USB_TIGL make[1]: *** [nonint_oldconfig] Error 14 make: *** [nonint_oldconfig] Error 2 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Feb 4 19:11:17 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 4 Feb 2005 20:11:17 +0100 Subject: New kernels: xen config breaking rpmbuild --target noarch? In-Reply-To: <20050204181541.GD20901@neu.nirvana> References: <20050204181541.GD20901@neu.nirvana> Message-ID: <20050204191117.GE20901@neu.nirvana> On Fri, Feb 04, 2005 at 07:15:41PM +0100, Axel Thimm wrote: > the new kernels have xen configs (nice :), No, they don't :/ The issue is that the specfile picks up all *.config files that are in your source dir ($RPM_SOURCE_DIR/kernel-%{kversion}*.config), so unpacking the src.rpm over a previously unpacked rawhide src.rpm picks up the xen config files as well. Not a big deal, but should the kernel specfile explicitely pull in the config files mentioned as %{SOURCE20} etc? > but rpmbuild -bp --target noarch breaks on FC2. Since there are > noarch builds published for FC2, I guess that maybe something is > different in Dave's build environment? > Error is below. > + cp .config configs/kernel-2.6.10-i686-smp.config > + mv kernel-2.6.10-i686-xen0.config .config > ++ echo kernel-2.6.10-i686-xen0.config > ++ cut -d- -f3 > ++ cut -d. -f1 > ++ sed -e s/i.86/i386/ -e s/s390x/s390/ -e s/ppc64.series/ppc64/ > + make ARCH=i386 nonint_oldconfig -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sopwith at redhat.com Fri Feb 4 21:29:41 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 4 Feb 2005 16:29:41 -0500 (EST) Subject: Fedora Core 4 test 1 freeze ahead Message-ID: Yes, it's that time again... Although the FC4 schedule hasn't been finalized yet, we do need to try to stick to the preliminary one until it's decided otherwise. Fedora Core 4 test 1 is currently slated to come out on February 21st, which means that I would fall in love with you all over again if you did your part to make sure the tree was installable and free of broken dependencies & conflicts by Valentine's Day (Monday, February 14th). The goal for FC4test1 is to "get something out there" - it may not be fully baked, but it does need to pass basic sanity tests, be able to install and avoid killing people's systems. One of the ways non-developers can help is by trying to install from rawhide and yelling loudly about any showstopper (i.e. hard disk-destroying) problems. I'm not yet sure whether we'll have PowerPC included - it would help to have someone from that team give a summary of the status of rawhide on that arch. Cheers, -- Elliot From roland at redhat.com Fri Feb 4 21:32:47 2005 From: roland at redhat.com (Roland McGrath) Date: Fri, 4 Feb 2005 13:32:47 -0800 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: Elliot Lee's message of Friday, 4 February 2005 16:29:41 -0500 Message-ID: <200502042132.j14LWlbE024854@magilla.sf.frob.com> > I would fall in love with you all over again if you did your part to make > sure the tree was installable and free of broken dependencies & conflicts Start with up2date putting all its rhn hooey modules into firstboot. From pnasrat at redhat.com Fri Feb 4 21:44:19 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 04 Feb 2005 16:44:19 -0500 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: References: Message-ID: <1107553484.21612.8.camel@minimumble.lab.boston.redhat.com> On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote: > Yes, it's that time again... > > I'm not yet sure whether we'll have PowerPC included - it would help to > have someone from that team give a summary of the status of rawhide on > that arch. I'll do some installs over the weekend and report back on Monday. Paul From dpaun at rogers.com Fri Feb 4 22:12:56 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Fri, 4 Feb 2005 17:12:56 -0500 Subject: Fedora Core 3 (4?) Live CD Message-ID: <20050204221256.GB11004@rogers.com> Hi folks, I was looking the other day for a Fedora Live CD, but couldn't find anything out there. For whatever reason, I thought FC3 had a Live CD... Am I missing something? If not, any plans to have one for FC4? -- Dimi. From paul at all-the-johnsons.co.uk Fri Feb 4 22:13:57 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 04 Feb 2005 22:13:57 +0000 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: References: Message-ID: <1107555238.12421.9.camel@localhost.localdomain> Hi, > The goal for FC4test1 is to "get something out there" - it may not be > fully baked, but it does need to pass basic sanity tests, be able to > install and avoid killing people's systems. One of the ways non-developers > can help is by trying to install from rawhide and yelling loudly about any > showstopper (i.e. hard disk-destroying) problems. Does dependency fails count? I have one blocking openoffice, one blocking evolution and the well reported nautilus-media one. And for those using a laptop, the classic... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145923 where the laptop keypad-mouse goes insane with all kernels post 1105_FC4 TTFN Paul P.S. kgpg is still broken. -- "I don't know how World War III will be fought, but I do know World War IV will be fought with sticks and stones" - Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rms at 1407.org Fri Feb 4 21:54:25 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 04 Feb 2005 21:54:25 +0000 Subject: Please, help me with at76c503a and recent Linux packages... Message-ID: <1107554065.3512.9.camel@roque> Hi, I've been making RPMS for my machine of at76c503a and have recently sent upstream a patch for rpm making. However, I have a huge problem that's bound to get worse without help, and I know little of kernel module building to understand the problem. I'm running Fedora Core (from the development rawhide tree), so this problem will be happening on FC4... quite likely. When I load the module with Linux 2.6.10-1.1090_FC4, I see the following: Feb 4 21:37:21 roque kernel: usb 3-2: new full speed USB device using uhci_hcd and address 2 Feb 4 21:37:22 roque modprobe: WARNING: Could not open '/lib/modules/2.6.10-1.1090_FC4/kernel/drivers/net/wireless/at76c503/at76_usbdfu.ko': No such file or directory Feb 4 21:37:22 roque modprobe: WARNING: Could not open '/lib/modules/2.6.10-1.1090_FC4/kernel/drivers/net/wireless/at76c503/at76c503.ko': No such file or directory Feb 4 21:37:22 roque modprobe: FATAL: Could not open '/lib/modules/2.6.10-1.1090_FC4/kernel/drivers/net/wireless/at76c503/at76c505-rfmd2958.ko': No such file or directory Ah... I forgot to rebuild with lower kernel again... so I disconnect, rebuild for the older Linux again, and put it in again: Feb 4 21:37:28 roque kernel: usb 3-2: USB disconnect, address 2 Feb 4 21:38:23 roque kernel: usb 3-2: new full speed USB device using uhci_hcd and address 3 Feb 4 21:38:24 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76_usbdfu.c: USB Device Firmware Upgrade (DFU) handler v0.12beta22-static loading Feb 4 21:38:24 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503.c: Generic Atmel at76c503/at76c505 routines v0.12beta22-static Feb 4 21:38:24 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503-fw_skel.c: Atmel at76c505 (RFMD 2958) Wireless LAN Driver v0.12beta22-static loading Feb 4 21:38:24 roque kernel: usbcore: registered new driver at76c505-rfmd2958 Feb 4 21:38:26 roque kernel: usb 3-2: reset full speed USB device using uhci_hcd and address 3 Feb 4 21:38:26 roque kernel: usb 3-2: device firmware changed Feb 4 21:38:26 roque kernel: usb 3-2: USB disconnect, address 3 Feb 4 21:38:26 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503-fw_skel.c: wlan%d disconnecting Feb 4 21:38:26 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503-fw_skel.c: at76c505-rfmd2958 disconnected Feb 4 21:38:26 roque kernel: usb 3-2: new full speed USB device using uhci_hcd and address 4 Feb 4 21:38:27 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503.c: $Id: at76c503.c,v 1.72 2004/10/19 20:45:25 jal2 Exp $ compiled Jan 23 2005 15:37:23 Feb 4 21:38:27 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503.c: firmware version 1.101.0 #86 (fcs_len 4) Feb 4 21:38:27 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503.c: device's MAC 00:11:3b:03:9d:dc, regulatory domain ETSI (Europe - (Spain+France) (id 48)Feb 4 21:38:27 roque kernel: /home/builder/redhat/BUILD/at76c503a/at76c503.c: registered wlan0 So all this works, ok? Now... lets go to Linux 2.6.10-1.1124_FC4 Feb 4 21:33:30 roque kernel: usb 3-2: new full speed USB device using uhci_hcd and address 2 Feb 4 21:33:31 roque modprobe: WARNING: Error inserting at76_usbdfu (/lib/modules/2.6.10-1.1124_FC4/kernel/drivers/net/wireless/at76c503/at76_usbdfu.ko): Invalid module format Feb 4 21:33:31 roque modprobe: WARNING: Error inserting at76c503 (/lib/modules/2.6.10-1.1124_FC4/kernel/drivers/net/wireless/at76c503/at76c503.ko): Invalid module format Feb 4 21:33:31 roque modprobe: FATAL: Error inserting at76c505_rfmd2958 (/lib/modules/2.6.10-1.1124_FC4/kernel/drivers/net/wireless/at76c503/at76c505-rfmd2958.ko): Invalid module format Feb 4 21:33:31 roque kernel: at76_usbdfu: version magic '2.6.10-1.1124_FC4 686 REGPARM 4KSTACKS gcc-3.4' should be '2.6.10-1.1124_FC4 586 REGPARM 4KSTACKS gcc-3.4' Feb 4 21:33:31 roque kernel: at76c503: version magic '2.6.10-1.1124_FC4 686 REGPARM 4KSTACKS gcc-3.4' should be '2.6.10-1.1124_FC4 586 REGPARM 4KSTACKS gcc-3.4' Feb 4 21:33:31 roque kernel: at76c505_rfmd2958: version magic '2.6.10-1.1124_FC4 686 REGPARM 4KSTACKS gcc-3.4' should be '2.6.10-1.1124_FC4 586 REGPARM 4KSTACKS gcc-3.4' Feb 4 21:33:31 roque usb.agent[4293]: ... can't load module at76c505-rfmd2958 Feb 4 21:33:31 roque usb.agent[4293]: missing kernel or user mode driver at76c505-rfmd2958 So you see, it _is_bad_ but I can't find a way to solve this... Any 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 rms at 1407.org Fri Feb 4 22:41:28 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 04 Feb 2005 22:41:28 +0000 Subject: Please, help me with at76c503a and recent Linux packages... In-Reply-To: <1107554065.3512.9.camel@roque> References: <1107554065.3512.9.camel@roque> Message-ID: <1107556889.3515.1.camel@roque> I feel embarassed... On Fri, 2005-02-04 at 21:54 +0000, Rui Miguel Seabra wrote: > Feb 4 21:33:31 roque kernel: at76_usbdfu: version magic > '2.6.10-1.1124_FC4 686 REGPARM 4KSTACKS gcc-3.4' should be > '2.6.10-1.1124_FC4 586 REGPARM 4KSTACKS gcc-3.4' The i586 should have been a dead give away. Thank you guys @ #fedora-devel!!! Note to Seth: yum somehow siletly upgraded my i686 Linux to an i586 one... Regards, 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 mattdm at mattdm.org Fri Feb 4 22:42:45 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 4 Feb 2005 17:42:45 -0500 Subject: Firefox not starting properly In-Reply-To: <20050204095836.GA29746@dudweiler.stuttgart.redhat.com> References: <1107492531.3363.2.camel@trevally.redfishdemo.com> <20050204095836.GA29746@dudweiler.stuttgart.redhat.com> Message-ID: <20050204224245.GA29343@jadzia.bu.edu> On Fri, Feb 04, 2005 at 10:58:36AM +0100, Florian La Roche wrote: > I've downgraded to the previous version without language > packs and that works fine for me. Bugzilla on this one is > open AFAIK. Yeah. Bug #145806: -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From esr at thyrsus.com Fri Feb 4 22:42:24 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 4 Feb 2005 17:42:24 -0500 Subject: x86_64 in FC4? In-Reply-To: References: Message-ID: <20050204224224.GD19669@thyrsus.com> Elliot Lee : > I'm not yet sure whether we'll have PowerPC included - it would help to > have someone from that team give a summary of the status of rawhide on > that arch. I just got an Opteron box. It would be real nice if the FC4 test 1 disks included 64-bit kernel RPMS and a handful of 64-bit builds for the most speed-critical stuff (Perl & Python interpreters, Open Office, etc.). -- Eric S. Raymond From gauret at free.fr Fri Feb 4 22:50:09 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 04 Feb 2005 23:50:09 +0100 Subject: SSL certificate management/storage References: <20050204162512.GA23731@redhat.com> Message-ID: Joe Orton wrote: > 1. certificate storage is split between /etc/httpd/conf/ssl.* > for mod_ssl-specific stuff, and and /usr/share/ssl for system-wide > 2. ... and /usr/share/ssl is Very Wrong for "config data" like certs > 3. increasing number of daemon packages are creating self-signed > certs in %post scripts; could/should this be unified? For what it's worth, Debian puts its certs in /etc/ssl/certs. There may be a problem with apache accessing files in /etc/ssl because of SELinux, but I don't know much about SELinux yet. Having the contents of /usr/share/ssl in /etc would be nice, since it's mainly config files (except the scripts). Regards, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info No, I coded it crappily on purpose, just so that I could say "There's plenty of room for optimization." From cturner at redhat.com Fri Feb 4 22:55:42 2005 From: cturner at redhat.com (Chip Turner) Date: Fri, 04 Feb 2005 17:55:42 -0500 Subject: x86_64 in FC4? In-Reply-To: <20050204224224.GD19669@thyrsus.com> (Eric S. Raymond's message of "Fri, 4 Feb 2005 17:42:24 -0500") References: <20050204224224.GD19669@thyrsus.com> Message-ID: "Eric S. Raymond" writes: > Elliot Lee : >> I'm not yet sure whether we'll have PowerPC included - it would help to >> have someone from that team give a summary of the status of rawhide on >> that arch. > > I just got an Opteron box. It would be real nice if the FC4 test 1 disks > included 64-bit kernel RPMS and a handful of 64-bit builds for the most > speed-critical stuff (Perl & Python interpreters, Open Office, etc.). That's assuming 64bit is faster than 32bit... which it isn't necessarily. But even if it were, you don't want a 64bit version of perl and python on a mostly 32bit box. Trust me; you don't want to mix 32 and 64 with those languages. Either you end up with a rats nest of other 64 bit apps (vim, xchat, gaim, mod_perl, apache -- after all, those link against perl and/or python, and that means they have to be 64bit also) or you end up trying somehow to get both a 64bit and a 32bit perl on the same box (which means maintaining each CPAN module in two places, etc). Madness in both directions. Install the full 64bit distro if you want 64bit, otherwise stick with 32bit. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From walters at redhat.com Fri Feb 4 22:57:35 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 04 Feb 2005 17:57:35 -0500 Subject: x86_64 in FC4? In-Reply-To: <20050204224224.GD19669@thyrsus.com> References: <20050204224224.GD19669@thyrsus.com> Message-ID: <1107557855.16306.1.camel@nexus.verbum.private> On Fri, 2005-02-04 at 17:42 -0500, Eric S. Raymond wrote: > Elliot Lee : > > I'm not yet sure whether we'll have PowerPC included - it would help to > > have someone from that team give a summary of the status of rawhide on > > that arch. > > I just got an Opteron box. It would be real nice if the FC4 test 1 disks > included 64-bit kernel RPMS and a handful of 64-bit builds for the most > speed-critical stuff (Perl & Python interpreters, Open Office, etc.). It looks to me like Python and Perl are already both 64-bit executables in FC3. Open Office is a huge amount of work; I think Dan Williams was doing some on it, but my impression was it was still fairly far away. From czar at czarc.net Fri Feb 4 23:05:14 2005 From: czar at czarc.net (Gene C.) Date: Fri, 4 Feb 2005 18:05:14 -0500 Subject: x86_64 in FC4? In-Reply-To: <20050204224224.GD19669@thyrsus.com> References: <20050204224224.GD19669@thyrsus.com> Message-ID: <200502041805.14706.czar@czarc.net> On Friday 04 February 2005 17:42, Eric S. Raymond wrote: > Elliot Lee : > > I'm not yet sure whether we'll have PowerPC included - it would help to > > have someone from that team give a summary of the status of rawhide on > > that arch. > > I just got an Opteron box. ?It would be real nice if the FC4 test 1 disks > included 64-bit kernel RPMS and a handful of 64-bit builds for the most > speed-critical stuff (Perl & Python interpreters, Open Office, etc.). Yes, I have an Opteron system also and have been impressed with its relative performance (even with my Opteron 140). For FC2 and FC3, the x86_64 has been a fully "tier 1" "supported" architecture and I would expect this to continue with FC4 [FC1 was also supported but just a bit later]. The folks behind Fedora Core are trying to pick architectures for which there are a large number of potential users. Thus, you have i386 (i586 and i686), x86_64, and (maybe) the ppc. For x86_64, almost all of the packages are built as x86_64 (not just the kernel and a few other packages). Included are some i386 packages since the system supports dual mode running of 32 bit or 64 bit applications and there are a few applications (notably openoffice.org) that are still 32 bit only. -- Gene From nalin at redhat.com Fri Feb 4 23:25:21 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 4 Feb 2005 18:25:21 -0500 Subject: SSL certificate management/storage In-Reply-To: References: <20050204162512.GA23731@redhat.com> Message-ID: <20050204232521.GB31894@redhat.com> On Fri, Feb 04, 2005 at 11:50:09PM +0100, Aurelien Bompard wrote: > Joe Orton wrote: > > 1. certificate storage is split between /etc/httpd/conf/ssl.* > > for mod_ssl-specific stuff, and and /usr/share/ssl for system-wide > > 2. ... and /usr/share/ssl is Very Wrong for "config data" like certs > > 3. increasing number of daemon packages are creating self-signed > > certs in %post scripts; could/should this be unified? > > For what it's worth, Debian puts its certs in /etc/ssl/certs. > There may be a problem with apache accessing files in /etc/ssl because of > SELinux, but I don't know much about SELinux yet. > > Having the contents of /usr/share/ssl in /etc would be nice, since it's > mainly config files (except the scripts). I agree with moving the files from /usr to /etc. The specific name isn't all that important (though I suspect it'll make for some lively debate -- "but certificates aren't SSL-specific, so call it 'certs'!" "but I don't keep my OpenPGP certificates there, so call it 'ssl'!" "oh, just call it 'pki' already!") The main concern in my mind is making sure that applications which explicitly configure OpenSSL to look in particular locations don't suddently break if/when the set of trusted CA certs is moved, and that the location to where they're being moved is well-known, so that things don't get more confusing in the process. If we stash a symlink in /usr/share/ssl, then packages can move to the using/referencing the new location on a case-by-case basis, with the plan being to get them all switched over in Raw Hide before some to-be-determined date. I guess that leaves the naming debate. I propose we move this stuff to "/etc/x509-certificates-and-corresponding-private-keys-and-other-related-files". Cheers, Nalin From nalin at redhat.com Fri Feb 4 23:33:18 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 4 Feb 2005 18:33:18 -0500 Subject: SSL certificate management/storage In-Reply-To: <20050204162512.GA23731@redhat.com> References: <20050204162512.GA23731@redhat.com> Message-ID: <20050204233318.GC31894@redhat.com> On Fri, Feb 04, 2005 at 04:25:12PM +0000, Joe Orton wrote: > 3. increasing number of daemon packages are creating self-signed > certs in %post scripts; could/should this be unified? Whatever process (right now, I think it's usually a shell snippet we copy from %post to %post) we use for generating them could definitely stand to be cleaned up. Those self-signed certificiates are becoming less and less useful as applications move toward properly verifying certificates. Factoring that shared %post chunk down to a single command would at least make it easier to change what happens later on, if/when a better option becomes available. Cheers, Nalin From esr at thyrsus.com Fri Feb 4 23:34:45 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 4 Feb 2005 18:34:45 -0500 Subject: x86_64 in FC4? In-Reply-To: <200502041805.14706.czar@czarc.net> References: <20050204224224.GD19669@thyrsus.com> <200502041805.14706.czar@czarc.net> Message-ID: <20050204233445.GB20362@thyrsus.com> Gene C. : > Yes, I have an Opteron system also and have been impressed with its relative > performance (even with my Opteron 140). Indeed. I have a single Opteron 3400 that is cranking a measured 1.65 times better performance than my previous machine on doclifter, my monster Python app -- which doesn't sound impressive until you consider that the previous machine was a 2-processor SMP with 1.8GHz Athlons. So my real-world throughput is as good or (allowing for Amdahl's Law inefficiencies) better than what I'd get from a 6 GHz Athlon, if such a thing existed. > The folks behind Fedora Core are trying to pick architectures > for which there are a large number of potential users. Thus, you have i386 > (i586 and i686), x86_64, and (maybe) the ppc. That should do it. I expect the PPC to rise in importance rapidly over the next two years, but I don't see anything other than x86_32, x86_64 and PPC achieving significant market share. -- Eric S. Raymond From roland at redhat.com Fri Feb 4 23:38:14 2005 From: roland at redhat.com (Roland McGrath) Date: Fri, 4 Feb 2005 15:38:14 -0800 Subject: x86_64 in FC4? In-Reply-To: Eric S. Raymond's message of Friday, 4 February 2005 18:34:45 -0500 <20050204233445.GB20362@thyrsus.com> Message-ID: <200502042338.j14NcEHN025071@magilla.sf.frob.com> Unlike other architectures with 32-bit and 64-bit flavors, where the biggest change in 64-bit binaries is using twice as much space for a lot of things, the x86-64 architecture also has twice as many registers as the 32-bit x86 and so 64-bit compiled code tends to perform noticeably better. From cturner at redhat.com Fri Feb 4 23:45:52 2005 From: cturner at redhat.com (Chip Turner) Date: Fri, 04 Feb 2005 18:45:52 -0500 Subject: x86_64 in FC4? In-Reply-To: <200502042338.j14NcEHN025071@magilla.sf.frob.com> (Roland McGrath's message of "Fri, 4 Feb 2005 15:38:14 -0800") References: <200502042338.j14NcEHN025071@magilla.sf.frob.com> Message-ID: Roland McGrath writes: > Unlike other architectures with 32-bit and 64-bit flavors, where the > biggest change in 64-bit binaries is using twice as much space for a lot of > things, the x86-64 architecture also has twice as many registers as the > 32-bit x86 and so 64-bit compiled code tends to perform noticeably better. Aren't those registers available to 32bit apps, though, should the compiler choose to make use of them? Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From roland at redhat.com Fri Feb 4 23:48:11 2005 From: roland at redhat.com (Roland McGrath) Date: Fri, 4 Feb 2005 15:48:11 -0800 Subject: x86_64 in FC4? In-Reply-To: Chip Turner's message of Friday, 4 February 2005 18:45:52 -0500 Message-ID: <200502042348.j14NmBHN025108@magilla.sf.frob.com> > Aren't those registers available to 32bit apps, though, should the > compiler choose to make use of them? No. From esr at thyrsus.com Sat Feb 5 00:03:47 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 4 Feb 2005 19:03:47 -0500 Subject: x86_64 in FC4? In-Reply-To: <1107560637.31589.10.camel@prospect.inetint.com> References: <1107560637.31589.10.camel@prospect.inetint.com> Message-ID: <20050205000347.GA21368@thyrsus.com> eli.carter at exgate.tek.com : > > Indeed. I have a single Opteron 3400 that is cranking a measured 1.65 > > times better performance than my previous machine on doclifter, my > > monster Python app -- which doesn't sound impressive until you > > consider that the previous machine was a 2-processor SMP with 1.8GHz > > Athlons. So my real-world throughput is as good or (allowing for > > Amdahl's Law inefficiencies) better than what I'd get from a 6 GHz > > Athlon, if such a thing existed. > > I was under the impression that the Python interpreter was serialized > and thus unable to take good advantage of SMP systems. > If that's the case, then you'd only be getting one of those 1.8GHz > processors beating on 'doclifter'... and if that's the case, you'd be > looking at a 3GHz Althon instead of 6GHz. Hmm...you're probably mostly right about this. The Python app would get some gain from background daemons and X traffic migrating to the other processor, though. -- Eric S. Raymond From tadams-lists at myrealbox.com Sat Feb 5 02:02:37 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Fri, 04 Feb 2005 19:02:37 -0700 Subject: x86_64 in FC4? In-Reply-To: References: <200502042338.j14NcEHN025071@magilla.sf.frob.com> Message-ID: <1107568957.3383.5.camel@localhost.localdomain> No, to remain compatible with x86 32, you cannot add more registers without all sorts of fun problems. Also, since AMD wanted to remain perfectly 32bit compatible, no, no more registers for 32bit apps. Trever On Fri, 2005-02-04 at 18:45 -0500, Chip Turner wrote: > Roland McGrath writes: > > > Unlike other architectures with 32-bit and 64-bit flavors, where the > > biggest change in 64-bit binaries is using twice as much space for a lot of > > things, the x86-64 architecture also has twice as many registers as the > > 32-bit x86 and so 64-bit compiled code tends to perform noticeably better. > > Aren't those registers available to 32bit apps, though, should the > compiler choose to make use of them? > > Chip > > -- > Chip Turner cturner at redhat.com > Red Hat, Inc. > -- "Magazines all too frequently lead to books and should be regarded by the prudent as the heavy petting of literature." -- Fran Lebowitz From rgammon at real.com Sat Feb 5 02:10:32 2005 From: rgammon at real.com (Ryan Gammon) Date: Fri, 04 Feb 2005 18:10:32 -0800 Subject: Sharing sound hardware Message-ID: <42042B18.2090207@real.com> Hi guys, I've been catching up on my mailing list reading on fedora, helix, and general sound server interaction, and saw a couple threads of interest from late last year. I'm curious to know what the current fedora thinking is on software mixing & sharing sound hardware, particularly with sound devices that don't have any hardware mixing support. From where I'm sitting, there's some appeal to the alsa asym / dmix solution that I've seen discussed. The alsa api, while pretty complex, gives good access to all the features a given piece of hardware supports. The fact that alsa has an awareness of the hardware it's running on gives it the ability to (eventually) be smarter when it comes to things like mixing in hardware vs mixing in software. I did some playing around with dmix last year when I was touching up helix's alsa support, and found it to be pretty buggy on the alsa side. Some of this may be incorrect, but as I recall: 1. libasound forks what is basically a sound server process when the sound device is first accessed, but it does not exec. This was not working well with helix -- by the time helix opens the sound device, it has several threads running and a number of plugins loaded. Alsa's mixer process was hanging when forked from helix, for reasons I never figured out. 2. Pausing was generally broken 3. The first process to play back sound defines the characteristics of the sound device device. If it open up the device at a low sample rate, all playback would suffer. 4. Decent alsa documentation was generally lacking. At the time, I fooled around with using esound + alsa + dmix, with esound set up to always hold the sound device open, and with the alsa sound server running in a forked esound process. http://bugzilla.gnome.org/show_bug.cgi?id=140803 http://sourceforge.net/mailarchive/message.php?msg_id=8898607 Currently, the helix we ship with RealPlayer 10 is built to use OSS, as it's generally the lowest common denominator. We rely on sound servers like esound releasing the sound device when not in use. In terms of what we currently support in helix on linux we have: - OSS support - Esound support (works for audio only, not usable for good quality AV playback) - Usound support (contributed by Matt Campbell, http://mattcamp.paunix.org/usound/) - ALSA support ... of which we're only shipping OSS. Ideally IMHO dmix / asym would: - Be a sound server that runs on startup instead of something that forks off the first process to open the sound device - Open the sound device using sensible maximum capabilities of the device in terms of sampling rate and # of channels, etc. The guys who write our resamplers generally prefer to have helix doing any sample rate conversion where possible: http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/000243.html - Have good sound latency information, enabling good AV sync - Be generally solid in terms of pausing & restarting playback - Be documented :) I'm very interested in what others are thinking here for fedora, be it alsa-related or otherwise. -- Ryan Gammon rgammon at real.com Developer for Helix Player https://player.helixcommunity.org From cra at WPI.EDU Sat Feb 5 04:00:10 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 4 Feb 2005 23:00:10 -0500 Subject: Please, help me with at76c503a and recent Linux packages... In-Reply-To: <1107556889.3515.1.camel@roque> References: <1107554065.3512.9.camel@roque> <1107556889.3515.1.camel@roque> Message-ID: <20050205040009.GA18917@angus.ind.WPI.EDU> On Fri, Feb 04, 2005 at 10:41:28PM +0000, Rui Miguel Seabra wrote: > Note to Seth: yum somehow siletly upgraded my i686 Linux to an i586 > one... Do you have exactarch=1 set in your yum.conf? From skvidal at phy.duke.edu Sat Feb 5 04:07:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Feb 2005 23:07:03 -0500 Subject: Please, help me with at76c503a and recent Linux packages... In-Reply-To: <20050205040009.GA18917@angus.ind.WPI.EDU> References: <1107554065.3512.9.camel@roque> <1107556889.3515.1.camel@roque> <20050205040009.GA18917@angus.ind.WPI.EDU> Message-ID: <1107576423.8961.5.camel@cutter> On Fri, 2005-02-04 at 23:00 -0500, Charles R. Anderson wrote: > On Fri, Feb 04, 2005 at 10:41:28PM +0000, Rui Miguel Seabra wrote: > > Note to Seth: yum somehow siletly upgraded my i686 Linux to an i586 > > one... > > Do you have exactarch=1 set in your yum.conf? Another note - don't expect me to read every single message that comes across f-d-l :) if you think you've found a bug, let me know in bugzilla. :) -sv From skvidal at phy.duke.edu Sat Feb 5 05:12:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 00:12:02 -0500 Subject: Including udftools In-Reply-To: <20050204105818.22b8a5ae@python2> References: <20050204105818.22b8a5ae@python2> Message-ID: <1107580322.8961.36.camel@cutter> On Fri, 2005-02-04 at 10:58 +0100, Matthias Saou wrote: > Hi, > > I just received this email about udftools : > Matthias: only two question: why not put this on fedora-extras-list? any reticence on your part for bringing it in? -sv From skvidal at phy.duke.edu Sat Feb 5 08:17:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 03:17:43 -0500 Subject: repoclosure.py Message-ID: <1107591464.8961.77.camel@cutter> Hey, I just wrote a script using the yum modules to check to see if a set of repositories have dependency closure for all packages in the repositories. it's very simple and obvious but it has some nice results: I ran: cutter:~$ python ./repoclosure.py development Not running a root, might not be able to import all of cache Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 development Num Packages in Repos: 2663 package: openoffice.org - 1.1.3-2.7.i386 from development unresolved deps: libedataserver.so.3 libebook.so.8 package: gnome-python2-nautilus - 2.6.0-5.i386 from development unresolved deps: libnautilus.so.2 package: struts11-webapps-tomcat5 - 1.1-1jpp_2fc.noarch from development unresolved deps: tomcat5 package: nautilus-media - 0.8.1-4.i386 from development unresolved deps: libnautilus.so.2 package: evolution-connector - 2.0.3-1.i386 from development unresolved deps: libcamel.so.0 libedata-book.so.1 libedata-cal.so.5 libedataserver.so.3 libgal-a11y-2.2.so.1 libgal-2.2.so.1 libebook.so.8 libecal.so.6 so that's kinda cool b/c now we know what packages simply aren't going to resolve out in development right now if you tried to install or update to them. http://linux.duke.edu/yum/download/misc/repoclosure.py I think it works okay, it seems to at least :) You run it like: repoclosure.py repoid repoid repoid or if you want it to check your default repositories that you have enabled in your yum configuration then just run: repoclosure.py You need to have yum 2.1.13 installed to really test it. The only other thing you might want to do is either: 1. run repoclosure.py as root 2. run yum makecache as root with the repositories you want to use enabled. thanks, -sv From mpeters at mac.com Sat Feb 5 08:48:36 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 05 Feb 2005 08:48:36 +0000 Subject: Fedora Core 3 (4?) Live CD In-Reply-To: <20050204221256.GB11004@rogers.com> (from dpaun@rogers.com on Fri Feb 4 14:12:56 2005) References: <20050204221256.GB11004@rogers.com> Message-ID: <1107593316l.6367l.0l@devel.mpeters.us> On 02/04/2005 02:12:56 PM, Dimitrie O. Paun wrote: > Hi folks, > > I was looking the other day for a Fedora Live CD, but couldn't > find anything out there. For whatever reason, I thought FC3 > had a Live CD... Am I missing something? If not, any plans to > have one for FC4? Someone made one for FC3 - but it was not official. I do not remember who it was, but it was posted to this list - so *maybe* googling the list archive will find it. From livelinux at nwst.de Sat Feb 5 09:40:20 2005 From: livelinux at nwst.de (livelinux at nwst.de) Date: Sat, 05 Feb 2005 10:40:20 +0100 Subject: Fedora Core 3 (4?) Live CD In-Reply-To: <20050204221256.GB11004@rogers.com> References: <20050204221256.GB11004@rogers.com> Message-ID: <42049484.6030901@nwst.de> Hello, Dimitrie O. Paun schrieb: > Hi folks, > > I was looking the other day for a Fedora Live CD, but couldn't > find anything out there. For whatever reason, I thought FC3 > had a Live CD... Am I missing something? If not, any plans to > have one for FC4? > This might be for you: a fedora core 3 with gnome/kde and kernel 2.6.8 http://www.linux4all.de/livecd/basilisk/1.40/ It uses an zisofs compressed filesystem image instead of cloop, so no modifications to the fedora kernel are required. I`m currently working on a modified version of anaconda so every fedora/redhat user can create custom livecd`s using a gui/wizard to control the installation and build. The installer and livecd creation process is compatible with the lvm - snapshot method from fedora-stateless. All(or at least most) modifications to the system that will go into the livecd are done by a set of rpm packages. Screenshots & snapshots (unsigned fc3 rpm) can be found here: http://www.linux4all.de/livecd/livecdanaconda ('livecdanaconda' is just the working term, so the package can be installed independently from the original anaconda packages and to separate class/function namespaces.) The current development target for this installer is a first full working version for fedora core 4. Perhaps there are also other interested parties ? Best regards, Dirk Westfal -- fedora core 3 livecd: http://www.linux4all.de From mpeters at mac.com Sat Feb 5 09:29:08 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 05 Feb 2005 09:29:08 +0000 Subject: repoclosure.py In-Reply-To: <1107591464.8961.77.camel@cutter> (from skvidal@phy.duke.edu on Sat Feb 5 00:17:43 2005) References: <1107591464.8961.77.camel@cutter> Message-ID: <1107595748l.6367l.1l@devel.mpeters.us> On 02/05/2005 12:17:43 AM, seth vidal wrote: > > I think it works okay, it seems to at least :) *snip* package: httpd - 2.0.52-3.1.i386 from updates-released unresolved deps: /usr/share/magic.mime package: libxml2-python - 2.6.16-3.i386 from updates-released unresolved deps: /usr/lib/python2.3 package: openmotif - 2.2.3-6.FC3.1.i386 from updates-released unresolved deps: /usr/X11R6/lib/X11/XKeysymDB [root at devel bin]# rpm -qf /usr/share/magic.mime file-4.12-1.FC3.1 You have new mail in /var/spool/mail/mpeters [root at devel bin]# rpm -qf /usr/share/magic.mime file-4.12-1.FC3.1 [root at devel bin]# rpm -qf /usr/lib/python2.3 python-2.3.4-11 [root at devel bin]# rpm -qf /usr/X11R6/lib/X11/XKeysymDB xorg-x11-libs-6.8.1-12.FC3.21 [root at devel bin]# :shrug: From iago.rubio at hispalinux.es Sat Feb 5 09:44:58 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Sat, 05 Feb 2005 10:44:58 +0100 Subject: SSL certificate management/storage In-Reply-To: <20050204233318.GC31894@redhat.com> References: <20050204162512.GA23731@redhat.com> <20050204233318.GC31894@redhat.com> Message-ID: <1107596698.11240.785.camel@speedy.iagorubio.net> On Sat, 2005-02-05 at 00:33, Nalin Dahyabhai wrote: > On Fri, Feb 04, 2005 at 04:25:12PM +0000, Joe Orton wrote: > > 3. increasing number of daemon packages are creating self-signed > > certs in %post scripts; could/should this be unified? [snip] > Those self-signed certificiates are becoming less and less useful as > applications move toward properly verifying certificates. Could be a problem to assume this, as self-signed certificates does not require a CA - that'll pick some bucks from you to sign your certificates - and it's sure self-signed certificates will be hanging around for a while, because they're cheaper than CA signed ones. Even in web servers self-signed certificates are being deployed, despite the browser certificate error dialogs that are show when you visit those web sites. Regards. -- Iago Rubio From rhally at mindspring.com Sat Feb 5 10:18:21 2005 From: rhally at mindspring.com (Richard Hally) Date: Sat, 05 Feb 2005 05:18:21 -0500 Subject: repoclosure.py In-Reply-To: <1107591464.8961.77.camel@cutter> References: <1107591464.8961.77.camel@cutter> Message-ID: <42049D6D.9090205@mindspring.com> seth vidal wrote: >Hey, > I just wrote a script using the yum modules to check to see if a set of >repositories have dependency closure for all packages in the >repositories. > >it's very simple and obvious but it has some nice results: >I ran: > >cutter:~$ python ./repoclosure.py development >Not running a root, might not be able to import all of cache >Reading in repository metadata - please wait.... >Checking Dependencies >Repos looked at: 1 > development >Num Packages in Repos: 2663 >package: openoffice.org - 1.1.3-2.7.i386 from development > unresolved deps: > libedataserver.so.3 > libebook.so.8 >package: gnome-python2-nautilus - 2.6.0-5.i386 from development > unresolved deps: > libnautilus.so.2 >package: struts11-webapps-tomcat5 - 1.1-1jpp_2fc.noarch from development > unresolved deps: > tomcat5 >package: nautilus-media - 0.8.1-4.i386 from development > unresolved deps: > libnautilus.so.2 >package: evolution-connector - 2.0.3-1.i386 from development > unresolved deps: > libcamel.so.0 > libedata-book.so.1 > libedata-cal.so.5 > libedataserver.so.3 > libgal-a11y-2.2.so.1 > libgal-2.2.so.1 > libebook.so.8 > libecal.so.6 > >so that's kinda cool b/c now we know what packages simply aren't going >to resolve out in development right now if you tried to install or >update to them. > >http://linux.duke.edu/yum/download/misc/repoclosure.py > >I think it works okay, it seems to at least :) > >You run it like: >repoclosure.py repoid repoid repoid > >or if you want it to check your default repositories that you have >enabled in your yum configuration then just run: >repoclosure.py > >You need to have yum 2.1.13 installed to really test it. > >The only other thing you might want to do is either: > 1. run repoclosure.py as root > 2. run yum makecache as root with the repositories you want to use >enabled. > >thanks, >-sv > > > > > > > That's neat!! thanks, Now if we can only get someone to use it to prod the people responsible for fixing the "unresolved deps" fixed. Richard From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Feb 5 10:20:10 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 5 Feb 2005 11:20:10 +0100 Subject: repoclosure.py In-Reply-To: <1107595748l.6367l.1l@devel.mpeters.us> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> Message-ID: <20050205112010.6ad8d463@python2> Michael A. Peters wrote : > On 02/05/2005 12:17:43 AM, seth vidal wrote: > > > > > I think it works okay, it seems to at least :) > > *snip* > package: httpd - 2.0.52-3.1.i386 from updates-released > unresolved deps: > /usr/share/magic.mime > package: libxml2-python - 2.6.16-3.i386 from updates-released > unresolved deps: > /usr/lib/python2.3 > package: openmotif - 2.2.3-6.FC3.1.i386 from updates-released > unresolved deps: > /usr/X11R6/lib/X11/XKeysymDB Well, seems like it only processes file dependencies on the "basic" ones (i.e. *bin/* etc.) from the metadata, so you just got a few false positives, nothing dramatic for a quick script ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.09 0.10 0.10 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Feb 5 10:23:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 5 Feb 2005 11:23:52 +0100 Subject: Including udftools In-Reply-To: <1107580322.8961.36.camel@cutter> References: <20050204105818.22b8a5ae@python2> <1107580322.8961.36.camel@cutter> Message-ID: <20050205112352.3ed22a38@python2> seth vidal wrote : > On Fri, 2005-02-04 at 10:58 +0100, Matthias Saou wrote: > > Hi, > > > > I just received this email about udftools : > > Matthias: > only two question: > why not put this on fedora-extras-list? > any reticence on your part for bringing it in? Two answers ;-) - Because I think it's a package for Core - Nope, I could package it for Extras for now, and let someone take it later on to include it into Core I was just asking in case some RH developer was already planning on putting it in now that the shipped kernel supports packet writing. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.47 0.23 0.14 From Nicolas.Mailhot at laPoste.net Sat Feb 5 10:24:24 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 05 Feb 2005 11:24:24 +0100 Subject: repoclosure.py In-Reply-To: <20050205112010.6ad8d463@python2> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> Message-ID: <1107599064.21712.0.camel@rousalka.dyndns.org> Le samedi 05 f?vrier 2005 ? 11:20 +0100, Matthias Saou a ?crit : > Well, seems like it only processes file dependencies on the "basic" ones > (i.e. *bin/* etc.) from the metadata, so you just got a few false > positives, nothing dramatic for a quick script ;-) Well now you only need to hook it on the rawhide status message with auto cc to the maintainers of broken packages. 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 rbultje at ronald.bitfreak.net Sat Feb 5 10:49:32 2005 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Sat, 05 Feb 2005 11:49:32 +0100 Subject: Sharing sound hardware In-Reply-To: <42042B18.2090207@real.com> References: <42042B18.2090207@real.com> Message-ID: <1107600571.5561.122.camel@tux.lan> Hi Ryan, On Sat, 2005-02-05 at 03:10, Ryan Gammon wrote: > From where I'm sitting, there's some appeal to the alsa asym / dmix > solution that I've seen discussed. (nod here. Same seems to be true for GNOME on the Linux-side.) > 2. Pausing was generally broken Hm, do you mean the ALSA paused state? As far as I know, Dmix doesn't implement that. You're supposed to just stop playback alltogether when paused. Not ideal, admittedly, but appears to work. > 4. Decent alsa documentation was generally lacking. Kernel documentation is still lacking poorly. There's library reference API, and the server is sometimes even turned on, so they're making progress. There's no good example code documentation or programming guides. On the good side, alsamixer et al are liberally licensed, so you use those for inspiration. Note that I've faced those exact same problems, plus a lot of instability and erronous behaviour inside ALSA, and I've found ALSA to vastly improve on those fronts over the last year. > Ideally IMHO dmix / asym would: [..] > - Open the sound device using sensible maximum capabilities of the > device in terms of sampling rate and # of channels, etc. The guys who > write our resamplers generally prefer to have helix doing any sample > rate conversion where possible: > http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/000243.html Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users won't notice the difference if you're using a reasonably good resampler. On my computer (don't know if this is generally true), dmix operates on a fixed samplerate, regardless of playback. For the future, ALSA is definately the way to do. It's a pain to get fully stable, still, but it's getting better. I've ended up debugging some ALSA issues, but the result isn't too bad really. Cheers, Ronald -- Ronald S. Bultje From jwz at jwz.org Sat Feb 5 11:00:46 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 05 Feb 2005 03:00:46 -0800 Subject: SSL certificate management/storage References: <20050204162512.GA23731@redhat.com> <20050204233318.GC31894@redhat.com> <1107596698.11240.785.camel@speedy.iagorubio.net> Message-ID: <4204A75E.7BD1FC37@jwz.org> Iago Rubio wrote: > > Could be a problem to assume this, as self-signed certificates does not > require a CA - that'll pick some bucks from you to sign your > certificates - and it's sure self-signed certificates will be hanging > around for a while, because they're cheaper than CA signed ones. Absolutely -- I use pop3s (and a self-signed ssl cert) for my employees' email, and I'm sure not going to tithe anually to Verisign or whoever merely to avoid a one-time warning dialog for my dozen users. I'm sure lots of other small companies feel the same way. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From thuforuk at yahoo.co.uk Sat Feb 5 11:25:22 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Sat, 05 Feb 2005 11:25:22 +0000 Subject: Sharing sound hardware In-Reply-To: <1107600571.5561.122.camel@tux.lan> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> Message-ID: <4204AD22.8020605@yahoo.co.uk> On 02/05/2005 10:49 AM, Ronald S. Bultje wrote: > Hi Ryan, > > On Sat, 2005-02-05 at 03:10, Ryan Gammon wrote: >>Ideally IMHO dmix / asym would: > > [..] > >>- Open the sound device using sensible maximum capabilities of the >>device in terms of sampling rate and # of channels, etc. The guys who >>write our resamplers generally prefer to have helix doing any sample >>rate conversion where possible: >>http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/000243.html > > > Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users won't > notice the difference if you're using a reasonably good resampler. On my > computer (don't know if this is generally true), dmix operates on a > fixed samplerate, regardless of playback. Please, no! This sounds really bad to me (pun intended ;-) I own a card that can do hardware mixing and really don't like the idea of "being punished" for that. Especially by something like upsampling almost every sound I play from 44.1 to 48kHz. And yes, I will notice (is it really 99% of the users who won't? where does this number come from?) -- decent amplifier, cables and loudspeakers do just that: you start noticing. The reason I'm really worried here is that I recall Colin Walters saying that dmix will be on for everybody in FC4: https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00614.html Question: will there be a SIMPLE way (a script or HOWTO/FAQ would do) to turn dmix off for those whose soundcard can do hardware mixing so they can use their hardware the way it was intended to? If so, *please* include a note how to do it in Release Notes for FC4. This would make me happy enough to keep quiet even with dmix set on as default :-) Regards, Dariusz From rms at 1407.org Sat Feb 5 12:46:59 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sat, 05 Feb 2005 12:46:59 +0000 Subject: Please, help me with at76c503a and recent Linux packages... In-Reply-To: <1107576423.8961.5.camel@cutter> References: <1107554065.3512.9.camel@roque> <1107556889.3515.1.camel@roque> <20050205040009.GA18917@angus.ind.WPI.EDU> <1107576423.8961.5.camel@cutter> Message-ID: <1107607620.3515.12.camel@roque> On Fri, 2005-02-04 at 23:07 -0500, seth vidal wrote: > On Fri, 2005-02-04 at 23:00 -0500, Charles R. Anderson wrote: > > On Fri, Feb 04, 2005 at 10:41:28PM +0000, Rui Miguel Seabra wrote: > > > Note to Seth: yum somehow siletly upgraded my i686 Linux to an i586 > > > one... > > > > Do you have exactarch=1 set in your yum.conf? Yes: grep exactarch /etc/yum.conf exactarch=1 > Another note - don't expect me to read every single message that comes > across f-d-l :) hehe sorry :) > if you think you've found a bug, let me know in bugzilla. :) I wish I knew when it happened. It started happening right after linux rpm 1090. In the meanwhile, yum was updated so it might have been a temporary problem! 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 fedora-devel at camperquake.de Sat Feb 5 12:50:49 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sat, 5 Feb 2005 13:50:49 +0100 Subject: New kernels: xen config breaking rpmbuild --target noarch? In-Reply-To: <20050204191117.GE20901@neu.nirvana> References: <20050204181541.GD20901@neu.nirvana> <20050204191117.GE20901@neu.nirvana> Message-ID: <20050205135049.3332e611@nausicaa.camperquake.de> Hi. Axel Thimm wrote: > Not a big deal, but should the kernel specfile explicitely pull in the > config files mentioned as %{SOURCE20} etc? There is some black magic going on the the kernel spec files :) -- Salzflecken auf einer Tischdecke bekommt man mit etwas Rotwein wieder heraus. From buildsys at redhat.com Sat Feb 5 13:08:17 2005 From: buildsys at redhat.com (Build System) Date: Sat, 5 Feb 2005 08:08:17 -0500 Subject: rawhide report: 20050205 changes Message-ID: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> Updated Packages: anaconda-10.2.0.16-1 -------------------- * Fri Feb 04 2005 Chris Lumens - 10.2.0.16-1 - Support setting fs options in kickstart via --fsoptions (#97560) - Fix tracebacks beecrypt-3.1.0-7 ---------------- * Fri Feb 04 2005 Miloslav Trmac - 3.1.0-7 - Rebuild against Python 2.4 coreutils-5.2.1-38 ------------------ * Fri Feb 04 2005 Tim Waugh 5.2.1-38 - Special case for ia32e in uname (bug #145266). cpuspeed-1:1.2.1-1.16 --------------------- * Fri Feb 04 2005 Dave Jones - Enable builds for PPC (#147089) dasher-3.2.13-1 --------------- * Fri Feb 04 2005 3.2.13-1 - Update to 3.2.13 evince-0.1.3-1 -------------- * Fri Feb 04 2005 Marco Pesenti Gritti - 0.1.3-1 - Update to 0.1.3 gdb-6.3.0.0-0.16 ---------------- * Fri Feb 04 2005 Jeff Johnston 6.3.0.0-0.16 - Fix gcore to work properly for threaded applications - Bugzilla 145309, 145092 * Fri Feb 04 2005 Jeff Johnston 6.3.0.0-0.15 - Tolerate DW_AT_type referencing <0> and instead of generating an error, treat as unknown type. - Bugzilla 144852. * Thu Feb 03 2005 Andrew Cagney 6.3.0.0-0.14 - Separate out test patches. glade2-2.9.0-1 -------------- * Fri Feb 04 2005 Matthias Clasen - 2.9.0-1 - Update to 2.9.0 glib2-2.6.2-1 ------------- * Fri Feb 04 2005 Matthias Clasen - 2.6.2-1 - Upgrade to 2.6.2 gnome-applets-1:2.9.5-2 ----------------------- * Fri Feb 04 2005 Mark McLoughlin - 2.9.5-2 - Fix schemas list (#146880, #147011) gnome-desktop-2.9.90.1-1 ------------------------ * Fri Feb 04 2005 Matthias Clasen 2.9.90.1-1 - Update to 2.9.90.1 gnome-icon-theme-2.9.90-3 ------------------------- * Fri Feb 04 2005 Matthias Clasen - 2.9.90-3 - Silence %post gnome-panel-2.9.90-3 -------------------- * Fri Feb 04 2005 Mark McLoughlin - 2.9.90-3 - Update schemas list (#147112) gnome-themes-2.9.90-3 --------------------- * Sat Feb 05 2005 Matthias Clasen - 2.9.90-3 - Silence gtk-update-icon-cache gtk2-2.6.2-1 ------------ * Fri Feb 04 2005 Matthias Clasen - 2.6.2-1 - Upgrade to 2.6.2 * Mon Jan 10 2005 Matthias Clasen - 2.6.1-1 - Upgrade to 2.6.1 - Drop no longer needed fixes * Mon Dec 06 2004 Matthias Clasen - 2.4.14-1 - Upgrade to 2.4.14 - Remove the no longer needed pa.po patch - Adjust gtk+-2.4.7-update-counter.patch kernel-2.6.10-1.1125_FC4 ------------------------ * Fri Feb 04 2005 Dave Jones - 2.6.11-rc3-bk1 libgda-1:1.2.0-1 ---------------- * Fri Feb 04 2005 Caolan McNamara 1:1.2.0-1 - bump to latest version - drop integrated break warning patch - update configure patch libgnomedb-1:1.2.0-1 -------------------- * Fri Feb 04 2005 Caolan McNamara 1.2.0-1 - bump to latest stable version - drop integrated patchs redhat-artwork-0.120-5 ---------------------- * Sat Feb 05 2005 Matthias Clasen - 0.120-5 - Silence %post rpmdb-fedora-1:4-0.20050205 --------------------------- setarch-1.7-1 ------------- * Fri Feb 04 2005 Jindrich Novy 1.7-1 - Add '-R' option for ADDR_NO_RANDOMIZE (patch from Arjan van de Ven) - Minor code cleanup strace-4.5.9-2 -------------- * Fri Feb 04 2005 Roland McGrath - 4.5.9-2 - update ia64 syscall list (#146245) - fix x86_64 syscall argument extraction for 32-bit processes (#146093) - fix -e signal=NAME parsing (#143362) - fix x86_64 exit_group syscall handling - improve socket ioctl printing (#138223) - code cleanups (#143369, #143370) - improve mount flags printing (#141932) - support symbolic printing of x86_64 arch_prctl parameters (#142667) - fix potential crash in getxattr printing From arjanv at redhat.com Sat Feb 5 13:22:43 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 05 Feb 2005 14:22:43 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> Message-ID: <1107609763.4127.95.camel@laptopd505.fenrus.org> > coreutils-5.2.1-38 > ------------------ > * Fri Feb 04 2005 Tim Waugh 5.2.1-38 > - Special case for ia32e in uname (bug #145266). this is wrong. Very wrong. uname should report x86_64 for both AMD and Intel 64 bit x64 machines. The architecture is x86_64. No ifs or buts. Please undo this change before it ships in any release. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Sat Feb 5 13:31:28 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 05 Feb 2005 13:31:28 +0000 Subject: rawhide report: 20050205 changes In-Reply-To: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> Message-ID: <1107610288.5778.5.camel@localhost.localdomain> Hi, Oh well. Still can't do a proper update... Error: Missing Dependency: libedata-book.so.1 is needed by package evolution-connector Error: Missing Dependency: libebook.so.8 is needed by package openoffice.org Error: Missing Dependency: libcamel.so.0 is needed by package evolution- connector Error: Missing Dependency: libgal-2.2.so.1 is needed by package evolution-connector Error: Missing Dependency: libgal-a11y-2.2.so.1 is needed by package evolution-connector Error: Missing Dependency: libedataserver.so.3 is needed by package openoffice.org Error: Missing Dependency: libecal.so.6 is needed by package evolution- connector Error: Missing Dependency: libedataserver.so.3 is needed by package evolution-connector Error: Missing Dependency: libedata-cal.so.5 is needed by package evolution-connector Error: Missing Dependency: libnautilus.so.2 is needed by package nautilus-media Error: Missing Dependency: libebook.so.8 is needed by package evolution- connector It's been like this for a while now. This prevents updating gnomemeeting, gtkhtml3, evolution, openoffice and a few other gnome- based bits and pieces. TTFN Paul -- "I don't know how World War III will be fought, but I do know World War IV will be fought with sticks and stones" - Einstein -------------- next part -------------- A 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 peter.backlund at home.se Sat Feb 5 13:42:34 2005 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 05 Feb 2005 14:42:34 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <1107610288.5778.5.camel@localhost.localdomain> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107610288.5778.5.camel@localhost.localdomain> Message-ID: <1107610954.3496.2.camel@localhost.localdomain> On l?r, 2005-02-05 at 13:31 +0000, Paul wrote: > Hi, > > Oh well. Still can't do a proper update... > > Error: Missing Dependency: libedata-book.so.1 is needed by package > evolution-connector > Error: Missing Dependency: libebook.so.8 is needed by package > openoffice.org > Error: Missing Dependency: libcamel.so.0 is needed by package evolution- > connector > Error: Missing Dependency: libgal-2.2.so.1 is needed by package > evolution-connector > Error: Missing Dependency: libgal-a11y-2.2.so.1 is needed by package > evolution-connector > Error: Missing Dependency: libedataserver.so.3 is needed by package > openoffice.org > Error: Missing Dependency: libecal.so.6 is needed by package evolution- > connector > Error: Missing Dependency: libedataserver.so.3 is needed by package > evolution-connector > Error: Missing Dependency: libedata-cal.so.5 is needed by package > evolution-connector > Error: Missing Dependency: libnautilus.so.2 is needed by package > nautilus-media > Error: Missing Dependency: libebook.so.8 is needed by package evolution- > connector > > It's been like this for a while now. This prevents updating > gnomemeeting, gtkhtml3, evolution, openoffice and a few other gnome- > based bits and pieces. I saw this when moving my box from FC3 to Rawhide this morning. I worked around it by --disablerepo=base --exclude=openoffice\* It seems openoffice.org is linked to libedataserver.so.3, which is provided by the old evolution-data-server-1.0.2-3 but not e-d-s-1.1.4.2. You might need to temporarily remove or exclude e-connector as well. /Peter From fedora at leemhuis.info Sat Feb 5 13:55:18 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 Feb 2005 14:55:18 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <1107609763.4127.95.camel@laptopd505.fenrus.org> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> Message-ID: <1107611718.5823.9.camel@localhost.localdomain> Am Samstag, den 05.02.2005, 14:22 +0100 schrieb Arjan van de Ven: > > coreutils-5.2.1-38 > > ------------------ > > * Fri Feb 04 2005 Tim Waugh 5.2.1-38 > > - Special case for ia32e in uname (bug #145266). > > this is wrong. Very wrong. > uname should report x86_64 for both AMD and Intel 64 bit x64 machines. > The architecture is x86_64. No ifs or buts. While at it and just out of curiosity -- why to we have both ia32e and x86_64 as possible archs in bugzilla.redhat.com? I'm just wondering if that is (still?) needed... And yes, I know there are small differences between those two. But are they important for us and needed in bugzilla? I think they are more confusing then helpful. just my 2 cent... -- Thorsten Leemhuis From arjanv at redhat.com Sat Feb 5 14:14:02 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 5 Feb 2005 15:14:02 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <1107611718.5823.9.camel@localhost.localdomain> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <1107611718.5823.9.camel@localhost.localdomain> Message-ID: <20050205141401.GB25534@devserv.devel.redhat.com> On Sat, Feb 05, 2005 at 02:55:18PM +0100, Thorsten Leemhuis wrote: > Am Samstag, den 05.02.2005, 14:22 +0100 schrieb Arjan van de Ven: > > > coreutils-5.2.1-38 > > > ------------------ > > > * Fri Feb 04 2005 Tim Waugh 5.2.1-38 > > > - Special case for ia32e in uname (bug #145266). > > > > this is wrong. Very wrong. > > uname should report x86_64 for both AMD and Intel 64 bit x64 machines. > > The architecture is x86_64. No ifs or buts. > > While at it and just out of curiosity -- why to we have both ia32e and > x86_64 as possible archs in bugzilla.redhat.com? because for RHEL3 we had to do a second kernel rpm because we couldn't retrofit em64t support into the kernel within the compability and stability contraints rhel3 updates have. > I'm just wondering if that is (still?) needed... And yes, I know there not for anything not RHEL3. Note that ia32e is doubly wrong; Intel calls their cpu technology EM64T not ia32e. From marcel at mesa.nl Sat Feb 5 14:37:53 2005 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 5 Feb 2005 15:37:53 +0100 Subject: building kernel sourcecode rpm again Message-ID: <20050205143753.GA28477@joshua.mesa.nl> Hi, I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 kernel src.rpm but noticed 'buildsource' is removed from the specfile. So is there new way to build the kernel-sourcecode rpm ? thanks -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From fedora at leemhuis.info Sat Feb 5 14:30:09 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 Feb 2005 15:30:09 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <20050205141401.GB25534@devserv.devel.redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <1107611718.5823.9.camel@localhost.localdomain> <20050205141401.GB25534@devserv.devel.redhat.com> Message-ID: <1107613810.5823.15.camel@localhost.localdomain> Am Samstag, den 05.02.2005, 15:14 +0100 schrieb Arjan van de Ven: > On Sat, Feb 05, 2005 at 02:55:18PM +0100, Thorsten Leemhuis wrote: > > Am Samstag, den 05.02.2005, 14:22 +0100 schrieb Arjan van de Ven: > > > > - Special case for ia32e in uname (bug #145266). > > > > > > this is wrong. Very wrong. > > > > While at it and just out of curiosity -- why to we have both ia32e and > > x86_64 as possible archs in bugzilla.redhat.com? > > because for RHEL3 we had to do a second kernel rpm because we couldn't > retrofit em64t support into the kernel within the compability and stability > contraints rhel3 updates have. > > > I'm just wondering if that is (still?) needed... And yes, I know there > > not for anything not RHEL3. I don't know bugzilla internals that much -- should it be possible to limit that arch to the RHEL component? If someones says "yes" I'm going to to open a bugzilla report against bugzilla ;-) > Note that ia32e is doubly wrong; Intel calls their cpu technology EM64T not > ia32e. Before my first post I rechecked it: Google finds 27 hits on intel.com for "ia32"e ;-) But of course EM64T is correct. -- Thorsten Leemhuis From selinux at gmail.com Sat Feb 5 14:54:28 2005 From: selinux at gmail.com (Tom London) Date: Sat, 5 Feb 2005 06:54:28 -0800 Subject: repoclosure.py In-Reply-To: <1107599064.21712.0.camel@rousalka.dyndns.org> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> <1107599064.21712.0.camel@rousalka.dyndns.org> Message-ID: <4c4ba153050205065434100b86@mail.gmail.com> Got the following..... any easy way to 'refresh' filelists.xml.gz? tom [tbl at tlondon Downloads]$ python ./repoclosure.py development Not running as root, might not be able to import all of cache Reading in repository metadata - please wait.... Traceback (most recent call last): File "./repoclosure.py", line 124, in ? main(repos) File "./repoclosure.py", line 77, in main my.repos.populateSack(with='filelists') File "repos.py", line 215, in populateSack File "repos.py", line 649, in getFileListsXML File "repos.py", line 607, in _retrieveMD yum.Errors.RepoError: Caching enabled and local cache: //var/cache/yum/development/filelists.xml.gz does not match checksum [tbl at tlondon Downloads]$ From rahulsundaram at gmail.com Sat Feb 5 14:57:28 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 5 Feb 2005 20:27:28 +0530 Subject: rawhide report: 20050205 changes In-Reply-To: <1107613810.5823.15.camel@localhost.localdomain> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <1107611718.5823.9.camel@localhost.localdomain> <20050205141401.GB25534@devserv.devel.redhat.com> <1107613810.5823.15.camel@localhost.localdomain> Message-ID: Hi > I don't know bugzilla internals that much -- should it be possible to > limit that arch to the RHEL component? If someones says "yes" I'm going > to to open a bugzilla report against bugzilla ;-) > yes. -- Regards, Rahul Sundaram From skvidal at phy.duke.edu Sat Feb 5 15:09:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 10:09:13 -0500 Subject: repoclosure.py In-Reply-To: <1107595748l.6367l.1l@devel.mpeters.us> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> Message-ID: <1107616153.8961.84.camel@cutter> On Sat, 2005-02-05 at 09:29 +0000, Michael A. Peters wrote: > On 02/05/2005 12:17:43 AM, seth vidal wrote: > > > > > I think it works okay, it seems to at least :) > > *snip* > package: httpd - 2.0.52-3.1.i386 from updates-released > unresolved deps: > /usr/share/magic.mime > package: libxml2-python - 2.6.16-3.i386 from updates-released > unresolved deps: > /usr/lib/python2.3 > package: openmotif - 2.2.3-6.FC3.1.i386 from updates-released > unresolved deps: > /usr/X11R6/lib/X11/XKeysymDB > > [root at devel bin]# rpm -qf /usr/share/magic.mime > file-4.12-1.FC3.1 > You have new mail in /var/spool/mail/mpeters > [root at devel bin]# rpm -qf /usr/share/magic.mime > file-4.12-1.FC3.1 > [root at devel bin]# rpm -qf /usr/lib/python2.3 > python-2.3.4-11 > [root at devel bin]# rpm -qf /usr/X11R6/lib/X11/XKeysymDB > xorg-x11-libs-6.8.1-12.FC3.21 > [root at devel bin]# It doesn't, at all, read things from your rpmdb. It uses ONLY the information out in the repositories. So just b/c something on your system resolves it - doesn't mean that there is something in a repository that does. -sv From skvidal at phy.duke.edu Sat Feb 5 15:10:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 10:10:08 -0500 Subject: repoclosure.py In-Reply-To: <4c4ba153050205065434100b86@mail.gmail.com> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> <1107599064.21712.0.camel@rousalka.dyndns.org> <4c4ba153050205065434100b86@mail.gmail.com> Message-ID: <1107616208.8961.86.camel@cutter> On Sat, 2005-02-05 at 06:54 -0800, Tom London wrote: > Got the following..... any easy way to 'refresh' filelists.xml.gz? > > tom > > [tbl at tlondon Downloads]$ python ./repoclosure.py development > Not running as root, might not be able to import all of cache > Reading in repository metadata - please wait.... > Traceback (most recent call last): > File "./repoclosure.py", line 124, in ? > main(repos) > File "./repoclosure.py", line 77, in main > my.repos.populateSack(with='filelists') > File "repos.py", line 215, in populateSack > File "repos.py", line 649, in getFileListsXML > File "repos.py", line 607, in _retrieveMD > yum.Errors.RepoError: Caching enabled and local cache: > //var/cache/yum/development/filelists.xml.gz does not match checksum > [tbl at tlondon Downloads]$ like I said in the initial message: The only other thing you might want to do is either: 1. run repoclosure.py as root 2. run yum makecache as root with the repositories you want to use enabled. thanks, -sv From skvidal at phy.duke.edu Sat Feb 5 15:12:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 10:12:04 -0500 Subject: repoclosure.py In-Reply-To: <20050205112010.6ad8d463@python2> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> Message-ID: <1107616324.8961.88.camel@cutter> > Well, seems like it only processes file dependencies on the "basic" ones > (i.e. *bin/* etc.) from the metadata, so you just got a few false > positives, nothing dramatic for a quick script ;-) Actually I just realized what's happening there. It's a small bug in the metadata import routine - it's not rebuilding the filelist indexes to be searched. It's an easy fix, really. It'll be in the next release of yum. -sv From skvidal at phy.duke.edu Sat Feb 5 15:33:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 10:33:07 -0500 Subject: repoclosure.py In-Reply-To: <1107595748l.6367l.1l@devel.mpeters.us> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> Message-ID: <1107617587.8961.91.camel@cutter> > package: openmotif - 2.2.3-6.FC3.1.i386 from updates-released > unresolved deps: > /usr/X11R6/lib/X11/XKeysymDB > > [root at devel bin]# rpm -qf /usr/share/magic.mime > file-4.12-1.FC3.1 > You have new mail in /var/spool/mail/mpeters > [root at devel bin]# rpm -qf /usr/share/magic.mime > file-4.12-1.FC3.1 > [root at devel bin]# rpm -qf /usr/lib/python2.3 > python-2.3.4-11 > [root at devel bin]# rpm -qf /usr/X11R6/lib/X11/XKeysymDB > xorg-x11-libs-6.8.1-12.FC3.21 > [root at devel bin]# > So what you're seeing is a small bug during the metadata import. Here is the patch that's in cvs for it: --- yum/repos.py 20 Jan 2005 06:59:18 -0000 1.59 +++ yum/repos.py 30 Jan 2005 18:12:20 -0000 1.60 @@ -59,6 +59,8 @@ if not self.added.has_key(repoid): self.added[repoid] = [] self.added[repoid].append('metadata') + # indexes will need to be rebuilt + self.indexesBuilt = 0 elif datatype in ['filelists', 'otherdata']: if self.added.has_key(repoid): @@ -75,6 +77,8 @@ po.importFromDict(pkgdict, repoid) self.added[repoid].append(datatype) + # indexes will need to be rebuilt + self.indexesBuilt = 0 else: # umm, wtf? pass -sv From bgerst at didntduck.org Sat Feb 5 15:40:40 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Sat, 05 Feb 2005 10:40:40 -0500 Subject: building kernel sourcecode rpm again In-Reply-To: <20050205143753.GA28477@joshua.mesa.nl> References: <20050205143753.GA28477@joshua.mesa.nl> Message-ID: <4204E8F8.1050701@didntduck.org> Marcel J.E. Mol wrote: > Hi, > I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 kernel > src.rpm but noticed 'buildsource' is removed from the specfile. > So is there new way to build the kernel-sourcecode rpm ? > > thanks > > -Marcel kernel-sourcecode doesn't exist anymore. kernel-devel is the replacement. -- Brian Gerst From marcel at mesa.nl Sat Feb 5 15:56:04 2005 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 5 Feb 2005 16:56:04 +0100 Subject: building kernel sourcecode rpm again In-Reply-To: <4204E8F8.1050701@didntduck.org> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> Message-ID: <20050205155604.GB28477@joshua.mesa.nl> On Sat, Feb 05, 2005 at 10:40:40AM -0500, Brian Gerst wrote: > Marcel J.E. Mol wrote: > >Hi, > >I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 > >kernel > >src.rpm but noticed 'buildsource' is removed from the specfile. > >So is there new way to build the kernel-sourcecode rpm ? > > > >thanks > > > >-Marcel > > kernel-sourcecode doesn't exist anymore. kernel-devel is the replacement. But kernel-devel only contains include files and some other stuff to build additional modules. I want to change some specific part of the kernel to get some functionality that can not be done by adding a new module. Using the kernel-sourcode package was a good starting point for that. -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From arjanv at redhat.com Sat Feb 5 16:03:36 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 05 Feb 2005 17:03:36 +0100 Subject: building kernel sourcecode rpm again In-Reply-To: <4204E8F8.1050701@didntduck.org> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> Message-ID: <1107619416.4127.118.camel@laptopd505.fenrus.org> On Sat, 2005-02-05 at 10:40 -0500, Brian Gerst wrote: > Marcel J.E. Mol wrote: > > Hi, > > I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 kernel > > src.rpm but noticed 'buildsource' is removed from the specfile. > > So is there new way to build the kernel-sourcecode rpm ? > > > > thanks > > > > -Marcel > > kernel-sourcecode doesn't exist anymore. kernel-devel is the replacement. that sounds wrong; as I understand it kernel-devel is for including into kernel modules only. You could never do anything like that with kernel- sourcecode.... that was exclusively for building your own kernel. -------------- next part -------------- A 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 bgerst at didntduck.org Sat Feb 5 16:21:14 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Sat, 05 Feb 2005 11:21:14 -0500 Subject: building kernel sourcecode rpm again In-Reply-To: <1107619416.4127.118.camel@laptopd505.fenrus.org> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> <1107619416.4127.118.camel@laptopd505.fenrus.org> Message-ID: <4204F27A.2070506@didntduck.org> Arjan van de Ven wrote: > On Sat, 2005-02-05 at 10:40 -0500, Brian Gerst wrote: > >>Marcel J.E. Mol wrote: >> >>>Hi, >>>I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 kernel >>>src.rpm but noticed 'buildsource' is removed from the specfile. >>>So is there new way to build the kernel-sourcecode rpm ? >>> >>>thanks >>> >>>-Marcel >> >>kernel-sourcecode doesn't exist anymore. kernel-devel is the replacement. > > > that sounds wrong; as I understand it kernel-devel is for including into > kernel modules only. You could never do anything like that with kernel- > sourcecode.... that was exclusively for building your own kernel. You are correct. The correct replacement for kernel-sourcecode is the kernel SRPM. -- Brian Gerst From marcel at mesa.nl Sat Feb 5 16:50:57 2005 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 5 Feb 2005 17:50:57 +0100 Subject: building kernel sourcecode rpm again In-Reply-To: <4204F27A.2070506@didntduck.org> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> <1107619416.4127.118.camel@laptopd505.fenrus.org> <4204F27A.2070506@didntduck.org> Message-ID: <20050205165057.GC28477@joshua.mesa.nl> On Sat, Feb 05, 2005 at 11:21:14AM -0500, Brian Gerst wrote: > Arjan van de Ven wrote: > >On Sat, 2005-02-05 at 10:40 -0500, Brian Gerst wrote: > > > >>Marcel J.E. Mol wrote: > >> > >>>Hi, > >>>I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 > >>>kernel > >>>src.rpm but noticed 'buildsource' is removed from the specfile. > >>>So is there new way to build the kernel-sourcecode rpm ? > >>> > >>>thanks > >>> > >>>-Marcel > >> > >>kernel-sourcecode doesn't exist anymore. kernel-devel is the replacement. > > > > > >that sounds wrong; as I understand it kernel-devel is for including into > >kernel modules only. You could never do anything like that with kernel- > >sourcecode.... that was exclusively for building your own kernel. > > You are correct. The correct replacement for kernel-sourcecode is the > kernel SRPM. Well, thats the point. I use the SRPM to build the kernel-sourcecode rpm... I guess processing the SRPM up to a certain point will leave the complete patch redhat/fedora version of the kernel in /usr/src/redhat/BUILD and I can work from that. But it seems so much easier to have the kernel-sourcode rpm so I can take it to other machines and also to have multiple kernel versions in /usr/src... -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From arjanv at redhat.com Sat Feb 5 16:58:01 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 05 Feb 2005 17:58:01 +0100 Subject: building kernel sourcecode rpm again In-Reply-To: <20050205165057.GC28477@joshua.mesa.nl> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> <1107619416.4127.118.camel@laptopd505.fenrus.org> <4204F27A.2070506@didntduck.org> <20050205165057.GC28477@joshua.mesa.nl> Message-ID: <1107622681.4127.127.camel@laptopd505.fenrus.org> > Well, thats the point. I use the SRPM to build the kernel-sourcecode rpm... > I guess processing the SRPM up to a certain point will leave the complete > patch redhat/fedora version of the kernel in /usr/src/redhat/BUILD and > I can work from that. read the fc3 release notes on a better description... -------------- next part -------------- A 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 lkml at mac.com Sat Feb 5 17:44:56 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Sat, 5 Feb 2005 18:44:56 +0100 Subject: Sharing sound hardware In-Reply-To: <4204AD22.8020605@yahoo.co.uk> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> <4204AD22.8020605@yahoo.co.uk> Message-ID: On 5 Feb 2005, at 12:25, Dariusz J. Garbowski wrote: > On 02/05/2005 10:49 AM, Ronald S. Bultje wrote: >> Hi Ryan, >> On Sat, 2005-02-05 at 03:10, Ryan Gammon wrote: >>> Ideally IMHO dmix / asym would: >> [..] >>> - Open the sound device using sensible maximum capabilities of the >>> device in terms of sampling rate and # of channels, etc. The guys >>> who write our resamplers generally prefer to have helix doing any >>> sample rate conversion where possible: >>> http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/ >>> 000243.html >> Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users >> won't >> notice the difference if you're using a reasonably good resampler. On >> my >> computer (don't know if this is generally true), dmix operates on a >> fixed samplerate, regardless of playback. > > Please, no! This sounds really bad to me (pun intended ;-) I own a > card that can do hardware mixing and really don't like the idea of > "being punished" for that. Especially by something like upsampling > almost every sound I play from 44.1 to 48kHz. And yes, I will notice > (is it really 99% of the users who won't? where does this number come > from?) -- decent amplifier, cables and loudspeakers do just that: you > start noticing. > > The reason I'm really worried here is that I recall Colin Walters > saying that dmix will be on for everybody in FC4: > > https://www.redhat.com/archives/fedora-devel-list/2005-January/ > msg00614.html AFAIK, dmix will use software mixing *only* if your sound card doesn't support hardware mixing. From lkml at mac.com Sat Feb 5 18:00:21 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Sat, 5 Feb 2005 19:00:21 +0100 Subject: building kernel sourcecode rpm again In-Reply-To: <4204E8F8.1050701@didntduck.org> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> Message-ID: On 5 Feb 2005, at 16:40, Brian Gerst wrote: > Marcel J.E. Mol wrote: >> Hi, >> I want to create the kernel-sourcecode rpm from the 2.6.10-1.1124_FC4 >> kernel >> src.rpm but noticed 'buildsource' is removed from the specfile. >> So is there new way to build the kernel-sourcecode rpm ? >> thanks >> -Marcel > > kernel-sourcecode doesn't exist anymore. kernel-devel is the > replacement. Nop. kernel-devel is used to support out-of-tree drivers, mainly binary drivers, like nVidia and VMware binary drivers. From aoliva at redhat.com Sat Feb 5 18:37:35 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Feb 2005 16:37:35 -0200 Subject: rawhide report: 20050205 changes In-Reply-To: <1107610288.5778.5.camel@localhost.localdomain> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107610288.5778.5.camel@localhost.localdomain> Message-ID: On Feb 5, 2005, Paul wrote: > It's been like this for a while now. This prevents updating > gnomemeeting, gtkhtml3, evolution, openoffice and a few other gnome- > based bits and pieces. Yes, it's a pain. I'd just like to note that there isn't an update for openoffice, you only see it mentioned if you try an update without excludes because they depend on the old evolution package. As soon as openoffice is rebuilt with the new evolution libraries and gnome-media is officially Obsoleted:, you'll be able to update everything. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From richard.hubbell at gmail.com Sat Feb 5 19:50:34 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Sat, 5 Feb 2005 11:50:34 -0800 Subject: do RHE3 fixes get ported into FC and vice-versa? Message-ID: How is this managed, assuming it happens? Someone suggested to me that fedora is a test bed for RHE but I don't want to believe that. Tell me it ain't so. Richard From n3npq at nc.rr.com Sat Feb 5 20:03:41 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 05 Feb 2005 15:03:41 -0500 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: References: Message-ID: <4205269D.3040106@nc.rr.com> Richard Hubbell wrote: >How is this managed, assuming it happens? Someone suggested to me >that fedora is a test bed for RHE but I don't want to believe that. >Tell me it ain't so. > > Bugs is bugs. Do you really care where bugs come from and where the fixes go? It's a multidimensional flow for both bugs and fixes these days. 73 de Jeff speaking only for himself. From arjanv at redhat.com Sat Feb 5 20:15:45 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 05 Feb 2005 21:15:45 +0100 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: References: Message-ID: <1107634546.4127.146.camel@laptopd505.fenrus.org> On Sat, 2005-02-05 at 11:50 -0800, Richard Hubbell wrote: > How is this managed, assuming it happens? well by now RHEL3 is so old that fixes in there are almost always superceded by new versions of the software in FC. But if not, of course it gets fixed in FC 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 richard.hubbell at gmail.com Sat Feb 5 20:37:37 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Sat, 5 Feb 2005 12:37:37 -0800 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: <4205269D.3040106@nc.rr.com> References: <4205269D.3040106@nc.rr.com> Message-ID: On Sat, 05 Feb 2005 15:03:41 -0500, Jeff Johnson wrote: > Richard Hubbell wrote: > > >How is this managed, assuming it happens? Someone suggested to me > >that fedora is a test bed for RHE but I don't want to believe that. > >Tell me it ain't so. > > > > > > Bugs is bugs. Do you really care where bugs come from and where the > fixes go? Yeah, I care where they get fixed since I try to use fc3. I am surprised that my minimal fc3 install can't run firefox or mozilla both have fatal problems with numbers to strings. prdtoa.c and js_numbertostring stuff Does RHE suffer similarly? Richard > > It's a multidimensional flow for both bugs and fixes these days. > > 73 de Jeff speaking only for himself. > > From kyrre at solution-forge.net Sat Feb 5 20:44:53 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 05 Feb 2005 21:44:53 +0100 Subject: x86_64 in FC4? In-Reply-To: <20050204233445.GB20362@thyrsus.com> References: <20050204224224.GD19669@thyrsus.com> <200502041805.14706.czar@czarc.net> <20050204233445.GB20362@thyrsus.com> Message-ID: <1107636293.2656.45.camel@localhost.localdomain> l?r, 05.02.2005 kl. 00.34 skrev Eric S. Raymond: > Gene C. : > > Yes, I have an Opteron system also and have been impressed with its relative > > performance (even with my Opteron 140). > > Indeed. I have a single Opteron 3400 that is cranking a measured 1.65 > times better performance than my previous machine on doclifter, my > monster Python app -- which doesn't sound impressive until you > consider that the previous machine was a 2-processor SMP with 1.8GHz > Athlons. So my real-world throughput is as good or (allowing for > Amdahl's Law inefficiencies) better than what I'd get from a 6 GHz > Athlon, if such a thing existed. > Depends on how well threaded the app is... A single-threaded app can't use more than one CPU :) From kyrre at solution-forge.net Sat Feb 5 20:47:17 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 05 Feb 2005 21:47:17 +0100 Subject: Firefox not starting properly In-Reply-To: <20050204095836.GA29746@dudweiler.stuttgart.redhat.com> References: <1107492531.3363.2.camel@trevally.redfishdemo.com> <20050204095836.GA29746@dudweiler.stuttgart.redhat.com> Message-ID: <1107636437.2656.47.camel@localhost.localdomain> > > 3394 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/firefox -UILocale en-US Hmm? Multi-lingual UI on the horizon? :) From hp at redhat.com Sat Feb 5 20:59:56 2005 From: hp at redhat.com (Havoc Pennington) Date: Sat, 05 Feb 2005 15:59:56 -0500 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: References: <4205269D.3040106@nc.rr.com> Message-ID: <1107637196.4277.67.camel@localhost.localdomain> On Sat, 2005-02-05 at 12:37 -0800, Richard Hubbell wrote: > > Yeah, I care where they get fixed since I try to use fc3. > I am surprised that my minimal fc3 install can't run firefox or mozilla > both have fatal problems with numbers to strings. > > prdtoa.c and js_numbertostring stuff > > Does RHE suffer similarly? > You'll have to give more details. I think the browsers run for most everyone else. I suggest filing a bug report, or alternatively asking for help on fedora-list (the user list; this is the development list)... there are thousands of bugs out there, if everyone panicked about RHEL vs. Fedora every time they saw one, this list would have no other traffic ;-) The difference between Fedora and RHEL isn't really what bugs there are but what promises you have about how/when/by-whom they are fixed. With Fedora, the fix is normally by upgrade to a new version. With RHEL, it would normally be by backporting a minimal patch to the old version to avoid introducing new risks/changes. With Fedora, help or bugfixes come according to whether other people are interested in fixing your problem; with RHEL, there are various levels of SLA available from Red Hat that make commitments about how support requests will be handled. Fedora normally has bleeding-edge versions, which means it will often have a lot of fixes not in old versions, but also is likely to have new bugs. See http://fedora.redhat.com/about/rhel.html for the full story. Havoc From mpeters at mac.com Sat Feb 5 22:23:13 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 05 Feb 2005 22:23:13 +0000 Subject: repoclosure.py In-Reply-To: <4c4ba153050205065434100b86@mail.gmail.com> (from selinux@gmail.com on Sat Feb 5 06:54:28 2005) References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> <1107599064.21712.0.camel@rousalka.dyndns.org> <4c4ba153050205065434100b86@mail.gmail.com> Message-ID: <1107642193l.6367l.6l@devel.mpeters.us> On 02/05/2005 06:54:28 AM, Tom London wrote: > Got the following..... any easy way to 'refresh' filelists.xml.gz? You could add the specific command to refresh to your /etc/sudoers file. I haven't done that - but I do have a group that is allowed to specifically run "yum update" and "yum -y update" with no password required (though everything else gets rejected - such as yum install or yum remove) Makes life somewhat easier - I may add the refresh command as well. From mpeters at mac.com Sat Feb 5 22:25:20 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 05 Feb 2005 22:25:20 +0000 Subject: repoclosure.py In-Reply-To: <1107617587.8961.91.camel@cutter> (from skvidal@phy.duke.edu on Sat Feb 5 07:33:07 2005) References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <1107617587.8961.91.camel@cutter> Message-ID: <1107642320l.6367l.7l@devel.mpeters.us> > > So what you're seeing is a small bug during the metadata import. > > Here is the patch that's in cvs for it: > --- yum/repos.py 20 Jan 2005 06:5 Awesome :) From bms at zoominternet.net Sat Feb 5 17:48:00 2005 From: bms at zoominternet.net (Robert Spangler) Date: Sat, 5 Feb 2005 17:48:00 +0000 Subject: New Install Idea Message-ID: <200502051748.12010.bms@zoominternet.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I had posted this idea on the Fedora list and the feed back showed some interest. It seems to take a long time to install Fedora and I believe a better way of doing it would be to have a bare bone install CD. It was suggested that I post the same idea here for you fine folks. Presently you down load minimum of 3 CD's or the DVD and install. After the install you run yum which again downloads all the latest software that you have installed. The idea would be to have a bare bone install CD. What this CD should contain is just enough software to get the system to the point where it could connect to a Repository. system and then download the latest up to date versions of the software you want to install. I was thinking somewhere along the lines of how the new Debian install works. You could keep the same install look that is now present in Fedora just when it comes time to install the system software it downloads what is needed from the Internet. With this type of install I can a great improvement. You will only be downloading the software you want which will not require you to download large amounts of software you don't need. Also you will always have the most up to date software installed on your system. I am not suggesting to stop making the ISO images just give the installer a choice of downloading the complete CD set or one small CD which will connect them to a Repository. site to download the latest version of everything they want to install. Just a thought. Thnx for your time. - -- Regards Robert Smile... it increases your face value! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCBQbb0xJrO8dQYHgRAv9/AKCxUey+tgqFLUsq5h5sVftOo3BRHQCgtVr+ JDzfWzWRr30XyHxssOAbEwU= =24K+ -----END PGP SIGNATURE----- From bgerst at didntduck.org Sat Feb 5 23:34:19 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Sat, 05 Feb 2005 18:34:19 -0500 Subject: New Install Idea In-Reply-To: <200502051748.12010.bms@zoominternet.net> References: <200502051748.12010.bms@zoominternet.net> Message-ID: <420557FB.2040005@didntduck.org> Robert Spangler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I had posted this idea on the Fedora list and the feed back showed some > interest. It seems to take a long time to install Fedora and I believe a > better way of doing it would be to have a bare bone install CD. It was > suggested that I post the same idea here for you fine folks. > > Presently you down load minimum of 3 CD's or the DVD and install. After the > install you run yum which again downloads all the latest software that you > have installed. > > The idea would be to have a bare bone install CD. What this CD should contain > is just enough software to get the system to the point where it could connect > to a Repository. system and then download the latest up to date versions of > the software you want to install. I was thinking somewhere along the lines > of how the new Debian install works. You could keep the same install look > that is now present in Fedora just when it comes time to install the system > software it downloads what is needed from the Internet. > > With this type of install I can a great improvement. You will only be > downloading the software you want which will not require you to download > large amounts of software you don't need. Also you will always have the most > up to date software installed on your system. > > I am not suggesting to stop making the ISO images just give the installer a > choice of downloading the complete CD set or one small CD which will connect > them to a Repository. site to download the latest version of everything they > want to install. > > Just a thought. Thnx for your time. > You already can do a network (FTP/HTTP/NFS) install from the first CD. -- Brian Gerst From mwiktowy at gmx.net Sat Feb 5 23:37:11 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Sat, 05 Feb 2005 18:37:11 -0500 Subject: Sharing sound hardware In-Reply-To: <20050205102410.23FD873682@hormel.redhat.com> References: <20050205102410.23FD873682@hormel.redhat.com> Message-ID: <1107646631.4973.30.camel@localhost> > Date: Fri, 04 Feb 2005 18:10:32 -0800 > From: Ryan Gammon > Message-ID: <42042B18.2090207 at real.com> ... Sorry for the lack of threading ... I get message digests. ... > Hi guys, > > I've been catching up on my mailing list reading on fedora, helix, and > general sound server interaction, and saw a couple threads of interest > from late last year. > > I'm curious to know what the current fedora thinking is on software > mixing & sharing sound hardware, particularly with sound devices that > don't have any hardware mixing support. As a regular user who is stuck with one of those onboard soundcards that is quite capable *except* for the seeming lack of hardware mixing, I would be extremely happy to see someone focusing on this. A complication that I have is the need to run programs that are OSS only (Teamspeak2 and Quake3 to be specific) and the OSS emulation via ALSA seems to add an extra wrinkle into getting any sort of software mixing (particularly sound capture) working properly. I have played around with arts/esound/.asound with no success. One project that I noticed recently is oss2jack that I thought might solve my problem by plugging OSS directly into JACK instead of the OSS emulation in ALSA. I would hate to have to wedge this stuff into my configuration every single kernel update though (I have recently given up running on the GATOS treadmill to keep my ATI AIW TV tuner working ... I am crossing my fingers to see some of that stuff natively in Xorg) and I sense that the chance of any of these thing making it upstream are slim especially without someone knowledgeable of such things (read "not me") pushing it along. Anyways, JACK seems to list ALSA as a supportee. Maybe the OSS emulation in ALSA could be modified to run more smoothly with JACK/dmix/etc. and let ALSA figure out if there is a hardware mixer available or not. Hoping that OSS applications go away is not the way to go. Linux falling on its face due to sound hardware contention is one of the last embarrassments left when I am trying to sell Linux as a true Windows replacement to friends and family. /Mike From jos at xos.nl Sat Feb 5 23:38:50 2005 From: jos at xos.nl (Jos Vos) Date: Sun, 6 Feb 2005 00:38:50 +0100 Subject: New Install Idea In-Reply-To: <420557FB.2040005@didntduck.org>; from bgerst@didntduck.org on Sat, Feb 05, 2005 at 06:34:19PM -0500 References: <200502051748.12010.bms@zoominternet.net> <420557FB.2040005@didntduck.org> Message-ID: <20050206003850.A24042@xos037.xos.nl> On Sat, Feb 05, 2005 at 06:34:19PM -0500, Brian Gerst wrote: > You already can do a network (FTP/HTTP/NFS) install from the first CD. You don't even need the first CD, the boot.iso (size 5 MB) is enough. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From richard.hubbell at gmail.com Sat Feb 5 23:53:59 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Sat, 5 Feb 2005 15:53:59 -0800 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: <1107637196.4277.67.camel@localhost.localdomain> References: <4205269D.3040106@nc.rr.com> <1107637196.4277.67.camel@localhost.localdomain> Message-ID: On Sat, 05 Feb 2005 15:59:56 -0500, Havoc Pennington wrote: > On Sat, 2005-02-05 at 12:37 -0800, Richard Hubbell wrote: > > > > Yeah, I care where they get fixed since I try to use fc3. > > I am surprised that my minimal fc3 install can't run firefox or mozilla > > both have fatal problems with numbers to strings. > > > > prdtoa.c and js_numbertostring stuff > > > > Does RHE suffer similarly? > > > > You'll have to give more details. I think the browsers run for most > everyone else. I suggest filing a bug report, or alternatively asking > for help on fedora-list (the user list; this is the development list)... Have done both, got nowhere fast. To be fixed in FC4 is what I'm told. Don't even know what it is that will be fixed. I even tried to build my own firefox and got stuck on the same problem (with a different symptom, something with shlibsign) . I could just install all the stuff that comes on the cds but I don't want to do that. The fact that it runs for everyone else tells me there exists some silent dependency somewhere. > there are thousands of bugs out there, if everyone panicked about RHEL > vs. Fedora every time they saw one, this list would have no other > traffic ;-) Panic is never recommended in a situation. > > The difference between Fedora and RHEL isn't really what bugs there are > but what promises you have about how/when/by-whom they are fixed. With > Fedora, the fix is normally by upgrade to a new version. With RHEL, it > would normally be by backporting a minimal patch to the old version to > avoid introducing new risks/changes. With Fedora, help or bugfixes come > according to whether other people are interested in fixing your problem; > with RHEL, there are various levels of SLA available from Red Hat that > make commitments about how support requests will be handled. > > Fedora normally has bleeding-edge versions, which means it will often > have a lot of fixes not in old versions, but also is likely to have new > bugs. > > See http://fedora.redhat.com/about/rhel.html for the full story. Will have a look. Thanks. Richard > > Havoc > > From pbrobinson at gmail.com Sun Feb 6 00:29:42 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 6 Feb 2005 08:29:42 +0800 Subject: SSL certificate management/storage In-Reply-To: <4204A75E.7BD1FC37@jwz.org> References: <20050204162512.GA23731@redhat.com> <20050204233318.GC31894@redhat.com> <1107596698.11240.785.camel@speedy.iagorubio.net> <4204A75E.7BD1FC37@jwz.org> Message-ID: <5256d0b050205162971c55363@mail.gmail.com> > > Could be a problem to assume this, as self-signed certificates does not > > require a CA - that'll pick some bucks from you to sign your > > certificates - and it's sure self-signed certificates will be hanging > > around for a while, because they're cheaper than CA signed ones. > > Absolutely -- I use pop3s (and a self-signed ssl cert) for my employees' > email, and I'm sure not going to tithe anually to Verisign or whoever > merely to avoid a one-time warning dialog for my dozen users. I'm sure > lots of other small companies feel the same way. I use http://www.cacert.org/ certificates, and while they have the same problems at the moment with a one time warning dialog eventually they may get included with the browsers etc. I use them for https, smtps, imaps and pop3s. P From bms at zoominternet.net Sun Feb 6 00:43:19 2005 From: bms at zoominternet.net (Robert Spangler) Date: Sun, 6 Feb 2005 00:43:19 +0000 Subject: New Install Idea In-Reply-To: <420557FB.2040005@didntduck.org> References: <200502051748.12010.bms@zoominternet.net> <420557FB.2040005@didntduck.org> Message-ID: <200502060043.30881.bms@zoominternet.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 05 February 2005 23:34, Brian Gerst wrote: > You already can do a network (FTP/HTTP/NFS) install from the first CD. But would that be the same as getting the latest software without having to run yum after the install? - -- Regards Robert Smile... it increases your face value! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCBWgy0xJrO8dQYHgRAiSWAKCCXQzU9f4IqFiLdOvt2bq9X4JXZQCfVE/z YJiotmZ1xsIc2E510yF6ybM= =zbgE -----END PGP SIGNATURE----- From cmadams at hiwaay.net Sun Feb 6 02:05:22 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 5 Feb 2005 20:05:22 -0600 Subject: rawhide report: 20050205 changes In-Reply-To: <1107609763.4127.95.camel@laptopd505.fenrus.org> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> Message-ID: <20050206020522.GA899850@hiwaay.net> Once upon a time, Arjan van de Ven said: > > coreutils-5.2.1-38 > > ------------------ > > * Fri Feb 04 2005 Tim Waugh 5.2.1-38 > > - Special case for ia32e in uname (bug #145266). > > this is wrong. Very wrong. > uname should report x86_64 for both AMD and Intel 64 bit x64 machines. > The architecture is x86_64. No ifs or buts. I'm not sure what the special case is, but the implementations are somewhat different. Why shouldn't that be like: kosh:38:~$ uname -p athlon kosh:39:~$ uname -m i686 kosh:40:~$ uname -i i386 -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From richard.hubbell at gmail.com Sun Feb 6 02:08:15 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Sat, 5 Feb 2005 18:08:15 -0800 Subject: FWIW bug # 146339 (was "do RHE3 fixes get ported into FC and vice-versa?") Message-ID: FWIW, https://bugzilla.redhat.com/beta/show_bug.cgi?id=146339 From skvidal at phy.duke.edu Sun Feb 6 02:40:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 21:40:26 -0500 Subject: repoclosure.py In-Reply-To: <1107642193l.6367l.6l@devel.mpeters.us> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> <1107599064.21712.0.camel@rousalka.dyndns.org> <4c4ba153050205065434100b86@mail.gmail.com> <1107642193l.6367l.6l@devel.mpeters.us> Message-ID: <1107657626.26807.0.camel@cutter> On Sat, 2005-02-05 at 22:23 +0000, Michael A. Peters wrote: > On 02/05/2005 06:54:28 AM, Tom London wrote: > > Got the following..... any easy way to 'refresh' filelists.xml.gz? > > You could add the specific command to refresh to your /etc/sudoers > file. > > I haven't done that - but I do have a group that is allowed to > specifically run "yum update" and "yum -y update" with no password > required (though everything else gets rejected - such as yum install or > yum remove) > > Makes life somewhat easier - I may add the refresh command as well. yum makecache refreshes the metadata -sv From mattdm at mattdm.org Sun Feb 6 03:16:01 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 5 Feb 2005 22:16:01 -0500 Subject: New Install Idea In-Reply-To: <200502060043.30881.bms@zoominternet.net> References: <200502051748.12010.bms@zoominternet.net> <420557FB.2040005@didntduck.org> <200502060043.30881.bms@zoominternet.net> Message-ID: <20050206031601.GA20439@jadzia.bu.edu> On Sun, Feb 06, 2005 at 12:43:19AM +0000, Robert Spangler wrote: > But would that be the same as getting the latest software without having to > run yum after the install? I think really your request is this: When doing a network install, anaconda should look for an updates directory on the remote server and use any newer packages from there instead of from the base area. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From bms at zoominternet.net Sun Feb 6 03:45:11 2005 From: bms at zoominternet.net (Robert Spangler) Date: Sun, 6 Feb 2005 03:45:11 +0000 Subject: New Install Idea In-Reply-To: <20050206031601.GA20439@jadzia.bu.edu> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> Message-ID: <200502060345.25504.bms@zoominternet.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 06 February 2005 03:16, Matthew Miller wrote: > I think really your request is this: > > When doing a network install, anaconda should look for an updates > directory on the remote server and use any newer packages from there > instead of from the base area. Nope. Me request is to have 1 CD that only needs the minimum software required to prep the disc and then install all the software you would like from a yum repository that way it is only installing the latest version. No updates needed after the install. I am not a programmer, but to me this sounds like it is do-able. Everything would run like it does now with the only exception being when the time comes to install the software a yum repository would be used instead of the CD. - -- Regards Robert Smile... it increases your face value! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCBZLV0xJrO8dQYHgRAuN9AJ9AWTpAWrwzzfuQCSLFw408dvj4aQCeMUhm n0XUkGDMUBU2R/37nD0ooR0= =uhAf -----END PGP SIGNATURE----- From seanlkml at sympatico.ca Sun Feb 6 03:47:56 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 5 Feb 2005 22:47:56 -0500 (EST) Subject: New Install Idea In-Reply-To: <200502060345.25504.bms@zoominternet.net> References: <200502051748.12010.bms@zoominternet.net><200502060043.30881.bms@zoominternet.net><20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> Message-ID: <59157.10.10.10.28.1107661676.squirrel@linux1> On Sat, February 5, 2005 10:45 pm, Robert Spangler said: > Nope. Me request is to have 1 CD that only needs the minimum software > required to prep the disc and then install all the software you would like > from a yum repository that way it is only installing the latest version. > No updates needed after the install. > > I am not a programmer, but to me this sounds like it is do-able. > Everything would run like it does now with the only exception being when > the time comes to install the software a yum repository would be used > instead of the CD. > As someone mentioned though, a CD is really overkill and would always have to be updated with the latest releases. What you're looking for is already available today. Run the Anaconda installer and use http or ftp to do the install over the network. As long as the ftp or http site you use is serving up the latest versions of each rpm you'll have no updating to do after the install. You can create your own collection of rpms that you want to serve to such network installs. This is a very common practice for people that maintain a large number of machines. Cheers, Sean From skvidal at phy.duke.edu Sun Feb 6 04:46:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 05 Feb 2005 23:46:25 -0500 Subject: Please, help me with at76c503a and recent Linux packages... In-Reply-To: <1107607620.3515.12.camel@roque> References: <1107554065.3512.9.camel@roque> <1107556889.3515.1.camel@roque> <20050205040009.GA18917@angus.ind.WPI.EDU> <1107576423.8961.5.camel@cutter> <1107607620.3515.12.camel@roque> Message-ID: <1107665185.26807.16.camel@cutter> On Sat, 2005-02-05 at 12:46 +0000, Rui Miguel Seabra wrote: > On Fri, 2005-02-04 at 23:07 -0500, seth vidal wrote: > > On Fri, 2005-02-04 at 23:00 -0500, Charles R. Anderson wrote: > > > On Fri, Feb 04, 2005 at 10:41:28PM +0000, Rui Miguel Seabra wrote: > > > > Note to Seth: yum somehow siletly upgraded my i686 Linux to an i586 > > > > one... > > > > > > Do you have exactarch=1 set in your yum.conf? > > > Yes: > grep exactarch /etc/yum.conf > exactarch=1 > > > Another note - don't expect me to read every single message that comes > > across f-d-l :) > > hehe sorry :) > > > if you think you've found a bug, let me know in bugzilla. :) > > I wish I knew when it happened. It started happening right after linux > rpm 1090. In the meanwhile, yum was updated so it might have been a > temporary problem! i'd like to see the /var/log/yum.log from this system. -sv From bms at zoominternet.net Tue Feb 8 05:02:37 2005 From: bms at zoominternet.net (Robert Spangler) Date: Tue, 8 Feb 2005 00:02:37 -0500 Subject: New Install Idea In-Reply-To: <59157.10.10.10.28.1107661676.squirrel@linux1> References: <200502051748.12010.bms@zoominternet.net> <200502060345.25504.bms@zoominternet.net> <59157.10.10.10.28.1107661676.squirrel@linux1> Message-ID: <200502080002.48093.bms@zoominternet.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 05 February 2005 22:47, Sean wrote: > As someone mentioned though, a CD is really overkill and would always have > to be updated with the latest releases. I think the CD part is throwing everyone off. The CD would never have to be updated unless the way a system hard drive is configured, the software that is used for this changes, or a totally new way of setting up a system changes. The CD is only used to prepare the hard drive, activate the network card and ask you with yum repository and what software you would like to have installed. Nothing more! This doesn't seem to be that big of a deal but I guess I was wrong. > What you're looking for is already available today. Run the Anaconda > installer and use http or ftp to do the install over the network. As long > as the ftp or http site you use is serving up the latest versions of each > rpm you'll have no updating to do after the install. Only if you could point it to a yum repository and install from there. And if that is the case please explain how it is done. > You can create your own collection of rpms that you want to serve to such > network installs. This is a very common practice for people that maintain > a large number of machines. That might be true, but I don't maintain a large number of machine. I am just looking for a simple way to only have to download and install the most up-to-date files without having to download 3 CD's and then run Yum only to have to download another 2G of software. - -- Regards Robert Smile... it increases your face value! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCCEf40xJrO8dQYHgRAmrTAKC96HVcwNCMx/mt+REEv/fEUt/SdwCguOiy F7bDnk+MfTwbEQ8ziJHwtSY= =L64s -----END PGP SIGNATURE----- From mattdm at mattdm.org Sun Feb 6 05:27:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 6 Feb 2005 00:27:21 -0500 Subject: New Install Idea In-Reply-To: <200502060345.25504.bms@zoominternet.net> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> Message-ID: <20050206052721.GA25371@jadzia.bu.edu> On Sun, Feb 06, 2005 at 03:45:11AM +0000, Robert Spangler wrote: > > I think really your request is this: > > When doing a network install, anaconda should look for an updates > > directory on the remote server and use any newer packages from there > > instead of from the base area. > Nope. Me request is to have 1 CD that only needs the minimum software > required to prep the disc and then install all the software you would like > from a yum repository that way it is only installing the latest version. No > updates needed after the install. Err, yes. Except the first half of your request is already done. You *can* install from a 5MB cd over the network. (Altough it's nicer to have an ~80mb one which has the full GUI installer, because it's annoying to pull that over the net every time.) But what it doesn't do is look for updates and use newer packages if available, like yum does. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From skvidal at phy.duke.edu Sun Feb 6 06:02:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 06 Feb 2005 01:02:45 -0500 Subject: New Install Idea In-Reply-To: <20050206052721.GA25371@jadzia.bu.edu> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> <20050206052721.GA25371@jadzia.bu.edu> Message-ID: <1107669765.26807.31.camel@cutter> > Err, yes. Except the first half of your request is already done. You *can* > install from a 5MB cd over the network. (Altough it's nicer to have an ~80mb > one which has the full GUI installer, because it's annoying to pull that > over the net every time.) > > But what it doesn't do is look for updates and use newer packages if > available, like yum does. > So in order to get there we need a number of things to happen in anaconda: 1. multiple repository support 2. a way to set up multiple repositories, sanely, in the gui 3. a nice way to handle conflicts and what not from the interface - seeing as anaconda has, historically, dealt with consistent repositories with complete dependency closure. B/c you know the moment there is multiple repo support people will not just do base+updates but base +extras+updates+joesrepoofdoom -sv From aoliva at redhat.com Sun Feb 6 06:00:53 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 06 Feb 2005 04:00:53 -0200 Subject: rawhide report: 20050205 changes In-Reply-To: References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107610288.5778.5.camel@localhost.localdomain> Message-ID: On Feb 5, 2005, Alexandre Oliva wrote: > As soon as openoffice is rebuilt with the new evolution libraries and > gnome-media is officially Obsoleted:, you'll be able to update > everything. Actually, evolution-connector needs a rebuild as well. And, as of 20050205's rawhide, so do gnumeric and abiword, as well as gda, libgda and libgnomedb. It appears that something's broken with the libgda build, because the new build appears to require the SONAME from the previous build. It appears that some of the binaries in it got linked with the pre-installed libs, instead of with the just-built ones. A simple rebuild would fix that, in that it would get the new libgda into the buildroot and link with that, but it would be better to get the real issue addressed. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Sun Feb 6 06:01:53 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 06 Feb 2005 04:01:53 -0200 Subject: rawhide report: 20050205 changes In-Reply-To: References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107610288.5778.5.camel@localhost.localdomain> Message-ID: On Feb 5, 2005, Alexandre Oliva wrote: > As soon as openoffice is rebuilt with the new evolution libraries and > gnome-media is officially Obsoleted:, you'll be able to update > everything. Another problem is that struts-webapps-tomcat5 has depended on tomcat5 for quite some time, although no package provides tomcat5 in rawhide. What gives? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mattdm at mattdm.org Sun Feb 6 06:06:46 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 6 Feb 2005 01:06:46 -0500 Subject: New Install Idea In-Reply-To: <1107669765.26807.31.camel@cutter> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> <20050206052721.GA25371@jadzia.bu.edu> <1107669765.26807.31.camel@cutter> Message-ID: <20050206060646.GA26732@jadzia.bu.edu> On Sun, Feb 06, 2005 at 01:02:45AM -0500, seth vidal wrote: > 1. multiple repository support > 2. a way to set up multiple repositories, sanely, in the gui > 3. a nice way to handle conflicts and what not from the interface - > seeing as anaconda has, historically, dealt with consistent repositories > with complete dependency closure. B/c you know the moment there is > multiple repo support people will not just do base+updates but base > +extras+updates+joesrepoofdoom So, can we just have anaconda call pup? I'm only half joking.... -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From skvidal at phy.duke.edu Sun Feb 6 06:15:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 06 Feb 2005 01:15:31 -0500 Subject: New Install Idea In-Reply-To: <20050206060646.GA26732@jadzia.bu.edu> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> <20050206052721.GA25371@jadzia.bu.edu> <1107669765.26807.31.camel@cutter> <20050206060646.GA26732@jadzia.bu.edu> Message-ID: <1107670531.26807.35.camel@cutter> On Sun, 2005-02-06 at 01:06 -0500, Matthew Miller wrote: > On Sun, Feb 06, 2005 at 01:02:45AM -0500, seth vidal wrote: > > 1. multiple repository support > > 2. a way to set up multiple repositories, sanely, in the gui > > 3. a nice way to handle conflicts and what not from the interface - > > seeing as anaconda has, historically, dealt with consistent repositories > > with complete dependency closure. B/c you know the moment there is > > multiple repo support people will not just do base+updates but base > > +extras+updates+joesrepoofdoom > > So, can we just have anaconda call pup? > > > I'm only half joking.... > The discussion I've heard so far is to work in the direction of having: 1. only one set of the metadata in any format 2. a single depsolver, slightly differently handled and subclassed 3. anaconda support some subset of that functionality. So how do we get there? I think that's a question best answered by Jeremy and other anaconda hackers. :) -sv From arjanv at redhat.com Sun Feb 6 09:21:08 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 06 Feb 2005 10:21:08 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <20050206020522.GA899850@hiwaay.net> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> Message-ID: <1107681668.22680.55.camel@laptopd505.fenrus.org> On Sat, 2005-02-05 at 20:05 -0600, Chris Adams wrote: > Once upon a time, Arjan van de Ven said: > > > coreutils-5.2.1-38 > > > ------------------ > > > * Fri Feb 04 2005 Tim Waugh 5.2.1-38 > > > - Special case for ia32e in uname (bug #145266). > > > > this is wrong. Very wrong. > > uname should report x86_64 for both AMD and Intel 64 bit x64 machines. > > The architecture is x86_64. No ifs or buts. > > I'm not sure what the special case is, but the implementations are > somewhat different. Why shouldn't that be like: > > kosh:38:~$ uname -p > athlon > kosh:39:~$ uname -m > i686 > kosh:40:~$ uname -i > i386 this is already wrong. The "athlon" hack is *WRONG*. Athlon is a marketing name, it could just as well be a duron or a sempron. It was a mistake to put the athlon hack in uname (but hindsight is easy); it's imo very wrong to repeat that mistake. Note that what you show is incorrect already if you are on a newer machine, it should report athlon64. Or opteron. Or sempron. It's better to report more generic information than specific information which is incorrect, since that is actually far less useful than returning the somewhat more generic but correct information. -------------- next part -------------- A 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 rbultje at ronald.bitfreak.net Sun Feb 6 10:11:22 2005 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Sun, 06 Feb 2005 11:11:22 +0100 Subject: Sharing sound hardware In-Reply-To: <4204AD22.8020605@yahoo.co.uk> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> <4204AD22.8020605@yahoo.co.uk> Message-ID: <1107684681.5561.130.camel@tux.lan> On Sat, 2005-02-05 at 12:25, Dariusz J. Garbowski wrote: [dmix...] > > Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users won't > > notice the difference if you're using a reasonably good resampler. On my > > computer (don't know if this is generally true), dmix operates on a > > fixed samplerate, regardless of playback. > > Please, no! This sounds really bad to me (pun intended ;-) I own a card > that can do hardware mixing and really don't like the idea of "being > punished" for that. Especially by something like upsampling almost every > sound I play from 44.1 to 48kHz. And yes, I will notice (is it really > 99% of the users who won't? where does this number come from?) -- decent > amplifier, cables and loudspeakers do just that: you start noticing. 99% of the users is a random guess. I'm talking about any user here, not technical user specifically. The idea is that dmix is only there when needed. If your card doesn't support mixing, well, you don't expect anything else, do you? You can't ask for the impossible. If you card does, then turn it off. It's not that hard. (And yes, this should of course be auto-detected, we're working on that.) > If so, *please* include a note how to do it in Release Notes for FC4. I'm sure the fedora people will do that, obviously, but I (for the GStreamer side of the thing) prefer to do the right thing automagically. I'm not sure that'll be finished by FC4. Ronald -- Ronald S. Bultje From ville.skytta at iki.fi Sun Feb 6 10:16:14 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 06 Feb 2005 12:16:14 +0200 Subject: rawhide report: 20050205 changes In-Reply-To: References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107610288.5778.5.camel@localhost.localdomain> Message-ID: <1107684974.30769.370.camel@bobcat.mine.nu> On Sun, 2005-02-06 at 04:00 -0200, Alexandre Oliva wrote: > On Feb 5, 2005, Alexandre Oliva wrote: > > > As soon as openoffice is rebuilt with the new evolution libraries and > > gnome-media is officially Obsoleted:, you'll be able to update > > everything. > > Actually, evolution-connector needs a rebuild as well. ...and OT: evolution-data-server needs to be updated/fixed, the current version available for FC3 (and the last time I checked, Rawhide) makes it impossible to use Exchange calendars due to immediate, reproducible backend process crashes: https://bugzilla.redhat.com/144072 From byte at aeon.com.my Sun Feb 6 11:11:20 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 06 Feb 2005 19:11:20 +0800 Subject: x86_64 in FC4? In-Reply-To: <1107557855.16306.1.camel@nexus.verbum.private> References: <20050204224224.GD19669@thyrsus.com> <1107557855.16306.1.camel@nexus.verbum.private> Message-ID: <1107688280.5367.91.camel@localhost.localdomain> On Fri, 2005-02-04 at 17:57 -0500, Colin Walters wrote: > > speed-critical stuff (Perl & Python interpreters, Open Office, > etc.). > > It looks to me like Python and Perl are already both 64-bit > executables > in FC3. Open Office is a huge amount of work; I think Dan Williams > was > doing some on it, but my impression was it was still fairly far away. There are OOo child workspaces for 64-bit integration, but yes, its still fairly far away. Thats going to remain 32-bit for quite a while, iirc (even upstream, that is) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From byte at aeon.com.my Sun Feb 6 11:13:13 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 06 Feb 2005 19:13:13 +0800 Subject: Fedora Core 3 (4?) Live CD In-Reply-To: <20050204221256.GB11004@rogers.com> References: <20050204221256.GB11004@rogers.com> Message-ID: <1107688393.5367.94.camel@localhost.localdomain> On Fri, 2005-02-04 at 17:12 -0500, Dimitrie O. Paun wrote: > I was looking the other day for a Fedora Live CD, but couldn't > find anything out there. For whatever reason, I thought FC3 > had a Live CD... Am I missing something? If not, any plans to > have one for FC4? On the agenda for discussion at FUDCon is definitely to talk about a Fedora LiveCD, created via the Stateless Linux system There is however one that Dirk Westfal has created, thats pretty good as well, so give that a twirl -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From buildsys at redhat.com Sun Feb 6 13:00:06 2005 From: buildsys at redhat.com (Build System) Date: Sun, 6 Feb 2005 08:00:06 -0500 Subject: rawhide report: 20050206 changes Message-ID: <200502061300.j16D06W32486@porkchop.devel.redhat.com> New package python-sqlite3 Python bindings for sqlite3 New package sqlite3 Library that implements an embeddable SQL database engine Updated Packages: coreutils-5.2.1-40 ------------------ * Sat Feb 05 2005 Tim Waugh 5.2.1-40 - Undo last change (bug #145266). elfutils-0.99-2 --------------- * Sat Feb 05 2005 Jeff Johnson 0.99-2 - upgrade to 0.99. * Sun Sep 26 2004 Jeff Johnson 0.97-3 - upgrade to 0.97. * Tue Aug 17 2004 Jakub Jelinek 0.95-5 - upgrade to 0.96. kernel-2.6.10-1.1126_FC4 ------------------------ * Sat Feb 05 2005 Dave Jones - 2.6.11-rc3-bk2 openoffice.org-1.1.3-5.7.0 -------------------------- * Sat Feb 05 2005 Dan Williams - 1.1.3-5 - Disable Evo2 connector on FC4 builds until we can get it ported to Evo 2.2 * Tue Feb 01 2005 Dan Williams - 1.1.3-4 - #rh146328# Fix printer discovery * Tue Feb 01 2005 Dan Williams - 1.1.3-3 - #rh146580# Dump upstream Novell patch that shifts rows on paste in Calc rpmdb-fedora-1:4-0.20050206 --------------------------- From Axel.Thimm at ATrpms.net Sun Feb 6 13:31:52 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 6 Feb 2005 14:31:52 +0100 Subject: repoclosure.py In-Reply-To: <1107616324.8961.88.camel@cutter> References: <1107591464.8961.77.camel@cutter> <1107595748l.6367l.1l@devel.mpeters.us> <20050205112010.6ad8d463@python2> <1107616324.8961.88.camel@cutter> Message-ID: <20050206133152.GA29828@neu.nirvana> On Sat, Feb 05, 2005 at 10:12:04AM -0500, seth vidal wrote: > > > Well, seems like it only processes file dependencies on the "basic" ones > > (i.e. *bin/* etc.) from the metadata, so you just got a few false > > positives, nothing dramatic for a quick script ;-) > > Actually I just realized what's happening there. > > It's a small bug in the metadata import routine - it's not rebuilding > the filelist indexes to be searched. It's an easy fix, really. > > It'll be in the next release of yum. will this fix http://bugzilla.atrpms.net/show_bug.cgi?id=288 https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=378 :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sitsofe at yahoo.com Sun Feb 6 14:06:45 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Sun, 06 Feb 2005 14:06:45 +0000 Subject: Sharing sound hardware In-Reply-To: References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> <4204AD22.8020605@yahoo.co.uk> Message-ID: <1107698805.4341.22.camel@galvatron.localdomain> On Sat, 2005-02-05 at 18:44 +0100, Felipe Alfaro Solana wrote: > On 5 Feb 2005, at 12:25, Dariusz J. Garbowski wrote: > AFAIK, dmix will use software mixing *only* if your sound card doesn't > support hardware mixing. Where did you get this from? Can you point to a page that explicitly says this? I would be *very* interested to know if this happens. The only information I could find was http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_dmix and there no mention of hardware mixing with software mixing fallbacks. I also had a cursory glance at http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/src/pcm/pcm_dmix.c?rev=1.60&view=auto and I don't see anything to check whether there are "free" hardware channels to mix with (but to be fair that might not be the piece of code that decides). -- Sitsofe | http://sucs.org/~sits/ From thuforuk at yahoo.co.uk Sun Feb 6 14:20:23 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Sun, 06 Feb 2005 14:20:23 +0000 Subject: Sharing sound hardware In-Reply-To: <1107684681.5561.130.camel@tux.lan> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> <4204AD22.8020605@yahoo.co.uk> <1107684681.5561.130.camel@tux.lan> Message-ID: <420627A7.8080405@yahoo.co.uk> On 02/06/2005 10:11 AM, Ronald S. Bultje wrote: > On Sat, 2005-02-05 at 12:25, Dariusz J. Garbowski wrote: > [dmix...] > >>>Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users won't >>>notice the difference if you're using a reasonably good resampler. On my >>>computer (don't know if this is generally true), dmix operates on a >>>fixed samplerate, regardless of playback. >> >>Please, no! This sounds really bad to me (pun intended ;-) I own a card >>that can do hardware mixing and really don't like the idea of "being >>punished" for that. Especially by something like upsampling almost every >>sound I play from 44.1 to 48kHz. And yes, I will notice (is it really >>99% of the users who won't? where does this number come from?) -- decent >>amplifier, cables and loudspeakers do just that: you start noticing. > > > 99% of the users is a random guess. I'm talking about any user here, not > technical user specifically. I was suspecting that much, however this sounds like "who cares about this 1%" -- I say: "it may or may not be 1%, and they probably care" ;-) Yes, I understand why users want software mixing if their soundcard doesn't support hardware mixing. I was there once. I support effort of getting it working out of the box for them. But I wouldn't like for Fedora to forget about those who build their machines to have better support just to discover that a year later their distro takes away support for their harware (or gives them hard time to get that support working right again). > The idea is that dmix is only there when > needed. If your card doesn't support mixing, well, you don't expect > anything else, do you? You can't ask for the impossible. If you card > does, then turn it off. It's not that hard. (And yes, this should of > course be auto-detected, we're working on that.) Always good to hear :-) >>If so, *please* include a note how to do it in Release Notes for FC4. > > > I'm sure the fedora people will do that, obviously, but I (for the > GStreamer side of the thing) prefer to do the right thing automagically. That would be great! And that's what I would expect to happen if implemented correctly, not less. > I'm not sure that'll be finished by FC4. I understand that there are some technical difficulties and sometimes developers need time to figure out how to do "the right thing" in all possible hardware/software configurations. That's why I'd be happy if there was clear and documented way of turning software mixing off if the user wishes. That should also keep it off after some related packages get upgraded. Kind regards, Dariusz From fedora at wir-sind-cool.org Sun Feb 6 14:44:39 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 6 Feb 2005 15:44:39 +0100 Subject: rawhide report: 20050206 changes In-Reply-To: <200502061300.j16D06W32486@porkchop.devel.redhat.com> References: <200502061300.j16D06W32486@porkchop.devel.redhat.com> Message-ID: <20050206154439.0f1f090e.fedora@wir-sind-cool.org> On Sun, 6 Feb 2005 08:00:06 -0500, Build System wrote: > New package python-sqlite3 > Python bindings for sqlite3 > > New package sqlite3 > Library that implements an embeddable SQL database engine Spec file mentions that there are 56 failed tests. Is that still accurate? The package in fedora.us queue passes all ~15000 tests on i386 and x86_64. https://bugzilla.fedora.us/show_bug.cgi?id=2135#c20 From sitsofe at yahoo.com Sun Feb 6 15:21:30 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Sun, 06 Feb 2005 15:21:30 +0000 Subject: Sharing sound hardware In-Reply-To: <42042B18.2090207@real.com> References: <42042B18.2090207@real.com> Message-ID: <1107703290.4341.83.camel@galvatron.localdomain> Hey Ryan, I'm no ALSA expert and in fact I have a hardware mixing soundcard but for various reasons I'm interested in dmix. On Fri, 2005-02-04 at 18:10 -0800, Ryan Gammon wrote: > From where I'm sitting, there's some appeal to the alsa asym / dmix > solution that I've seen discussed. > > The alsa api, while pretty complex, gives good access to all the > features a given piece of hardware supports. The fact that alsa has an > awareness of the hardware it's running on gives it the ability to > (eventually) be smarter when it comes to things like mixing in hardware > vs mixing in software. This is a bit contentious. Rumour has it (i.e. I've seen other people saying this in forums rather than actual ALSA developers) the ALSA folks want to keep hardware mixing and software mixing apart rather than doing a Windows like fallback of hardware mixing where possible and software mixing if not. As I said, I haven't talked to (or seen mention by) any ALSA devs about this so it amounts to nothing more than gossip. > I did some playing around with dmix last year when I was touching up > helix's alsa support, and found it to be pretty buggy on the alsa side. > > Some of this may be incorrect, but as I recall: > > 1. libasound forks what is basically a sound server process when the > sound device is first accessed, but it does not exec. This was not > working well with helix -- by the time helix opens the sound device, it > has several threads running and a number of plugins loaded. Alsa's mixer > process was hanging when forked from helix, for reasons I never figured out. You have to be a member of the helix community in order to get a prebuilt helix player that supports ALSA don't you? I would have liked to have tested this because apparently dmix has had various fixes in the past few months to make it more robust (I think in FC3 it was prone to lockups so it was not enabled by default)... > 2. Pausing was generally broken I haven't tested this so I can't comment. > 3. The first process to play back sound defines the characteristics of > the sound device device. If it open up the device at a low sample rate, > all playback would suffer. Does it? I thought it was fixed in a configuration file (I'm not an ALSA developer or someone who develops apps with ALSA - I'm just looking at http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_dmix ). Perhaps apps should try and work with whatever it defaults to. > 4. Decent alsa documentation was generally lacking. Still lacking from the sounds of it. It's a common complaint : ( > At the time, I fooled around with using esound + alsa + dmix, with > esound set up to always hold the sound device open, and with the alsa > sound server running in a forked esound process. > http://bugzilla.gnome.org/show_bug.cgi?id=140803 > http://sourceforge.net/mailarchive/message.php?msg_id=8898607 > > Currently, the helix we ship with RealPlayer 10 is built to use OSS, as > it's generally the lowest common denominator. We rely on sound servers > like esound releasing the sound device when not in use. I have to inject here. For legacy reasons wouldn't it be better to support esd? Then you would get artsd support for free (sure it will latent but it's better than nothing) and support old OSS systems. Newer systems with ALSA would get ALSA (with dmix) support. (goes away and reads posted links) Heh. You already know this and are submitting patches to make this work. I guess that tells me... > Ideally IMHO dmix / asym would: > - Be a sound server that runs on startup instead of something that forks > off the first process to open the sound device I think you might be better off suggesting this on the alsa-devel list. I don't know if Fedora could afford to deviate too far from upstream ALSA packages so the best thing would be to have a change like this come "down" from upstream. I suspect this won't be a popular idea because the "server-less" set up of dmix appears to have been done for design reasons (low latency problems, no need for RT priorities). I'll give a link in a minute. > - Open the sound device using sensible maximum capabilities of the > device in terms of sampling rate and # of channels, etc. The guys who > write our resamplers generally prefer to have helix doing any sample > rate conversion where possible: > http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/000243.html This doesn't sound like it will happen with dmix (although it could with another ALSA plugin). In the UKUUG paper "Sound Systems on Linux" (http://www.ukuug.org/events/linux2003/papers/TIwai/soundsystems/ ) Takashi Iwai talks a little about the rationale behind dmix. It sounds like the aim is to be simple so existing ALSA apps do not have to be rewritten, low enough latency for consumer use and free of RT-scheduling requirements. > I'm very interested in what others are thinking here for fedora, be it > alsa-related or otherwise. My general take on things so far has been tainted because although helix and real player work great on hardware mixed cards the lack of shipped support for esd/artsd has users wondering why things like real player don't start when they are streaming a radio station in their web browser ('cos the sound device is locked and there's no hardware mixing is the answer). I dearly hope that dmix is shipped in a working default configuration soon because software mixing has always been one of those annoying issues on Linux. My brief experience as a dmix user suggests that it provides the nearest solution for reasonable software mixing in a variety of applications with only binary legacy non-ALSA/esd applications suffering. The downsides of shipping dmix by default in FC4 today appear to be potential inefficiency on hardware mixing cards, sound quality degradation for those that want to do their own resampling and breaking things for people with a second sound card. These trade-offs look reasonable in the short term though. Really, FC4 should not be shipping with apps that don't support dmix'd ALSA or esd and defaulting as much as possible to use ALSA rather than anything else (whether this is a reasonable thing is another question though). I suspect the number of sound servers for typical applications will eventually drop to two - whatever ALSA usually supplies (virtual or otherwise) and esd. Rumour has it that KDE will drop artsd and move to gstreamer and since gstreamer supports both esd and ALSA out of box sound experience on typical consumer hardware should stop being such a mess. -- Sitsofe | http://sucs.org/~sits/ From n3npq at nc.rr.com Sun Feb 6 15:27:57 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 06 Feb 2005 10:27:57 -0500 Subject: rawhide report: 20050206 changes In-Reply-To: <20050206154439.0f1f090e.fedora@wir-sind-cool.org> References: <200502061300.j16D06W32486@porkchop.devel.redhat.com> <20050206154439.0f1f090e.fedora@wir-sind-cool.org> Message-ID: <4206377D.6070801@nc.rr.com> Michael Schwendt wrote: >On Sun, 6 Feb 2005 08:00:06 -0500, Build System wrote: > > > >>New package python-sqlite3 >> Python bindings for sqlite3 >> >>New package sqlite3 >> Library that implements an embeddable SQL database engine >> >> > >Spec file mentions that there are 56 failed tests. Is that still accurate? >The package in fedora.us queue passes all ~15000 tests on i386 and x86_64. > > Accurate as of yesterday. Good for fedora.us. >https://bugzilla.fedora.us/show_bug.cgi?id=2135#c20 > > > 73 de Jeff From katzj at redhat.com Sun Feb 6 15:45:12 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 06 Feb 2005 10:45:12 -0500 Subject: New Install Idea In-Reply-To: <20050206060646.GA26732@jadzia.bu.edu> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> <20050206052721.GA25371@jadzia.bu.edu> <1107669765.26807.31.camel@cutter> <20050206060646.GA26732@jadzia.bu.edu> Message-ID: <1107704713.17681.8.camel@bree.local.net> On Sun, 2005-02-06 at 01:06 -0500, Matthew Miller wrote: > On Sun, Feb 06, 2005 at 01:02:45AM -0500, seth vidal wrote: > > 1. multiple repository support > > 2. a way to set up multiple repositories, sanely, in the gui > > 3. a nice way to handle conflicts and what not from the interface - > > seeing as anaconda has, historically, dealt with consistent repositories > > with complete dependency closure. B/c you know the moment there is > > multiple repo support people will not just do base+updates but base > > +extras+updates+joesrepoofdoom > > So, can we just have anaconda call pup? ... as Seth said, the plan is for anaconda to essentially do this. Although probably not with (exactly) the pup UI. There's a method to the madness and something of a vague roadmap[1] for getting there sanely too ;-) The basic idea is as follows: 1) Get pup working nicely solely for getting updates (nb: pup is the under development update tool to sit on top of yum). 2) Interface along the lines of system-config-packages that allows installation/removal/etc of packages. This will build on the work of pup and allow fleshing out of things like CD information needed for the metadata format. 3) Pull current package handling/dep resolution code out of anaconda. A lot of #2 should drop in. Still single repository. 4) Add support for configuring additional repositories Granted, getting through the entire list is a lot of work and I really don't see it all happening for FC4. Hopefully we'll have the first and at least a good start on the second underway for FC4. Jeremy [1] Which I'll actually be writing up to some extent for my presentation at FUDCon. Once that's done, I'll ensure that it ends up online as well. From mattdm at mattdm.org Sun Feb 6 17:08:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 6 Feb 2005 12:08:58 -0500 Subject: New Install Idea In-Reply-To: <1107704713.17681.8.camel@bree.local.net> References: <200502051748.12010.bms@zoominternet.net> <200502060043.30881.bms@zoominternet.net> <20050206031601.GA20439@jadzia.bu.edu> <200502060345.25504.bms@zoominternet.net> <20050206052721.GA25371@jadzia.bu.edu> <1107669765.26807.31.camel@cutter> <20050206060646.GA26732@jadzia.bu.edu> <1107704713.17681.8.camel@bree.local.net> Message-ID: <20050206170858.GA19133@jadzia.bu.edu> On Sun, Feb 06, 2005 at 10:45:12AM -0500, Jeremy Katz wrote: > [1] Which I'll actually be writing up to some extent for my presentation > at FUDCon. Once that's done, I'll ensure that it ends up online as > well. Cool, thanks. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From giallu at gmail.com Sun Feb 6 18:30:33 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 6 Feb 2005 19:30:33 +0100 Subject: My open tickets in bugzilla.fedora.us Message-ID: I have a couple of pending package requests in bugzilla.fedora.us: https://bugzilla.fedora.us/show_bug.cgi?id=2329 and https://bugzilla.fedora.us/show_bug.cgi?id=2398 that I would like to help you close. The former (a library for visualization of 3D chemical structures) already had positive reviews, and I also included the suggested enhancements. The latter is just a port to FC3 of an already published (by livna) package: alleyoop, a gnome based frontend for valgrind. Better to submit the same requests to bugzilla.redhat.com so we can close to fedora.us ones? Cheers Gianluca From mr700 at globalnet.bg Sun Feb 6 22:08:03 2005 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Mon, 7 Feb 2005 00:08:03 +0200 Subject: SSL certificate management/storage In-Reply-To: <4204A75E.7BD1FC37@jwz.org> References: <20050204162512.GA23731@redhat.com> <1107596698.11240.785.camel@speedy.iagorubio.net> <4204A75E.7BD1FC37@jwz.org> Message-ID: <200502070008.03585@-mr700> On 2005-02-05 (Saturday) 13:00, Jamie Zawinski wrote: > Iago Rubio wrote: > > > > Could be a problem to assume this, as self-signed certificates does not > > require a CA - that'll pick some bucks from you to sign your > > certificates - and it's sure self-signed certificates will be hanging > > around for a while, because they're cheaper than CA signed ones. > > Absolutely -- I use pop3s (and a self-signed ssl cert) for my employees' > email, and I'm sure not going to tithe anually to Verisign or whoever > merely to avoid a one-time warning dialog for my dozen users. I'm sure > lots of other small companies feel the same way. I use self-signed CA. You can, as I do, install this CA's cert in your user's PCs and get no warnings :) I see no reason buying certificates unless you want to use them with a public service. -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From giallu at gmail.com Sun Feb 6 22:56:45 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 6 Feb 2005 23:56:45 +0100 Subject: My open tickets in bugzilla.fedora.us In-Reply-To: References: Message-ID: Oops, sorry, this was meant for the fedora-extras list... On Sun, 6 Feb 2005 19:30:33 +0100, Gianluca Sforna wrote: > I have a couple of pending package requests in bugzilla.fedora.us: > https://bugzilla.fedora.us/show_bug.cgi?id=2329 > and > https://bugzilla.fedora.us/show_bug.cgi?id=2398 > that I would like to help you close. > > The former (a library for visualization of 3D chemical structures) > already had positive reviews, and I also included the suggested > enhancements. > The latter is just a port to FC3 of an already published (by livna) > package: alleyoop, a gnome based frontend for valgrind. > Better to submit the same requests to bugzilla.redhat.com so we can > close to fedora.us ones? > > Cheers > > Gianluca > From twaugh at redhat.com Mon Feb 7 00:16:58 2005 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 7 Feb 2005 00:16:58 +0000 Subject: rawhide report: 20050205 changes In-Reply-To: <1107681668.22680.55.camel@laptopd505.fenrus.org> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> Message-ID: <20050207001658.GM10885@redhat.com> On Sun, Feb 06, 2005 at 10:21:08AM +0100, Arjan van de Ven wrote: > this is already wrong. The "athlon" hack is *WRONG*. Athlon is a > marketing name, it could just as well be a duron or a sempron. > It was a mistake to put the athlon hack in uname (but hindsight is > easy); it's imo very wrong to repeat that mistake. Should I take it out? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Mon Feb 7 01:53:26 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sun, 6 Feb 2005 18:53:26 -0700 Subject: Fedora Core 3 (4?) Live CD In-Reply-To: <1107688393.5367.94.camel@localhost.localdomain> References: <20050204221256.GB11004@rogers.com> <1107688393.5367.94.camel@localhost.localdomain> Message-ID: <80d7e409050206175342cd6ab2@mail.gmail.com> On Sun, 06 Feb 2005 19:13:13 +0800, Colin Charles wrote: > On Fri, 2005-02-04 at 17:12 -0500, Dimitrie O. Paun wrote: > > I was looking the other day for a Fedora Live CD, but couldn't > > find anything out there. For whatever reason, I thought FC3 > > had a Live CD... Am I missing something? If not, any plans to > > have one for FC4? > > On the agenda for discussion at FUDCon is definitely to talk about a > Fedora LiveCD, created via the Stateless Linux system > > There is however one that Dirk Westfal has created, thats pretty good as > well, so give that a twirl Pointers of where I could find that? We have some questions for setting up a lot of diskless workstations that would use the Stateless Disk system. -- Stephen J Smoogen. CSIRT/Linux System Administrator From aoliva at redhat.com Mon Feb 7 02:20:45 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Feb 2005 00:20:45 -0200 Subject: no openoffice.org-kde in development/x86_64? Message-ID: Is it not there on purpose? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dag at wieers.com Mon Feb 7 02:44:03 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 7 Feb 2005 03:44:03 +0100 (CET) Subject: Better repodata performance In-Reply-To: References: <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <41FC2248.3010100@sbcglobal.net> <20050130001209.GE21431@angus.ind.WPI.EDU> Message-ID: On Sun, 29 Jan 2005, Alexandre Oliva wrote: > On Jan 29, 2005, "Charles R. Anderson" wrote: > > > Why all the complication when a general-purpose algorithm, rsync, > > already exists to solve this problem? > > It doesn't do very well on compressed files, and there aren't a lot of > rsync-enabled web proxies out there. You may like this RFE: https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=391 gzip has an --rsyncable option that is missing from the python zlib implementation. If python/zlib could be taught this, and createrepo is able to use it, the metadata would be rsyncable (improves transferspeed for repo maintainers/mirrors). -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Mon Feb 7 03:09:31 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 7 Feb 2005 04:09:31 +0100 (CET) Subject: radical suggestion for fc4 release In-Reply-To: <1107210964.5291.52.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107210964.5291.52.camel@opus.phy.duke.edu> Message-ID: On Mon, 31 Jan 2005, seth vidal wrote: > On Mon, 2005-01-31 at 17:34 -0500, Nick Bargnesi wrote: > > On Mon, 31 Jan 2005 17:04:36 -0500, seth vidal wrote: > > > Hi folks, > > > this is a touch silly but possibly useful and it would definitely cut > > > down on the old crap blocking up cdroms. > > > > > > how about if we kill all rpm spec file changelog entries OLDER than 2 > > > years. > > > > > > they'll still live on in older srpms and rpms but it'd be a useful > > > reduction and it would make the specfiles that much smaller, along with > > > the rpm headers. > > > > > > thoughts? > > > > It'd be interesting to see how much space something like this would save first. > > Why first? What's the loss in doing it and moving along? > > the changelogs would be in cvs FOR EVER and in old srpms and on old isos > and... and... and... > > it seems like it is an immediate, not-huge win. > > heck it doesn't even have to happen immediately - just the next time > someone edits the spec file - just chop out all the old entries beyond 2 > yrs. > > if we did that right before every release it's easy to keep track of. > > hell, once a year would be enough. This is exactly one of the things I wanted to add to the pre-processing of the SPEC files before building. I hope we can add a modular plugin-system to pydar that is able to pre-process SPEC files before building binary packages and before building source packages (changing Release, Vendor, Packager, Distribution, SPEC filenames, trimming changelog, omitting epochs for cAos, remapping build-requirements/requirements, maybe using another pre-processing language...) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From zuirdj at gmail.com Mon Feb 7 04:02:38 2005 From: zuirdj at gmail.com (Zuir DJ) Date: Mon, 7 Feb 2005 01:02:38 -0300 Subject: Request for inclusion: gateway Message-ID: Please, a graphical method for doing this (or something like this): http://www.fedoranews.org/ghenry/gateway/ --- Zuirdj From dcbw at redhat.com Mon Feb 7 04:18:42 2005 From: dcbw at redhat.com (Dan Williams) Date: Sun, 6 Feb 2005 23:18:42 -0500 (EST) Subject: no openoffice.org-kde in development/x86_64? In-Reply-To: References: Message-ID: On Sun, 7 Feb 2005, Alexandre Oliva wrote: > Is it not there on purpose? Um, no, I wasn't aware of it. OOo is only 32-bit at this time, so what gets into the x86_64 tree will be 32-bit only anyway. And I don't have any idea how the repomagic works to copy over the i386 RPMs to x86_64 repos either. I just build the packages for i386 & PPC32 and beehive takes care of the rest as far as I'm aware. Its certainly not _supposed_ to be on purpose unless somebody had a problem with it. It would definitely mean pulling in all of 32-bit KDE onto an x86-64 box, so if KDE has multilib problems, then maybe that's why it got excluded. Dan From arjanv at redhat.com Mon Feb 7 06:24:19 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 7 Feb 2005 07:24:19 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <20050207001658.GM10885@redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> <20050207001658.GM10885@redhat.com> Message-ID: <20050207062419.GA25337@devserv.devel.redhat.com> On Mon, Feb 07, 2005 at 12:16:58AM +0000, Tim Waugh wrote: > On Sun, Feb 06, 2005 at 10:21:08AM +0100, Arjan van de Ven wrote: > > > this is already wrong. The "athlon" hack is *WRONG*. Athlon is a > > marketing name, it could just as well be a duron or a sempron. > > It was a mistake to put the athlon hack in uname (but hindsight is > > easy); it's imo very wrong to repeat that mistake. > > Should I take it out? hard dilemma in that it risks breaking existing stuff.... but if it wasn't for that I'd say yes. From dpaun at rogers.com Mon Feb 7 06:35:36 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 7 Feb 2005 01:35:36 -0500 Subject: Fedora Core 3 (4?) Live CD In-Reply-To: <42049484.6030901@nwst.de> References: <20050204221256.GB11004@rogers.com> <42049484.6030901@nwst.de> Message-ID: <20050207063536.GC6823@rogers.com> On Sat, Feb 05, 2005 at 10:40:20AM +0100, livelinux at nwst.de wrote: > This might be for you: > > a fedora core 3 with gnome/kde and kernel 2.6.8 > http://www.linux4all.de/livecd/basilisk/1.40/ Cool, thank you very much. > Screenshots & snapshots (unsigned fc3 rpm) can be found here: > http://www.linux4all.de/livecd/livecdanaconda There are a bunch of broken links on this page. Is it a known problem? -- Dimi. From mattdm at mattdm.org Mon Feb 7 06:39:18 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 7 Feb 2005 01:39:18 -0500 Subject: updated Festival (text-to-speech) rpms Message-ID: <20050207063918.GA12229@jadzia.bu.edu> Preliminary packages to use as a base (shouldn't require much more work at all): And bug requesting update: It'd be super-cool to get this in for the FC4 release, but I understand we're getting close, so there it is for the future if that is missed. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From lkml at mac.com Mon Feb 7 07:29:56 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Mon, 7 Feb 2005 08:29:56 +0100 Subject: Request for inclusion: gateway In-Reply-To: References: Message-ID: <1a5869f4d9f93368ad67e1650d9dcc66@mac.com> On 7 Feb 2005, at 05:02, Zuir DJ wrote: > Please, a graphical method for doing this (or something like this): > http://www.fedoranews.org/ghenry/gateway/ use system-config-network From n3npq at nc.rr.com Mon Feb 7 07:40:14 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 07 Feb 2005 02:40:14 -0500 Subject: Better repodata performance In-Reply-To: References: <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <41FC2248.3010100@sbcglobal.net> <20050130001209.GE21431@angus.ind.WPI.EDU> Message-ID: <42071B5E.7010507@nc.rr.com> Dag Wieers wrote: >On Sun, 29 Jan 2005, Alexandre Oliva wrote: > > > >>On Jan 29, 2005, "Charles R. Anderson" wrote: >> >> >> >>>Why all the complication when a general-purpose algorithm, rsync, >>>already exists to solve this problem? >>> >>> >>It doesn't do very well on compressed files, and there aren't a lot of >>rsync-enabled web proxies out there. >> >> > >You may like this RFE: > > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=391 > >gzip has an --rsyncable option that is missing from the python zlib >implementation. If python/zlib could be taught this, and createrepo >is able to use it, the metadata would be rsyncable (improves >transferspeed for repo maintainers/mirrors) > The necessary patch is at https://svn.uhulinux.hu/packages/dev/zlib/patches/02-rsync.patch The patch is also in rpm-4.4., zlib bundled into -lrpmio, with a "rpmz_" uniqifier on zlib symbols. 73 de Jeff From strange at nsk.no-ip.org Mon Feb 7 07:26:11 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 7 Feb 2005 07:26:11 +0000 Subject: rawhide report: 20050205 changes In-Reply-To: <20050207062419.GA25337@devserv.devel.redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> <20050207001658.GM10885@redhat.com> <20050207062419.GA25337@devserv.devel.redhat.com> Message-ID: <20050207072611.GA10759@nsk.no-ip.org> On Mon, Feb 07, 2005 at 07:24:19AM +0100, Arjan van de Ven wrote: > > On Mon, Feb 07, 2005 at 12:16:58AM +0000, Tim Waugh wrote: > > On Sun, Feb 06, 2005 at 10:21:08AM +0100, Arjan van de Ven wrote: > > > > > this is already wrong. The "athlon" hack is *WRONG*. Athlon is a > > > marketing name, it could just as well be a duron or a sempron. > > > It was a mistake to put the athlon hack in uname (but hindsight is > > > easy); it's imo very wrong to repeat that mistake. > > > > Should I take it out? > > hard dilemma in that it risks breaking existing stuff.... but if it wasn't > for that I'd say yes. It's not as if that would be the first time that stuff is broken by depending on a bug. If the hack is incorrect, then let it be taken out and broken applications corrected. Regards, Luciano Rocha -- 4/11 From aoliva at redhat.com Mon Feb 7 09:24:37 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Feb 2005 07:24:37 -0200 Subject: no openoffice.org-kde in development/x86_64? In-Reply-To: References: Message-ID: On Feb 7, 2005, Dan Williams wrote: > Its certainly not _supposed_ to be on purpose unless somebody had a > problem with it. It would definitely mean pulling in all of 32-bit > KDE onto an x86-64 box, so if KDE has multilib problems, then maybe > that's why it got excluded. It doesn't have any problem AFAICT. The OOo-kde.i386 package installs just fine on an everything install of rawhide on AMD64. It's probably something in the comps file. openoffice.org-kde is not listed anywhere. Heck, not even in the i386 comps.xml! -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dragoran at feuerpokemon.de Mon Feb 7 09:25:23 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 07 Feb 2005 10:25:23 +0100 Subject: updated Festival (text-to-speech) rpms In-Reply-To: <20050207063918.GA12229@jadzia.bu.edu> References: <20050207063918.GA12229@jadzia.bu.edu> Message-ID: <42073403.4000602@feuerpokemon.de> >Preliminary packages to use as a base (shouldn't require much more work at >all): > >And bug requesting update: > > >It'd be super-cool to get this in for the FC4 release, but I understand >we're getting close, so there it is for the future if that is missed. > > > can you also add some non us voices? From aoliva at redhat.com Mon Feb 7 09:27:35 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Feb 2005 07:27:35 -0200 Subject: rawhide report: 20050205 changes In-Reply-To: <20050207062419.GA25337@devserv.devel.redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> <20050207001658.GM10885@redhat.com> <20050207062419.GA25337@devserv.devel.redhat.com> Message-ID: On Feb 7, 2005, Arjan van de Ven wrote: > On Mon, Feb 07, 2005 at 12:16:58AM +0000, Tim Waugh wrote: >> On Sun, Feb 06, 2005 at 10:21:08AM +0100, Arjan van de Ven wrote: >> >> > this is already wrong. The "athlon" hack is *WRONG*. Athlon is a >> > marketing name, it could just as well be a duron or a sempron. >> > It was a mistake to put the athlon hack in uname (but hindsight is >> > easy); it's imo very wrong to repeat that mistake. >> >> Should I take it out? > hard dilemma in that it risks breaking existing stuff.... The most common case in which I've seen scripts depend on athlon or ia32e is to build kernels and kernel modules. Since the removal of athlon- and ia32e-specific kernels, having uname print athlon or ia32e no longer helps; it actually gets in the way. So my vote would be to get rid of it. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From rahulsundaram at gmail.com Mon Feb 7 10:18:51 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 7 Feb 2005 15:48:51 +0530 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: References: <4205269D.3040106@nc.rr.com> <1107637196.4277.67.camel@localhost.localdomain> Message-ID: Hi > > Have done both, got nowhere fast. To be fixed in FC4 is what I'm told. > Don't even know what it is that will be fixed. I even tried to build my own > firefox and got stuck on the same problem (with a different symptom, something > with shlibsign) do you have bugzilla numbers?. rest assured this problem is not wide spread -- Regards, Rahul Sundaram From aoliva at redhat.com Mon Feb 7 10:37:47 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Feb 2005 08:37:47 -0200 Subject: no openoffice.org-kde in development/x86_64? In-Reply-To: References: Message-ID: On Feb 7, 2005, Alexandre Oliva wrote: > On Feb 7, 2005, Dan Williams wrote: >> Its certainly not _supposed_ to be on purpose unless somebody had a >> problem with it. It would definitely mean pulling in all of 32-bit >> KDE onto an x86-64 box, so if KDE has multilib problems, then maybe >> that's why it got excluded. > It doesn't have any problem AFAICT. The OOo-kde.i386 package installs > just fine on an everything install of rawhide on AMD64. > It's probably something in the comps file. openoffice.org-kde is not > listed anywhere. Heck, not even in the i386 comps.xml! BZ#147322 just opened. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From buildsys at redhat.com Mon Feb 7 10:58:53 2005 From: buildsys at redhat.com (Build System) Date: Mon, 7 Feb 2005 05:58:53 -0500 Subject: rawhide report: 20050207 changes Message-ID: <200502071058.j17Awro26452@porkchop.devel.redhat.com> Updated Packages: beecrypt-4.1.2-1 ---------------- * Sat Feb 05 2005 Jeff Johnson 4.1.2-1 - upgrade to 4.1.2 - put java components in sub-package. - check that /usr/lib64 is not used on alpha (#146583). dvgrab-1.7-1 ------------ * Sun Feb 06 2005 Warren Togami 1.7-1 - 1.7 gstreamer-plugins-0.8.7-3 ------------------------- * Sun Feb 06 2005 Warren Togami - 0.8.7-3 - rebuild against new libraw1394 kdebase-6:3.3.2-0.3 ------------------- * Sun Feb 06 2005 Warren Togami 6:3.3.2-0.3 - rebuild against new libraw1394 libavc1394-0.4.1-6 ------------------ * Sun Feb 06 2005 Warren Togami 0.4.1-6 - rebuild against new libraw1394 libdv-0:0.103-2 --------------- * Sun Feb 06 2005 Warren Togami - 0:0.103-2 - Fix erroneously requiring an executable stack (Nicholas Miell #146590) libraw1394-1.1.0-1 ------------------ * Sun Feb 06 2005 Warren Togami 1.1.0-1 - 1.1.0 libtool-1.5.12.multilib2-3.4.3 ------------------------------ * Sun Feb 06 2005 Daniel Reed 1.5.12.multilib2-3.4.3 - update to the 1.5.12 bugfix release - Makes use of $datarootdir, which is necessary for Autoconf >= 2.60. - Correctly skip hppa, x86_64, and s390* in tests/demo-nopic.test. - Interpret `include' statements in toplevel ld.so.conf file. - While "parsing" /etc/ld.so.conf, skip comments. - add dependency on gcc version; /usr/bin/libtool hardcodes paths into gcc's internal directories - replace "libtool-libs" with "libtool-ltdl" and "libtool-ltdl-devel" rpm-4.4.1-0.18 -------------- * Wed Feb 02 2005 Jeff Johnson 4.4.1-0.16 - fix: length of gpg V4 hash seed was incorrect (#146896). - add support for V4 rfc-2440 signatures. rpmdb-fedora-1:4-0.20050207 --------------------------- From niki.waibel at newlogic.com Mon Feb 7 11:08:54 2005 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon, 07 Feb 2005 12:08:54 +0100 (MET) Subject: dmraud in initrd in fc4 Message-ID: <200502071108.j17B8s66028538@enterprise2.newlogic.at> have not found any mails in this list about dmraid... is it planned to put it into the fc4 initrd, to be able to boot from ie serial ata raid drives (a simple >>dmraid -ay<< at the right position of the boot script should be sufficient. maybe some sata_XXX and dmraidXXX modules have to be loaded before ...)? maybe it is already there -- have not yet found time to test fc4-testX ... rds, niki -- niki w. waibel - system administrator @ newlogic technologies ag From rc040203 at freenet.de Mon Feb 7 11:10:37 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 07 Feb 2005 12:10:37 +0100 Subject: x86_64 gcc multilibs Message-ID: <1107774637.6185.43.camel@columbo.corsepiu.local> Hi, Is it correct, that FC3's gcc on x86_64 uses these multilibs: $ x86_64-redhat-linux-gcc -print-multi-lib .; 32;@m32 IMO, this is wrong and should either be (assuming . matching -m64 | lib64) .; 32;../lib or (assuming . matching -m32 | lib) .; 64;../lib64 If x86_64 gcc was using one of the latter muliblib-sets, gcc -m64 -L/xxx/lib would automatically pickup m64 compiled libs from /xxx/lib/../lib64, instead of those from /xxx/lib. Unfortunately I don't have access to x86_64 systems :-( Ralf From Axel.Thimm at ATrpms.net Mon Feb 7 10:23:37 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Feb 2005 11:23:37 +0100 Subject: updated Festival (text-to-speech) rpms In-Reply-To: <20050207063918.GA12229@jadzia.bu.edu> References: <20050207063918.GA12229@jadzia.bu.edu> Message-ID: <20050207102337.GI9362@neu.nirvana> On Mon, Feb 07, 2005 at 01:39:18AM -0500, Matthew Miller wrote: > Preliminary packages to use as a base (shouldn't require much more work at > all): > > And bug requesting update: > > > It'd be super-cool to get this in for the FC4 release, but I understand > we're getting close, so there it is for the future if that is missed. Thanks! Any reasons, why there are no x86_64 packages? I've asked a couple times, the festival authors claim to run cross-platform, still there is no x86_64 build or any explanation why there should be none. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128621 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From si at bananas.hopto.org Mon Feb 7 11:25:29 2005 From: si at bananas.hopto.org (Si Jones) Date: Mon, 7 Feb 2005 11:25:29 -0000 (GMT) Subject: Athlon64 Access Message-ID: <24194.195.8.190.39.1107775529.squirrel@bananas.hopto.org> Hi Everyone, Noticed that some of you require athlon64 access, if you require one that is standard FC3 build then please email me with your details and I will set you up a ssh account. This should be enough for you to sort some of the cross-platform problems? From jakub at redhat.com Mon Feb 7 11:26:22 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 7 Feb 2005 06:26:22 -0500 Subject: x86_64 gcc multilibs In-Reply-To: <1107774637.6185.43.camel@columbo.corsepiu.local> References: <1107774637.6185.43.camel@columbo.corsepiu.local> Message-ID: <20050207112622.GA11199@devserv.devel.redhat.com> On Mon, Feb 07, 2005 at 12:10:37PM +0100, Ralf Corsepius wrote: > Hi, > > Is it correct, that FC3's gcc on x86_64 uses these multilibs: > > $ x86_64-redhat-linux-gcc -print-multi-lib > .; > 32;@m32 > > IMO, this is wrong and should either be > (assuming . matching -m64 | lib64) > .; > 32;../lib > > or (assuming . matching -m32 | lib) > .; > 64;../lib64 > > If x86_64 gcc was using one of the latter muliblib-sets, > gcc -m64 -L/xxx/lib > would automatically pickup m64 compiled libs from /xxx/lib/../lib64, > instead of those from /xxx/lib. > > Unfortunately I don't have access to x86_64 systems :-( Nope, it is correct. -print-multi-lib is about what multilib combinations exists and the relative path they are using inside of /usr/lib/gcc/*/*/ etc. -print-multi-os-directory is what tells you the relative path used to search multilib directories that are under OS rather than GCC's convention. For gcc that defaults to -m64 you get: gcc -print-multi-os-directory -m32; gcc -print-multi-os-directory -m64; gcc -print-multi-os-directory ../lib ../lib64 ../lib64 Jakub From rc040203 at freenet.de Mon Feb 7 12:07:03 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 07 Feb 2005 13:07:03 +0100 Subject: x86_64 gcc multilibs In-Reply-To: <20050207112622.GA11199@devserv.devel.redhat.com> References: <1107774637.6185.43.camel@columbo.corsepiu.local> <20050207112622.GA11199@devserv.devel.redhat.com> Message-ID: <1107778023.6185.60.camel@columbo.corsepiu.local> On Mon, 2005-02-07 at 06:26 -0500, Jakub Jelinek wrote: > On Mon, Feb 07, 2005 at 12:10:37PM +0100, Ralf Corsepius wrote: > > Hi, > > > > Is it correct, that FC3's gcc on x86_64 uses these multilibs: > > > > $ x86_64-redhat-linux-gcc -print-multi-lib > > .; > > 32;@m32 > > > > IMO, this is wrong and should either be > > (assuming . matching -m64 | lib64) > > .; > > 32;../lib > > > > or (assuming . matching -m32 | lib) > > .; > > 64;../lib64 > > > > If x86_64 gcc was using one of the latter muliblib-sets, > > gcc -m64 -L/xxx/lib > > would automatically pickup m64 compiled libs from /xxx/lib/../lib64, > > instead of those from /xxx/lib. > > > > Unfortunately I don't have access to x86_64 systems :-( > > Nope, it is correct. -print-multi-lib is about what multilib combinations > exists and the relative path they are using inside of /usr/lib/gcc/*/*/ > etc. Hmm, all multilib'ed OSes I have been using sofar used the relative path being contained in the second half of -print-multi-libs, as part of their library search path. This also is what I see in genmultilib: ... # The optional seventh argument is a list of OS subdirectory names. # The format is either the same as of the second argument, or a set of # mappings. When it is the same as the second argument, it describes # the multilib directories using OS conventions, rather than GCC # conventions. When it is a set of mappings of the form gccdir=osdir, # the left side gives the GCC convention and the right gives the # equivalent OS defined location. If the osdir part begins with a !, # the os directory names are used exclusively. Use the mapping when # there is no one-to-one equivalence between GCC levels and the OS. # The last option should be "yes" if multilibs are enabled. If it is not # "yes", all GCC multilib dir names will be ".". # The output looks like # #define MULTILIB_MATCHES "\ # SUBDIRECTORY OPTIONS;\ # ... # " # ... # Here is an example (this is from the actual sparc64 case): # genmultilib 'm64/m32 mno-app-regs|mcmodel=medany' '64 32 alt' # 'mcmodel?medany=mcmodel?medmid' 'm32/mno-app-regs* m32/mcmodel= # '' 'm32/!m64/mno-app-regs m32/!m64/mcmodel=medany' # '../lib64 ../lib32 alt' yes # This produces: # ". !m64 !m32 !mno-app-regs !mcmodel=medany;", # "64:../lib64 m64 !m32 !mno-app-regs !mcmodel=medany;", # "32:../lib32 !m64 m32 !mno-app-regs !mcmodel=medany;", # "alt !m64 !m32 mno-app-regs mcmodel=medany;", # "alt !m64 !m32 mno-app-regs !mcmodel=medany;", # "alt !m64 !m32 !mno-app-regs mcmodel=medany;", # "64/alt:../lib64/alt m64 !m32 mno-app-regs mcmodel=medany;", # "64/alt:../lib64/alt m64 !m32 mno-app-regs !mcmodel=medany;", # "64/alt:../lib64/alt m64 !m32 !mno-app-regs mcmodel=medany;", # # The effect is that `gcc -mno-app-regs' (for example) will append "alt" # to the directory name when searching for libraries or startup files and # `gcc -m32 -mcmodel=medany' (for example) will append "32/alt". Also note # that exclusion above is moot, unless the compiler had a default of - m32, # which would mean that all of the "alt" directories (not the 64/alt ones) # would be ignored (not generated, nor used) since the exclusion also # matches the multilib_default args. I read this as: x86_64-redhat-gcc -m64 should on ../lib64 > -print-multi-os-directory is what tells you the relative path > used to search multilib directories that are under OS rather than GCC's > convention. > For gcc that defaults to -m64 you get: > gcc -print-multi-os-directory -m32; gcc -print-multi-os-directory -m64; gcc -print-multi-os-directory > ../lib > ../lib64 > ../lib64 Then something else must be broken. I received complaints about programs trying to be linked as x86_64-redhat-gcc -m64 ... -L/usr/X11R6/lib to complain about 32 libs. This indicates that -m64 does not search on ../lib64 Ralf From ndbecker2 at verizon.net Mon Feb 7 12:10:13 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Mon, 07 Feb 2005 07:10:13 -0500 Subject: teTeX 3.0 released Message-ID: http://freshmeat.net/projects/tetex/?branch_id=10361&release_id=187066 From Axel.Thimm at ATrpms.net Mon Feb 7 10:28:24 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Feb 2005 11:28:24 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: <20050207072611.GA10759@nsk.no-ip.org> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> <20050207001658.GM10885@redhat.com> <20050207062419.GA25337@devserv.devel.redhat.com> <20050207072611.GA10759@nsk.no-ip.org> Message-ID: <20050207102824.GJ9362@neu.nirvana> On Mon, Feb 07, 2005 at 07:26:11AM +0000, Luciano Miguel Ferreira Rocha wrote: > On Mon, Feb 07, 2005 at 07:24:19AM +0100, Arjan van de Ven wrote: > > > > On Mon, Feb 07, 2005 at 12:16:58AM +0000, Tim Waugh wrote: > > > On Sun, Feb 06, 2005 at 10:21:08AM +0100, Arjan van de Ven wrote: > > > > this is already wrong. The "athlon" hack is *WRONG*. Athlon is a > > > > marketing name, it could just as well be a duron or a sempron. > > > > It was a mistake to put the athlon hack in uname (but hindsight is > > > > easy); it's imo very wrong to repeat that mistake. > > > > > > Should I take it out? > > > > hard dilemma in that it risks breaking existing stuff.... but if it wasn't > > for that I'd say yes. Would after removing athlon from uname rpm still detect "athlon" as its target architecture? FWIW the athlon.rpm naming scheme is then just as broken (athlon.rpm work on duron, too), so enforcing this strict policy would color off rpm packages as well (resulting to k8.rpm?) > It's not as if that would be the first time that stuff is broken by > depending on a bug. > > If the hack is incorrect, then let it be taken out and broken > applications corrected. IMHO, that should not happen for FC4. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Mon Feb 7 14:10:45 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 7 Feb 2005 09:10:45 -0500 Subject: updated Festival (text-to-speech) rpms In-Reply-To: <42073403.4000602@feuerpokemon.de> References: <20050207063918.GA12229@jadzia.bu.edu> <42073403.4000602@feuerpokemon.de> Message-ID: <20050207141045.GA22546@jadzia.bu.edu> On Mon, Feb 07, 2005 at 10:25:23AM +0100, dragoran wrote: > can you also add some non us voices? I'd love to. Unfortunately, not all are under a free license. The British ones and the OGI voices (which include German and Mexican Spanish) and have more restrictive licenses and can't be included. If you know of any that could go in, I'll definitely add 'em. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From mattdm at mattdm.org Mon Feb 7 14:12:38 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 7 Feb 2005 09:12:38 -0500 Subject: updated Festival (text-to-speech) rpms In-Reply-To: <20050207102337.GI9362@neu.nirvana> References: <20050207063918.GA12229@jadzia.bu.edu> <20050207102337.GI9362@neu.nirvana> Message-ID: <20050207141238.GB22546@jadzia.bu.edu> On Mon, Feb 07, 2005 at 11:23:37AM +0100, Axel Thimm wrote: > Thanks! Any reasons, why there are no x86_64 packages? None other than "I don't have enough machines, so my x86_64 systems need to run in 32 bit mode right now because that's what we're developing on here". -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From walters at redhat.com Mon Feb 7 15:45:35 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 07 Feb 2005 10:45:35 -0500 Subject: Sharing sound hardware In-Reply-To: <4204AD22.8020605@yahoo.co.uk> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> <4204AD22.8020605@yahoo.co.uk> Message-ID: <1107791135.5321.16.camel@nexus.verbum.private> On Sat, 2005-02-05 at 11:25 +0000, Dariusz J. Garbowski wrote: > Please, no! This sounds really bad to me (pun intended ;-) I own a card > that can do hardware mixing and really don't like the idea of "being > punished" for that. Especially by something like upsampling almost every > sound I play from 44.1 to 48kHz. And yes, I will notice (is it really > 99% of the users who won't? where does this number come from?) -- decent > amplifier, cables and loudspeakers do just that: you start noticing. Sure; but I think it's better to fix one huge, extremely user-visible bug (multiple apps playing sound not working and getting weird error messages) and introduce some smaller bugs (sound mixing not taking advantage of hardware mixing). Particularly when there's no obvious major technical difficulty in fixing the smaller bug. In other words, two steps forward and a temporary one back is better than none at all. > The reason I'm really worried here is that I recall Colin Walters saying > that dmix will be on for everybody in FC4: > > https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00614.html Nothing is final; I just wanted to experiment with it in rawhide for a while and get feedback. Right now unfortunately it's off again by default pending the outcome of a discussion between the new ALSA package maintainer and me. > Question: will there be a SIMPLE way (a script or HOWTO/FAQ would do) to > turn dmix off for those whose soundcard can do hardware mixing so they > can use their hardware the way it was intended to? Yeah; overriding ALSA_PCM_DEFAULT should do the trick if with my alsa-launch approach. > If so, *please* include a note how to do it in Release Notes for FC4. I wouldn't ask for a config option or a release note item first; you really just want the bug fixed, right? If that doesn't get done, then we fall back to the former. From walters at redhat.com Mon Feb 7 16:01:47 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 07 Feb 2005 11:01:47 -0500 Subject: Sharing sound hardware In-Reply-To: <42042B18.2090207@real.com> References: <42042B18.2090207@real.com> Message-ID: <1107792107.5321.27.camel@nexus.verbum.private> On Fri, 2005-02-04 at 18:10 -0800, Ryan Gammon wrote: > The alsa api, while pretty complex, gives good access to all the > features a given piece of hardware supports. The fact that alsa has an > awareness of the hardware it's running on gives it the ability to > (eventually) be smarter when it comes to things like mixing in hardware > vs mixing in software. Right; a number of us feel that it makes the most sense to have software mixing below the ALSA API, so that app writers don't have to make a choice between accessing card features and sound mixing. > I did some playing around with dmix last year when I was touching up > helix's alsa support, and found it to be pretty buggy on the alsa side. Yeah. > Some of this may be incorrect, but as I recall: > > 1. libasound forks what is basically a sound server process when the > sound device is first accessed, but it does not exec. This was not > working well with helix -- by the time helix opens the sound device, it > has several threads running and a number of plugins loaded. Alsa's mixer > process was hanging when forked from helix, for reasons I never figured out. Ultimately we may need a real sound server and protocol below ALSA based on something other than shm, so that there can be better access control for multiple users and also for networked sound. > I'm very interested in what others are thinking here for fedora, be it > alsa-related or otherwise. My personal feelings are that we should try it as the default in Fedora rawhide for a while, get a good sense of what bugs there are, and back off near the end of the FC4 cycle if there are too many. And if there aren't, then we've taken a big step forward on fixing one major user-visible pain that I'm sure every Linux user has experienced. From green at redhat.com Mon Feb 7 16:36:48 2005 From: green at redhat.com (Anthony Green) Date: Mon, 07 Feb 2005 08:36:48 -0800 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <200502071058.j17Awro26452@porkchop.devel.redhat.com> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> Message-ID: <1107794208.19169.32.camel@localhost.localdomain> On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: > beecrypt-4.1.2-1 > ---------------- > * Sat Feb 05 2005 Jeff Johnson 4.1.2-1 > - upgrade to 4.1.2 > - put java components in sub-package. > - check that /usr/lib64 is not used on alpha (#146583). You called this sub-package beecrypt-java. I suggest renaming this to something like beecrypt-java-jni. It only contains the JNI C side of the beecrypt java library. The library of java code for beecrypt is widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). beecrypt-java hasn't been packaged yet, but it will surely require this beecrypt-java-jni. AG From richard.hubbell at gmail.com Mon Feb 7 16:43:09 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Mon, 7 Feb 2005 08:43:09 -0800 Subject: do RHE3 fixes get ported into FC and vice-versa? In-Reply-To: References: <4205269D.3040106@nc.rr.com> <1107637196.4277.67.camel@localhost.localdomain> Message-ID: On Mon, 7 Feb 2005 15:48:51 +0530, Rahul Sundaram wrote: > Hi > > > > Have done both, got nowhere fast. To be fixed in FC4 is what I'm told. > > Don't even know what it is that will be fixed. I even tried to build my own > > firefox and got stuck on the same problem (with a different symptom, something > > with shlibsign) > > do you have bugzilla numbers?. rest assured this problem is not wide spread I guess I don't care if it's widespread. Sure I can understand others might care. It's all about me. (^; https://bugzilla.redhat.com/beta/show_bug.cgi?id=146339 I thought it was a gcc bug but it's not clear, but since it's unclear that led me to think it's a gcc bug. When I look at the core it appears to be some kind of race condition but I'm an amateur core file sleuth. I think this paragraph is in a race condition.... I did post my kickstart file and would be curious to know if anyone else can repro. I was able to repro. Richard > > -- > Regards, > Rahul Sundaram > From n3npq at nc.rr.com Mon Feb 7 16:45:06 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 07 Feb 2005 11:45:06 -0500 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107794208.19169.32.camel@localhost.localdomain> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> Message-ID: <42079B12.4040102@nc.rr.com> Anthony Green wrote: >On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: > > >>beecrypt-4.1.2-1 >>---------------- >>* Sat Feb 05 2005 Jeff Johnson 4.1.2-1 >>- upgrade to 4.1.2 >>- put java components in sub-package. >>- check that /usr/lib64 is not used on alpha (#146583). >> >> > >You called this sub-package beecrypt-java. I suggest renaming this to >something like beecrypt-java-jni. It only contains the JNI C side of >the beecrypt java library. The library of java code for beecrypt is >widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). >beecrypt-java hasn't been packaged yet, but it will surely require this >beecrypt-java-jni. > > Heh, "This space reserved." is perhaps not the right approach. Hint: A ptr to what is likely to be the best upstream source for beecrypt-java-2.0.0.zip in bugzilla will fix "hasn't been packaged yet" faster than anything. Otherwise you'll have to wait until I talk to Bob Deblier in 2 weeks or so ... 73 de Jeff From fedora-devel at camperquake.de Mon Feb 7 16:59:07 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 7 Feb 2005 17:59:07 +0100 Subject: rawhide report: 20050207 changes In-Reply-To: <200502071058.j17Awro26452@porkchop.devel.redhat.com> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> Message-ID: <20050207175907.7b775e50@nausicaa.camperquake.de> Hi. Build System wrote: > rpm-4.4.1-0.18 This made my rpm go bellyside up for the root user (normal users had no problems making queries against the database) until I manually removed all __db* files in /var/lib/rpm. Maybe a side effect of me using smart, I don't know. -- We aim to please, we shoot to kill. From n3npq at nc.rr.com Mon Feb 7 17:04:33 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 07 Feb 2005 12:04:33 -0500 Subject: rawhide report: 20050207 changes In-Reply-To: <20050207175907.7b775e50@nausicaa.camperquake.de> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <20050207175907.7b775e50@nausicaa.camperquake.de> Message-ID: <42079FA1.60505@nc.rr.com> Ralf Ertzinger wrote: >Hi. > >Build System wrote: > > > >>rpm-4.4.1-0.18 >> >> > >This made my rpm go bellyside up for the root user (normal users had no problems >making queries against the database) until I manually removed all __db* files in >/var/lib/rpm. Maybe a side effect of me using smart, I don't know. > > Likely to be a side effect of smart. Upgrading through a Berkeley DB version stamp in __db* files presumes cooperative applications, all of which are pretty deficient. The rpm-4.4.1 package already does "best effort" to correct the problem. However, any application that has loaded old bindings and runs another transaction after upgrading rpm with a Berkeley DB version change, will instanlt recreate a __db* file with the old version stamp. That cannot be fixed in rpmlib without some insane pokery-jiggery, it's easier to fix applications that use rpmlib imho. I'll poke Gustavo ... 73 de Jeff From Axel.Thimm at ATrpms.net Mon Feb 7 18:08:24 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Feb 2005 19:08:24 +0100 Subject: teTeX 3.0 released In-Reply-To: References: Message-ID: <20050207180824.GT9362@neu.nirvana> On Mon, Feb 07, 2005 at 07:10:13AM -0500, Neal Becker wrote: > http://freshmeat.net/projects/tetex/?branch_id=10361&release_id=187066 Bugzilla'd under https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147329 :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rgammon at real.com Mon Feb 7 19:56:03 2005 From: rgammon at real.com (Ryan Gammon) Date: Mon, 07 Feb 2005 11:56:03 -0800 Subject: Sharing sound hardware In-Reply-To: <1107600571.5561.122.camel@tux.lan> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> Message-ID: <4207C7D3.2040401@real.com> Ronald S. Bultje wrote: >Hi Ryan, > > Hi Ronald >On Sat, 2005-02-05 at 03:10, Ryan Gammon wrote: > > >>2. Pausing was generally broken >> >> > >Hm, do you mean the ALSA paused state? As far as I know, Dmix doesn't >implement that. You're supposed to just stop playback alltogether when >paused. Not ideal, admittedly, but appears to work. > > Yup. I don't think there's any reason that pause couldn't be implemented for dmix, but I guess if it's not working, don't use it. >Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users won't >notice the difference if you're using a reasonably good resampler. On my >computer (don't know if this is generally true), dmix operates on a >fixed samplerate, regardless of playback. > > Yeah, that's generally what I'm thinking. You could make an argument for 44100 too -- tends to be more popular, saves on cpu & resampling interpolation. >For the future, ALSA is definately the way to do. It's a pain to get >fully stable, still, but it's getting better. I've ended up debugging >some ALSA issues, but the result isn't too bad really. > > Agreed, looking forward to seeing what comes out of Colin's experiments. -- Ryan Gammon rgammon at real.com Developer for Helix Player https://player.helixcommunity.org From sitsofe at yahoo.com Mon Feb 7 19:47:55 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Mon, 07 Feb 2005 19:47:55 +0000 Subject: Sharing sound hardware In-Reply-To: <1107698805.4341.22.camel@galvatron.localdomain> References: <42042B18.2090207@real.com> <1107600571.5561.122.camel@tux.lan> <4204AD22.8020605@yahoo.co.uk> <1107698805.4341.22.camel@galvatron.localdomain> Message-ID: <1107805675.4332.2.camel@galvatron.localdomain> > On Sat, 2005-02-05 at 18:44 +0100, Felipe Alfaro Solana wrote: > > On 5 Feb 2005, at 12:25, Dariusz J. Garbowski wrote: > > AFAIK, dmix will use software mixing *only* if your sound card doesn't > > support hardware mixing. According to http://sourceforge.net/mailarchive/message.php?msg_id=10768851 from the alsa-list mailing list: "No, dmix always mixes in software. The card-specific configuration files are supposed to handle this." -- Sitsofe | http://sucs.org/~sits/ From rgammon at real.com Mon Feb 7 20:56:19 2005 From: rgammon at real.com (Ryan Gammon) Date: Mon, 07 Feb 2005 12:56:19 -0800 Subject: Sharing sound hardware In-Reply-To: <1107703290.4341.83.camel@galvatron.localdomain> References: <42042B18.2090207@real.com> <1107703290.4341.83.camel@galvatron.localdomain> Message-ID: <4207D5F3.3060402@real.com> Sitsofe Wheeler wrote: >You have to be a member of the helix community in order to get a >prebuilt helix player that supports ALSA don't you? > Is that a bad thing? Membership is free, all are welcome. In any case, the helix player code is all available under a GPL license, and you have the associated freedoms to modify & distribute. Fedora, for example, has a helix player source rpm, though the alsa code in that particular branch was in rough shape. I put together some docs on how to do an alsa enabled build if you are interested: https://player.helixcommunity.org/2004/developer/doc/splay_with_alsa.html If you want to try to do a similar build with the gtk player, we can help you out on the helix mailing lists, eg: player-dev at helixcommunity.org >>3. The first process to play back sound defines the characteristics of >>the sound device device. If it open up the device at a low sample rate, >>all playback would suffer. >> >> >Does it? I thought it was fixed in a configuration file (I'm not an ALSA >developer or someone who develops apps with ALSA - I'm just looking at >http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_dmix ). Perhaps apps should try and work with whatever it defaults to. > > The asoundrc file I put together seemed to do this back when I was looking at this... I'm not an alsa expert, so certainly take all these problems with a grain of salt. >I have to inject here. For legacy reasons wouldn't it be better to >support esd? Then you would get artsd support for free (sure it will >latent but it's better than nothing) and support old OSS systems. Newer >systems with ALSA would get ALSA (with dmix) support. >(goes away and reads posted links) >Heh. You already know this and are submitting patches to make this work. >I guess that tells me... > > Good suggestions. One thing to keep in mind with esound is that, last time I checked, esound had limited support for measuring the latency between when an app writes a sound for playback, and when the sound actually hits the speakers. This missing functionality makes it generally unappealing for A/V playback. Most distributions have their esound configured to release the sound device when not in use, which allows us play back video with good A/V sync as an OSS app. Not ideal, but hopefully good enough. IMO, OSS is still the best way to get a generic binary download working on the largest possible number of distributions without popping up a "select your sound server" type of dialog, which we're not really interested in doing for various reasons. >>Ideally IMHO dmix / asym would: >>- Be a sound server that runs on startup instead of something that forks >>off the first process to open the sound device >> >> >I think you might be better off suggesting this on the alsa-devel list. >I don't know if Fedora could afford to deviate too far from upstream >ALSA packages so the best thing would be to have a change like this come >"down" from upstream. I suspect this won't be a popular idea because the >"server-less" set up of dmix appears to have been done for design >reasons (low latency problems, no need for RT priorities). I'll give a >link in a minute. > > We'll see what Colin finds out in his testing... There are potentially other ways to solve this problem than with ALSA if things don't end up looking good. >>- Open the sound device using sensible maximum capabilities of the >>device in terms of sampling rate and # of channels, etc. The guys who >>write our resamplers generally prefer to have helix doing any sample >>rate conversion where possible: >>http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/000243.html >> >> >This doesn't sound like it will happen with dmix (although it could with >another ALSA plugin). In the UKUUG paper "Sound Systems on >Linux" (http://www.ukuug.org/events/linux2003/papers/TIwai/soundsystems/ ) Takashi Iwai talks a little about the rationale behind dmix. It sounds like the aim is to be simple so existing ALSA apps do not have to be rewritten, low enough latency for consumer use and free of RT-scheduling requirements. > > Thanks for the link, I'll check it out. >>I'm very interested in what others are thinking here for fedora, be it >>alsa-related or otherwise. >> >> >My general take on things so far has been tainted because although helix >and real player work great on hardware mixed cards the lack of shipped >support for esd/artsd has users wondering why things like real player >don't start when they are streaming a radio station in their web browser >('cos the sound device is locked and there's no hardware mixing is the >answer). > > There's no good answer... If we did ship with esound support turned on, users would wonder why they're getting bad A/V sync. There are also issues around how helix uses the audio device playback rate to drive its overall playback timeline. Given the choice between fixing helix esound support or fixing something like alsa, I'd tend toward fixing alsa. >I suspect the number of sound servers for typical applications will >eventually drop to two - whatever ALSA usually supplies (virtual or >otherwise) and esd. > I'd say it's just going to be alsa. The only thing esound offers over dmix / alsa is network transparency. When it comes to the (fairly rare) dumb terminal / network transparency case, my take would be to put the media engine on the terminal side & figure out how to make it work. The alternative (coming up with some transcoding / streaming translation framework that sits between something like a helix server, terminal server, and client) doesn't make sense to me. >Rumour has it that KDE will drop artsd and move to >gstreamer and since gstreamer supports both esd and ALSA out of box >sound experience on typical consumer hardware should stop being such a >mess. > > As I understand it, KDE has a kdemm project (currently a little stalled) that has the goal of providing basic access to multiple media engines. I have some links on the helix-qt resources page: https://player.helixcommunity.org/2004/developer/qt/ It's cool that gstreamer ships with good esound support, but that will only get you so far given the state of the underlying esound technology. -- Ryan Gammon rgammon at real.com Developer for Helix Player https://player.helixcommunity.org From dag at wieers.com Mon Feb 7 21:12:21 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 7 Feb 2005 22:12:21 +0100 (CET) Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107794208.19169.32.camel@localhost.localdomain> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> Message-ID: On Mon, 7 Feb 2005, Anthony Green wrote: > On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: > > beecrypt-4.1.2-1 > > ---------------- > > * Sat Feb 05 2005 Jeff Johnson 4.1.2-1 > > - upgrade to 4.1.2 > > - put java components in sub-package. > > - check that /usr/lib64 is not used on alpha (#146583). > > You called this sub-package beecrypt-java. I suggest renaming this to > something like beecrypt-java-jni. It only contains the JNI C side of > the beecrypt java library. The library of java code for beecrypt is > widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). > beecrypt-java hasn't been packaged yet, but it will surely require this > beecrypt-java-jni. I would suggest java-something as a standard name, just like python-something, perl-something and other subpackage policies. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From n3npq at nc.rr.com Mon Feb 7 21:23:17 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 07 Feb 2005 16:23:17 -0500 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> Message-ID: <4207DC45.6020602@nc.rr.com> Dag Wieers wrote: >On Mon, 7 Feb 2005, Anthony Green wrote: > > > >>On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: >> >> >>>beecrypt-4.1.2-1 >>>---------------- >>>* Sat Feb 05 2005 Jeff Johnson 4.1.2-1 >>>- upgrade to 4.1.2 >>>- put java components in sub-package. >>>- check that /usr/lib64 is not used on alpha (#146583). >>> >>> >>You called this sub-package beecrypt-java. I suggest renaming this to >>something like beecrypt-java-jni. It only contains the JNI C side of >>the beecrypt java library. The library of java code for beecrypt is >>widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). >>beecrypt-java hasn't been packaged yet, but it will surely require this >>beecrypt-java-jni. >> >> > >I would suggest java-something as a standard name, just like >python-something, perl-something and other subpackage policies. > As long as beecrypt-java is a subpkg, I prefer "beecrypt-java" OTOH, if standalone package, I would prefer "java-beecrypt", like, say, "python-sqlite3" today too. My rationale is to try to optimize the primary key retrieve on package file names, so that "similar" group together when eyeballing, say, "ls -al" lists. All is in the eye of the beholder of course, ymmv, everyone's does. And I think "beecrypt-java-jni" waiting for a java package to magically appear is rather effete, and confuses rpm package names with file names unnecessarily. And no matter what, popt as subpkg of rpm confuses everyone. But that's just me. 73 de Jeff From Nicolas.Mailhot at laPoste.net Mon Feb 7 21:34:10 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 07 Feb 2005 22:34:10 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> Message-ID: <1107812050.15014.1.camel@rousalka.dyndns.org> Le lundi 07 f?vrier 2005 ? 22:12 +0100, Dag Wieers a ?crit : > On Mon, 7 Feb 2005, Anthony Green wrote: > > > On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: > > > beecrypt-4.1.2-1 > > > ---------------- > > > * Sat Feb 05 2005 Jeff Johnson 4.1.2-1 > > > - upgrade to 4.1.2 > > > - put java components in sub-package. > > > - check that /usr/lib64 is not used on alpha (#146583). > > > > You called this sub-package beecrypt-java. I suggest renaming this to > > something like beecrypt-java-jni. It only contains the JNI C side of > > the beecrypt java library. The library of java code for beecrypt is > > widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). > > beecrypt-java hasn't been packaged yet, but it will surely require this > > beecrypt-java-jni. > > I would suggest java-something as a standard name, just like > python-something, perl-something and other subpackage policies. Please no oh no. Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because we have this number of java packages in jpackage. Regards, -- Nicolas Mailhot -------------- next part -------------- A 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 dag at wieers.com Mon Feb 7 22:01:33 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 7 Feb 2005 23:01:33 +0100 (CET) Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107812050.15014.1.camel@rousalka.dyndns.org> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> Message-ID: On Mon, 7 Feb 2005, Nicolas Mailhot wrote: > Le lundi 07 f?vrier 2005 ? 22:12 +0100, Dag Wieers a ?crit : > > On Mon, 7 Feb 2005, Anthony Green wrote: > > > > > On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: > > > > beecrypt-4.1.2-1 > > > > ---------------- > > > > * Sat Feb 05 2005 Jeff Johnson 4.1.2-1 > > > > - upgrade to 4.1.2 > > > > - put java components in sub-package. > > > > - check that /usr/lib64 is not used on alpha (#146583). > > > > > > You called this sub-package beecrypt-java. I suggest renaming this to > > > something like beecrypt-java-jni. It only contains the JNI C side of > > > the beecrypt java library. The library of java code for beecrypt is > > > widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). > > > beecrypt-java hasn't been packaged yet, but it will surely require this > > > beecrypt-java-jni. > > > > I would suggest java-something as a standard name, just like > > python-something, perl-something and other subpackage policies. > > Please no oh no. > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because > we have this number of java packages in jpackage. Well, I'm happy that perl packages have a seperate namespace and I would love python, mono and java packages pursue this further than they do (even without a CPAN alike infrastructure). Does Jpackage have 1000 java-class packages ? Because I'm not arguing to have everything java-based to fit this scheme, only packages that extend the java 'platform'. Just like perl-modules, python-classes or for that matter xmms-plugins... -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Nicolas.Mailhot at laPoste.net Mon Feb 7 23:13:17 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Feb 2005 00:13:17 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> Message-ID: <1107817997.15554.37.camel@rousalka.dyndns.org> Le lundi 07 f?vrier 2005 ? 23:01 +0100, Dag Wieers a ?crit : > Well, I'm happy that perl packages have a seperate namespace and I would > love python, mono and java packages pursue this further than they do (even > without a CPAN alike infrastructure). > > Does Jpackage have 1000 java-class packages ? Because I'm not arguing to > have everything java-based to fit this scheme, only packages that extend > the java 'platform'. Just like perl-modules, python-classes or for that > matter xmms-plugins... Unfortunately with java very often lib = leaf app. The jar is the lib and with a small shell script that is often not worth spinning out in a separate package you get you get the app. Java is much less organised than perl or python (more accurately Java FOSS evolved at the fringes of Sun's closed core) naming is pretty much a mess except for some big projects like jakarta. So you won't get an unified java namespace (unless you want jpp packagers to lynch you;) but a classpathx namespace (for classpathx reimplementations), a jakarta namespace, an eclipse namespace, and lots of packages released by independant projects with no strong ties to a big org that will probably constitute the bulk of the FOSS java "platform" for a long time. Unless of course someone steps ups to organise this mess and have everyone follow some common rules. But remember the small projects chose not to work through Sun or Jakarta/Classpath/Eclipse... so chances are their authors are pretty independent folks. IMHO the only entity that could do it now is Sun if it spun out Java stewardship in a FOSS-friendly foundation but do not count on it. In the meanwhile it'd be misleading to present Java as a perl or python-like community when it's not. There is less communication between some of the projects we package than say between your average Gnome and KDE developer (which means it's not always inexistant, just uncommon). People share Sun's langage and apis but not much anything else. Forking is nascent because you don't have the exchanges necessary to make sure original versions play well with everything (and people are used to get buggy stuff from Sun it's no use to complain about - better to patch it locally and forget about it). On the other hand the coming of age of gcj/classpath/jakarta is very interesting. It could provide the heart of a vibrant FOSS community with common values and policies. But the effects won't be seen for some time - till then the center of gravity remains Sun. Its focus on controlling the platform makes it a cold and sterile star. Regards, -- Nicolas Mailhot -------------- next part -------------- A 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 dag at wieers.com Mon Feb 7 23:39:13 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Feb 2005 00:39:13 +0100 (CET) Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107817997.15554.37.camel@rousalka.dyndns.org> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> <1107817997.15554.37.camel@rousalka.dyndns.org> Message-ID: On Tue, 8 Feb 2005, Nicolas Mailhot wrote: > Le lundi 07 f?vrier 2005 ? 23:01 +0100, Dag Wieers a ?crit : > > > Well, I'm happy that perl packages have a seperate namespace and I would > > love python, mono and java packages pursue this further than they do (even > > without a CPAN alike infrastructure). > > > > Does Jpackage have 1000 java-class packages ? Because I'm not arguing to > > have everything java-based to fit this scheme, only packages that extend > > the java 'platform'. Just like perl-modules, python-classes or for that > > matter xmms-plugins... > > Unfortunately with java very often lib = leaf app. The jar is the lib > and with a small shell script that is often not worth spinning out in a > separate package you get you get the app. In that case the JAR is not really shared much (if at all) between other apps ? So in that case we would not prepend the namespace, but I understand it's harder with Java than perl, mono or python. It would be silly to have a seperate package holding just the shell-script (unless we want to compete with Debian in number of packages). Still in the case of beecrypt, I would prefer java-beecrypt over beecrypt-java. Even if it is not a 100% cut case and the majority of the packages follow the exception rather than the rule. (ie. the exception is part of the policy too) Thanks for the torough explanation, I picked up a few things new to me. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Axel.Thimm at ATrpms.net Mon Feb 7 22:59:11 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Feb 2005 23:59:11 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107812050.15014.1.camel@rousalka.dyndns.org> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> Message-ID: <20050207225911.GX9362@neu.nirvana> On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote: > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because > we have this number of java packages in jpackage. Regardless of naming issues, are indeed 1000 packages waiting to be imported into rawhide? I.e. will all of jpackage be imported? Not that I would have anything to object, but that would be a new scaling of package imports, almost doubling the packages in rawhide right now. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n3npq at nc.rr.com Tue Feb 8 00:41:12 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 07 Feb 2005 19:41:12 -0500 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <20050207225911.GX9362@neu.nirvana> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> <20050207225911.GX9362@neu.nirvana> Message-ID: <42080AA8.3010909@nc.rr.com> Axel Thimm wrote: >On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote: > > >>Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because >>we have this number of java packages in jpackage. >> >> I'll hazard a guess based on objective criteria: >Regardless of naming issues, are indeed 1000 packages waiting to be >imported into rawhide? I.e. will all of jpackage be imported? > > Dunno all 1000 packages, but Sun's current use of rpm-3.0.4, bizarre shell script extraction to add click through sufficient to satisfy legal beagles, and other licensing oddities makes at least some of the jpackage packages extremely problematic to incorporate into any OSS distro, not just FC. >Not that I would have anything to object, but that would be a new >scaling of package imports, almost doubling the packages in rawhide >right now. > > In case you haven't noticed, FC is showing a net loss of packages recently, and is unlikely to suddenly decide to include all of jpackage.org. Not that it matters, JPackage is doing a wonderful job with a messy problem space. 73 de Jeff From mbneto at gmail.com Tue Feb 8 01:24:52 2005 From: mbneto at gmail.com (mbneto) Date: Mon, 7 Feb 2005 21:24:52 -0400 Subject: building kernel sourcecode rpm again In-Reply-To: <20050205155604.GB28477@joshua.mesa.nl> References: <20050205143753.GA28477@joshua.mesa.nl> <4204E8F8.1050701@didntduck.org> <20050205155604.GB28477@joshua.mesa.nl> Message-ID: <5cf776b805020717246ba2ef49@mail.gmail.com> hi, before switching to rawhide kernels I used to get madwifi modules. in order to compile my own should I install kernel-devel ? el > > > > kernel-sourcecode doesn't exist anymore. kernel-devel is the replacement. > > But kernel-devel only contains include files and some other stuff to build > additional modules. > > I want to change some specific part of the kernel to get some functionality > that can not be done by adding a new module. > Using the kernel-sourcode package was a good starting point for that. > > -Marcel > -- > ======-------- Marcel J.E. Mol MESA Consulting B.V. > =======--------- ph. +31-(0)6-54724868 P.O. Box 112 > =======--------- marcel at mesa.nl 2630 AC Nootdorp > __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ > They couldn't think of a number, Linux user 1148 -- counter.li.org > so they gave me a name! -- Rupert Hine -- www.ruperthine.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From green at redhat.com Tue Feb 8 01:58:44 2005 From: green at redhat.com (Anthony Green) Date: Mon, 07 Feb 2005 17:58:44 -0800 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <4207DC45.6020602@nc.rr.com> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <4207DC45.6020602@nc.rr.com> Message-ID: <1107827924.5133.29.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Mon, 2005-02-07 at 16:23 -0500, Jeff Johnson wrote: > And I think "beecrypt-java-jni" waiting for a java package to > magically > appear > is rather effete, and confuses rpm package names with file names > unnecessarily. Whatever you want to call it, the JNI library you packaged is completely useless without the breecrypt java code. If there's no plan to package the java code then there's no sense in producing the JNI library. AG From pbruna at linuxcenterla.com Tue Feb 8 00:17:48 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Mon, 07 Feb 2005 21:17:48 -0300 Subject: gconf Message-ID: <1107821868.2531.0.camel@p.linuxcenter.cl> does gconf works like client-server? can i setup a gconf server where all the clients pcs reads their configurations -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- 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 n3npq at nc.rr.com Tue Feb 8 03:18:27 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 07 Feb 2005 22:18:27 -0500 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107827924.5133.29.camel@dhcp-172-16-25-146.sfbay.redhat.com> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <4207DC45.6020602@nc.rr.com> <1107827924.5133.29.camel@dhcp-172-16-25-146.sfbay.redhat.com> Message-ID: <42082F83.7030008@nc.rr.com> Anthony Green wrote: >On Mon, 2005-02-07 at 16:23 -0500, Jeff Johnson wrote: > > >>And I think "beecrypt-java-jni" waiting for a java package to >>magically >>appear >>is rather effete, and confuses rpm package names with file names >>unnecessarily. >> >> > >Whatever you want to call it, the JNI library you packaged is completely >useless without the breecrypt java code. If there's no plan to package >the java code then there's no sense in producing the JNI library. > > Then there's also no reason to rename to "beecrypt-java-jni" either. I will insure that the "beecrypt-java" package is removed tomorrow. 73 de Jeff From bob.deblier at telenet.be Tue Feb 8 06:37:25 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Tue, 08 Feb 2005 07:37:25 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <42079B12.4040102@nc.rr.com> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <42079B12.4040102@nc.rr.com> Message-ID: <1107844645.5535.20.camel@orion> On Mon, 2005-02-07 at 11:45 -0500, Jeff Johnson wrote: > Anthony Green wrote: > > >On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: > > > > > >>beecrypt-4.1.2-1 > >>---------------- > >>* Sat Feb 05 2005 Jeff Johnson 4.1.2-1 > >>- upgrade to 4.1.2 > >>- put java components in sub-package. > >>- check that /usr/lib64 is not used on alpha (#146583). > >> > >> > > > >You called this sub-package beecrypt-java. I suggest renaming this to > >something like beecrypt-java-jni. It only contains the JNI C side of > >the beecrypt java library. The library of java code for beecrypt is > >widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). > >beecrypt-java hasn't been packaged yet, but it will surely require this > >beecrypt-java-jni. > > > > > > Heh, "This space reserved." is perhaps not the right approach. > > Hint: A ptr to what is likely to be the best upstream source for > beecrypt-java-2.0.0.zip > in bugzilla will fix "hasn't been packaged yet" faster than anything. > > Otherwise you'll have to wait until I talk to Bob Deblier in 2 weeks or > so ... > > 73 de Jeff Jeff, Anthony, Please ignore the old beecrypt-java-2.0.0 for now. A new version (mainly a provider offering access to native speed algorithms, requiring the JNI interface) is being worked on, and should start appearing in the BeeCrypt CVS tree shortly. Ideas and thoughts as to which direction that particular package should evolve towards are welcome, as I get little feedback from beecrypt-java users. Although not officially hosted there yet, any bugs or feature requests are always welcome on the BeeCrypt SourceForge page... Cheers, Bob From michael.favia at insitesinc.com Tue Feb 8 06:48:05 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 08 Feb 2005 00:48:05 -0600 Subject: gconf In-Reply-To: <1107821868.2531.0.camel@p.linuxcenter.cl> References: <1107821868.2531.0.camel@p.linuxcenter.cl> Message-ID: <420860A5.8080304@insitesinc.com> Patricio Bruna V wrote: >does gconf works like client-server? can i setup a gconf server where >all the clients pcs reads their configurations > > Please direct user support questions to the appropriate list. This list is for development related discussion only. Thank you and good luck. -mf From arjanv at redhat.com Tue Feb 8 08:45:42 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 8 Feb 2005 09:45:42 +0100 Subject: rawhide report: 20050205 changes In-Reply-To: References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> <20050207001658.GM10885@redhat.com> <20050207062419.GA25337@devserv.devel.redhat.com> Message-ID: <20050208084541.GA15877@devserv.devel.redhat.com> On Mon, Feb 07, 2005 at 07:27:35AM -0200, Alexandre Oliva wrote: > On Feb 7, 2005, Arjan van de Ven wrote: > > > On Mon, Feb 07, 2005 at 12:16:58AM +0000, Tim Waugh wrote: > >> On Sun, Feb 06, 2005 at 10:21:08AM +0100, Arjan van de Ven wrote: > >> > >> > this is already wrong. The "athlon" hack is *WRONG*. Athlon is a > >> > marketing name, it could just as well be a duron or a sempron. > >> > It was a mistake to put the athlon hack in uname (but hindsight is > >> > easy); it's imo very wrong to repeat that mistake. > >> > >> Should I take it out? > > > hard dilemma in that it risks breaking existing stuff.... > > The most common case in which I've seen scripts depend on athlon or > ia32e is to build kernels and kernel modules. Since the removal of > athlon- and ia32e-specific kernels, having uname print athlon or ia32e > no longer helps; it actually gets in the way. So my vote would be to > get rid of it. those scripts are really broken anyway if they do that. uname is NOT the way to get the rpm architecture of the kernel, you HAVE to use rpm -q --queryformat %{ARCH} kernel-`uname -r` for that. Simlply because you can install an i686 kernel on an athlon.... From n3npq at nc.rr.com Tue Feb 8 08:54:19 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 08 Feb 2005 03:54:19 -0500 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107844645.5535.20.camel@orion> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <42079B12.4040102@nc.rr.com> <1107844645.5535.20.camel@orion> Message-ID: <42087E3B.3000400@nc.rr.com> Bob Deblier wrote: >On Mon, 2005-02-07 at 11:45 -0500, Jeff Johnson wrote: > > >>Anthony Green wrote: >> >> >> >>>On Mon, 2005-02-07 at 05:58 -0500, Build System wrote: >>> >>> >>> >>> >>>>beecrypt-4.1.2-1 >>>>---------------- >>>>* Sat Feb 05 2005 Jeff Johnson 4.1.2-1 >>>>- upgrade to 4.1.2 >>>>- put java components in sub-package. >>>>- check that /usr/lib64 is not used on alpha (#146583). >>>> >>>> >>>> >>>> >>>You called this sub-package beecrypt-java. I suggest renaming this to >>>something like beecrypt-java-jni. It only contains the JNI C side of >>>the beecrypt java library. The library of java code for beecrypt is >>>widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip). >>>beecrypt-java hasn't been packaged yet, but it will surely require this >>>beecrypt-java-jni. >>> >>> >>> >>> >>Heh, "This space reserved." is perhaps not the right approach. >> >>Hint: A ptr to what is likely to be the best upstream source for >>beecrypt-java-2.0.0.zip >>in bugzilla will fix "hasn't been packaged yet" faster than anything. >> >>Otherwise you'll have to wait until I talk to Bob Deblier in 2 weeks or >>so ... >> >>73 de Jeff >> >> > >Jeff, Anthony, > > >Please ignore the old beecrypt-java-2.0.0 for now. A new version (mainly >a provider offering access to native speed algorithms, requiring the JNI >interface) is being worked on, and should start appearing in the >BeeCrypt CVS tree shortly. > > OK. I'll be happy to add next generation beecrypt-java to "beecrypt-java" whenever. >Ideas and thoughts as to which direction that particular package should >evolve towards are welcome, as I get little feedback from beecrypt-java >users. Although not officially hosted there yet, any bugs or feature >requests are always welcome on the BeeCrypt SourceForge page... > > FC might be a place to get more feedback for beecrypt-java. Anyways, see you at Cafe Subite in 2 weeks ;-) 73 de Jeff From bob.deblier at telenet.be Tue Feb 8 09:49:29 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Tue, 08 Feb 2005 10:49:29 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <42087E3B.3000400@nc.rr.com> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <42079B12.4040102@nc.rr.com> <1107844645.5535.20.camel@orion> <42087E3B.3000400@nc.rr.com> Message-ID: <1107856169.5530.1.camel@orion> On Tue, 2005-02-08 at 03:54 -0500, Jeff Johnson wrote: > OK. I'll be happy to add next generation beecrypt-java to > "beecrypt-java" whenever. > > >Ideas and thoughts as to which direction that particular package should > >evolve towards are welcome, as I get little feedback from beecrypt-java > >users. Although not officially hosted there yet, any bugs or feature > >requests are always welcome on the BeeCrypt SourceForge page... > > > > > > FC might be a place to get more feedback for beecrypt-java. That's why I'm lurking here ;) > Anyways, see you at Cafe Subite in 2 weeks ;-) Looking forward! Cheers, Bob From arjanv at redhat.com Tue Feb 8 10:42:49 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 8 Feb 2005 11:42:49 +0100 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: References: Message-ID: <20050208104249.GA23495@devserv.devel.redhat.com> On Fri, Feb 04, 2005 at 04:29:41PM -0500, Elliot Lee wrote: > Yes, it's that time again... > > Although the FC4 schedule hasn't been finalized yet, we do need to try to > stick to the preliminary one until it's decided otherwise. Fedora Core 4 > test 1 is currently slated to come out on February 21st, which means that > I would fall in love with you all over again if you did your part to make > sure the tree was installable and free of broken dependencies & conflicts > by Valentine's Day (Monday, February 14th). > > The goal for FC4test1 is to "get something out there" - it may not be > fully baked, but it does need to pass basic sanity tests, be able to > install and avoid killing people's systems. One of the ways non-developers > can help is by trying to install from rawhide and yelling loudly about any > showstopper (i.e. hard disk-destroying) problems. oh another thing we need to resolve is the over-abundance of execshield-disabling libaries and binaries in the distro. the following list (made by Marc Cox) is what we shipped as such in rhel4; if you're the owner of any of these packages/files please seriously consider fixing these. If you don't know how or what or otherwise have questions, do not hesitate to ask via email (on this list or off list) or on IRC; for security reasons we really need to reduce this list to almost nothing. anaconda-runtime-10.1.1.13-1.i386 ./usr/lib/anaconda-runtime/loader/init: stack=RWE anaconda-runtime-10.1.1.13-1.i386 ./usr/lib/anaconda-runtime/loader/loader: stack=RWE libgcj-3.4.3-9.EL4.i386 ./usr/lib/libgcj.so.5.0.0: stack=RWE gcc-gnat-3.4.3-9.EL4.i386 ./usr/bin/gnatbind: stack=RWE gcc-gnat-3.4.3-9.EL4.i386 ./usr/bin/gnatls: stack=RWE gcc-gnat-3.4.3-9.EL4.i386 ./usr/bin/gnatmake: stack=RWE gcc-gnat-3.4.3-9.EL4.i386 ./usr/libexec/gcc/i386-redhat-linux/3.4.3/gnat1: stack=RWE libgnat-3.4.3-9.EL4.i386 ./usr/lib/libgnat-3.4.so.1: stack=RWE compat-libstdc++-296-2.96-132.7.2.i386 ./usr/lib/libstdc++-3-libc6.2-2-2.10.0.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/gamma_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/i810_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/i915_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/mga_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/r128_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/r200_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/radeon_dri.so: stack=RWE xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/tdfx_dri.so: stack=RWE xorg-x11-libs-6.8.1-23.EL.i386 ./usr/X11R6/lib/libOSMesa.so.4.0: stack=RWE gstreamer-0.8.7-4.EL.0.i386 ./usr/lib/gstreamer-0.8/libgstgetbits.so: stack=RWE alsa-lib-1.0.6-4.i386 ./lib/libasound.so.2.0.0: stack=RWE grub-0.95-3.1.i386 ./sbin/grub: stack=RWE kernel-utils-2.4-13.1.48.i386 ./usr/sbin/x86info: stack=RWE valgrind-2.2.0-5.EL4.i386 ./usr/lib/valgrind/libpthread.so: stack=RWE gstreamer-plugins-0.8.5-1.EL.0.i386 ./usr/lib/gstreamer-0.8/libgsthermescolorspace.so: stack=RWE gstreamer-plugins-0.8.5-1.EL.0.i386 ./usr/lib/gstreamer-0.8/libgstvideoscale.so: stack=RWE HelixPlayer-1.0.1.gold-8EL.i386 ./usr/lib/helix/codecs/colorcvt.so: stack=RWE HelixPlayer-1.0.1.gold-8EL.i386 ./usr/lib/helix/codecs/cvt1.so: stack=RWE HelixPlayer-1.0.1.gold-8EL.i386 ./usr/lib/helix/plugins/vidsite.so: stack=RWE mkinitrd-4.1.18-2.i386 ./sbin/nash: stack=RWE bogl-0.1.18-4.i386 ./usr/lib/libbogl.so.0.1: stack=RWE dietlibc-0.27-4.i386 ./usr/bin/diet: stack=RWE SDL-1.2.7-8.i386 ./usr/lib/libSDL-1.2.so.0.7.0: stack=RWE xmms-1.2.10-9.i386 ./usr/lib/xmms/Visualization/libbscope.so: stack=RWE guile-1.6.4-14.i386 ./usr/lib/libqthreads.so.12.3.0: stack=RWE net-tools-1.60-37.i386 ./sbin/netplugd: stack=RWE module-init-tools-3.1-0.pre5.3.i386 ./sbin/insmod.static: stack=RWE libdv-0.103-1.i386 ./usr/lib/libdv.so.4.0.1: stack=RWE gdk-pixbuf-0.22.0-15.1.i386 ./usr/lib/libgdk_pixbuf.so.2.0.0: stack=RWE gdk-pixbuf-0.22.0-15.1.i386 ./usr/lib/libgdk_pixbuf_xlib.so.2.0.0: stack=RWE libsilc-0.9.12-7.i386 ./usr/lib/libsilc-1.0.so.2.1.0: stack=RWE gnupg-1.2.6-1.i386 ./usr/bin/gpg: stack=RWE gnupg-1.2.6-1.i386 ./usr/bin/gpgv: stack=RWE flac-1.1.0-7.i386 ./usr/lib/libFLAC.so.4.1.2: stack=RWE beecrypt-3.1.0-6.i386 ./usr/lib/libbeecrypt.so.6.2.0: stack=RWE From buildsys at redhat.com Tue Feb 8 11:19:31 2005 From: buildsys at redhat.com (Build System) Date: Tue, 8 Feb 2005 06:19:31 -0500 Subject: rawhide report: 20050208 changes Message-ID: <200502081119.j18BJVw31011@porkchop.devel.redhat.com> New package gnome-python2-extras The sources for additional. PyGNOME Python extension modules. Removed package nautilus-media Updated Packages: GConf2-2.9.91-1 --------------- * Mon Feb 07 2005 Mark McLoughlin 2.9.91-1 - Update to 2.9.91 abiword-1:2.2.3-3 ----------------- * Mon Feb 07 2005 Matthias Clasen - 1:2.2.3-3 - rebuild chkconfig-1.3.15-1 ------------------ * Mon Feb 07 2005 Bill Nottingham 1.3.15-1 - print usage when various invalid args are passed (#147393) evolution-connector-2.1.4-3 --------------------------- * Mon Feb 07 2005 David Malcolm - 2.1.4-3 - Patch to fix non-portable usage of convenience libraries; reorganised the hand-edited vs generated patches (generated patch is 990K in size) - Add "-Wl" to make arguments to escape usage of -rpath so it is seen by linker, but not by libtool, enabling libexchange.la to install below /usr/lib/evolution-data-server-1.2/camel-providers, rather than /usr/lib/evolution/2.2 * Mon Jan 31 2005 David Malcolm - 2.1.4-2 - Split out the 64-bit acinclude.m4 patch into two patches, one containing the "actual" patch; the other containing all of the regenerated autotool results. - Actually apply the 64-bit acinclude.m4 fix this time. * Wed Jan 26 2005 David Malcolm - 2.1.4-1 - Update from stable upstream 2.0.3 to unstable upstream 2.1.4 - Update evo_major from 2.0 to 2.2 - Added eds_major definition - Require evolution 2.1.4 - Require libsoup 2.2.2 - Re-enable s390 architectures - Cope with camel-providers now being stored below evolution-data-server, rather than evolution. - Remove .a files from camel-providers subdir - Removed various docs no longer present findutils-1:4.1.20-8 -------------------- * Tue Jan 04 2005 Dan Walsh 1:4.1.20-8 - Change --context to use fnmatch instead of strcmp * Tue Dec 07 2004 Tim Waugh - Removed "G" and "M" size qualifiers from man page, since support for those is not in the stable branch (bug #141987). * Tue Oct 19 2004 Tim Waugh 1:4.1.20-7 - Better xargs ARG_SIZE handling (bug #135129). gdb-6.3.0.0-0.17 ---------------- * Mon Feb 07 2005 Jeff Johnston 6.3.0.0-0.17 - Modify previous gcore patch to only apply to ia64. gnome-panel-2.9.90-4 -------------------- * Mon Feb 07 2005 Mark McLoughlin - 2.9.90-4 - Don't use --makefile-install-rule to install .entries files (#147112) gnome-python2-2.9.4-2 --------------------- * Mon Feb 07 2005 Matthias Clasen - 2.9.4-2 - Remove unnecessary BuildRequires * Mon Feb 07 2005 Matthias Clasen - 2.9.4-1 - Update to 2.9.4 - Move some subpackages to gnome-python2-extra - Obsolete gnome-python2-nautilus gnumeric-1:1.4.2-2 ------------------ * Mon Feb 07 2005 Matthias Clasen 1.4.2-2 - rebuild hotplug-3:2004_09_23-1 ---------------------- * Mon Feb 07 2005 Bill Nottingham 3:2004_09_23-1 - update to 2004-09-23 - add some USB ids (#91677, #140957) - add support for osst (#143655, ) - call ifdown on interface removal (#127283) httpd-2.0.52-7 -------------- * Mon Feb 07 2005 Joe Orton 2.0.52-7 - fix cosmetic issues in "service httpd reload" - move User/Group higher in httpd.conf (#146793) - load mod_logio by default in httpd.conf - apachectl: update for correct libselinux tools locations kernel-2.6.10-1.1134_FC4 ------------------------ * Tue Feb 08 2005 Dave Jones - Enable old style and new style USB initialisation. * Mon Feb 07 2005 Dave Jones - 2.6.11-rc3-bk4 - Various patches to unbork PPC. - Display taint bits on VM error. * Mon Feb 07 2005 Rik van Riel - upgrade to latest upstream Xen bits, upgrade those to 2.6.11-rc3-bk2 lksctp-tools-1.0.2-4 -------------------- * Mon Feb 07 2005 Karsten Hopp 1.0.2-4 - initialize variable before use - fix subscript out of range bug (#147286) net-tools-1.60-44 ----------------- * Mon Feb 07 2005 Radek Vokal 1.60-44 - net-plug-1.2.9 - no changes, upstream included Red Hat patches - ether-wake-1.08 - few changes in implementation (#145718) policycoreutils-1.21.12-2 ------------------------- * Mon Feb 07 2005 Dan Walsh 1.21.12-2 - Fix sestatus for longer booleans prelink-0.3.4-1 --------------- * Mon Feb 07 2005 Jakub Jelinek 0.3.4-1 - fix prelink -uo when linked against libselinux (#146637) and when the -o argument filename is on a different filesystem than the object that needs undoing psacct-6.3.2-34.fc4 ------------------- * Thu Feb 03 2005 Charles Bennett 6.3.2-33.fc4 - rhbz 133077: logrotate fixed to continue accounting during rotate - rhbz 141802: lastcomm was not handling all forms of --strict-match - rhbz 141971: rpm -e no longer leaves /var/lock/subsys/psacct - rhbz 43294: sa will never report any io because the kernel doesn't provide it. Tweaked to ignore ac_io in acct.h - integrate lastcomm hz patch from RH support rpmdb-fedora-1:4-0.20050208 --------------------------- selinux-policy-strict-1.21.8-6 ------------------------------ * Mon Feb 07 2005 Dan Walsh 1.21.8-6 - Allow user apps to read event_device_t * Fri Feb 04 2005 Dan Walsh 1.21.8-5 - Add java plugin policy selinux-policy-targeted-1.21.8-6 -------------------------------- * Mon Feb 07 2005 Dan Walsh 1.21.8-6 - Allow user apps to read event_device_t * Fri Feb 04 2005 Dan Walsh 1.21.8-5 - Add java plugin policy system-config-printer-0.6.122-1 ------------------------------- * Mon Feb 07 2005 Tim Waugh 0.6.122-1 - 0.6.122: - Fixes for printconf_tui mangled/demangled names (bug #147330). texinfo-4.8-2 ------------- * Mon Feb 07 2005 Tim Waugh 4.8-2 - Don't ship texi2pdf (bug #147271). totem-0.101-3 ------------- * Wed Feb 02 2005 Matthias Clasen - 0.101-3 - Obsolete nautilus-media - Install property page and thumbnailer vim-1:6.3.061-2 --------------- * Mon Feb 07 2005 Karsten Hopp 6.3.061-2 - fix tmpfile patch (#147192) * Mon Jan 31 2005 Karsten Hopp 6.3.061-1 - patchlevel 61 vsftpd-2.0.1-9 -------------- * Mon Feb 07 2005 Radek Vokal 2.0.1-9 - don't allow to read non-root config files (#145548) xemacs-21.4.17-1 ---------------- * Mon Feb 07 2005 Jens Petersen - 21.4.17-1 - update to 21.4.17 - xemacs-21.4.16-xutil-keysym-144601.patch no longer needed - fixes format string vulnerability in movemail (CAN-2005-0100, 146705) xterm-200-2 ----------- * Mon Feb 07 2005 Mike A. Harris 200-2 - Removed chmod from prep, and updated comment to refect (#128341c12) * Mon Feb 07 2005 Mike A. Harris 200-1 - Updated main tarball to xterm-200 for FC4 devel - Disabled xterm-179-ppc-fix-bug-101472.patch for now, to see if the problem occurs on ppc still or not. From dragoran at feuerpokemon.de Tue Feb 8 11:42:43 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 08 Feb 2005 12:42:43 +0100 Subject: CVS server down? In-Reply-To: <1107526123.21487.0.camel@jdub.homelinux.org> References: <1107519829.20325.1.camel@jdub.homelinux.org> <1107523683.30769.5.camel@bobcat.mine.nu> <1107526123.21487.0.camel@jdub.homelinux.org> Message-ID: <4208A5B3.9050005@feuerpokemon.de> Josh Boyer schrieb: >On Fri, 2005-02-04 at 15:28 +0200, Ville Skytt? wrote: > > >>On Fri, 2005-02-04 at 06:23 -0600, Josh Boyer wrote: >> >> >>>Seems CVS is down. A cvs co times out and I can't get to >>>http://cvs.fedora.redhat.com. >>> >>>Any idea why? >>> >>> >>https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00125.html >> >> > >Ah. Thanks. > >josh > > > still down .... From si at bananas.hopto.org Tue Feb 8 11:51:14 2005 From: si at bananas.hopto.org (Si Jones) Date: Tue, 8 Feb 2005 11:51:14 -0000 (GMT) Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: <20050208104249.GA23495@devserv.devel.redhat.com> References: <20050208104249.GA23495@devserv.devel.redhat.com> Message-ID: <44395.195.8.190.39.1107863474.squirrel@bananas.hopto.org> > On Fri, Feb 04, 2005 at 04:29:41PM -0500, Elliot Lee wrote: >> Yes, it's that time again... >> >> Although the FC4 schedule hasn't been finalized yet, we do need to try >> to >> stick to the preliminary one until it's decided otherwise. Fedora Core >> 4 >> test 1 is currently slated to come out on February 21st, which means >> that >> I would fall in love with you all over again if you did your part to >> make >> sure the tree was installable and free of broken dependencies & >> conflicts >> by Valentine's Day (Monday, February 14th). >> >> The goal for FC4test1 is to "get something out there" - it may not be >> fully baked, but it does need to pass basic sanity tests, be able to >> install and avoid killing people's systems. One of the ways >> non-developers >> can help is by trying to install from rawhide and yelling loudly about >> any >> showstopper (i.e. hard disk-destroying) problems. > I have a x86_64 FC3 - Completely up to date, Would yum it up to Rawhide be a test for you? If not let me know what to do and I will try it. Regards, From ghenry at suretecsystems.com Tue Feb 8 12:01:22 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 8 Feb 2005 12:01:22 -0000 (GMT) Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) Message-ID: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> Dear all, Just been chatting to Tim Waugh via irc and I am going to start work on adding FOP support to xmlto, in the hope of fixing the current Docbook XML PDF generation problems. I'll let you know how I get on over the next few days/weeks. FOP: http://xml.apache.org/fop/ Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1467 624141 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From skvidal at phy.duke.edu Tue Feb 8 13:25:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 08 Feb 2005 08:25:09 -0500 Subject: CVS server down? In-Reply-To: <4208A5B3.9050005@feuerpokemon.de> References: <1107519829.20325.1.camel@jdub.homelinux.org> <1107523683.30769.5.camel@bobcat.mine.nu> <1107526123.21487.0.camel@jdub.homelinux.org> <4208A5B3.9050005@feuerpokemon.de> Message-ID: <1107869109.20957.3.camel@cutter> > >>> > >>https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00125.html > >> > >> > > > >Ah. Thanks. > > > >josh > > > > > > > still down .... right now it's waiting on a sysadmin to fix a configuration problem left over from before it left RDU. -sv From pnasrat at redhat.com Tue Feb 8 15:35:04 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 08 Feb 2005 10:35:04 -0500 Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> Message-ID: <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> On Tue, 2005-02-08 at 12:01 +0000, Gavin Henry wrote: > Dear all, > > Just been chatting to Tim Waugh via irc and I am going to start work on > adding FOP support to xmlto, in the hope of fixing the current Docbook XML > PDF generation problems. > > I'll let you know how I get on over the next few days/weeks. > > FOP: http://xml.apache.org/fop/ Please use the JPackage stack as in rawhide or from jpackage.org as this is our java platform. You will need to build without jimi support. Paul From brugolsky at telemetry-investments.com Tue Feb 8 15:39:29 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 8 Feb 2005 10:39:29 -0500 Subject: rawhide report: 20050205 changes In-Reply-To: <20050208084541.GA15877@devserv.devel.redhat.com> References: <200502051308.j15D8Hb16710@porkchop.devel.redhat.com> <1107609763.4127.95.camel@laptopd505.fenrus.org> <20050206020522.GA899850@hiwaay.net> <1107681668.22680.55.camel@laptopd505.fenrus.org> <20050207001658.GM10885@redhat.com> <20050207062419.GA25337@devserv.devel.redhat.com> <20050208084541.GA15877@devserv.devel.redhat.com> Message-ID: <20050208153929.GB7036@ti64.telemetry-investments.com> On Tue, Feb 08, 2005 at 09:45:42AM +0100, Arjan van de Ven wrote: > those scripts are really broken anyway if they do that. uname is NOT the way > to get the rpm architecture of the kernel, you HAVE to use > rpm -q --queryformat %{ARCH} kernel-`uname -r` To handle kernel-smp and other variants, perhaps that ought to be: rpm -qf --queryformat '%{ARCH}' /lib/modules/`uname -r` Regards, Bill Rugolsky From ghenry at suretecsystems.com Tue Feb 8 15:43:32 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 8 Feb 2005 15:43:32 -0000 (GMT) Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> Message-ID: <56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> > On Tue, 2005-02-08 at 12:01 +0000, Gavin Henry wrote: >> Dear all, >> >> Just been chatting to Tim Waugh via irc and I am going to start work on >> adding FOP support to xmlto, in the hope of fixing the current Docbook >> XML >> PDF generation problems. >> >> I'll let you know how I get on over the next few days/weeks. >> >> FOP: http://xml.apache.org/fop/ > > Please use the JPackage stack as in rawhide or from jpackage.org as this > is our java platform. > > You will need to build without jimi support. > > Will do. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1467 624141 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From Daniel.Kaliel at jjbedmonton.com Tue Feb 8 16:19:56 2005 From: Daniel.Kaliel at jjbedmonton.com (Daniel Kaliel) Date: Tue, 8 Feb 2005 09:19:56 -0700 Subject: Courier RPM Message-ID: <20050208160837.EA4C720E158@hades.jjbedmonton.com> I built a RPM of the latest version of Courier IMAP on FC3 if the development team is interested. ===================================== Daniel Kaliel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Mailhot at laPoste.net Tue Feb 8 17:54:11 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Feb 2005 18:54:11 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <20050207225911.GX9362@neu.nirvana> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> <20050207225911.GX9362@neu.nirvana> Message-ID: <1107885251.21339.2.camel@rousalka.dyndns.org> Le lundi 07 f?vrier 2005 ? 23:59 +0100, Axel Thimm a ?crit : > On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote: > > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because > > we have this number of java packages in jpackage. > > Regardless of naming issues, are indeed 1000 packages waiting to be > imported into rawhide? I.e. will all of jpackage be imported? I don't think so (who knows;) But if the java-xx virus caughts on we'd have to preemptively rename a lot of stuff just in case it gets imported someday (to avoid packagename conflicts later) Not fun at all;( Regards, -- Nicolas Mailhot -------------- next part -------------- A 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 8 18:30:05 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 08 Feb 2005 11:30:05 -0700 Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> <56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> Message-ID: <1107887405.3377.5.camel@localhost.localdomain> FOP lacks many features, and it seems no one has touched it since 2003. Are you sure you really want to add it? On Tue, 2005-02-08 at 15:43 +0000, Gavin Henry wrote: > > > On Tue, 2005-02-08 at 12:01 +0000, Gavin Henry wrote: > >> Dear all, > >> > >> Just been chatting to Tim Waugh via irc and I am going to start work on > >> adding FOP support to xmlto, in the hope of fixing the current Docbook > >> XML > >> PDF generation problems. > >> > >> I'll let you know how I get on over the next few days/weeks. > >> > >> FOP: http://xml.apache.org/fop/ > > > > Please use the JPackage stack as in rawhide or from jpackage.org as this > > is our java platform. > > > > You will need to build without jimi support. > > > > > > Will do. > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1467 624141 > M +44 (0) 7930 323266 > F +44 (0) 1224 742001 > E ghenry at suretecsystems.com > > Open Source. Open Solutions(tm). > > http://www.suretecsystems.com/ > -- "I'm politically incorrect and damn proud of it. I love my country, but I'm scared to death of it's government." -- Blackie Lawless From nutello at sweetness.com Tue Feb 8 18:44:20 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 8 Feb 2005 19:44:20 +0100 Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <1107887405.3377.5.camel@localhost.localdomain> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> <56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> <1107887405.3377.5.camel@localhost.localdomain> Message-ID: <20050208184420.GG6403@plain.rackshack.net> On Tue, Feb 08, 2005 at 11:30:05AM -0700, Trever L. Adams wrote: > FOP lacks many features, and it seems no one has touched it since 2003. > Are you sure you really want to add it? Sad, but true: for my DocBook documents, despite it having serious problems with some indexterm elements, the DSSSL toolchain still produces better output than the alternatives. As to FOP, it's not dead, it just smells funny. I think there's a rewrite in progress. -- Rudi From ghenry at suretecsystems.com Tue Feb 8 18:48:06 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 8 Feb 2005 18:48:06 -0000 (GMT) Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <1107887405.3377.5.camel@localhost.localdomain> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com><1107876904.20866.5.camel@minimumble.lab.boston.redhat.com><56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> <1107887405.3377.5.camel@localhost.localdomain> Message-ID: <1643.192.168.100.89.1107888486.squirrel@webmail.suretecsystems.com> > FOP lacks many features, and it seems no one has touched it since 2003. > Are you sure you really want to add it? I getting desperate for a working PDF solution, so I was hoping this would be it. > > On Tue, 2005-02-08 at 15:43 +0000, Gavin Henry wrote: >> >> > On Tue, 2005-02-08 at 12:01 +0000, Gavin Henry wrote: >> >> Dear all, >> >> >> >> Just been chatting to Tim Waugh via irc and I am going to start work >> on >> >> adding FOP support to xmlto, in the hope of fixing the current >> Docbook >> >> XML >> >> PDF generation problems. >> >> >> >> I'll let you know how I get on over the next few days/weeks. >> >> >> >> FOP: http://xml.apache.org/fop/ >> > >> > Please use the JPackage stack as in rawhide or from jpackage.org as >> this >> > is our java platform. >> > >> > You will need to build without jimi support. >> > >> > >> >> Will do. >> >> -- >> Kind Regards, >> >> Gavin Henry. >> Managing Director. >> >> T +44 (0) 1467 624141 >> M +44 (0) 7930 323266 >> F +44 (0) 1224 742001 >> E ghenry at suretecsystems.com >> >> Open Source. Open Solutions(tm). >> >> http://www.suretecsystems.com/ >> > -- > "I'm politically incorrect and damn proud of it. I love my country, but > I'm scared to death of it's government." -- Blackie Lawless > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From ghenry at suretecsystems.com Tue Feb 8 18:51:13 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 8 Feb 2005 18:51:13 -0000 (GMT) Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <20050208184420.GG6403@plain.rackshack.net> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com><1107876904.20866.5.camel@minimumble.lab.boston.redhat.com><56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com><1107887405.3377.5.camel@localhost.localdomain> <20050208184420.GG6403@plain.rackshack.net> Message-ID: <1691.192.168.100.89.1107888673.squirrel@webmail.suretecsystems.com> > On Tue, Feb 08, 2005 at 11:30:05AM -0700, Trever L. Adams wrote: >> FOP lacks many features, and it seems no one has touched it since 2003. >> Are you sure you really want to add it? > > Sad, but true: for my DocBook documents, despite it having serious > problems with some indexterm elements, the DSSSL toolchain still > produces better output than the alternatives. > > As to FOP, it's not dead, it just smells funny. I think there's a > rewrite in progress. It does have some good security features, like stopping printing/editing etc., but why you would do that for a free software guide, I don know. And, saying that, I couldn even build html with the same stylesheet, main-html.xsl. Maybe itś not worth the effort. > > -- > Rudi > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From tadams-lists at myrealbox.com Tue Feb 8 18:58:55 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 08 Feb 2005 11:58:55 -0700 Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <1643.192.168.100.89.1107888486.squirrel@webmail.suretecsystems.com> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> <56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> <1107887405.3377.5.camel@localhost.localdomain> <1643.192.168.100.89.1107888486.squirrel@webmail.suretecsystems.com> Message-ID: <1107889135.3377.13.camel@localhost.localdomain> On Tue, 2005-02-08 at 18:48 +0000, Gavin Henry wrote: > > > FOP lacks many features, and it seems no one has touched it since 2003. > > Are you sure you really want to add it? > > I getting desperate for a working PDF solution, so I was hoping this would > be it. Well, please don't let me discourage you. I actually have used it. It works for most things I do (it would be nice to have). However, it needs a lot of work. If I had money to throw at it, I think I would encourage another to be written (maybe in C/C++). Also, I just saw that it hasn't changed since 2003 yesterday; hence my reaction. I apologize. The base style-sheets can be ugly in certain page sizes, but this is from the docbook-xml stuff I Believe and can be fixed. There are a few things that I don't seem to be able to do. Docbook or FOP may be at fault. Trever -- "If there was strife and contention in the home, very little else in life could compensate for it." -- Lawana Blackwell, The Courtship of the Vicar's Daughter, 1998 From jeff at ollie.clive.ia.us Tue Feb 8 20:12:28 2005 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Tue, 08 Feb 2005 14:12:28 -0600 Subject: Adding FOP Support to xmlto to fix PDF generation (Bug 147472) In-Reply-To: <1107889135.3377.13.camel@localhost.localdomain> References: <63221.193.195.148.66.1107864082.squirrel@webmail.suretecsystems.com> <1107876904.20866.5.camel@minimumble.lab.boston.redhat.com> <56825.193.195.148.66.1107877412.squirrel@webmail.suretecsystems.com> <1107887405.3377.5.camel@localhost.localdomain> <1643.192.168.100.89.1107888486.squirrel@webmail.suretecsystems.com> <1107889135.3377.13.camel@localhost.localdomain> Message-ID: <1107893549.8326.37.camel@localhost.localdomain> On Tue, 2005-02-08 at 11:58 -0700, Trever L. Adams wrote: > > If I had money to throw at it, I think I would encourage another to be > written (maybe in C/C++). Take a look at xmlroff: http://xmlroff.sourceforge.net/ > Also, I just saw that [FOP] hasn't changed since 2003 yesterday I haven't read the FOP developer lists for a while, but they were/are involved in a major rewrite because of architectural problems with the code that had previously been release. I don't know what the current status is though... Check the FOP developer list archives. -------------- next part -------------- A 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 giallu at gmail.com Tue Feb 8 21:53:55 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 8 Feb 2005 22:53:55 +0100 Subject: Packaging a gnome applet Message-ID: Can anyone give me any pointer to gnome docs relevant for understanding how to write a spec file for a gnome applet (or gnome apps in general)? Right now I am trying to learn from existing srpms like gnome-netstatus-2.8.0-3.src.rpm, but I think it would be better to first understand what's going on behind the scenes of a gnome app. Any help is appreciated BTW the applet is gnome-sensors (http://sensors-applet.sourceforge.net/) Cheers Gianluca From dag at wieers.com Tue Feb 8 22:39:51 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Feb 2005 23:39:51 +0100 (CET) Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: <1107885251.21339.2.camel@rousalka.dyndns.org> References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> <20050207225911.GX9362@neu.nirvana> <1107885251.21339.2.camel@rousalka.dyndns.org> Message-ID: On Tue, 8 Feb 2005, Nicolas Mailhot wrote: > Le lundi 07 f?vrier 2005 ? 23:59 +0100, Axel Thimm a ?crit : > > On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote: > > > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because > > > we have this number of java packages in jpackage. > > > > Regardless of naming issues, are indeed 1000 packages waiting to be > > imported into rawhide? I.e. will all of jpackage be imported? > > I don't think so (who knows;) > But if the java-xx virus caughts on we'd have to preemptively rename a > lot of stuff just in case it gets imported someday (to avoid packagename > conflicts later) > > Not fun at all;( Well, that's why a policy should have been made at the very start. Naming is very important and the lack of a naming policy is causing all sorts of confusions and problems (like the lack of a 'virtual package' namespace). And the longer we wait, the more messy it becomes the day one is required. Unless it is worked around by adding complexity/layers. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From steve at silug.org Tue Feb 8 22:58:30 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 8 Feb 2005 16:58:30 -0600 Subject: Courier RPM In-Reply-To: <20050208160837.EA4C720E158@hades.jjbedmonton.com> References: <20050208160837.EA4C720E158@hades.jjbedmonton.com> Message-ID: <20050208225830.GA28762@osiris.silug.org> On Tue, Feb 08, 2005 at 09:19:56AM -0700, Daniel Kaliel wrote: > I built a RPM of the latest version of Courier IMAP on FC3 if the > development team is interested. I'd love to see someone else help out (or even take the lead) with this: https://bugzilla.fedora.us/show_bug.cgi?id=1931 Please post to fedora-extras-list about this in the future though. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From n3npq at nc.rr.com Wed Feb 9 02:14:17 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 08 Feb 2005 21:14:17 -0500 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> <20050207225911.GX9362@neu.nirvana> <1107885251.21339.2.camel@rousalka.dyndns.org> Message-ID: <420971F9.2080900@nc.rr.com> Dag Wieers wrote: >On Tue, 8 Feb 2005, Nicolas Mailhot wrote: > > > >>Le lundi 07 f?vrier 2005 ? 23:59 +0100, Axel Thimm a ?crit : >> >> >>>On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote: >>> >>> >>>>Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because >>>>we have this number of java packages in jpackage. >>>> >>>> >>>Regardless of naming issues, are indeed 1000 packages waiting to be >>>imported into rawhide? I.e. will all of jpackage be imported? >>> >>> >>I don't think so (who knows;) >>But if the java-xx virus caughts on we'd have to preemptively rename a >>lot of stuff just in case it gets imported someday (to avoid packagename >>conflicts later) >> >>Not fun at all;( >> >> > >Well, that's why a policy should have been made at the very start. Naming >is very important and the lack of a naming policy is causing all sorts of >confusions and problems (like the lack of a 'virtual package' namespace). > >And the longer we wait, the more messy it becomes the day one is >required. Unless it is worked around by adding complexity/layers. > > FUD, plain and simple. The internet is not running out of numbers, and lack of conventionally named packages is something that can be lived with. rpm is already independent of package file names because SuSE had to deal with 8.3 pakcage names. And package names themselves have been duplicated into dependencies for several years. All package names could be changed to whatever if the per-package dependency name was created differently, and nothing whatsoever would break. User and repo maintainer confusion is a whole different matter. 73 de Jeff From Nicolas.Mailhot at laPoste.net Wed Feb 9 06:55:38 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 09 Feb 2005 07:55:38 +0100 Subject: beecrypt-java (Was: rawhide report: 20050207 changes) In-Reply-To: References: <200502071058.j17Awro26452@porkchop.devel.redhat.com> <1107794208.19169.32.camel@localhost.localdomain> <1107812050.15014.1.camel@rousalka.dyndns.org> <20050207225911.GX9362@neu.nirvana> <1107885251.21339.2.camel@rousalka.dyndns.org> Message-ID: <1107932138.11280.4.camel@rousalka.dyndns.org> Le mardi 08 f?vrier 2005 ? 23:39 +0100, Dag Wieers a ?crit : > On Tue, 8 Feb 2005, Nicolas Mailhot wrote: > > > Le lundi 07 f?vrier 2005 ? 23:59 +0100, Axel Thimm a ?crit : > > > On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote: > > > > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because > > > > we have this number of java packages in jpackage. > > > > > > Regardless of naming issues, are indeed 1000 packages waiting to be > > > imported into rawhide? I.e. will all of jpackage be imported? > > > > I don't think so (who knows;) > > But if the java-xx virus caughts on we'd have to preemptively rename a > > lot of stuff just in case it gets imported someday (to avoid packagename > > conflicts later) > > > > Not fun at all;( > > Well, that's why a policy should have been made at the very start. Naming > is very important and the lack of a naming policy is causing all sorts of > confusions and problems (like the lack of a 'virtual package' namespace). The point that you seem to miss of course is the "very start" was several years ago for jpackage. Moreover jpackage is not a pure FC pipe - its release schedule is not synched with FC's at all. Even if only say 25% of the packages were to be changed they're likely to be core packages with mass rebuilds as the result to fix requires in the rest of the repo. For a win that's dubious at best given the platform fragmentation. Regards, -- Nicolas Mailhot -------------- next part -------------- A 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 byte at aeon.com.my Wed Feb 9 07:04:50 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 09 Feb 2005 15:04:50 +0800 Subject: Fedora Core 3 (4?) Live CD In-Reply-To: <80d7e409050206175342cd6ab2@mail.gmail.com> References: <20050204221256.GB11004@rogers.com> <1107688393.5367.94.camel@localhost.localdomain> <80d7e409050206175342cd6ab2@mail.gmail.com> Message-ID: <1107932691.6866.98.camel@localhost.localdomain> On Sun, 2005-02-06 at 18:53 -0700, Stephen J. Smoogen wrote: > > On the agenda for discussion at FUDCon is definitely to talk about a > > Fedora LiveCD, created via the Stateless Linux system > > > > There is however one that Dirk Westfal has created, thats pretty > good as > > well, so give that a twirl > > Pointers of where I could find that? We have some questions for > setting up a lot of diskless workstations that would use the Stateless > Disk system. http://fedora.redhat.com/projects/stateless/ http://www.linux4all.de/ The latter link has some plans on getting the LiveCD scripts working alongside StatelessLinux as well... -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From sitsofe at yahoo.com Wed Feb 9 08:29:14 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Wed, 09 Feb 2005 08:29:14 +0000 Subject: ALSA CVS dmix defaulted for certain cards? Message-ID: <1107937754.4310.10.camel@galvatron.localdomain> According to https://bugtrack.alsa-project.org/alsa-bug/view.php?id=863% 3E it sounds like ALSA will default certain mobo sounds cards to using dmix... Does anyone know if this is the case and whether this will make it's way into FC4 or is compatible with the way FC4 was going to enable dmix? -- Sitsofe | http://sucs.org/~sits/ From niki.waibel at newlogic.com Wed Feb 9 12:29:49 2005 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed, 09 Feb 2005 13:29:49 +0100 (CET) Subject: dmraid / initrd Message-ID: <200502091229.j19CTn66027809@enterprise2.newlogic.at> who is reponsible for the initial ramdisk? would like to know if dmraid support will be integrated into initrd in fc4. thanks, niki -- niki w. waibel - system administrator @ newlogic technologies ag From buildsys at redhat.com Wed Feb 9 12:38:32 2005 From: buildsys at redhat.com (Build System) Date: Wed, 9 Feb 2005 07:38:32 -0500 Subject: rawhide report: 20050209 changes Message-ID: <200502091238.j19CcWk13969@porkchop.devel.redhat.com> New package gjdoc GNU Javadoc Updated Packages: OpenIPMI-1.4.11-2 ----------------- anaconda-10.2.0.18-1 -------------------- * Tue Feb 08 2005 Jeremy Katz - 10.2.0.18-1 - Remove some old cruft - Fix-up for new module naming in gnome-python2-canvas 2.9.x - Add needed requirements for rpm 4.4 - Fix segfault when rpm tries to write to non-existent fd during transaction ordering - Support --erroronfail as an option for %pre/%post (clumens, #124386) * Tue Feb 08 2005 Jeremy Katz - 10.2.0.17-1 - Use rhpl.archscore to fix iseries upgrades (pnasrat, #146915) - Only configure ksdevice if no --device (pnasrat, #138852) - Don't redraw help if disasbled on next button click (clumens, #145691) - Fix exception in exception handler (msw) - Rebuild for new librpm apr-0.9.6-1 ----------- * Wed Feb 09 2005 Joe Orton 0.9.6-1 - update to 0.9.6 apr-util-0.9.6-1 ---------------- * Wed Feb 09 2005 Joe Orton 0.9.6-1 - update to 0.9.6 cpufreq-utils-1:0.1pre3-1.1.7 ----------------------------- cpuspeed-1:1.2.1-1.17 --------------------- * Tue Feb 08 2005 Dave Jones - Rebuild with -D_FORTIFY_SOURCE=2 dmidecode-1:2.5-1.8 ------------------- * Tue Feb 08 2005 Dave Jones - Rebuild with -D_FORTIFY_SOURCE=2 dos2unix-3.1-22 --------------- * Tue Feb 08 2005 Mike A. Harris 3.1-22 - Bump and rebuild for FC4 elinks-0.10.2-1 --------------- * Tue Feb 08 2005 Karel Zak 0.10.2-1 - sync with upstream; stable 0.10.2 evolution-data-server-1.0.2-3 ----------------------------- * Wed Oct 20 2004 David Malcolm - 1.0.2-3 - added workaround for a backend leak that causes the "contacts" calendar backend to hold open an EBook for the local contacts (filed upstream at: http://bugzilla.ximian.com/show_bug.cgi?id=68533 ); this was causing e-d-s to never lose its last addressbook, and hence never quit. We workaround this by detecting this condition and exiting when it occurs, fixing bug #134851 and #134849. * Tue Oct 12 2004 David Malcolm - 1.0.2-2 - added patch to fix build on x86_64 (had multiple definitions of mutex code in libdb/dbinc.mutex.h) * Tue Oct 12 2004 David Malcolm - 1.0.2-1 - update from 1.0.1 to 1.0.2 - increased libsoup requirement to 2.2.1 to match configuration script evolution-data-server-1.1.5-3 ----------------------------- * Tue Feb 08 2005 David Malcolm - 1.1.5-3 - rebuild * Tue Feb 08 2005 David Malcolm - 1.1.5-2 - forgot to fix sources * Tue Feb 08 2005 David Malcolm - 1.1.5-1 - 1.1.5 fribidi-0.10.4-7 ---------------- * Wed Feb 09 2005 Caolan McNamara 0.10.4-7 - rebuilt gamin-0.0.23-1 -------------- * Tue Feb 08 2005 Daniel Veillard 0.0.23-1 - memory corruption fix from Mark on the client side - extending the protocol and API to allow skipping Exists and EndExists events to avoid deadlock on reconnect or when they are not used. * Mon Jan 31 2005 Daniel Veillard 0.0.22-1 - bit of python bindings improvements, added test - fixed 3 bugs * Wed Jan 26 2005 Daniel Veillard 0.0.21-1 - Added Python support - Updated for inotify-0.18 gdb-6.3.0.0-0.18 ---------------- * Tue Feb 08 2005 Jeff Johnston 6.3.0.0-0.18 - Modify previous gcore patch to not use linux_proc_xfer_memory even for main thread. glibc-2.3.4-7 ------------- * Tue Feb 08 2005 Jakub Jelinek 2.3.4-7 - update from CVS - fix TLS handling in linuxthreads * Tue Feb 08 2005 Jakub Jelinek 2.3.4-6 - update from CVS - ld.so auditing - fix segfault if chrooted app attempts to dlopen a library and no standard library directory exists at all (#147067, #144303) - fix initgroups when nscd is running, but has group caching disabled (#146588) - fix pthread_key_{create,destroy} in LinuxThreads when pthread_create has not been called yet (#146710) - fix ppc64 swapcontext and setcontext (#146736, BZ#700) - service nscd cosmetic fixes (#146776) - fix IA-32 and x86-64 stack alignment in DSO constructors (#145689) - fix zdump -v segfaults on x86-64 (#146210) - avoid calling sigaction (SIGPIPE, ...) inside syslog (#146021, IT#56686) - fix errno values for futimes (BZ#633) - unconditionally include in malloc.h (BZ#650) - change regex \B handling to match old GNU regex as well as perl/grep's dfa (from empty string inside of word to empty string not at a word boundary, BZ#693) - slightly optimize i686 TLS accesses, use direct TLS %gs access in sem_* and allow building -mno-tls-direct-seg-refs glibc that is free of direct TLS %gs access with negative offsets - fix addseverity - fix fmemopen - fix rewinddir - increase svc{tcp,unix}_create listen backlog * Thu Jan 06 2005 Jakub Jelinek 2.3.4-5 - update from CVS - add some warn_unused_result marking - make ftruncate available even for just -D_POSIX_C_SOURCE=200112L (BZ#640) gtkhtml3-3.5.6-2 ---------------- * Tue Feb 08 2005 David Malcolm - 3.5.6-2 - Changed deprecated "Copyright" directive into a "License" directive - License directive now reads "LGPL/GPL", rather than "LGPL", reflecting comment in README file * Tue Feb 08 2005 David Malcolm - 3.5.6-1 - 3.5.6 hardlink-1:1.0-1.7 ------------------ httpd-2.0.53-4 -------------- * Wed Feb 09 2005 Joe Orton 2.0.53-4 - update to 2.0.53 - move prefork/worker modules comparison to %check irqbalance-1:1.12-1.16 ---------------------- * Tue Feb 08 2005 Dave Jones - Build as pie, also -D_FORTIFY_SOURCE=2 java-1.4.2-gcj4-compat-0:1.4.2.0-4jpp_2rh ----------------------------------------- * Tue Feb 08 2005 Thomas Fitzsimmons - 0:1.4.2.0-4jpp_2rh - Import java-gcj-compat 1.0.13. kdeutils-6:3.3.2-0.2 -------------------- * Tue Feb 08 2005 Than Ngo 6:3.3.2-0.2 - add buildrequires on net-snmp-devel for ksim #147390 kinput2-v3.1-24 --------------- * Tue Feb 08 2005 Akira TAGOH - v3.1-24 - kinput2-redraw.patch: applied to commit the strings after pressing Right button say. (#146204) libgal2-2:2.3.4-1 ----------------- * Tue Feb 08 2005 David Malcolm - 2:2.3.4-1 - 2.3.4 libgconf-java-2.9.91-3 ---------------------- * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-3 - Work around libtool, gcj, -D_FORTIFY_SOURCE=2, rpmbuild problem. libglade-java-2.9.91-3 ---------------------- * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-3 - Work around libtool, gcj, -D_FORTIFY_SOURCE=2, rpmbuild problem. * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-2 - Only build on i386 and x86_64. * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-1 - Import libglade-java 2.9.91. libgnome-java-2.9.91-3 ---------------------- * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-3 - Work around libtool, gcj, -D_FORTIFY_SOURCE=2, rpmbuild problem. * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-2 - Only build on i386 and x86_64. * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-1 - Import libgnome-java 2.9.91. libgtk-java-2.5.91-3 -------------------- * Tue Feb 08 2005 Thomas Fitzsimmons - 2.5.91-3 - Work around libtool, gcj, -D_FORTIFY_SOURCE=2, rpmbuild problem. * Tue Feb 08 2005 Thomas Fitzsimmons - 2.5.91-2 - Only build on i386 and x86_64. * Tue Feb 08 2005 Thomas Fitzsimmons - 2.5.91-1 - Import libgtk-java 2.5.91. libselinux-1.21.8-1 ------------------- * Tue Feb 08 2005 Dan Walsh 1.21.8-1 - Update from NSA * Regenerated av_permissions.h. libwpd-0.7.2-2 -------------- * Wed Feb 09 2005 Caolan McNamara 0.7.2-2 - rebuild lsof-4.74-2 ----------- * Tue Feb 08 2005 Karel Zak 4.74-2 - replace 'Copyright' with 'License' in .spec * Tue Feb 08 2005 Karel Zak 4.74-1 - sync with upstream 4.74 mailman-3:2.1.5-30.fc4 ---------------------- * Tue Feb 08 2005 John Dennis - 3:2.1.5-30.fc4 - fix release tag * Tue Feb 08 2005 John Dennis - 3:2.1.5-29 - fix security vulnerability CAN-2005-0202, errata RHSA-2005:137, bug #147344 * Tue Nov 09 2004 John Dennis 3:2.1.5-28 - fix bug #137863, buildroot path in .pyc files net-snmp-5.2.1-2 ---------------- * Tue Feb 08 2005 Jeremy Katz - 5.2.1-2 - rebuild for new librpm net-tools-1.60-45 ----------------- * Wed Feb 09 2005 Radek Vokal 1.60-45 - included infiniband support (#147396) - added etherwake man page numactl-0.6.4-1.16 ------------------ * Tue Feb 08 2005 Dave Jones - rebuild with -D_FORTIFY_SOURCE=2 openssh-3.9p1-10 ---------------- * Tue Feb 08 2005 Tomas Mraz 3.9p1-10 - enable trusted forwarding by default if X11 forwarding is required by user (#137685 and duplicates) - disable protocol 1 support by default in sshd server config (#88329) - keep the gnome-askpass dialog above others (#69131) * Fri Feb 04 2005 Tomas Mraz - change permissions on pam.d/sshd to 0644 (#64697) - patch initscript so it doesn't kill opened sessions if the sshd daemon isn't running anymore (#67624) ots-0.4.2-3 ----------- * Wed Feb 09 2005 Caolan McNamara - 0.4.2-3 - rebuilt policycoreutils-1.21.13-1 ------------------------- * Tue Feb 08 2005 Dan Walsh 1.21.13-1 - Update from NSA * Merged further change to fixfiles -C from Dan Walsh. * Merged updated fixfiles script from Dan Walsh. - Fix error handling of restorecon python-ldap-0:2.0.6-1 --------------------- * Tue Feb 08 2005 David Malcolm - 0:2.0.6-1 - 2.0.6 redhat-menus-3.7.1-6 -------------------- * Tue Feb 08 2005 - 3.7.1-6 - Don't pick up duplicates in the Others menu rpmdb-fedora-1:4-0.20050209 --------------------------- schedutils-1.4.0-3 ------------------ * Tue Feb 08 2005 Dave Jones - Rebuild for -D_FORTIFY_SOURCE=2 * Tue Oct 12 2004 Dave Jones - Rebuilt. selinux-policy-strict-1.21.9-1 ------------------------------ * Tue Feb 08 2005 Dan Walsh 1.21.9-1 - Update to latest from NSA * Updated capability access vector for audit capabilities. - Fix file_contexts spec selinux-policy-targeted-1.21.9-1 -------------------------------- * Tue Feb 08 2005 Dan Walsh 1.21.9-1 - Update to latest from NSA * Updated capability access vector for audit capabilities. - Fix file_contexts spec * Mon Feb 07 2005 Dan Walsh 1.21.8p-6 - Allow user apps to read event_device_t * Fri Feb 04 2005 Dan Walsh 1.21.8-5 - Add java plugin policy valgrind-1:2.2.0-8 ------------------ * Tue Feb 08 2005 Jakub Jelinek 2.2.0-8 - avoid unnecessary use of nested functions for pthread_once cleanup x86info-1:1.13-1.7 ------------------ xen-2-20050207 -------------- * Tue Feb 08 2005 Rik van Riel 2-20050207 - upgrade to last night's Xen snapshot From toshio at tiki-lounge.com Wed Feb 9 13:47:11 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 09 Feb 2005 08:47:11 -0500 Subject: A tale of two bugzillas Message-ID: <1107956832.8636.27.camel@Madison.badger.com> Are there any substantive differences between bugzilla.redhat.com and bugzilla.redhat.com/beta? In particular, it looks like they are views of the same data so it should be okay to enter information into either one? -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 dwmw2 at infradead.org Wed Feb 9 15:14:56 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 Feb 2005 15:14:56 +0000 Subject: rawhide report: 20050209 changes In-Reply-To: <200502091238.j19CcWk13969@porkchop.devel.redhat.com> References: <200502091238.j19CcWk13969@porkchop.devel.redhat.com> Message-ID: <1107962096.19262.531.camel@hades.cambridge.redhat.com> On Wed, 2005-02-09 at 07:38 -0500, Build System wrote: > libglade-java-2.9.91-3 > * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-2 > - Only build on i386 and x86_64. Why? -- dwmw2 From overholt at redhat.com Wed Feb 9 15:22:32 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 9 Feb 2005 10:22:32 -0500 Subject: rawhide report: 20050209 changes In-Reply-To: <1107962096.19262.531.camel@hades.cambridge.redhat.com> References: <200502091238.j19CcWk13969@porkchop.devel.redhat.com> <1107962096.19262.531.camel@hades.cambridge.redhat.com> Message-ID: <20050209152232.GA856@redhat.com> * David Woodhouse [2005-02-09 10:15]: > On Wed, 2005-02-09 at 07:38 -0500, Build System wrote: > > libglade-java-2.9.91-3 > > > * Tue Feb 08 2005 Thomas Fitzsimmons - 2.9.91-2 > > - Only build on i386 and x86_64. > > Why? Because eclipse-ecj is our bytecode compiler and we're having issues building it on other architectures. When new gcc4 rpms hit, I'm going to push in a new build of eclipse 3.1 M4 (much cleaner build procedure this time) and get it onto all platforms. Then we can rebuild the Java-GNOME bindings on all platforms. Andrew From katzj at redhat.com Wed Feb 9 15:47:03 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 09 Feb 2005 10:47:03 -0500 Subject: A tale of two bugzillas In-Reply-To: <1107956832.8636.27.camel@Madison.badger.com> References: <1107956832.8636.27.camel@Madison.badger.com> Message-ID: <1107964024.5706.12.camel@bree.local.net> On Wed, 2005-02-09 at 08:47 -0500, Toshio wrote: > Are there any substantive differences between bugzilla.redhat.com and > bugzilla.redhat.com/beta? In particular, it looks like they are views > of the same data so it should be okay to enter information into either > one? It's the same database. /beta is the current devel one (and a lot nicer in a lot of ways) and should be becoming the main interface "real soon now" Jeremy From stevelist at silverorange.com Wed Feb 9 18:10:43 2005 From: stevelist at silverorange.com (Steven Garrity) Date: Wed, 09 Feb 2005 14:10:43 -0400 Subject: A tale of two bugzillas In-Reply-To: <1107964024.5706.12.camel@bree.local.net> References: <1107956832.8636.27.camel@Madison.badger.com> <1107964024.5706.12.camel@bree.local.net> Message-ID: <420A5223.3040002@silverorange.com> Jeremy Katz wrote: > On Wed, 2005-02-09 at 08:47 -0500, Toshio wrote: >>Are there any substantive differences between bugzilla.redhat.com and >>bugzilla.redhat.com/beta? In particular, it looks like they are views >>of the same data so it should be okay to enter information into either >>one? > > It's the same database. /beta is the current devel one (and a lot nicer > in a lot of ways) and should be becoming the main interface "real soon > now" Who has been doing the visual/UI customization in the new beta Bugzilla? It looks great. I'd love to see if we could get this kind of customization and integration into the Mozilla.org style for bugzilla.mozilla.org Thanks, Steven Garrity From rms at 1407.org Wed Feb 9 22:13:20 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 09 Feb 2005 22:13:20 +0000 Subject: yum bug or repo too borked? Message-ID: <1107987200.5149.1.camel@roque> Or is it me, some how? Ok, so repo is borked... I try to update in parts... [root at roque ~]# yum update hotplug* mod_* xterm x86info ntsysv nscd* nptl* vim* lsof Setting up Update Process Setting up Repos development 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files developmen: ################################################## 3741/3741 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package ntsysv.i386 0:1.3.15-1 set to be updated ---> Package vim-enhanced.i386 1:6.3.061-2 set to be updated ---> Package x86info.i386 1:1.13-1.7 set to be updated ---> Package vim-minimal.i386 1:6.3.061-2 set to be updated ---> Package xterm.i386 0:200-2 set to be updated ---> Package nptl-devel.i686 0:2.3.4-7 set to be updated ---> Package mod_ssl.i386 1:2.0.53-4 set to be updated ---> Package hotplug.i386 3:2004_09_23-1 set to be updated ---> Package lsof.i386 0:4.74-2 set to be updated ---> Package nscd.i386 0:2.3.4-7 set to be updated ---> Package vim-common.i386 1:6.3.061-2 set to be updated --> Running transaction check --> Processing Dependency: chkconfig = 1.3.15 for package: ntsysv --> Processing Dependency: httpd = 2.0.53-4 for package: mod_ssl --> Processing Dependency: glibc-devel = 2.3.4-7 for package: nptl-devel --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package chkconfig.i386 0:1.3.15-1 set to be updated ---> Package glibc-devel.i386 0:2.3.4-7 set to be updated ---> Package httpd.i386 0:2.0.53-4 set to be updated --> Running transaction check --> Processing Dependency: httpd = 2.0.52 for package: httpd-devel --> Processing Dependency: httpd = 2.0.52-6 for package: httpd-suexec --> Processing Dependency: httpd = 2.0.52-6 for package: httpd-manual --> Processing Dependency: glibc-headers = 2.3.4-7 for package: glibc-devel --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package glibc-headers.i386 0:2.3.4-7 set to be updated ---> Package httpd-devel.i386 0:2.0.53-4 set to be updated ---> Package httpd-suexec.i386 0:2.0.53-4 set to be updated ---> Package httpd-manual.i386 0:2.0.53-4 set to be updated --> Running transaction check Dependencies Resolved Transaction Listing: Update: xterm.i386 0:200-2 - development Update: x86info.i386 1:1.13-1.7 - development Update: nscd.i386 0:2.3.4-7 - development Update: nptl-devel.i686 0:2.3.4-7 - development Update: mod_ssl.i386 1:2.0.53-4 - development Update: hotplug.i386 3:2004_09_23-1 - development Update: ntsysv.i386 0:1.3.15-1 - development Update: vim-enhanced.i386 1:6.3.061-2 - development Update: vim-minimal.i386 1:6.3.061-2 - development Update: vim-common.i386 1:6.3.061-2 - development Update: lsof.i386 0:4.74-2 - development Performing the following to resolve dependencies: Update: chkconfig.i386 0:1.3.15-1 - development Update: httpd.i386 0:2.0.53-4 - development Update: httpd-manual.i386 0:2.0.53-4 - development Update: httpd-suexec.i386 0:2.0.53-4 - development Update: httpd-devel.i386 0:2.0.53-4 - development Update: glibc-headers.i386 0:2.3.4-7 - development Update: glibc-devel.i386 0:2.3.4-7 - development Total download size: 12 M Is this ok [y/N]: y Downloading Packages: Traceback (most recent call last): File "/usr/bin/yum", line 7, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 146, in main base.doTransaction() File "/usr/share/yum-cli/cli.py", line 630, in doTransaction problems = self.downloadPkgs(downloadpkgs) File "__init__.py", line 442, in downloadPkgs File "repos.py", line 521, in get File "mirror.py", line 414, in urlgrab File "mirror.py", line 400, in _mirror_try File "grabber.py", line 601, in urlgrab File "grabber.py", line 533, in _retry File "grabber.py", line 587, in retryfunc File "grabber.py", line 709, in __init__ File "grabber.py", line 752, in _do_open File "grabber.py", line 817, in _build_range File "byterange.py", line 422, in range_tuple_to_header TypeError: not enough arguments for format string [root at roque ~]# -- + 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 Wed Feb 9 22:19:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 17:19:22 -0500 Subject: yum bug or repo too borked? In-Reply-To: <1107987200.5149.1.camel@roque> References: <1107987200.5149.1.camel@roque> Message-ID: <1107987563.4617.30.camel@cutter> On Wed, 2005-02-09 at 22:13 +0000, Rui Miguel Seabra wrote: > Or is it me, some how? > > Ok, so repo is borked... I try to update in parts... > https://bugzilla.redhat.com/beta/show_bug.cgi?id=147124 -sv From rms at 1407.org Wed Feb 9 22:23:30 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 09 Feb 2005 22:23:30 +0000 Subject: yum bug or repo too borked? In-Reply-To: <1107987563.4617.30.camel@cutter> References: <1107987200.5149.1.camel@roque> <1107987563.4617.30.camel@cutter> Message-ID: <1107987810.5149.3.camel@roque> On Wed, 2005-02-09 at 17:19 -0500, seth vidal wrote: > On Wed, 2005-02-09 at 22:13 +0000, Rui Miguel Seabra wrote: > > Or is it me, some how? > > > > Ok, so repo is borked... I try to update in parts... > > > > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=147124 Thanks, although I have hit this only with yesterday's build repo. And I've been curving around bad dependencies manually. Regards, 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 Wed Feb 9 22:26:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 17:26:58 -0500 Subject: yum bug or repo too borked? In-Reply-To: <1107987810.5149.3.camel@roque> References: <1107987200.5149.1.camel@roque> <1107987563.4617.30.camel@cutter> <1107987810.5149.3.camel@roque> Message-ID: <1107988018.4617.32.camel@cutter> On Wed, 2005-02-09 at 22:23 +0000, Rui Miguel Seabra wrote: > On Wed, 2005-02-09 at 17:19 -0500, seth vidal wrote: > > On Wed, 2005-02-09 at 22:13 +0000, Rui Miguel Seabra wrote: > > > Or is it me, some how? > > > > > > Ok, so repo is borked... I try to update in parts... > > > > > > > > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=147124 > > Thanks, although I have hit this only with yesterday's build repo. it doesn't happen all the time - it's caused by a reget, actually. -sv From rms at 1407.org Wed Feb 9 22:28:10 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 09 Feb 2005 22:28:10 +0000 Subject: yum bug or repo too borked? In-Reply-To: <1107988018.4617.32.camel@cutter> References: <1107987200.5149.1.camel@roque> <1107987563.4617.30.camel@cutter> <1107987810.5149.3.camel@roque> <1107988018.4617.32.camel@cutter> Message-ID: <1107988090.5149.5.camel@roque> On Wed, 2005-02-09 at 17:26 -0500, seth vidal wrote: > On Wed, 2005-02-09 at 22:23 +0000, Rui Miguel Seabra wrote: > > On Wed, 2005-02-09 at 17:19 -0500, seth vidal wrote: > > > On Wed, 2005-02-09 at 22:13 +0000, Rui Miguel Seabra wrote: > > > > Or is it me, some how? > > > > > > > > Ok, so repo is borked... I try to update in parts... > > > > > > > > > > > > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=147124 > > > > Thanks, although I have hit this only with yesterday's build repo. > > it doesn't happen all the time - it's caused by a reget, actually. Ah, cool. Then mybe rm -rf /var/cache/yum/development will help me :) 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 Wed Feb 9 22:30:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Feb 2005 17:30:03 -0500 Subject: yum bug or repo too borked? In-Reply-To: <1107988090.5149.5.camel@roque> References: <1107987200.5149.1.camel@roque> <1107987563.4617.30.camel@cutter> <1107987810.5149.3.camel@roque> <1107988018.4617.32.camel@cutter> <1107988090.5149.5.camel@roque> Message-ID: <1107988203.4617.37.camel@cutter> > Ah, cool. Then mybe rm -rf /var/cache/yum/development will help me :) > yum clean packages should do it. -sv From ivazquez at ivazquez.net Thu Feb 10 05:55:59 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 10 Feb 2005 00:55:59 -0500 Subject: Self-Introduction: Ignacio Vazquez-Abrams Message-ID: <1108014959.5351.22.camel@localhost.localdomain> Name: Ignacio Vazquez-Abrams Location: Toronto, Ontario, Canada Occupation: Freelance sysadmin and software developer Synopsis: I have been using Linux for 8 years, most of it Red Hat Linux. I have in the past participated in newsgroups, mailing lists, and/or forums pertaining to PHP, Python, Delphi, XML/XSLT, and Linux, and have contributed to the phpMyAdmin, HTML Tidy, and JVCL projects. I currently run a Fedora-oriented website and FC3 repository at http://fedora.ivazquez.net/. I also spend time in #fedora and other channels on freenode helping out when I can. Goals: As maintainer of my own repository I've come across several packages both general-purpose and niche that I feel would be appropriate to be contained in a repository that more people would use. To that end I am willing to maintain most if not all of the packages that make it from my repository into Fedora Extras or even the Core. Key Fingerprint: 9C43 FB95 A4BE 2876 F304 A984 A0AD 47B2 7B1E 87C4 -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A 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 toni at willberg.fi Thu Feb 10 08:06:50 2005 From: toni at willberg.fi (Toni Willberg) Date: Thu, 10 Feb 2005 10:06:50 +0200 Subject: suggestion: searchable package list site Message-ID: <1108022810.22573.16.camel@held119> Hello. I'd like to see something similar as the Debian Packages(*) site for Fedora Extras and Core. Unfortunately I can't implement it myself - even if I wanted. I've already ran out of time, so this is just to start discussion. Yours, Toni *) http://www.debian.org/distrib/packages -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Feb 10 08:13:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 10 Feb 2005 03:13:44 -0500 Subject: suggestion: searchable package list site In-Reply-To: <1108022810.22573.16.camel@held119> References: <1108022810.22573.16.camel@held119> Message-ID: <1108023225.8233.8.camel@cutter> On Thu, 2005-02-10 at 10:06 +0200, Toni Willberg wrote: > Hello. > > I'd like to see something similar as the Debian Packages(*) site for > Fedora Extras and Core. > > Unfortunately I can't implement it myself - even if I wanted. I've > already ran out of time, so this is just to start discussion. > If someone wants to design an interface that they think would be effective I think that would be a great place to start. get a nice layout and the backend stuff can be worked out in coming weeks. -sv From kzak at redhat.com Thu Feb 10 08:43:18 2005 From: kzak at redhat.com (Karel Zak) Date: Thu, 10 Feb 2005 09:43:18 +0100 Subject: suggestion: searchable package list site In-Reply-To: <1108022810.22573.16.camel@held119> References: <1108022810.22573.16.camel@held119> Message-ID: <1108024998.4044.42.camel@petra> On Thu, 2005-02-10 at 10:06 +0200, Toni Willberg wrote: > Hello. > > I'd like to see something similar as the Debian Packages(*) site for > Fedora Extras and Core. > > Unfortunately I can't implement it myself - even if I wanted. I've > already ran out of time, so this is just to start discussion. > > Yours, > Toni > > *) http://www.debian.org/distrib/packages I have something like this in my TODO. Maybe in next two weeks I will have some results. Karel -- Karel Zak From gauret at free.fr Thu Feb 10 08:42:46 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 10 Feb 2005 09:42:46 +0100 Subject: suggestion: searchable package list site References: <1108022810.22573.16.camel@held119> Message-ID: Toni Willberg wrote: > I'd like to see something similar as the Debian Packages(*) site for > Fedora Extras and Core. Fedora Tracker could be a good start : http://www.fedoratracker.org/ Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "L'adulte ne croit pas au P?re No?l. Il vote." -- Pierre Desproges From jorton at redhat.com Thu Feb 10 09:21:14 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 10 Feb 2005 09:21:14 +0000 Subject: Raw Hide ypbind/initscripts issues Message-ID: <20050210092114.GA4319@redhat.com> I'm not sure what package to file this bug against: in Raw Hide, the ypbind service is being started before the network is brought up, and so fails to initialize. The chkconfig runlevels listed in /etc/init.d/ypbind have not changed so maybe something else has? (this bug is new since FC3) joe From roland at redhat.com Thu Feb 10 09:24:08 2005 From: roland at redhat.com (Roland McGrath) Date: Thu, 10 Feb 2005 01:24:08 -0800 Subject: Raw Hide ypbind/initscripts issues In-Reply-To: Joe Orton's message of Thursday, 10 February 2005 09:21:14 +0000 <20050210092114.GA4319@redhat.com> Message-ID: <200502100924.j1A9O8YT010756@magilla.sf.frob.com> > I'm not sure what package to file this bug against: > > in Raw Hide, the ypbind service is being started before the network is > brought up, and so fails to initialize. The chkconfig runlevels listed > in /etc/init.d/ypbind have not changed so maybe something else has? > > (this bug is new since FC3) Also tries to mount nfs filesystems before starting the network. I think what changed is the init order of the network interfaces getting configured/dhcp et al. From aoliva at redhat.com Thu Feb 10 10:00:42 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Feb 2005 08:00:42 -0200 Subject: Raw Hide ypbind/initscripts issues In-Reply-To: <200502100924.j1A9O8YT010756@magilla.sf.frob.com> References: <200502100924.j1A9O8YT010756@magilla.sf.frob.com> Message-ID: On Feb 10, 2005, Roland McGrath wrote: >> I'm not sure what package to file this bug against: >> >> in Raw Hide, the ypbind service is being started before the network is >> brought up > Also tries to mount nfs filesystems before starting the network. And starts ntp before the network -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dhollis at davehollis.com Thu Feb 10 11:14:43 2005 From: dhollis at davehollis.com (David Hollis) Date: Thu, 10 Feb 2005 06:14:43 -0500 Subject: Raw Hide ypbind/initscripts issues In-Reply-To: References: <200502100924.j1A9O8YT010756@magilla.sf.frob.com> Message-ID: <1108034083.4861.6.camel@dhollis-lnx.centricconsulting.com> On Thu, 2005-02-10 at 08:00 -0200, Alexandre Oliva wrote: > On Feb 10, 2005, Roland McGrath wrote: > > >> I'm not sure what package to file this bug against: > >> > >> in Raw Hide, the ypbind service is being started before the network is > >> brought up > > > Also tries to mount nfs filesystems before starting the network. > > And starts ntp before the network Is it because the interfaces are being handled by NetworkManager? NetworkManager starts pretty late due to needing haldaemon and messagebus. Of course, it starts really late if you are on a wireless connection and need to enter a passphrase which won't happen until you've logged in. -- David Hollis -------------- next part -------------- A 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 jorton at redhat.com Thu Feb 10 11:46:39 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 10 Feb 2005 11:46:39 +0000 Subject: Raw Hide ypbind/initscripts issues In-Reply-To: <1108034083.4861.6.camel@dhollis-lnx.centricconsulting.com> References: <200502100924.j1A9O8YT010756@magilla.sf.frob.com> <1108034083.4861.6.camel@dhollis-lnx.centricconsulting.com> Message-ID: <20050210114639.GA8273@redhat.com> On Thu, Feb 10, 2005 at 06:14:43AM -0500, David Hollis wrote: > On Thu, 2005-02-10 at 08:00 -0200, Alexandre Oliva wrote: > > On Feb 10, 2005, Roland McGrath wrote: > > > > >> I'm not sure what package to file this bug against: > > >> > > >> in Raw Hide, the ypbind service is being started before the network is > > >> brought up > > > > > Also tries to mount nfs filesystems before starting the network. > > > > And starts ntp before the network > > Is it because the interfaces are being handled by NetworkManager? > NetworkManager starts pretty late due to needing haldaemon and > messagebus. Of course, it starts really late if you are on a wireless > connection and need to enter a passphrase which won't happen until > you've logged in. I don't think so: [root at trash ~]# chkconfig --list NetworkManager NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off From alan at balclutha.org Thu Feb 10 11:49:38 2005 From: alan at balclutha.org (Alan Milligan) Date: Thu, 10 Feb 2005 22:49:38 +1100 Subject: Courier RPM Message-ID: <420B4A52.20107@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unfortunately, courier is a bit screwed for mass RPM distribution. The problem is that it is ESSENTIAL that the courier user is defined and defined to have the same uid/gid on the build server and the target clients. The courier spec itself does not define such a user, and obviously this is something that would have to be agreed at distro level. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCC0pSCfroLk4EZpkRAjf2AJ9QEI0JcqVrN6BhXxDWG4bdOxF/kACgwsdo K/JFaZEmuw4seR3qecDy70o= =H62J -----END PGP SIGNATURE----- From rahulsundaram at gmail.com Thu Feb 10 11:50:32 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Thu, 10 Feb 2005 17:20:32 +0530 Subject: Self-Introduction: Ignacio Vazquez-Abrams In-Reply-To: <1108014959.5351.22.camel@localhost.localdomain> References: <1108014959.5351.22.camel@localhost.localdomain> Message-ID: Hi > > Goals: As maintainer of my own repository I've come across several > packages both general-purpose and niche that I feel would be appropriate > to be contained in a repository that more people would use. To that end > I am willing to maintain most if not all of the packages that make it > from my repository into Fedora Extras or even the Core. > you can start by proposing individual packages to the fedora extras list -- Regards, Rahul Sundaram From ndbecker2 at verizon.net Thu Feb 10 12:28:18 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Thu, 10 Feb 2005 07:28:18 -0500 Subject: freenx? Message-ID: Has anyone had any success building freenx on FC3? I just grabbed the srpm that was posted to fedoranews.org, but it doesn't compile on FC3. From rahulsundaram at yahoo.co.in Thu Feb 10 12:35:55 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 10 Feb 2005 04:35:55 -0800 (PST) Subject: freenx? In-Reply-To: Message-ID: <20050210123555.780.qmail@web8505.mail.in.yahoo.com> --- Neal Becker wrote: > Has anyone had any success building freenx on FC3? > I just grabbed the srpm > that was posted to fedoranews.org, but it doesn't > compile on FC3. this is the development list. please ask your question in the fedora users list Thanks ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From rdieter at math.unl.edu Thu Feb 10 12:46:02 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 10 Feb 2005 06:46:02 -0600 Subject: freenx? In-Reply-To: References: Message-ID: <420B578A.5030404@math.unl.edu> Neal Becker wrote: > Has anyone had any success building freenx on FC3? I just grabbed the srpm > that was posted to fedoranews.org, but it doesn't compile on FC3. The the (old) Fedora Extras submission: http://bugzilla.fedora.us/show_bug.cgi?id=2101 -- Rex From buildsys at redhat.com Thu Feb 10 12:51:50 2005 From: buildsys at redhat.com (Build System) Date: Thu, 10 Feb 2005 07:51:50 -0500 Subject: rawhide report: 20050210 changes Message-ID: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> New package aqbanking A library for online banking functions and financial data import/export. New package aqhbci The HBCI backend for the Aqbanking library. New package gwenhywfar A multi-platform helper library for other libraries Removed package openhbci Updated Packages: ORBit2-2.12.1-1 --------------- * Wed Feb 09 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 SDL_image-1.2.3-7 ----------------- * Wed Feb 09 2005 Thomas Woerner 1.2.3-7 - rebuild SDL_mixer-1.2.5-5 ----------------- * Wed Feb 09 2005 Thomas Woerner 1.2.5-5 - rebuild SDL_net-1.2.5-3 --------------- * Wed Feb 09 2005 Thomas Woerner 1.2.5-3 - rebuild acl-2.2.23-7 ------------ * Wed Feb 09 2005 Stephen C. Tweedie 2.2.23-6 - Rebuild adjtimex-1.13-15 ---------------- * Thu Feb 10 2005 Jindrich Novy 1.13-15 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 1.13-14 - add -D_FORTIFY_SOURCE=2 to CFLAGS - spec cleanup attr-2.4.16-4 ------------- * Wed Feb 09 2005 Stephen C. Tweedie 2.4.16-4 - Rebuild cdparanoia-alpha9.8-24.2 ------------------------ * Wed Feb 09 2005 Peter Jones alpha9.8-24.2 - Rebuild for new toolchain cdrdao-1.1.9-7 -------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt cdrtools-8:2.01.1-6 ------------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt coreutils-5.2.1-41 ------------------ * Wed Feb 09 2005 Tim Waugh 5.2.1-41 - Jakub's sort -t multibyte fixes (bug #147567). cproto-4.7c-5 ------------- * Thu Feb 10 2005 Jindrich Novy 4.7c-5 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 4.7c-4 - add RPM_OPT_FLAGS to CFLAGS - convert Copyright to License - rebuild with -D_FORTIFY_SOURCE=2 cpufreq-utils-1:0.1pre3-1.1.9 ----------------------------- ctags-5.5.4-2 ------------- * Wed Feb 09 2005 Than Ngo 5.5.4-2 - rebuilt curl-7.12.3-3 ------------- * Wed Feb 09 2005 Joe Orton 7.12.3-3 - don't pass /usr to --with-libidn to remove "-L/usr/lib" from 'curl-config --libs' output on x86_64. diffutils-2.8.1-13 ------------------ * Wed Feb 09 2005 Tim Waugh 2.8.1-13 - Rebuilt. docbook-style-xsl-1.68.0-1 -------------------------- * Wed Feb 09 2005 Tim Waugh 1.68.0-1 - 1.68.0. dvd+rw-tools-5.21.4.10.8-3 -------------------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt e2fsprogs-1.35-12 ----------------- * Wed Feb 09 2005 Thomas Woerner 1.35-12 - rebuild * Wed Dec 22 2004 Stephen C. Tweedie - Disable offline resize for now: resize2fs is incompatible with online resize, and can result in corrupt filesystems. * Thu Dec 09 2004 Stephen C. Tweedie - More byte-order fixes for mke2fs and ext2online - Disable fallback to old-style resize if new kernel resize code is not available efax-0.9-23 ----------- * Wed Feb 09 2005 Than Ngo 0.9-23 - rebuilt epiphany-1.5.6-1 ---------------- * Wed Feb 09 2005 Matthias Clasen - 1.5.6-1 - Update to 1.5.6 evince-0.1.4-1 -------------- * Wed Feb 09 2005 Marco Pesenti Gritti - 0.1.4-1 - Update to 0.1.4 - Install schemas and update desktop database evolution-2.1.5-1 ----------------- * Wed Feb 09 2005 David Malcolm - 2.1.5-1 - Update from upstream unstable 2.1.4 to 2.1.5 - Updated requirements: * gtkhtml3 from 3.5.4 to 3.5.6 * libgal2 from 2.3.3 to 2.3.4 * eds from 1.1.4.1 to 1.1.5 - Removed explicit packaging of weather icons as these are now below DATADIR/evolution/2.2 rather than DATADIR/evolution-2.2 * Wed Jan 26 2005 David Malcolm - 2.1.4-1 - Update from upstream stable 2.0.3 to unstable 2.1.4 - Updated evo_major from 2.0 to 2.2 - Removed camel packaging as this has been moved to evolution-data-server for Evolution 2.2 - Added plugins to the packaged files - Added weather icons to the packaged files - Updated requirements: * gtkhtml3 from 3.3.2 to 3.5.4 * libgal2 from 2.2.4 to 2.3.3 * eds from 1.0.3 to 1.1.4.1 * libsoup from 2.2.0 to 2.2.2 - Added built-time requirement on atk-devel - Enable all plugins for now - Added requirement on dbus (for the new-mail-notify plugin) - Enable gtk-doc - Updated GConf schema name suffixes from 2.0 to 2.2 * Sun Dec 19 2004 Christopher Aillon 2.0.3-2 - Rebuild against mozilla 1.7.5 evolution-connector-2.1.5-1 --------------------------- * Wed Feb 09 2005 David Malcolm - 2.1.5-1 - Update from unstable upstream 2.1.4 to 2.1.5 - Require evolution 2.1.5 evolution-webcal-2.1.91-1 ------------------------- * Wed Feb 09 2005 David Malcolm - 2.1.91-1 - updated from 2.1.4 to 2.1.91 fbset-2.1-19 ------------ * Thu Feb 10 2005 Jindrich Novy 2.1-19 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 2.1-18 - Copyright -> License conversion - rebuilt with -D_FORTIFY_SOURCE=2 file-roller-2.9.91-1 -------------------- * Wed Feb 09 2005 Matthias Clasen 2.9.91-1 - Update to 2.9.91 finger-0.17-27 -------------- * Wed Feb 09 2005 Radek Vokal 0.17-27 - rebuilt to get fortified fsh-1.2-6 --------- * Wed Feb 09 2005 David Woodhouse 1.2-6 - Fix to build with python 2.4. Fixes #142071 ftpcopy-0.6.2-8 --------------- * Wed Feb 09 2005 Thomas Woerner 0.6.2-8 - rebuild gedit-1:2.9.6-1 --------------- * Wed Feb 09 2005 Matthias Clasen 1:2.9.6-1 - Update to 2.9.6 ggv-2.8.3-1 ----------- * Wed Feb 09 2005 Matthias Clasen 2.8.3-1 - Update to 2.8.3 gmp-4.1.4-4 ----------- * Wed Feb 09 2005 Karsten Hopp 4.1.4-4 - rebuilt gnome-applets-1:2.9.6-1 ----------------------- * Wed Feb 09 2005 Matthias Clasen - 2.9.6-1 - Update to 2.9.6 * Wed Feb 09 2005 Mark McLoughlin 2.9.5-4 - Add patch for mixer crash - #147282. Thanks Neil Paris for tracking down. gnome-desktop-2.9.91-1 ---------------------- * Wed Feb 09 2005 Matthias Clasen 2.9.91-1 - Update to 2.9.91 gnome-games-1:2.9.6-1 --------------------- * Wed Feb 09 2005 Matthias Clasen 1:2.9.6-1 - Update to 2.9.6 - Needs to wait for newer guile gnome-icon-theme-2.9.91-1 ------------------------- * Wed Feb 09 2005 Matthias Clasen - 2.9.91-1 - Update to 2.9.91 gnome-mag-0.11.14-1 ------------------- * Wed Feb 09 2005 Matthias Clasen 0.11.14-1 - Update to 0.11.14 gnome-panel-2.9.91-1 -------------------- * Wed Feb 09 2005 Matthias Clasen - 2.9.91-1 - Update to 2.9.91 gnome-system-monitor-2.9.91-1 ----------------------------- * Wed Feb 09 2005 Matthias Clasen 2.9.91-1 - Update to 2.9.91 gnome-utils-1:2.9.91-1 ---------------------- * Wed Feb 09 2005 Matthias Clasen 1:2.9.91-1 - Update to gnome-utils 2.9.91, zenity 2.9.91, gcalctool 5.5.34 gnomemeeting-1.2.0-5 -------------------- * Wed Feb 09 2005 David Malcolm - 1.2.0-5 - rebuild gnopernicus-0.10.1-1 -------------------- * Wed Feb 09 2005 Matthias Clasen 0.10.1-1 - Update to 0.10.1 gnucash-1.8.11-1 ---------------- * Wed Feb 09 2005 Bill Nottingham 1.8.11-1 - update to 1.8.11 - update docs to 1.8.5 - remove info file (#123444) gob2-2.0.11-2 ------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt * Mon Nov 22 2004 Harald Hoyer - 2.0.11-1 - version 2.0.11 gok-0.12.3-1 ------------ * Wed Feb 09 2005 Matthias Clasen 0.12.3-1 - Update to 0.12.3 gpdf-2.9.3-1 ------------ * Wed Feb 09 2005 Marco Pesenti Gritti 2.9.3-1 - Update to 2.9.3 gperf-3.0.1-5 ------------- * Wed Feb 09 2005 Karsten Hopp 3.0.1-5 - rebuilt gtksourceview-1.1.92-1 ---------------------- * Wed Feb 09 2005 Matthias Clasen - 1.1.92-1 - Update to 1.1.92 guile-5:1.6.7-1 --------------- * Wed Feb 09 2005 Phil Knirsch 5:1.6.7-1 - Update to guile-1.6.7 - Dropped ia64 patch, stuff looks fixed in upstream code hardlink-1:1.0-1.10 ------------------- hexedit-1.2.10-3 ---------------- * Thu Feb 10 2005 Jindrich Novy 1.2.10-3 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 1.2.10-2 - rebuilt with -D_FORTIFY_SOURCE=2 iptstate-1.3-5 -------------- * Wed Feb 09 2005 Thomas Woerner 1.3-5 - rebuild joystick-1.2.15-19 ------------------ * Wed Feb 09 2005 Than Ngo 1.2.15-19 - rebuilt kdbg-1:1.2.10-1 --------------- * Wed Feb 09 2005 Than Ngo 1.2.10-1 - 1.2.10 - drop kdbg-1.2.9-warning.patch, it's included in new upstream kdeedu-3.3.2-0.2 ---------------- * Wed Feb 09 2005 Than Ngo 3.3.2-0.2 - replace kgeo (#142367) * Fri Dec 03 2004 Than Ngo 3.3.2-0.1 - update to 3.3.2 * Mon Oct 18 2004 Than Ngo 3.3.1-2 - rebuilt kernel-2.6.10-1.1136_FC4 ------------------------ * Wed Feb 09 2005 Dave Jones - 2.6.11-rc3-bk6 lha-1.14i-18 ------------ * Wed Feb 09 2005 Than Ngo 1.14i-18 - rebuilt libIDL-0.8.5-1 -------------- * Wed Feb 09 2005 Matthias Clasen 0.8.5-1 - Update to 0.8.5 libbonobo-2.8.1-1 ----------------- * Wed Feb 09 2005 Matthias Clasen 2.8.1-1 - Update to 2.8.1 * Tue Sep 28 2004 Mark McLoughlin 2.8.0-2 - Add patch to make bonobo-activation notice epiphany being installed. Bug #117790 * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 libbtctl-0.4.1-4 ---------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt libcap-1.10-21 -------------- * Wed Feb 09 2005 Karsten Hopp 1.10-21 - rebuilt libgda-1:1.2.0-3 ---------------- * Thu Feb 10 2005 Caolan McNamara 1:1.2.0-3 - bandaid * Wed Feb 09 2005 Jeremy Katz - 1:1.2.0-2 - rebuild to try to fix broken dep libgtop2-2.9.91-1 ----------------- * Wed Feb 09 2005 Matthias Clasen - 2.9.91-1 - Update to 2.9.91 libofx-0.7.0-1 -------------- libwnck-2.9.91-1 ---------------- * Wed Feb 09 2005 Matthias Clasen 2.9.91-1 - Update to 2.9.91 libwvstreams-3.75.0-3 --------------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt libxml-1:1.8.17-13 ------------------ * Wed Feb 09 2005 Daniel Veillard 1.8.17-13 - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt * Tue Mar 02 2004 Elliot Lee - rebuilt longrun-1:0.9-1.7 ----------------- lrzsz-0.12.20-20 ---------------- * Wed Feb 09 2005 Than Ngo 0.12.20-20 - rebuilt lslk-1.29-14 ------------ * Thu Feb 10 2005 Jindrich Novy 1.29-14 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 1.29-13 - add -D_FORTIFY_SOURCE=2 to CFLAGS lvm2-2.01.04-1.0 ---------------- * Wed Feb 09 2005 Alasdair Kergon - 2.01.04-1.0 - Offset pool minors; lvm2cmd.so skips open fd check; pvmove -f gone. macutils-2.0b3-31 ----------------- * Thu Feb 10 2005 Jindrich Novy 2.0b3-31 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 2.0b3-30 - add -D_FORTIFY_SOURCE=2 - define TYPES_H, DIRENT_H, TERMIOS_H, NODOT and APPLEDOUBLE macros explicitely in spec to avoid clashes between CFLAGS in spec and CF defined in the makefile mcelog-1:0.4-1.7 ---------------- metacity-2.9.13-1 ----------------- * Wed Feb 09 2005 Matthias Clasen 2.9.13-1 - Update to 2.9.13 mingetty-1.07-4 --------------- * Wed Feb 09 2005 Karsten Hopp 1.07-4 - rebuilt mpage-2.5.4-3 ------------- * Wed Feb 09 2005 Tim Waugh 2.5.4-3 - Rebuilt. mt-st-0.8-3 ----------- * Thu Feb 10 2005 Jindrich Novy 0.8-3 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 0.8-2 - rebuilt with -D_FORTIFY_SOURCE=2 mtr-2:0.69-1 ------------ * Wed Feb 09 2005 Phil Knirsch 2:0.69-1 - Updated to mtr-0.69 - Dropped quite a few patches - Forewardported the CVE patch mtx-1.2.18-7 ------------ * Thu Feb 10 2005 Jindrich Novy 1.2.18-7 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 1.2.18-6 - rebuilt with -D_FORTIFY_SOURCE=2 nautilus-cd-burner-2.9.6-1 -------------------------- * Wed Feb 09 2005 Matthias Clasen - 2.9.6-1 - Update to 2.9.6 ncftp-2:3.1.8-3 --------------- * Wed Feb 09 2005 Karsten Hopp 2:3.1.8-3 - rebuilt open-1.4-22 ----------- * Wed Feb 09 2005 Than Ngo 1.4-22 - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt openjade-1.3.2-15 ----------------- * Wed Feb 09 2005 Tim Waugh 1.3.2-15 - Rebuilt. openobex-1.0.1-2 ---------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt * Mon Sep 13 2004 Harald Hoyer 1.0.1-1 - version 1.0.1 * Tue Jun 22 2004 Alan Cox - removed now unneeded glib requirement openobex-apps-1.0.0-7 --------------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt oprofile-0.8.1-13 ----------------- * Wed Feb 09 2005 Will Cohen - Do not need -D_FORTIFY_SOURCE=2 * Wed Feb 09 2005 Will Cohen - Rebuild for -D_FORTIFY_SOURCE=2 patch-2.5.4-21 -------------- * Wed Feb 09 2005 Tim Waugh 2.5.4-21 - Rebuilt. * Tue Jun 15 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt pccts-1.33mr33-12 ----------------- * Wed Feb 09 2005 Karsten Hopp 1.33mr33-12 - rebuilt pcmcia-cs-3.2.8-4.6 ------------------- * Wed Feb 09 2005 Dave Jones - Rebuild as pie. php-5.0.3-2 ----------- * Wed Feb 09 2005 Joe Orton 5.0.3-2 - install the ext/gd headers (#145891) - enable pcntl extension in /usr/bin/php (#142903) - add libmbfl array arithmetic fix (dcb314 at hotmail.com, #143795) - add BuildRequire for recent pcre-devel (#147448) pnm2ppa-1:1.04-12 ----------------- * Wed Feb 09 2005 Tim Waugh 1:1.04-12 - s/Copyright:/License:/. - s/Serial:/Epoch:/. - Rebuilt. policycoreutils-1.21.14-1 ------------------------- * Wed Feb 09 2005 Dan Walsh 1.21.14-1 - Update from NSA * Merged restorecon patch from Dan Walsh. pygtk2-2.5.3-2 -------------- * Wed Feb 09 2005 Mark McLoughlin 2.5.3-2 - Backport fix for gnome #154779 - python signal handlers weren't getting executed while gobject.MainLoop was running recode-3.6-14 ------------- * Wed Feb 09 2005 Than Ngo 3.6-14 - rebuilt redhat-rpm-config-8.0.33-1 -------------------------- * Wed Feb 09 2005 Elliot Lee 8.0.33-1 - Change -D to -Wp,-D to make java happy - Add -D_FORTIFY_SOURCE=2 to global cflags (as per Jakub & Arjan's request) * Fri Oct 01 2004 Bill Nottingham 8.0.32-1 - allow all symbol versioning in find_requires - matches RPM internal behavior * Mon Jun 28 2004 Elliot Lee 8.0.31-1 - Add ppc8[25]60 to rpmrc optflags rng-utils-1:2.0-1.4 ------------------- rpmdb-fedora-1:4-0.20050210 --------------------------- salinfo-1:0.5-1.3 ----------------- sash-3.7-5 ---------- * Wed Feb 09 2005 Karsten Hopp 3.7-5 - change Copyright -> License - rebuilt selinux-policy-strict-1.21.11-3 ------------------------------- * Wed Feb 09 2005 Dan Walsh 1.21.11-3 - Add additional texrel_shlib * Wed Feb 09 2005 Dan Walsh 1.21.11-1 - Eliminate lots of net_admin privs. - Add privs to useradd to create homedir correctly * Wed Feb 09 2005 Dan Walsh 1.21.10-1 - Fix traceroute policy for nmap - remove cap31 to prevent checkpolicy bug selinux-policy-targeted-1.21.11-3 --------------------------------- * Wed Feb 09 2005 Dan Walsh 1.21.11-3 - Add additional texrel_shlib * Wed Feb 09 2005 Dan Walsh 1.21.11-1 - Eliminate lots of net_admin privs. - Add privs to useradd to create homedir correctly * Wed Feb 09 2005 Dan Walsh 1.21.10-1 - Fix traceroute policy for nmap - remove cap31 to prevent checkpolicy bug setserial-2.17-18 ----------------- * Wed Feb 09 2005 Tim Waugh 2.17-18 - Rebuilt. sharutils-4.2.1-23 ------------------ * Wed Feb 09 2005 Than Ngo 4.2.1-23 - rebuilt smartmontools-1:5.33-1.4 ------------------------ statserial-1.1-36 ----------------- * Wed Feb 09 2005 Tim Waugh 1.1-36 - Rebuilt. sudo-1.6.7p5-31 --------------- * Wed Feb 09 2005 Thomas Woerner 1.6.7p5-31 - rebuild symlinks-1.2-23 --------------- * Wed Feb 09 2005 Tim Waugh 1.2-23 - s/Copyright:/License:/. sysfsutils-1.2.0-3 ------------------ * Wed Feb 09 2005 AJ Lewis 1.2.0-3 - start using CFLAGS="${CFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m64}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m64}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m64}" ; export FFLAGS ; for i in $(find . -name config.guess -o -name config.sub) ; do [ -f /usr/lib/rpm/redhat/$(basename $i) ] && /bin/rm -f $i && /bin/cp -fv /usr/lib/rpm/redhat/$(basename $i) $i ; done ; ./configure --build=x86_64-redhat-linux --host=x86_64-redhat-linux \ --target=x86_64-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/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info instead of calling configure directly * Wed Feb 09 2005 AJ Lewis 1.2.0-2 - rebuild tcp_wrappers-7.6-38 ------------------- * Wed Feb 09 2005 Thomas Woerner 7.6-38 - rebuild tcpdump-14:3.8.2-8 ------------------ * Thu Feb 10 2005 Ivana Varekova - 14:3.8.2-8 - rebuilt time-1.7-26 ----------- * Wed Feb 09 2005 Karsten Hopp 1.7-26 - update source URL - rebuilt timidity++-2.13.2-1 ------------------- tora-1.3.14.1-3 --------------- * Wed Feb 09 2005 Mihai Ibanescu 1.3.14.1-3 - rebuilt traceroute-1.4a12-25 -------------------- * Wed Feb 09 2005 Radek Vokal 1.4a12-25 - rebuilt - verify icmp checksum only when -I used (#106013) tuxracer-0.61-29 ---------------- * Wed Feb 09 2005 Than Ngo 0.61-29 - rebuilt umb-scheme-3.2-37 ----------------- * Thu Feb 10 2005 Jindrich Novy 3.2-37 - remove -D_FORTIFY_SOURCE=2 from CFLAGS, present in RPM_OPT_FLAGS * Wed Feb 09 2005 Jindrich Novy 3.2-36 - create backup for patches - rebuild with -D_FORTIFY_SOURCE=2 unzip-5.51-9 ------------ * Thu Feb 10 2005 Ivana Varekova 5.51-9 - fix the other problem with unpacking zipfiles containing symlinks (bug #134073) * Thu Feb 03 2005 Ivana Varekova 5.51-8 - fix segfault with unpacking of zipfiles containing dangling symlinks (bug #134073) * Thu Dec 02 2004 Lon Hohberger 5.51-6 - Rebuild w3c-libwww-5.4.0-11 ------------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt which-2.16-5 ------------ * Wed Feb 09 2005 Than Ngo 2.16-5 - rebuilt wvdial-1.54.0-4 --------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt x86info-1:1.13-1.8 ------------------ xcdroast-0.98a15-9 ------------------ * Wed Feb 09 2005 Harald Hoyer - rebuilt * Mon Sep 20 2004 Harald Hoyer - 0.98a15-7 - only add /dev/cdrom* - enable prodvd mode for our cdrecord * Fri Sep 10 2004 Harald Hoyer - 0.98a15-6 - improved scanning and removed warnings xferstats-2.16-12 ----------------- * Wed Feb 09 2005 Than Ngo 2.16-12 - rebuilt xfig-3.2.4-7 ------------ * Wed Feb 09 2005 Than Ngo 3.2.4-7 - rebuilt * Sat Sep 25 2004 Than Ngo 3.2.4-6 - add mimetype spec #131629 xmlsec1-1.2.6-4 --------------- * Wed Feb 09 2005 Daniel Veillard 1.2.6-4 - Adding support for GNUTls crypto backend xmlto-0.0.18-5 -------------- * Wed Feb 09 2005 Tim Waugh 0.0.18-5 - Rebuilt. zisofs-tools-1.0.6-2 -------------------- * Wed Feb 09 2005 Harald Hoyer - rebuilt From twaugh at redhat.com Thu Feb 10 13:31:31 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 10 Feb 2005 13:31:31 +0000 Subject: rawhide report: 20050210 changes In-Reply-To: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> References: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> Message-ID: <20050210133131.GH10885@redhat.com> On Thu, Feb 10, 2005 at 07:51:50AM -0500, Build System wrote: > sysfsutils-1.2.0-3 > ------------------ > * Wed Feb 09 2005 AJ Lewis 1.2.0-3 > - start using > CFLAGS="${CFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m64}" ; export CFLAGS ; [...] > --mandir=/usr/share/man \ > --infodir=/usr/share/info instead of calling configure directly Heh, might want to use '%%configure' there: macros get expanded in the changelog, too. :-) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lkml at mac.com Thu Feb 10 14:44:01 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Thu, 10 Feb 2005 15:44:01 +0100 Subject: freenx? In-Reply-To: References: Message-ID: <6dfec61d78a2d959d50738a4a4987de6@mac.com> On 10 Feb 2005, at 13:28, Neal Becker wrote: > Has anyone had any success building freenx on FC3? I just grabbed the > srpm > that was posted to fedoranews.org, but it doesn't compile on FC3. Try with these ones: http://homepage.mac.com/felipe_alfaro/FileSharing10.html From thacker at math.cornell.edu Thu Feb 10 15:34:28 2005 From: thacker at math.cornell.edu (John Thacker) Date: Thu, 10 Feb 2005 10:34:28 -0500 Subject: rawhide report: 20050210 changes In-Reply-To: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> References: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> Message-ID: <20050210153428.GA12469@thacker.dyndns.org> On Thu, Feb 10, 2005 at 07:51:50AM -0500, Build System wrote: > mtr-2:0.69-1 > ------------ > * Wed Feb 09 2005 Phil Knirsch 2:0.69-1 > - Updated to mtr-0.69 > - Dropped quite a few patches > - Forewardported the CVE patch I assume we waited until now to update mtr's version because of IPv6 support. Since it's updated, I'd like to suggest compiling it with --enable-gtk2, which is an option in this version. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Feb 10 16:27:50 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 10 Feb 2005 11:27:50 -0500 Subject: suggestion: searchable package list site In-Reply-To: References: <1108022810.22573.16.camel@held119> Message-ID: <20050210162750.GA29595@jadzia.bu.edu> On Thu, Feb 10, 2005 at 09:42:46AM +0100, Aurelien Bompard wrote: > Fedora Tracker could be a good start : > http://www.fedoratracker.org/ Try this, to add Fedora Tracker to Firefox's search box: -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From dag at wieers.com Thu Feb 10 16:47:26 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 10 Feb 2005 17:47:26 +0100 (CET) Subject: Better repodata performance In-Reply-To: References: <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <41FC2248.3010100@sbcglobal.net> <20050130001209.GE21431@angus.ind.WPI.EDU> Message-ID: On Mon, 7 Feb 2005, Dag Wieers wrote: > On Sun, 29 Jan 2005, Alexandre Oliva wrote: > > On Jan 29, 2005, "Charles R. Anderson" wrote: > > > > > Why all the complication when a general-purpose algorithm, rsync, > > > already exists to solve this problem? > > > > It doesn't do very well on compressed files, and there aren't a lot of > > rsync-enabled web proxies out there. > > You may like this RFE: > > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=391 > > gzip has an --rsyncable option that is missing from the python zlib > implementation. If python/zlib could be taught this, and createrepo > is able to use it, the metadata would be rsyncable (improves > transferspeed for repo maintainers/mirrors). My repo-generation script now unzips the createrepo metadata, recompresses with --rsyncable and recreates the repomd.xml after createrepo's run. I synced the repository. I then added a single update package to my repository And then rsynced again (with a 12kB upstream limitation), and got: fedora/3/en/i386/dag/repodata/ fedora/3/en/i386/dag/repodata/filelists.xml.gz 961353 100% 306.10kB/s 0:00:03 (68, 16.8% of 208800) fedora/3/en/i386/dag/repodata/other.xml.gz 412335 100% 89.30kB/s 0:00:04 (69, 16.8% of 208800) fedora/3/en/i386/dag/repodata/primary.xml.gz 668753 100% 154.79kB/s 0:00:04 (70, 16.8% of 208800) fedora/3/en/i386/dag/repodata/repomd.xml 1128 100% 4.87kB/s 0:00:00 (71, 16.8% of 208800) and fedora/3/en/x86_64/dag/repodata/ fedora/3/en/x86_64/dag/repodata/filelists.xml.gz 1466742 100% 273.93kB/s 0:00:05 (86, 20.9% of 208800) fedora/3/en/x86_64/dag/repodata/other.xml.gz 674072 100% 79.47kB/s 0:00:08 (87, 20.9% of 208800) fedora/3/en/x86_64/dag/repodata/primary.xml.gz 1086239 100% 141.68kB/s 0:00:07 (88, 20.9% of 208800) fedora/3/en/x86_64/dag/repodata/repomd.xml 1128 100% 1.46kB/s 0:00:00 (89, 20.9% of 208800) Which is a between 6.6x and 25.6x speed improvement for something I have to update every single sync. (Normally these files are synced with a 12kB/sec rate limitation taking on average 1min per file, now only 6secs) Now imagine what this would do if Yum had a client-side rsync implementation. zsync may be something to look at. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From michael.favia at insitesinc.com Thu Feb 10 17:57:14 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 10 Feb 2005 11:57:14 -0600 Subject: Self-Introduction: Ignacio Vazquez-Abrams In-Reply-To: References: <1108014959.5351.22.camel@localhost.localdomain> Message-ID: <420BA07A.4090804@insitesinc.com> Rahul Sundaram wrote: >Hi > > > >>Goals: As maintainer of my own repository I've come across several >>packages both general-purpose and niche that I feel would be appropriate >>to be contained in a repository that more people would use. To that end >>I am willing to maintain most if not all of the packages that make it >>from my repository into Fedora Extras or even the Core. >> >> >> > >you can start by proposing individual packages to the fedora extras list > > What he meant to say was welcome, thank you for taking the time to introduce yourself. Anyone with the patience and wherewithal to deal with most of the problems that show themselves in #fedora has my deepest respect. ;). Fedora extras does have its own mailing list and you probably want to start down your path of inclusion in that direction as it will be the normal route towards inclusion in core in the following releases. Fedora-extras-list: http://www.redhat.com/mailman/listinfo/fedora-extras-list Good luck and welcome, Michael -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From notting at redhat.com Thu Feb 10 20:29:37 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Feb 2005 15:29:37 -0500 Subject: Raw Hide ypbind/initscripts issues In-Reply-To: <20050210092114.GA4319@redhat.com> References: <20050210092114.GA4319@redhat.com> Message-ID: <20050210202936.GD23982@nostromo.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > I'm not sure what package to file this bug against: > > in Raw Hide, the ypbind service is being started before the network is > brought up, and so fails to initialize. The chkconfig runlevels listed > in /etc/init.d/ypbind have not changed so maybe something else has? > > (this bug is new since FC3) chkconfig bug. *sigh*. Will get it fixed. Bill From josha at sgi.com Thu Feb 10 22:08:57 2005 From: josha at sgi.com (Josh Aas) Date: Thu, 10 Feb 2005 16:08:57 -0600 Subject: refactoring rc.sysinit Message-ID: <420BDB79.2060505@sgi.com> Hello, The following is a proposal for modularizing Red Hat's /etc/rc.d/rc.sysinit script. This proposal solves the problem of having to patch rc.sysinit and respin the RPM when modifying the rc.sysinit process (instead, simply add a script to a directory). It would be nice if rc.sysinit was broken into chunks and organized in separate files, similar to what was done with init.d. The following scheme should mesh fairly well with the way /etc/rc.d is already set up on Red Hat systems, and it also closely (but not exactly) follows conventions used in Debian and Gentoo systems, as well as others (e.g. symlinks in an rcS.d directory to init.d/* scripts). - Each chunk of rc.sysinit would be a file in a directory "/etc/rc.d/init.d", prefixed by "boot.". So, the "example" section of rc.sysinit would be "/etc/rc.d/init.d/boot.example" - a new directory, "/etc/rc.d/rcS.d", would contain symlinks to scripts in "/etc/rc.d/init.d". These symlinks would start with "S" and then a two digit number, then the script name, with the numbers ascending in the order that the scripts should be run. This is similar to what is done with rcX.d scripts, where "X" is any runlevel. - The rc.sysinit script itself would remain, and it would be the script that calls scripts in rc.sysinit.d in the appropriate order. This means that nothing else in the boot setup would need to change since running rc.sysinit until completion would still be all that needs to be done. That mechanism is already in place, obviously. Given way rc.sysinit is written now, a shift to this scheme is not exactly straightforward. I tried to write a patch for this during a limited period of time I had, but I wasn't able to finish as things got a little more complicated than I expected and having help from the beginning would be best. Perhaps there are better schemes? Also, having help from people who know more about the order of operations in rc.sysinit would be great. Comments would be appreciated. I would be interested in such a scheme for the reason at the top of this email, but there are probably more benefits (why did Debian, Gentoo, etc. do it? Ease of maintenance?). -- Josh Aas Linux System Software Silicon Graphics, Inc. (SGI) From notting at redhat.com Thu Feb 10 22:20:27 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Feb 2005 17:20:27 -0500 Subject: refactoring rc.sysinit In-Reply-To: <420BDB79.2060505@sgi.com> References: <420BDB79.2060505@sgi.com> Message-ID: <20050210222027.GA26361@nostromo.devel.redhat.com> Josh Aas (josha at sgi.com) said: > The following is a proposal for modularizing Red Hat's > /etc/rc.d/rc.sysinit script. This proposal solves the problem of having > to patch rc.sysinit and respin the RPM when modifying the rc.sysinit > process (instead, simply add a script to a directory). Thinking about it some more, I don't see *that* much need for modularizing rc.sysinit; that's orthogonal to a rcS.d. Most of what rc.sysinit does isn't really something to be made optional. > - Each chunk of rc.sysinit would be a file in a directory > "/etc/rc.d/init.d", prefixed by "boot.". So, the "example" section of > rc.sysinit would be "/etc/rc.d/init.d/boot.example" As stated before, I don't see the need for the 'boot' prefix. Bill From rodd at clarkson.id.au Thu Feb 10 23:08:50 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 11 Feb 2005 10:08:50 +1100 Subject: Major SELinux output and things not working with current rawhide In-Reply-To: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> References: <200502101251.j1ACpoD00714@porkchop.devel.redhat.com> Message-ID: <1108076930.3402.2.camel@trevally.redfishdemo.com> I was up-to-date with rawhide yesterday with the exception of evolution-data-server (for obvious reasons). From Lam at Lam.pl Fri Feb 11 01:28:42 2005 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 11 Feb 2005 02:28:42 +0100 Subject: refactoring rc.sysinit In-Reply-To: <20050210222027.GA26361@nostromo.devel.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> Message-ID: <1108085322.6187.17.camel@pensja.lam.pl> Dnia 10-02-2005, czw o godzinie 17:20 -0500, Bill Nottingham napisa?(a): > Thinking about it some more, I don't see *that* much need for modularizing > rc.sysinit; > As stated before, I don't see the need for the 'boot' prefix. Think about uptimed. It needs to create unique boot id upon every boot. Then it can be started and stopped many times using service uptimed stop/start, changing runlevels (upon bootup, too), playing with kill etc. The Red Hat way of doing this sort of things was always something like if [ -x /etc/rc.d/init.d/uptimed -a -f /etc/sysconfig/uptimed ] then /etc/rc.d/init.d/uptimed createbootid fi in rc.sysinit, which will do the job once per machine boot only if the package is installed and/or configured. This creates some very small overhead (checks for a significant number of files which are or aren't there and we know the state anyhow) and doesn't leave room for new third-party packages (like uptimed). Having rcS.d would change that. The "boot." prefix seems ugly. It would be better to just have scripts from rcS.d be run with "boot" instead of "start" as a parameter. This way one init.d script belonging to one package could be linked to rcS.d and rc5.d and distinguish how it was called by this parameter. And this is the kind of functionality I need for uptimed - "start" being called any number of times when the system is running, but certain operations run only once. Apologies for my English, I can only defend myself by saying it's really late in my TZ :) Lam From notting at redhat.com Fri Feb 11 03:21:05 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Feb 2005 22:21:05 -0500 Subject: refactoring rc.sysinit In-Reply-To: <1108085322.6187.17.camel@pensja.lam.pl> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> Message-ID: <20050211032105.GF29375@nostromo.devel.redhat.com> Leszek Matok (Lam at Lam.pl) said: > Dnia 10-02-2005, czw o godzinie 17:20 -0500, Bill Nottingham napisa?(a): > > Thinking about it some more, I don't see *that* much need for modularizing > > rc.sysinit; > > As stated before, I don't see the need for the 'boot' prefix. > Think about uptimed. It needs to create unique boot id upon every boot. > Then it can be started and stopped many times using service uptimed > stop/start, changing runlevels (upon bootup, too), playing with kill > etc. When I speak about modularization above, I mean I don't see reason for splitting much of the *current* rc.sysinit to separate scripts; what I'd suspect is that we'd have the current rc.sysinit do the normal stuff (drivers, fsck, remount r/w) and then run all the scripts in rcS.d. Bill From backes at rhrk.uni-kl.de Fri Feb 11 07:29:21 2005 From: backes at rhrk.uni-kl.de (Joachim Backes) Date: Fri, 11 Feb 2005 08:29:21 +0100 Subject: FC3: Usage of IDE-USB-Adapters on ASUS K8V SE Deluxe with an 80GB IDE Disk Message-ID: <1108106961.5392.7.camel@sunny.rhrk.uni-kl.de> Hi, I have an ASUS K8V SE Deluxe MB, and I attached an 80GB Samsung IDE Disk via an IDE-USB-Adapator at the front usb connector. Problem: Partitioning the DISK by cfdisk is OK (1 primary, spanning over the whole disk). But formatting with etx2/ext3 or xfs hangs up, after about one 3rd of the disk is formatted (mkfs.ext2/3/xfs). mkfs.vfat is OK. Kernel: 2.6.10 (Vanilla). Any help is appreciated. -- Regards Joachim Backes Joachim Backes University of Kaiserslautern,Computer Center, High Performance Computing, D-67653 Kaiserslautern, PO Box 3049, Germany -------------------------------------------------- Phone: +49-631-205-2438, FAX: +49-631-205-3056 http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html From dragoran at feuerpokemon.de Fri Feb 11 08:09:18 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 11 Feb 2005 09:09:18 +0100 Subject: FC3: Usage of IDE-USB-Adapters on ASUS K8V SE Deluxe with an 80GB IDE Disk In-Reply-To: <1108106961.5392.7.camel@sunny.rhrk.uni-kl.de> References: <1108106961.5392.7.camel@sunny.rhrk.uni-kl.de> Message-ID: <420C682E.5050701@feuerpokemon.de> Joachim Backes schrieb: >Hi, > >I have an ASUS K8V SE Deluxe MB, and I attached an 80GB Samsung IDE Disk >via an IDE-USB-Adapator at the front usb connector. > >Problem: Partitioning the DISK by cfdisk is OK (1 primary, spanning over >the whole disk). But formatting with etx2/ext3 or xfs hangs up, after >about one 3rd of the disk is formatted (mkfs.ext2/3/xfs). > >mkfs.vfat is OK. > >Kernel: 2.6.10 (Vanilla). > >Any help is appreciated. > > > wrong list .... From nphilipp at redhat.com Fri Feb 11 08:51:31 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Feb 2005 09:51:31 +0100 Subject: refactoring rc.sysinit In-Reply-To: <20050211032105.GF29375@nostromo.devel.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> Message-ID: <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> On Thu, 2005-02-10 at 22:21 -0500, Bill Nottingham wrote: > Leszek Matok (Lam at Lam.pl) said: > > Dnia 10-02-2005, czw o godzinie 17:20 -0500, Bill Nottingham napisa?(a): > > > Thinking about it some more, I don't see *that* much need for modularizing > > > rc.sysinit; > > > As stated before, I don't see the need for the 'boot' prefix. > > Think about uptimed. It needs to create unique boot id upon every boot. > > Then it can be started and stopped many times using service uptimed > > stop/start, changing runlevels (upon bootup, too), playing with kill > > etc. > > When I speak about modularization above, I mean I don't see reason > for splitting much of the *current* rc.sysinit to separate scripts; > what I'd suspect is that we'd have the current rc.sysinit do > the normal stuff (drivers, fsck, remount r/w) and then run all > the scripts in rcS.d. In the past, I found myself in some situations where I would have loved to do things before or after a certain stage in rc.sysinit. How things were, I had to change the file itself which either made me retrofit these changes to a new rc.sysinit or lead to surprises when updating initscripts. Granted, given a completely standard installation splitting up rc.sysinit doesn't gain anything but as soon as you want to extend things beyond the normal state of affairs, having it the proposed way would make it very easy. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From buildsys at redhat.com Fri Feb 11 12:41:32 2005 From: buildsys at redhat.com (Build System) Date: Fri, 11 Feb 2005 07:41:32 -0500 Subject: rawhide report: 20050211 changes Message-ID: <200502111241.j1BCfW02007042@porkchop.devel.redhat.com> Updated Packages: From dhollis at davehollis.com Fri Feb 11 12:51:29 2005 From: dhollis at davehollis.com (David Hollis) Date: Fri, 11 Feb 2005 07:51:29 -0500 Subject: FC3: Usage of IDE-USB-Adapters on ASUS K8V SE Deluxe with an 80GB IDE Disk In-Reply-To: <1108106961.5392.7.camel@sunny.rhrk.uni-kl.de> References: <1108106961.5392.7.camel@sunny.rhrk.uni-kl.de> Message-ID: <1108126289.4861.13.camel@dhollis-lnx.centricconsulting.com> On Fri, 2005-02-11 at 08:29 +0100, Joachim Backes wrote: > Hi, > > I have an ASUS K8V SE Deluxe MB, and I attached an 80GB Samsung IDE Disk > via an IDE-USB-Adapator at the front usb connector. > > Problem: Partitioning the DISK by cfdisk is OK (1 primary, spanning over > the whole disk). But formatting with etx2/ext3 or xfs hangs up, after > about one 3rd of the disk is formatted (mkfs.ext2/3/xfs). Wrong list. Try linux-usb-devel at lists.sourceforge.net -- David Hollis -------------- next part -------------- A 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 11 14:22:31 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 11 Feb 2005 12:22:31 -0200 Subject: rawhide report: 20050211 changes In-Reply-To: <200502111241.j1BCfW02007042@porkchop.devel.redhat.com> References: <200502111241.j1BCfW02007042@porkchop.devel.redhat.com> Message-ID: On Feb 11, 2005, Build System wrote: [nothing] > Updated Packages: [nothing] Boooring.... :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From ellson at research.att.com Fri Feb 11 14:35:56 2005 From: ellson at research.att.com (John Ellson) Date: Fri, 11 Feb 2005 09:35:56 -0500 Subject: rawhide report: 20050211 changes In-Reply-To: References: <200502111241.j1BCfW02007042@porkchop.devel.redhat.com> Message-ID: <420CC2CC.9070507@research.att.com> Alexandre Oliva wrote: >On Feb 11, 2005, Build System wrote: > >[nothing] > > >>Updated Packages: >> >> >[nothing] > >Boooring.... :-) > > > [broken report generator] Boooring... ;-) From kewley at gps.caltech.edu Fri Feb 11 15:28:21 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Fri, 11 Feb 2005 07:28:21 -0800 Subject: refactoring rc.sysinit In-Reply-To: <20050211032105.GF29375@nostromo.devel.redhat.com> References: <420BDB79.2060505@sgi.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> Message-ID: <200502110728.21579.kewley@gps.caltech.edu> Bill Nottingham wrote on Thursday 10 February 2005 19:21: > When I speak about modularization above, I mean I don't see reason > for splitting much of the *current* rc.sysinit to separate scripts; > what I'd suspect is that we'd have the current rc.sysinit do > the normal stuff (drivers, fsck, remount r/w) and then run all > the scripts in rcS.d. Here's an example in FC2 where I could have used modularization of "all the normal stuff", in order to implement EVMS. Here EVMS is not managing the boot drive, so it's not in the initrd. But it should be initialized in rc.sysinit so that its volumes can be mounted simply by having them in /etc/fstab like so: /dev/evms/raid1 /export/raid1 xfs defaults,quota,grpquota 0 2 David --- rc.sysinit-dist-2005.01.26 2005-01-11 09:38:44.000000000 -0800 +++ rc.sysinit 2005-01-26 17:37:51.000000000 -0800 @@ -375,14 +375,23 @@ [ "$state" != "rw" ] && \ action $"Remounting root filesystem in read-write mode: " mount -n -o remount,rw / -# LVM2 initialization -if [ -x /sbin/lvm.static ]; then +# Device-Mapper initialization +if [ -x /sbin/lvm.static -o -x /sbin/evms_activate ]; then if ! LC_ALL=C fgrep -q "device-mapper" /proc/devices 2>/dev/null ; then modprobe dm-mod >/dev/null 2>&1 fi /bin/rm -f /dev/mapper/control echo "mkdmnod" | /sbin/nash --quiet >/dev/null 2>&1 [ -n "$SELINUX" ] && restorecon /dev/mapper/control +fi + +# EVMS initialization +if [ -s /sbin/evms_activate ]; then + action $"Setting up Enterprise Volume Management System:" /sbin/evms_activate +fi + +# LVM2 initialization +if [ -x /sbin/lvm.static ]; then if [ -c /dev/mapper/control -a -x /sbin/lvm.static ]; then if /sbin/lvm.static vgscan > /dev/null 2>&1 ; then action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y && /sbin/lvm vgmknodes From nick.thorley at btinternet.com Fri Feb 11 15:30:52 2005 From: nick.thorley at btinternet.com (Nick Thorley) Date: Fri, 11 Feb 2005 15:30:52 +0000 Subject: VPN Server features Message-ID: <420CCFAC.1080102@btinternet.com> Could I ask for or get everyones opinion that VPN features are required in core 4. I think it is the one major function that is missing from the software is a good vpn server that can be used as a gateway into remote networks and although connections from linux clients would be best - it would be possible to connect to it from windows. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 11 15:41:54 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 Feb 2005 16:41:54 +0100 Subject: VPN Server features In-Reply-To: <420CCFAC.1080102@btinternet.com> References: <420CCFAC.1080102@btinternet.com> Message-ID: <20050211164154.5fb1b667@python2> Nick Thorley wrote : > Could I ask for or get everyones opinion that VPN features are required > in core 4. I think it is the one major function that is missing from > the software is a good vpn server that can be used as a gateway into > remote networks and although connections from linux clients would be > best - it would be possible to connect to it from windows. On a related note... I just noticed that openvpn isn't included in Extras (yet?). I've found it to be the most simple and reliable VPN software to interconnect "static" networks after having spent years working with CIPE, then having messed around with IPSec. I'll look around to see if anyone has already started working on it or not, and if there aren't any obvious crypto or similar issues that prevent it from being shipped, then ask on fedora-extras-list. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.14 0.11 0.16 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 11 15:46:35 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 Feb 2005 16:46:35 +0100 Subject: VPN Server features In-Reply-To: <20050211164154.5fb1b667@python2> References: <420CCFAC.1080102@btinternet.com> <20050211164154.5fb1b667@python2> Message-ID: <20050211164635.3b3526fb@python2> Matthias Saou wrote : > Nick Thorley wrote : > > > Could I ask for or get everyones opinion that VPN features are required > > in core 4. I think it is the one major function that is missing from > > the software is a good vpn server that can be used as a gateway into > > remote networks and although connections from linux clients would be > > best - it would be possible to connect to it from windows. > > On a related note... I just noticed that openvpn isn't included in Extras > (yet?). I've found it to be the most simple and reliable VPN software to > interconnect "static" networks after having spent years working with CIPE, > then having messed around with IPSec. > > I'll look around to see if anyone has already started working on it or not, > and if there aren't any obvious crypto or similar issues that prevent it > from being shipped, then ask on fedora-extras-list. There is a "stalled" discussion here : https://bugzilla.fedora.us/show_bug.cgi?id=1531 Please, anyone interested, add follow-ups and help us move the package to Fedora Extras! ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3 Load : 0.30 0.18 0.17 From rdieter at math.unl.edu Fri Feb 11 15:49:05 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 11 Feb 2005 09:49:05 -0600 Subject: VPN Server features In-Reply-To: <20050211164154.5fb1b667@python2> References: <420CCFAC.1080102@btinternet.com> <20050211164154.5fb1b667@python2> Message-ID: <420CD3F1.9060607@math.unl.edu> Matthias Saou wrote: > On a related note... I just noticed that openvpn isn't included in Extras > (yet?). Pending reviews: http://bugzilla.fedora.us/show_bug.cgi?id=1531 -- Rex From jspaleta at gmail.com Fri Feb 11 18:06:59 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Feb 2005 13:06:59 -0500 Subject: udev-050-3 and make_extra_nodes function Message-ID: <604aa7910502111006231b5296@mail.gmail.com> Referencing https://bugzilla.redhat.com/beta/show_bug.cgi?id=147814 Looking at the make_extras_nodes () function in /sbin/start_udev logic to read /etc/sysconfig/makedev.d/*.nodes has been introduced and the cp -a /etc/udev/devices/* /dev/ >/dev/null 2>&1 logic has been removed. Not sure what those .nodes files are suppose to look like. Anyone care to share a simple example for say... the nvidia devices. Unless I'm missing something the faq instructions ( http://fedora.redhat.com/docs/udev/ ) cp -a /dev/nvidia* /etc/udev/devices chown root.root /etc/udev/devices/nvidia* are no longer going to work with the new start_udev logic. -jef From buildsys at redhat.com Fri Feb 11 18:09:15 2005 From: buildsys at redhat.com (Build System) Date: Fri, 11 Feb 2005 13:09:15 -0500 Subject: rawhide report: 20050211 changes Message-ID: <200502111809.j1BI9FOI019074@porkchop.devel.redhat.com> Removed package openssl096b Removed package THE Removed package Regina Updated Packages: VFlib2-2.25.6-26 ---------------- * Thu Feb 10 2005 Akira TAGOH - 2.25.6-26 - rebuilt alsa-lib-1.0.8-2.devel ---------------------- * Fri Feb 11 2005 Martin Stransky 1.0.8-2.devel - add alpha patch (#147388, thx to Sergey Tikhonov) - fix alsa-mixer on ICH6 system (#146607) authconfig-4.6.9-1 ------------------ * Thu Feb 10 2005 Tomas Mraz - 4.6.9-1 - improved the code that writes tls_cacertdir to ldap.conf * Tue Jan 25 2005 Tomas Mraz - renamed functions in authconfigmodule to be more clear - implemented cacertdir for LDAP with TLS * Mon Jan 24 2005 Tomas Mraz - fixed a bug in authinfo_differs when called from python binutils-2.15.94.0.2-1 ---------------------- * Thu Feb 10 2005 Jakub Jelinek 2.15.94.0.2-1 - update to 2.15.94.0.2 - fix .note.GNU-stack/PT_GNU_STACK computation in linker on ppc64 (#147296) - fix stripping of binaries/libraries that have empty sections right before .dynamic section (with the same starting address; #144038) - handle AS_NEEDED (...) in linker script INPUT/GROUP cdicconf-0.2-10 --------------- * Thu Feb 10 2005 Akira TAGOH - 0.2-10 - rebuilt chkconfig-1.3.16-1 ------------------ * Thu Feb 10 2005 Bill Nottingham 1.3.16-1 - prefer chkconfig: start/stop priorities in LSB mode unless Required-Start/Stop are used ckermit-8.0.209-11 ------------------ * Tue Feb 08 2005 Peter Vrabec - rebuilt * Tue Nov 02 2004 Peter Vrabec - fix ssh connection (#128349) crash-3.10-9 ------------ * Thu Feb 10 2005 Dave Anderson 3.10-9 - Updated source package to crash-3.10.tar.gz, containing IBM's final ppc64 processor support for RHEL4 - Fixes potential "bt -a" hang on dumpfile where netdump IPI interrupted an x86 process while executing the instructions just after it had entered the kernel for a syscall, but before calling the handler. BZ #139437 - Update to handle backtraces in dumpfiles generated on IA64 with the INIT switch (functionality intro'd in RHEL3-U5 kernel). BZ #139429 - Fix for handling ia64 and x86_64 machines booted with maxcpus=1 on an SMP kernel. BZ #139435 - Update to handle backtraces in dumpfiles generated on x86_64 from the NMI exception stack (functionality intro'd in RHEL3-U5 kernel). - "kmem -[sS]" beefed up to more accurately verify slab cache chains and report errors found. - Fix for ia64 INIT switch-generated backtrace handling when init_handler_platform() is inlined into ia64_init_handler(); properly handles both RHEL3 and RHEL4 kernel patches. BZ #138350 - Update to enhance ia64 gdb disassembly output so as to symbolically display call targets from kernel module text without requiring module debuginfo data. cups-1:1.1.23-9 --------------- * Thu Feb 10 2005 Tim Waugh 1.1.23-9 - Back to old DBUS API since new DBUS isn't built yet. * Mon Feb 07 2005 Tim Waugh - Use upstream patch for STR #1068. - Apply patch to fix remainder of CAN-2004-0888 (bug #135378). * Wed Feb 02 2005 Tim Waugh - Applied patch to prevent occasional cupsd crash on reload (bug #146850). cyrus-imapd-2.2.10-11.1.fc4 --------------------------- * Thu Feb 10 2005 John Dennis - 2.2.10-11.1.fc4 - bring up to date with Simon Matter's 2.2.10-11 rpm * Sat Feb 05 2005 Simon Matter - updated autosievefolder patch * Tue Feb 01 2005 Simon Matter - remove special ownership and permissions from deliver - enable deliver-wrapper per default - enable OutlookExpress seenstate patch per default dhcp-8:3.0.2rc3-3 ----------------- * Thu Feb 10 2005 Jason Vas Dias 8.3.0.4rc3-3 - fix bug 147375: dhcpd heap corruption on 32-bit 'subnet' masks - fix bug 147502: dhclient should honor GATEWAYDEV and GATEWAY settings - fix bug 146600: dhclient's timeout mode ping should use -I - fix bug 146524: dhcpd.init should discard dhcpd's initial output message - fix bug 147739: dhcpd.init configtest should honor -cf in DHCPDARGS epic-4:1.0.1-19 --------------- * Tue Feb 08 2005 Peter Vrabec - rebuilt eruby-1.0.5-4 ------------- * Thu Feb 10 2005 Akira TAGOH - 1.0.5-4 - rebuilt gcc-3.4.3-18 ------------ * Thu Feb 10 2005 Jakub Jelinek 3.4.3-18 - update from gcc-3_4-branch - PRs c++/18370, c++/19366, c++/19499, c++/19733, libstdc++/19642, middle-end/19775, target/15384, target/16201, target/17771, target/19293, target/19329, target/19393, target/19803 - fix c++filt/__cxa_demangle segfault on invalidly mangled names generated by G++ 3.4 (#145781, PR c++/16240) - make sure libgcj.so is not PT_GNU_STACK RWE - disallow dlopening libgnat-3*.so, as it must be PT_GNU_STACK RWE due to its extensive use of trampolines - fix PRs c++/18838 and c++/19367 (Mark Mitchell, backported by Alexandro Oliva) - fix ICE in fold_convert (Andrew Pinski, #146385, PR c++/19666) * Tue Jan 25 2005 Jakub Jelinek 3.4.3-17 - update from gcc-3_4-branch - PRs c++/19258, c++/19375, libstdc++/19510, other/16403, rtl-optimization/19296, target/16304, target/19548 - fix PR rtl-optimization/19579 - remove Java *.a libraries, issue error for gcj -static (#145829) * Sat Jan 22 2005 Jakub Jelinek 3.4.3-16 - fix PRs middle-end/19551 gdm-1:2.6.0.7-2 --------------- * Thu Feb 10 2005 Ray Strode 1:2.6.0.7-2 - Turn off "switchdesk" mode by default which accidentally got turned on by default in 2.6.0.5-4 gftp-1:2.0.18-1 --------------- * Thu Feb 10 2005 Warren Togami 2.0.18-1 - 2.0.18 gnome-panel-2.9.91-2 -------------------- * Thu Feb 10 2005 Mark McLoughlin - 2.9.91-2 - Require gnome-desktop 2.9.91 grub-0.95-8 ----------- * Tue Feb 08 2005 Peter Jones 0.95-8 - Mark the simulation stack executable - Eliminate the use of inline functions in stage2/builtins.c kakasi-2.3.4-18 --------------- * Thu Feb 10 2005 Akira TAGOH - 2.3.4-18 - rebuilt kcc-2.3-23 ---------- * Thu Feb 10 2005 Akira TAGOH - 2.3-23 - rebuilt kdeaddons-3.3.2-0.2 ------------------- * Tue Feb 08 2005 Than Ngo 3.3.2-0.2 - disable vimpart kdebase-6:3.3.2-0.4 ------------------- * Thu Feb 10 2005 Than Ngo 6:3.3.2-0.4 - add cleanup patch file from Steve kdegraphics-7:3.3.2-0.3 ----------------------- * Thu Feb 10 2005 Than Ngo 7:3.3.2-0.3 - Applied patch to fix CAN-2005-0064 - Applied Steve cleanup patch file kdelibs-6:3.3.2-0.5 ------------------- * Thu Feb 10 2005 Than Ngo 6:3.3.2-0.5 - use mkstemp instead of mktemp - fix knotify crash after applying sound system change - add steve cleanup patch kernel-2.6.10-1.1137_FC4 ------------------------ * Thu Feb 10 2005 Dave Jones - 2.6.11-rc3-bk7 libbonoboui-2.8.1-1 ------------------- * Wed Feb 09 2005 Matthias Clasen - 2.8.1-1 - Update to 2.8.1 libselinux-1.21.9-2 ------------------- * Thu Feb 10 2005 Dan Walsh 1.21.9-2 - Process file_context.homedir * Thu Feb 10 2005 Dan Walsh 1.21.9-1 - Update from NSA * Changed relabel Makefile target to use restorecon. lv-4.51-4 --------- * Thu Feb 10 2005 Akira TAGOH - 4.51-4 - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt * Tue Mar 02 2004 Elliot Lee - rebuilt mod_python-3.1.4-1 ------------------ * Thu Feb 10 2005 Joe Orton 3.1.4-1 - update to 3.1.4 mtr-2:0.69-2 ------------ * Thu Feb 10 2005 Karsten Hopp 2:0.69-2 - build with --enable-gtk2 (John Thacker) ncompress-4.2.4-41 ------------------ * Tue Feb 08 2005 Peter Vrabec - rebuilt neon-0.24.7-5 ------------- * Thu Feb 10 2005 Joe Orton 0.24.7-5 - don't define min() in ne_utils.h (Caolan McNamara, #147228) netdump-0.7.5-3 --------------- * Thu Feb 10 2005 Dave Anderson 0.7.5-3 - Updated source package to netdump-0.7.5.tar.gz: Allows multiple "service netdump start" to handle magic numbers properly. BZ #142752 * Tue Nov 30 2004 Dave Anderson 0.7.4-1 - Fix for unintentional failure of netconsole modprobe when NETLOGADDR=NONE. BZ #141373. * Wed Nov 24 2004 Dave Anderson 0.7.3-1 - Fix for print_address_info IFS manipulation that caused the first arp line's data to be assigned to first variable. BZ #139781 - Convert netdump-server.8 man page to UTF-8 format. BZ #140707 nkf-2.04-4 ---------- * Thu Feb 10 2005 Akira TAGOH - 2.04-4 - rebuilt policycoreutils-1.21.15-5 ------------------------- * Thu Feb 10 2005 Dan Walsh 1.21.15-5 - Trap failure on write - Rewrite genhomedircon to generate file_context.homedirs - several passes * Thu Feb 10 2005 Dan Walsh 1.21.15-1 - Update from NSA * Changed relabel Makefile target to use restorecon. pygtk2-2.5.3-3 -------------- * Thu Feb 10 2005 Mark McLoughlin - 2.5.3-3 - Avoid assertion errors in signal handling patch * Wed Feb 09 2005 Mark McLoughlin - 2.5.3-2 - Backport fix for gnome #154779 - python signal handlers weren't getting executed while gobject.MainLoop was running * Tue Jan 25 2005 Jeremy Katz - 2.5.3-1 - 2.5.3 qt-1:3.3.4-3 ------------ * Thu Feb 10 2005 Than Ngo 1:3.3.4-3 - fix rpm file conflict readahead-1:1.0-1.6 ------------------- rhdb-utils-4.0-1 ---------------- * Thu Feb 10 2005 Tom Lane 4.0-1 - Update pg_filedump to version 4.0, to support PostgreSQL 8.0. - Keep pg_crc.c on hand as a plain source file instead of a patch. Easier to compare to main PG sources that way. rpm-4.4.1-0.20 -------------- * Thu Feb 10 2005 Jeff Johnson 4.4.1-0.20 - perform callbacks as always (#147537). rpmdb-fedora-1:4-0.20050211 --------------------------- rsync-2.6.3-2 ------------- * Thu Feb 10 2005 Jay Fenlason 2.6.3-2 - Added my -xattr patch, which is based on the -acl patch. selinux-doc-1.17.6-1 -------------------- * Thu Feb 10 2005 Dan Walsh 1.17.6-1 - Upgrade to match NSA * Further revs to socket and network hook sections of module report. * Further revs to the policy report. * Minor revs to the module report. * Updated policy report. * Updated IP network hook section of module report. * Updated miscellaneous hook section of module report. * Completed first pass update of module report. * Updated inode hook section of the module report. * Updated file hook section of the module report. * Updated ipc hook section of the module report. * Updated socket hook section of the module report. * Removed obsolete sections of the module report. * Updated CREDITS. * Updated README.CONDITIONAL. * Updated README.MLS. * Updated README. * Updated task hooks section of the module report. * Updated bprm hooks section of the module report. * Updated superblock hooks section of the module report. * Updated CREDITS. * Minor rev to the stacking section of the module report. selinux-policy-targeted-1.21.12-1 --------------------------------- * Thu Feb 10 2005 Dan Walsh 1.21.12-1 - Use new gethomedircon system-config-securitylevel-1.5.0-1 ----------------------------------- * Thu Feb 10 2005 Chris Lumens 1.5.0-1 - Added a patch to easily configure connection sharing via trusted interfaces (#83704). udev-050-3 ---------- * Thu Feb 10 2005 Harald Hoyer - 050-3 - fixed forgotten " in udev.rules * Tue Jan 11 2005 Harald Hoyer - 050-2 - removed /dev/microcode, /dev/cpu/microcode is now the real node - cleaned up start_udev uucp-1.07-6 ----------- * Tue Feb 08 2005 Peter Vrabec - rebuilt * Mon Oct 25 2004 Peter Vrabec - uucppublic change attr from 755 to 775 (#135335) * Mon Oct 25 2004 Peter Vrabec - add dependencie tetex w3m-el-1.4.3-3 -------------- * Thu Feb 10 2005 Akira TAGOH - 1.4.3-3 - rebuilt xorg-x11-6.8.2-1 ---------------- * Thu Feb 10 2005 Mike A. Harris 6.8.2-1 - Update main tarball to X.Org X11 6.8.2 * Tue Feb 08 2005 Mike A. Harris 6.8.1.904-2 - [SECURITY] Added with_fortify_source option macro to spec file, to allow xorg-x11 to take partial advantage of the new gcc FORTIFY_SOURCE feature available in newer gcc releases. This option is automatically enabled in FC4 builds by rpm by default via RPM_OPT_FLAGS, however while gcc in FC3 and RHEL4 has this support also, it must be manually enabled in the spec file for it to get used. "-D_FORTIFY_SOURCE=2" gets passed to gcc when this option is enabled. xpdf-1:3.00-17 -------------- * Thu Feb 10 2005 Than Ngo 1:3.00-17 - More fixing of CAN-2004-0888 patch (bug #135393) From nphilipp at redhat.com Fri Feb 11 18:46:00 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Feb 2005 19:46:00 +0100 Subject: rawhide report: 20050211 changes In-Reply-To: <200502111809.j1BI9FOI019074@porkchop.devel.redhat.com> References: <200502111809.j1BI9FOI019074@porkchop.devel.redhat.com> Message-ID: <1108147560.455.137.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-02-11 at 13:09 -0500, Build System wrote: > uucp-1.07-6 > ----------- > * Tue Feb 08 2005 Peter Vrabec > - rebuilt > > * Mon Oct 25 2004 Peter Vrabec > - uucppublic change attr from 755 to 775 (#135335) > > * Mon Oct 25 2004 Peter Vrabec > - add dependencie tetex Huh, why that? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From josha at sgi.com Fri Feb 11 20:08:44 2005 From: josha at sgi.com (Josh Aas) Date: Fri, 11 Feb 2005 14:08:44 -0600 Subject: refactoring rc.sysinit In-Reply-To: <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> Message-ID: <420D10CC.4070402@sgi.com> Nils Philippsen wrote: > Granted, given a completely standard installation splitting > >up rc.sysinit doesn't gain anything but as soon as you want to extend >things beyond the normal state of affairs, having it the proposed way >would make it very easy. > >Nils > > Well said - I should have said it that way in my proposal. -- Josh Aas Linux System Software Silicon Graphics, Inc. (SGI) From notting at redhat.com Fri Feb 11 20:22:04 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 Feb 2005 15:22:04 -0500 Subject: refactoring rc.sysinit In-Reply-To: <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20050211202204.GB18471@nostromo.devel.redhat.com> Nils Philippsen (nphilipp at redhat.com) said: > In the past, I found myself in some situations where I would have loved > to do things before or after a certain stage in rc.sysinit. How things > were, I had to change the file itself which either made me retrofit > these changes to a new rc.sysinit or lead to surprises when updating > initscripts. Got example usage cases? I'm just skeptical of making things more complicated and slower if the only usage cases are theoretical. Bill From lkml at mac.com Fri Feb 11 21:31:47 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Fri, 11 Feb 2005 22:31:47 +0100 Subject: udev complains about makedev.d/*.nodes Message-ID: <4efa4d2a5d5583f898ff09980abb6dcc@mac.com> udev-050-3 issues a warning if no /etc/sysconfig/makedev.d/*.nodes file matches. This will shut udev up. -------------- next part -------------- A non-text attachment was scrubbed... Name: warning.patch Type: application/octet-stream Size: 454 bytes Desc: not available URL: From zaitcev at redhat.com Fri Feb 11 22:07:38 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 11 Feb 2005 14:07:38 -0800 Subject: Source versus Patch (in pcmcia-cs) Message-ID: <20050211140738.33cd0e37@localhost.localdomain> Does anyone know why the startup script in pcmcia-cs is carried in the SRPM as a Source, instead of Patch? Source3: rc.pcmcia Do we have any guidelines about what should go into Source, and what should go into into Patch? Thanks, -- Pete From dcbw at redhat.com Fri Feb 11 22:13:28 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 11 Feb 2005 17:13:28 -0500 Subject: Source versus Patch (in pcmcia-cs) In-Reply-To: <20050211140738.33cd0e37@localhost.localdomain> References: <20050211140738.33cd0e37@localhost.localdomain> Message-ID: <1108160008.26324.7.camel@dcbw.boston.redhat.com> On Fri, 2005-02-11 at 14:07 -0800, Pete Zaitcev wrote: > Does anyone know why the startup script in pcmcia-cs is carried in the SRPM > as a Source, instead of Patch? > > Source3: rc.pcmcia > > Do we have any guidelines about what should go into Source, and what should > go into into Patch? Well, rc.pcmcia isn't a patch, its the actual script. So in that sense, it shouldn't be in a Patch: line in the specfile because it never gets applied anywhere, it just gets copied to where it needs to go during % install. And it would be pretty silly to generate a patch with "diff /dev/null rc.pcmcia" so that it _would_ be a Patch:. Dan From notting at redhat.com Fri Feb 11 22:27:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 Feb 2005 17:27:47 -0500 Subject: Source versus Patch (in pcmcia-cs) In-Reply-To: <20050211140738.33cd0e37@localhost.localdomain> References: <20050211140738.33cd0e37@localhost.localdomain> Message-ID: <20050211222747.GA20668@nostromo.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > Does anyone know why the startup script in pcmcia-cs is carried in the SRPM > as a Source, instead of Patch? > > Source3: rc.pcmcia > > Do we have any guidelines about what should go into Source, and what should > go into into Patch? Generally, it's included as a Source: when either a) upstream doesn't ship one or b) we'd have to mangle the upstream one enough that it's simpler to keep our own copy. Bill From rms at 1407.org Fri Feb 11 22:38:30 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 11 Feb 2005 22:38:30 +0000 Subject: bluetooth support broken? Message-ID: <1108161510.3780.9.camel@roque> Hi, I used to swap files and vcards with my cell phone through bluetooth. My usb bt dongle is a Sitecom CN-502, which AFAIK works. When I plug-it, I see in /var/log/messages Feb 11 22:25:19 roque kernel: Bluetooth: Core ver 2.7 Feb 11 22:25:19 roque kernel: NET: Registered protocol family 31 Feb 11 22:25:19 roque kernel: Bluetooth: HCI device and connection manager initialized Feb 11 22:25:19 roque kernel: Bluetooth: HCI socket layer initialized Feb 11 22:25:19 roque kernel: Bluetooth: HCI USB driver ver 2.8 Feb 11 22:25:19 roque kernel: usbcore: registered new driver hci_usb Feb 11 22:25:19 roque kernel: usb 3-2: reset full speed USB device using uhci_hcd and address 3 Feb 11 22:25:19 roque kernel: usb 3-2: device firmware changed Feb 11 22:25:19 roque kernel: usb 3-2: USB disconnect, address 3 Then I start the bluetooth service: # service bluetooth start and see: Feb 11 22:28:09 roque hcid[3963]: Bluetooth HCI daemon Feb 11 22:28:10 roque kernel: Bluetooth: L2CAP ver 2.7 Feb 11 22:28:10 roque kernel: Bluetooth: L2CAP socket layer initialized Feb 11 22:28:10 roque hcid[3963]: HCI dev 0 up Feb 11 22:28:10 roque hcid[3963]: Starting security manager 0 Feb 11 22:28:10 roque sdpd[3966]: Bluetooth SDP daemon Feb 11 22:28:10 roque kernel: Bluetooth: RFCOMM ver 1.5 Feb 11 22:28:10 roque kernel: Bluetooth: RFCOMM socket layer initialized Feb 11 22:28:10 roque kernel: Bluetooth: RFCOMM TTY layer initialized I try sending something to my bluetooth phone with: gnome-obex-send -d XX:YY.... a_friend.vcf Browsing XX:YY.... ... Service Name: OBEX Object Push Service RecHandle: 0x10004 Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 9 "OBEX" (0x0008) Service Class ID List: "OBEX Object Push" (0x1105) ** Message: device XX:YY.... (OBEX Object Push) port 9 And a dialog shows up saying: <> In /var/log/messages... Feb 11 22:28:43 roque hcid[3963]: link_key_request (sba=AA:BB...., dba=XX:YY....) Sending _from_ the cell phone to the laptop works. Feb 11 22:36:27 roque hcid[3963]: link_key_request (sba=AA:BB...., dba=XX:YY....) But shouldn't 's' and 'd' change order now? If I define an rfcomm I can dial by typing atd someNumber 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 fedora-devel at tlarson.com Fri Feb 11 22:49:11 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Fri, 11 Feb 2005 15:49:11 -0700 Subject: refactoring rc.sysinit In-Reply-To: <20050211202204.GB18471@nostromo.devel.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> <20050211202204.GB18471@nostromo.devel.redhat.com> Message-ID: <420D3667.1060201@tlarson.com> Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: > >>In the past, I found myself in some situations where I would have loved >>to do things before or after a certain stage in rc.sysinit. How things >>were, I had to change the file itself which either made me retrofit >>these changes to a new rc.sysinit or lead to surprises when updating >>initscripts. > > > Got example usage cases? I'm just skeptical of making things more > complicated and slower if the only usage cases are theoretical. > > Bill > I know it would have come in handy when I was modifying an old FC box to run off a read-only drive (long before the Stateless Linux project). I had to change the way it mounted /, create and initialize some ram disk, and some other little goodies that, for one reason or another, couldn't be put off till later. rc.sysinit makes a number of assumptions about the way you want your system to boot which are true almost all the time. Every now and then, though, you have to configure a box to do something weird. On the one hand, on the occasions when you *do* have to modify the sysinit procedure, it would be much cleaner and easier if rc.sysinit took a more modular approach. On the other hand, those situations are so rare it's easy to not think about them. There is also something to be said about the fact that modular code tends to be cleaner code. rc.sysinit feels a bit like a run-on sentence. It would be easier to understand and modify if it were broken up a bit. Not sure if it's worth a design change to fix that, though. From rms at 1407.org Fri Feb 11 22:51:32 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 11 Feb 2005 22:51:32 +0000 Subject: bluetooth support broken? In-Reply-To: <1108161510.3780.9.camel@roque> References: <1108161510.3780.9.camel@roque> Message-ID: <1108162292.3780.12.camel@roque> I'm sorry, I forgot to include useful information :) I'm with the most recent Linux package (2.6.10-1.1137_FC4) and gnome-bluetooth (0.5.1-8). The cell phone is a Nokia 6600, and interoperability between this laptop and the cell phone worked previously (last used in rawhide after FC3 but I can't remember exacty when). 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 zaitcev at redhat.com Fri Feb 11 23:01:29 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 11 Feb 2005 15:01:29 -0800 Subject: Source versus Patch (in pcmcia-cs) In-Reply-To: <1108160008.26324.7.camel@dcbw.boston.redhat.com> References: <20050211140738.33cd0e37@localhost.localdomain> <1108160008.26324.7.camel@dcbw.boston.redhat.com> Message-ID: <20050211150129.72f0f8dc@localhost.localdomain> On Fri, 11 Feb 2005 17:13:28 -0500, Dan Williams wrote: > On Fri, 2005-02-11 at 14:07 -0800, Pete Zaitcev wrote: > > Does anyone know why the startup script in pcmcia-cs is carried in the SRPM > > as a Source, instead of Patch? > > > > Source3: rc.pcmcia > Well, rc.pcmcia isn't a patch, its the actual script. So in that sense, > it shouldn't be in a Patch: line in the specfile because it never gets > applied anywhere, it just gets copied to where it needs to go during % > install. And it would be pretty silly to generate a patch with > "diff /dev/null rc.pcmcia" so that it _would_ be a Patch:. It's a copy of a downrev upstream script which we delete before installing our own. We have to consider two points here: - The patch will include all these -"foo" +$"foo" for i18n - The script name is different: upstream uses rc.pcmcia and we use pcmcia. My concern is that by forking the script wholesale we will slide behind and lose some important modifications. I am going to poke David Hinds about accepting our modifications. Thanks, -- Pete From lkml at mac.com Fri Feb 11 23:16:39 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Sat, 12 Feb 2005 00:16:39 +0100 Subject: -fvisibility=hidden Message-ID: Hello, I've seen Mandrake has started compiling KDE with -fvisibility=hidden. They say this improve load times considerably. Has this flag other nasty consequences? Thanks. From pbrobinson at gmail.com Sat Feb 12 00:41:47 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 12 Feb 2005 08:41:47 +0800 Subject: VPN Server features In-Reply-To: <420CCFAC.1080102@btinternet.com> References: <420CCFAC.1080102@btinternet.com> Message-ID: <5256d0b05021116411e1caf6a@mail.gmail.com> > Could I ask for or get everyones opinion that VPN features are required > in core 4. I think it is the one major function that is missing from > the software is a good vpn server that can be used as a gateway into > remote networks and although connections from linux clients would be > best - it would be possible to connect to it from windows. Well there's support for IPSEC from the ipsec and openswan packages. I tried miserably to get it working the other day and couldn't. There seems to be a conflict when connecting between the two packages and I couldn't work out whether they were suppose to work together or you chose one or the other. There's a IPSEC tab in the network config gui which creates an ifcfg-Blah script and so on. Is there documentation any where? I couldn't even find a post to a list outlining it. It'd be nice to have a example for something like a RoadWarrior connecting in. I believe it should work with the standard W2K/XP IPSEC client. There's also a newer rc of the ipsec package on their site which is suppose to be quite stable and have lots of extra feature. Possible inclusion for the test release? Links here http://ipsec-tools.sourceforge.net/ and here http://www.openswan.org p From ndbecker2 at verizon.net Sat Feb 12 01:00:07 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Fri, 11 Feb 2005 20:00:07 -0500 Subject: VPN Server features References: <420CCFAC.1080102@btinternet.com> <20050211164154.5fb1b667@python2> <20050211164635.3b3526fb@python2> Message-ID: Matthias Saou wrote: > Matthias Saou wrote : > >> Nick Thorley wrote : >> >> > Could I ask for or get everyones opinion that VPN features are required > >> > in core 4. I think it is the one major function that is missing from >> > the software is a good vpn server that can be used as a gateway into >> > remote networks and although connections from linux clients would be >> > best - it would be possible to connect to it from windows. >> >> On a related note... I just noticed that openvpn isn't included in Extras >> (yet?). I've found it to be the most simple and reliable VPN software to >> interconnect "static" networks after having spent years working with > CIPE, >> then having messed around with IPSec. >> >> I'll look around to see if anyone has already started working on it or > not, >> and if there aren't any obvious crypto or similar issues that prevent it >> from being shipped, then ask on fedora-extras-list. > > There is a "stalled" discussion here : > > https://bugzilla.fedora.us/show_bug.cgi?id=1531 > > Please, anyone interested, add follow-ups and help us move the package to > Fedora Extras! ;-) > openvpn rules. Works fine on FC3. What's the hangup? From symbiont at berlios.de Sat Feb 12 02:21:07 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 12 Feb 2005 10:21:07 +0800 Subject: VPN Server features In-Reply-To: References: <420CCFAC.1080102@btinternet.com> <20050211164635.3b3526fb@python2> Message-ID: <200502121021.07660.symbiont@berlios.de> On Saturday 12 February 2005 09:00, Neal Becker wrote: > > Please, anyone interested, add follow-ups and help us move the > > package to Fedora Extras! ;-) > > openvpn rules. ?Works fine on FC3. ?What's the hangup? With a little bit of work, it also fulfills the "Works for Windows clients" requirement. Probably someone with this need also can put together an installer (msi or another) to do the dirty work. Hopefully 2.0 will be ready by FC4, because that'll be a huge leap in scalability and easier configuration for a larger number of clients. -- -jeff From dcbw at redhat.com Sat Feb 12 02:40:28 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 11 Feb 2005 21:40:28 -0500 (EST) Subject: -fvisibility=hidden In-Reply-To: References: Message-ID: On Sat, 12 Feb 2005, Felipe Alfaro Solana wrote: > I've seen Mandrake has started compiling KDE with -fvisibility=hidden. > They say this improve load times considerably. Has this flag other > nasty consequences? It shouldn't, as long as the code is fairly well behaved. We're starting to use this for OpenOffice.org as well, any large C++ app can greatly benefit from this option because the rather un-optimized dynamic linker doesn't have to load and resolve as many symbols at run-time. You should get link-time errors if symbols that aren't explicitly marked visible are needed by some other part of the program. Dan From dag at wieers.com Sat Feb 12 03:25:08 2005 From: dag at wieers.com (Dag Wieers) Date: Sat, 12 Feb 2005 04:25:08 +0100 (CET) Subject: VPN Server features In-Reply-To: <200502121021.07660.symbiont@berlios.de> References: <420CCFAC.1080102@btinternet.com> <20050211164635.3b3526fb@python2> <200502121021.07660.symbiont@berlios.de> Message-ID: On Sat, 12 Feb 2005, Jeff Pitman wrote: > On Saturday 12 February 2005 09:00, Neal Becker wrote: > > > Please, anyone interested, add follow-ups and help us move the > > > package to Fedora Extras! ;-) > > > > openvpn rules. ?Works fine on FC3. ?What's the hangup? > > With a little bit of work, it also fulfills the "Works for Windows > clients" requirement. Probably someone with this need also can put > together an installer (msi or another) to do the dirty work. > > Hopefully 2.0 will be ready by FC4, because that'll be a huge leap in > scalability and easier configuration for a larger number of clients. The developer promised me it will be released within the next month. I've been waiting for a proper release for quite some time now. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From elanthis at awesomeplay.com Sat Feb 12 04:28:47 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 11 Feb 2005 23:28:47 -0500 Subject: -fvisibility=hidden In-Reply-To: References: Message-ID: <1108182527.30107.1.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-02-12 at 00:16 +0100, Felipe Alfaro Solana wrote: >Hello, > >I've seen Mandrake has started compiling KDE with -fvisibility=hidden. >They say this improve load times considerably. Has this flag other >nasty consequences? Check this out, covers in detail the pros/cons of that flag, as well as other issues. The paper concentrates on shared libraries, but is applicable to general app link time issues as well. http://people.redhat.com/drepper/dsohowto.pdf > >Thanks. > -- Sean Middleditch From drepper at redhat.com Sat Feb 12 05:21:00 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 11 Feb 2005 21:21:00 -0800 Subject: -fvisibility=hidden In-Reply-To: References: Message-ID: <420D923C.40709@redhat.com> Felipe Alfaro Solana wrote: > I've seen Mandrake has started compiling KDE with -fvisibility=hidden. > They say this improve load times considerably. Has this flag other nasty > consequences? It changes the API of all the DSOs. Programs might simple stop working since functions are no longer exported from DSOs. One cannot simply add this flag. All functions in a DSO which have ever been used by any program must be exported. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From rahulsundaram at yahoo.co.in Sat Feb 12 08:37:00 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Sat, 12 Feb 2005 00:37:00 -0800 (PST) Subject: Self-Introduction: Ignacio Vazquez-Abrams In-Reply-To: <420BA07A.4090804@insitesinc.com> Message-ID: <20050212083700.94047.qmail@web8502.mail.in.yahoo.com> --- Michael Favia wrote: > Rahul Sundaram wrote: > > >Hi > > > > > > > >>Goals: As maintainer of my own repository I've > come across several > >>packages both general-purpose and niche that I > feel would be appropriate > >>to be contained in a repository that more people > would use. To that end > >>I am willing to maintain most if not all of the > packages that make it > >>from my repository into Fedora Extras or even the > Core. > >> > >> > >> > > > >you can start by proposing individual packages to > the fedora extras list > > > > > What he meant to say was welcome, thank you for > taking the time to > introduce yourself. Anyone with the patience and > wherewithal to deal > with most of the problems that show themselves in > #fedora has my deepest > respect. ;). ya right :-). responding to hundreds of mails demands utilitarian replies. anyway thanks ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From malists at epon.ro Sat Feb 12 09:19:14 2005 From: malists at epon.ro (Marius Andreiana) Date: Sat, 12 Feb 2005 11:19:14 +0200 Subject: openoffice 2.0 & FC4 - status, plans Message-ID: <1108199954.3544.14.camel@venus.epon.ro> >From previous discussions, there are 2 realistic alternatives: - include ooo 1.9.x in rawhide/fc4 tests ASAP. If there's no ooo 2.0 final until FC4 release, issue an update. - leave FC4 with ooo 1.x. Don't issue an update to ooo 2.0, changes are too big for an update. Which one will it be? 2nd option would leave fedora users with ooo 1.x until around november 2005, which is quite late. Arguments for 1st option: - schedules match, both fc4 and ooo 2.0 should have final releases in may http://development.openoffice.org/releases/OpenOffice_org_2_x.html http://fedora.redhat.com/participate/schedule/ - current ooo 1.9.x is very usable. I use it and do QA since 1.9.47 - ooo 2.0 new features since 1.x are many and important - fedora users get a better, stable office suite, red hat desktop users will get a better, tested and rock-solid office suite. By including ooo 1.9.x in FC4 test1, more people will test it. There are already rpms available on people.redhat.com. Please report ooo bugs at http://www.openoffice.org/issues/enter_bug.cgi and packaging bugs at https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% 20Core& Your opinion? -- Marius Andreiana Epon Business Applications http://www.epon.ro From paul at all-the-johnsons.co.uk Sat Feb 12 11:42:46 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 12 Feb 2005 11:42:46 +0000 Subject: openoffice 2.0 & FC4 - status, plans In-Reply-To: <1108199954.3544.14.camel@venus.epon.ro> References: <1108199954.3544.14.camel@venus.epon.ro> Message-ID: <1108208566.5332.6.camel@localhost.localdomain> Hi, >By including ooo 1.9.x in FC4 test1, more people will test it. There are >already rpms available on people.redhat.com. Please report ooo bugs at >http://www.openoffice.org/issues/enter_bug.cgi >and packaging bugs at >https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% >20Core& I'd love to see OOo2(beta) incorporated into rawhide today if truth be told as it is way and above better than the standard OOo. I can see the RH arguments against it though, but given that the schedule for both to be released is about the same time, a small delay in FC4 to incorporate it would be acceptable (IMO at least). TTFN Paul -- "I don't know how World War III will be fought, but I do know World War IV will be fought with sticks and stones" - Einstein -------------- next part -------------- A 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 jos at xos.nl Sat Feb 12 12:02:20 2005 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Feb 2005 13:02:20 +0100 Subject: Fedora non-standard build environment (%_host etc.) Message-ID: <200502121202.j1CC2KB31448@xos037.xos.nl> Hi, When rebuilding pango on a clean FC3 system, the result package includes a directory /etc/pango/i686-redhat-linux-gnu (at least when it is built on a i686 system). FC3 is shipped with /etc/pango/i386-redhat-linux-gnu. I know this be done with "--define '_host i386-redhat-linux-gnu', but is this what RH actually does in their build environment and, if yes, are there more non-standard rpm settings used? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora-devel at camperquake.de Sat Feb 12 12:12:55 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sat, 12 Feb 2005 13:12:55 +0100 Subject: VPN Server features In-Reply-To: <200502121021.07660.symbiont@berlios.de> References: <420CCFAC.1080102@btinternet.com> <20050211164635.3b3526fb@python2> <200502121021.07660.symbiont@berlios.de> Message-ID: <20050212131255.793d0bfd@nausicaa.camperquake.de> Hi. Jeff Pitman wrote: > With a little bit of work, it also fulfills the "Works for Windows > clients" requirement. Probably someone with this need also can put > together an installer (msi or another) to do the dirty work. The windows version has a nice graphical installer. I do not know if there is a GUI, though. Apart from that, it works as it does on *NIX. -- All that glitters has a high refractive index. From buildsys at redhat.com Sat Feb 12 13:24:33 2005 From: buildsys at redhat.com (Build System) Date: Sat, 12 Feb 2005 08:24:33 -0500 Subject: rawhide report: 20050212 changes Message-ID: <200502121324.j1CDOX6g013230@porkchop.devel.redhat.com> Updated Packages: From ville.skytta at iki.fi Sat Feb 12 13:57:16 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 12 Feb 2005 15:57:16 +0200 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <200502121202.j1CC2KB31448@xos037.xos.nl> References: <200502121202.j1CC2KB31448@xos037.xos.nl> Message-ID: <1108216636.5281.249.camel@bobcat.mine.nu> On Sat, 2005-02-12 at 13:02 +0100, Jos Vos wrote: > FC3 is shipped with /etc/pango/i386-redhat-linux-gnu. I know > this be done with "--define '_host i386-redhat-linux-gnu', but > is this what RH actually does in their build environment and, > if yes, are there more non-standard rpm settings used? Does installing redhat-rpm-config affect the build results? From jos at xos.nl Sat Feb 12 14:09:38 2005 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Feb 2005 15:09:38 +0100 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <1108216636.5281.249.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Sat, Feb 12, 2005 at 03:57:16PM +0200 References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> Message-ID: <20050212150938.B31892@xos037.xos.nl> On Sat, Feb 12, 2005 at 03:57:16PM +0200, Ville Skytt? wrote: > > FC3 is shipped with /etc/pango/i386-redhat-linux-gnu. I know > > this be done with "--define '_host i386-redhat-linux-gnu', but > > is this what RH actually does in their build environment and, > > if yes, are there more non-standard rpm settings used? > > Does installing redhat-rpm-config affect the build results? That package is installed. This also applies to RHEL3 and RHEL4b2. In fact, pango could better use %_target i.s.o. %_host, as %_target *is* indenpendent of the specific build host, but the question is why %_host is evaluated this way in the RH builds. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From n3npq at nc.rr.com Sat Feb 12 15:14:14 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 12 Feb 2005 10:14:14 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <20050212150938.B31892@xos037.xos.nl> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> Message-ID: <420E1D46.7000102@nc.rr.com> Jos Vos wrote: >On Sat, Feb 12, 2005 at 03:57:16PM +0200, Ville Skytt? wrote: > > > >>>FC3 is shipped with /etc/pango/i386-redhat-linux-gnu. I know >>>this be done with "--define '_host i386-redhat-linux-gnu', but >>>is this what RH actually does in their build environment and, >>>if yes, are there more non-standard rpm settings used? >>> >>> >>Does installing redhat-rpm-config affect the build results? >> >> > >That package is installed. This also applies to RHEL3 and RHEL4b2. > >In fact, pango could better use %_target i.s.o. %_host, as %_target >*is* indenpendent of the specific build host, but the question is >why %_host is evaluated this way in the RH builds. > > THe issue with pango is perhaps subtle. In a multilib environment, pango was one of about 6 or so packages that had to change because of path collisions. The fix was to create a per-platform directory. How that directory is named, and how the path is determined, have nothing whatsoever to do with the original problem that needed to be solved, i.e. changing the path so that components were not clobbered in a multilib environment. For example, the paths /etc/pango/ringo /etc/pango/john could have been used ;-) 73 de Jeff From jos at xos.nl Sat Feb 12 16:09:06 2005 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Feb 2005 17:09:06 +0100 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <420E1D46.7000102@nc.rr.com>; from n3npq@nc.rr.com on Sat, Feb 12, 2005 at 10:14:14AM -0500 References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> Message-ID: <20050212170906.A32256@xos037.xos.nl> On Sat, Feb 12, 2005 at 10:14:14AM -0500, Jeff Johnson wrote: > THe issue with pango is perhaps subtle. > > In a multilib environment, pango was one of about 6 or so packages that > had to change because of path collisions. > > The fix was to create a per-platform directory. > > How that directory is named, and how the path is determined, have nothing > whatsoever to do with the original problem that needed to be solved, i.e. > changing the path so that components were not clobbered in a multilib > environment. All fine, but my answer is still not answered (unless I'm missing the point in your answer): why is %_host evaluated to i386-redhat-linux-gnu in the RH build environment and to i686-redhat-linux-gnu on a standard Fedora/RHEL system. Is this an intentional, explicit setting in the RH environment, or is it done for a few packages only, or... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From dcbw at redhat.com Sat Feb 12 16:22:44 2005 From: dcbw at redhat.com (Dan Williams) Date: Sat, 12 Feb 2005 11:22:44 -0500 (EST) Subject: openoffice 2.0 & FC4 - status, plans In-Reply-To: <1108208566.5332.6.camel@localhost.localdomain> References: <1108199954.3544.14.camel@venus.epon.ro> <1108208566.5332.6.camel@localhost.localdomain> Message-ID: On Sat, 12 Feb 2005, Paul wrote: > >By including ooo 1.9.x in FC4 test1, more people will test it. There are > >already rpms available on people.redhat.com. Please report ooo bugs at > >http://www.openoffice.org/issues/enter_bug.cgi > >and packaging bugs at > >https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% > >20Core& > > I'd love to see OOo2(beta) incorporated into rawhide today if truth be > told as it is way and above better than the standard OOo. I can see the > RH arguments against it though, but given that the schedule for both to > be released is about the same time, a small delay in FC4 to incorporate > it would be acceptable (IMO at least). Fedora isn't just about OOo though. There are a lot of other packages in the distribution and slipping FC4 just to wait for a build of OOo that may/may not be coming out soon after the FC4 freeze date seems a bit presumptuous. However, since it is a fairly important app, its schedule may get more weight than, say, gcalctool. As we get nearer to the freeze, we'll have a clearer picture of the schedules of both FC4 and OOo 2.0, and Fedora has been known to slip due to other reasons too. Dan From n3npq at nc.rr.com Sat Feb 12 16:22:42 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 12 Feb 2005 11:22:42 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <20050212170906.A32256@xos037.xos.nl> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> Message-ID: <420E2D52.7070408@nc.rr.com> Jos Vos wrote: >On Sat, Feb 12, 2005 at 10:14:14AM -0500, Jeff Johnson wrote: > > > >>THe issue with pango is perhaps subtle. >> >>In a multilib environment, pango was one of about 6 or so packages that >>had to change because of path collisions. >> >>The fix was to create a per-platform directory. >> >>How that directory is named, and how the path is determined, have nothing >>whatsoever to do with the original problem that needed to be solved, i.e. >>changing the path so that components were not clobbered in a multilib >>environment. >> >> > >All fine, but my answer is still not answered (unless I'm missing the >point in your answer): why is %_host evaluated to i386-redhat-linux-gnu >in the RH build environment and to i686-redhat-linux-gnu on a standard >Fedora/RHEL system. > >Is this an intentional, explicit setting in the RH environment, or is >it done for a few packages only, or... > All depends on how build systems are configured. Get a copy of rpm --showrc from a RH build, and configure your build machine the same way. There are as few overrides and "secret sauce" as possible in beehive, by intent. OTOH, arch happens to be one configuration parameter that is overridden frequently. There are certainly no per-package unique build configuration flags by intent. OTOH, configurations can and do rot, and there is the occaisional need to expedite a package build with a hack to get the job done. HTH 73 de Jeff From skvidal at phy.duke.edu Sat Feb 12 16:31:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 12 Feb 2005 11:31:11 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <420E2D52.7070408@nc.rr.com> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> <420E2D52.7070408@nc.rr.com> Message-ID: <1108225871.3823.28.camel@cutter> >There are certainly no per-package unique build configuration flags by >intent. OTOH, >configurations can and do rot, and there is the occaisional need to >expedite a package >build with a hack to get the job done. > I think the only thing Jos is asking is to get these build configs so anyone who wants to build/rebuild fedora can get a complete and accurate rebuild. -sv From n3npq at nc.rr.com Sat Feb 12 16:29:05 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 12 Feb 2005 11:29:05 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <1108225871.3823.28.camel@cutter> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> <420E2D52.7070408@nc.rr.com> <1108225871.3823.28.camel@cutter> Message-ID: <420E2ED1.2000503@nc.rr.com> seth vidal wrote: >>There are certainly no per-package unique build configuration flags by >>intent. OTOH, >>configurations can and do rot, and there is the occaisional need to >>expedite a package >>build with a hack to get the job done. >> >> >> > > >I think the only thing Jos is asking is to get these build configs so >anyone who wants to build/rebuild fedora can get a complete and accurate >rebuild. > > rpm --showrc displays those values. Where those values come from, and why it is done that way, is a rather more complex question. 73 de Jeff From paul at all-the-johnsons.co.uk Sat Feb 12 16:36:44 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 12 Feb 2005 16:36:44 +0000 Subject: openoffice 2.0 & FC4 - status, plans In-Reply-To: References: <1108199954.3544.14.camel@venus.epon.ro> <1108208566.5332.6.camel@localhost.localdomain> Message-ID: <1108226204.5332.12.camel@localhost.localdomain> Hi, >> I'd love to see OOo2(beta) incorporated into rawhide today if truth be >> told as it is way and above better than the standard OOo. I can see the >> RH arguments against it though, but given that the schedule for both to >> be released is about the same time, a small delay in FC4 to incorporate >> it would be acceptable (IMO at least). > >Fedora isn't just about OOo though. There are a lot of other packages in the >distribution and slipping FC4 just to wait for a build of OOo that may/may not >be coming out soon after the FC4 freeze date seems a bit presumptuous. However, >since it is a fairly important app, its schedule may get more weight than, say, >gcalctool. As we get nearer to the freeze, we'll have a clearer picture of the >schedules of both FC4 and OOo 2.0, and Fedora has been known to slip due to >other reasons too. Fair enough. I'm not sure how important it comes in the stakes, but IMO, it's well up there with the developer toolchain. TTFN Paul -- "I don't know how World War III will be fought, but I do know World War IV will be fought with sticks and stones" - Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Sat Feb 12 16:41:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 12 Feb 2005 11:41:06 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <420E2ED1.2000503@nc.rr.com> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> <420E2D52.7070408@nc.rr.com> <1108225871.3823.28.camel@cutter> <420E2ED1.2000503@nc.rr.com> Message-ID: <1108226467.3823.30.camel@cutter> >rpm --showrc displays those values. > >Where those values come from, and why it is done that way, is a rather more >complex question. > I understand how to view them - I think Jos wants to get the ones from a fedora build system. -sv From jos at xos.nl Sat Feb 12 16:46:20 2005 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Feb 2005 17:46:20 +0100 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <1108226467.3823.30.camel@cutter>; from skvidal@phy.duke.edu on Sat, Feb 12, 2005 at 11:41:06AM -0500 References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> <420E2D52.7070408@nc.rr.com> <1108225871.3823.28.camel@cutter> <420E2ED1.2000503@nc.rr.com> <1108226467.3823.30.camel@cutter> Message-ID: <20050212174620.A32373@xos037.xos.nl> On Sat, Feb 12, 2005 at 11:41:06AM -0500, seth vidal wrote: > I understand how to view them - I think Jos wants to get the ones from a > fedora build system. Yep, exactly (although I would prefer to know what settings were changed, i.s.o. just the raw dump that also may contain derived values). I was also looking for beehive packages or scripts on the Fedora site, as I would guess they were published somewhere for Fedora developers, but I couldn't find them. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From n3npq at nc.rr.com Sat Feb 12 16:48:20 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 12 Feb 2005 11:48:20 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <1108226467.3823.30.camel@cutter> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> <420E2D52.7070408@nc.rr.com> <1108225871.3823.28.camel@cutter> <420E2ED1.2000503@nc.rr.com> <1108226467.3823.30.camel@cutter> Message-ID: <420E3354.5020300@nc.rr.com> seth vidal wrote: >>rpm --showrc displays those values. >> >>Where those values come from, and why it is done that way, is a rather more >>complex question. >> >> >> > >I understand how to view them - I think Jos wants to get the ones from a >fedora build system. > > Then he should ask for someone to run rpm --showrc within a specific beehive build tree. What he asked instead was perhaps more complex. I would send rpm --showrc spew to Jos, but I have not access to beehive atm. 73 de Jeff From pbrobinson at gmail.com Sat Feb 12 16:57:28 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 13 Feb 2005 00:57:28 +0800 Subject: openoffice 2.0 & FC4 - status, plans In-Reply-To: References: <1108199954.3544.14.camel@venus.epon.ro> <1108208566.5332.6.camel@localhost.localdomain> Message-ID: <5256d0b0502120857541ab251@mail.gmail.com> > > I'd love to see OOo2(beta) incorporated into rawhide today if truth be > > told as it is way and above better than the standard OOo. I can see the > > RH arguments against it though, but given that the schedule for both to > > be released is about the same time, a small delay in FC4 to incorporate > > it would be acceptable (IMO at least). > > Fedora isn't just about OOo though. There are a lot of other packages in the > distribution and slipping FC4 just to wait for a build of OOo that may/may not > be coming out soon after the FC4 freeze date seems a bit presumptuous. However, > since it is a fairly important app, its schedule may get more weight than, say, > gcalctool. As we get nearer to the freeze, we'll have a clearer picture of the > schedules of both FC4 and OOo 2.0, and Fedora has been known to slip due to > other reasons too. And I also vaguely remember Fedora shipping with an important close to release, relatively stable prerelease product and updating it to the final release shortly after the release. Ahem... firefox 0.10.1 PR1 with release.... cough firefox 1.0 a good couple of weeks later :-) So if its a decent update with a full stable release due about the same time I fully agree shipping a release canditate with the final coming shortly there after. BTW speaking of which what ever happened to a thunderbird 1.0 release/update? regards pete From n3npq at nc.rr.com Sat Feb 12 16:58:47 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 12 Feb 2005 11:58:47 -0500 Subject: Fedora non-standard build environment (%_host etc.) In-Reply-To: <20050212174620.A32373@xos037.xos.nl> References: <200502121202.j1CC2KB31448@xos037.xos.nl> <1108216636.5281.249.camel@bobcat.mine.nu> <20050212150938.B31892@xos037.xos.nl> <420E1D46.7000102@nc.rr.com> <20050212170906.A32256@xos037.xos.nl> <420E2D52.7070408@nc.rr.com> <1108225871.3823.28.camel@cutter> <420E2ED1.2000503@nc.rr.com> <1108226467.3823.30.camel@cutter> <20050212174620.A32373@xos037.xos.nl> Message-ID: <420E35C7.7010204@nc.rr.com> Jos Vos wrote: >On Sat, Feb 12, 2005 at 11:41:06AM -0500, seth vidal wrote: > > >values). > >I was also looking for beehive packages or scripts on the Fedora site, >as I would guess they were published somewhere for Fedora developers, >but I couldn't find them. > > beehive packages are not released anywhere. rpm --showrc should show essentially what is found in redhat-rpm-config. beehive overrides arch during invocation, which percolates throughout rpm configuration in values like %_host. There is also a run time element setting arch (and %_target_cpu) from uname(2) and or the contents of /etc/rpm/platform. Except as noted, all that information is in rpm --showrc spew. 73 de Jeff From mike at navi.cx Sat Feb 12 20:55:36 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 12 Feb 2005 20:55:36 +0000 Subject: alsa-oss got lost? Message-ID: Hi, According to this post from Matthias Saou: https://www.redhat.com/archives/fedora-extras-commits/2004-November/msg00064.html Alsa-oss (aoss) is a part of Fedora Core 3. But it seems not to be, or at least I cannot find it - in fact, I can't find an RPM of it anywhere. Did this one somehow slip through the cracks, or am I just looking in the wrong places? It should really be installed by default IMHO, perhaps even loaded into the environment permenantly (eg the entire desktop run under it), otherwise random apps will not use software mixing for no obvious reason. thanks -mike From pbruna at linuxcenterla.com Sat Feb 12 21:48:10 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Sat, 12 Feb 2005 18:48:10 -0300 Subject: NetworkManager Message-ID: <1108244890.4571.1.camel@p.linuxcenter.cl> i just install NetworkManager and NetworkManager-gnome but i can't find the applet that supose to allow me change networks. the error its not find /usr/share/pixmaps/NMWirelessApplet/wireless-applet.png -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From florin at andrei.myip.org Sat Feb 12 22:02:11 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 12 Feb 2005 14:02:11 -0800 Subject: priorities and dependencies for network interfaces Message-ID: <1108245731.6922.11.camel@scout.home.local> Problem: I've a laptop with a wired network interface (eth0) and a wireless network interface (eth1). Both interfaces are configured for DHCP. The wireless interface can connect to any SSID. If i boot up the laptop without a network cable plugged in, the wireless card will find an access point, get an address and all is good. If i boot up the laptop with a network cable plugged in, it will get an address and a default route from the wired network, but then it will do the same with the wireless network! Often, this will result in unusable network configuration (static route clashes, etc.) Wish: I wish my laptop would stop activating any other interface once the wired network card is on. Possible solution: The various network interfaces should have dependencies: - set a flag on ethX so that, if ethY is already up, don't activate ethX - set a flag on ethX so that, if there's already a default route, don't activate ethX - etc Also, the order the interfaces are brought up should not depend on the interface name (first eth0, then eth1, etc.) because some interfaces are named in a very different way (ath0, ppp0). Therefore, each interface should get a priority flag (an integer) which should determine its place in the boot-up queue. I'm currently playing with /etc/init.d/network and hacking it to implement some features mentioned above. But i'd like to get the group's opinion before investing too much time and effort. What do y'all think? -- Florin Andrei http://florin.myip.org/ From kevinverma at gmail.com Sat Feb 12 22:12:28 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 13 Feb 2005 02:12:28 +0400 Subject: [Evolution] Evolution syncing In-Reply-To: <1108240938.7788.15.camel@linux.site> References: <1108051155.31657.9.camel@linux.site> <1108052217.32184.12.camel@lin-workstation.azapple.com> <1108053068.6790.27.camel@bishop.rosevear.com> <1108061016.32628.15.camel@lin-workstation.azapple.com> <1108240938.7788.15.camel@linux.site> Message-ID: <1108246348.8760.9.camel@localhost.localdomain> Guys, Finally a success story, Zire 72 does sync with gnome-pilot on FC3. Two most important things missing are: 1) udev default for common pilot PDAs 2) few popular pilot PDAs missing from /usr/share/gnome- pilot/devices.xml The changes I had to make are as following: /usr/share/gnome-pilot/devices.xml /etc/udev/rules.d/10-visor.rules BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot" JP Hats off to you buddy, I hope you guys will take care next time. Many Thanks On Sat, 2005-02-12 at 13:42 -0700, Richard Zach wrote: > Someone just posted something to the gnome-pilot list which might > explain the syncing problems reported by various people recently: > > > Oh, forgot the obvious: have you added the USB Vendor/Product ID to > > the list of recognised IDs for gnome-pilot? If you're running > > gnome-pilot-2.0.12 you need to edit the devices.xml file by hand and > > restart gnome-pilot. > > > > The Kyocera Vendor ID is 0x0c88, and the device ID for the > > 7135 is 0x0021. > > The Palm Zire 72, for instance, isn't in > my /opt/gnome/share/gnome-pilot/devices.xml > > Maybe that helps. > -R > -- Kevin Verma From michael.favia at insitesinc.com Sat Feb 12 22:56:11 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Sat, 12 Feb 2005 16:56:11 -0600 Subject: priorities and dependencies for network interfaces In-Reply-To: <1108245731.6922.11.camel@scout.home.local> References: <1108245731.6922.11.camel@scout.home.local> Message-ID: <420E898B.4020103@insitesinc.com> Florin Andrei wrote: >Problem: >I've a laptop with a wired network interface (eth0) and a wireless >network interface (eth1). Both interfaces are configured for DHCP. The >wireless interface can connect to any SSID. >If i boot up the laptop without a network cable plugged in, the wireless >card will find an access point, get an address and all is good. >If i boot up the laptop with a network cable plugged in, it will get an >address and a default route from the wired network, but then it will do >the same with the wireless network! Often, this will result in unusable >network configuration (static route clashes, etc.) > >Wish: >I wish my laptop would stop activating any other interface once the >wired network card is on. > > How does this affect servers with multiple network interfaces? While i understand your frustration and agree that the initialization og network devices should be refined ifn a few ways im afraid that the changes you are looking to make ignore the scope of the distributions use. As a result i would think that the ability to configure this type of behavior would be appreciated by all (especially me) the default behavior should remain (possibly as the default through an expanded configuration capability). -mf From bclark at redhat.com Sat Feb 12 23:53:09 2005 From: bclark at redhat.com (Bryan Clark) Date: Sat, 12 Feb 2005 18:53:09 -0500 Subject: priorities and dependencies for network interfaces In-Reply-To: <1108245731.6922.11.camel@scout.home.local> References: <1108245731.6922.11.camel@scout.home.local> Message-ID: <1108252389.3887.3.camel@rhbw.boston.redhat.com> On Sat, 2005-02-12 at 14:02 -0800, Florin Andrei wrote: >Problem: >I've a laptop with a wired network interface (eth0) and a wireless >network interface (eth1). Both interfaces are configured for DHCP. The >wireless interface can connect to any SSID. >If i boot up the laptop without a network cable plugged in, the wireless >card will find an access point, get an address and all is good. >If i boot up the laptop with a network cable plugged in, it will get an >address and a default route from the wired network, but then it will do >the same with the wireless network! Often, this will result in unusable >network configuration (static route clashes, etc.) > >Wish: >I wish my laptop would stop activating any other interface once the >wired network card is on. Have you tried NetworkManager, it will do just what you're asking for. yum install NetworkManager NetworkManager-gnome You might want to enable the rawhide repository so you get the latest. NetworkManager works in KDE as well since it runs out of the notification area. check it out: http://people.redhat.com/dcbw/NetworkManager/ Cheers, ~ Bryan From bclark at redhat.com Sat Feb 12 23:59:02 2005 From: bclark at redhat.com (Bryan Clark) Date: Sat, 12 Feb 2005 18:59:02 -0500 Subject: NetworkManager In-Reply-To: <1108244890.4571.1.camel@p.linuxcenter.cl> References: <1108244890.4571.1.camel@p.linuxcenter.cl> Message-ID: <1108252742.3887.8.camel@rhbw.boston.redhat.com> When you're logged in as yourself did you run NetworkManagerInfo from a terminal? It doesn't appear automatically on the first run just yet. If you do a 'ps ax | grep Network' you should see NetworkManager and NetworkManagerInfo both running. You might try restarting the NetworkManager service (past few releases have needed that for me). Cheers, ~ Bryan On Sat, 2005-02-12 at 18:48 -0300, Patricio Bruna V wrote: >i just install NetworkManager and NetworkManager-gnome >but i can't find the applet that supose to allow me change networks. >the error its not >find /usr/share/pixmaps/NMWirelessApplet/wireless-applet.png From mike at navi.cx Sun Feb 13 00:37:40 2005 From: mike at navi.cx (Mike Hearn) Date: Sun, 13 Feb 2005 00:37:40 +0000 Subject: alsa-oss got lost? References: Message-ID: On Sat, 12 Feb 2005 20:55:36 +0000, Mike Hearn wrote: > It should really be installed by default IMHO, perhaps even > loaded into the environment permenantly (eg the entire desktop run under > it), otherwise random apps will not use software mixing for no obvious > reason. Scratch that, it apparently messes up select() and maybe there are other compatibility problems with it too. At the very least it needs more work. I submitted one patch for it to Jaroslav already, who knows how many more it may need.... From florin at andrei.myip.org Sun Feb 13 01:37:11 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 12 Feb 2005 17:37:11 -0800 Subject: priorities and dependencies for network interfaces In-Reply-To: <1108252389.3887.3.camel@rhbw.boston.redhat.com> References: <1108245731.6922.11.camel@scout.home.local> <1108252389.3887.3.camel@rhbw.boston.redhat.com> Message-ID: <1108258631.5971.3.camel@scout.home.local> On Sat, 2005-02-12 at 18:53 -0500, Bryan Clark wrote: > Have you tried NetworkManager, it will do just what you're asking for. > > yum install NetworkManager NetworkManager-gnome > > You might want to enable the rawhide repository so you get the latest. > NetworkManager works in KDE as well since it runs out of the > notification area. I knew the day was come when dbus would finally start working some kickass magic! :-) Anyway, if i enable rawhide, yum finally bails out after running through a ton of dependencies. If i don't enable rawhide, i can install NM just fine, but it doesn't work: # /etc/init.d/NetworkManager start Setting network parameters: [ OK ] Starting NetworkManager daemon: ** (process:6238): CRITICAL **: file NetworkManagerDevice.c: line 324 (nm_device_unref): assertion `dev != NULL' failed [FAILED] -- Florin Andrei http://florin.myip.org/ From mbneto at gmail.com Sun Feb 13 01:42:02 2005 From: mbneto at gmail.com (mbneto) Date: Sat, 12 Feb 2005 21:42:02 -0400 Subject: A tale of two bugzillas In-Reply-To: <420A5223.3040002@silverorange.com> References: <1107956832.8636.27.camel@Madison.badger.com> <1107964024.5706.12.camel@bree.local.net> <420A5223.3040002@silverorange.com> Message-ID: <5cf776b8050212174267a7458a@mail.gmail.com> Looks great indeed. As a suggestion, if you reach the guy, remind him/her to add a to the template. - mb On Wed, 09 Feb 2005 14:10:43 -0400, Steven Garrity wrote: > Jeremy Katz wrote: > > On Wed, 2005-02-09 at 08:47 -0500, Toshio wrote: > >>Are there any substantive differences between bugzilla.redhat.com and > >>bugzilla.redhat.com/beta? In particular, it looks like they are views > >>of the same data so it should be okay to enter information into either > >>one? > > > > It's the same database. /beta is the current devel one (and a lot nicer > > in a lot of ways) and should be becoming the main interface "real soon > > now" > > Who has been doing the visual/UI customization in the new beta Bugzilla? > It looks great. I'd love to see if we could get this kind of > customization and integration into the Mozilla.org style for > bugzilla.mozilla.org > > Thanks, > Steven Garrity > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From dcbw at redhat.com Sun Feb 13 04:39:00 2005 From: dcbw at redhat.com (Dan Williams) Date: Sat, 12 Feb 2005 23:39:00 -0500 (EST) Subject: priorities and dependencies for network interfaces In-Reply-To: <1108258631.5971.3.camel@scout.home.local> References: <1108245731.6922.11.camel@scout.home.local> <1108252389.3887.3.camel@rhbw.boston.redhat.com> <1108258631.5971.3.camel@scout.home.local> Message-ID: On Sat, 12 Feb 2005, Florin Andrei wrote: > > Have you tried NetworkManager, it will do just what you're asking for. > > > > yum install NetworkManager NetworkManager-gnome > > > > You might want to enable the rawhide repository so you get the latest. > > NetworkManager works in KDE as well since it runs out of the > > notification area. > > I knew the day was come when dbus would finally start working some > kickass magic! :-) > > Anyway, if i enable rawhide, yum finally bails out after running through > a ton of dependencies. > If i don't enable rawhide, i can install NM just fine, but it doesn't > work: > > # /etc/init.d/NetworkManager start > Setting network parameters: [ OK ] > Starting NetworkManager daemon: > ** (process:6238): CRITICAL **: file NetworkManagerDevice.c: line 324 > (nm_device_unref): assertion `dev != NULL' failed > [FAILED] Yeah, NM has become somewhat more stable since the version that's in FC-3. That seems to happen at least ever week or two. I'm going to shove a new version through into Rawhide for FC4 test 1, and will also push that same version to FC3-updates-testing. Look for it soon :) Dan From shiva at sewingwitch.com Sun Feb 13 05:38:19 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 12 Feb 2005 21:38:19 -0800 Subject: mod_bt package Message-ID: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> Has anyone attempted to capture mod_bt in an RPM? >From the web page: > mod_bt is a BitTorrent tracker for the Apache webserver. It is written in > C and runs as an Apache 2.x module. It is possible for mod_perl or PHP > to directly access the tracker's information; no need to download and > bdecode scrape URLs. The tracker is fully configured from within Apache's > own configuration file. I tried simply building it from the tarball tonight but it fails trying to build the Apache part, and I think its assumptions about APR are wrong, as it can't find apr.h. (apr-devel is installed, and the file is in /usr/include/apr-0/.) I'm no expert on building Apache modules and certainly not on how RH has packaged the associated development system, so I'm not sure how to proceed. Is there a "canonical Apache module RPM" that can be used as an example of how modules should be organized in the RPM environment? From kevinverma at gmail.com Sun Feb 13 06:26:31 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 13 Feb 2005 06:26:31 -0000 Subject: [Evolution] Evolution syncing In-Reply-To: <1108240938.7788.15.camel@linux.site> References: <1108051155.31657.9.camel@linux.site> <1108052217.32184.12.camel@lin-workstation.azapple.com> <1108053068.6790.27.camel@bishop.rosevear.com> <1108061016.32628.15.camel@lin-workstation.azapple.com> <1108240938.7788.15.camel@linux.site> Message-ID: <141801c51194$f4db6c60$0301a8c0@executivesontheweb.local> Guys, Finally a success story, Zire 72 does sync with gnome-pilot on FC3. Two most important things missing are: 1) udev default for common pilot PDAs 2) few popular pilot PDAs missing from /usr/share/gnome- pilot/devices.xml The changes I had to make are as following: /usr/share/gnome-pilot/devices.xml /etc/udev/rules.d/10-visor.rules BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot" JP Hats off to you buddy, I hope you guys will take care next time. Many Thanks On Sat, 2005-02-12 at 13:42 -0700, Richard Zach wrote: > Someone just posted something to the gnome-pilot list which might > explain the syncing problems reported by various people recently: > > > Oh, forgot the obvious: have you added the USB Vendor/Product ID to > > the list of recognised IDs for gnome-pilot? If you're running > > gnome-pilot-2.0.12 you need to edit the devices.xml file by hand and > > restart gnome-pilot. > > > > The Kyocera Vendor ID is 0x0c88, and the device ID for the > > 7135 is 0x0021. > > The Palm Zire 72, for instance, isn't in > my /opt/gnome/share/gnome-pilot/devices.xml > > Maybe that helps. > -R > -- Kevin Verma _______________________________________________ evolution maillist - evolution at lists.ximian.com http://lists.ximian.com/mailman/listinfo/evolution From buildsys at redhat.com Sun Feb 13 13:01:04 2005 From: buildsys at redhat.com (Build System) Date: Sun, 13 Feb 2005 08:01:04 -0500 Subject: rawhide report: 20050213 changes Message-ID: <200502131301.j1DD142U029791@porkchop.devel.redhat.com> Updated Packages: From cpedersen at c-note.dk Sun Feb 13 17:05:38 2005 From: cpedersen at c-note.dk (Casper Pedersen) Date: Sun, 13 Feb 2005 18:05:38 +0100 Subject: mod_bt package In-Reply-To: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> Message-ID: <420F88E2.7010507@c-note.dk> > Has anyone attempted to capture mod_bt in an RPM? No. > I tried simply building it from the tarball tonight but it fails > trying to build the Apache part, and I think its assumptions about APR > are wrong, as it can't find apr.h. (apr-devel is installed, and the > file is in /usr/include/apr-0/.) > Try by adding "--with-apr-include=/usr/include/apr-0" to configure. Regards/Casper -- GPG Public key is available from: http://www.keyserver.net/ Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From kyrre at solution-forge.net Sun Feb 13 21:23:56 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 13 Feb 2005 22:23:56 +0100 Subject: fedora stable branch updates Q&A policy In-Reply-To: <20050128095349.60116.qmail@web8509.mail.in.yahoo.com> References: <20050128095349.60116.qmail@web8509.mail.in.yahoo.com> Message-ID: <1108329836.3449.0.camel@localhost.localdomain> fre, 28.01.2005 kl. 10.53 skrev Rahul Sundaram: > --- Colin Charles wrote: > > > On Thu, 2005-01-27 at 19:46 +0100, Kyrre Ness Sjobak > > wrote: > > > Personally, i would believe a q&a mailinglist and > > a "testing" repo for > > > yum could be a good idea, in order to get packages > > as good tested as > > > possible - as fast as possible. > > > > There is a testing repo, its called updates-testing > > (look > > in /etc/yum.repos.d/fedora-updates-testing.repo). > > Discussion of that > > happens at fedora-test-list at redhat.com as do the > > announcements for new > > packages > > > > However, I don't think many folk test it and QA it, > > and it usually gets > > pushed out as an update (updates-released) within a > > couple of days > > > > So, whats your issue with an update that core had? > > > there were several regressions. kernels, gui for > firewall with relation to selinux, network manager and > so on. I am sure many of them are well know if you > search in the users list and bugzilla > And now, the openoffice bug. Major one (wrong shortcuts i think it was) From dcbw at redhat.com Sun Feb 13 22:14:14 2005 From: dcbw at redhat.com (Dan Williams) Date: Sun, 13 Feb 2005 17:14:14 -0500 (EST) Subject: fedora stable branch updates Q&A policy In-Reply-To: <1108329836.3449.0.camel@localhost.localdomain> References: <20050128095349.60116.qmail@web8509.mail.in.yahoo.com> <1108329836.3449.0.camel@localhost.localdomain> Message-ID: On Sun, 13 Feb 2005, Kyrre Ness Sjobak wrote: > fre, 28.01.2005 kl. 10.53 skrev Rahul Sundaram: > > --- Colin Charles wrote: > > > > > On Thu, 2005-01-27 at 19:46 +0100, Kyrre Ness Sjobak > > > wrote: > > > > Personally, i would believe a q&a mailinglist and > > > a "testing" repo for > > > > yum could be a good idea, in order to get packages > > > as good tested as > > > > possible - as fast as possible. > > > > > > There is a testing repo, its called updates-testing > > > (look > > > in /etc/yum.repos.d/fedora-updates-testing.repo). > > > Discussion of that > > > happens at fedora-test-list at redhat.com as do the > > > announcements for new > > > packages > > > > > > However, I don't think many folk test it and QA it, > > > and it usually gets > > > pushed out as an update (updates-released) within a > > > couple of days > > > > > > So, whats your issue with an update that core had? > > > > > > there were several regressions. kernels, gui for > > firewall with relation to selinux, network manager and > > so on. I am sure many of them are well know if you > > search in the users list and bugzilla > > > And now, the openoffice bug. Major one (wrong shortcuts i think it was) Fix is waiting on releng to get pushed. Main cause was updating the tarball to latest supposedly "stable" ooo-build sources, into which Novell had pushed a few broken patches. Will be more careful in the future, but the 1.1.2->1.1.3 transition was difficult and people really seemed to want 1.1.3 for some reason. Dan From byte at aeon.com.my Sun Feb 13 22:16:04 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 14 Feb 2005 06:16:04 +0800 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: References: Message-ID: <1108332965.6792.102.camel@localhost.localdomain> On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote: > I'm not yet sure whether we'll have PowerPC included - it would help > to > have someone from that team give a summary of the status of rawhide on > that arch. I know Paul did an install on his iMac and was successful So, I did one today on the iBook G3. X detection from anaconda wasn't appropriate (first time this has happened, incidentally); relevant bugzilla filed (radeon 7500 not being configured well). Autopartitioning is still something that needs to be fixed. Manual disk druid partitioning works There is an /etc/yaboot.conf with the appropriate initrd line available. However, the drive isn't blessed (so running /sbin/mkofboot, and then saying Y will allow you to get fedora booting - in the instructions, this is stated to be /sbin/yabootconfig ...) X, for the Radeon 7500 actually comes up, using fbdev, at 640x480. Its ugly :P rhgb works. SELinux brought up a system that was rather weird - ping, scp, traceroute wouldn't work (error while loading shared libraries: cannot restore segment prot after reloc: Permission denied). Bringing it up with selinux=0 solved that for me quickly. APM is still installed by default. Why is apmd.spec showing: ExclusiveArch: %{ix86} ppc Do we really want apmd running on PPC? I'd have figured pmud/pbbuttonsd (i'm vouching for the former) would be a better bet. Incidentally, David Woodhouse should be posting (or has already posted) for pmud's inclusion into Extras -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From shiva at sewingwitch.com Sun Feb 13 22:35:26 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 13 Feb 2005 14:35:26 -0800 Subject: mod_bt package In-Reply-To: <420F88E2.7010507@c-note.dk> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> Message-ID: --On Sunday, February 13, 2005 6:05 PM +0100 Casper Pedersen wrote: > Try by adding "--with-apr-include=/usr/include/apr-0" to configure. Thanks. Alas, that doesn't fix it. Here's the failing command (can't find apr.h): /usr/sbin/apxs -S CFLAGS="-g -O2 -O2 -Werror -Wall -Wimplicit-function-declaration -Wall -Wno-strict-aliasing -I.. -I../libbtt " -L.. -lbtt `/usr/bin/apr-config --ldflags` -ldb-4.2 `/usr/bin/apr-config --link-ld --libs` -c mod_bt.c "apr-config --includes" displays the correct directory, so I'd guess apxs is not using that. With that hint it looks like I can add `/usr/bin/apr-config --includes` to the above command. That seems to let that part run to completion. The next failure happens building php_mod_bt. It looks like multiple headers are defining regex stuff, from both glibc-headers and httpd-devel. I'd guess that the glibc-headers one wants to be suppressed, since the other is included by way of php-devel stuff. I see this happening with the first source file: make -C php_mod_bt make[3]: Entering directory `/home2/buildmeister/BUILD/mod_bt-0.0.13/src/apache2/php_mod_bt' gcc -g -O2 -O2 -Werror -Wall -Wimplicit-function-declaration -fpic -I/usr/include/httpd -I/usr/include/apr-0 -I/usr/include/php -I/usr/incl? ude/php/main -I/usr/include/php/Zend -I/usr/include/php/TSRM -DBT_VERSION=\"0.0.13\" `/usr/bin/apr-config --cppflags --includes` `/usr/bin/php? -config --includes` -I../.. -I ../../libbtt -DCOMPILE_DL=1 -c -o php_mod_bt.o php_mod_bt.c In file included from /usr/include/httpd/httpd.h:43, from php_apache.h:24, from php_mod_bt.c:8: /usr/include/httpd/pcreposix.h:32:1: "REG_ICASE" redefined In file included from /usr/include/php/main/php_regex.h:39, from /usr/include/php/main/php.h:78, from php_mod_bt.c:6: /usr/include/regex.h:277:1: this is the location of the previous definition From dwmw2 at infradead.org Sun Feb 13 22:51:38 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Feb 2005 22:51:38 +0000 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: <1108332965.6792.102.camel@localhost.localdomain> References: <1108332965.6792.102.camel@localhost.localdomain> Message-ID: <1108335098.7436.100.camel@localhost.localdomain> On Mon, 2005-02-14 at 06:16 +0800, Colin Charles wrote: >On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote: >> I'm not yet sure whether we'll have PowerPC included - it would help >> to have someone from that team give a summary of the status of >> rawhide on that arch. > >I know Paul did an install on his iMac and was successful I updated my powerbook to rawhide a few days ago, just after the rpm-4.4 update. Nothing broken on it that isn't broken on i386, afaict. It's just the installer autopartitioning and yaboot stuff which needs attention for PPC, I think. I'm using a lot of FC3/ppc machines for real work, and there's basically not a lot wrong with FC3 other than the installer, either. >APM is still installed by default. Why is apmd.spec showing: > ExclusiveArch: %{ix86} ppc > >Do we really want apmd running on PPC? I'd have figured pmud/pbbuttonsd >(i'm vouching for the former) would be a better bet. We don't get battstat_applet support in gnome-applets unless we provide /usr/lib/libapm.a. Yes, that sucks. > Incidentally, David Woodhouse should be posting (or has already >posted) for pmud's inclusion into Extras Waiting for someone to second it. -- dwmw2 From byte at aeon.com.my Mon Feb 14 01:04:30 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 14 Feb 2005 09:04:30 +0800 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: <1108335098.7436.100.camel@localhost.localdomain> References: <1108332965.6792.102.camel@localhost.localdomain> <1108335098.7436.100.camel@localhost.localdomain> Message-ID: <1108343070.6792.108.camel@localhost.localdomain> On Sun, 2005-02-13 at 22:51 +0000, David Woodhouse wrote: > I'm using a lot of FC3/ppc machines for real work, and there's basically > not a lot wrong with FC3 other than the installer, either. Agreed. We need to fix: a) autopartitioning b) since we provide a correct yaboot.conf, just run mkofboot and bless it > >APM is still installed by default. Why is apmd.spec showing: > > ExclusiveArch: %{ix86} ppc > > > >Do we really want apmd running on PPC? I'd have figured pmud/pbbuttonsd > >(i'm vouching for the former) would be a better bet. > > We don't get battstat_applet support in gnome-applets unless we > provide /usr/lib/libapm.a. Yes, that sucks. Urgh. > > Incidentally, David Woodhouse should be posting (or has already > >posted) for pmud's inclusion into Extras > > Waiting for someone to second it. Aye from me, though I haven't taken a look at the spec file/built it yet. Will do so soon (after I fix selinux issues) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From dwmw2 at infradead.org Mon Feb 14 01:08:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Feb 2005 01:08:22 +0000 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: <1108343070.6792.108.camel@localhost.localdomain> References: <1108332965.6792.102.camel@localhost.localdomain> <1108335098.7436.100.camel@localhost.localdomain> <1108343070.6792.108.camel@localhost.localdomain> Message-ID: <1108343302.7436.115.camel@localhost.localdomain> On Mon, 2005-02-14 at 09:04 +0800, Colin Charles wrote: >Aye from me, though I haven't taken a look at the spec file/built it >yet. Will do so soon (after I fix selinux issues) I took the YDL patches I liked, I updated to apmud-1.0.0 from upstream, I fixed the fcntl thing properly, I updated the init script. There's possibly more that could be done, but it's working for now. I'll import it in the morning. -- dwmw2 From shiva at sewingwitch.com Mon Feb 14 01:43:32 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 13 Feb 2005 17:43:32 -0800 Subject: mod_bt package In-Reply-To: References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> Message-ID: <098F540093982AB8186FEDF0@[10.0.0.4]> --On Sunday, February 13, 2005 2:35 PM -0800 Kenneth Porter wrote: > The next failure happens building php_mod_bt. It looks like multiple > headers are defining regex stuff, from both glibc-headers and httpd-devel. Misdiagnosis. The problem is a conflict between the regex stuff in Apache and PHP headers. To reproduce, make a simple source file and attempt to compile it: echo > foo.c << EOF #include "php.h" #include "httpd.h" EOF gcc `php-config --includes` `apr-config --includes` -I /usr/include/httpd -c foo.c Now look at the definition of REG_ICASE is /usr/include/httpd/pcreposix.h and /usr/include/regex.h. I'm not sure how to address this or who to file this with. For now I'll post it to the mod_bt maintainer. From shiva at sewingwitch.com Mon Feb 14 02:06:35 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 13 Feb 2005 18:06:35 -0800 Subject: mod_bt package In-Reply-To: <098F540093982AB8186FEDF0@[10.0.0.4]> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> <098F540093982AB8186FEDF0@[10.0.0.4]> Message-ID: <300E4C70D60FE58FCEDEAB38@[10.0.0.4]> --On Sunday, February 13, 2005 5:43 PM -0800 Kenneth Porter wrote: ># include "php.h" ># include "httpd.h" As a hack, I suppressed inclusion of Apache's regex file with: #define _PCREPOSIX_H This allows things to build. It doesn't look like anything in this module uses regex support so this should work for now. From bojan at rexursive.com Mon Feb 14 03:12:01 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 14 Feb 2005 14:12:01 +1100 Subject: GFS inside Xen Message-ID: <1108350721.42101701ea3d2@imp.rexursive.com> This may sound like a very strange thing to do, but it may be useful in situations where you have only one physical machine and want to play with GFS based clusters. So the real question is, did anyone try this (with current development branch) and if yes, was there some kind of "magic" setup involved or did it just work? I've posted this message originally on the user list, but later realised that the devel list is the correct place for virtualisation questions. Sorry :-( -- Bojan From si at bananas.hopto.org Mon Feb 14 08:29:15 2005 From: si at bananas.hopto.org (Si Jones) Date: Mon, 14 Feb 2005 08:29:15 -0000 (GMT) Subject: Current Dev Tree Message-ID: <15517.195.8.190.39.1108369755.squirrel@bananas.hopto.org> Hi, Just to let you know some things maybe issues... When I tried to yum upto dev it complained about perl, xchat, foomatic So I excluded them from the update, once the update was done, X will not run and I get glic detected if I try to login on a shell using runlevel 3... Is there any fix I can do or should I rebuild my machine...? it a amd64. Thanks, Si From jbarnes at engr.sgi.com Wed Feb 2 22:41:58 2005 From: jbarnes at engr.sgi.com (Jesse Barnes) Date: Wed, 2 Feb 2005 14:41:58 -0800 Subject: FC for ia64? Message-ID: <200502021441.58659.jbarnes@engr.sgi.com> What would it take to make ia64 support in Fedora bit more official? I.e. part of core releases, part of the Extras build process, etc. I might be interested in taking it on if it's not something huge... FWIW, I've been using it pretty regularly on an Altix 350 I have here and it's working pretty well for the most part (at least as well as it does on my PowerBook). Thanks, Jesse From jerry at samba.org Fri Feb 4 18:43:55 2005 From: jerry at samba.org (Gerald (Jerry) Carter) Date: Fri, 04 Feb 2005 12:43:55 -0600 Subject: [Samba] Samba RPMs for RedHat/FC and idmap_rid In-Reply-To: <20050204183459.57562.qmail@web51010.mail.yahoo.com> References: <20050204183459.57562.qmail@web51010.mail.yahoo.com> Message-ID: <4203C26B.3060304@samba.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 S Murthy Kambhampaty wrote: | As discussed previously on this list, Samba RPMs for | Fedora Core do not include idmap_rid support. This is | also true for older RedHat distributions. SuSE on the | other hand, seems to have been patching in idmap_rid | support since 3.0.5 or so; and with trusted domain | support, to boot. Harrumph. | | I've been able to rebuild samba srpms on FC2 and | RedHat 8 by patching the samba distributed rpms, and | get idmap_rid support which is a lot easier than using | the xad plugins (no offense to PADL and Luke H., but | our setup is simple so idmap_rid is all we need). The | diffs are attached; it would be nice if they could be | mainlined. | | Thanks, Murthy | | PS: It is way cool that mappings produced by RH8, FC2 | and SuSE 9.2 are same, with so little effort, thanks | for this feature, Samba team. Murth, If you will send me your spec file patches I'll get them in for the next Samba release. The attachments were strippedby mailman (for samba.org at least). cheers, jerry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCA8JrIR7qMdg1EfYRAsKDAJ4zf7VtN4di89PGmEVfbMpRHsRwgQCgqkij nuaRWWLW5FIdSm2RUcZIHp4= =z1uc -----END PGP SIGNATURE----- From fernando.herrera at tecsidel.es Mon Feb 7 11:45:45 2005 From: fernando.herrera at tecsidel.es (Fernando Herrera) Date: Mon, 07 Feb 2005 12:45:45 +0100 Subject: updated Festival (text-to-speech) rpms In-Reply-To: <42073403.4000602@feuerpokemon.de> References: <20050207063918.GA12229@jadzia.bu.edu> <42073403.4000602@feuerpokemon.de> Message-ID: <1107776745.2760.33.camel@localhost> El lun, 07-02-2005 a las 10:25 +0100, dragoran escribi?: > >Preliminary packages to use as a base (shouldn't require much more work at > >all): > > > >And bug requesting update: > > > > > >It'd be super-cool to get this in for the FC4 release, but I understand > >we're getting close, so there it is for the future if that is missed. > > > > > > > can you also add some non us voices? Yes, including the Spanish "el" voice [1] would be a great step on getting an accesible Desktop out-of-the-box for people speaking Spanish with FC. Thanks [1] http://www.cstr.ed.ac.uk/downloads/festival/1.95/festvox_ellpc11k.tar.gz From shiva at sewingwitch.com Mon Feb 14 09:45:31 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 14 Feb 2005 01:45:31 -0800 Subject: mod_bt package In-Reply-To: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> Message-ID: <5A23ACF8CF3B3A2A86305671@[10.0.0.4]> --On Saturday, February 12, 2005 9:38 PM -0800 Kenneth Porter wrote: > I've created an SRPM for this here: I can load it on my Apache setup but the virtual server isn't listening on the desired port. I'm not sure yet what I'm doing wrong in configuring that but I'm still investigating. The module seems to create its database and issues reasonable shutdown messages when Apache is stopped. From harald at redhat.com Mon Feb 14 10:46:46 2005 From: harald at redhat.com (Harald Hoyer) Date: Mon, 14 Feb 2005 11:46:46 +0100 Subject: udev complains about makedev.d/*.nodes In-Reply-To: <4efa4d2a5d5583f898ff09980abb6dcc@mac.com> References: <4efa4d2a5d5583f898ff09980abb6dcc@mac.com> Message-ID: <42108196.3090902@redhat.com> Felipe Alfaro Solana wrote: > udev-050-3 issues a warning if no /etc/sysconfig/makedev.d/*.nodes file > matches. This will shut udev up. > see https://bugzilla.redhat.com/beta/show_bug.cgi?id=147814 From jorton at redhat.com Mon Feb 14 10:54:57 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 14 Feb 2005 10:54:57 +0000 Subject: mod_bt package In-Reply-To: <098F540093982AB8186FEDF0@[10.0.0.4]> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> <098F540093982AB8186FEDF0@[10.0.0.4]> Message-ID: <20050214105457.GA24808@redhat.com> On Sun, Feb 13, 2005 at 05:43:32PM -0800, Kenneth Porter wrote: > --On Sunday, February 13, 2005 2:35 PM -0800 Kenneth Porter > wrote: > > >The next failure happens building php_mod_bt. It looks like multiple > >headers are defining regex stuff, from both glibc-headers and httpd-devel. > > Misdiagnosis. The problem is a conflict between the regex stuff in Apache > and PHP headers. To reproduce, make a simple source file and attempt to > compile it: > > echo > foo.c << EOF > #include "php.h" > #include "httpd.h" > EOF > gcc `php-config --includes` `apr-config --includes` -I /usr/include/httpd > -c foo.c > > Now look at the definition of REG_ICASE is /usr/include/httpd/pcreposix.h > and /usr/include/regex.h. What versions of php and httpd are you using? You shouldn't get this problem with FC3 or Raw Hide. joe From iago.rubio at hispalinux.es Mon Feb 14 10:58:26 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Mon, 14 Feb 2005 11:58:26 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9D9F9.7F27132C@dnalounge.com> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> Message-ID: <1108378702.18437.8.camel@speedy.iagorubio.net> On Fri, 2005-01-28 at 07:21, Jamie Zawinski wrote: > So then I tried Totem, and it suffers from the canonical Red Hat > braindamage of "oh, you haven't installed the mystery secret MP3 plugin, > and no, I won't even hint to you where to find it." Frankly, I can't be > bothered to go on this snark hunt again, I've done that enough times. Feel free to buy an MP3 decoder license and donate it to rh. http://www.mp3licensing.com/help/developer.html#1 http://www.iis.fraunhofer.de/amm/legal/index.html http://www.mp3licensing.com/royalty/index.html Regards. -- Iago Rubio From pbruna at linuxcenterla.com Mon Feb 14 12:29:10 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Mon, 14 Feb 2005 09:29:10 -0300 Subject: GFS Message-ID: <1108384150.2929.4.camel@p.linuxcenter.cl> its gfs related in anyway with opengfs? i asking this because i want to know if fedora(redhat) GFS support OpenDLM thx -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A 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 Mon Feb 14 12:46:43 2005 From: buildsys at redhat.com (Build System) Date: Mon, 14 Feb 2005 07:46:43 -0500 Subject: rawhide report: 20050214 changes Message-ID: <200502141246.j1ECkhbn015185@porkchop.devel.redhat.com> Updated Packages: From aoliva at redhat.com Mon Feb 14 13:18:27 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 14 Feb 2005 11:18:27 -0200 Subject: Current Dev Tree In-Reply-To: <15517.195.8.190.39.1108369755.squirrel@bananas.hopto.org> References: <15517.195.8.190.39.1108369755.squirrel@bananas.hopto.org> Message-ID: On Feb 14, 2005, "Si Jones" wrote: > X will not run and I get glic detected if I try to login on a shell > using runlevel 3... Is there any fix I can do or should I rebuild my > machine...? it a amd64. Boot single-user, run prelink -u /lib64/libc-2.3.4.so, then update to today's glibc and you should be all set. There's a bug in glibc-2.3.4-7 that breaks prelinked start-up badly on amd64. 2.3.4-10 seems to be fine. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From ph18 at cornell.edu Mon Feb 14 14:14:12 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Mon, 14 Feb 2005 09:14:12 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108378702.18437.8.camel@speedy.iagorubio.net> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> Message-ID: On Mon, 14 Feb 2005 11:58:26 +0100, Iago Rubio wrote: > Feel free to buy an MP3 decoder license and donate it to rh. > http://www.mp3licensing.com/help/developer.html#1 > http://www.iis.fraunhofer.de/amm/legal/index.html > http://www.mp3licensing.com/royalty/index.html > That's insane. The decoder license is $60,000. What's that? The revenue RH gets from selling 40 copies of RHEL 3 AS -- with a kernel that's so full of race conditions and deadlocks that we had to wipe our hands of it and just install mainline 2.6 (the system runs quite nicely now) and support that ought to be in the dictionary next to "worthless". It's good if you have problems like Q: The computer doesn't turn on A: Have you looked to see if it's plugged in? or Q: I forgot the root password. A: Try booting with a rescue disk But if you're unlucky enough to have kernel problems with RH (and I've had them on every RH distribution from kernel 2.2 to kernel 2.4) you're SOL. I've had great experiences with Fedora and am optimistic about RHEL 4, but I've been burned bad enough I just might install Solaris 10 on the next batch of servers I'm getting. Perhaps RH could spend some of the money that it's not spending on quality assurance and support and buy a decoder license and put an end to this nonsense. (Granted, I don't see a 'one-time' licensing fee for the encoder and the encoder licensing really does look stiff.) From arjanv at redhat.com Mon Feb 14 14:28:22 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 14 Feb 2005 09:28:22 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> Message-ID: <1108391302.5994.1.camel@localhost.localdomain> On Mon, 2005-02-14 at 09:14 -0500, Paul A. Houle wrote: > On Mon, 14 Feb 2005 11:58:26 +0100, Iago Rubio > wrote: > > > Feel free to buy an MP3 decoder license and donate it to rh. > > http://www.mp3licensing.com/help/developer.html#1 > > http://www.iis.fraunhofer.de/amm/legal/index.html > > http://www.mp3licensing.com/royalty/index.html > > > > That's insane. > > The decoder license is $60,000. What's that? The revenue RH gets from > Perhaps RH could spend some of the money that it's not spending on > quality assurance and support and buy a decoder license and put an end to > this nonsense. (Granted, I don't see a 'one-time' licensing fee for the > encoder and the encoder licensing really does look stiff.) it's worse actually. If RH coughed up the $60k we still can't ship it, since all MP3 decoders are GPL licensed. And the GPL doesn't actually allow you to ship code only YOU have a patent license for; you need a patent license for everyone and every possible derived work of that code..... which the licensing guys aren't actually providing. -------------- next part -------------- A 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 richardl at redhat.com Mon Feb 14 14:31:09 2005 From: richardl at redhat.com (Richard Li) Date: Mon, 14 Feb 2005 09:31:09 -0500 Subject: A tale of two bugzillas In-Reply-To: <5cf776b8050212174267a7458a@mail.gmail.com> References: <1107956832.8636.27.camel@Madison.badger.com> <1107964024.5706.12.camel@bree.local.net> <420A5223.3040002@silverorange.com> <5cf776b8050212174267a7458a@mail.gmail.com> Message-ID: <4210B62D.4030300@redhat.com> Thanks, we'll get it fixed. BTW, there is a "Bugzilla" product inside Bugzilla where you can file bugs ;-). mbneto wrote: >Looks great indeed. > >As a suggestion, if you reach the guy, remind him/her to add a > to the template. > >- mb > > >On Wed, 09 Feb 2005 14:10:43 -0400, Steven Garrity > wrote: > > >>Jeremy Katz wrote: >> >> >>>On Wed, 2005-02-09 at 08:47 -0500, Toshio wrote: >>> >>> >>>>Are there any substantive differences between bugzilla.redhat.com and >>>>bugzilla.redhat.com/beta? In particular, it looks like they are views >>>>of the same data so it should be okay to enter information into either >>>>one? >>>> >>>> >>>It's the same database. /beta is the current devel one (and a lot nicer >>>in a lot of ways) and should be becoming the main interface "real soon >>>now" >>> >>> >>Who has been doing the visual/UI customization in the new beta Bugzilla? >>It looks great. I'd love to see if we could get this kind of >>customization and integration into the Mozilla.org style for >>bugzilla.mozilla.org >> >>Thanks, >>Steven Garrity >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> >> > > > From pbruna at linuxcenterla.com Mon Feb 14 14:36:58 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Mon, 14 Feb 2005 11:36:58 -0300 Subject: resize2fs Message-ID: <1108391818.2934.0.camel@p.linuxcenter.cl> where goes resize2fs, i can't find anywhere -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 4834041 -------------- next part -------------- A 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 Mon Feb 14 14:38:21 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 14 Feb 2005 15:38:21 +0100 Subject: refactoring rc.sysinit In-Reply-To: <20050211202204.GB18471@nostromo.devel.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> <20050211202204.GB18471@nostromo.devel.redhat.com> Message-ID: <1108391901.5252.22.camel@wombat.tiptoe.de> On Fri, 2005-02-11 at 15:22 -0500, Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: > > In the past, I found myself in some situations where I would have loved > > to do things before or after a certain stage in rc.sysinit. How things > > were, I had to change the file itself which either made me retrofit > > these changes to a new rc.sysinit or lead to surprises when updating > > initscripts. > > Got example usage cases? I'm just skeptical of making things more > complicated and slower if the only usage cases are theoretical. Oh, it's been quite a while and my memories in that area are sketchy at best. I guess it's been stuff like devfs, wanting to have hdparm before fsck and such. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From alan at redhat.com Mon Feb 14 14:50:28 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 14 Feb 2005 09:50:28 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108391302.5994.1.camel@localhost.localdomain> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> Message-ID: <20050214145028.GB29552@devserv.devel.redhat.com> On Mon, Feb 14, 2005 at 09:28:22AM -0500, Arjan van de Ven wrote: > it's worse actually. If RH coughed up the $60k we still can't ship it, > since all MP3 decoders are GPL licensed. And the GPL doesn't actually > allow you to ship code only YOU have a patent license for; you need a > patent license for everyone and every possible derived work of that > code..... which the licensing guys aren't actually providing. Even if we shipped a BSD licensed one it would leave third parties in very awkward positions (eg folks hacking Fedora or making CDs). And if you want a non-free mp3 player then the current Realplayer uses gtk is a great deal better than the older one. From symbiont at berlios.de Mon Feb 14 14:50:14 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 14 Feb 2005 22:50:14 +0800 Subject: binary rpm package checking In-Reply-To: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> References: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> Message-ID: <200502142250.14559.symbiont@berlios.de> On Saturday 29 January 2005 22:21, Florian La Roche wrote: > I'd be interested to get feedback on what output is generated > for rpm addon expositories and non - Red Hat distributions > if the script generates warning messages. For http://python.org/pyvault, only unknown packager: PyVault Repository unknown vendor: PyVault when the --strict flag is used. thanks, -- -jeff From walters at redhat.com Mon Feb 14 15:11:27 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 14 Feb 2005 10:11:27 -0500 Subject: Fedora Core 4 test 1 freeze ahead In-Reply-To: <1108332965.6792.102.camel@localhost.localdomain> References: <1108332965.6792.102.camel@localhost.localdomain> Message-ID: <1108393888.3775.1.camel@nexus.verbum.private> On Mon, 2005-02-14 at 06:16 +0800, Colin Charles wrote: >SELinux brought up a system that was rather weird - ping, scp, >traceroute wouldn't work (error while loading shared libraries: cannot >restore segment prot after reloc: Permission denied). Bringing it up >with selinux=0 solved that for me quickly. Were there any avc denials in /var/log/messages? Please post problems to fedora-selinux-list and give us a chance rather than disable it entirely. From rahulsundaram at yahoo.co.in Mon Feb 14 16:34:02 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Mon, 14 Feb 2005 08:34:02 -0800 (PST) Subject: GFS In-Reply-To: <1108384150.2929.4.camel@p.linuxcenter.cl> Message-ID: <20050214163402.949.qmail@web8502.mail.in.yahoo.com> --- Patricio Bruna V wrote: > its gfs related in anyway with opengfs? yes it is. its a older fork when sistina converted gfs into a proprietary product. redhat has fixed that problem now > > i asking this because i want to know if > fedora(redhat) GFS support > OpenDLM it should ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From scottb at bxwa.com Mon Feb 14 17:25:43 2005 From: scottb at bxwa.com (Scott Becker) Date: Mon, 14 Feb 2005 09:25:43 -0800 Subject: Security Question Message-ID: <4210DF17.1070101@bxwa.com> Does anybody know which mailing list addresses security issues? Logwatch on my server reported this: apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138) using password: 1 Time(s) My apache account is active so I can su to it to administer postgresql databases accessable via php scripts. No password is set. It was my understanding that it would be impossible to log in except via su from root. Either I'm dead wrong or there's a security hole which needs fixed. thanks Scott Becker From pbruna at linuxcenterla.com Mon Feb 14 17:52:25 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Mon, 14 Feb 2005 14:52:25 -0300 Subject: where its resize2fs? Message-ID: <1108403545.2734.0.camel@p.linuxcenter.cl> i can find anywhere, was removed? if so, why? -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 4834041 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Mon Feb 14 18:03:17 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 14 Feb 2005 16:03:17 -0200 Subject: Current Dev Tree In-Reply-To: References: <15517.195.8.190.39.1108369755.squirrel@bananas.hopto.org> Message-ID: On Feb 14, 2005, Alexandre Oliva wrote: > On Feb 14, 2005, "Si Jones" wrote: >> X will not run and I get glic detected if I try to login on a shell >> using runlevel 3... Is there any fix I can do or should I rebuild my >> machine...? it a amd64. > Boot single-user, run prelink -u /lib64/libc-2.3.4.so, I meant /lib64/ld-2.3.4.so /lib64/tls/libc-2.3.4.so, sorry. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Mon Feb 14 18:08:30 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 14 Feb 2005 16:08:30 -0200 Subject: where its resize2fs? In-Reply-To: <1108403545.2734.0.camel@p.linuxcenter.cl> References: <1108403545.2734.0.camel@p.linuxcenter.cl> Message-ID: On Feb 14, 2005, Patricio Bruna V wrote: > i can find anywhere, was removed? if so, why? Posting once is supposed to be enough, even if it takes one or two hours to trigger a response :-) IIRC it was temporarily removed because it was found to modify the filesystem in such a way that a later fsck could destroy the contents of the filesystem. I think there's probably a bugzilla about it. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jspaleta at gmail.com Mon Feb 14 18:09:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Feb 2005 13:09:05 -0500 Subject: where its resize2fs? In-Reply-To: <1108403545.2734.0.camel@p.linuxcenter.cl> References: <1108403545.2734.0.camel@p.linuxcenter.cl> Message-ID: <604aa79105021410092c90ba38@mail.gmail.com> On Mon, 14 Feb 2005 14:52:25 -0300, Patricio Bruna V wrote: > i can find anywhere, was removed? if so, why? rpm -q --changelog e2fsprogs * Wed Feb 09 2005 Thomas Woerner 1.35-12 - rebuild * Wed Dec 22 2004 Stephen C. Tweedie - Disable offline resize for now: resize2fs is incompatible with online resize, and can result in corrupt filesystems. ext2online is available however. -jef From si at bananas.hopto.org Mon Feb 14 18:12:33 2005 From: si at bananas.hopto.org (Si Jones) Date: Mon, 14 Feb 2005 18:12:33 -0000 (GMT) Subject: Current Dev Tree In-Reply-To: References: <15517.195.8.190.39.1108369755.squirrel@bananas.hopto.org><1137.192.168.1.80.1108403114.squirrel@linux2> Message-ID: <1361.192.168.1.80.1108404753.squirrel@linux2> > Oops. That should have been: > > prelink -u /lib64/ld-2.3.4.so /lib64/tls/libc-2.3.4.so > > sorry. > >> Is there anything else I can try... maybe manually download the glibc >> lib >> and install in single user mode from cdrom. > Thanks for your help, I downloaded glibc and glibc-common and installed from cd... it seems to be letting me in now. Am doing another yum up to dev to see if any other problems pop up. Regards, Simon From strange at nsk.no-ip.org Mon Feb 14 18:21:24 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 14 Feb 2005 18:21:24 +0000 Subject: where its resize2fs? In-Reply-To: <604aa79105021410092c90ba38@mail.gmail.com> References: <1108403545.2734.0.camel@p.linuxcenter.cl> <604aa79105021410092c90ba38@mail.gmail.com> Message-ID: <20050214182124.GC2719@nsk.no-ip.org> On Mon, Feb 14, 2005 at 01:09:05PM -0500, Jeff Spaleta wrote: > On Mon, 14 Feb 2005 14:52:25 -0300, Patricio Bruna V > wrote: > > i can find anywhere, was removed? if so, why? > > rpm -q --changelog e2fsprogs > > * Wed Feb 09 2005 Thomas Woerner 1.35-12 > - rebuild > > * Wed Dec 22 2004 Stephen C. Tweedie > - Disable offline resize for now: resize2fs is incompatible with > online resize, and can result in corrupt filesystems. > > > ext2online is available however. I'm still waiting for an answer to my question "ext2resize vs resize2fs" on fedora-test-list @ 05/02/01. So, in this case, would ext2resize work better than resize2fs? Regards, Luciano Rocha From mattdm at mattdm.org Mon Feb 14 18:23:11 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 14 Feb 2005 13:23:11 -0500 Subject: Security Question In-Reply-To: <4210DF17.1070101@bxwa.com> References: <4210DF17.1070101@bxwa.com> Message-ID: <20050214182311.GA10713@jadzia.bu.edu> On Mon, Feb 14, 2005 at 09:25:43AM -0800, Scott Becker wrote: > Does anybody know which mailing list addresses security issues? fedora-list is best for this in general. But there is a "-devel" issue here..... > Logwatch on my server reported this: > apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138) using > password: 1 Time(s) > My apache account is active so I can su to it to administer postgresql > databases accessable via php scripts. No password is set. It was my > understanding that it would be impossible to log in except via su from > root. Either I'm dead wrong or there's a security hole which needs fixed. I think the problem here is that you're dead wrong. If no password is set and the account isn't locked, anyone can log in. Make sure the account is locked. For this reason, I apply the following patch to authconfig, to make the default configuration disallow logins with null passwords. I think it'd be a good idea to make this be the default, in fact. People who really want empty passwords should have to do this to themselves. --- ../authconfig-4.1.6.orig/authinfo.c Wed Aug 29 14:26:40 2001 +++ ./authinfo.c Wed Aug 29 14:29:46 2001 @@ -2061,9 +2061,7 @@ static const char *argv_unix_auth[] = { "likeauth", - "nullok", NULL, }; static const char *argv_unix_password[] = { - "nullok", "use_authtok", NULL, -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From notting at redhat.com Mon Feb 14 18:28:01 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Feb 2005 13:28:01 -0500 Subject: alsa-oss got lost? In-Reply-To: References: Message-ID: <20050214182801.GA13353@nostromo.devel.redhat.com> Mike Hearn (mike at navi.cx) said: > According to this post from Matthias Saou: > > https://www.redhat.com/archives/fedora-extras-commits/2004-November/msg00064.html > > Alsa-oss (aoss) is a part of Fedora Core 3. But it seems not to be, or at > least I cannot find it - in fact, I can't find an RPM of it anywhere. No, this wasn't put in FC3. Bill From fedora-devel at camperquake.de Mon Feb 14 18:28:57 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 14 Feb 2005 19:28:57 +0100 Subject: Security Question In-Reply-To: <4210DF17.1070101@bxwa.com> References: <4210DF17.1070101@bxwa.com> Message-ID: <20050214192857.657d4227@nausicaa.camperquake.de> Hi. Scott Becker wrote: > My apache account is active so I can su to it to administer postgresql > databases accessable via php scripts. You do not need a password for that, or change anything about the account. "sudo -u apache" (as normal user) or just "su -m apache" (as root) ought to do the job. -- "Your reality, sir, is lies and balderdash and I am delighted to say that I have no grasp of it whatsoever." -- Baron Munchausen From strange at nsk.no-ip.org Mon Feb 14 18:35:01 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 14 Feb 2005 18:35:01 +0000 Subject: Security Question In-Reply-To: <20050214192857.657d4227@nausicaa.camperquake.de> References: <4210DF17.1070101@bxwa.com> <20050214192857.657d4227@nausicaa.camperquake.de> Message-ID: <20050214183501.GD2719@nsk.no-ip.org> On Mon, Feb 14, 2005 at 07:28:57PM +0100, Ralf Ertzinger wrote: > Hi. > > Scott Becker wrote: > > > My apache account is active so I can su to it to administer postgresql > > databases accessable via php scripts. > > You do not need a password for that, or change anything about the > account. > > "sudo -u apache" (as normal user) or just "su -m apache" (as root) ought > to do the job. Or just psql -U apache. And login with empty passwords can be disabled by removing nullok from /etc/pam.d/system-auth. > > -- > "Your reality, sir, is lies and balderdash and I am delighted to say > that I have no grasp of it whatsoever." -- Baron Munchausen > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- 4/11 From fedora at leemhuis.info Mon Feb 14 18:44:37 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Feb 2005 19:44:37 +0100 Subject: alsa-oss got lost? In-Reply-To: <20050214182801.GA13353@nostromo.devel.redhat.com> References: <20050214182801.GA13353@nostromo.devel.redhat.com> Message-ID: <1108406677.6112.17.camel@localhost.localdomain> Am Montag, den 14.02.2005, 13:28 -0500 schrieb Bill Nottingham: > Mike Hearn (mike at navi.cx) said: > > According to this post from Matthias Saou: > > > > https://www.redhat.com/archives/fedora-extras-commits/2004-November/msg00064.html > > > > Alsa-oss (aoss) is a part of Fedora Core 3. But it seems not to be, or at > > least I cannot find it - in fact, I can't find an RPM of it anywhere. > > No, this wasn't put in FC3. Well, does anyone need it? If really yes I'll maybe put it back and update it. -- Thorsten Leemhuis From bruno at wolff.to Mon Feb 14 19:04:57 2005 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 14 Feb 2005 13:04:57 -0600 Subject: Security Question In-Reply-To: <20050214183501.GD2719@nsk.no-ip.org> References: <4210DF17.1070101@bxwa.com> <20050214192857.657d4227@nausicaa.camperquake.de> <20050214183501.GD2719@nsk.no-ip.org> Message-ID: <20050214190457.GA6984@wolff.to> On Mon, Feb 14, 2005 at 18:35:01 +0000, Luciano Miguel Ferreira Rocha wrote: > > Or just psql -U apache. If you go that route, you can set up ident authentication for postgres so that this command will work from your normal user account, without having to switch to root first or supply an additional password. From scottb at bxwa.com Mon Feb 14 18:57:03 2005 From: scottb at bxwa.com (Scott Becker) Date: Mon, 14 Feb 2005 10:57:03 -0800 Subject: Security Question In-Reply-To: <20050214192857.657d4227@nausicaa.camperquake.de> References: <4210DF17.1070101@bxwa.com> <20050214192857.657d4227@nausicaa.camperquake.de> Message-ID: <4210F47F.1080600@bxwa.com> I started with the default apache user and ran the following commands: #bring up apache account- mkdir /home/apache cp /etc/skel/.* /home/apache chown -R apache: /home/apache usermod -d /home/apache apache usermod -s /bin/bash apache This way I can access it with a simple 'su apache' command ran as root and there's a home directory to store the .psql_history file so the command history is saved across sessions. I fear that by setting the shell with 'usermod -s /bin/bash apache' I've opened a can of worms. I just set a password on the account to prevent any more logins but if there's a security hole it would be nice to fix it and if not I would like to know how they logged in and understand the process. I tried (just before setting the password) to login hitting enter for the password and I couldn't get in. Luciano Miguel Ferreira Rocha wrote: >And login with empty passwords can be disabled by removing nullok from >/etc/pam.d/system-auth. I found nullok twice in the file. Perhaps I couldn't get in on my test because PuTTY doesn't pass null. I guess I shall always set a password from now on. thanks all scottb Ralf Ertzinger wrote: >Hi. > >Scott Becker wrote: > > > >>My apache account is active so I can su to it to administer postgresql >>databases accessable via php scripts. >> >> > >You do not need a password for that, or change anything about the >account. > >"sudo -u apache" (as normal user) or just "su -m apache" (as root) ought >to do the job. > > > From brugolsky at telemetry-investments.com Mon Feb 14 19:09:41 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Mon, 14 Feb 2005 14:09:41 -0500 Subject: where its resize2fs? In-Reply-To: <20050214182124.GC2719@nsk.no-ip.org> References: <1108403545.2734.0.camel@p.linuxcenter.cl> <604aa79105021410092c90ba38@mail.gmail.com> <20050214182124.GC2719@nsk.no-ip.org> Message-ID: <20050214190941.GA24031@ti64.telemetry-investments.com> On Mon, Feb 14, 2005 at 06:21:24PM +0000, Luciano Miguel Ferreira Rocha wrote: > I'm still waiting for an answer to my question "ext2resize vs resize2fs" > on fedora-test-list @ 05/02/01. > > So, in this case, would ext2resize work better than resize2fs? See http://marc.theaimsgroup.com/?w=2&r=1&s=e2fsck+1.36-rc1&q=t Regards, Bill Rugolsky From buildsys at redhat.com Mon Feb 14 21:11:32 2005 From: buildsys at redhat.com (Build System) Date: Mon, 14 Feb 2005 16:11:32 -0500 Subject: rawhide report: 20050214 changes Message-ID: <200502142111.j1ELBWDW028051@porkchop.devel.redhat.com> From buildsys at redhat.com Mon Feb 14 21:12:09 2005 From: buildsys at redhat.com (Build System) Date: Mon, 14 Feb 2005 16:12:09 -0500 Subject: rawhide report: 20050214 changes Message-ID: <200502142112.j1ELC9E1028067@porkchop.devel.redhat.com> From buildsys at redhat.com Mon Feb 14 21:12:45 2005 From: buildsys at redhat.com (Build System) Date: Mon, 14 Feb 2005 16:12:45 -0500 Subject: rawhide report: 20050214 changes Message-ID: <200502142112.j1ELCjif028086@porkchop.devel.redhat.com> Updated Packages: anaconda-10.2.0.19-1 -------------------- * Sat Feb 12 2005 Jeremy Katz - 10.2.0.19-1 - fix x86_64 installs for bad urlgrabber import - Fix traceback with no %post (clumens) - Put hostname in the text entry (clumens, #132826) automake-1.9.5-1 ---------------- * Sun Feb 13 2005 Florian La Roche - 1.9.5 bug-fix release curl-7.13.0-1 ------------- * Sun Feb 13 2005 Florian La Roche - 7.13.0 emacs-21.3-22 ------------- * Mon Feb 14 2005 Jens Petersen - 21.3-22 - use prereq instead of contexts for common script requirements (Axel Thimm, 147791) - move emacs.png from common to main package * Fri Feb 04 2005 Jens Petersen - 21.3-21 - fix CAN-2005-0100 movemail vulnerability with movemail-CAN-2005-0100.patch (Max Vozeler, 146701) gcc-3.4.3-19 ------------ * Thu Feb 10 2005 Jakub Jelinek 3.4.3-19 - use crtendS.o instead of crtend.o on ppc -pie - use execv instead of execl in libgcc_post_upgrade to avoid bringing in malloc and friends into the statically linked binary (which increases its size ~ 10 times) * Thu Feb 10 2005 Jakub Jelinek 3.4.3-18 - update from gcc-3_4-branch - PRs c++/18370, c++/19366, c++/19499, c++/19733, libstdc++/19642, middle-end/19775, target/15384, target/16201, target/17771, target/19293, target/19329, target/19393, target/19803 - fix c++filt/__cxa_demangle segfault on invalidly mangled names generated by G++ 3.4 (#145781, PR c++/16240) - make sure libgcj.so is not PT_GNU_STACK RWE - disallow dlopening libgnat-3*.so, as it must be PT_GNU_STACK RWE due to its extensive use of trampolines - fix PRs c++/18838 and c++/19367 (Mark Mitchell, backported by Alexandro Oliva) - fix ICE in fold_convert (Andrew Pinski, #146385, PR c++/19666) * Tue Jan 25 2005 Jakub Jelinek 3.4.3-17 - update from gcc-3_4-branch - PRs c++/19258, c++/19375, libstdc++/19510, other/16403, rtl-optimization/19296, target/16304, target/19548 - fix PR rtl-optimization/19579 - remove Java *.a libraries, issue error for gcj -static (#145829) glibc-2.3.4-10 -------------- * Sat Feb 12 2005 Jakub Jelinek 2.3.4-10 - hopefully fix interaction with prelink (#147655) * Fri Feb 11 2005 Jakub Jelinek 2.3.4-9 - update from CVS - bi-arch (BZ#715) * Fri Feb 11 2005 Jakub Jelinek 2.3.4-8 - update from CVS - bi-arch (BZ#632) - fix libdl on s390 and maybe other platforms - fix initstate{,_r} (BZ#710) - fix generation (BZ#157) - define CMSPAR in bits/termios.h (#147533) kde-i18n-1:3.3.2-1 ------------------ * Sat Feb 12 2005 Than Ngo 1:3.3.2-1 - add Hindi, Tamil, Punjabi, Bengali translation kdegraphics-7:3.3.2-0.4 ----------------------- * Sat Feb 12 2005 Than Ngo 7:3.3.2-0.4 - backport from CVS for working with qt-immodule kdelibs-6:3.3.2-0.7 ------------------- * Sat Feb 12 2005 Than Ngo 6:3.3.2-0.7 - backport CVS patch, cleanup InputMethod kernel-2.6.10-1.1141_FC4 ------------------------ * Sun Feb 13 2005 Dave Jones - 2.6.11-rc4-bk1 * Sat Feb 12 2005 Dave Jones - 2.6.11-rc4 * Fri Feb 11 2005 Dave Jones - 2.6.11-rc3-bk8 koffice-4:1.3.5-3 ----------------- * Sat Feb 12 2005 Than Ngo 4:1.3.5-3 - backport from CVS for working with qt-immodule libgconf-java-2.9.91.1-1 ------------------------ * Sat Feb 12 2005 Thomas Fitzsimmons - 2.9.91.1-1 - Import libgconf-java 2.9.91.1. libglade-java-2.9.91.1-1 ------------------------ * Sat Feb 12 2005 Thomas Fitzsimmons - 2.9.91.1-1 - Import libglade-java 2.9.91.1. libgnome-java-2.9.91.1-1 ------------------------ * Sat Feb 12 2005 Thomas Fitzsimmons - 2.9.91.1-1 - Import libgnome-java 2.9.91.1. libgtk-java-2.5.91.1-1 ---------------------- * Sat Feb 12 2005 Thomas Fitzsimmons - 2.5.91.1-1 - Import libgtk-java 2.5.91.1. libtool-1.5.14.multilib2-3.4.3 ------------------------------ * Sun Feb 13 2005 Florian La Roche - 1.5.14 bugfix release openoffice.org-1.1.3-6.7.0 -------------------------- * Sat Feb 12 2005 Dan Williams - 1.1.3-6 - Revert _another_ Novell patch that caused individual programs not to launch pcmcia-cs-3.2.8-4.7 ------------------- * Sun Feb 13 2005 Dave Jones - Fix up ranges on RadeonIGP workaround. (Maybe fixes #80584) perl-RPM2-0.66-8 ---------------- * Sun Feb 13 2005 Florian La Roche - rebuild rcs-5.7-27 ---------- * Sun Feb 13 2005 Florian La Roche - add spec change from #144485 rpm-4.4.1-2 ----------- * Sun Feb 13 2005 Jeff Johnson 4.4.1-1 - don't classify files in /dev (#146623). - don't build with sqlite3 if is missing. * Sat Feb 12 2005 Jeff Johnson 4.4.1-0.24 - zlib: uniqify certain symbols to prevent name space pollution. - macosx: include so that python sees the u_char typedef. - macosx: change to --prefix=/usr rather than /opt/local. - use waitpid rather than SIGCHLD reaper. - rip out DB_PRIVATE revert if not NPTL, it's not the right thing to do. rpmdb-fedora-1:4-0.20050214 --------------------------- slang-1.4.9-15 -------------- * Mon Feb 14 2005 Adrian Havill - rebuilt * Sun Aug 01 2004 Alan Cox - fixed requires so slang-devel pulls in libtermcap-devel (#125299) * Tue Jun 15 2004 Elliot Lee - rebuilt tclx-8.3.5-5 ------------ * Sun Feb 13 2005 Jens Petersen - 8.3.5-5 - rebuild tix-1:8.1.4-99 -------------- * Sun Feb 13 2005 Jens Petersen - 1:8.1.4-99 - rebuilt ttcp-1.12-11 ------------ * Sun Feb 13 2005 Florian La Roche - add patch from #146012 vconfig-1.8-5 ------------- * Sun Feb 13 2005 Florian La Roche - remove kernel dep, kernel runtime deps should go into apps, #146151 vlock-1.3-17 ------------ * Mon Feb 14 2005 Adrian Havill - rebuilt From denis at poolshark.org Mon Feb 14 22:25:46 2005 From: denis at poolshark.org (Denis Leroy) Date: Mon, 14 Feb 2005 14:25:46 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050214145028.GB29552@devserv.devel.redhat.com> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> Message-ID: <4211256A.7020804@poolshark.org> An interesting quote from a SuSe forum: ---- The owners of the patent on MP3 decoding, the Fraunhofer Institute, usually enforce a license fee for software MP3 decoding. (Microsoft, Apple and anyone else who sells software that decodes MP3 files pay Fraunhofer for the privilege). Fraunhofer have previously made a statement that they will not enforce their licensing scheme against distributors of free software which decodes MP3 files. This is not legally binding nor is it written down anywhere. Mandrake and SuSE consider that to be enough to go on, and include MP3 decoding without paying Fraunhofer. Red Hat have decided it's not a strong enough guarantee, so they don't include MP3 decoding. It's a more conservative but safer stance. ---- So why couldn't the Fedora project ask Fraunhofer (a german company, btw, so all this talk about 'Mandrake is a french company and not affected by patent law' seems rather weak) for permission ? Alan Cox wrote: > On Mon, Feb 14, 2005 at 09:28:22AM -0500, Arjan van de Ven wrote: > >>it's worse actually. If RH coughed up the $60k we still can't ship it, >>since all MP3 decoders are GPL licensed. And the GPL doesn't actually >>allow you to ship code only YOU have a patent license for; you need a >>patent license for everyone and every possible derived work of that >>code..... which the licensing guys aren't actually providing. > > > Even if we shipped a BSD licensed one it would leave third parties in very > awkward positions (eg folks hacking Fedora or making CDs). And if you want > a non-free mp3 player then the current Realplayer uses gtk is a great deal > better than the older one. > From rahulsundaram at yahoo.co.in Mon Feb 14 22:29:14 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Mon, 14 Feb 2005 14:29:14 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <4211256A.7020804@poolshark.org> Message-ID: <20050214222914.81678.qmail@web8510.mail.in.yahoo.com> Hi > So why couldn't the Fedora project ask Fraunhofer (a > german company, > btw, so all this talk about 'Mandrake is a french > company and not > affected by patent law' seems rather weak) for > permission ? > why is the statement that a french company is not affected by software patents enforced only in the US a weak argument? If permission is to be obtained it should be in a legally binding non discriminatory way. I have a feeling that its not going to happen. ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From shiva at sewingwitch.com Mon Feb 14 22:38:03 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 14 Feb 2005 14:38:03 -0800 Subject: mod_bt package In-Reply-To: <20050214105457.GA24808@redhat.com> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> <098F540093982AB8186FEDF0@[10.0.0.4]> <20050214105457.GA24808@redhat.com> Message-ID: <9481E5A10504BB28C58567A0@[10.0.0.4]> --On Monday, February 14, 2005 10:54 AM +0000 Joe Orton wrote: > What versions of php and httpd are you using? You shouldn't get this > problem with FC3 or Raw Hide. FC2, so: php-devel-4.3.10-2.4 httpd-devel-2.0.51-2.9 Which package changed its definitions to comply with the other? From feliciano.matias at free.fr Mon Feb 14 23:02:40 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 15 Feb 2005 00:02:40 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <4211256A.7020804@poolshark.org> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> Message-ID: <1108422161.32171.4.camel@one.myworld> Le lundi 14 f?vrier 2005 ? 14:25 -0800, Denis Leroy a ?crit : > So why couldn't the Fedora project ask Fraunhofer (a german company, > btw, so all this talk about 'Mandrake is a french company and not > affected by patent law' seems rather weak) for permission ? > http://fr2.rpmfind.net/linux/Mandrake/10.1/i586/LICENSE.txt Warning: Free Software may not necessarily be patent free, and some Free Software included may be covered by patents in your country. For example, the MP3 decoders included may require a licence for further usage (see http://www.mp3licensing.com for more details). If you are unsure if a patent may be applicable to you, check your local laws. -------------- 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 dag at wieers.com Tue Feb 15 01:16:40 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 15 Feb 2005 02:16:40 +0100 (CET) Subject: binary rpm package checking In-Reply-To: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> References: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> Message-ID: On Sat, 29 Jan 2005, Florian La Roche wrote: > This is a start to check binary rpm packages for consistency. > Right now mostly the rpm header is checked to get a feeling > how much "strange" binary rpm packages might be out there. > It has two modes of checking, one for the current Fedora Development > tree with more strict checks and a more relaxed one that should > work for all existing rpm packages, also other distributions. > > I'd be interested to get feedback on what output is generated > for rpm addon expositories and non - Red Hat distributions > if the script generates warning messages. > At least for Fedora Core only very few rpm tags are actually > used in the rpm header. > > Examples usage: > ./pyrpm.py --strict /mirror/fedora/development/i386/Fedora/RPMS/*.rpm > > Checking all rpms: > locate .rpm | xargs ./pyrpm.py > find /mirror/linux -name "*.rpm" -type f -print0 2>/dev/null | > xargs -0 ./pyrpm.py Hi Florian, I've ran it on about 28000 packages, mostly unknown tag values: unknown distribution: Dag Apt Repository for Red Hat 7.3 unknown packager: Dries Verachtert unknown vendor: Dag Apt Repository, http://dag.wieers.com/apt/ However it also triggered a problem: ValueError: amavisd-new-milter-2.2.0-2.0.rh8.test.i386.rpm: wrong data in rpm lead Traceback (most recent call last): File "./pyrpm.py", line 676, in ? verifyAllRpms() File "./pyrpm.py", line 657, in verifyAllRpms rpm = verifyRpm(a, legacy) File "./pyrpm.py", line 583, in verifyRpm if rpm.readHeader(): File "./pyrpm.py", line 308, in readHeader self.parseLead(leaddata) File "./pyrpm.py", line 110, in parseLead self.raiseErr("wrong data in rpm lead") File "./pyrpm.py", line 59, in raiseErr raise ValueError, "%s: %s" % (self.filename, err) on files like: perl-Tk-804.026-1.rhfc1.test.i386.rpm amavisd-new-2.2.0-2.0.rh8.test.i386.rpm xpde-0.4.0-1.1.fc2.test.i386.rpm Fortunately all of these have been renamed files where the repotag has been changed to 'test'. Something I frequently do after a package didn't go through QA but was still worth distributing. After a while, when it started with kernel-module packages, I got this: ValueError: kernel-module-ov511-2.25-0_2.4.20_20.9.dag.rh90.i686.rpm: unknown prog: ['/sbin/depmod', '-ae'] Traceback (most recent call last): File "./pyrpm.py", line 676, in ? verifyAllRpms() File "./pyrpm.py", line 663, in verifyAllRpms rrpm = RRpm(rpm) File "./pyrpm.py", line 509, in __init__ (self.post, self.postprog) = rpm.getScript("postin", "postinprog") File "./pyrpm.py", line 415, in getScript self.raiseErr("unknown prog: %s" % prog) File "./pyrpm.py", line 59, in raiseErr raise ValueError, "%s: %s" % (self.filename, err) These messages are printed for each package. The command I ran was: find /dar/packages/ -type f -name "*.rpm" | xargs -i ./pyrpm.py --strict '{}' \; | grep -vE 'unknown (packager|vendor|distribution)' | sort | uniq -c I ended it after a lot of these 'errors'. Is the traceback intentional ? Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From green at redhat.com Tue Feb 15 01:13:40 2005 From: green at redhat.com (Anthony Green) Date: Mon, 14 Feb 2005 17:13:40 -0800 Subject: The fedora-devel-java-list list Message-ID: <1108430021.5427.80.camel@localhost.localdomain> Hello, We've recently created a new mailing list called: fedora-devel-java-list at redhat.com. This is a mailing list for people interested in java related technologies on Fedora Core. There are many application/tools/runtime integration and packaging issues that, to date, have mostly been discussed in private mail, IRC or internal Red Hat mail. I hope that we will use this list to push the discussion out in the open and grow participation. Details on subscribing and the archives are here: http://www.redhat.com/mailman/listinfo/fedora-devel-java-list. Now, who can add this to http://fedora.redhat.com/participate/communicate/ ? AG From alan at redhat.com Tue Feb 15 02:31:34 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 14 Feb 2005 21:31:34 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <4211256A.7020804@poolshark.org> References: <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> Message-ID: <20050215023134.GC16980@devserv.devel.redhat.com> On Mon, Feb 14, 2005 at 02:25:46PM -0800, Denis Leroy wrote: > So why couldn't the Fedora project ask Fraunhofer (a german company, > btw, so all this talk about 'Mandrake is a french company and not > affected by patent law' seems rather weak) for permission ? Fedora is a free software project. Note that the Fraunhofer comment was about free (as in beer) not free as in price. So again we'd screw all the people who build things on Fedora or make CD images. Alan From rodd at clarkson.id.au Tue Feb 15 03:41:04 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 15 Feb 2005 14:41:04 +1100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050215023134.GC16980@devserv.devel.redhat.com> References: <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <20050215023134.GC16980@devserv.devel.redhat.com> Message-ID: <1108438864.6719.28.camel@localhost.localdomain> On Mon, 2005-02-14 at 21:31 -0500, Alan Cox wrote: >On Mon, Feb 14, 2005 at 02:25:46PM -0800, Denis Leroy wrote: >> So why couldn't the Fedora project ask Fraunhofer (a german company, >> btw, so all this talk about 'Mandrake is a french company and not >> affected by patent law' seems rather weak) for permission ? > >Fedora is a free software project. Note that the Fraunhofer comment was about >free (as in beer) not free as in price. So again we'd screw all the people who >build things on Fedora or make CD images. Okay, but this is the bit I struggle with in regard to the idea of a community process for Fedora Core. What I read your comments as saying is that give that Fedora Core is free (as in beer) then there is no problem with including it in Fedora Core. The problem lies in people using Fedora Core down-stream. Am I right? IF this is the case: This seems to be a sticking point in the community driven process for FC. In this case, software that could be included isn't because it might hinder some other group down-stream that wishes to benefit from the work in FC. Part of me says, "Who Cares, that's there problem" If RHEL want's to base off of FC then they might need to remove some aspects of it to meet their needs, but why should the community driven process be limited because RHEL wants FC to be just right for RHEL (instead of just right for FC users). Or why should FC care whether third parties (in some countries) who can download the ISO's and then charge per CD-ROM might be affected by the software included. I guess this is to some extent and issue of just how libre free FC is, but it also is an issue of the community process that FC should have. We need some method of including things that would be fine in FC, but not fine in say RHEL or when someone produces disks an sells them. Similar to extras I guess, but easy for FC users to just install, but also where down-stream users who might be affected by such software aren't required to rebuild to just supply onward. Or I might just be raving (mad) ;-] Rodd > >Alan > From n3npq at nc.rr.com Tue Feb 15 06:18:39 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 15 Feb 2005 01:18:39 -0500 Subject: The fedora-devel-java-list list In-Reply-To: <1108430021.5427.80.camel@localhost.localdomain> References: <1108430021.5427.80.camel@localhost.localdomain> Message-ID: <4211943F.1050901@nc.rr.com> Anthony Green wrote: >Hello, > >We've recently created a new mailing list called: > > fedora-devel-java-list at redhat.com. > >This is a mailing list for people interested in java related >technologies on Fedora Core. There are many application/tools/runtime >integration and packaging issues that, to date, have mostly been >discussed in private mail, IRC or internal Red Hat mail. I hope that we >will use this list to push the discussion out in the open and grow >participation. > >Details on subscribing and the archives are here: >http://www.redhat.com/mailman/listinfo/fedora-devel-java-list. > >Now, who can add this to >http://fedora.redhat.com/participate/communicate/ ? > > Shouldn't the list be called ? 73 de Jeff scampering merrily away From laroche at redhat.com Tue Feb 15 07:58:22 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 15 Feb 2005 08:58:22 +0100 Subject: [Rpm-devel] Re: binary rpm package checking In-Reply-To: References: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> Message-ID: <20050215075822.GA9784@dudweiler.stuttgart.redhat.com> Hello Dag, I've copied a newer version to http://people.redhat.com/laroche/pyrpm/ It can now also read the cpio data part of rpm packages and has several items cleaned up. I'd be interested to hear more feedback from python experts about possibly improvements. ;-) The "--strict" option should only be used for Fedora Core development branch. > I've ran it on about 28000 packages, mostly unknown tag values: > > unknown distribution: Dag Apt Repository for Red Hat 7.3 > unknown packager: Dries Verachtert > unknown vendor: Dag Apt Repository, http://dag.wieers.com/apt/ Yepp, content check for "--strict" not useful for non-FC-devel. > > However it also triggered a problem: > > ValueError: amavisd-new-milter-2.2.0-2.0.rh8.test.i386.rpm: wrong data in rpm lead > Traceback (most recent call last): > File "./pyrpm.py", line 676, in ? > verifyAllRpms() > File "./pyrpm.py", line 657, in verifyAllRpms > rpm = verifyRpm(a, legacy) > File "./pyrpm.py", line 583, in verifyRpm > if rpm.readHeader(): > File "./pyrpm.py", line 308, in readHeader > self.parseLead(leaddata) > File "./pyrpm.py", line 110, in parseLead > self.raiseErr("wrong data in rpm lead") > File "./pyrpm.py", line 59, in raiseErr > raise ValueError, "%s: %s" % (self.filename, err) > > on files like: > > perl-Tk-804.026-1.rhfc1.test.i386.rpm > amavisd-new-2.2.0-2.0.rh8.test.i386.rpm > xpde-0.4.0-1.1.fc2.test.i386.rpm > > Fortunately all of these have been renamed files where the repotag has > been changed to 'test'. Something I frequently do after a package didn't > go through QA but was still worth distributing. Should also not be happen without the "--strict" option. > After a while, when it started with kernel-module packages, I got this: > > ValueError: kernel-module-ov511-2.25-0_2.4.20_20.9.dag.rh90.i686.rpm: unknown prog: ['/sbin/depmod', '-ae'] > Traceback (most recent call last): > File "./pyrpm.py", line 676, in ? > verifyAllRpms() > File "./pyrpm.py", line 663, in verifyAllRpms > rrpm = RRpm(rpm) > File "./pyrpm.py", line 509, in __init__ > (self.post, self.postprog) = rpm.getScript("postin", "postinprog") > File "./pyrpm.py", line 415, in getScript > self.raiseErr("unknown prog: %s" % prog) > File "./pyrpm.py", line 59, in raiseErr > raise ValueError, "%s: %s" % (self.filename, err) > > These messages are printed for each package. The command I ran was: > > find /dar/packages/ -type f -name "*.rpm" | xargs -i ./pyrpm.py --strict '{}' \; | grep -vE 'unknown (packager|vendor|distribution)' | sort | uniq -c > > I ended it after a lot of these 'errors'. Is the traceback intentional ? I should change the tracebacks into errors only, so that you can still enable this option and look at the items we would not like to have in FC-devel. Thanks for running this test. Looks like the rpm parser is stable enough for existing packages and we mostly deal with the "noise" the parser is also checking right now. greetings, Florian La Roche From marcel at mesa.nl Tue Feb 15 07:41:54 2005 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Tue, 15 Feb 2005 08:41:54 +0100 Subject: rawhide report: 20050214 changes In-Reply-To: <200502142112.j1ELCjif028086@porkchop.devel.redhat.com> References: <200502142112.j1ELCjif028086@porkchop.devel.redhat.com> Message-ID: <20050215074154.GA22884@joshua.mesa.nl> On Mon, Feb 14, 2005 at 04:12:45PM -0500, Build System wrote: > > > > Updated Packages: > > > rpmdb-fedora-1:4-0.20050214 > --------------------------- The rpmdb rpm seems to be missing for a couple of days now... -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From n3npq at nc.rr.com Tue Feb 15 07:47:48 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 15 Feb 2005 02:47:48 -0500 Subject: [Rpm-devel] Re: binary rpm package checking In-Reply-To: <20050215075822.GA9784@dudweiler.stuttgart.redhat.com> References: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> <20050215075822.GA9784@dudweiler.stuttgart.redhat.com> Message-ID: <4211A924.1020602@nc.rr.com> Florian La Roche wrote: >Hello Dag, > >I've copied a newer version to http://people.redhat.com/laroche/pyrpm/ >It can now also read the cpio data part of rpm packages and has several >items cleaned up. I'd be interested to hear more feedback from python >experts about possibly improvements. ;-) > > If python rpm experts is your goal, try the rpm-python list please. >The "--strict" option should only be used for Fedora Core development >branch. > > > >>I've ran it on about 28000 packages, mostly unknown tag values: >> >> unknown distribution: Dag Apt Repository for Red Hat 7.3 >> unknown packager: Dries Verachtert >> unknown vendor: Dag Apt Repository, http://dag.wieers.com/apt/ >> >> > >Yepp, content check for "--strict" not useful for non-FC-devel. > > > >>However it also triggered a problem: >> >> ValueError: amavisd-new-milter-2.2.0-2.0.rh8.test.i386.rpm: wrong data in rpm lead >> Traceback (most recent call last): >> File "./pyrpm.py", line 676, in ? >> verifyAllRpms() >> File "./pyrpm.py", line 657, in verifyAllRpms >> rpm = verifyRpm(a, legacy) >> File "./pyrpm.py", line 583, in verifyRpm >> if rpm.readHeader(): >> File "./pyrpm.py", line 308, in readHeader >> self.parseLead(leaddata) >> File "./pyrpm.py", line 110, in parseLead >> self.raiseErr("wrong data in rpm lead") >> File "./pyrpm.py", line 59, in raiseErr >> raise ValueError, "%s: %s" % (self.filename, err) >> >>on files like: >> >> perl-Tk-804.026-1.rhfc1.test.i386.rpm >> amavisd-new-2.2.0-2.0.rh8.test.i386.rpm >> xpde-0.4.0-1.1.fc2.test.i386.rpm >> >>Fortunately all of these have been renamed files where the repotag has >>been changed to 'test'. Something I frequently do after a package didn't >>go through QA but was still worth distributing. >> >> > >Should also not be happen without the "--strict" option. > > > >>After a while, when it started with kernel-module packages, I got this: >> >> ValueError: kernel-module-ov511-2.25-0_2.4.20_20.9.dag.rh90.i686.rpm: unknown prog: ['/sbin/depmod', '-ae'] >> Traceback (most recent call last): >> File "./pyrpm.py", line 676, in ? >> verifyAllRpms() >> File "./pyrpm.py", line 663, in verifyAllRpms >> rrpm = RRpm(rpm) >> File "./pyrpm.py", line 509, in __init__ >> (self.post, self.postprog) = rpm.getScript("postin", "postinprog") >> File "./pyrpm.py", line 415, in getScript >> self.raiseErr("unknown prog: %s" % prog) >> File "./pyrpm.py", line 59, in raiseErr >> raise ValueError, "%s: %s" % (self.filename, err) >> >>These messages are printed for each package. The command I ran was: >> >> find /dar/packages/ -type f -name "*.rpm" | xargs -i ./pyrpm.py --strict '{}' \; | grep -vE 'unknown (packager|vendor|distribution)' | sort | uniq -c >> >>I ended it after a lot of these 'errors'. Is the traceback intentional ? >> >> > >I should change the tracebacks into errors only, so that you can still >enable this option and look at the items we would not like to have in >FC-devel. > >Thanks for running this test. Looks like the rpm parser is stable enough >for existing packages and we mostly deal with the "noise" the parser is >also checking right now. > > OK, so you can read *.rpm format in native python. Good, even though you are not verifying signatures or digests of what you are reading. At the content level, you are attempting explicit enums with limited value sets. You can do that, but if an explicit enum for certain tags is the goal, well, that is more easily arranged in rpmbuild rather than vetting every *.rpm package built in the wild. At the semantic level, pyrpm is not even close to extracting and verifying immutable header regions, nor the sort properties of tag value sets. And existing packages are really easy to vet. Try pkgs produced by rpm-3.0.4 and earlier for some real fun. %description and %verifyscript, exercise left for pyrpm.py. Have fun! 73 de Jeff From stephan.helas at e-7.com Tue Feb 15 09:19:56 2005 From: stephan.helas at e-7.com (stephan.helas at e-7.com) Date: Tue, 15 Feb 2005 10:19:56 +0100 Subject: Adaptec ASR-2010S, supported by i2o_block on FC3 Message-ID: <96849388D2102F40AEF198798540F2E105E503@gt1mail1.gt.da-ag.local> Hello, i got problems to install FC3 on server FSC RX300 SN because of the scsi raid controler. this raid controler can managed by i2o_block. but the modul don't get loaded automaticly on boot cd (boot.iso). FC1 with modul dpt_i2o works. if i load modul manualy (anaconda ask for it) the controller gets loaded and i can install. after extracting initrd.img on boot.iso i realized that i2o_block and i2o_core are included in kernel. so i don't understand why this controler isn't loaded automaticly. i use kickstart for installation and so i need an option to load this modul during installation. is there an grub option to load this modul on boot time? or how can i make my own boot.iso or boot floppy with customized kernel (compiled in Modul i2o_block)? raid controler on fedora core1: lspci got: 03:08.0 RAID bus controller: Distributed Processing Technology SmartRAID V Controller (rev 01) lsmod got: dpt_i2o 29568 7 sd_mod 13388 14 scsi_mod 116136 2 [dpt_i2o sd_mod] dmesg |grep scsi got: scsi0 : Vendor: Adaptec Model: 2010S FW:FS13 seems to be an: Adaptec ASR-2010S, supported by i2o_block (http://i2o.shadowconnect.com/index.php). Best Regards Stephan Helas From nicolas.mailhot at laposte.net Tue Feb 15 10:05:30 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 15 Feb 2005 11:05:30 +0100 (CET) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108438864.6719.28.camel@localhost.localdomain> References: <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <20050215023134.GC16980@devserv.devel.redhat.com> <1108438864.6719.28.camel@localhost.localdomain> Message-ID: <2551.212.157.164.129.1108461930.squirrel@rousalka.dyndns.org> On Mar 15 f?vrier 2005 4:41, Rodd Clarkson a ?crit : > On Mon, 2005-02-14 at 21:31 -0500, Alan Cox wrote: >>On Mon, Feb 14, 2005 at 02:25:46PM -0800, Denis Leroy wrote: >>> So why couldn't the Fedora project ask Fraunhofer (a german company, >>> btw, so all this talk about 'Mandrake is a french company and not >>> affected by patent law' seems rather weak) for permission ? >> >>Fedora is a free software project. Note that the Fraunhofer comment was >> about >>free (as in beer) not free as in price. So again we'd screw all the >> people who >>build things on Fedora or make CD images. > > Okay, but this is the bit I struggle with in regard to the idea of a > community process for Fedora Core. [...] > Or why should FC care whether third parties (in some countries) who can > download the ISO's and then charge per CD-ROM might be affected by the > software included. 1. FC is not the ultimate source of all its components - why should upstream projects care about FC if it doesn't care about its downstream ? 2. I think you severily underestimate the contributions of downstream projects - if you play nice with downstream downstream will play nice with you and contribute developpers/packages to FC. A lot of the people contributing things for FC extras now come from what can be considered downstream projects : livna, dag, aurora... Getting the relations right with upstream and downstream is one of the main points of Fedora - this is what RH was about to lose when RHEL was launched. Regards, -- Nicolas Mailhot From rodd at clarkson.id.au Tue Feb 15 10:48:42 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 15 Feb 2005 21:48:42 +1100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <2551.212.157.164.129.1108461930.squirrel@rousalka.dyndns.org> References: <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <20050215023134.GC16980@devserv.devel.redhat.com> <1108438864.6719.28.camel@localhost.localdomain> <2551.212.157.164.129.1108461930.squirrel@rousalka.dyndns.org> Message-ID: <1108464522.6719.57.camel@localhost.localdomain> On Tue, 2005-02-15 at 11:05 +0100, Nicolas Mailhot wrote: >> Or why should FC care whether third parties (in some countries) who can >> download the ISO's and then charge per CD-ROM might be affected by the >> software included. > >1. FC is not the ultimate source of all its components - why should >upstream projects care about FC if it doesn't care about its downstream ? > >2. I think you severily underestimate the contributions of downstream >projects - if you play nice with downstream downstream will play nice with >you and contribute developpers/packages to FC. A lot of the people >contributing things for FC extras now come from what can be considered >downstream projects : livna, dag, aurora... > >Getting the relations right with upstream and downstream is one of the >main points of Fedora - this is what RH was about to lose when RHEL was >launched. Good points Nicolas! I'm sure this isn't a black and white issue, but I must admit to some misgivings when you hear comments like FC won't be doing this because RH want this package, but the users of FC seem to be screaming for something different. However, with that said, without the very generous contributions of RH, Fedora Core wouldn't even exist, so that's something that needs to be considered. Food for thought! Rodd From buildsys at redhat.com Tue Feb 15 12:35:37 2005 From: buildsys at redhat.com (Build System) Date: Tue, 15 Feb 2005 07:35:37 -0500 Subject: rawhide report: 20050215 changes Message-ID: <200502151235.j1FCZba9015649@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.3.3-2.cvs20050214.3.1 -------------------------------------- * Mon Feb 14 2005 Dan Williams 0.3.3-2.cvs20050214.x.1 - Fix free of invalid pointer for multiple search domains * Mon Feb 14 2005 Dan Williams 0.3.3-2.cvs20050214 - Never automatically choose a device that doesn't support carrier detection - Add right-click menu to applet, can now "Pause/Resume" scanning through it - Fix DHCP Renew/Rebind timeouts - Fix frequency cycling problem on some cards, even when scanning was off - Play better with IPv6 - Don't send kernel version in DHCP packets, and ensure DHCP packets are at least 300 bytes in length to work around broken router - New DHCP options D-BUS API by Dan Reed - Handle multiple domain search options in DHCP responses autofs-1:4.1.3-99 ----------------- * Mon Feb 14 2005 Jeff Moyer - 1:4.1.3-99 - Change Copyright to License in the spec file so it will build. * Fri Feb 11 2005 Jeff Moyer - 1:4.1.3-98 - Program maps can repeat the last character of output. Fix this. Addresses bz #138606 - Return first entry when there are duplicate keys in a map. Addresses bz #140108. - Propagate custom map variables to submounts. Fixes bz #143074. - Create a sysconfig variable to control whether we source only one master map (the way sun does), or source all maps found (which is the default for backwards compatibility). Addresses bz #143126. - Revised version of the get_best_mount patch. (#146887) cfeist at redhat.com The previous patch introduced a regression. Non-replicated mounts would not have the white space stripped from the entry and the mount would fail. - Handle comment characters in the middle of the automount line in /etc/nsswitch.conf. Addresses bz #127457. * Wed Feb 02 2005 Chris Feist - 1:4.1.3-94 - Stop automount from pinging hosts if there is only one host (#146887) basesystem-8.0-5 ---------------- cvs-1.11.17-6 ------------- * Mon Feb 14 2005 Adrian Havill - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt * Thu Jun 10 2004 Nalin Dahyabhai 1.11.17-2 - rebuild dev86-0.16.16-3 --------------- * Mon Feb 14 2005 Florian La Roche - Copyright: -> License: dhcp-8:3.0.2rc3-4 ----------------- * Mon Feb 14 2005 Jason Vas Dias 3.0.2rc3-4 - make dhclient-script TIMEOUT mode do exactly the same configuration - as BOUND / RENEW / REBIND / REBOOT if router ping succeeds * Mon Feb 14 2005 Jason Vas Dias 3.0.2rc3-4 - fix bug 147926: dhclient-script should do restorecon for modified conf files - optimize execshield protection docbook-style-xsl-1.68.1-1 -------------------------- * Mon Feb 14 2005 Tim Waugh 1.68.1-1 - 1.68.1. dovecot-0.99.14-1.fc4 --------------------- * Mon Feb 14 2005 John Dennis - 0.99.14-1.fc4 - fix bug #147874, update to 0.99.14 release v0.99.14 2005-02-11 Timo Sirainen - Message address fields are now parsed differently, fixing some issues with spaces. Affects only clients which use FETCH ENVELOPE command. - Message MIME parser was somewhat broken with missing MIME boundaries - mbox: Don't allow X-UID headers in mails to override the UIDs we would otherwise set. Too large values can break some clients and cause other trouble. - passwd-file userdb wasn't working - PAM crashed with 64bit systems - non-SSL inetd startup wasn't working - If UID FETCH notices and skips an expunged message, don't return a NO reply. It's not needed and only makes clients give error messages. * Wed Feb 02 2005 John Dennis - 0.99.13-4.devel - fix bug #146198, clean up temp kerberos tickets * Mon Jan 17 2005 John Dennis 0.99.13-3.devel - fix bug #145214, force mbox_locks to fcntl only - fix bug #145241, remove prereq on postgres and mysql, allow rpm auto dependency generator to pick up client lib dependency if needed. file-4.13-1 ----------- * Tue Feb 15 2005 Radek Vokal - 4.13-1 - new version, fixing few bugs, patch clean-up - consistent output for bzip files (#147440) * Mon Jan 24 2005 Radek Vokal - 4.12-3 - core64 patch fixing output on core files (#145354) - minor change in magic patch * Mon Jan 03 2005 Radek Vokal - 4.12-2 - fixed crashes in threaded environment (#143871) findutils-1:4.2.15-2 -------------------- * Mon Feb 14 2005 Tim Waugh 1:4.2.15-2 - Added nofollow patch from upstream. * Mon Jan 31 2005 Tim Waugh 1:4.2.15-1 - 4.2.15. Lots of patches removed due to upstream merge. gdb-6.3.0.0-0.25 ---------------- * Mon Feb 14 2005 Jeff Johnston 6.3.0.0-0.25 - Bump up release number. * Mon Feb 14 2005 Jeff Johnston 6.3.0.0-0.24 - Fix gdb to always grab the terminal before a readline call. - Bugzilla 147880 * Fri Feb 11 2005 Jeff Johnston 6.3.0.0-0.23 - Bump up release number. hfsutils-3.2.6-5 ---------------- * Mon Feb 14 2005 David Woodhouse 3.2.6-5 - s/Copyright:/License:/ (sic) * Tue Jun 15 2004 Elliot Lee 3.2.6-4 - rebuilt * Mon Apr 19 2004 David Woodhouse 3.2.6-3 - BuildRequires tk-devel irda-utils-0.9.16-5 ------------------- * Tue Feb 15 2005 Karsten Hopp 0.9.16-5 - load irtty-sir module (#148750) kbd-1.12-3 ---------- * Mon Feb 14 2005 Adrian Havill - rebuilt kdepim-6:3.3.2-0.3 ------------------ * Mon Feb 14 2005 Than Ngo 6:3.3.2-0.3 - apply Steve patch to fix buffer problem kernel-2.6.10-1.1142_FC4 ------------------------ * Mon Feb 14 2005 Dave Jones - 2.6.11-rc4-bk2 libaio-0.3.103-4 ---------------- * Mon Feb 14 2005 Jeff Moyer - 0.3.103-4 - Build the library twice. Once with the old SONAME and once with the new one. This fixes the wrong SONAME problem by keeping a library around with the wrong name (libaio.so.1.0.0) and generating a new one (libaio.so.1.0.1). nfs-utils-1.0.6-53 ------------------ * Mon Feb 14 2005 Steve Dickson - Added support to rpcgssd.init and rpcsvcgssd.init scripts to insmod security modules. - Changed the nfs.init script to bring rpc.svcgssd up and down, since rpc.svcgssd is only needed with the NFS server is running. * Tue Dec 14 2004 Steve Dickson - Fix problem in idmapd that was causing "xdr error 10008" errors (bz 142813) - make sure the correct hostname is used in the SM_NOTIFY message that is sent from a rebooted server which has multiple network interfaces. (bz 139101) - Changed nfslock to send lockd a -KILL signal when coming down. (bz 125257) openhpi-1.9.2-3 --------------- * Mon Feb 14 2005 Phil Knirsch 1.9.2-3 - Rebuilt for new rpm-4.4 pam_ccreds-1-4 -------------- * Mon Feb 14 2005 Nalin Dahyabhai pam_ccreds-1-4 - change install dir from /lib/security to /%{_lib}/security pcmcia-cs-3.2.8-4.9 ------------------- * Mon Feb 14 2005 Dave Jones - Fix thinko in RadeonIGP exclusion. * Sun Feb 13 2005 Pete Zaitcev - Add bison to BuildRequires and set YACC variable, because we patch a .y file - Change rc.pcmcia to exit with a correct code (#142451) psacct-6.3.2-35 --------------- * Tue Feb 15 2005 Ivana Varekova 6.3.2-35 - fix #147782 logrotate script error pump-0.8.21-2 ------------- * Mon Feb 14 2005 Adrian Havill - rebuilt rpmdb-fedora-1:4-0.20050215 --------------------------- selinux-policy-strict-1.21.12-3 ------------------------------- * Mon Feb 14 2005 Dan Walsh 1.21.12-3 - Cleanup x_client_domain - Add dontaudit net_admin for cups selinux-policy-targeted-1.21.12-3 --------------------------------- * Mon Feb 14 2005 Dan Walsh 1.21.12-3 - Cleanup x_client_domain - Add dontaudit net_admin for cups shadow-utils-2:4.0.3-57 ----------------------- * Mon Feb 14 2005 Adrian Havill - rebuilt * Wed Feb 09 2005 Dan Walsh 2:4.0.3-39 - Change useradd to use matchpathcon * Thu Oct 21 2004 Dan Walsh 2:4.0.3-37 - Add matchpathcon to create the files correctly when they do not exist. tcpdump-14:3.8.2-10 ------------------- * Mon Feb 14 2005 Martin Stransky - 14:3.8.2-10 - remove explicit kernel dependecy (#146165) - support for files larger than 2GB (#147840) udev-050-5 ---------- * Thu Feb 10 2005 Harald Hoyer - 050-5 - doh, reverted the start_udev devel version, which slipped in From alan at redhat.com Tue Feb 15 12:35:59 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 15 Feb 2005 07:35:59 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108438864.6719.28.camel@localhost.localdomain> References: <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <20050215023134.GC16980@devserv.devel.redhat.com> <1108438864.6719.28.camel@localhost.localdomain> Message-ID: <20050215123559.GA7927@devserv.devel.redhat.com> On Tue, Feb 15, 2005 at 02:41:04PM +1100, Rodd Clarkson wrote: > What I read your comments as saying is that give that Fedora Core is > free (as in beer) then there is no problem with including it in Fedora > Core. The problem lies in people using Fedora Core down-stream. Am I > right? And the fact that the goal of Fedora is freedom as in "libre". An mp3 player would fail that goal. Lots of non US people make MP3 player packages available at the moment although that might of course change if EU law changes. From tmraz at redhat.com Tue Feb 15 12:54:08 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 15 Feb 2005 13:54:08 +0100 Subject: Security Question In-Reply-To: <4210F47F.1080600@bxwa.com> References: <4210DF17.1070101@bxwa.com> <20050214192857.657d4227@nausicaa.camperquake.de> <4210F47F.1080600@bxwa.com> Message-ID: <1108472048.6855.11.camel@perun.redhat.usu> On Mon, 2005-02-14 at 10:57 -0800, Scott Becker wrote: > I started with the default apache user and ran the following commands: > > #bring up apache account- > mkdir /home/apache > cp /etc/skel/.* /home/apache > chown -R apache: /home/apache > usermod -d /home/apache apache > usermod -s /bin/bash apache > > This way I can access it with a simple 'su apache' command ran as root > and there's a home directory to store the .psql_history file so the > command history is saved across sessions. I fear that by setting the > shell with 'usermod -s /bin/bash apache' I've opened a can of worms. I > just set a password on the account to prevent any more logins but if > there's a security hole it would be nice to fix it and if not I would > like to know how they logged in and understand the process. I tried > (just before setting the password) to login hitting enter for the > password and I couldn't get in. .... > I found nullok twice in the file. Perhaps I couldn't get in on my test > because PuTTY doesn't pass null. I guess I shall always set a password > from now on. > What does 'getent shadow apache' gives you if you call it from root account? If it's something like: apache:!!:xxxxx:::::: ^^ note these. If the exclamation marks are missing it means that this account is without a password and nullok allows to login to it. But if the !! (or *) is there it means something is broken on your system if it allowed login to that account. Can you find the messages from the /var/log/ surrounding the 'apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138)' message? -- Tomas Mraz From pbrobinson at gmail.com Tue Feb 15 13:33:54 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 15 Feb 2005 21:33:54 +0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050215123559.GA7927@devserv.devel.redhat.com> References: <604aa791050127190670b45173@mail.gmail.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <20050215023134.GC16980@devserv.devel.redhat.com> <1108438864.6719.28.camel@localhost.localdomain> <20050215123559.GA7927@devserv.devel.redhat.com> Message-ID: <5256d0b05021505335caf9cf5@mail.gmail.com> > > What I read your comments as saying is that give that Fedora Core is > > free (as in beer) then there is no problem with including it in Fedora > > Core. The problem lies in people using Fedora Core down-stream. Am I > > right? > > And the fact that the goal of Fedora is freedom as in "libre". An mp3 player > would fail that goal. Lots of non US people make MP3 player packages available > at the moment although that might of course change if EU law changes. And Australia with the 'free trade agreement' with the US gets some of the DMCA as well so I wouldn't know how we stand in regard to this. peter From ph18 at cornell.edu Tue Feb 15 14:57:21 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 15 Feb 2005 09:57:21 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108422161.32171.4.camel@one.myworld> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> Message-ID: To change the subject entirely, doesn't grip support OGG and FLAC? For the person who wants to "rip, mix and burn", OGG is better than MP3. Interoperability with Windows is good, the main trouble is listening to streaming audio on the web and downloading to many mp3 players. A win:win answer might be to build a grip that supports only ogg and flac? Is that hard? From fedora-devel at camperquake.de Tue Feb 15 15:02:21 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 15 Feb 2005 16:02:21 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> Message-ID: <20050215160221.799a14df@nausicaa.camperquake.de> Hi. "Paul A. Houle" wrote: > A win:win answer might be to build a grip that supports only ogg and > flac? Is that hard? grip itself does not support anything. It relies on external encoders. -- "Never underestimate the bandwidth of a truck full of tapes hurtling down the highway." -- Andrew S. Tannenbaum From jorton at redhat.com Tue Feb 15 15:07:27 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 15 Feb 2005 15:07:27 +0000 Subject: mod_bt package In-Reply-To: <9481E5A10504BB28C58567A0@[10.0.0.4]> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> <098F540093982AB8186FEDF0@[10.0.0.4]> <20050214105457.GA24808@redhat.com> <9481E5A10504BB28C58567A0@[10.0.0.4]> Message-ID: <20050215150727.GA31791@redhat.com> On Mon, Feb 14, 2005 at 02:38:03PM -0800, Kenneth Porter wrote: > --On Monday, February 14, 2005 10:54 AM +0000 Joe Orton > wrote: > > >What versions of php and httpd are you using? You shouldn't get this > >problem with FC3 or Raw Hide. > > FC2, so: > > php-devel-4.3.10-2.4 > httpd-devel-2.0.51-2.9 > > Which package changed its definitions to comply with the other? PHP will not #include in FC3 and later. If you file a bug against FC2 php I can probably fix it there for future updates. (the fact that both httpd and PHP think it's a good idea to reimplement the POSIX regex interface in random different ways is an accident waiting to happen; I've fixed it in the httpd 2.1 branch but PHP is another matter) Regards, joe From ph18 at cornell.edu Tue Feb 15 15:47:16 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 15 Feb 2005 10:47:16 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050215160221.799a14df@nausicaa.camperquake.de> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> Message-ID: On Tue, 15 Feb 2005 16:02:21 +0100, Ralf Ertzinger wrote: > Hi. > > "Paul A. Houle" wrote: > >> A win:win answer might be to build a grip that supports only ogg and >> flac? Is that hard? > > grip itself does not support anything. It relies on external encoders. > If that's the case, why is it being removed? Fedora has support for ogg. From seyman at wanadoo.fr Tue Feb 15 16:02:57 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Tue, 15 Feb 2005 17:02:57 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: References: <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> Message-ID: <20050215160257.GA27847@orient.maison.moi> On Tue, Feb 15, 2005 at 10:47:16AM -0500, Paul A. Houle wrote: > > If that's the case, why is it being removed? Fedora has support > for ogg. It's being removed because sound-juicer is the better CD ripper. Emmanuel From tadams-lists at myrealbox.com Tue Feb 15 16:13:58 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 15 Feb 2005 09:13:58 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050215160257.GA27847@orient.maison.moi> References: <41F9D9F9.7F27132C@dnalounge.com> <1108378702.18437.8.camel@speedy.iagorubio.net> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> <20050215160257.GA27847@orient.maison.moi> Message-ID: <1108484038.3721.9.camel@localhost.localdomain> On Tue, 2005-02-15 at 17:02 +0100, Emmanuel Seyman wrote: >On Tue, Feb 15, 2005 at 10:47:16AM -0500, Paul A. Houle wrote: >> >> If that's the case, why is it being removed? Fedora has support >> for ogg. > >It's being removed because sound-juicer is the better CD ripper. > >Emmanuel > Personally I would be all for this, but I still hear "It may not have quality selection support yet, but it will." This isn't some how does it look on my screen feature, it is vital. Trever -- A traveler on the information superhighway who often stops and looks around... From seyman at wanadoo.fr Tue Feb 15 16:33:28 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Tue, 15 Feb 2005 17:33:28 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108484038.3721.9.camel@localhost.localdomain> References: <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> <20050215160257.GA27847@orient.maison.moi> <1108484038.3721.9.camel@localhost.localdomain> Message-ID: <20050215163328.GA27959@orient.maison.moi> On Tue, Feb 15, 2005 at 09:13:58AM -0700, Trever L. Adams wrote: > > Personally I would be all for this, but I still hear "It may not have > quality selection support yet, but it will." This isn't some how does it > look on my screen feature, it is vital. This isn't in the CVS version? Emmanuel From tadams-lists at myrealbox.com Tue Feb 15 16:52:11 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 15 Feb 2005 09:52:11 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050215163328.GA27959@orient.maison.moi> References: <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> <20050215160257.GA27847@orient.maison.moi> <1108484038.3721.9.camel@localhost.localdomain> <20050215163328.GA27959@orient.maison.moi> Message-ID: <1108486331.3721.11.camel@localhost.localdomain> On Tue, 2005-02-15 at 17:33 +0100, Emmanuel Seyman wrote: >On Tue, Feb 15, 2005 at 09:13:58AM -0700, Trever L. Adams wrote: >> >> Personally I would be all for this, but I still hear "It may not have >> quality selection support yet, but it will." This isn't some how does it >> look on my screen feature, it is vital. > >This isn't in the CVS version? > >Emmanuel > Haven't the foggiest. I just know it isn't in the released versions. If it gets released, then no problem getting rid of grip on my part. Trever -- "Better to remain silent and be thought a fool than to speak out and remove all doubt." -- A. Lincoln From seyman at wanadoo.fr Tue Feb 15 17:02:25 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Tue, 15 Feb 2005 18:02:25 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108486331.3721.11.camel@localhost.localdomain> References: <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> <20050215160257.GA27847@orient.maison.moi> <1108484038.3721.9.camel@localhost.localdomain> <20050215163328.GA27959@orient.maison.moi> <1108486331.3721.11.camel@localhost.localdomain> Message-ID: <20050215170224.GA28136@orient.maison.moi> On Tue, Feb 15, 2005 at 09:52:11AM -0700, Trever L. Adams wrote: > > Haven't the foggiest. I just know it isn't in the released versions. If > it gets released, then no problem getting rid of grip on my part. The "How do I set the quality?" section of the README was removed a few days ago. See http://cvs.gnome.org/viewcvs/sound-juicer/README?r1=1.11&r2=1.12 Emmanuel From mpeters at mac.com Tue Feb 15 18:14:46 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 15 Feb 2005 18:14:46 +0000 Subject: kudzu network weirdness Message-ID: <1108491286l.6481l.0l@devel.mpeters.us> Changing my network, or at least - preparing to. Formerly I had 3 ethernet devices - as seen by Fedora: eth0: onboard 3Com nic (a7n8x deluxe) eth1: pci card, linksys generic eth2: onboard forcedepth nvidia nic (did not use) eth1 is what was attached to my DSL modem (since it was the only nic Win XP knew what to do with after a bare install w/o board driver disc) eth0 goes to a hub which has my iMac and a LaserJet 4 attached My plan was remove the pci ethernet card (eth0) and until I have the wireless router set up, use the forcedepth nic for my PPPoE. I moved the ethernet cable and used the network control panel to change the PPPoE to eth2. Restarted network - it was good, I could ping yahoo. I removed the pci card that was eth1 and installed an Atheros wireless card (AT&T P&S 6500G). I have the madwifi drivers installed. kudzu deleted the pci card, I told to ignore the wireless card, as from fedora user list archive, that is what I'm suppose to do. Kudzu did correctly enter the wireless card into /etc/sysconfig/hwconf I'm not sure why, but for the life of me, I could not get it to use the forcedepth card for the dsl - even though it had worked when I had switched it before doing the hardware change. Looked in the /etc/modprobe.conf - the reference to forcedepth as eth2 was still there, and an additional reference to forcedepth as eth1 was also there - at the end of the file, as if kudzu had just put it there. Looked in /etc/sysconfig/hwconf - and the foredepth card was only there as eth2. There was no eth1 (and shouldn't have been). Manually altered /etc/sysconfig/hwconf to make the forcedepth card be eth1 there, deleted /etc/sysconfig/network-scripts/ifcfg-eth2 - and rebooted, changed the PPPoE device to use eth1, everything worked fine then. I don't know if this is a kudzu bug or a quirk or what, but it seems that when the Linksys card that was eth1 was removed by kudzu, that since there now was no eth1 anymore, that gave a problem and eth2 could not be used to bring up PPPoE - so eth2 *should* have been migrated to eth1 in both /etc/sysconfig/hwconf and /etc/sysconfig/network-scripts - which is effectively what I manually did. Unfortunately it would a real PITA to try and duplicate this. -- Michael A. Peters http://mpeters.us/ From si at bananas.hopto.org Tue Feb 15 18:28:45 2005 From: si at bananas.hopto.org (Si Jones) Date: Tue, 15 Feb 2005 18:28:45 +0000 Subject: Perl, xchat, foomatic updates Message-ID: <1108492125.11319.9.camel@apple.bananas.hopto.org> Hi, I don't know if it's a bug but ever time I try to yum up to dev i have to exclude perl, xchat and foomatic. I think it's perl that has conflicting files but thought you should all know just in case. I am running an amd64. Regards, Si Jones From notting at redhat.com Tue Feb 15 18:40:43 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Feb 2005 13:40:43 -0500 Subject: kudzu network weirdness In-Reply-To: <1108491286l.6481l.0l@devel.mpeters.us> References: <1108491286l.6481l.0l@devel.mpeters.us> Message-ID: <20050215184043.GA21144@nostromo.devel.redhat.com> Michael A. Peters (mpeters at mac.com) said: > Unfortunately it would a real PITA to try and duplicate this. Did you have HWADDR in your ifcfg files beforehand? Bill From mpeters at mac.com Tue Feb 15 19:09:00 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 15 Feb 2005 19:09:00 +0000 Subject: kudzu network weirdness In-Reply-To: <20050215184043.GA21144@nostromo.devel.redhat.com> (from notting@redhat.com on Tue Feb 15 10:40:43 2005) References: <1108491286l.6481l.0l@devel.mpeters.us> <20050215184043.GA21144@nostromo.devel.redhat.com> Message-ID: <1108494540l.6481l.1l@devel.mpeters.us> On 02/15/2005 10:40:43 AM, Bill Nottingham wrote: > Michael A. Peters (mpeters at mac.com) said: > > Unfortunately it would a real PITA to try and duplicate this. > > Did you have HWADDR in your ifcfg files beforehand? No. -- Michael A. Peters http://mpeters.us/ From notting at redhat.com Tue Feb 15 19:22:56 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Feb 2005 14:22:56 -0500 Subject: kudzu network weirdness In-Reply-To: <1108494540l.6481l.1l@devel.mpeters.us> References: <1108491286l.6481l.0l@devel.mpeters.us> <20050215184043.GA21144@nostromo.devel.redhat.com> <1108494540l.6481l.1l@devel.mpeters.us> Message-ID: <20050215192255.GA5475@nostromo.devel.redhat.com> Michael A. Peters (mpeters at mac.com) said: > > On 02/15/2005 10:40:43 AM, Bill Nottingham wrote: > >Michael A. Peters (mpeters at mac.com) said: > >> Unfortunately it would a real PITA to try and duplicate this. > > > >Did you have HWADDR in your ifcfg files beforehand? > > No. Unfortunately, without that, it's a good deal harder to consistently tie configurations to cards on card changes, and so the right thing may not happen. Bill From shiva at sewingwitch.com Tue Feb 15 20:29:24 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 15 Feb 2005 12:29:24 -0800 Subject: mod_bt package In-Reply-To: <20050215150727.GA31791@redhat.com> References: <9BBE8C7FB561C684968C0CEA@[10.0.0.4]> <420F88E2.7010507@c-note.dk> <098F540093982AB8186FEDF0@[10.0.0.4]> <20050214105457.GA24808@redhat.com> <9481E5A10504BB28C58567A0@[10.0.0.4]> <20050215150727.GA31791@redhat.com> Message-ID: <3370013BE1F0FA5B435AF81D@[10.0.0.4]> --On Tuesday, February 15, 2005 3:07 PM +0000 Joe Orton wrote: > PHP will not #include in FC3 and later. If you file a bug > against FC2 php I can probably fix it there for future updates. > > (the fact that both httpd and PHP think it's a good idea to reimplement > the POSIX regex interface in random different ways is an accident > waiting to happen; I've fixed it in the httpd 2.1 branch but PHP is > another matter) Done: Thanks. Yeah, it looks like anyone wanting to manage Apache from PHP has to keep the code carefully separated in separate modules right now to avoid the header collision. From Daniel.Kaliel at jjbedmonton.com Tue Feb 15 20:13:14 2005 From: Daniel.Kaliel at jjbedmonton.com (Daniel Kaliel) Date: Tue, 15 Feb 2005 13:13:14 -0700 Subject: Courier Package Message-ID: <20050215200517.6A19D20E12B@hades.jjbedmonton.com> What list should I submit a courier rpm to? ===================================== Daniel Kaliel Network Administrator -------------------------------------------------------------------------- J.J. Barnicke Edmonton Ltd. #2300, 10123 99 Street Edmonton, AB T5J3H1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottb at bxwa.com Tue Feb 15 22:11:53 2005 From: scottb at bxwa.com (Scott Becker) Date: Tue, 15 Feb 2005 14:11:53 -0800 Subject: Security Question In-Reply-To: <1108472048.6855.11.camel@perun.redhat.usu> References: <4210DF17.1070101@bxwa.com> <20050214192857.657d4227@nausicaa.camperquake.de> <4210F47F.1080600@bxwa.com> <1108472048.6855.11.camel@perun.redhat.usu> Message-ID: <421273A9.2060802@bxwa.com> I've already set a proper password but on a twin testing machine the !!s are there, before and after running my setup commands to change the shell. Here's the top of message with the login and logout lines: Feb 13 04:05:24 backup syslogd 1.4.1: restart. Feb 13 05:39:25 backup named[31607]: lame server resolving '191.236.191.211.in-addr.arpa' (in '236.191.211.in-addr.arpa'?): 203.251.201.1#53 Feb 13 05:45:51 backup named[31607]: lame server resolving '201.32.110.61.in-addr.arpa' (in '32.110.61.in-addr.arpa'?): 203.240.193.11#53 Feb 13 05:45:51 backup named[31607]: lame server resolving '201.32.110.61.in-addr.arpa' (in '32.110.61.in-addr.arpa'?): 203.251.201.1#53 Feb 13 06:36:09 backup sshd(pam_unix)[422]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=dsl-82-199-133-138.dutchdsl.nl user=apache Feb 13 06:36:17 backup sshd(pam_unix)[425]: session opened for user apache by (uid=48) Feb 13 06:53:58 backup named[31607]: lame server resolving '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.240.193.11#53 Feb 13 06:53:58 backup named[31607]: lame server resolving '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.251.201.1#53 Feb 13 07:00:44 backup sshd(pam_unix)[425]: session closed for user apache Feb 13 07:39:19 backup sshd(pam_unix)[710]: check pass; user unknown Feb 13 07:39:19 backup sshd(pam_unix)[710]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:23 backup sshd(pam_unix)[713]: check pass; user unknown Feb 13 07:39:23 backup sshd(pam_unix)[713]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:27 backup sshd(pam_unix)[715]: check pass; user unknown Feb 13 07:39:27 backup sshd(pam_unix)[715]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:31 backup sshd(pam_unix)[717]: check pass; user unknown Feb 13 07:39:31 backup sshd(pam_unix)[717]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:34 backup sshd(pam_unix)[720]: check pass; user unknown Feb 13 07:39:34 backup sshd(pam_unix)[720]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:38 backup sshd(pam_unix)[722]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root Feb 13 07:39:42 backup sshd(pam_unix)[724]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root Feb 13 07:39:46 backup sshd(pam_unix)[726]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root One failed attempt, one successful attempt and a logout 24 minutes later. scottb Tomas Mraz wrote: >On Mon, 2005-02-14 at 10:57 -0800, Scott Becker wrote: > > >> >> > >What does 'getent shadow apache' gives you if you call it from root >account? >If it's something like: >apache:!!:xxxxx:::::: > ^^ note these. If the exclamation marks are missing it means that >this account is without a password and nullok allows to login to it. But >if the !! (or *) is there it means something is broken on your system if >it allowed login to that account. Can you find the messages from >the /var/log/ surrounding the 'apache logged in from >dsl-82-199-133-138.dutchdsl.nl (82.199.133.138)' message? > > > From pbrobinson at gmail.com Wed Feb 16 00:12:37 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 16 Feb 2005 08:12:37 +0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1108484038.3721.9.camel@localhost.localdomain> References: <41F9D9F9.7F27132C@dnalounge.com> <1108391302.5994.1.camel@localhost.localdomain> <20050214145028.GB29552@devserv.devel.redhat.com> <4211256A.7020804@poolshark.org> <1108422161.32171.4.camel@one.myworld> <20050215160221.799a14df@nausicaa.camperquake.de> <20050215160257.GA27847@orient.maison.moi> <1108484038.3721.9.camel@localhost.localdomain> Message-ID: <5256d0b05021516125c33e53d@mail.gmail.com> > On Tue, 2005-02-15 at 17:02 +0100, Emmanuel Seyman wrote: > >On Tue, Feb 15, 2005 at 10:47:16AM -0500, Paul A. Houle wrote: > >> > >> If that's the case, why is it being removed? Fedora has support > >> for ogg. > > > >It's being removed because sound-juicer is the better CD ripper. > > > >Emmanuel > > > > Personally I would be all for this, but I still hear "It may not have > quality selection support yet, but it will." This isn't some how does it > look on my screen feature, it is vital. I agree and I don't see anywhere to do VBR (Is this the same as quality). I use VBR in grip for all my MP3s to get better quality with smaller size. Is VBR supported by sound-juicer. Pete From mrsam at courier-mta.com Wed Feb 16 02:34:44 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 15 Feb 2005 21:34:44 -0500 Subject: RPM needs to go on a diet. Message-ID: I decided to clean up some old crud. # rpm -e kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 kernel-2.6.8-1.521 kernel-2.6.7-1.494.2.2 kernel-2.6.9-1.3_FC2 kernel-2.6.9-1.6_FC2 kernel-2.6.9-1.11_FC2 I was watching this with top(1). This command took six minutes to complete, with rpm taking up 100% CPU for six minutes straight. Yes, these are large packages that are being removed. No, even with all that, taking six minutes, a dual Opteron box, with SCSI RAID, is unreasonable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ghenriks at rogers.com Wed Feb 16 04:35:42 2005 From: ghenriks at rogers.com (Gerald Henriksen) Date: Tue, 15 Feb 2005 23:35:42 -0500 Subject: no keyboard with 2.6.10 kernels Message-ID: Everything works fine with kernel-2.6.9-1.667 However all of the 2.6.10 kernels I have tried from devel have given the "i8042.c: Can't read CTR while initializing i8042" error during the boot process and the keyboard doesn't work. Booting with acpi=off solves the problem but given that this is a laptop (Dell Inspiron 5150) this seems less than ideal. Any ideas? From tmraz at redhat.com Wed Feb 16 09:51:31 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 16 Feb 2005 10:51:31 +0100 Subject: Security Question In-Reply-To: <421273A9.2060802@bxwa.com> References: <4210DF17.1070101@bxwa.com> <20050214192857.657d4227@nausicaa.camperquake.de> <4210F47F.1080600@bxwa.com> <1108472048.6855.11.camel@perun.redhat.usu> <421273A9.2060802@bxwa.com> Message-ID: <1108547491.5808.13.camel@perun.redhat.usu> On Tue, 2005-02-15 at 14:11 -0800, Scott Becker wrote: > I've already set a proper password but on a twin testing machine the !!s > are there, before and after running my setup commands to change the > shell. Here's the top of message with the login and logout lines: > Feb 13 06:36:09 backup sshd(pam_unix)[422]: authentication failure; > logname= uid=0 euid=0 tty=NODEVssh ruser= > rhost=dsl-82-199-133-138.dutchdsl.nl user=apache > Feb 13 06:36:17 backup sshd(pam_unix)[425]: session opened for user > apache by (uid=48) > Feb 13 06:53:58 backup named[31607]: lame server resolving > '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.240.193.11#53 > Feb 13 06:53:58 backup named[31607]: lame server resolving > '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.251.201.1#53 > Feb 13 07:00:44 backup sshd(pam_unix)[425]: session closed for user apache The problem is that I don't see how anyone could login using ssh to account with !! in /etc/shadow. I have to suppose that there were nothing instead of !! and then the login could succeed - the attacker would first try no password which wouldn't be allowed if PermitEmptyPassword is set to 'no' in /etc/ssh/sshd_config and then he would try any password and he would be allowed in. What versions of pam and openssh do you have? -- Tomas Mraz From pmatilai at welho.com Wed Feb 16 11:27:23 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 16 Feb 2005 13:27:23 +0200 (EET) Subject: RPM needs to go on a diet. In-Reply-To: References: Message-ID: On Tue, 15 Feb 2005, Sam Varshavchik wrote: > I decided to clean up some old crud. > > # rpm -e kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 kernel-2.6.8-1.521 > kernel-2.6.7-1.494.2.2 kernel-2.6.9-1.3_FC2 kernel-2.6.9-1.6_FC2 > kernel-2.6.9-1.11_FC2 > > I was watching this with top(1). > > This command took six minutes to complete, with rpm taking up 100% CPU for > six minutes straight. > > Yes, these are large packages that are being removed. No, even with all > that, taking six minutes, a dual Opteron box, with SCSI RAID, is > unreasonable. The kernel package runs hardlink on /lib/modules/*/build/ in %post to save space on FC2 and FC3, that's what's taking so long when installing and removing kernels. That's no longer the case on devel tree kernels where the headers have been split out to separate kernel-devel package for those who need it. Kernel-devel still does the hardlink, but that doesn't affect nearly as many people. - Panu - From dwmw2 at infradead.org Wed Feb 16 11:30:51 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 16 Feb 2005 11:30:51 +0000 Subject: RPM needs to go on a diet. In-Reply-To: References: Message-ID: <1108553451.22597.93.camel@baythorne.infradead.org> On Wed, 2005-02-16 at 13:27 +0200, Panu Matilainen wrote: > The kernel package runs hardlink on /lib/modules/*/build/ in %post to save > space on FC2 and FC3, that's what's taking so long when installing and > removing kernels. Not on remove. -- dwmw2 From symbiont at berlios.de Wed Feb 16 11:31:37 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 16 Feb 2005 19:31:37 +0800 Subject: RPM needs to go on a diet. In-Reply-To: References: Message-ID: <200502161931.37729.symbiont@berlios.de> On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote: > Yes, these are large packages that are being removed. ?No, even with > all that, taking six minutes, a dual Opteron box, with SCSI RAID, is > unreasonable. Check strace, %preun, %post, %postun, and other related trigger operations and post your results where the bottlenecks are. Could be rpm, could be db, could be scriptlets .. who knows. Maybe use the bootchart except retune it to read strace/ltrace output and produce analysis. valgrind and others work too. have fun, -- -jeff From arjanv at redhat.com Wed Feb 16 11:36:49 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 16 Feb 2005 06:36:49 -0500 Subject: RPM needs to go on a diet. In-Reply-To: References: Message-ID: <1108553809.3972.66.camel@localhost.localdomain> On Wed, 2005-02-16 at 13:27 +0200, Panu Matilainen wrote: > On Tue, 15 Feb 2005, Sam Varshavchik wrote: > > > I decided to clean up some old crud. > > > > # rpm -e kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 kernel-2.6.8-1.521 > > kernel-2.6.7-1.494.2.2 kernel-2.6.9-1.3_FC2 kernel-2.6.9-1.6_FC2 > > kernel-2.6.9-1.11_FC2 > > > > I was watching this with top(1). > > > > This command took six minutes to complete, with rpm taking up 100% CPU for > > six minutes straight. > > > > Yes, these are large packages that are being removed. No, even with all > > that, taking six minutes, a dual Opteron box, with SCSI RAID, is > > unreasonable. > > The kernel package runs hardlink on /lib/modules/*/build/ in %post to save > space on FC2 and FC3, that's what's taking so long when installing and > removing kernels. That's no longer the case on devel tree kernels where > the headers have been split out to separate kernel-devel package for those > who need it. Kernel-devel still does the hardlink, but that doesn't > affect nearly as many people. actually the hardlink doesn't matter for rpm -e, only for rpm -i. -------------- next part -------------- A 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 mrsam at courier-mta.com Wed Feb 16 12:13:04 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 16 Feb 2005 07:13:04 -0500 Subject: RPM needs to go on a diet. References: <200502161931.37729.symbiont@berlios.de> Message-ID: Jeff Pitman writes: > On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote: >> Yes, these are large packages that are being removed. ?No, even with >> all that, taking six minutes, a dual Opteron box, with SCSI RAID, is >> unreasonable. > > Check strace, %preun, %post, %postun, and other related trigger > operations and post your results where the bottlenecks are. Could be > rpm, could be db, could be scriptlets .. who knows. It's neither of these. According to top, all the CPU was being charged to the rpm process alone. The kernel package's %preun consists of: /sbin/modprobe loop 2> /dev/null > /dev/null || : [ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 2.6.10-1.12_FC2 Which is nothing. rpm was eating CPU like there's no tomorrow. strace was showing lots of read/writes, likely its database. -------------- 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 16 12:57:06 2005 From: buildsys at redhat.com (Build System) Date: Wed, 16 Feb 2005 07:57:06 -0500 Subject: rawhide report: 20050216 changes Message-ID: <200502161257.j1GCv6jV030217@porkchop.devel.redhat.com> Updated Packages: bluez-bluefw-1.0-7 ------------------ * Tue Feb 15 2005 David Woodhouse 1.0-7 - Rebuild bluez-pin-0.23-4 ---------------- * Tue Feb 15 2005 David Woodhouse 0.23-4 - Rebuild, include debug info bridge-utils-1.0.4-5 -------------------- * Tue Feb 15 2005 David Woodhouse 1.0.4-5 - Rebuild crypto-utils-2.1-5 ------------------ * Tue Feb 15 2005 Joe Orton 2.1-5 - certwatch: prevent warnings for duplicate certs (#103807) - make /etc/cron.daily/certwatch 0755 (#141003) - add genkey(1) man page (#134821) dhcp-8:3.0.2rc3-8_FC4 --------------------- * Mon Feb 14 2005 Jason Vas Dias 8:3.0.2rc3-8 - Add better execshield security link options - fix dhcpd.init when no /etc/dhcpd.conf exists and -cf in DHCPDARGS * Mon Feb 14 2005 Jason Vas Dias 8:3.0.2rc3-4 - make dhclient-script TIMEOUT mode do exactly the same configuration - as BOUND / RENEW / REBIND / REBOOT if router ping succeeds irda-utils-0.9.16-6 ------------------- * Tue Feb 15 2005 Karsten Hopp 0.9.16-6 - use RPM_OPT_FLAGS as CFLAGS kernel-2.6.10-1.1143_FC4 ------------------------ * Tue Feb 15 2005 Dave Jones - 2.6.11-rc4-bk3 libtool-1.5.14.multilib2-4 -------------------------- * Tue Feb 15 2005 Joe Orton 1.5.14.multilib2-4 - revert to the old multilib patch (#138742) nvi-m17n-1.79-20040401.22 ------------------------- * Wed Feb 16 2005 Akira TAGOH - 1.79-20040401.22 - nvi-1.79-comment-out-unreferenced-functions.patch: comment out the unreferenced functions. (#145945) octave-6:2.1.57-10 ------------------ * Tue Feb 15 2005 Ivana Varekova 2.1.57-10 - Fix bug 142477 - problem with signbit definition (Patch2) open-1.4-23 ----------- * Tue Feb 15 2005 Than Ngo 1.4-23 - use $RPM_OPT_FLAGS * Wed Feb 09 2005 Than Ngo 1.4-22 - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt psacct-6.3.2-36 --------------- * Tue Feb 15 2005 Ivana Varekova 6.3.2-36 - fix sa manpage - necessary becouse of bug #43294 and previous patch rpmdb-fedora-1:4-0.20050216 --------------------------- selinux-policy-strict-1.21.13-1 ------------------------------- * Mon Feb 14 2005 Dan Walsh 1.21.13-1 - Update from NSA - Add bin_t, sbin_t, exec_type execmod privs for targeted policy selinux-policy-targeted-1.21.13-1 --------------------------------- * Mon Feb 14 2005 Dan Walsh 1.21.13-1 - Update from NSA - Add bin_t, sbin_t, exec_type execmod privs for targeted policy slocate-2.7-14 -------------- * Tue Feb 15 2005 Miloslav Trmac - 2.7-14 - Process the filesystem type exclusion list when finding the mount points, not only before starting the filesystem tree walk (#139950) - Clean up the spec file (#135192, original patch by Robert Scheck) subversion-1.1.3-3 ------------------ * Tue Feb 15 2005 Joe Orton 1.1.3-3 - run test suite in C locale (#146125) - adjust -pie patch for build.conf naming upstream * Wed Jan 19 2005 Joe Orton 1.1.3-2 - rebuild to pick up db-4.3 properly; don't ignore test failures tetex-3.0-1 ----------- * Thu Feb 10 2005 Jindrich Novy 3.0-1 - drop CAN-2004-1125 patch, applied upstream - drop CAN-2004-0064 patch, CAN-2004-0888 fixed sufficiently upstream - drop xaw3d (use Motif intead), nostrip, old (>65 limitation in latex.ltx), xdvik-xdvi-resources - keep marvosym-rightarrow patch (not fixed yet) - update Source0, Source1, drop Source13 (varioref fixed) - sync with spec for 3.0 suggested by MATSUURA Takanori (#147668) - don't ship log files in /usr/share/texmf-var/web2c/*.log * Wed Feb 02 2005 MATSUURA Takanori - 2.99.11.20050131-0.0.1 - update to 2.99.11-20050131b - update Japanese support (Japanese -> UTF-8 conversion, cleanup of patches, spec update) - add support for firefox, mozilla, htmlview (first), w3m browsers for xdvik (browser patch) - suggest to drop CAN*, xaw3d, nostrip (fixed), old, xdvik-xdvi-resources, marvosym-rightarrow - suggest separation of latex2html and texi2html (new packages) from tetex package - delete support for latex2html, texi2html from spec - fix %post phase in latex subpackage * Fri Dec 03 2004 Jindrich Novy 2.0.2-26 - Convert archives to bz2 to save some space - Update to ptex-src-3.1.4, ptex-texmf-2.2, mendenk to 2.5a, pdvipsk to 5.94a-1.6a (bug #138444) usermode-1.78-2 --------------- * Wed Feb 16 2005 Jindrich Novy 1.78-2 - add $RPM_OPT_FLAGS to CFLAGS From n3npq at nc.rr.com Wed Feb 16 13:27:38 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 16 Feb 2005 08:27:38 -0500 Subject: RPM needs to go on a diet. In-Reply-To: References: <200502161931.37729.symbiont@berlios.de> Message-ID: <42134A4A.6040809@nc.rr.com> Sam Varshavchik wrote: > Jeff Pitman writes: > >> On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote: >> >>> Yes, these are large packages that are being removed. No, even with >>> all that, taking six minutes, a dual Opteron box, with SCSI RAID, is >>> unreasonable. >> >> >> Check strace, %preun, %post, %postun, and other related trigger >> operations and post your results where the bottlenecks are. Could be >> rpm, could be db, could be scriptlets .. who knows. > > > It's neither of these. According to top, all the CPU was being > charged to the rpm process alone. The kernel package's %preun > consists of: > > /sbin/modprobe loop 2> /dev/null > /dev/null || : > [ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd > --rmmoddep --remove 2.6.10-1.12_FC2 > > Which is nothing. > > rpm was eating CPU like there's no tomorrow. strace was showing lots > of read/writes, likely its database. Yep. There's a busted algorithm in rpm that goes badly when there are numerous duplicate basenames that is triggered by installing lots and lots of kernels (with 18K+ duplicate basenames each) onto client machines. Keep fewer kernels installed is the only answer I have at the moment. A real fix is non-trivial and has been blocked (because not prioritized) for many years now. There has been little need to "fix" the problem because behavior has been acceptable except for certain problem areas like LC_MESSAGES in glibc-common. Now there are often 10+ kernels are present on each and every client. There is certainly no "need" for 10+ kernels on most client machines that I'm aware of. I'd also suggest better install policies for kernels would help. Note that multilib installs are forcing multiple duplicate file basenames onto lots of machines as well. The same slow behavior will be seen, just not as bad as kernel packages because fewer files involved. 73 de Jeff From rjune at bravegnuworld.com Wed Feb 16 13:37:40 2005 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 16 Feb 2005 08:37:40 -0500 Subject: Security Question In-Reply-To: <1108547491.5808.13.camel@perun.redhat.usu> References: <4210DF17.1070101@bxwa.com> <421273A9.2060802@bxwa.com> <1108547491.5808.13.camel@perun.redhat.usu> Message-ID: <200502160837.49684.rjune@bravegnuworld.com> > The problem is that I don't see how anyone could login using ssh to > account with !! in /etc/shadow. I have to suppose that there were three words, ssh pubkey authentication. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmraz at redhat.com Wed Feb 16 14:04:56 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 16 Feb 2005 15:04:56 +0100 Subject: Security Question In-Reply-To: <200502160837.49684.rjune@bravegnuworld.com> References: <4210DF17.1070101@bxwa.com> <421273A9.2060802@bxwa.com> <1108547491.5808.13.camel@perun.redhat.usu> <200502160837.49684.rjune@bravegnuworld.com> Message-ID: <1108562696.5808.25.camel@perun.redhat.usu> On Wed, 2005-02-16 at 08:37 -0500, Richard June wrote: > > > The problem is that I don't see how anyone could login using ssh to > > account with !! in /etc/shadow. I have to suppose that there were > three words, ssh pubkey authentication. This doesn't apply as the attacker would have to have the ssh private key of a public key which would have to be installed in the ~apache/.ssh/authorized_keys what I don't suppose. However I've been mistaken with the /etc/shadow - the real thing is in the /etc/passwd line - if the second field is empty (no 'x' there) that means the password is empty and sshd would allow logging in. -- Tomas Mraz From marcel at mesa.nl Wed Feb 16 14:25:58 2005 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Wed, 16 Feb 2005 15:25:58 +0100 Subject: rawhide report: 20050216 changes In-Reply-To: <200502161257.j1GCv6jV030217@porkchop.devel.redhat.com> References: <200502161257.j1GCv6jV030217@porkchop.devel.redhat.com> Message-ID: <20050216142558.GC4065@joshua.mesa.nl> On Wed, Feb 16, 2005 at 07:57:06AM -0500, Build System wrote: > > rpmdb-fedora-1:4-0.20050216 > --------------------------- Does nobody care that rpmdb is still not on the ftp sites (not on the mirrors and not on download.fedora.redhat.com)? -Marcel From rjune at bravegnuworld.com Wed Feb 16 14:28:45 2005 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 16 Feb 2005 09:28:45 -0500 Subject: Security Question In-Reply-To: <1108562696.5808.25.camel@perun.redhat.usu> References: <4210DF17.1070101@bxwa.com> <200502160837.49684.rjune@bravegnuworld.com> <1108562696.5808.25.camel@perun.redhat.usu> Message-ID: <200502160928.48131.rjune@bravegnuworld.com> On Wednesday 16 February 2005 09:04, Tomas Mraz wrote: > On Wed, 2005-02-16 at 08:37 -0500, Richard June wrote: > > > > > > > The problem is that I don't see how anyone could login using ssh to > > > account with !! in /etc/shadow. I have to suppose that there were > > > > three words, ssh pubkey authentication. > > This doesn't apply as the attacker would have to have the ssh private > key of a public key which would have to be installed in the > ~apache/.ssh/authorized_keys what I don't suppose. > However I've been mistaken with the /etc/shadow - the real thing is in > the /etc/passwd line - if the second field is empty (no 'x' there) that > means the password is empty and sshd would allow logging in. Default config is for ssh to not allow emtpy passwords to login *AND* to put either x or !! into the passwd field in /etc/passwd. Thus for sshd to allow sombody to log in like that, the user (or the attacker through some other means) would have to edit /etc/passwd, and enable empty passwords in sshd_config, and restart ssh(though if you have the first two done, the last should be simple) and in the event of users such as apache, you have to change the shell from /bin/false to /bin/bash or something. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kyrre at solution-forge.net Wed Feb 16 15:37:03 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 16 Feb 2005 16:37:03 +0100 Subject: kudzu network weirdness In-Reply-To: <20050215192255.GA5475@nostromo.devel.redhat.com> References: <1108491286l.6481l.0l@devel.mpeters.us> <20050215184043.GA21144@nostromo.devel.redhat.com> <1108494540l.6481l.1l@devel.mpeters.us> <20050215192255.GA5475@nostromo.devel.redhat.com> Message-ID: <1108568222.4323.0.camel@localhost.localdomain> tir, 15.02.2005 kl. 20.22 skrev Bill Nottingham: > Michael A. Peters (mpeters at mac.com) said: > > > > On 02/15/2005 10:40:43 AM, Bill Nottingham wrote: > > >Michael A. Peters (mpeters at mac.com) said: > > >> Unfortunately it would a real PITA to try and duplicate this. > > > > > >Did you have HWADDR in your ifcfg files beforehand? > > > > No. > > Unfortunately, without that, it's a good deal harder to consistently > tie configurations to cards on card changes, and so the right thing > may not happen. > > Bill Then why isn't this done by kudzu (or the tool that configures the cards in the first hand)? From mike at navi.cx Wed Feb 16 17:07:57 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 16 Feb 2005 17:07:57 +0000 Subject: alsa-oss got lost? References: <20050214182801.GA13353@nostromo.devel.redhat.com> <1108406677.6112.17.camel@localhost.localdomain> Message-ID: On Mon, 14 Feb 2005 19:44:37 +0100, Thorsten Leemhuis wrote: > Well, does anyone need it? If really yes I'll maybe put it back and > update it. If you guys go ahead and enable dmix then yes, it'll be needed. Otherwise OSS apps will break software mixing by holding the kernel level device open. thanks -mike From ken at bonsai.com Wed Feb 16 17:41:50 2005 From: ken at bonsai.com (Ken Sedgwick) Date: Wed, 16 Feb 2005 09:41:50 -0800 Subject: Self-Introduction: Ken Sedgwick Message-ID: <421385DE.3060503@bonsai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, 1. My name is Ken Sedgwick. 2. My full legal name is Kenneth Arthur Sedgwick. 3. I am a professional software consultant. 4. I work for Bonsai Software, Inc., a small consulting company ~ located in Albany, CA. 5. My immediate goal in the Fedora Project is to publish the ACE and ~ TAO packages. ~ Official ACE Site http://www.cs.wustl.edu/~schmidt/ACE.html ~ Official TAO Site http://www.cs.wustl.edu/~schmidt/TAO.html 6. I have worked for a variety of large and small software companies ~ for 20 years. ~ I'm fluent in C, C++, Java, Python, Perl ... ~ I'm experienced with multi-threaded programming, CORBA, STL, OpenSSL ... ~ You should trust me because I have a clean record and many ~ excellent references. 7. My GPG key is uploaded to pgp.mit.edu. Here is the key fingerprint: pub 1024D/3F3F9640 2005-02-14 Ken Sedgwick ~ Key fingerprint = 851E 3B07 E586 0843 9434 5CC7 4033 3B9B 3F3F 9640 uid Ken Sedgwick sub 1024g/3C6A2CCC 2005-02-14 [expires: 2015-02-12] - -- Ken Sedgwick Bonsai Software, Inc. (510) 610-4162 ken+5a4 at bonsai.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCE4XeQDM7mz8/lkARAtWuAJwPCL/pI7Al5eBNIMhrMZfWI0hwrwCdGIMd stg1wtJovad0ztV60879MVU= =Giqc -----END PGP SIGNATURE----- From kevinverma at gmail.com Wed Feb 16 19:05:02 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Wed, 16 Feb 2005 23:05:02 +0400 Subject: snd_intel8x0 problem on 2.6.10 Message-ID: <1108580702.5698.0.camel@localhost.localdomain> I am using FC3 on ThinkPad R50e. I had sound problems earlier while upgrading the kernel. The solution on the below given URL solved the purpose: http://www.ces.clemson.edu/linux/alsa.shtml Now yesterday suddenly while using my ThinkPad volume keys sound stopped responding, I have tried the same solution no help. I have disabled the 'tpb' as well. Sound is not responding. I looked into Bug 144742 and related, but no solution worked. Presently I have set snd_intel8x0m in /etc/hotplug/blacklist . https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144742 My sound card information is as below: 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) Think Pad R50e 1834 RYV76 with kernel 2.6.10-1_760 FC3 Please suggest. -- Kevin Verma From jules at tdcadsl.dk Wed Feb 16 21:24:12 2005 From: jules at tdcadsl.dk (Jules Colding) Date: Wed, 16 Feb 2005 22:24:12 +0100 Subject: Self-Introduction: Ken Sedgwick In-Reply-To: <421385DE.3060503@bonsai.com> References: <421385DE.3060503@bonsai.com> Message-ID: <1108589052.5668.7.camel@localhost.localdomain> On Wed, 2005-02-16 at 09:41 -0800, Ken Sedgwick wrote: > 5. My immediate goal in the Fedora Project is to publish the ACE and > ~ TAO packages. > > ~ Official ACE Site http://www.cs.wustl.edu/~schmidt/ACE.html > > ~ Official TAO Site http://www.cs.wustl.edu/~schmidt/TAO.html I for one would love to see ACE and TAO in Fedora Extras. Info for the uninitiated: ACE is a *very* versatile C++ wrapper framework. It has platform wrappers for threads, networking, loggin and everything you could possibly think of. Think of ACE as glib on steroids. TAO is a very complete CORBA implementation with C++ bindings build upon ACE. -- jules From davidc at ccmi.salk.edu Thu Feb 17 00:54:56 2005 From: davidc at ccmi.salk.edu (David Chambers) Date: Wed, 16 Feb 2005 16:54:56 -0800 Subject: no keyboard with 2.6.10 kernels In-Reply-To: References: Message-ID: <20050216165456.176108a9@muk.mgl> On Tue, 15 Feb 2005 23:35:42 -0500 Gerald Henriksen wrote: > Everything works fine with kernel-2.6.9-1.667 > > However all of the 2.6.10 kernels I have tried from devel have given > the "i8042.c: Can't read CTR while initializing i8042" error during > the boot process and the keyboard doesn't work. > > Booting with acpi=off solves the problem but given that this is a > laptop (Dell Inspiron 5150) this seems less than ideal. > > Any ideas? > Try booting with "usb-handoff" - this works for me on a dual xeon with i7505 chipset and smp kernels: it's worth a go on the laptop. - David From shiva at sewingwitch.com Thu Feb 17 03:37:58 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 16 Feb 2005 19:37:58 -0800 Subject: RPM needs to go on a diet. In-Reply-To: References: Message-ID: --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen wrote: > The kernel package runs hardlink on /lib/modules/*/build/ in %post to > save space on FC2 and FC3, that's what's taking so long when installing > and removing kernels. What does hardlink do? There appears to be no man page or other documentation for it in kernel-utils. From n3npq at nc.rr.com Thu Feb 17 03:47:07 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 16 Feb 2005 22:47:07 -0500 Subject: RPM needs to go on a diet. In-Reply-To: References: Message-ID: <421413BB.3030106@nc.rr.com> Kenneth Porter wrote: > --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen > wrote: > >> The kernel package runs hardlink on /lib/modules/*/build/ in %post to >> save space on FC2 and FC3, that's what's taking so long when installing >> and removing kernels. > > > What does hardlink do? There appears to be no man page or other > documentation for it in kernel-utils. Hardlinks's identical files to save space. 73 de Jeff From ghenriks at rogers.com Thu Feb 17 05:10:34 2005 From: ghenriks at rogers.com (Gerald Henriksen) Date: Thu, 17 Feb 2005 00:10:34 -0500 Subject: no keyboard with 2.6.10 kernels In-Reply-To: <20050216165456.176108a9@muk.mgl> References: <20050216165456.176108a9@muk.mgl> Message-ID: On Wed, 16 Feb 2005 16:54:56 -0800, you wrote: >Try booting with "usb-handoff" - this works for me on a dual xeon with >i7505 chipset and smp kernels: it's worth a go on the laptop. Thanks for the suggestion but it didn't help. From arnaud.abelard at univ-nantes.fr Thu Feb 17 07:54:52 2005 From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=) Date: Thu, 17 Feb 2005 08:54:52 +0100 Subject: NetworkManager In-Reply-To: <1108244890.4571.1.camel@p.linuxcenter.cl> References: <1108244890.4571.1.camel@p.linuxcenter.cl> Message-ID: <42144DCC.5050802@univ-nantes.fr> Patricio Bruna V wrote: > i just install NetworkManager and NetworkManager-gnome > but i can't find the applet that supose to allow me change networks. Be sure the NetworkManager service is running (service NetworkManager status) then run NetworkManagerInfo, you should see a little icon appearing in Gnome's notification area. I've been playing with the applet for a little while now and it's work fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again and again.. very very annoying. If anyone knows how to tell NetworkManager to leave my resolv.conf or at least to fill it with the servers sent by the DHCP server.... Thanks -- Arnaud Ab?lard Administrateur Syst?mes et R?seaux Facult? de Sciences et Techniques Universit? de Nantes From fedora-devel at camperquake.de Thu Feb 17 10:22:57 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 11:22:57 +0100 Subject: RPM needs to go on a diet. In-Reply-To: <421413BB.3030106@nc.rr.com> References: <421413BB.3030106@nc.rr.com> Message-ID: <20050217112257.755a4fc2@nausicaa.camperquake.de> Hi. Jeff Johnson wrote: > Hardlinks's identical files to save space. Does this really pay off? I for one would be glad for a switch to disable this. -- "Personally I'm always ready to learn, although I do not always like being taught." -- Winston Churchill From rahulsundaram at yahoo.co.in Thu Feb 17 10:29:24 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 17 Feb 2005 02:29:24 -0800 (PST) Subject: RPM needs to go on a diet. In-Reply-To: <20050217112257.755a4fc2@nausicaa.camperquake.de> Message-ID: <20050217102924.41084.qmail@web8502.mail.in.yahoo.com> --- Ralf Ertzinger wrote: > Hi. > > Jeff Johnson wrote: > > > Hardlinks's identical files to save space. > > Does this really pay off? I for one would be glad > for a switch to disable > this. > it does pay off in a big way for systems having a lot of kernels installed in them which seems to be pretty typical esp for fedora ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From fedora-devel at camperquake.de Thu Feb 17 10:37:11 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 11:37:11 +0100 Subject: RPM needs to go on a diet. In-Reply-To: <20050217102924.41084.qmail@web8502.mail.in.yahoo.com> References: <20050217112257.755a4fc2@nausicaa.camperquake.de> <20050217102924.41084.qmail@web8502.mail.in.yahoo.com> Message-ID: <20050217113711.75b770a9@nausicaa.camperquake.de> Hi. Rahul Sundaram wrote: > it does pay off in a big way for systems having a lot > of kernels installed in them which seems to be pretty > typical esp for fedora What is "a lot"? I currently have the last 6 kernels on this machine. Given that the hard disk is not the fastest one around, I'd rather spend the 12MB or so per -devel package than wait ages for hardlink to finish it's grind though /lib/modules. -- "What's the use of logic in a world where everyone talks about the sun setting, when it's really the horizon rising?" -- Iain Street From pbruna at linuxcenterla.com Thu Feb 17 12:24:53 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Thu, 17 Feb 2005 09:24:53 -0300 Subject: NetworkManager In-Reply-To: <42144DCC.5050802@univ-nantes.fr> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> Message-ID: <1108643093.2791.3.camel@p.linuxcenter.cl> El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: >Patricio Bruna V wrote: >> i just install NetworkManager and NetworkManager-gnome >> but i can't find the applet that supose to allow me change networks. > >Be sure the NetworkManager service is running (service NetworkManager >status) then run NetworkManagerInfo, you should see a little icon >appearing in Gnome's notification area. >I've been playing with the applet for a little while now and it's work >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again >and again.. very very annoying. > >If anyone knows how to tell NetworkManager to leave my resolv.conf or at >least to fill it with the servers sent by the DHCP server.... > > I can't see the icon you mentiont, and i have the same problem that you with /etc/resolv.conf -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 4834041 -------------- next part -------------- A 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 17 12:22:20 2005 From: buildsys at redhat.com (Build System) Date: Thu, 17 Feb 2005 07:22:20 -0500 Subject: rawhide report: 20050217 changes Message-ID: <200502171222.j1HCMKxu016651@porkchop.devel.redhat.com> Updated Packages: alsa-lib-1.0.8-3.devel ---------------------- * Tue Feb 15 2005 Martin Stransky 1.0.8-3.devel - add $RPM_OPT_FLAGS to CFLAGS alsa-utils-1.0.8-2 ------------------ * Sat Feb 16 2008 Martin Stransky 1.0.8-2 - fix #148011 (add gettext-devel to BuildRequires) - add $RPM_OPT_FLAGS to CFLAGS awesfx-0.5.0d-1 --------------- * Mon Jan 31 2005 Martin Stransky 0.5.0d-1 - updated to 0.5.0d dvd+rw-tools-5.21.4.10.8-5 -------------------------- * Wed Feb 16 2005 Harald Hoyer - 5.21.4.10.8-5 - built with RPM_OPT_FLAGS elfutils-0.101-2 ---------------- * Wed Feb 16 2005 Jakub Jelinek 0.101-2 - update to 0.101. - use %configure macro to get CFLAGS etc. right foomatic-3.0.2-14 ----------------- * Wed Feb 16 2005 Tim Waugh 3.0.2-14 - Updated db to 20050216. * Thu Feb 10 2005 Tim Waugh - Added IEEE 1284 information for HP Color LaserJet 4600 (bug #147648). * Tue Feb 08 2005 Tim Waugh - Corrected IEEE 1284 information for HP DeskJet 6540 (bug #147288). - Added IEEE 1284 information for Epson Stylus C82 (bug #147230). gcc4-4.0.0-0.24 --------------- * Wed Feb 16 2005 Jakub Jelinek 4.0.0-0.24 - update from trunk - fix PRs middle-end/19857, tree-optimization/18947 - work around PR debug/19769 giftrans-1.12.2-21 ------------------ * Wed Feb 16 2005 Phil Knirsch 1.12.2-21 - rebuilt - Fixed Copyright to License * Tue Jun 15 2004 Elliot Lee 1.12.2-20 - rebuilt * Fri Feb 13 2004 Elliot Lee 1.12.2-19 - rebuilt gnome-vfs2-2.9.91-2 ------------------- * Wed Feb 16 2005 Alexander Larsson - 2.9.91-2 - Add patch from cvs that fixes #144607 hpoj-0.91-12 ------------ * Wed Feb 16 2005 Tim Waugh 0.91-12 - Use RPM_OPT_FLAGS. isdn4k-utils-3.2-24 ------------------- * Wed Feb 16 2005 Than Ngo 3.2-24 - update cvs snapshot - use RPM_OPT_FLAGS less-382-6 ---------- * Wed Feb 16 2005 Jindrich Novy 382-6 - add patch for proper detection of UTF-8 locale, patch from Peter Rockai net-tools-1.60-46 ----------------- * Wed Feb 16 2005 Radek Vokal 1.60-46 - small typo in german translation (#148775) octave-6:2.1.57-11 ------------------ * Wed Feb 16 2005 Ivana Varekova 2.1.57-11 - add $RPM_OPT_FLAGS rpmdb-fedora-1:4-0.20050217 --------------------------- slocate-2.7-15 -------------- * Wed Feb 16 2005 Miloslav Trmac - 2.7-15 - Fix slocate-2.7-fts.patch - Automatically prune all nodev filesystems, remove those entries from PRUNEFS (#123914) squid-7:2.5.STABLE8-2 --------------------- * Wed Feb 16 2005 Jay Fenlason 7:2.5.STABLE8-2 - new upstream version with 4 upstream patches. - Reorganize spec file to apply upstream patches first * Tue Feb 01 2005 Jay Fenlason 7:2.5.STABLE7-4 - Include two more upstream patches for security vulns: bz#146783 Correct handling of oversized reply headers bz#146778 CAN-2005-0211 Buffer overflow in WCCP recvfrom() call * Tue Jan 25 2005 Jay Fenlason 7:2.5.STABLE7-3 - Include more upstream patches, including two for security holes. system-config-printer-0.6.123-1 ------------------------------- * Wed Feb 16 2005 Tim Waugh 0.6.123-1 - 0.6.123: - One more instance of needing to demangle the queue name (bug #147330). - Use RPM_OPT_FLAGS. From dcbw at redhat.com Thu Feb 17 12:33:56 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 17 Feb 2005 07:33:56 -0500 (EST) Subject: NetworkManager In-Reply-To: <1108643093.2791.3.camel@p.linuxcenter.cl> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> Message-ID: On Thu, 17 Feb 2005, Patricio Bruna V wrote: > El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: > >Patricio Bruna V wrote: > >> i just install NetworkManager and NetworkManager-gnome > >> but i can't find the applet that supose to allow me change networks. > > > >Be sure the NetworkManager service is running (service NetworkManager > >status) then run NetworkManagerInfo, you should see a little icon > >appearing in Gnome's notification area. > > > >I've been playing with the applet for a little while now and it's work > >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop > >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again > >and again.. very very annoying. > > > >If anyone knows how to tell NetworkManager to leave my resolv.conf or at > >least to fill it with the servers sent by the DHCP server.... > > > > > I can't see the icon you mentiont, and i have the same problem that you > with /etc/resolv.conf Can you guys post the output of the "Server replied with DHCP options:" part of /var/log/messages? Dan From ml2news at optonline.net Thu Feb 17 13:26:16 2005 From: ml2news at optonline.net (Mathieu Chouquet-Stringer) Date: Thu, 17 Feb 2005 08:26:16 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <20050217112257.755a4fc2@nausicaa.camperquake.de> References: <20050217112257.755a4fc2@nausicaa.camperquake.de> Message-ID: fedora-devel at camperquake.de (Ralf Ertzinger) writes: > Does this really pay off? I for one would be glad for a switch to disable > this. The only time it's really a real pain imho is when you run your own kernel because hardlinks is going to update your kernel tree and change ownership to root on a bunch of files. -- Mathieu Chouquet-Stringer E-Mail: ml2news at optonline.net "Le disparu, si l'on v?n?re sa m?moire, est plus pr?sent et plus puissant que le vivant". -- Antoine de Saint-Exup?ry, Citadelle -- From paul at all-the-johnsons.co.uk Thu Feb 17 13:26:46 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 17 Feb 2005 13:26:46 +0000 Subject: rawhide report: 20050217 changes In-Reply-To: <200502171222.j1HCMKxu016651@porkchop.devel.redhat.com> References: <200502171222.j1HCMKxu016651@porkchop.devel.redhat.com> Message-ID: <1108646806.5079.19.camel@localhost.localdomain> Hi, Is it me or does libraw1394 need updating? Without it, I can't update kdebase(-devel), libavc1394, dvgrab, gstreamer-plugin or libquicktime. TTFN Paul -- "I like blinking me" - Helen, Big Brother 2 contestant -------------- next part -------------- A 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 fedora-devel at camperquake.de Thu Feb 17 13:30:21 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 14:30:21 +0100 Subject: Running with vm.overcommit_memory=2 Message-ID: <20050217143021.35815547@nausicaa.camperquake.de> Hi. After having firefox killed by the OOM-killer due to a totem running wild (and watching the killer churn the disks for 5 minutes to do so, what the heck is it doing?), I ventured to try a hard overcommit limit (which setting vm.overcommit_memory=2 does, to the best of my knowledge). The system in question has 640MB RAM, no swap. The result is that almost nothing works, even with plenty of memory free. It's even impossible to get a simple man page to display: [sun at nausicaa ~/src/gmemusage-0.2 :) 23]$ free total used free shared buffers cached Mem: 645152 366636 278516 0 16900 106340 -/+ buffers/cache: 243396 401756 Swap: 0 0 0 [sun at nausicaa ~/src/gmemusage-0.2 :) 24]$ man sysctl sh: fork: Cannot allocate memory sh: fork: Cannot allocate memory Error executing formatting or display command. System command (cd /usr/share/man && (echo ".ll 11.8i"; echo ".pl 1100i"; /usr/bin/gunzip -c '/usr/share/man/man8/sysctl.8.gz'; echo ".\\\""; echo ".pl \n(nlu+10") | /usr/bin/gtbl | nroff --legacy ISO-8859-1 -man -rLL=129n -rLT=129n 2>/dev/null | /usr/bin/less -iRs) exited with status 32768. No manual entry for sysctl The system has nearly 400MB of free memory. What does it take to display some lines of text these days? -- "It's one of those irregular verbs: I explore the possibilities of computing, you hack, he has been charged under section 2 of the computer misuse act..." -- Richard Watts From rahulsundaram at yahoo.co.in Thu Feb 17 13:34:21 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 17 Feb 2005 05:34:21 -0800 (PST) Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217143021.35815547@nausicaa.camperquake.de> Message-ID: <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> --- Ralf Ertzinger wrote: > Hi. > > After having firefox killed by the OOM-killer due to > a totem running wild > (and watching the killer churn the disks for 5 > minutes to do so, what the heck > is it doing?), I ventured to try a hard overcommit > limit (which setting > vm.overcommit_memory=2 does, to the best of my > knowledge). The system in > question has 640MB RAM, no swap. > > The result is that almost nothing works, even with > plenty of memory free. > It's even impossible to get a simple man page to > display: a bug report with other important information like the exact ernel version number would be useful ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From rdieter at math.unl.edu Thu Feb 17 13:36:05 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 Feb 2005 07:36:05 -0600 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217143021.35815547@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> Message-ID: <42149DC5.7000903@math.unl.edu> Ralf Ertzinger wrote: > The system in question has 640MB RAM, no swap. I wouldn't even think about running a system with *0* swap these days. -- Rex From hk at isphuset.no Thu Feb 17 13:37:56 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 17 Feb 2005 14:37:56 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217143021.35815547@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> Message-ID: <1108647475.30301.14.camel@linux.local> > After having firefox killed by the OOM-killer due to a totem running wild > (and watching the killer churn the disks for 5 minutes to do so, what the heck > is it doing?), I ventured to try a hard overcommit limit (which setting > vm.overcommit_memory=2 does, to the best of my knowledge). The system in > question has 640MB RAM, no swap. Running completely without swap is know to be dangerous.. -HK From dstolte at arcor.de Thu Feb 17 14:04:49 2005 From: dstolte at arcor.de (D. Stolte) Date: Thu, 17 Feb 2005 15:04:49 +0100 Subject: rawhide report: 20050217 changes In-Reply-To: <1108646806.5079.19.camel@localhost.localdomain> References: <200502171222.j1HCMKxu016651@porkchop.devel.redhat.com> <1108646806.5079.19.camel@localhost.localdomain> Message-ID: <4214A481.8010803@arcor.de> i guess you have libquicktime from freshrpms and that needs an update. /ds Paul schrieb: > Hi, > > Is it me or does libraw1394 need updating? Without it, I can't update > kdebase(-devel), libavc1394, dvgrab, gstreamer-plugin or libquicktime. > > TTFN > > Paul > From fedora-devel at camperquake.de Thu Feb 17 14:08:26 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 15:08:26 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> Message-ID: <20050217150826.10382e70@nausicaa.camperquake.de> Hi. Rahul Sundaram wrote: > a bug report with other important information like the > exact ernel version number would be useful A bug report against what? I do not think this is the kernels fault. The kernel I tried on was 2.6.10-1.1143_FC4 -- Q. How many people does it take to change a lightbulb on Usenet? A. 1 to say the light's out, 100 to say "Yes, I noticed that", and 1,000 to post requests for FTP sites with free software that replaces lightbulbs. Meanwhile, it's still dark. From rahulsundaram at gmail.com Thu Feb 17 14:14:24 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Thu, 17 Feb 2005 19:44:24 +0530 Subject: no keyboard with 2.6.10 kernels In-Reply-To: References: <20050216165456.176108a9@muk.mgl> Message-ID: On Thu, 17 Feb 2005 00:10:34 -0500, Gerald Henriksen wrote: > On Wed, 16 Feb 2005 16:54:56 -0800, you wrote: > > >Try booting with "usb-handoff" - this works for me on a dual xeon with > >i7505 chipset and smp kernels: it's worth a go on the laptop. > > Thanks for the suggestion but it didn't help. > please file a bug report against the kernel in bugzilla.redhat.com -- Regards, Rahul Sundaram From tjb at unh.edu Thu Feb 17 14:25:26 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 17 Feb 2005 09:25:26 -0500 Subject: NetworkManager In-Reply-To: <1108643093.2791.3.camel@p.linuxcenter.cl> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> Message-ID: <1108650326.1324.1.camel@wintermute.sr.unh.edu> On Thu, 2005-02-17 at 09:24 -0300, Patricio Bruna V wrote: > El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: > >Patricio Bruna V wrote: > >> i just install NetworkManager and NetworkManager-gnome > >> but i can't find the applet that supose to allow me change networks. > > > >Be sure the NetworkManager service is running (service NetworkManager > >status) then run NetworkManagerInfo, you should see a little icon > >appearing in Gnome's notification area. > > > >I've been playing with the applet for a little while now and it's work > >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop > >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again > >and again.. very very annoying. > > > >If anyone knows how to tell NetworkManager to leave my resolv.conf or at > >least to fill it with the servers sent by the DHCP server.... > > > > > I can't see the icon you mentiont, and i have the same problem that you > with /etc/resolv.conf > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list It's a know bug that it breaks the resolv.conf search: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146389 Also, NetworkManager-gnome is not an applet but a tray icon. You must have a system tray running to see it. tjb --- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From fedora-devel at camperquake.de Thu Feb 17 14:32:49 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 15:32:49 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <42149DC5.7000903@math.unl.edu> References: <20050217143021.35815547@nausicaa.camperquake.de> <42149DC5.7000903@math.unl.edu> Message-ID: <20050217153249.1dbd35f8@nausicaa.camperquake.de> Hi. Rex Dieter wrote: > I wouldn't even think about running a system with *0* swap these days. Throwing (virtual) memory at the problem is certainly going to make it go away, I am sure. It just is not right. 640MB is not exactly a small amount of memory (be it real or virtual). -- Quantum Mechanics: The dreams stuff is made of. From hk at isphuset.no Thu Feb 17 14:38:12 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 17 Feb 2005 15:38:12 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217153249.1dbd35f8@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <42149DC5.7000903@math.unl.edu> <20050217153249.1dbd35f8@nausicaa.camperquake.de> Message-ID: <1108651092.30182.17.camel@linux.local> On Thu, 2005-02-17 at 15:32, Ralf Ertzinger wrote: > Hi. > > Rex Dieter wrote: > > > I wouldn't even think about running a system with *0* swap these days. > > Throwing (virtual) memory at the problem is certainly going to make it > go away, I am sure. It just is not right. 640MB is not exactly a small > amount of memory (be it real or virtual). But the kernel has been known to behave strangely when it does not have ANY swap space at all. Even 10MB could solve the problem. I don't know what the technical problem is but I have had customers with just this problem where it could be solved perfectly with just a little 10MB swapfile. -HK From stan at ccs.neu.edu Thu Feb 17 15:56:59 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Thu, 17 Feb 2005 10:56:59 -0500 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217150826.10382e70@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> Message-ID: <4214BECB.5040908@ccs.neu.edu> Ralf Ertzinger wrote: > A bug report against what? I do not think this is the kernels fault. > The kernel I tried on was 2.6.10-1.1143_FC4 > I wouldn't make the assumption that its not the kernel, seems like its the kernel for sure? For instance: sh: fork: Cannot allocate memory sh: fork: Cannot allocate memory This is not a good sign when you have free memory, but on the surface this does indeed to be a kernel problem... who you think decides there is no memory? :) -sb From pbruna at linuxcenterla.com Thu Feb 17 16:32:35 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Thu, 17 Feb 2005 13:32:35 -0300 Subject: NetworkManager In-Reply-To: <1108650326.1324.1.camel@wintermute.sr.unh.edu> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> <1108650326.1324.1.camel@wintermute.sr.unh.edu> Message-ID: <1108657955.2791.28.camel@p.linuxcenter.cl> El jue, 17-02-2005 a las 09:25 -0500, Thomas J. Baker escribi?: >On Thu, 2005-02-17 at 09:24 -0300, Patricio Bruna V wrote: >> El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: >> >Patricio Bruna V wrote: >> >> i just install NetworkManager and NetworkManager-gnome >> >> but i can't find the applet that supose to allow me change networks. >> > >> >Be sure the NetworkManager service is running (service NetworkManager >> >status) then run NetworkManagerInfo, you should see a little icon >> >appearing in Gnome's notification area. >> >> >> >I've been playing with the applet for a little while now and it's work >> >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop >> >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again >> >and again.. very very annoying. >> > >> >If anyone knows how to tell NetworkManager to leave my resolv.conf or at >> >least to fill it with the servers sent by the DHCP server.... >> > >> > >> I can't see the icon you mentiont, and i have the same problem that you >> with /etc/resolv.conf >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-devel-list > >It's a know bug that it breaks the resolv.conf search: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146389 > >Also, NetworkManager-gnome is not an applet but a tray icon. You must >have a system tray running to see it. just like gaim, so i must see it beside gaim, yes? i dont see it -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 4834041 -------------- next part -------------- A 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 tjb at unh.edu Thu Feb 17 16:36:24 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 17 Feb 2005 11:36:24 -0500 Subject: NetworkManager In-Reply-To: <1108657955.2791.28.camel@p.linuxcenter.cl> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> <1108650326.1324.1.camel@wintermute.sr.unh.edu> <1108657955.2791.28.camel@p.linuxcenter.cl> Message-ID: <1108658184.1324.6.camel@wintermute.sr.unh.edu> On Thu, 2005-02-17 at 13:32 -0300, Patricio Bruna V wrote: > El jue, 17-02-2005 a las 09:25 -0500, Thomas J. Baker escribi?: > >On Thu, 2005-02-17 at 09:24 -0300, Patricio Bruna V wrote: > >> El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: > >> >Patricio Bruna V wrote: > >> >> i just install NetworkManager and NetworkManager-gnome > >> >> but i can't find the applet that supose to allow me change networks. > >> > > >> >Be sure the NetworkManager service is running (service NetworkManager > >> >status) then run NetworkManagerInfo, you should see a little icon > >> >appearing in Gnome's notification area. > >> > >> > >> >I've been playing with the applet for a little while now and it's work > >> >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop > >> >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again > >> >and again.. very very annoying. > >> > > >> >If anyone knows how to tell NetworkManager to leave my resolv.conf or at > >> >least to fill it with the servers sent by the DHCP server.... > >> > > >> > > >> I can't see the icon you mentiont, and i have the same problem that you > >> with /etc/resolv.conf > >> -- > >> fedora-devel-list mailing list > >> fedora-devel-list at redhat.com > >> http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > >It's a know bug that it breaks the resolv.conf search: > > > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146389 > > > >Also, NetworkManager-gnome is not an applet but a tray icon. You must > >have a system tray running to see it. > just like gaim, so i must see it beside gaim, yes? i dont see it Yes, that should work. tjb --- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From fedora-devel at camperquake.de Thu Feb 17 16:44:37 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 17:44:37 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <4214BECB.5040908@ccs.neu.edu>; from stan@ccs.neu.edu on Thu, Feb 17, 2005 at 10:56:59AM -0500 References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> Message-ID: <20050217174437.A16952@ryoko.camperquake.de> On Thu, Feb 17, 2005 at 10:56:59AM -0500, Stan Bubrouski wrote: > sh: fork: Cannot allocate memory > sh: fork: Cannot allocate memory > > This is not a good sign when you have free memory, but on the surface > this does indeed to be a kernel problem... who you think decides there > is no memory? :) Of course it is the kernel that ultimately decides if a memory request can be served. But after all it is the application that requests the memory (in most cases, that is), and various programs allocate large chunks of memory but never use it. This does not matter much when you have overcommit on, but fails without it. In this special case however a strace shows that the clone() system call fails with -ENOMEM, which is a bit strange, at least for me. So it seems I will file a kernel bug for this after all. From scottb at bxwa.com Thu Feb 17 16:50:42 2005 From: scottb at bxwa.com (Scott Becker) Date: Thu, 17 Feb 2005 08:50:42 -0800 Subject: freenx? In-Reply-To: <20050210123555.780.qmail@web8505.mail.in.yahoo.com> References: <20050210123555.780.qmail@web8505.mail.in.yahoo.com> Message-ID: <4214CB62.2090701@bxwa.com> I thought 'building' and compile errors were development questions. Rahul Sundaram wrote: >>Has anyone had any success building freenx on FC3? >> >> > >this is the development list. please ask your question >in the fedora users list > > From kyrre at solution-forge.net Thu Feb 17 16:49:50 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 17 Feb 2005 17:49:50 +0100 Subject: RPM needs to go on a diet. In-Reply-To: <421413BB.3030106@nc.rr.com> References: <421413BB.3030106@nc.rr.com> Message-ID: <1108658989.3579.7.camel@localhost.localdomain> tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson: > Kenneth Porter wrote: > > > --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen > > wrote: > > > >> The kernel package runs hardlink on /lib/modules/*/build/ in %post to > >> save space on FC2 and FC3, that's what's taking so long when installing > >> and removing kernels. > > > > > > What does hardlink do? There appears to be no man page or other > > documentation for it in kernel-utils. > > > Hardlinks's identical files to save space. Why are hardlinks chosen over symlinks here? From elanthis at awesomeplay.com Thu Feb 17 16:52:32 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 17 Feb 2005 11:52:32 -0500 Subject: freenx? In-Reply-To: <4214CB62.2090701@bxwa.com> References: <20050210123555.780.qmail@web8505.mail.in.yahoo.com> <4214CB62.2090701@bxwa.com> Message-ID: <1108659152.5217.8.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2005-02-17 at 08:50 -0800, Scott Becker wrote: >I thought 'building' and compile errors were development questions. fedora-devel is for development of the distribution itself, not individual applications you want to use or develop. fedora-list is for users of Fedora, including people "using" the system to build or develop software. > >Rahul Sundaram wrote: > >>>Has anyone had any success building freenx on FC3? >>> >>> >> >>this is the development list. please ask your question >>in the fedora users list >> >> > -- Sean Middleditch From kyrre at solution-forge.net Thu Feb 17 16:55:20 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 17 Feb 2005 17:55:20 +0100 Subject: NetworkManager In-Reply-To: <1108658184.1324.6.camel@wintermute.sr.unh.edu> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> <1108650326.1324.1.camel@wintermute.sr.unh.edu> <1108657955.2791.28.camel@p.linuxcenter.cl> <1108658184.1324.6.camel@wintermute.sr.unh.edu> Message-ID: <1108659320.3579.9.camel@localhost.localdomain> tor, 17.02.2005 kl. 17.36 skrev Thomas J. Baker: > On Thu, 2005-02-17 at 13:32 -0300, Patricio Bruna V wrote: > > El jue, 17-02-2005 a las 09:25 -0500, Thomas J. Baker escribi?: > > >On Thu, 2005-02-17 at 09:24 -0300, Patricio Bruna V wrote: > > >> El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: > > >> >Patricio Bruna V wrote: > > >> >> i just install NetworkManager and NetworkManager-gnome > > >> >> but i can't find the applet that supose to allow me change networks. > > >> > > > >> >Be sure the NetworkManager service is running (service NetworkManager > > >> >status) then run NetworkManagerInfo, you should see a little icon > > >> >appearing in Gnome's notification area. > > >> > > >> > > >> >I've been playing with the applet for a little while now and it's work > > >> >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop > > >> >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again > > >> >and again.. very very annoying. > > >> > > > >> >If anyone knows how to tell NetworkManager to leave my resolv.conf or at > > >> >least to fill it with the servers sent by the DHCP server.... > > >> > > > >> > > > >> I can't see the icon you mentiont, and i have the same problem that you > > >> with /etc/resolv.conf > > >> -- > > >> fedora-devel-list mailing list > > >> fedora-devel-list at redhat.com > > >> http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > >It's a know bug that it breaks the resolv.conf search: > > > > > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146389 > > > > > >Also, NetworkManager-gnome is not an applet but a tray icon. You must > > >have a system tray running to see it. > > just like gaim, so i must see it beside gaim, yes? i dont see it > > Yes, that should work. *probably completely stupid* - you did start NetworkManagerInfo? From fedora-devel at camperquake.de Thu Feb 17 16:59:44 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 17:59:44 +0100 Subject: RPM needs to go on a diet. In-Reply-To: <1108658989.3579.7.camel@localhost.localdomain>; from kyrre@solution-forge.net on Thu, Feb 17, 2005 at 05:49:50PM +0100 References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> Message-ID: <20050217175944.B16952@ryoko.camperquake.de> On Thu, Feb 17, 2005 at 05:49:50PM +0100, Kyrre Ness Sjobak wrote: > Why are hardlinks chosen over symlinks here? That's what hardlinks are for. Multiple file system entries to the same datablocks on disk, so the disk allocation disappears when the last entry is unlink()ed. Symlinks can not do this. From elanthis at awesomeplay.com Thu Feb 17 17:00:15 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 17 Feb 2005 12:00:15 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <1108658989.3579.7.camel@localhost.localdomain> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> Message-ID: <1108659615.5217.10.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2005-02-17 at 17:49 +0100, Kyrre Ness Sjobak wrote: >Why are hardlinks chosen over symlinks here? If you used symlinks, then when you removed a kernel, you migth end up removing the only real copy of a file. With hardlinks, you remove a kernel, it'll only remove one instance of the file, and the others will remain, until all kernels using that file are removed. > -- Sean Middleditch From Nigel.Metheringham at dev.intechnology.co.uk Thu Feb 17 17:00:39 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 17 Feb 2005 17:00:39 +0000 Subject: RPM needs to go on a diet. In-Reply-To: <1108658989.3579.7.camel@localhost.localdomain> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> Message-ID: <1108659639.20532.66.camel@angua.localnet> On Thu, 2005-02-17 at 17:49 +0100, Kyrre Ness Sjobak wrote: > Why are hardlinks chosen over symlinks here? Short answer: Think what happens when you delete a package. Longer answer: install kernel-1.0-1 - modules are just put into /lib/mod... install kernel-1.0-2 - modules added, then converted to symlinks [now rpm -Vv fails because there are symlinks, not files] remove kernel-1.0-1 now kernel-1.0-2 has dangling symlinks (oh, and you can't boot either) Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From fedora-devel at camperquake.de Thu Feb 17 18:04:25 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Feb 2005 19:04:25 +0100 Subject: RPM needs to go on a diet. In-Reply-To: <1108659639.20532.66.camel@angua.localnet> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <1108659639.20532.66.camel@angua.localnet> Message-ID: <20050217190425.2600efef@nausicaa.camperquake.de> Hi. Nigel Metheringham wrote: > (oh, and you can't boot either) Huh? What files (except those covered in kernel-devel now) are being hardlinked? I thought all module files are versioned, so modules from different kernel builds are not identical. -- Ergometer = Schlussfolgerungsmessgeraet From orion at cora.nwra.com Thu Feb 17 18:24:58 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Feb 2005 11:24:58 -0700 Subject: Keeping external kernel modules up to date with yum Message-ID: <4214E17A.6020402@cora.nwra.com> Is there a standard way for keeping external kernel modules up to date via yum? Apparently the standard is for the package name be "kernel-module--". But with the "name" of the package containing the kernel version, new versions for new kernels look like new packages, not updates. Is anyone building external modules for FC3? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From n3npq at nc.rr.com Thu Feb 17 18:58:13 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 17 Feb 2005 13:58:13 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <1108658989.3579.7.camel@localhost.localdomain> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> Message-ID: <4214E945.7000208@nc.rr.com> Kyrre Ness Sjobak wrote: >tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson: > > >>Kenneth Porter wrote: >> >> >> >>>--On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen >>> wrote: >>> >>> >>> >>>>The kernel package runs hardlink on /lib/modules/*/build/ in %post to >>>>save space on FC2 and FC3, that's what's taking so long when installing >>>>and removing kernels. >>>> >>>> >>>What does hardlink do? There appears to be no man page or other >>>documentation for it in kernel-utils. >>> >>> >>Hardlinks's identical files to save space. >> >> > >Why are hardlinks chosen over symlinks here? > Because symlinks behave differently than files in vcertain contexts, hardlinks are always the same as files. Look there's a really simple answer to hardlinks and rpm and more: Choose a kernel, use that. Chose another kernel, use that, get rid of previous. With one (or very few) kernels installed, hardlink and rpm performance is a non-issue. 73 de Jeff From fedora-devel at tlarson.com Thu Feb 17 19:06:12 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Thu, 17 Feb 2005 12:06:12 -0700 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <1108651092.30182.17.camel@linux.local> References: <20050217143021.35815547@nausicaa.camperquake.de> <42149DC5.7000903@math.unl.edu> <20050217153249.1dbd35f8@nausicaa.camperquake.de> <1108651092.30182.17.camel@linux.local> Message-ID: <4214EB24.50300@tlarson.com> Hans Kristian Rosbach wrote: > But the kernel has been known to behave strangely when it does not have > ANY swap space at all. Even 10MB could solve the problem. That would, then, point to a kernel bug that needs to be fixed. Swap space is a luxury that not all systems have. Most embedded environments don't even have disks. Adding swap isn't a solution--it's a workaround. If, indeed, it *does* fix your problem, you should include that detail in your bug report. From michael.favia at insitesinc.com Thu Feb 17 19:16:59 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 17 Feb 2005 13:16:59 -0600 Subject: RPM needs to go on a diet. In-Reply-To: <4214E945.7000208@nc.rr.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> Message-ID: <4214EDAB.7050101@insitesinc.com> Jeff Johnson wrote: > Kyrre Ness Sjobak wrote: > >> tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson: >> >> >>> Kenneth Porter wrote: >>> >>> >>> >>>> --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen >>>> wrote: >>>> >>>> >>>> >>>>> The kernel package runs hardlink on /lib/modules/*/build/ in %post to >>>>> save space on FC2 and FC3, that's what's taking so long when >>>>> installing >>>>> and removing kernels. >>>>> >>>> >>>> What does hardlink do? There appears to be no man page or other >>>> documentation for it in kernel-utils. >>>> >>> >>> Hardlinks's identical files to save space. >>> >> >> >> Why are hardlinks chosen over symlinks here? >> > > Look there's a really simple answer to hardlinks and rpm and more: > > Choose a kernel, use that. > > Chose another kernel, use that, get rid of previous. > > With one (or very few) kernels installed, hardlink and rpm performance > is a non-issue. At a cursory glance, arbitrarily limiting the ability to rollback kernel upgrades (to a small or larger extent) seems a poor fix. Discovering kernel flaws or bugs doenst necessarily happen the first time you use the new kernel and may lay hidden for some time. In my company dictating acceptable use (outside of normal operating bounds, and without very good reason) is seen as a red herring of poor design (no implications intended). I suppose you could just go find and download the older kernels to test but i honestly dont know where to find archived versions of kernel updates (that is: not base and not most recent update). Perhaps i am the only one who doesnt know where to find such things or maybe information on that subject will reduce the need to keep the kernels installed. I dont know the issues involved but i hesitate when i hear answers like the above suggestion to problems like these. -mf From arnaud.abelard at univ-nantes.fr Thu Feb 17 19:17:36 2005 From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=) Date: Thu, 17 Feb 2005 20:17:36 +0100 Subject: NetworkManager In-Reply-To: References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> Message-ID: <4214EDD0.4060607@univ-nantes.fr> > Can you guys post the output of the "Server replied with DHCP options:" part > of /var/log/messages? hum.. i've got nothing like that in my /var/log/messages... Arnaud > > Dan > From n3npq at nc.rr.com Thu Feb 17 19:33:24 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 17 Feb 2005 14:33:24 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <4214EDAB.7050101@insitesinc.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> Message-ID: <4214F184.6020203@nc.rr.com> Michael Favia wrote: > Jeff Johnson wrote: > >> Kyrre Ness Sjobak wrote: >> >>> tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson: >>> >>> >>>> Kenneth Porter wrote: >>>> >>>> >>>> >>>>> --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> The kernel package runs hardlink on /lib/modules/*/build/ in >>>>>> %post to >>>>>> save space on FC2 and FC3, that's what's taking so long when >>>>>> installing >>>>>> and removing kernels. >>>>>> >>>>> >>>>> >>>>> What does hardlink do? There appears to be no man page or other >>>>> documentation for it in kernel-utils. >>>>> >>>> >>>> >>>> Hardlinks's identical files to save space. >>>> >>> >>> >>> >>> Why are hardlinks chosen over symlinks here? >>> >> >> Look there's a really simple answer to hardlinks and rpm and more: >> >> Choose a kernel, use that. >> >> Chose another kernel, use that, get rid of previous. >> >> With one (or very few) kernels installed, hardlink and rpm >> performance is a non-issue. > > > At a cursory glance, arbitrarily limiting the ability to rollback > kernel upgrades (to a small or larger extent) seems a poor fix. > Discovering kernel flaws or bugs doenst necessarily happen the first > time you use the new kernel and may lay hidden for some time. In my > company dictating acceptable use (outside of normal operating bounds, > and without very good reason) is seen as a red herring of poor design > (no implications intended). I suppose you could just go find and > download the older kernels to test but i honestly dont know where to > find archived versions of kernel updates (that is: not base and not > most recent update). Perhaps i am the only one who doesnt know where > to find such things or maybe information on that subject will reduce > the need to keep the kernels installed. I dont know the issues > involved but i hesitate when i hear answers like the above suggestion > to problems like these. All very well known problems. As long as you can boot off *some* kernel, any desired kernel package can be installed. So "choose" carefully. And if you miss, well, always keep some way to boot, and copy available kernel packages out of /var/cache/yum somewhere so the yum clean does not nuke. Or have every possible bleeping kernel already pre-installed and never remove anything. Unfortunately, that exercises known deficiencies with both rpm and hardlinks, and is slower than optimal, so take valium and be patient. Entirely up to you, it's your machine. 73 de Jeff From jspaleta at gmail.com Thu Feb 17 19:45:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 Feb 2005 14:45:50 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <4214F184.6020203@nc.rr.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> Message-ID: <604aa791050217114562fda93a@mail.gmail.com> On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson wrote: > Or have every possible bleeping kernel already pre-installed and never > remove anything. > Unfortunately, that exercises known deficiencies with both rpm and > hardlinks, and is > slower than optimal, so take valium and be patient. The question becomes... can someone expose reasonable sane default behavior of some tool to do old kernel pruning... to avoid normal fedora users from encountering these deficiencies when you have 17 or so update kernels installed. -jef From notting at redhat.com Thu Feb 17 19:51:45 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 Feb 2005 14:51:45 -0500 Subject: kudzu network weirdness In-Reply-To: <1108568222.4323.0.camel@localhost.localdomain> References: <1108491286l.6481l.0l@devel.mpeters.us> <20050215184043.GA21144@nostromo.devel.redhat.com> <1108494540l.6481l.1l@devel.mpeters.us> <20050215192255.GA5475@nostromo.devel.redhat.com> <1108568222.4323.0.camel@localhost.localdomain> Message-ID: <20050217195145.GB10656@nostromo.devel.redhat.com> Kyrre Ness Sjobak (kyrre at solution-forge.net) said: > > Unfortunately, without that, it's a good deal harder to consistently > > tie configurations to cards on card changes, and so the right thing > > may not happen. > > Then why isn't this done by kudzu (or the tool that configures the cards > in the first hand)? It is (at least, the code is there.) Bill From skvidal at phy.duke.edu Thu Feb 17 19:58:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 17 Feb 2005 14:58:09 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <604aa791050217114562fda93a@mail.gmail.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> Message-ID: <1108670289.8029.2.camel@cutter> On Thu, 2005-02-17 at 14:45 -0500, Jeff Spaleta wrote: >On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson wrote: >> Or have every possible bleeping kernel already pre-installed and never >> remove anything. >> Unfortunately, that exercises known deficiencies with both rpm and >> hardlinks, and is >> slower than optimal, so take valium and be patient. > > >The question becomes... can someone expose reasonable sane default >behavior of some tool to do old kernel pruning... to avoid normal >fedora users from encountering these deficiencies when you have 17 or >so update kernels installed. I may be able to do so. keep the kernel you're running and all newer than that. older kernels, remove. have a text file which can specify kernels-versions to keep/ignore from removal. -sv From notting at redhat.com Thu Feb 17 19:54:56 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 Feb 2005 14:54:56 -0500 Subject: rawhide report: 20050216 changes In-Reply-To: <20050216142558.GC4065@joshua.mesa.nl> References: <200502161257.j1GCv6jV030217@porkchop.devel.redhat.com> <20050216142558.GC4065@joshua.mesa.nl> Message-ID: <20050217195456.GC10656@nostromo.devel.redhat.com> Marcel J.E. Mol (marcel at mesa.nl) said: > On Wed, Feb 16, 2005 at 07:57:06AM -0500, Build System wrote: > > > > rpmdb-fedora-1:4-0.20050216 > > --------------------------- > > Does nobody care that rpmdb is still not on the ftp sites (not on the mirrors > and not on download.fedora.redhat.com)? Looks like the build of it is failing. Will fix. Bill From elanthis at awesomeplay.com Thu Feb 17 20:06:32 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 17 Feb 2005 15:06:32 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <604aa791050217114562fda93a@mail.gmail.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> Message-ID: <1108670792.5217.19.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2005-02-17 at 14:45 -0500, Jeff Spaleta wrote: >On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson wrote: >> Or have every possible bleeping kernel already pre-installed and never >> remove anything. >> Unfortunately, that exercises known deficiencies with both rpm and >> hardlinks, and is >> slower than optimal, so take valium and be patient. > > >The question becomes... can someone expose reasonable sane default >behavior of some tool to do old kernel pruning... to avoid normal >fedora users from encountering these deficiencies when you have 17 or >so update kernels installed. This is a script I've been using on two Rawhide boxes. (Well, actually, it's the version I use on this box; the version on the other box is different and a bit better, but it's not online right now.) It displays a list of installed kernels, except for the newest kernel and the currently running kernel, and lets you pick the ones you want to remove. It's graphical (uses Zenity), but could easily be changed to be console-only if someone really wanted to. The other version I have knew how to remove some related packages like kernel-devel, but it also wasn't quite as bright about some other things; it's been a while, I forget what all the differences between the two scripts were. This is definitely not the ideal tool for the problem, but it's something other Rawhide users might find useful, so here it is. > >-jef > -- Sean Middleditch -------------- next part -------------- A non-text attachment was scrubbed... Name: remove-kernels.sh Type: application/x-shellscript Size: 918 bytes Desc: not available URL: From jwz at jwz.org Thu Feb 17 20:07:57 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Thu, 17 Feb 2005 12:07:57 -0800 Subject: RPM needs to go on a diet. References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <1108670289.8029.2.camel@cutter> Message-ID: <4214F99D.1FFEC70C@jwz.org> seth vidal wrote: > > keep the kernel you're running and all newer than that. > > older kernels, remove. > > have a text file which can specify kernels-versions to keep/ignore > from removal. I'd rather see "keep the kernel you're running, and the most recent." If I run yum regularly but only reboot every couple of months, I can end up with half a dozen kernels on my disk that I have not yet ever booted, and now never will. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From michael.favia at insitesinc.com Thu Feb 17 20:14:28 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 17 Feb 2005 14:14:28 -0600 Subject: RPM needs to go on a diet. In-Reply-To: <604aa791050217114562fda93a@mail.gmail.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> Message-ID: <4214FB24.4040109@insitesinc.com> Jeff Spaleta wrote: >On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson wrote: > > >>Or have every possible bleeping kernel already pre-installed and never >>remove anything. >>Unfortunately, that exercises known deficiencies with both rpm and >>hardlinks, and is >>slower than optimal, so take valium and be patient. >> >> > > >The question becomes... can someone expose reasonable sane default >behavior of some tool to do old kernel pruning... to avoid normal >fedora users from encountering these deficiencies when you have 17 or >so update kernels installed. > > For me this issue and others (plugins, kernel modules, missingok/optional features) seem to bolster the claim for a more interactive Yum or at least yum mode. A yum that poses a few simple question to the user like: You have 7 kernels installed we recommend that you keep the number of kernels installed concurrently fewer than 3 would you like to remove some of them? Yes all but the most recent 3. No keep your grimy hands off my kernels. or Mplayer-plugin requires either mozilla or firefox to be present which would you like to install? Mozilla (X Megs) Firefox (X Megs) or The followng plugins depend on gaim but are not installed woudl you like to add these features? I am only halfheartedly trying to make these make sense and the last one might require a rpm flag or something, but the functioanlity would be appreciated by a great numebr of users i think. Managing the changes so that users arent overwhelmed with options and confused is the key to adding this functionality sanely but i think that it can be done and should be done eventually. Obvioulsy a Yum based GUI tool would handle this type of interactivity more adeptly becuase of the multiple selections that are made by the user. If there is genuine interest id be happy to mockup an User interaction model that might help ease some of these and other pains while providing the user with a simple and useful software upgrade interface. IMO as the number of packages continue to increase we need to be able to provide users with this type of information instead otf the raw data we are asking them to sort through right now. -mf From hp at redhat.com Thu Feb 17 20:23:37 2005 From: hp at redhat.com (Havoc Pennington) Date: Thu, 17 Feb 2005 15:23:37 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <4214FB24.4040109@insitesinc.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <4214FB24.4040109@insitesinc.com> Message-ID: <1108671817.21367.8.camel@localhost.localdomain> On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote: > For me this issue and others (plugins, kernel modules, > missingok/optional features) seem to bolster the claim for a more > interactive Yum or at least yum mode. A yum that poses a few simple > question to the user like: > > You have 7 kernels installed we recommend that you keep the number of > kernels installed concurrently fewer than 3 would you like to remove > some of them? > Yes all but the most recent 3. > No keep your grimy hands off my kernels. I wouldn't exactly describe this as a "simple question" ;-) The right approach is to just have a default garbage collection policy, and for the 0.25% or less of the world that wants something else have a config file where you can disable kernel GC entirely or pin certain versions so they won't be removed. Havoc From cmadams at hiwaay.net Thu Feb 17 20:24:39 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 17 Feb 2005 14:24:39 -0600 Subject: RPM needs to go on a diet. In-Reply-To: <1108671817.21367.8.camel@localhost.localdomain> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <4214FB24.4040109@insitesinc.com> <1108671817.21367.8.camel@localhost.localdomain> Message-ID: <20050217202439.GC1168387@hiwaay.net> Once upon a time, Havoc Pennington said: > The right approach is to just have a default garbage collection policy, > and for the 0.25% or less of the world that wants something else have a > config file where you can disable kernel GC entirely or pin certain > versions so they won't be removed. How about something like a default cron job (that can be easily disabled) that looks at how long you've been running a particular kernel? If you've been running for more than X days, remove everything older. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From elanthis at awesomeplay.com Thu Feb 17 20:25:34 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 17 Feb 2005 15:25:34 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <4214FB24.4040109@insitesinc.com> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <4214FB24.4040109@insitesinc.com> Message-ID: <1108671934.5217.28.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote: >Jeff Spaleta wrote: > >>On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson wrote: >> >> >>>Or have every possible bleeping kernel already pre-installed and never >>>remove anything. >>>Unfortunately, that exercises known deficiencies with both rpm and >>>hardlinks, and is >>>slower than optimal, so take valium and be patient. >>> >>> >> >> >>The question becomes... can someone expose reasonable sane default >>behavior of some tool to do old kernel pruning... to avoid normal >>fedora users from encountering these deficiencies when you have 17 or >>so update kernels installed. >> >> >For me this issue and others (plugins, kernel modules, >missingok/optional features) seem to bolster the claim for a more >interactive Yum or at least yum mode. A yum that poses a few simple >question to the user like: > >You have 7 kernels installed we recommend that you keep the number of >kernels installed concurrently fewer than 3 would you like to remove >some of them? > Yes all but the most recent 3. > No keep your grimy hands off my kernels. I'd much, much rather just see the proper and most correct behavior be added to Yum, instead of punting the issue and making the user handle it. Especially given the number of users that don't know, or want to know, the correct answer. Really, there's only two kernels you'd ever need, aside from specialty cases that normal users don't have to worry about. Those kernels are the currently running kernel, and the kernel you plan on getting on your next boot (i.e., the newest kernel). Simply making that the default behavior, with options or features for more advanced users to pin kernels or disable the behavior, would be far more beneficial for the average user, as well as greatly simplify the life of yum front-end and library users. > >or > >Mplayer-plugin requires either mozilla or firefox to be present which >would you like to install? > Mozilla (X Megs) > Firefox (X Megs) Same deal here. Better to just come up with a policy for picking one automatically. If a user is advanced enough to know which they want, they can install it explicitly with the plugin/add-on. > >or > >The followng plugins depend on gaim but are not installed woudl you like >to add these features? Now this is somewhat of a different issue. Being able to mark a package as an "add-on" to another could *really* help user-oriented package management tools. For example, if I open up the Application Manager, I *only* expect to see applications - not plugins or libraries or anything else. If I click on GAIM, it could then display a list of plugin package that are installed or available. By default, though, when initially installing GAIM, I dont' think you should ask the user, unless the user has explicitly stated that they want the control (i.e., a "confirm suggested packages" option that is off by default). Something like a "Suggests" field might work - those are the packages that GAIM doesn't need, but recommends are installed with it, which would be default behavior. -- Sean Middleditch From michael.favia at insitesinc.com Thu Feb 17 20:50:39 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 17 Feb 2005 14:50:39 -0600 Subject: RPM needs to go on a diet. In-Reply-To: <1108671817.21367.8.camel@localhost.localdomain> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <4214FB24.4040109@insitesinc.com> <1108671817.21367.8.camel@localhost.localdomain> Message-ID: <4215039F.6090708@insitesinc.com> Havoc Pennington wrote: >On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote: > > >>For me this issue and others (plugins, kernel modules, >>missingok/optional features) seem to bolster the claim for a more >>interactive Yum or at least yum mode. A yum that poses a few simple >>question to the user like: >> >>You have 7 kernels installed we recommend that you keep the number of >>kernels installed concurrently fewer than 3 would you like to remove >>some of them? >> Yes all but the most recent 3. >> No keep your grimy hands off my kernels. >> >> > >I wouldn't exactly describe this as a "simple question" ;-) > > Like i said half heartedly. And im not proposing this be a default operation but possible a mode of operation. Like the work on yum interactive that is going on right now. >The right approach is to just have a default garbage collection policy, >and for the 0.25% or less of the world that wants something else have a >config file where you can disable kernel GC entirely or pin certain >versions so they won't be removed. > > I agree. A good default behavior is in perfect line with my suggestion. Essentially i am proposing to have a system where the default operation satisfies most of the user base and you only enter interactive mode (in CLI or GUI) if you try a transaction and you dont like the suggestions or would like to know more options (like adding plugins to newly installed apps or choosing which 1 of the two applications that provide the same functionality (firefox, mozilla). To be prefectly clear i am not trying to punt the decision to the user. I wanted a good default option (current plus highest sounds best) with the ability for a user to make decisions should they desire to do so in this and other cases like i mentioned. The kernel argument isnt a huge one for this interactive mode. It just seemed to be one more piece that lended slightly to the argument for me. And im not proposing the interactive mode as default behavior but i think that there are a lot of issues like unknown plugins (to the user), and plugins that require either X or Y and i dont know how they are resolved at this time and i thought that it might be nice to try to flesh out a unified solution that simplifies the process using package management tools instead of cron jobs and scripts. Many new users to fedora dont know they need to download plugins to enhance programs and i was trying to give them a way to "discover" fedora using the same tool that they use to manage the installation of the new application. -mf From ghenriks at rogers.com Thu Feb 17 23:09:32 2005 From: ghenriks at rogers.com (Gerald Henriksen) Date: Thu, 17 Feb 2005 18:09:32 -0500 Subject: no keyboard with 2.6.10 kernels In-Reply-To: References: <20050216165456.176108a9@muk.mgl> Message-ID: <5v8a11tslft5b6aoqnre4dopfmoj12uq6d@4ax.com> On Thu, 17 Feb 2005 19:44:24 +0530, you wrote: >On Thu, 17 Feb 2005 00:10:34 -0500, Gerald Henriksen > wrote: >> On Wed, 16 Feb 2005 16:54:56 -0800, you wrote: >> >> >Try booting with "usb-handoff" - this works for me on a dual xeon with >> >i7505 chipset and smp kernels: it's worth a go on the laptop. >> >> Thanks for the suggestion but it didn't help. >> > >please file a bug report against the kernel in bugzilla.redhat.com Did that earlier, see bug 145854. From jspaleta at gmail.com Thu Feb 17 23:24:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 Feb 2005 18:24:12 -0500 Subject: RPM needs to go on a diet. In-Reply-To: <1108670289.8029.2.camel@cutter> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <1108670289.8029.2.camel@cutter> Message-ID: <604aa7910502171524bf95cca@mail.gmail.com> On Thu, 17 Feb 2005 14:58:09 -0500, seth vidal wrote: > I may be able to do so. > > keep the kernel you're running and all newer than that. > > older kernels, remove. > > have a text file which can specify kernels-versions to keep/ignore from > removal. would it make sense to enshrine the mechanism variable(s) in /etc/sysconfig/kernel? something like: PRUNEOLDKERNEL=yes/no DONTFRELLINGPRUNETHISLIST= space seperate list of kernel versions -jef From mrsam at courier-mta.com Thu Feb 17 23:29:01 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 17 Feb 2005 18:29:01 -0500 Subject: RPM needs to go on a diet. References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> Message-ID: Jeff Johnson writes: > Look there's a really simple answer to hardlinks and rpm and more: > > Choose a kernel, use that. > > Chose another kernel, use that, get rid of previous. This might've been a prudent approach for the days long gone. But, in the age of Fedora, I'm not that optimistic. Just recently I had to temporarily roll back a few kernel builds. Something broke in usb-storage. I didn't notice it for a while, because I don't use my digital camera that often. I now keep a minimum of current+three previous versions of the kernel. Plus -smp. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sitsofe at yahoo.com Thu Feb 17 23:47:44 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Thu, 17 Feb 2005 23:47:44 +0000 Subject: udev + usb2 kernel race? Message-ID: <1108684064.4328.10.camel@galvatron.localdomain> Hi, We have a computer acting as a server that locks hard (PS2 keyboard stops responding, prompt never returns, boot gets no further) when USB2 is enabled on FC3 (there were no lockups with FC1). I finally traced this down to being some sort of interaction between udev and USB2. The following steps reproduce the problem: Boot the kernel with init=/bin/sh mount -n -t proc /proc /proc mount -n -t sysfs /sys /sys /sbin/start_udev /sbin/modprobe uhci-hcd The machine will hang and not get any further nor will it respond to a ctrl-alt-del or sysrq commands. modprobing uhci-hcd before starting udev causes the problem to disappear as does disabling USB2 (but leaving USB1 on) in the BIOS. Kernels tested are kernel-2.6.9-1.667 and kernel-2.6.10-1.766_FC3. lspci prints the following USB controller: 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16) Does this sound like a known issue? -- Sitsofe | http://sucs.org/~sits/ From pbruna at linuxcenterla.com Fri Feb 18 00:28:31 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Thu, 17 Feb 2005 21:28:31 -0300 Subject: NetworkManager In-Reply-To: <1108659320.3579.9.camel@localhost.localdomain> References: <1108244890.4571.1.camel@p.linuxcenter.cl> <42144DCC.5050802@univ-nantes.fr> <1108643093.2791.3.camel@p.linuxcenter.cl> <1108650326.1324.1.camel@wintermute.sr.unh.edu> <1108657955.2791.28.camel@p.linuxcenter.cl> <1108658184.1324.6.camel@wintermute.sr.unh.edu> <1108659320.3579.9.camel@localhost.localdomain> Message-ID: <1108686511.2691.5.camel@p.linuxcenter.cl> El jue, 17-02-2005 a las 17:55 +0100, Kyrre Ness Sjobak escribi?: >tor, 17.02.2005 kl. 17.36 skrev Thomas J. Baker: >> On Thu, 2005-02-17 at 13:32 -0300, Patricio Bruna V wrote: >> > El jue, 17-02-2005 a las 09:25 -0500, Thomas J. Baker escribi?: >> > >On Thu, 2005-02-17 at 09:24 -0300, Patricio Bruna V wrote: >> > >> El jue, 17-02-2005 a las 08:54 +0100, Arnaud Ab?lard escribi?: >> > >> >Patricio Bruna V wrote: >> > >> >> i just install NetworkManager and NetworkManager-gnome >> > >> >> but i can't find the applet that supose to allow me change networks. >> > >> > >> > >> >Be sure the NetworkManager service is running (service NetworkManager >> > >> >status) then run NetworkManagerInfo, you should see a little icon >> > >> >appearing in Gnome's notification area. >> > >> >> > >> >> > >> >I've been playing with the applet for a little while now and it's work >> > >> >fairly well.. but i have a _BIG_ problem with NetworkManager: My laptop >> > >> >uses DHCP and NetworkManager will keep wiping my /etc/resolv.conf again >> > >> >and again.. very very annoying. >> > >> > >> > >> >If anyone knows how to tell NetworkManager to leave my resolv.conf or at >> > >> >least to fill it with the servers sent by the DHCP server.... >> > >> > >> > >> > >> > >> I can't see the icon you mentiont, and i have the same problem that you >> > >> with /etc/resolv.conf >> > >> -- >> > >> fedora-devel-list mailing list >> > >> fedora-devel-list at redhat.com >> > >> http://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > >> > >It's a know bug that it breaks the resolv.conf search: >> > > >> > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146389 >> > > >> > >Also, NetworkManager-gnome is not an applet but a tray icon. You must >> > >have a system tray running to see it. >> > just like gaim, so i must see it beside gaim, yes? i dont see it >> >> Yes, that should work. > >*probably completely stupid* - you did start NetworkManagerInfo? > yes, i did -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 4834041 -------------- next part -------------- A 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 n3npq at nc.rr.com Fri Feb 18 00:26:39 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 17 Feb 2005 19:26:39 -0500 Subject: RPM needs to go on a diet. In-Reply-To: References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> Message-ID: <4215363F.7090702@nc.rr.com> Sam Varshavchik wrote: > Jeff Johnson writes: > >> Look there's a really simple answer to hardlinks and rpm and more: >> >> Choose a kernel, use that. >> >> Chose another kernel, use that, get rid of previous. > > > This might've been a prudent approach for the days long gone. But, in > the age of Fedora, I'm not that optimistic. It's still a prudent approach, not much has changed with FC-devel nee rawhide, for a very long time. FC-devel is a development tree, there is breakage. If you want to see the breakage, well it's there for all to see. > > Just recently I had to temporarily roll back a few kernel builds. > Something broke in usb-storage. I didn't notice it for a while, > because I don't use my digital camera that often. What has changed is expectations, a couple years back you wouldn't have even noticed if your digital camera broke. What has also changed is the flood of kernels and the rate of change. The bits are still borken. > > I now keep a minimum of current+three previous versions of the > kernel. Plus -smp. > There's an optimum point between prudence and keeping every kernel ever pushed through yum installed. If that is 3 for you, that's fine, rpm and hardlink prolly have tolerable performance there. 73 de Jeff From shiva at sewingwitch.com Fri Feb 18 06:47:38 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 17 Feb 2005 22:47:38 -0800 Subject: RPM needs to go on a diet. In-Reply-To: References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> Message-ID: <7AC81046F24A02EA0CE1A8E5@[10.0.0.4]> --On Thursday, February 17, 2005 6:29 PM -0500 Sam Varshavchik wrote: > Just recently I had to temporarily roll back a few kernel builds. > Something broke in usb-storage. I didn't notice it for a while, because > I don't use my digital camera that often. Did that keep you from booting? I thought the point of keeping the previous kernel installed was in case the new one didn't allow one to boot. Presumably you'd have older kernel RPMs in your yum cache to deal with non-boot issues. From pmatilai at welho.com Fri Feb 18 09:18:14 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 18 Feb 2005 11:18:14 +0200 (EET) Subject: RPM needs to go on a diet. In-Reply-To: <1108670289.8029.2.camel@cutter> References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <1108670289.8029.2.camel@cutter> Message-ID: On Thu, 17 Feb 2005, seth vidal wrote: > On Thu, 2005-02-17 at 14:45 -0500, Jeff Spaleta wrote: >> The question becomes... can someone expose reasonable sane default >> behavior of some tool to do old kernel pruning... to avoid normal >> fedora users from encountering these deficiencies when you have 17 or >> so update kernels installed. > > > I may be able to do so. > > keep the kernel you're running and all newer than that. > > older kernels, remove. Apt's kernel-upgrade lua-thingy at some point had something like this: keep latest kernel and the one you're running. It got lost when I rewrote the thing and nobody has missed it so I never bothered to add it back... > > have a text file which can specify kernels-versions to keep/ignore from > removal. That's probably an overkill. People who want to play around with several kernels can disable the automatic pruning and do so manually, for the rest of us "current running and latest" ought to be enough. - Panu - From mailinglists at erwinrol.com Fri Feb 18 12:19:59 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 18 Feb 2005 13:19:59 +0100 Subject: sqlite3 in CVS ? Message-ID: <1108729200.6578.82.camel@drake.home.erwinrol.com> Hey all, I was wondering where I could find sqlite3 in CVS. I checked out the CVS trees from ":pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist" but it doesn't seem to be in the "devel" directory. Did I miss it somehow ? TIA, Erwin From laroche at redhat.com Fri Feb 18 12:24:39 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 18 Feb 2005 13:24:39 +0100 Subject: sqlite3 in CVS ? In-Reply-To: <1108729200.6578.82.camel@drake.home.erwinrol.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> Message-ID: <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> On Fri, Feb 18, 2005 at 01:19:59PM +0100, Erwin Rol wrote: > Hey all, > > I was wondering where I could find sqlite3 in CVS. I checked out the CVS > trees from ":pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist" but it > doesn't seem to be in the "devel" directory. > > Did I miss it somehow ? Try looking at the development tree, it often needs some time until new packages also show up in cvs. greetings, Florian La Roche From mailinglists at erwinrol.com Fri Feb 18 12:33:05 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 18 Feb 2005 13:33:05 +0100 Subject: sqlite3 in CVS ? In-Reply-To: <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> Message-ID: <1108729985.6578.86.camel@drake.home.erwinrol.com> Hey Florian, On Fri, 2005-02-18 at 13:24 +0100, Florian La Roche wrote: > On Fri, Feb 18, 2005 at 01:19:59PM +0100, Erwin Rol wrote: > > Hey all, > > > > I was wondering where I could find sqlite3 in CVS. I checked out the CVS > > trees from ":pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist" but it > > doesn't seem to be in the "devel" directory. > > > > Did I miss it somehow ? > > Try looking at the development tree, it often needs some time until > new packages also show up in cvs. > Is there another development tree than the "devel" checkout from cvs.fedora.redhat.com:/cvs/dist/ ? cause in that tree is doesn't show up. > greetings, > > Florian La Roche > - Erwin From laroche at redhat.com Fri Feb 18 12:35:04 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 18 Feb 2005 13:35:04 +0100 Subject: sqlite3 in CVS ? In-Reply-To: <1108729985.6578.86.camel@drake.home.erwinrol.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> <1108729985.6578.86.camel@drake.home.erwinrol.com> Message-ID: <20050218123504.GA15011@dudweiler.stuttgart.redhat.com> > Is there another development tree than the "devel" checkout from > cvs.fedora.redhat.com:/cvs/dist/ ? cause in that tree is doesn't show > up. I meant directory tree with newest src.rpms. ;-) I still mirror src.rpms plus cvs, too. greetings, Florian La Roche From rahulsundaram at yahoo.co.in Fri Feb 18 12:35:21 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 18 Feb 2005 04:35:21 -0800 (PST) Subject: sqlite3 in CVS ? In-Reply-To: <1108729985.6578.86.camel@drake.home.erwinrol.com> Message-ID: <20050218123521.87683.qmail@web8501.mail.in.yahoo.com> Hi > Is there another development tree than the "devel" > checkout from > cvs.fedora.redhat.com:/cvs/dist/ ? cause in that > tree is doesn't show > up. download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/ ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From mailinglists at erwinrol.com Fri Feb 18 12:45:22 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 18 Feb 2005 13:45:22 +0100 Subject: sqlite3 in CVS ? In-Reply-To: <20050218123504.GA15011@dudweiler.stuttgart.redhat.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> <1108729985.6578.86.camel@drake.home.erwinrol.com> <20050218123504.GA15011@dudweiler.stuttgart.redhat.com> Message-ID: <1108730723.6578.93.camel@drake.home.erwinrol.com> On Fri, 2005-02-18 at 13:35 +0100, Florian La Roche wrote: > > Is there another development tree than the "devel" checkout from > > cvs.fedora.redhat.com:/cvs/dist/ ? cause in that tree is doesn't show > > up. > > I meant directory tree with newest src.rpms. ;-) I still mirror src.rpms > plus cvs, too. > Oh :-) Yeah, both RPM and SRPM are available, it is just not in CVS, and I was wondering why :-) Is CVS just lagging behind ? (I would have expected that CVS would be the most up to date "source" :-) > greetings, > > Florian La Roche > - Erwin From pknirsch at redhat.com Fri Feb 18 12:50:54 2005 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 18 Feb 2005 13:50:54 +0100 Subject: sqlite3 in CVS ? In-Reply-To: <1108730723.6578.93.camel@drake.home.erwinrol.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> <1108729985.6578.86.camel@drake.home.erwinrol.com> <20050218123504.GA15011@dudweiler.stuttgart.redhat.com> <1108730723.6578.93.camel@drake.home.erwinrol.com> Message-ID: <4215E4AE.3070106@redhat.com> Erwin Rol wrote: > On Fri, 2005-02-18 at 13:35 +0100, Florian La Roche wrote: > >>>Is there another development tree than the "devel" checkout from >>>cvs.fedora.redhat.com:/cvs/dist/ ? cause in that tree is doesn't show >>>up. >> >>I meant directory tree with newest src.rpms. ;-) I still mirror src.rpms >>plus cvs, too. >> > > > Oh :-) Yeah, both RPM and SRPM are available, it is just not in CVS, and > I was wondering why :-) Is CVS just lagging behind ? (I would have > expected that CVS would be the most up to date "source" :-) > Yeah, it should be, but obviosuly still some folks don't treat CVS with the necessary importance. ;) But thats life (and developer preferences ;) ). Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From buildsys at redhat.com Fri Feb 18 12:54:27 2005 From: buildsys at redhat.com (Build System) Date: Fri, 18 Feb 2005 07:54:27 -0500 Subject: rawhide report: 20050218 changes Message-ID: <200502181254.j1ICsRGC001752@porkchop.devel.redhat.com> New package kdeaccessibility K Desktop Environment - Accessibility Updated Packages: bash-3.0-28 ----------- * Thu Feb 17 2005 Tim Waugh 3.0-28 - Define _GNU_SOURCE in CPPFLAGS (bug #147573). * Mon Feb 14 2005 Tim Waugh - Reverted this change: - Added code to /etc/skel/.bash_logout to support the gpm selection buffer invalidation on virtual terminals (bug #115493). bogl-0:0.1.18-6 --------------- * Thu Feb 17 2005 Miloslav Trmac - 0:0.1.18-6 - Don't require executable stack - Fix build with gcc 4 - Use $RPM_OPT_FLAGS bootparamd-0.17-21.devel ------------------------ * Thu Feb 17 2005 Martin Stransky 0.17-21.devel - rebuilt checkpolicy-1.21.4-1 -------------------- * Thu Feb 17 2005 Dan Walsh 1.21.4-1 * Merged define_user() cleanup patch from Darrel Goeddel (TCS). * Moved genpolusers utility to libsepol. * Merged range_transition support from Darrel Goeddel (TCS). * Thu Feb 10 2005 Dan Walsh 1.21.2-1 - Latest from NSA * Changed relabel Makefile target to use restorecon. * Mon Feb 07 2005 Dan Walsh 1.21.1-1 - Latest from NSA * Merged enhanced MLS support from Darrel Goeddel (TCS). compat-slang-1.4.5-9 -------------------- * Thu Feb 17 2005 Petr Rockai - 1.4.5-9 - Copyright -> License in spec foomatic-3.0.2-15 ----------------- * Thu Feb 17 2005 Tim Waugh 3.0.2-15 - Fixed warning patch. * Wed Feb 16 2005 Tim Waugh - Don't ship backup files. gcc4-4.0.0-0.26 --------------- * Thu Feb 17 2005 Jakub Jelinek 4.0.0-0.26 - update from trunk - fix PRs c++/20023, tree-optimization/20009 * Wed Feb 16 2005 Jakub Jelinek 4.0.0-0.25 - fix PR c++/19813 kdelibs-6:3.3.2-0.8 ------------------- * Thu Feb 17 2005 Than Ngo 3.3.2-0.8 - Add symlinks to crystal icons, thanks Peter Rockai, #121929 libghttp-1:1.0.9-11 ------------------- * Thu Feb 17 2005 Christopher Blizzard - remove bogus copyright tag libselinux-1.21.10-1 -------------------- * Thu Feb 17 2005 Dan Walsh 1.21.10-1 - Update from NSA * Merged matchpathcon patch for file_contexts.homedir from Dan Walsh. * Added selinux_users_path() for path to directory containing system.users and local.users. libsepol-1.3.5-1 ---------------- * Thu Feb 17 2005 Dan Walsh 1.3.3-1 - Update to latest from NSA * Merged endianness and compute_av patches from Darrel Goeddel (TCS). * Merged range_transition support from Darrel Goeddel (TCS). * Added sepol_genusers function. * Thu Feb 10 2005 Dan Walsh 1.3.2-1 - Update to latest from NSA * Changed relabel Makefile target to use restorecon. * Mon Feb 07 2005 Dan Walsh 1.3.1-1 - Update to latest from NSA * Merged enhanced MLS support from Darrel Goeddel (TCS). mpage-2.5.4-4 ------------- * Thu Feb 17 2005 Tim Waugh 2.5.4-4 - Fixed build with GCC 4. policycoreutils-1.21.17-1 ------------------------- * Thu Feb 17 2005 Dan Walsh 1.21.17-1 - Update to latest from NSA * Merged new genhomedircon script from Dan Walsh. * Changed load_policy to call sepol_genusers(). * Thu Feb 17 2005 Dan Walsh 1.21.15-9 - Remove Red Hat rhpl usage - Add back in original syntax - Update man page to match new syntax * Fri Feb 11 2005 Dan Walsh 1.21.15-8 - Fix genhomedircon regular expression - Fix exclude in restorecon prctl-1.4-4 ----------- * Thu Feb 17 2005 Karsten Hopp 1.4-4 - change Copyright: -> License: rpmdb-fedora-1:4-0.20050218 --------------------------- screen-4.0.2-6 -------------- * Tue Feb 15 2005 Petr Rockai - 4.0.2-6 - fix BR 136234 by carrying out the suggested change in /etc/screenrc - drop screen-4.0.2-logname.patch (merged into screen-4.0.2-screenrc.patch) - grant wish 130674 by adding a (commented out) caption statement to default screenrc selinux-policy-strict-1.21.14-1 ------------------------------- * Thu Feb 17 2005 Dan Walsh 1.21.14-1 - Update from NSA selinux-policy-targeted-1.21.14-1 --------------------------------- * Thu Feb 17 2005 Dan Walsh 1.21.14-1 - Update from NSA system-config-services-0.8.19-1 ------------------------------- * Thu Feb 17 2005 Daniel J Walsh 0.8.19-1 - Added patch from Charlie Brej tn5250-0.16.5-4 --------------- * Thu Feb 17 2005 Karsten Hopp 0.16.5-4 - change Copyright: -> License: From djotaku1282 at yahoo.com Fri Feb 18 14:41:23 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Fri, 18 Feb 2005 06:41:23 -0800 (PST) Subject: shutdown items not showing Message-ID: <20050218144123.35747.qmail@web50804.mail.yahoo.com> Hello, I'm using FC3 and when I shut down, the screen just goes blank until the end of the process when it comes back on for a second right before hda is turned off. With FC1 and 2 I used to be able to see the processes taking place. In addition to being a good debugging tool and a good learning experience, it also "entertained" me. I didn't mind shutting down my Linux computer because I could SEE what it was actually doing. With my Windows computer, however, it's just stuck on a shutdown screen and I don't know if it's frozen or working. Can you please bring this feature back in FC4? Thanks, Eric __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From cra at WPI.EDU Fri Feb 18 14:44:08 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 18 Feb 2005 09:44:08 -0500 Subject: shutdown items not showing In-Reply-To: <20050218144123.35747.qmail@web50804.mail.yahoo.com> References: <20050218144123.35747.qmail@web50804.mail.yahoo.com> Message-ID: <20050218144408.GA3493@angus.ind.WPI.EDU> On Fri, Feb 18, 2005 at 06:41:23AM -0800, The DJ wrote: > I'm using FC3 and when I shut down, the screen just > goes blank until the end of the process when it comes > back on for a second right before hda is turned off. 1. Wrong list. These types of non-development questions belong on fedora-list. 2. I've found that hitting any key on the keyboard unblanks the shutdown screen. I'd imagine this was done to make the shutdown less cluttered, while still having the ability to see what is happening if you want. From eric at snowmoon.com Fri Feb 18 14:48:24 2005 From: eric at snowmoon.com (Eric Warnke) Date: Fri, 18 Feb 2005 09:48:24 -0500 Subject: shutdown items not showing In-Reply-To: <20050218144123.35747.qmail@web50804.mail.yahoo.com> References: <20050218144123.35747.qmail@web50804.mail.yahoo.com> Message-ID: <0013c320a5c0749402a08dcee00baa00@snowmoon.com> On Feb 18, 2005, at 9:41 AM, The DJ wrote: > Hello, > > I'm using FC3 and when I shut down, the screen just > goes blank until the end of the process when it comes > back on for a second right before hda is turned off. > ... > > Can you please bring this feature back in FC4? > > Thanks, > Eric > I have noticed that on some installations as well. IIRC removing "rhgb" from grub did the trick for me. In some odd way it appears that rhgb is on, but doesn't work do you just get a blank screen. Since I turned off gb by default it hasn't bothered me much. Cheers, Eric Warnke Systems Administrator - Research Computation Center State University of New York at Albany From rcblach at blach.dnsalias.org Fri Feb 18 14:48:35 2005 From: rcblach at blach.dnsalias.org (Ralph Blach) Date: Fri, 18 Feb 2005 09:48:35 -0500 Subject: Hald hangs my system, totally Message-ID: <42160043.1080007@blach.dnsalias.org> I am having problems with hald hanging my system When I run it, my system totally hangs up, the keyboad get disconnected, the mouse wont move, and when I reboot, there is nothing in the error logs. I cannot ctl-alt-backspace to get out of x and I cannot ping or ssh into the system. It seems to be totally hung. My son, who is running fedora also is seeing the same behavior. Here my system setup /proc/version Linux version 2.6.10-1.760_FC3 (bhcompile at bugs.build.redhat.com) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Wed Feb 2 00:14:23 EST 2005 hal-0.4.7-1.FC3 hal-cups-utils-0.5.2-8dbus-python-0.22-10.FC3.2 dbus-devel-0.22-10.FC3.2 dbus-glib-0.22-10.FC3.2 dbus-x11-0.22-10.FC3.2 dbus-0.22-10.FC3.2 Any ideas.. Chip From rahulsundaram at yahoo.co.in Fri Feb 18 14:55:10 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 18 Feb 2005 06:55:10 -0800 (PST) Subject: Hald hangs my system, totally In-Reply-To: <42160043.1080007@blach.dnsalias.org> Message-ID: <20050218145510.33983.qmail@web8503.mail.in.yahoo.com> --- Ralph Blach wrote: > I am having problems with hald hanging my system > > When I run it, my system totally hangs up, > the keyboad get disconnected, the mouse wont move, > and when I reboot, > there is nothing in the error logs. > > I cannot ctl-alt-backspace to get out of x and I > cannot ping or ssh into > the system. It seems to be totally hung. My son, > who is running fedora > also is seeing the same behavior. > > Here my system setup > /proc/version > > Linux version 2.6.10-1.760_FC3 > (bhcompile at bugs.build.redhat.com) (gcc > version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Wed > Feb 2 00:14:23 EST 2005 > > hal-0.4.7-1.FC3 > hal-cups-utils-0.5.2-8dbus-python-0.22-10.FC3.2 > dbus-devel-0.22-10.FC3.2 > dbus-glib-0.22-10.FC3.2 > dbus-x11-0.22-10.FC3.2 > dbus-0.22-10.FC3.2 > > Any ideas.. please file a bug report in bugzilla.redhat.com against hald ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From riel at redhat.com Fri Feb 18 15:17:26 2005 From: riel at redhat.com (Rik van Riel) Date: Fri, 18 Feb 2005 10:17:26 -0500 (EST) Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217174437.A16952@ryoko.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> Message-ID: On Thu, 17 Feb 2005, Ralf Ertzinger wrote: > But after all it is the application that requests the memory (in most > cases, that is), and various programs allocate large chunks of memory > but never use it. > So it seems I will file a kernel bug for this after all. NOTABUG You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it. -- "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 fedora-devel at camperquake.de Fri Feb 18 15:25:09 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 18 Feb 2005 16:25:09 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> Message-ID: <20050218162509.66b03c00@nausicaa.camperquake.de> Hi. Rik van Riel wrote: > NOTABUG > > You configured the kernel to not overcommit memory, so it won't. > It makes sure that all the memory that was requested is available > for programs to use, regardless of whether programs actually use it. How much memory does it take to clone() a bash? -- If we are what we eat, then I'm easy, fast and cheap. From stan at ccs.neu.edu Fri Feb 18 16:21:48 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Fri, 18 Feb 2005 11:21:48 -0500 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050218162509.66b03c00@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> <20050218162509.66b03c00@nausicaa.camperquake.de> Message-ID: <4216161C.1070703@ccs.neu.edu> Ralf Ertzinger wrote: > Hi. > > Rik van Riel wrote: > > >>NOTABUG >> >>You configured the kernel to not overcommit memory, so it won't. >>It makes sure that all the memory that was requested is available >>for programs to use, regardless of whether programs actually use it. > > > How much memory does it take to clone() a bash? > *chuckle* -sb = a continuous waste of bandwith :) From notting at redhat.com Fri Feb 18 16:39:19 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Feb 2005 11:39:19 -0500 Subject: sqlite3 in CVS ? In-Reply-To: <1108729985.6578.86.camel@drake.home.erwinrol.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> <1108729985.6578.86.camel@drake.home.erwinrol.com> Message-ID: <20050218163919.GB9685@nostromo.devel.redhat.com> Erwin Rol (mailinglists at erwinrol.com) said: > Is there another development tree than the "devel" checkout from > cvs.fedora.redhat.com:/cvs/dist/ ? cause in that tree is doesn't show > up. cvs/dist/rpms/sqlite3 should have it. Bill From mailinglists at erwinrol.com Fri Feb 18 17:51:15 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 18 Feb 2005 18:51:15 +0100 Subject: sqlite3 in CVS ? In-Reply-To: <20050218163919.GB9685@nostromo.devel.redhat.com> References: <1108729200.6578.82.camel@drake.home.erwinrol.com> <20050218122439.GA14962@dudweiler.stuttgart.redhat.com> <1108729985.6578.86.camel@drake.home.erwinrol.com> <20050218163919.GB9685@nostromo.devel.redhat.com> Message-ID: <1108749076.6578.99.camel@drake.home.erwinrol.com> On Fri, 2005-02-18 at 11:39 -0500, Bill Nottingham wrote: > Erwin Rol (mailinglists at erwinrol.com) said: > > Is there another development tree than the "devel" checkout from > > cvs.fedora.redhat.com:/cvs/dist/ ? cause in that tree is doesn't show > > up. > > cvs/dist/rpms/sqlite3 should have it. > it doesn't show up on http://cvs.fedora.redhat.com/viewcvs/rpms/ and a checkout gives: cvs co sqlite3 cvs server: cannot find module `sqlite3' - ignored cvs [checkout aborted]: cannot expand modules > Bill > - Erwin From fedora-devel at camperquake.de Fri Feb 18 18:13:55 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 18 Feb 2005 19:13:55 +0100 Subject: Running with vm.overcommit_memory=2 In-Reply-To: References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> Message-ID: <20050218191355.55143bb9@nausicaa.camperquake.de> Hi. Rik van Riel wrote: > You configured the kernel to not overcommit memory, so it won't. > It makes sure that all the memory that was requested is available > for programs to use, regardless of whether programs actually use it. Is the amount of memory that 'free' reports as 'free' (or /proc/meminfo states as 'MemFree:') the amount of unrequested memory, or does it include requested but not actually used memory? If the latter, where can one see the amount of unrequested memory? -- "Something that I was not aware had happened suddenly turned out not to have happened." -- John Major in the Scott Report From avi at argo.co.il Fri Feb 18 19:00:14 2005 From: avi at argo.co.il (Avi Kivity) Date: Fri, 18 Feb 2005 21:00:14 +0200 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050218191355.55143bb9@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> <20050218191355.55143bb9@nausicaa.camperquake.de> Message-ID: <42163B3E.8050005@argo.co.il> Ralf Ertzinger wrote: >Hi. > >Rik van Riel wrote: > > > >>You configured the kernel to not overcommit memory, so it won't. >>It makes sure that all the memory that was requested is available >>for programs to use, regardless of whether programs actually use it. >> >> > >Is the amount of memory that 'free' reports as 'free' (or /proc/meminfo >states as 'MemFree:') the amount of unrequested memory, or does it include >requested but not actually used memory? > > used memory includes file-backed (cached) memory, and kernel memory, so 'free' does not fit any of your descriptions. >If the latter, where can one see the amount of unrequested memory? > > > total requested memory is in /proc/meminfo:Committed_AS, which is limited by swap + half ram. subtract the former from the latter to see how far you can go. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From barryn at pobox.com Fri Feb 18 19:23:28 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 18 Feb 2005 11:23:28 -0800 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050218191355.55143bb9@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> <20050218191355.55143bb9@nausicaa.camperquake.de> Message-ID: <20050218192328.GA30940@ip68-4-98-123.oc.oc.cox.net> On Fri, Feb 18, 2005 at 07:13:55PM +0100, Ralf Ertzinger wrote: > Is the amount of memory that 'free' reports as 'free' (or /proc/meminfo > states as 'MemFree:') the amount of unrequested memory, or does it include > requested but not actually used memory? The latter. (MemFree is physical memory, not virtual memory, by the way.) > If the latter, where can one see the amount of unrequested memory? It's CommitLimit - Committed_AS. At one point there was a CommitAvail but it looks like it was removed in 2.6.10 because it's redundant: http://lkml.org/lkml/2004/10/24/118 BTW, with overcommit_memory=2, CommitLimit = (MemTotal * (overcommit_ratio / 100)) + SwapFree With the default of overcommit_ratio = 50, this simplifies to: CommitLimit = (MemTotal / 2) + SwapFree Unless you're setting overcommit_ratio to 100, this means that with 640MB of RAM and no swap, user programs are allowed to request 320MB of memory at most. I hope this helps... -Barry K. Nathan From kyrre at solution-forge.net Fri Feb 18 19:49:12 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 18 Feb 2005 20:49:12 +0100 Subject: Hald hangs my system, totally In-Reply-To: <20050218145510.33983.qmail@web8503.mail.in.yahoo.com> References: <20050218145510.33983.qmail@web8503.mail.in.yahoo.com> Message-ID: <1108756152.3438.21.camel@localhost.localdomain> fre, 18.02.2005 kl. 15.55 skrev Rahul Sundaram: > --- Ralph Blach wrote: > > > I am having problems with hald hanging my system > > > > When I run it, my system totally hangs up, > > the keyboad get disconnected, the mouse wont move, > > and when I reboot, > > there is nothing in the error logs. > > > > I cannot ctl-alt-backspace to get out of x and I > > cannot ping or ssh into > > the system. It seems to be totally hung. My son, > > who is running fedora > > also is seeing the same behavior. > > > > Here my system setup > > /proc/version > > > > Linux version 2.6.10-1.760_FC3 > > (bhcompile at bugs.build.redhat.com) (gcc > > version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Wed > > Feb 2 00:14:23 EST 2005 > > > > hal-0.4.7-1.FC3 > > hal-cups-utils-0.5.2-8dbus-python-0.22-10.FC3.2 > > dbus-devel-0.22-10.FC3.2 > > dbus-glib-0.22-10.FC3.2 > > dbus-x11-0.22-10.FC3.2 > > dbus-0.22-10.FC3.2 > > > > Any ideas.. > > > please file a bug report in bugzilla.redhat.com > against hald > > ===== > Regards > Rahul Sundaram > > > It is just as much kernel - the kernel shouldn't *hang* whatever is going on around its "ears"! From kyrre at solution-forge.net Fri Feb 18 19:50:27 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 18 Feb 2005 20:50:27 +0100 Subject: shutdown items not showing In-Reply-To: <20050218144408.GA3493@angus.ind.WPI.EDU> References: <20050218144123.35747.qmail@web50804.mail.yahoo.com> <20050218144408.GA3493@angus.ind.WPI.EDU> Message-ID: <1108756226.3438.23.camel@localhost.localdomain> fre, 18.02.2005 kl. 15.44 skrev Charles R. Anderson: > On Fri, Feb 18, 2005 at 06:41:23AM -0800, The DJ wrote: > > I'm using FC3 and when I shut down, the screen just > > goes blank until the end of the process when it comes > > back on for a second right before hda is turned off. > > 1. Wrong list. These types of non-development questions belong on > fedora-list. > > 2. I've found that hitting any key on the keyboard unblanks the > shutdown screen. I'd imagine this was done to make the shutdown less > cluttered, while still having the ability to see what is happening if > you want. Hmm.. i though it was my laptop's graphic adapter borking again, not a *feature*... From david at fubar.dk Fri Feb 18 20:10:19 2005 From: david at fubar.dk (David Zeuthen) Date: Fri, 18 Feb 2005 15:10:19 -0500 Subject: Hald hangs my system, totally In-Reply-To: <1108756152.3438.21.camel@localhost.localdomain> References: <20050218145510.33983.qmail@web8503.mail.in.yahoo.com> <1108756152.3438.21.camel@localhost.localdomain> Message-ID: <1108757420.5617.2.camel@daxter.boston.redhat.com> On Fri, 2005-02-18 at 20:49 +0100, Kyrre Ness Sjobak wrote: >It is just as much kernel - the kernel shouldn't *hang* whatever is >going on around its "ears"! > Right, but hardware probing/access is nasty business; e.g. you have to be careful what you do. These days, hald is pretty careful though, but it's too early to just blame it on the kernel. David From strange at nsk.no-ip.org Fri Feb 18 21:05:18 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 18 Feb 2005 21:05:18 +0000 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050218162509.66b03c00@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> <20050218162509.66b03c00@nausicaa.camperquake.de> Message-ID: <20050218210518.GA1566@nsk.no-ip.org> On Fri, Feb 18, 2005 at 04:25:09PM +0100, Ralf Ertzinger wrote: > Hi. > > Rik van Riel wrote: > > > NOTABUG > > > > You configured the kernel to not overcommit memory, so it won't. > > It makes sure that all the memory that was requested is available > > for programs to use, regardless of whether programs actually use it. > > How much memory does it take to clone() a bash? > $ ps -o size,vsz,rss,args SZ VSZ RSS COMMAND 1428 6244 2212 -bash About 1428MB, I guess. Not that it would be consumed, but that the kernel must guarantee to be available. Regards, Luciano Rocha -- 6/9 From mailinglists at erwinrol.com Fri Feb 18 22:51:21 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 18 Feb 2005 23:51:21 +0100 Subject: rpm -i bla.i?86.rpm problems Message-ID: <1108767083.6578.114.camel@drake.home.erwinrol.com> Hey all, I tried rebuilding rpmdb-fedora from the source rpm and noticed a problem (which could certainly be because i did something wrong :-). For all rpm's in my directory of rpms (the ones i want in the db) that have more than one arch (for example glibc , i386 and glibc i686) i get an error like: error: error reading from file glibc-2.3.4-10.i686.rpm Now i changed the spec file to only include i386 and noarch rpms and it works fine. I tried with the following quick test to reproduce the effect: [root at drake RPMS]# rpm -i --justdb --force glibc-2.3.4-10.i386.rpm glibc-2.3.4-10.i686.rpm error: error reading from file glibc-2.3.4-10.i686.rpm [root at drake RPMS]# rpm -i --justdb --force glibc-2.3.4-10.i686.rpm glibc-2.3.4-10.i386.rpm error: error reading from file glibc-2.3.4-10.i386.rpm As you can see it complains about the second rpm it finds that just differs in arch. The files are all 100% correct, since i can install them one by one, just not in one go. This is on a chrooted minimal install with the latests (rsync'ed a few hours ago) rpms from the development directory. Is this expected behavior ? - Erwin From mbneto at gmail.com Sat Feb 19 01:25:05 2005 From: mbneto at gmail.com (mbneto) Date: Fri, 18 Feb 2005 21:25:05 -0400 Subject: RFE: Put fedora on a diet Message-ID: <5cf776b8050218172539ce5544@mail.gmail.com> Hi, There was a thread a few days ago about the minimum size of fedora and the number of dependencies that the packages do have today. Since seems to be too late for FC4, perhaps as a suggestion for FC5, please consider breaking the packages into smaller pieces so when we need package X it does not forces us to download a dozen of extra packages just to conform to it's dependencies. We can reduce the minimum hw necessary (good news for 3rd world/legacy hw) and ease admins' lifes (less packages to configure/worry). Thanks. From jspaar at users.sourceforge.net Sat Feb 19 01:29:16 2005 From: jspaar at users.sourceforge.net (Jack Spaar) Date: Fri, 18 Feb 2005 17:29:16 -0800 Subject: RPM needs to go on a diet. References: <421413BB.3030106@nc.rr.com> <1108658989.3579.7.camel@localhost.localdomain> <4214E945.7000208@nc.rr.com> <4214EDAB.7050101@insitesinc.com> <4214F184.6020203@nc.rr.com> <604aa791050217114562fda93a@mail.gmail.com> <1108670289.8029.2.camel@cutter> <604aa7910502171524bf95cca@mail.gmail.com> Message-ID: On Thu, 17 Feb 2005 18:24:12 -0500, Jeff Spaleta wrote: > On Thu, 17 Feb 2005 14:58:09 -0500, seth vidal > wrote: >> I may be able to do so. >> >> keep the kernel you're running and all newer than that. >> >> older kernels, remove. >> >> have a text file which can specify kernels-versions to keep/ignore from >> removal. > > would it make sense to enshrine the mechanism variable(s) in > /etc/sysconfig/kernel? > something like: > PRUNEOLDKERNEL=yes/no > DONTFRELLINGPRUNETHISLIST= space seperate list of kernel versions > > -jef FWIW, and since no one commented, it makes sense to mere lurking users like me. And the follow-on is that the prune job would probably best be done by new-kernel-pkg (and would therefore be independent of the updater-of-choice). But since Mr. Yum is volunteering, power to him. --Jack From dwmw2 at infradead.org Sat Feb 19 03:57:40 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 19 Feb 2005 03:57:40 +0000 Subject: Fedora Core 4 on PPC (was Re: Fedora Core 4 test 1 freeze ahead) In-Reply-To: References: Message-ID: <1108785460.15768.31.camel@localhost.localdomain> On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote: >I'm not yet sure whether we'll have PowerPC included - it would help to >have someone from that team give a summary of the status of rawhide on >that arch. I've just done some playing with rawhide installs, and I think it's well worth including it for FC4T1 -- we can always drop it later if we really have to, not that I think that'll be necessary. It's only really the installer which was in question -- the distro itself has been fairly solid on PPC since at least FC2, if you could get it to install. Anaconda in rawhide is now capable of installing the bootloader correctly and rendering the system bootable -- unlike in FC3. That was the biggest problem in the past. Remaining issues (see tracker BZ #121179): - Rawhide lacks a 64-bit boot.iso for the Mac G5. That's fixed with the patch in BZ #149081. - Autopartitioning doesn't work well. That's partially fixed with the patch in BZ #121266, but there's a few more relatively minor issues which could do with being fixed by someone who understands anaconda, or at least speaks python. The problem is definitely tractable though. - A few X configuration problems. These should also be relatively easy. There's an Xautoconfig package from Yellow Dog which gets it right, and it's just a case of getting system-config-display and/or anaconda to learn the same tricks. -- dwmw2 From eric at snowmoon.com Sat Feb 19 04:17:23 2005 From: eric at snowmoon.com (Eric Warnke) Date: Fri, 18 Feb 2005 23:17:23 -0500 Subject: RFE: Put fedora on a diet In-Reply-To: <5cf776b8050218172539ce5544@mail.gmail.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> Message-ID: <4216BDD3.2080001@snowmoon.com> mbneto wrote: >Hi, > >There was a thread a few days ago about the minimum size of fedora and >the number of dependencies that the packages do have today. > >Since seems to be too late for FC4, perhaps as a suggestion for FC5, >please consider breaking the packages into smaller pieces so when we >need package X it does not forces us to download a dozen of extra >packages just to conform to it's dependencies. > > > Yes, please. A base install is 666MB acording to anaconda. Almost half of which require immediate updating to get up-to-date. It just does not make sense to have this many packages in the base install. Some of the ones off the top if my head ( starting from a blamk package list in kickstart ) include FreeType and xorg-x11-libs. I need almost nothing since my post-install scripts just end up pulling down everything from our own mirror+custom repo's. Cheers, Eric -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken From fedora-devel at tlarson.com Sat Feb 19 06:50:39 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Fri, 18 Feb 2005 23:50:39 -0700 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050218210518.GA1566@nsk.no-ip.org> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> <20050218162509.66b03c00@nausicaa.camperquake.de> <20050218210518.GA1566@nsk.no-ip.org> Message-ID: <4216E1BF.2070400@tlarson.com> Luciano Miguel Ferreira Rocha wrote: >>How much memory does it take to clone() a bash? >> > > > $ ps -o size,vsz,rss,args > SZ VSZ RSS COMMAND > 1428 6244 2212 -bash > > About 1428MB, I guess. Not that it would be consumed, but that the > kernel must guarantee to be available. > > Regards, > Luciano Rocha > Erm.. Perhaps I'm a bit behind on things, but I though the SZ field shows the number of pages that a process is using, not the number of Megs guaranteed. That'd make your estimate just a few orders of magnitude high. The VSZ will give your answer in bytes rather than pages. That's the total process size in virtual memory, displayed in KB. The RSS is the amount of that's actually IN memory. The discrepency between these numbers would then indicate, at least in a crude way, the difference between what the app thinks it's using versus what the OS actually has tied up in the process. So, you're looking at something more along the lines of 6MB, rather than 1.4GB; with 2M actually used. Someone care to check my math? From laroche at redhat.com Sat Feb 19 07:36:45 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 19 Feb 2005 08:36:45 +0100 Subject: RFE: Put fedora on a diet In-Reply-To: <5cf776b8050218172539ce5544@mail.gmail.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> Message-ID: <20050219073645.GB4273@dudweiler.stuttgart.redhat.com> > We can reduce the minimum hw necessary (good news for 3rd world/legacy > hw) and ease admins' lifes (less packages to configure/worry). There could be a special case to reduce calculation on the client machines if they only install packages in a set of repos and the deps for set are pre-computed already. greetings, Florian La Roche From seyman at wanadoo.fr Sat Feb 19 09:11:18 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Sat, 19 Feb 2005 10:11:18 +0100 Subject: RFE: Put fedora on a diet In-Reply-To: <5cf776b8050218172539ce5544@mail.gmail.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> Message-ID: <20050219091118.GA10998@orient.maison.moi> On Fri, Feb 18, 2005 at 09:25:05PM -0400, mbneto wrote: > > We can reduce the minimum hw necessary (good news for 3rd world/legacy > hw) and ease admins' lifes (less packages to configure/worry). This comes up every once in a while and the reply is always the same. The Red Hat devs guys are all for this bhut it's simply not important enough for them to do all the work themselves. If you really want this to happen, you should take a hard look at the packages in the minimal install, submit RFEs in bugzilla to have them split then work out a new comps.xml file so that people can burn CDs which redefine the base setup. Emmanuel From rahulsundaram at yahoo.co.in Sat Feb 19 09:42:02 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Sat, 19 Feb 2005 01:42:02 -0800 (PST) Subject: RFE: Put fedora on a diet In-Reply-To: <5cf776b8050218172539ce5544@mail.gmail.com> Message-ID: <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> --- mbneto wrote: > Hi, > > There was a thread a few days ago about the minimum > size of fedora and > the number of dependencies that the packages do have > today. > > Since seems to be too late for FC4, perhaps as a > suggestion for FC5, > please consider breaking the packages into smaller > pieces so when we > need package X it does not forces us to download a > dozen of extra > packages just to conform to it's dependencies. you need to file specific bug reports/ RFE's about all those packages where you believe that dependencies can be split up in a more granular way. If you are unsure of the list then discuss about them here by proposing a list of packages which can be modular ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? All your favorites on one personal page ? Try My Yahoo! http://my.yahoo.com From mr700 at globalnet.bg Sat Feb 19 11:21:27 2005 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Sat, 19 Feb 2005 13:21:27 +0200 Subject: VPN Server features In-Reply-To: <20050211164635.3b3526fb@python2> References: <420CCFAC.1080102@btinternet.com> <20050211164154.5fb1b667@python2> <20050211164635.3b3526fb@python2> Message-ID: <200502191321.27750@-mr700> On 2005-02-11 (Friday) 17:46, Matthias Saou wrote: > Matthias Saou wrote : ... > > and if there aren't any obvious crypto or similar issues that prevent it > > from being shipped, then ask on fedora-extras-list. > > There is a "stalled" discussion here : > > https://bugzilla.fedora.us/show_bug.cgi?id=1531 > > Please, anyone interested, add follow-ups and help us move the package to > Fedora Extras! ;-) > I'm interested. I use it from 1.5 and have now moved to the last 2.0rc without any problems, but there's no voting for and against, so I just make my own rpms. -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From csh_jp at yahoo.com Sat Feb 19 11:23:50 2005 From: csh_jp at yahoo.com (s. h.) Date: Sat, 19 Feb 2005 03:23:50 -0800 (PST) Subject: Cannot run scripts in FC3 if the first line is a comment specifying interpreter Message-ID: <20050219112351.99328.qmail@web40424.mail.yahoo.com> Hi, Just installed FC3 and updated. But I found that I cannot run scripts if the first line is the comment specifying the interpretor, like: ============= #!/bin/bash echo "aaa" ============= but a script without that first line works fine: ============= echo "aaa" ============= Does anyone have the same problem? How to fix it? thanks, Chris __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From rahulsundaram at yahoo.co.in Sat Feb 19 11:26:04 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Sat, 19 Feb 2005 03:26:04 -0800 (PST) Subject: Cannot run scripts in FC3 if the first line is a comment specifying interpreter In-Reply-To: <20050219112351.99328.qmail@web40424.mail.yahoo.com> Message-ID: <20050219112604.29092.qmail@web8508.mail.in.yahoo.com> --- "s. h." wrote: > Hi, > > Just installed FC3 and updated. But I found that I > cannot run scripts if the first line is the comment > specifying the interpretor, like: > > ============= > #!/bin/bash > echo "aaa" > ============= > > but a script without that first line works fine: > > > ============= > echo "aaa" > ============= > > Does anyone have the same problem? How to fix it? > > thanks, > Chris > off topic here. please ask the fedora users list instead. ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From csh_jp at yahoo.com Sat Feb 19 11:52:44 2005 From: csh_jp at yahoo.com (s. h.) Date: Sat, 19 Feb 2005 03:52:44 -0800 (PST) Subject: Cannot run scripts in FC3 if the first line is a comment specifying interpreter In-Reply-To: <20050219112604.29092.qmail@web8508.mail.in.yahoo.com> Message-ID: <20050219115244.57183.qmail@web40423.mail.yahoo.com> Sorry, registered to the wrong list... --- Rahul Sundaram wrote: > > off topic here. please ask the fedora users list > instead. > > ===== > Regards > Rahul Sundaram > __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From strange at nsk.no-ip.org Sat Feb 19 13:25:33 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 19 Feb 2005 13:25:33 +0000 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <4216E1BF.2070400@tlarson.com> References: <20050217143021.35815547@nausicaa.camperquake.de> <20050217133421.57599.qmail@web8503.mail.in.yahoo.com> <20050217150826.10382e70@nausicaa.camperquake.de> <4214BECB.5040908@ccs.neu.edu> <20050217174437.A16952@ryoko.camperquake.de> <20050218162509.66b03c00@nausicaa.camperquake.de> <20050218210518.GA1566@nsk.no-ip.org> <4216E1BF.2070400@tlarson.com> Message-ID: <20050219132533.GA1892@nsk.no-ip.org> On Fri, Feb 18, 2005 at 11:50:39PM -0700, Tyler Larson wrote: > Luciano Miguel Ferreira Rocha wrote: > >>How much memory does it take to clone() a bash? > >> > > > > > >$ ps -o size,vsz,rss,args > >SZ VSZ RSS COMMAND > >1428 6244 2212 -bash > > > >About 1428MB, I guess. Not that it would be consumed, but that the > >kernel must guarantee to be available. > > > >Regards, > >Luciano Rocha > > > > Erm.. Perhaps I'm a bit behind on things, but I though the SZ field > shows the number of pages that a process is using, not the number of > Megs guaranteed. That'd make your estimate just a few orders of > magnitude high. > > The VSZ will give your answer in bytes rather than pages. That's the > total process size in virtual memory, displayed in KB. The RSS is the > amount of that's actually IN memory. The discrepency between these > numbers would then indicate, at least in a crude way, the difference > between what the app thinks it's using versus what the OS actually has > tied up in the process. They're both in KB, my mistake. > So, you're looking at something more along the lines of 6MB, rather than > 1.4GB; with 2M actually used. Actually, from the manual page: size SZ approximate amount of swap space that would be required if the process were to dirty all writable pages and then be swapped out. This number is very rough! So, if it is correct, about 1.4MB. Regards, Luciano Rocha -- 6/9 From buildsys at redhat.com Sat Feb 19 13:44:40 2005 From: buildsys at redhat.com (Build System) Date: Sat, 19 Feb 2005 08:44:40 -0500 Subject: rawhide report: 20050219 changes Message-ID: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> Removed package libtool-libs13 Updated Packages: VFlib2-2.25.6-27 ---------------- * Fri Feb 18 2005 Akira TAGOH - 2.25.6-27 - separated out X-related tools to VFlib2-xtools package. (#148936) - BuildRequires xorg-x11-devel rather than XFree86-devel. bind-22:9.3.1rc1-1 ------------------ * Wed Feb 16 2005 Jason Vas Dias - 22:9.3.1rc1-1 - Upgrade to 9.3.1rc1 - Add Simplified Database Backend (SDB) sub-package ( bind-sdb ) - add named_sdb - ldap + pgsql + dir database backend support with - 'ENABLE_SDB' named.sysconfig option - Add BIND resolver library & includes sub-package ( libbind-devel) - fix bug 147824 / 147073 / 145664: ENABLE_ZONE_WRITE in named.init - fix bug 146084 : shutup restorecon bzflag-2.0.0-2 -------------- * Tue Jan 18 2005 Nils Philippsen 2.0.0-2 - build as PIE * Tue Jan 18 2005 Nils Philippsen 2.0.0-1 - correct source URL - buildrequire ncurses-devel * Tue Jan 18 2005 Nils Philippsen 2.0.0-0.1 - version 2.0.0.20050117 - buildrequire xorg-x11-devel, not XFree86-devel cdrtools-8:2.01.1-7 ------------------- * Fri Feb 18 2005 Harald Hoyer 8:2.01.1-7 - fixed gcc4 pickieness cups-1:1.1.23-10 ---------------- * Fri Feb 18 2005 Tim Waugh 1:1.1.23-10 - Fixed build with GCC 4. * Thu Feb 10 2005 Tim Waugh 1:1.1.23-9 - Back to old DBUS API since new DBUS isn't built yet. * Mon Feb 07 2005 Tim Waugh - Use upstream patch for STR #1068. - Apply patch to fix remainder of CAN-2004-0888 (bug #135378). emacs-21.3-23 ------------- * Fri Feb 18 2005 Jens Petersen - 21.3-23 - install /usr/bin/emacs-nox as a hardlink of the versioned binary - drop explicit lib requirements - use sed instead of perl to fix up filelists gaim-1:1.1.3-1 -------------- * Fri Feb 18 2005 Warren Togami 1:1.1.3-1 - 1.1.3 including two security fixes gamin-0.0.24-1 -------------- * Fri Feb 18 2005 Daniel Veillard 0.0.24-1 - more documentation - lot of serious bug fixes including Gnome Desktop refresh bug - extending the framework for more debug (configure --enable-debug-api) - extending the python bindings for watching the same resource multiple times and adding debug framework support - growing the regression tests a lot based on python bindings - inotify-0.19 patch from John McCutchan - renamed python private module to _gamin to follow Python PEP 8 gcc4-4.0.0-0.27 --------------- * Fri Feb 18 2005 Jakub Jelinek 4.0.0-0.27 - fix PRs c++/20008, target/20054, tree-optimization/19828 gnumeric-1:1.4.2-3 ------------------ * Fri Feb 18 2005 Caolan McNamara 1.4.2-3 - rh#149005# htdig-3:3.2.0b6-4 ----------------- * Tue Jan 25 2005 Phil Knirsch - Fixed security bug with unescaped output in htsearch and qtest (#144127) - Removed .la and .a libs from package (#145649) kernel-2.6.10-1.1146_FC4 ------------------------ * Sat Feb 19 2005 Dave Jones - 2.6.11-rc4-bk6 * Fri Feb 18 2005 David Woodhouse - Add SMP kernel for PPC32 * Fri Feb 18 2005 Dave Jones - 2.6.11-rc4-bk5 kudzu-1.1.108-1 --------------- * Fri Feb 18 2005 Bill Nottingham 1.1.108-1 - add patch for detecting macio bmac devices () logrotate-3.7.1-6 ----------------- * Fri Feb 18 2005 Peter Vrabec - remove logrotate-3.7.1-share.patch, it doesn't solve (#140353) lvm2-2.01.05-1.0 ---------------- * Fri Feb 18 2005 Alasdair Kergon - 2.01.05-1.0 - Upstream changes not affecting Fedora. mailman-3:2.1.5-31.fc4 ---------------------- * Mon Feb 14 2005 John Dennis - 3:2.1.5-31.fc4 - fix bug #132750, add daemon to mail-gid so courier mail server will work. - fix bug #143008, wrong location of mailmanctl in logrotate - fix bug #142605, init script doesn't use /var/lock/subsys openswan-2.3.0-3 ---------------- * Fri Feb 18 2005 Harald Hoyer - 2.3.0-3 - patched code to compile with gcc4 pychecker-0.8.14-3 ------------------ * Fri Feb 18 2005 Miloslav Trmac - 0.8.14-3 - Fix build failure on lib64 platforms * Mon Nov 08 2004 Jeremy Katz - 0.8.14-2 - rebuild against python 2.4 rarpd-ss981107-19 ----------------- * Fri Feb 18 2005 Phil Knirsch ss981107-19 - rebuilt * Tue Jun 15 2004 Elliot Lee ss981107-18 - rebuilt * Wed May 12 2004 Phil Knirsch ss981107-17 - Enabled PIE compilation and linking. rdate-1.4-3 ----------- * Fri Feb 18 2005 Phil Knirsch 1.4-3 - rebuilt * Tue Jun 15 2004 Elliot Lee 1.4-2 - rebuilt * Mon Mar 22 2004 Elliot Lee 1.4-1 - Timeout (-t) patch from Johan Nilsson rdist-1:6.1.5-39 ---------------- * Fri Feb 18 2005 Phil Knirsch 6.1.5-39 - rebuilt rpmdb-fedora-1:4-0.20050219 --------------------------- rusers-0.17-42 -------------- * Fri Feb 18 2005 Phil Knirsch 0.17-42 - rebuilt rwall-0.17-24 ------------- * Fri Feb 18 2005 Phil Knirsch 0.17-24 - rebuilt sg3_utils-1.06-4 ---------------- * Fri Feb 18 2005 Phil Knirsch 1.06-4 - rebuilt tora-1.3.15-1 ------------- * Thu Feb 17 2005 Mihai Ibanescu 1.3.15-1 - updated to 1.3.15 udev-050-7 ---------- * Fri Feb 18 2005 Harald Hoyer - 050-6 - introducing /etc/udev/makedev.d/50-udev.nodes - glibcstatic patch modified to let gcc4 compile udev vconfig-1.8-6 ------------- * Fri Feb 18 2005 Phil Knirsch 1.8-6 - rebuilt * Sun Feb 13 2005 Florian La Roche 1.8-5 - remove kernel dep, kernel runtime deps should go into apps, #146151 * Mon Sep 27 2004 Phil Knirsch 1.8-4 - Small specfile changes (#131487) From arjanv at redhat.com Sat Feb 19 14:10:44 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 19 Feb 2005 15:10:44 +0100 Subject: rawhide report: 20050219 changes In-Reply-To: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> Message-ID: <1108822244.6304.106.camel@laptopd505.fenrus.org> On Sat, 2005-02-19 at 08:44 -0500, Build System wrote: > > gamin-0.0.24-1 > -------------- > * Fri Feb 18 2005 Daniel Veillard 0.0.24-1 > - more documentation > - lot of serious bug fixes including Gnome Desktop refresh bug > - extending the framework for more debug (configure --enable-debug- > api) > - extending the python bindings for watching the same resource > multiple times > and adding debug framework support > - growing the regression tests a lot based on python bindings > - inotify-0.19 patch from John McCutchan I hope inotify stuff isn't enabled by default though.. the kernel<->user ABI for it is still changing all the time, and it's even not sure (if not unlikely) that it will ever make it into the mainline kernels.. -------------- next part -------------- A 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 veillard at redhat.com Sat Feb 19 15:52:57 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 19 Feb 2005 10:52:57 -0500 Subject: rawhide report: 20050219 changes In-Reply-To: <1108822244.6304.106.camel@laptopd505.fenrus.org> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> <1108822244.6304.106.camel@laptopd505.fenrus.org> Message-ID: <20050219155257.GD8615@redhat.com> On Sat, Feb 19, 2005 at 03:10:44PM +0100, Arjan van de Ven wrote: > On Sat, 2005-02-19 at 08:44 -0500, Build System wrote: > > > > gamin-0.0.24-1 > > -------------- > > * Fri Feb 18 2005 Daniel Veillard 0.0.24-1 > > - more documentation > > - lot of serious bug fixes including Gnome Desktop refresh bug > > - extending the framework for more debug (configure --enable-debug- > > api) > > - extending the python bindings for watching the same resource > > multiple times > > and adding debug framework support > > - growing the regression tests a lot based on python bindings > > - inotify-0.19 patch from John McCutchan > > I hope inotify stuff isn't enabled by default though.. the kernel<->user > ABI for it is still changing all the time, and it's even not sure (if > not unlikely) that it will ever make it into the mainline kernels.. The inotify stuff is enabled by default. But if the kernel doesn't have support for it we fallback to dnotify automatically. Allows people to experiment with it without relying on it. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From arjanv at redhat.com Sat Feb 19 15:54:12 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 19 Feb 2005 16:54:12 +0100 Subject: rawhide report: 20050219 changes In-Reply-To: <20050219155257.GD8615@redhat.com> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> <1108822244.6304.106.camel@laptopd505.fenrus.org> <20050219155257.GD8615@redhat.com> Message-ID: <20050219155412.GC32222@devserv.devel.redhat.com> On Sat, Feb 19, 2005 at 10:52:57AM -0500, Daniel Veillard wrote: > On Sat, Feb 19, 2005 at 03:10:44PM +0100, Arjan van de Ven wrote: > > On Sat, 2005-02-19 at 08:44 -0500, Build System wrote: > > > > > > gamin-0.0.24-1 > > > -------------- > > > * Fri Feb 18 2005 Daniel Veillard 0.0.24-1 > > > - more documentation > > > - lot of serious bug fixes including Gnome Desktop refresh bug > > > - extending the framework for more debug (configure --enable-debug- > > > api) > > > - extending the python bindings for watching the same resource > > > multiple times > > > and adding debug framework support > > > - growing the regression tests a lot based on python bindings > > > - inotify-0.19 patch from John McCutchan > > > > I hope inotify stuff isn't enabled by default though.. the kernel<->user > > ABI for it is still changing all the time, and it's even not sure (if > > not unlikely) that it will ever make it into the mainline kernels.. > > The inotify stuff is enabled by default. But if the kernel doesn't > have support for it we fallback to dnotify automatically. Allows people > to experiment with it without relying on it. question is how you detect inotify support... that's going to be tough without breaking when the abi changes again etc From veillard at redhat.com Sat Feb 19 16:11:18 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 19 Feb 2005 11:11:18 -0500 Subject: rawhide report: 20050219 changes In-Reply-To: <20050219155412.GC32222@devserv.devel.redhat.com> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> <1108822244.6304.106.camel@laptopd505.fenrus.org> <20050219155257.GD8615@redhat.com> <20050219155412.GC32222@devserv.devel.redhat.com> Message-ID: <20050219161118.GF8615@redhat.com> On Sat, Feb 19, 2005 at 04:54:12PM +0100, Arjan van de Ven wrote: > On Sat, Feb 19, 2005 at 10:52:57AM -0500, Daniel Veillard wrote: > > The inotify stuff is enabled by default. But if the kernel doesn't > > have support for it we fallback to dnotify automatically. Allows people > > to experiment with it without relying on it. > > question is how you detect inotify support... that's going to be tough > without breaking when the abi changes again etc If an user update the kernel without also updating the user space tools he's in for troubles, that's true for many kernel interfaces. Gamin is far from being cast in stone either, expect more updates ! Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From nbargnesi at gmail.com Sat Feb 19 18:35:55 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Sat, 19 Feb 2005 13:35:55 -0500 Subject: Cannot run scripts in FC3 if the first line is a comment specifying interpreter In-Reply-To: <20050219112351.99328.qmail@web40424.mail.yahoo.com> References: <20050219112351.99328.qmail@web40424.mail.yahoo.com> Message-ID: <3077b8a005021910351e8e8126@mail.gmail.com> On Sat, 19 Feb 2005 03:23:50 -0800 (PST), s. h. wrote: > Hi, > > Just installed FC3 and updated. But I found that I > cannot run scripts if the first line is the comment > specifying the interpretor, like: > > ============= > #!/bin/bash > echo "aaa" > ============= > > but a script without that first line works fine: > > ============= > echo "aaa" > ============= > > Does anyone have the same problem? How to fix it? > Even though you're off topic - I'd bet the format of the text file isn't unix. Sounds like bash is trying to execute a script that's in dos format. > thanks, > Chris > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - You care about security. So do we. > http://promotions.yahoo.com/new_mail > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Feb 19 22:58:24 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 19 Feb 2005 23:58:24 +0100 Subject: bzflag 2.0 (was: Re: rawhide report: 20050219 changes) In-Reply-To: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> Message-ID: <20050219235824.6e93f3e9@python2> Build System wrote : > bzflag-2.0.0-2 > -------------- > * Tue Jan 18 2005 Nils Philippsen 2.0.0-2 > - build as PIE > > * Tue Jan 18 2005 Nils Philippsen 2.0.0-1 > - correct source URL > - buildrequire ncurses-devel > > * Tue Jan 18 2005 Nils Philippsen 2.0.0-0.1 > - version 2.0.0.20050117 > - buildrequire xorg-x11-devel, not XFree86-devel Maybe Nils should become the bugzilla owner of bzflag? Anyway, I guess this means this bug can be closed : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145780 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.40 0.34 0.20 From jerone at gmail.com Sun Feb 20 06:37:49 2005 From: jerone at gmail.com (Jerone Young) Date: Sun, 20 Feb 2005 00:37:49 -0600 Subject: RFE: Put fedora on a diet In-Reply-To: <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> Message-ID: <9f50a7a005021922376f3c2baf@mail.gmail.com> Since Fedora Core is a general purpose Linux distributions it's size will actually increase over time. Why you ask? Because with more users come more use cases. The beautiful part of Fedora is that a user can install a base system and have just about everything they need. Not everybody likes playing around finding packages and what not (especially new users), they want it to be there and ready to use. If you have a problem with the base install then you can customize your install to be smaller. The other thing is hard disk space is dirt cheap! Can you even buy anything under 80Gigs? The fact is that Fedora has a wide verity of use cases and hard disk space is really not an issue. You can customize your install to be smaller, and if you do need something smaller there are many other Linux distributions that can accomidate your needs. On Sat, 19 Feb 2005 01:42:02 -0800 (PST), Rahul Sundaram wrote: > > --- mbneto wrote: > > > Hi, > > > > There was a thread a few days ago about the minimum > > size of fedora and > > the number of dependencies that the packages do have > > today. > > > > Since seems to be too late for FC4, perhaps as a > > suggestion for FC5, > > please consider breaking the packages into smaller > > pieces so when we > > need package X it does not forces us to download a > > dozen of extra > > packages just to conform to it's dependencies. > > you need to file specific bug reports/ RFE's about all > those packages where you believe that dependencies can > be split up in a more granular way. If you are unsure > of the list then discuss about them here by proposing > a list of packages which can be modular > > ===== > Regards > Rahul Sundaram > > > __________________________________ > Do you Yahoo!? > All your favorites on one personal page ? Try My Yahoo! > http://my.yahoo.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From Lam at Lam.pl Sun Feb 20 08:35:02 2005 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 20 Feb 2005 09:35:02 +0100 Subject: RFE: Put fedora on a diet In-Reply-To: <9f50a7a005021922376f3c2baf@mail.gmail.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> <9f50a7a005021922376f3c2baf@mail.gmail.com> Message-ID: <1108888503.5960.15.camel@pensja.lam.pl> Dnia 20-02-2005, nie o godzinie 00:37 -0600, Jerone Young napisa?(a): > if you do > need something smaller there are many other Linux distributions that > can accomidate your needs. And don't forget about "live" Fedora requiring _0_ HDD space :) Of course it will need more memory, so it won't fill the "runs on legacy hardware" requirement. I guess todays (desktop) applications won't run well on such hardware anyhow - I wouldn't expect a computer with 200 MiB HDD to have 686-class CPU and 256 MiB of RAM (which are below minimum requirements for desktop - try to run Mozilla on 400 MHz Pentium 2 - pointless). Lam From mbneto at gmail.com Sun Feb 20 13:15:26 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 20 Feb 2005 09:15:26 -0400 Subject: RFE: Put fedora on a diet In-Reply-To: <9f50a7a005021922376f3c2baf@mail.gmail.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> <9f50a7a005021922376f3c2baf@mail.gmail.com> Message-ID: <5cf776b805022005154a16aa86@mail.gmail.com> Jerone, The point is that I do like Fedora (I've been using redhat distros since redhat 5) and feel that the other distros do have a 'firewall'/minimum with requirements less than 100 Mb. What I'd like to have is the hability without having to hack it to go from a firewall to a server to desktop from the same provider, relying on the same updates. On Sun, 20 Feb 2005 00:37:49 -0600, Jerone Young wrote: > Since Fedora Core is a general purpose Linux distributions it's size > will actually increase over time. Why you ask? Because with more users > come more use cases. The beautiful part of Fedora is that a user can > install a base system and have just about everything they need. Not > everybody likes playing around finding packages and what not > (especially new users), they want it to be there and ready to use. If > you have a problem with the base install then you can customize your > install to be smaller. The other thing is hard disk space is dirt > cheap! Can you even buy anything under 80Gigs? The fact is that Fedora > has a wide verity of use cases and hard disk space is really not an > issue. You can customize your install to be smaller, and if you do > need something smaller there are many other Linux distributions that > can accomidate your needs. From mbneto at gmail.com Sun Feb 20 13:19:24 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 20 Feb 2005 09:19:24 -0400 Subject: RFE: Put fedora on a diet In-Reply-To: <20050219091118.GA10998@orient.maison.moi> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219091118.GA10998@orient.maison.moi> Message-ID: <5cf776b805022005194c5aab80@mail.gmail.com> Ok. I'll try that approach. It will take more time since those who develop the package already know what I'll try to figure it out. - mb On Sat, 19 Feb 2005 10:11:18 +0100, Emmanuel Seyman wrote: > On Fri, Feb 18, 2005 at 09:25:05PM -0400, mbneto wrote: > > > > We can reduce the minimum hw necessary (good news for 3rd world/legacy > > hw) and ease admins' lifes (less packages to configure/worry). > > This comes up every once in a while and the reply is always the same. > The Red Hat devs guys are all for this bhut it's simply not important > enough for them to do all the work themselves. > > If you really want this to happen, you should take a hard look at the > packages in the minimal install, submit RFEs in bugzilla to have them > split then work out a new comps.xml file so that people can burn CDs > which redefine the base setup. > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From buildsys at redhat.com Sun Feb 20 13:45:01 2005 From: buildsys at redhat.com (Build System) Date: Sun, 20 Feb 2005 08:45:01 -0500 Subject: rawhide report: 20050220 changes Message-ID: <200502201345.j1KDj15x015945@porkchop.devel.redhat.com> Updated Packages: anaconda-10.2.0.20-1 -------------------- * Sat Feb 19 2005 Paul Nasrat - 10.2.0.20-1 - Pull in translations - s390 linuxrc silence nonexistant group warnings (karsten) - ppc mac autopartitioning and G5 boot.iso (#121266) and (#149081) gaim-1:1.1.3-2 -------------- * Fri Feb 18 2005 Warren Togami 1:1.1.3-2 - 1.1.3 including two security fixes CAN-2005-0472 Client freezes when receiving certain invalid messages CAN-2005-0473 Client crashes when receiving specific malformed HTML * Fri Jan 28 2005 Florian La Roche - rebuild * Thu Jan 20 2005 Warren Togami 1:1.1.2-1 - 1.1.2 with more bugfixes kbd-1.12-4 ---------- * Sat Feb 19 2005 Miloslav Trmac - 1.12-4 - Don't ship a patch backup file - Mention in setfont.8 that 512-glyph fonts reduce the number of available colors (#140935, patch by Dmitry Butskoj) - Remove "Meta_acute" from German keymaps (#143124) - Make the %triggerun script condition more precise, ignore failure of the script kernel-2.6.10-1.1148_FC4 ------------------------ policycoreutils-1.21.18-1 ------------------------- * Sat Feb 19 2005 Dan Walsh 1.21.18-1 - Update to latest from NSA * Changed load_policy to fall back to the original policy upon an error from sepol_genusers(). * Thu Feb 17 2005 Dan Walsh 1.21.17-2 - Only restorecon on ext[23], reiser and xfs rpmdb-fedora-1:4-0.20050220 --------------------------- xen-2-20050219 -------------- * Sat Feb 19 2005 Rik van Riel 2-20050219 - fix more compile warnings - fix the fwrite return check * Fri Feb 18 2005 Rik van Riel 2-20050218 - upgrade to last night's Xen snapshot - a kernel upgrade is needed to run this Xen, the hypervisor interface changed slightly - comment out unused debugging function in plan9 domain builder that was giving compile errors with -Werror From mpeters at mac.com Sun Feb 20 14:41:42 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 20 Feb 2005 14:41:42 +0000 Subject: RFE: Put fedora on a diet In-Reply-To: <9f50a7a005021922376f3c2baf@mail.gmail.com> (from jerone@gmail.com on Sat Feb 19 22:37:49 2005) References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> <9f50a7a005021922376f3c2baf@mail.gmail.com> Message-ID: <1108910502l.22459l.0l@devel.mpeters.us> On 02/19/2005 10:37:49 PM, Jerone Young wrote: > Since Fedora Core is a general purpose Linux distributions it's size > will actually increase over time. Why you ask? Because with more > users > come more use cases. The beautiful part of Fedora is that a user can > install a base system and have just about everything they need. Not > everybody likes playing around finding packages and what not > (especially new users), they want it to be there and ready to use. The problem comes when a vendor wants to ship fedora core. Either the vendor needs to spend time and resources stripping fedora core or the vendor needs to support a wide range of software - which has high training costs. A smaller core operating system means that vendors do not need to support as much software. Addon software that the small core does not come with that the vendor specifically wants can be done through a second CD, add on software could me available as an iso download (or purchased on CDR from any number of college kids with a burner and a paypal account) etc. A big distro makes it a lot harder for support - that might be one reason why Debian has so many off shoots now that are smaller. A small distro does not mean that an official repository like Fedora Extras can't exist to provide what users want that a vendor doesn't necessarily want to support. And they could be provided as CD/DVD with an addon installer much like the Anaconda package chooser. -- Michael A. Peters http://mpeters.us/ From dstolte at arcor.de Sun Feb 20 15:17:47 2005 From: dstolte at arcor.de (D. Stolte) Date: Sun, 20 Feb 2005 16:17:47 +0100 Subject: rawhide report: 20050219 changes In-Reply-To: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> Message-ID: <4218AA1B.8060107@arcor.de> > bind-22:9.3.1rc1-1 > ------------------ > * Wed Feb 16 2005 Jason Vas Dias - 22:9.3.1rc1-1 > - Upgrade to 9.3.1rc1 > - Add Simplified Database Backend (SDB) sub-package ( bind-sdb ) > - add named_sdb - ldap + pgsql + dir database backend support with > - 'ENABLE_SDB' named.sysconfig option > - Add BIND resolver library & includes sub-package ( libbind-devel) > - fix bug 147824 / 147073 / 145664: ENABLE_ZONE_WRITE in named.init > - fix bug 146084 : shutup restorecon > the name server process doesnt start: Feb 20 16:05:34 gate named[26672]: starting BIND 9.3.1rc1 -u named Feb 20 16:05:34 gate named[26672]: found 1 CPU, using 1 worker thread Feb 20 16:05:34 gate named[26672]: loading configuration from '/etc/named.conf' Feb 20 16:05:34 gate named[26672]: ifiter_getifaddrs.c:109: INSIST(ifa->ifa_addr != ((void *)0)) failed Feb 20 16:05:34 gate named[26672]: exiting (due to assertion failure) is it a bug or configuration issue? /ds From jspaleta at gmail.com Sun Feb 20 17:07:35 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 20 Feb 2005 12:07:35 -0500 Subject: rawhide report: 20050219 changes In-Reply-To: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> Message-ID: <604aa7910502200907715de79a@mail.gmail.com> On Sat, 19 Feb 2005 08:44:40 -0500, Build System wrote: > gamin-0.0.24-1 FYI, the gamin* packages in rawhide look 'older' to both yum and up2date than the fc3 updates. This might be a small problem to tester trying to upgrade to fc4 test1. This is especially problematic for the gamin-python package since the fc3 update is built against python2.3. -jef From ben at bagu.org Sun Feb 20 19:33:39 2005 From: ben at bagu.org (Ben Konrath) Date: Sun, 20 Feb 2005 14:33:39 -0500 Subject: inotify kernel for FC3 Message-ID: Hi, I just made an inotify enabled kernel for FC3. To install it, add something like this to your /etc/yum.conf: [inotify] name=inotify baseurl=http://www.bagu.org/inotify enabled=0 gpgcheck=0 And then run: yum --enablerepo=inotify install kernel-smp-2.6.10-1.766.inotify.0.19_FC3.i686 Enjoy, Ben From Nicolas.Mailhot at laPoste.net Sun Feb 20 22:35:37 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 20 Feb 2005 23:35:37 +0100 Subject: RFE: Put fedora on a diet In-Reply-To: <9f50a7a005021922376f3c2baf@mail.gmail.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> <9f50a7a005021922376f3c2baf@mail.gmail.com> Message-ID: <1108938938.29016.4.camel@rousalka.dyndns.org> Le dimanche 20 f?vrier 2005 ? 00:37 -0600, Jerone Young a ?crit : >Since Fedora Core is a general purpose Linux distributions it's size >will actually increase over time. Why you ask? Because with more users >come more use cases. The beautiful part of Fedora is that a user can >install a base system and have just about everything they need. Not >everybody likes playing around finding packages and what not >(especially new users), they want it to be there and ready to use. If >you have a problem with the base install then you can customize your >install to be smaller. The other thing is hard disk space is dirt >cheap! Can you even buy anything under 80Gigs? Think boot-on-a flash/rom for things like pvr boxes where hd space is reserved to the data, router/nat boxes, multi-boot setups where your 80 Gig is split in multiple small chunks, etc, etc The simple fact is general generic base (for RHEL and lots of other things) means FC must scale to low-storage-space setups too. (plus multiple interdependencies make it very hard to remove legacy libs once they've been linked almost everywhere just because one could do it at a time) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sean.bruno at dsl-only.net Sun Feb 20 23:59:35 2005 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 20 Feb 2005 15:59:35 -0800 Subject: Latest selinux policy update disables NIS Message-ID: <1108943975.16613.5.camel@oscar.metro1.com> The latest selinux policy update threw me for a loop this week. It seems to have caused NIS to stop functioning altogether. This seems bad, but I don't know if it was intentional. To work around this, I went into the GUI security level tool and disabled selinux for NIS. Should this be a bug? Sean From rkearey at redhat.com Mon Feb 21 00:37:27 2005 From: rkearey at redhat.com (Rob Kearey) Date: Mon, 21 Feb 2005 10:37:27 +1000 Subject: Running with vm.overcommit_memory=2 In-Reply-To: <20050217153249.1dbd35f8@nausicaa.camperquake.de> References: <20050217143021.35815547@nausicaa.camperquake.de> <42149DC5.7000903@math.unl.edu> <20050217153249.1dbd35f8@nausicaa.camperquake.de> Message-ID: <42192D47.1000008@redhat.com> Ralf Ertzinger wrote: > Rex Dieter wrote: >>I wouldn't even think about running a system with *0* swap these days. > Throwing (virtual) memory at the problem is certainly going to make it > go away, I am sure. It just is not right. 640MB is not exactly a small > amount of memory (be it real or virtual). This may be a useful read: http://sourcefrog.net/weblog/software/linux-kernel/swap.html -- Rob Kearey Website: http://apac.redhat.com Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer +61 7 3514 8102 Stuff: http://people.redhat.com/rkearey From drepper at redhat.com Mon Feb 21 00:45:58 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 20 Feb 2005 16:45:58 -0800 Subject: Latest selinux policy update disables NIS In-Reply-To: <1108943975.16613.5.camel@oscar.metro1.com> References: <1108943975.16613.5.camel@oscar.metro1.com> Message-ID: <42192F46.4050209@redhat.com> Sean Bruno wrote: > The latest selinux policy update threw me for a loop this week. It > seems to have caused NIS to stop functioning altogether. This seems > bad, but I don't know if it was intentional. What messages do you get in /var/log/messages? There is one problem with all but the latest version of dhcp which created yp.conf files incorrectly (see bz 147926). Beside that I don't think anything else is known. Only looking at the messages will help to say more. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From djotaku1282 at yahoo.com Mon Feb 21 01:43:45 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Sun, 20 Feb 2005 17:43:45 -0800 (PST) Subject: Fedora needs to go on a diet Message-ID: <20050221014345.10250.qmail@web50808.mail.yahoo.com> I actually really like Fedora as is. I hate having to find stuff on Fed-extras and other sites/repos, especially when I have to figure out what the cryptic name these packages are given, actually does. They're ok for true extras, but for the already built-in functions, they should remain. Also, as was said before, as time passes hds are bigger and bigger and it really doesn't matter anymore. I saw a 300 GB hd the other day for only $250. The cheapest computer at Best Buy had a 40 GB hd. Plus, as long as we continue to give people the ability to pick/choose applications (as is now), they can choose more or less. Finally, I am currently running FC3 on 2 legacy computers and FC1 on one of them. They are 400-600Mhz machines with 10 GB max. None of them has over 128 Mb of ram. Doesn't matter, they all run perfectly fine! I mean, they run at ~Win 98 speeds - Openoffice can take on the order of two minutes to load, but once it's running it runs great. Frankly, with how well FC runs on these legacy machines, I can't wait to install it on a nice new computer. (Just need some $$$ first) __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From rees at ddcom.co.jp Mon Feb 21 02:35:26 2005 From: rees at ddcom.co.jp (Joel) Date: Mon, 21 Feb 2005 11:35:26 +0900 Subject: /usr/bin/rmic -- why? In-Reply-To: <20050218184403.D0BA.REES@ddcom.co.jp> References: <20050218184403.D0BA.REES@ddcom.co.jp> Message-ID: <20050221102216.7B09.REES@ddcom.co.jp> (Apologies for the cross-post.) I asked > > What are jar, rmiregistry, and who knows what else doing in /usr/bin ? > > > > I know that everyone just shoves /usr/local/java/sdk/bin (or whatever) > > in at the top of $PATH, but I can think of several very good reasons > > that is not a good idea. So if there's a good reason, I'd like some > > feedback before I post a bug on this. Rahul explained > they are java related packages. they might have been installed by > default. if you dont want remove them. this is not a bug and James added > They're symlinks into the Red Hat alternatives scheme. > man 8 alternatives says: > > [...] > > So they allow you to have a number of Java virtual machines, and easily > swap from one to another. and then Matthew clarified > The Jpackage-style Java installs (including the gcj one included in FC3) > use the alternatives(8) system to manage simultaneous installation of > multiple versions. Okay, I'll dig into the alternatives man page, although I really didn't want to know about that. Don't plan on using it. But I did not install any java at all when I installed Fedora. There was no javac in the same place. Moreover, on this FC2 install, these are not symbolic links. If they're multiply linked, the links are hard. They do not show up in /etc/alternatives, nor in anything in /var/lib/alternatives. Why are jar and rmic in there at all? Are they being used by the system, and if I remove them will something break? How do I find out what else to remove? I really would prefer not to put the directory where I've installed sun's java at the top of my path, but it looks like I have to put it there if I want to compile sun-standard java 5 rmi. -- Joel Rees digitcom, inc. ???????? Kobe, Japan +81-78-672-8800 ** ** From djotaku1282 at yahoo.com Mon Feb 21 04:25:41 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Sun, 20 Feb 2005 20:25:41 -0800 (PST) Subject: thunderbird Message-ID: <20050221042541.79988.qmail@web50802.mail.yahoo.com> Are there currently any plans to include Thunderbird in FC4? __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From rodd at clarkson.id.au Mon Feb 21 05:09:10 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 21 Feb 2005 16:09:10 +1100 Subject: thunderbird In-Reply-To: <20050221042541.79988.qmail@web50802.mail.yahoo.com> References: <20050221042541.79988.qmail@web50802.mail.yahoo.com> Message-ID: <1108962551.8565.43.camel@trevally.redfishdemo.com> On Sun, 2005-02-20 at 20:25 -0800, The DJ wrote: >Are there currently any plans to include Thunderbird >in FC4? Do you mean thunderbird the email client, related to firefox? It's in rawhide as thunderbird-1.0-2..rpm which means it will almost surely be included in FC4. thunderbird was also in FC3 so I can't imagine why they would pull it out. Rodd From sean.bruno at dsl-only.net Mon Feb 21 05:35:36 2005 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 20 Feb 2005 21:35:36 -0800 Subject: Latest selinux policy update disables NIS In-Reply-To: <42192F46.4050209@redhat.com> References: <1108943975.16613.5.camel@oscar.metro1.com> <42192F46.4050209@redhat.com> Message-ID: <1108964136.22267.0.camel@localhost.localdomain> > What messages do you get in /var/log/messages? There is one problem > with all but the latest version of dhcp which created yp.conf files > incorrectly (see bz 147926). Beside that I don't think anything else is > known. Only looking at the messages will help to say more. Interestingly enough, I don't see anything. However, /etc/init.d/ypbind throws an error about accessing /var/yp. Thoughts? From kevinverma at gmail.com Mon Feb 21 05:22:42 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Mon, 21 Feb 2005 09:22:42 +0400 Subject: Fedora Installation on USB Mass Storage devices Message-ID: <1108963362.7759.1.camel@localhost.localdomain> I'll like to know if this is possible to install Fedora on a USB mass storage device yet ? Cheers, -- Kevin Verma From skvidal at phy.duke.edu Mon Feb 21 05:56:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 00:56:21 -0500 Subject: Fedora Installation on USB Mass Storage devices In-Reply-To: <1108963362.7759.1.camel@localhost.localdomain> References: <1108963362.7759.1.camel@localhost.localdomain> Message-ID: <1108965381.7032.38.camel@cutter> On Mon, 2005-02-21 at 09:22 +0400, Kevin Verma wrote: >I'll like to know if this is possible to install Fedora on a USB mass >storage device yet ? 1. Don't crosspost 2. Don't crosspost off topic posts. fedora-list is the best place to ask this question. -sv From rahulsundaram at yahoo.co.in Mon Feb 21 08:21:56 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Mon, 21 Feb 2005 00:21:56 -0800 (PST) Subject: /usr/bin/rmic -- why? In-Reply-To: <20050221102216.7B09.REES@ddcom.co.jp> Message-ID: <20050221082156.81593.qmail@web8502.mail.in.yahoo.com> Hi > > Why are jar and rmic in there at all? Are they being > used by the system, > and if I remove them will something break? How do I > find out what else > to remove? if you want to continue the dicussion, you could have done that in the fedora users list itself. this is off topic here. ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From rahulsundaram at yahoo.co.in Mon Feb 21 08:21:56 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Mon, 21 Feb 2005 00:21:56 -0800 (PST) Subject: /usr/bin/rmic -- why? In-Reply-To: <20050221102216.7B09.REES@ddcom.co.jp> Message-ID: <20050221082156.81593.qmail@web8502.mail.in.yahoo.com> Hi > > Why are jar and rmic in there at all? Are they being > used by the system, > and if I remove them will something break? How do I > find out what else > to remove? if you want to continue the dicussion, you could have done that in the fedora users list itself. this is off topic here. ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From nphilipp at redhat.com Mon Feb 21 08:40:08 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 21 Feb 2005 09:40:08 +0100 Subject: bzflag 2.0 (was: Re: rawhide report: 20050219 changes) In-Reply-To: <20050219235824.6e93f3e9@python2> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> <20050219235824.6e93f3e9@python2> Message-ID: <1108975208.19681.10.camel@gibraltar.stuttgart.redhat.com> On Sat, 2005-02-19 at 23:58 +0100, Matthias Saou wrote: > Build System wrote : > > > bzflag-2.0.0-2 > > -------------- > > * Tue Jan 18 2005 Nils Philippsen 2.0.0-2 > > - build as PIE > > > > * Tue Jan 18 2005 Nils Philippsen 2.0.0-1 > > - correct source URL > > - buildrequire ncurses-devel > > > > * Tue Jan 18 2005 Nils Philippsen 2.0.0-0.1 > > - version 2.0.0.20050117 > > - buildrequire xorg-x11-devel, not XFree86-devel > > Maybe Nils should become the bugzilla owner of bzflag? Well maybe not considering how I failed to use the correct dates in the changelog ;-). It's interesting how the build system used the correct Tuesday for the wrong date though instead if the Friday I used, probably something which should be complained about at some point, when checking in, before building, ... rather than magically correcting this (not). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From rees at ddcom.co.jp Mon Feb 21 11:16:47 2005 From: rees at ddcom.co.jp (Joel) Date: Mon, 21 Feb 2005 20:16:47 +0900 Subject: /usr/bin/rmic -- why? Message-ID: <20050221195949.7B25.REES@ddcom.co.jp> > > Why are jar and rmic in there at all? Are they being > > used by the system, > > and if I remove them will something break? How do I > > find out what else > > to remove? > > if you want to continue the dicussion, you could have > done that in the fedora users list itself. this is off > topic here. I want to know why rmic is in the default install **** before I install java. **** Is that a question for users? If so, I don't mind asking again on the user list. But I wonder why all the answers I got so far explained why it would be there *** if I had installed java ***, which I haven't. -- Joel Rees digitcom, inc. ???????? Kobe, Japan +81-78-672-8800 ** ** From rees at ddcom.co.jp Mon Feb 21 12:18:43 2005 From: rees at ddcom.co.jp (Joel) Date: Mon, 21 Feb 2005 21:18:43 +0900 Subject: /usr/bin/rmic -- why? In-Reply-To: <20050221195949.7B25.REES@ddcom.co.jp> References: <20050221195949.7B25.REES@ddcom.co.jp> Message-ID: <20050221210658.7A7D.REES@ddcom.co.jp> Woops. I wrote > [...] But I wonder why all the answers I got so far explained why > it would be there > *** if I had installed java ***, > which I haven't. ... if I had installed a java _rpm_, which I'm pretty sure I haven't. If I could scrounge up an extra box, I'd check, but I can't, so I'm just going on my admin notes when I say I've never installed a java rpm on it. Since the non-rpm install is just tar and setting paths and softlinks by hand, and those aren't softlinks, and I know I didn't put them there, the only way I can see how they got there would be through the Linux install process, and I'm pretty sure I didn't do anything with java at that point, either. -- Joel Rees digitcom, inc. ???????? Kobe, Japan +81-78-672-8800 ** ** From buildsys at redhat.com Mon Feb 21 13:31:43 2005 From: buildsys at redhat.com (Build System) Date: Mon, 21 Feb 2005 08:31:43 -0500 Subject: rawhide report: 20050221 changes Message-ID: <200502211331.j1LDVhQU011380@porkchop.devel.redhat.com> Updated Packages: anaconda-10.2.0.22-1 -------------------- * Sun Feb 20 2005 Jeremy Katz - 10.2.0.22-1 - revert some of the ppc changes so that lvm is used (nasrat) - Try to fix bogl stuff some more (#149039) - x86_64 install fixes (#149040) * Sun Feb 20 2005 Peter Jones - 10.2.0.21-1 - get rid of lilo - make grub work with raid1 /boot and /root audit-0.6.3-2 ------------- * Sun Feb 20 2005 Steve Grubb 0.6.3-2 - Another lib64 correction * Sun Feb 20 2005 Steve Grubb 0.6.3-1 - Change pam install from /lib/security to /lib64/security - Change pam_audit to write loginuid to /proc/pid/loginuid - Add pam_session_close handle - Update to newest kernel headers autoconf213-2.13-10 ------------------- * Mon Feb 21 2005 Karsten Hopp 2.13-10 - Copyright -> License bind-22:9.3.1rc1-2 ------------------ * Sun Feb 20 2005 Jason Vas Dias - 22:9.3.1rc1-2 - fix bug 149183: don't use getifaddrs() . booty-0.46-1 ------------ * Sun Feb 20 2005 Peter Jones 0.46-1 - add in silo.conf handling, so spot will stop harassing me. - add support for /boot on raid1 with grub bzflag-2.0.0-3 -------------- * Mon Feb 21 2005 Nils Philippsen 2.0.0-3 - fix dates in %changelog * Fri Feb 18 2005 Nils Philippsen 2.0.0-2 - build as PIE * Fri Feb 18 2005 Nils Philippsen 2.0.0-1 - correct source URL - buildrequire ncurses-devel ecj-1:3.1-0.M4.5 ---------------- * Sun Feb 20 2005 Andrew Overholt 1:3.1.0.M4.5 - Upgrade back to 3.1M4. - Don't build for x86 and x86_64. - Provide eclipse-ecj until we can deprecate this package. * Fri Jan 14 2005 Andrew Overholt 3.1.0.M4.4 - build for all but x86 * Thu Jan 13 2005 Andrew Overholt 3.1.0.M4.3 - build for ppc exclusively ecj-1:3.1-0.M4.6 ---------------- * Sun Feb 20 2005 Andrew Overholt 1:3.1.0.M4.6 - Upgrade back to 3.1M4. - Don't build for i386 and x86_64. - Provide eclipse-ecj until we can deprecate this package. * Fri Jan 14 2005 Andrew Overholt 3.1.0.M4.4 - build for all but x86 * Thu Jan 13 2005 Andrew Overholt 3.1.0.M4.3 - build for ppc exclusively grub-0.95-10 ------------ * Sun Feb 20 2005 Peter Jones 0.96-10 - Always install in MBR for raid1 /boot/ * Sun Feb 20 2005 Peter Jones 0.96-9 - Always use full path for mdadm in grub-install hfsutils-3.2.6-6 ---------------- * Sun Feb 20 2005 David Woodhouse 3.2.6-6 - Handle files larger than 2GiB - Include hfsck * Mon Feb 14 2005 David Woodhouse 3.2.6-5 - s/Copyright:/License:/ (sic) * Tue Jun 15 2004 Elliot Lee 3.2.6-4 - rebuilt jwhois-3.2.2-10 --------------- * Sun Feb 20 2005 Miloslav Trmac - 3.2.2-10 - Update to upstream CVS config as of Feb 10 2005 (#147562); Remove now unecessary denic.patch, update update_2004.patch - Fix .cd, .gi, .io (#146613, patch by Robert Scheck) kbd-1.12-5 ---------- * Sun Feb 20 2005 Miloslav Trmac - 1.12-5 - Put "Meta_acute" back in German keymaps, just ignore it in (loadkeys -u) (patch by Jochen Schmitt) - Don't ship patch backup files, simpler way parted-1.6.21-2 --------------- * Sun Feb 20 2005 Paul Nasrat 1.6.21-2 - Support lvm flags on mac partitions (#121266) rpmdb-fedora-1:4-0.20050221 --------------------------- From aoliva at redhat.com Mon Feb 21 13:44:36 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Feb 2005 10:44:36 -0300 Subject: rawhide report: 20050219 changes In-Reply-To: <4218AA1B.8060107@arcor.de> References: <200502191344.j1JDieO4023882@porkchop.devel.redhat.com> <4218AA1B.8060107@arcor.de> Message-ID: On Feb 20, 2005, "D. Stolte" wrote: > Feb 20 16:05:34 gate named[26672]: ifiter_getifaddrs.c:109: INSIST(ifa->ifa_addr != ((void *)0)) failed > is it a bug or configuration issue? Bug. It's supposed to be fixed in today's rawhide. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dwalsh at redhat.com Mon Feb 21 16:22:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 21 Feb 2005 11:22:08 -0500 Subject: Latest selinux policy update disables NIS In-Reply-To: <1108964136.22267.0.camel@localhost.localdomain> References: <1108943975.16613.5.camel@oscar.metro1.com> <42192F46.4050209@redhat.com> <1108964136.22267.0.camel@localhost.localdomain> Message-ID: <421A0AB0.7060406@redhat.com> Sean Bruno wrote: >>What messages do you get in /var/log/messages? There is one problem >>with all but the latest version of dhcp which created yp.conf files >>incorrectly (see bz 147926). Beside that I don't think anything else is >>known. Only looking at the messages will help to say more. >> >> > >Interestingly enough, I don't see anything. However, /etc/init.d/ypbind >throws an error about accessing /var/yp. > >Thoughts? > > > Can you check /var/log/audit.log also? Which policy are you running? If you have sources installed you can do a make -C /etc/selinux/targeted/src/policy enableaudit reload And see if you have any audit messages. Dan From linux_4ever at yahoo.com Mon Feb 21 16:33:22 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 21 Feb 2005 08:33:22 -0800 (PST) Subject: Latest selinux policy update disables NIS In-Reply-To: <421A0AB0.7060406@redhat.com> Message-ID: <20050221163323.57543.qmail@web51504.mail.yahoo.com> >Can you check /var/log/audit.log also? He won't have anything here unless the audit daemon is installed and running. For people who don't know about the audit daemon...if running, the kernel sends all audit messages to it rather than syslog. By default, it stores the audit messages in /var/log/audit.log. If installing, use the one in rawhide. The audit daemon will automatically enable auditing at startup, so you do not need to pass any flags to the kernel from grub. Hope this helps... -Steve Grubb __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From sopwith at redhat.com Mon Feb 21 20:35:34 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 21 Feb 2005 15:35:34 -0500 (EST) Subject: FC4 slimfast slimfest Message-ID: Hi all, Here's a heads up that we need to get rid of about 300M of packages to make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, xemacs, cfengine, and all the games are leading candidates. We also may try to start removing stuff from Core in hopes that it will appear in Extras if someone cares about it. Nothing is set in stone, but if you want to write in favor of keeping something, you'll have to suggest something else of equal or greater size to axe instead. You can view the list of new packages since FC3 (sorted by package size) at http://people.redhat.com/sopwith/new-packages.txt FYI, -- Elliot From josh at bluga.net Mon Feb 21 20:54:20 2005 From: josh at bluga.net (Joshua Eichorn) Date: Mon, 21 Feb 2005 13:54:20 -0700 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <421A4A7C.3000002@bluga.net> Elliot Lee wrote: >Hi all, > >Here's a heads up that we need to get rid of about 300M of packages to >make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, >xemacs, cfengine, and all the games are leading candidates. We also may >try to start removing stuff from Core in hopes that it will appear in >Extras if someone cares about it. > >Nothing is set in stone, but if you want to write in favor of keeping >something, you'll have to suggest something else of equal or greater size >to axe instead. > >You can view the list of new packages since FC3 (sorted by package size) >at http://people.redhat.com/sopwith/new-packages.txt > >FYI, >-- Elliot > > > It would be a shame to lose gnome-games, every computer needs easy access to solitaire. How about dropping some of the random documentation rpms we keep around, they don't follow a pattern anyway (ie we have exim-doc but no postfix-doc, we have python-doc but no php-doc or perl-doc) exim-doc 3.2m python-docs 2.4m python-twisted-docs 6.4m postgresql-docs 4.6m (there are a couple more) Or even better drop tetex-doc 51M (im pretty sure the php manual package got dropped long before it got that big) -josh From mpeters at mac.com Mon Feb 21 21:02:04 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 21 Feb 2005 21:02:04 +0000 Subject: FC4 slimfast slimfest In-Reply-To: (from sopwith@redhat.com on Mon Feb 21 12:35:34 2005) References: Message-ID: <1109019724l.6648l.2l@devel.mpeters.us> On 02/21/2005 12:35:34 PM, Elliot Lee wrote: > Hi all, > > Here's a heads up that we need to get rid of about 300M of packages > to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, > xfce, > xemacs, cfengine, and all the games are leading candidates. We also > may > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. I would take a look at the alternatives that aren't planned to be pushed - like AbiWord, Gnumeric, Balsa Now - those particular packages are packages I personally use quite a bit as I don't use OO.o or Evolution - but if they remained in Extras, I would still be able to install them and thus be happy. I would prefer they were on the core install, but they _are_ alternatives that duplicate functionallity to what is installed by default when you click the "Desktop" install. As long as there isn't a delay for Extras for fc4 like there was for fc3 (IE the day fc4 ships, I could yum install them) Epiphany is another one - I was a die hard epiphany fan, but firefox really is that good. -- Michael A. Peters http://mpeters.us/ From gemi at bluewin.ch Mon Feb 21 21:04:17 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 21 Feb 2005 22:04:17 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <421A4A7C.3000002@bluga.net> References: <421A4A7C.3000002@bluga.net> Message-ID: <1109019857.30173.4.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-21 at 13:54 -0700, Joshua Eichorn wrote: > Elliot Lee wrote: > > >Hi all, > > > >Here's a heads up that we need to get rid of about 300M of packages to > >make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > >xemacs, cfengine, and all the games are leading candidates. We also may > >try to start removing stuff from Core in hopes that it will appear in > >Extras if someone cares about it. Why limit FC4 to 4 CD's? Is it out fear that someone will cry "bloat"? If packages were properly distributed among the CD's, one didn't need to download all images. I admit I am a bit biased since I use XEmacs regularly. I you list I see many java-related packages. Why not bundle them into a separate CD? Another option would be to retain 4 images and create additional images with extras. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From jspaleta at gmail.com Mon Feb 21 21:06:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 21 Feb 2005 16:06:27 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421A4A7C.3000002@bluga.net> References: <421A4A7C.3000002@bluga.net> Message-ID: <604aa791050221130614784876@mail.gmail.com> On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn wrote: > It would be a shame to lose gnome-games, every computer needs easy > access to solitaire. why? so office workers can be less productive? > How about dropping some of the random documentation rpms we keep around, > they don't follow a pattern anyway (ie we have exim-doc but no > postfix-doc, we have python-doc but no php-doc or perl-doc) Let me point out a hidden constraint for this fc4 timescale. You have to think in terms of 'srpms' subpackages can only be dropped.. subpackages can not be moved out of Core into Extras. The -doc packages you describe are actualy subpackages built from the same srpm as the related runtime package. Its inappropriate to drop documentation completely.. and since they are subpackages from the same srpm you can't move them across the Core/Extras boundary. So really the packages you suggest are non-starters.. unless package can be re-engineered so that the docs are built from their own seperate srpms. -jef From dcbw at redhat.com Mon Feb 21 21:10:15 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 21 Feb 2005 16:10:15 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: On Mon, 21 Feb 2005, Elliot Lee wrote: > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. > > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. > > You can view the list of new packages since FC3 (sorted by package size) > at http://people.redhat.com/sopwith/new-packages.txt Is there any particular reason to keep 'gv'? How important is it to keep around pure X11 versions of tools like this? There are gnome & KDE versions of PostScript & PDF viewers that are much more capable, and far less ugly. Furthermore, I think it's time for 'ggv' and 'gpdf' to go as well, in favor of Evince as the Single Gnome Document Viewer for PS/PDF files. Its going to happen at some point anyway, might as well be now. Total savings from these three would be: 169938 gv-3.5.8-29.i386.rpm 936623 ggv-2.8.3-1.i386.rpm 775003 gpdf-2.9.3-1.i386.rpm ---------------------------- 1881564 Dan PS (I think xpdf has to stick around for now...) From josh at bluga.net Mon Feb 21 21:11:06 2005 From: josh at bluga.net (Joshua Eichorn) Date: Mon, 21 Feb 2005 14:11:06 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <604aa791050221130614784876@mail.gmail.com> References: <421A4A7C.3000002@bluga.net> <604aa791050221130614784876@mail.gmail.com> Message-ID: <421A4E6A.2050701@bluga.net> Jeff Spaleta wrote: >On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn wrote: > > >>It would be a shame to lose gnome-games, every computer needs easy >>access to solitaire. >> >> > >why? so office workers can be less productive? > > > Because every graphical OS since 1984 has shipped with it, and it has more users then most other applications. >>How about dropping some of the random documentation rpms we keep around, >>they don't follow a pattern anyway (ie we have exim-doc but no >>postfix-doc, we have python-doc but no php-doc or perl-doc) >> >> > >Let me point out a hidden constraint for this fc4 timescale. You have >to think in terms of 'srpms' subpackages can only be dropped.. >subpackages can not be moved out of Core into Extras. The -doc >packages you describe are actualy subpackages built from the same srpm >as the related runtime package. Its inappropriate to drop >documentation completely.. and since they are subpackages from the >same srpm you can't move them across the Core/Extras boundary. So >really the packages you suggest are non-starters.. unless package can >be re-engineered so that the docs are built from their own seperate >srpms. > > > We have dropped other large doc rpms in the past, its all the web anyway. I'm not saying we can drop all the docs, but the docs for programming languages would be an easy drop and would mesh well with what has happened in the past (dropping php-manual between rh8-9 for example) >-jef > > > -josh From toshio at tiki-lounge.com Mon Feb 21 21:07:21 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 21 Feb 2005 13:07:21 -0800 Subject: FC4 slimfast slimfest In-Reply-To: ; from sopwith@redhat.com on Mon, Feb 21, 2005 at 03:35:34PM -0500 References: Message-ID: <20050221130721.B21733@tiki-lounge.com> On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote: > Hi all, > > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. > Has anyone answered the question of whether RedHat will provide manpower to maintain packages in Extras? (I wasn't at FUDCon -- I was hoping it would get tossed about there.) It's one thing to talk about keeping FC4 to 4 CDs so we don't burden users with downloading extra programs. It's another to say RedHat needs to keep its maintenance of packages down; currently we can only support about 4 CDs worth of stuff. -Toshio From skvidal at phy.duke.edu Mon Feb 21 21:15:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 16:15:20 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221130721.B21733@tiki-lounge.com> References: <20050221130721.B21733@tiki-lounge.com> Message-ID: <1109020521.24448.1.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 13:07 -0800, Toshio Kuratomi wrote: > On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote: > > Hi all, > > > > Here's a heads up that we need to get rid of about 300M of packages to > > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > > xemacs, cfengine, and all the games are leading candidates. We also may > > try to start removing stuff from Core in hopes that it will appear in > > Extras if someone cares about it. > > > Has anyone answered the question of whether RedHat will provide manpower to > maintain packages in Extras? (I wasn't at FUDCon -- I was hoping it would > get tossed about there.) > > It's one thing to talk about keeping FC4 to 4 CDs so we don't burden users > with downloading extra programs. It's another to say RedHat needs to keep > its maintenance of packages down; currently we can only support about 4 CDs > worth of stuff. > No, That's the point - if fedora is going to work and going to have a constantly increasing number of packages then people OUTSIDE of red hat need to play ball. if you don't know how to get on the team go here: http://fedoraproject.org/wiki/Extras/CvsAccess and learn! :) -sv From sopwith at redhat.com Mon Feb 21 21:16:48 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 21 Feb 2005 16:16:48 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <1109019857.30173.4.camel@scriabin.tannenrauch.ch> References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: On Mon, 21 Feb 2005, [ISO-8859-1] G?rard Milmeister wrote: > On Mon, 2005-02-21 at 13:54 -0700, Joshua Eichorn wrote: > > Elliot Lee wrote: > > > > >Hi all, > > > > > >Here's a heads up that we need to get rid of about 300M of packages to > > >make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > > >xemacs, cfengine, and all the games are leading candidates. We also may > > >try to start removing stuff from Core in hopes that it will appear in > > >Extras if someone cares about it. > > Why limit FC4 to 4 CD's? Is it out fear that someone will cry "bloat"? If we add another CD: The companies that create CD sets for magazines or resale will see their media costs go up by 25%. The mirror sites with limited bandwidth and disk space will be likely to stop mirroring Fedora Core. The users who don't want to download and burn another CD will go elsewhere. > If packages were properly distributed among the CD's, one didn't need to > download all images. I admit I am a bit biased since I use XEmacs > regularly. I you list I see many java-related packages. Why not bundle > them into a separate CD? Because we don't have the infrastructure/tools to do it properly. > Another option would be to retain 4 images and create additional images > with extras. Which means removing things from Core so we can put them in Extras... -- Elliot From feliciano.matias at free.fr Mon Feb 21 21:19:48 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 21 Feb 2005 22:19:48 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <421A4A7C.3000002@bluga.net> References: <421A4A7C.3000002@bluga.net> Message-ID: <1109020788.24391.3.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 13:54 -0700, Joshua Eichorn a ?crit : > How about dropping some of the random documentation rpms we keep around, > they don't follow a pattern anyway (ie we have exim-doc but no > postfix-doc, we have python-doc but no php-doc or perl-doc) > I am not agree. If we provide exim, we provide *all* exim. -------------- 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 gemi at bluewin.ch Mon Feb 21 21:23:53 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 21 Feb 2005 22:23:53 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: <1109021034.30549.4.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-21 at 16:16 -0500, Elliot Lee wrote: > > > > Why limit FC4 to 4 CD's? Is it out fear that someone will cry "bloat"? > > If we add another CD: > The companies that create CD sets for magazines or resale will see > their media costs go up by 25%. > > The mirror sites with limited bandwidth and disk space will be > likely to stop mirroring Fedora Core. > > The users who don't want to download and burn another CD will go > elsewhere. > > > If packages were properly distributed among the CD's, one didn't need to > > download all images. I admit I am a bit biased since I use XEmacs > > regularly. I you list I see many java-related packages. Why not bundle > > them into a separate CD? > > Because we don't have the infrastructure/tools to do it properly. > > > Another option would be to retain 4 images and create additional images > > with extras. > > Which means removing things from Core so we can put them in Extras... > -- Elliot > Ok, I understand your reasoning. However I think moving packages from Core to Extras can only be done, if access to Extras is immediate after Core has been installed. Which means: no manual setting up of repository files in /etc/yum.repos.d or /etc/apt. And a usable graphical package manager like synaptic instead of the braindead system-config-packages. As I said, a set of optional Extras CDs, downloadable from the same location as the Core CDs would be a benefit. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gemi at bluewin.ch Mon Feb 21 21:25:45 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 21 Feb 2005 22:25:45 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <1109021145.30549.6.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-21 at 16:10 -0500, Dan Williams wrote: > Is there any particular reason to keep 'gv'? How important is it to keep around > pure X11 versions of tools like this? There are gnome & KDE versions of > PostScript & PDF viewers that are much more capable, and far less ugly. > In my experience it is the fasted PS viewer around. I occasionally use it instead of ggv. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From feliciano.matias at free.fr Mon Feb 21 21:25:40 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 21 Feb 2005 22:25:40 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <1109021140.24391.4.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 15:35 -0500, Elliot Lee a ?crit : > Hi all, > > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. > > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. > > You can view the list of new packages since FC3 (sorted by package size) > at http://people.redhat.com/sopwith/new-packages.txt > Increase the CD size to 700 or 720 Mo ? > FYI, > -- Elliot > -------------- 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 dag at wieers.com Mon Feb 21 21:29:59 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 21 Feb 2005 22:29:59 +0100 (CET) Subject: FC4 slimfast slimfest In-Reply-To: <604aa791050221130614784876@mail.gmail.com> References: <421A4A7C.3000002@bluga.net> <604aa791050221130614784876@mail.gmail.com> Message-ID: On Mon, 21 Feb 2005, Jeff Spaleta wrote: > On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn wrote: > > > How about dropping some of the random documentation rpms we keep around, > > they don't follow a pattern anyway (ie we have exim-doc but no > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > Let me point out a hidden constraint for this fc4 timescale. You have > to think in terms of 'srpms' subpackages can only be dropped.. > subpackages can not be moved out of Core into Extras. The -doc > packages you describe are actualy subpackages built from the same srpm > as the related runtime package. Its inappropriate to drop > documentation completely.. and since they are subpackages from the > same srpm you can't move them across the Core/Extras boundary. So > really the packages you suggest are non-starters.. unless package can > be re-engineered so that the docs are built from their own seperate > srpms. What you could do is have a subset of packages in the repository, but not on the CD. I don't think there is a rule that everything in Fedora Core has to be on the CD or that the repository should equal the CD content. RHEL already does this and has extra packages (mostly -devel stuff) in a special repository. You could release the CD with less packages and release the extra packages in the updates repository at the same time. (I like that more than having yet another repository) Just a thought. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From josh at bluga.net Mon Feb 21 21:30:14 2005 From: josh at bluga.net (Joshua Eichorn) Date: Mon, 21 Feb 2005 14:30:14 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <1109020788.24391.3.camel@one.myworld> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> Message-ID: <421A52E6.4070407@bluga.net> F?liciano Matias wrote: >Le lundi 21 f?vrier 2005 ? 13:54 -0700, Joshua Eichorn a ?crit : > > >>How about dropping some of the random documentation rpms we keep around, >>they don't follow a pattern anyway (ie we have exim-doc but no >>postfix-doc, we have python-doc but no php-doc or perl-doc) >> >> >> > >I am not agree. If we provide exim, we provide *all* exim. > > So we should drop packages used by high % of fedora users for the doc for tetex or exim which are used by a very small % users, and which are also available online? And we should be held hostage in the future by any project that decides that bundling there docs (no matter how big) with the program is a good idea. I would also like to point out, the exim docs are a good example of general space waste on docs packages, it contains html, pdf, ps, and texinfo docs so the same content 4 times (so im guessing just with some new configure flags could take 1/4 the space). -josh From perbj at stanford.edu Mon Feb 21 21:33:06 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 21 Feb 2005 13:33:06 -0800 Subject: FC4 slimfast slimfest In-Reply-To: <1109021145.30549.6.camel@scriabin.tannenrauch.ch> References: <1109021145.30549.6.camel@scriabin.tannenrauch.ch> Message-ID: <1109021586.5319.13.camel@localhost.localdomain> On Mon, 2005-02-21 at 22:25 +0100, G?rard Milmeister wrote: > On Mon, 2005-02-21 at 16:10 -0500, Dan Williams wrote: > > > Is there any particular reason to keep 'gv'? How important is it to keep around > > pure X11 versions of tools like this? There are gnome & KDE versions of > > PostScript & PDF viewers that are much more capable, and far less ugly. > > > In my experience it is the fasted PS viewer around. I occasionally use > it instead of ggv. Did you try Evince yet? I haven't time it against gv, but it feels much faster than ggv. Also, it doen't allocate enough memory to trigger the oom-killer on PDFs with big monochromatic bitmaps, like gpdf sometimes does (apparently this is due to being based on an older version of xpdf, and since Evince exists I doubt that gpdf is ever going to see more significant work). I can't see any place where it's a regression compared to gv. I'd say kill them all, as Dan suggested. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From overholt at redhat.com Mon Feb 21 21:33:54 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 16:33:54 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221213354.GD17531@redhat.com> * Elliot Lee [2005-02-21 15:36]: > > Right now eclipse, xfce, xemacs, cfengine, and all the games are leading > candidates. We also may try to start removing stuff from Core in hopes > that it will appear in Extras if someone cares about it. If Eclipse goes then so does all of the Java stuff since Eclipse is our bytecode compiler. > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. I'm sorry, but I think this is silly and leads to finger-pointing. Just because I work on and use Eclipse and lots of the Java-related stuff doesn't mean that others don't see other things as being just as useful. My only other comments are the following: . there is a very active and vibrant "open source/free java" community . having these in Core brings in a large segment of Java users who would normally just download the non-free JVMs . Eclipse is a well-supported upstream project . we have people within RH working on all of this Andrew "I'm sure I've violated trademarks with my use of the j-word" Overholt From eric at snowmoon.com Mon Feb 21 21:34:45 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 21 Feb 2005 16:34:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <421A53F5.2060302@snowmoon.com> I know this will be an unpopular suggestion, but 300MB is a lot to loose. So I'm just throwing this out there..... KDE by my estimates is 350mb, move it into extras. Cheers, Elliot Lee wrote: > Hi all, > > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Mon Feb 21 21:36:36 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 21 Feb 2005 13:36:36 -0800 Subject: FC4 slimfast slimfest In-Reply-To: <1109021140.24391.4.camel@one.myworld> References: <1109021140.24391.4.camel@one.myworld> Message-ID: <1109021796.5710.152.camel@jkeating2.hq.pogolinux.com> On Mon, 2005-02-21 at 22:25 +0100, F?liciano Matias wrote: > Increase the CD size to 700 or 720 Mo ? > And watch the bugzilla count rise very very quickly. Must use conservative sizes on the isos given the wide array of burners and media used. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From sopwith at redhat.com Mon Feb 21 21:37:21 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 21 Feb 2005 16:37:21 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <20050221213354.GD17531@redhat.com> References: <20050221213354.GD17531@redhat.com> Message-ID: On Mon, 21 Feb 2005, Andrew Overholt wrote: > > Nothing is set in stone, but if you want to write in favor of keeping > > something, you'll have to suggest something else of equal or greater size > > to axe instead. > > I'm sorry, but I think this is silly and leads to finger-pointing. > Just because I work on and use Eclipse and lots of the Java-related > stuff doesn't mean that others don't see other things as being just as > useful. > > My only other comments are the following: > > . there is a very active and vibrant "open source/free java" community > . having these in Core brings in a large segment of Java users who would > normally just download the non-free JVMs > . Eclipse is a well-supported upstream project > . we have people within RH working on all of this I agree 100%, and I for one want Java to become much more widely used. At the same time, we need to stick with a hard constraint of 4 CD's for Fedora Core, and that means cutting out /something/. Best, -- Elliot From ronny-vlug at vlugnet.org Mon Feb 21 21:37:38 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Mon, 21 Feb 2005 22:37:38 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <200502212237.38864.ronny-vlug@vlugnet.org> On Monday 21 February 2005 21:35, Elliot Lee wrote: > Hi all, > > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may please not the gnome/kde games, but some of the bigger ones (bzflag, tuxracer,freeciv,...) not xfce (the only thing usable on old hardware) > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. > > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. xscreensaver-gl-extras (could go in extras) desktop-backgrounds-extra (could go in extras) ggv,gpdf (I think evince can hanlde most stuff, and we still have gs and xpdf) rpmdb-fedora (is this used anywhere else than rpm --redhatprovides/requires?) kdeartwork-icons (could go in extras) comps (what needs/uses this?) HelixPlayer and/or xmms samba-swat (it's as useful as the man page but not much more) nedit (old motif stuff) ncftp (lftp does the same) -- http://LinuxWiki.org/RonnyBuchmann From pmuldoon at redhat.com Mon Feb 21 21:43:04 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Feb 2005 15:43:04 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213354.GD17531@redhat.com> References: <20050221213354.GD17531@redhat.com> Message-ID: <1109022184.5795.87.camel@dhcp-12.hsv.redhat.com> On Mon, 2005-02-21 at 16:33 -0500, Andrew Overholt wrote: > I'm sorry, but I think this is silly and leads to finger-pointing. Just > because I work on and use Eclipse and lots of the Java-related stuff > doesn't mean that others don't see other things as being just as useful. I agree with Andrew. I can make the argument of why Eclipse should stay; but I don't know how to make the argument on what should go in equal size. I can't do the math in such a way, because size != usefulness, at least I believe, in this context. Eclipse is important as it is the IDE with the largest open source developer base; that various open source groups (like classpath) for example, consistently ask us for improvement to it and rely on it; we do a lot of work with Eclipse within Red Hat (RHN use it in their Java stack), and that Eclipse already exists as a product in RHEL and should have a Fedora Core mirror package. Fedora Core is the only place where Eclipse exists as a completely free, natively built Java app, and where we can proudly say, this product is completely free. Regards Phil From overholt at redhat.com Mon Feb 21 21:45:53 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 16:45:53 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213354.GD17531@redhat.com> References: <20050221213354.GD17531@redhat.com> Message-ID: <20050221214553.GE17531@redhat.com> I should also point out that once I get my new 3.1 M5a RPMs building, they'll save us about 20 MB. I know it isn't much, but it's something. Andrew From ronny-vlug at vlugnet.org Mon Feb 21 21:45:35 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Mon, 21 Feb 2005 22:45:35 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <200502212245.35367.ronny-vlug@vlugnet.org> Is IIIMF ready to replace to the old input method stuff? -- http://LinuxWiki.org/RonnyBuchmann From skvidal at phy.duke.edu Mon Feb 21 21:53:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 16:53:41 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109021034.30549.4.camel@scriabin.tannenrauch.ch> References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> <1109021034.30549.4.camel@scriabin.tannenrauch.ch> Message-ID: <1109022821.24448.9.camel@opus.phy.duke.edu> > Ok, I understand your reasoning. However I think moving packages from > Core to Extras can only be done, if access to Extras is immediate after > Core has been installed. Which means: no manual setting up of repository > files in /etc/yum.repos.d or /etc/apt. And a usable graphical package > manager like synaptic instead of the braindead system-config-packages. > As I said, a set of optional Extras CDs, downloadable from the same > location as the Core CDs would be a benefit. 1. extras repo should ship, enabled, in yum.conf for fc4, I think. 2. system-config-packages is going away for pup - hopefully in fc4 - but let's be clear about something - sometimes we have to take iterative steps to get somewhere. We can't do everything all at once. -sv From lists at sapience.com Mon Feb 21 21:54:21 2005 From: lists at sapience.com (Mail Lists) Date: Mon, 21 Feb 2005 16:54:21 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421A53F5.2060302@snowmoon.com> References: <421A53F5.2060302@snowmoon.com> Message-ID: <20050221215421.GC4417@sapience.com> On Mon, Feb 21, 2005 at 04:34:45PM -0500, Eric Warnke wrote: > KDE by my estimates is 350mb, move it into extras. Opinions vary. I'd say toss gnome and keep kde - it is substantially more functional and professional. Another opinion. g/ From aoliva at redhat.com Mon Feb 21 21:55:59 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Feb 2005 18:55:59 -0300 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: On Feb 21, 2005, Elliot Lee wrote: > On Mon, 21 Feb 2005, [ISO-8859-1] G?rard Milmeister wrote: >> On Mon, 2005-02-21 at 13:54 -0700, Joshua Eichorn wrote: >> > Elliot Lee wrote: >> > >Here's a heads up that we need to get rid of about 300M of packages to >> > >make sure that FC4 continues to fit on 4 CD's. >> Why limit FC4 to 4 CD's? Is it out fear that someone will cry "bloat"? > If we add another CD: > The companies that create CD sets for magazines or resale will see > their media costs go up by 25%. How about 1 DVD? The binaries for FC1 up to FC3 fit in that, and I very much doubt FC4's wouldn't. CDs are *so* small... People didn't have so much trouble installing GNU/Linux distros from 40+ floppies before I started playing with GNU/Linux myself. Why are 4 or 5 CDs such a big deal? > The mirror sites with limited bandwidth and disk space will be > likely to stop mirroring Fedora Core. If they didn't have trouble mirroring the FC2 DVD images, that include SRPMS, or even mirroring the FC2 i386 and x86_64 CD and DVD isos, with a total of 4 copies of every SRPM (not counting the exploded RPMS and SRPMS trees), why would they have trouble with an additional GiB or so now that we don't include the SRPMS in the DVD images any more? > Which means removing things from Core so we can put them in Extras... How about moving Gnome and KDE to extras? That would save a lot of space. Then the same clueless users that would be driven away by the additional half-CD would think: hey, cool, this distro is a single CD (or maybe two), why not give it a try? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Mon Feb 21 21:58:14 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Feb 2005 18:58:14 -0300 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: On Feb 21, 2005, Elliot Lee wrote: > The mirror sites with limited bandwidth and disk space will be > likely to stop mirroring Fedora Core. And as Fedora shrinks in out-of-the-box usability because more and more important features will be pushed to Extras, that won't be available from CD vendors nor downloadable in the form of CDs, they might even stop mirroring Fedora Core since nobody will want it. Or are Extras going to actually be made part of the distro for real, as opposed to a dump of packages that we can't fit in 4 CDs, or don't want to support, or both? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From notting at redhat.com Mon Feb 21 21:30:44 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 16:30:44 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109021140.24391.4.camel@one.myworld> References: <1109021140.24391.4.camel@one.myworld> Message-ID: <20050221213044.GF31765@nostromo.devel.redhat.com> F?liciano Matias (feliciano.matias at free.fr) said: > > You can view the list of new packages since FC3 (sorted by package size) > > at http://people.redhat.com/sopwith/new-packages.txt > > Increase the CD size to 700 or 720 Mo ? This was tried around Red Hat Linux 8.0. There were too many failures, really. Bill From notting at redhat.com Mon Feb 21 21:29:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 16:29:40 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109021034.30549.4.camel@scriabin.tannenrauch.ch> References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> <1109021034.30549.4.camel@scriabin.tannenrauch.ch> Message-ID: <20050221212939.GE31765@nostromo.devel.redhat.com> G?rard Milmeister (gemi at bluewin.ch) said: > Ok, I understand your reasoning. However I think moving packages from > Core to Extras can only be done, if access to Extras is immediate after > Core has been installed. Which means: no manual setting up of repository > files in /etc/yum.repos.d or /etc/apt. Planned. > And a usable graphical package > manager like synaptic instead of the braindead system-config-packages. > As I said, a set of optional Extras CDs, downloadable from the same > location as the Core CDs would be a benefit. https://www.redhat.com/archives/fedora-config-list/2005-January/msg00017.html Bill From notting at redhat.com Mon Feb 21 21:19:34 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 16:19:34 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221211934.GD31765@nostromo.devel.redhat.com> Elliot Lee (sopwith at redhat.com) said: > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. OK, so: - non-IIIMF input methods - they are now obsolete for a few releases - mozilla (classic) - superseded by firefox, thunderbird, epiphany, etc - XFCE - we already have GNOME and KDE - Eclipse - it's just Too Big. Moreover, it won't cause the Upgrade problem (1) - cfengine - it's not in use by Core packages, ergo, it makes sense for Extras - One of XEmacs/emacs. :) - gpdf/ggv/gv/xpdf - superceded by evince That's my opinion, anyway. Bill (1) The problem with moving any large package from Core to Extras is that, until anaconda grows support for multiple repositories, upgrades will cause failures. If you move stuff that isn't *yet* in a Core release, you avoid that. From jkeating at j2solutions.net Mon Feb 21 22:04:00 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 21 Feb 2005 14:04:00 -0800 Subject: Proposal for CD count in FC4 Message-ID: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> Here is my proposal: Given that x86_64 platform will remain at 5CDs unless we do something drastic, and that FC5 is targeted to have the ability to install from other repos during anaconda install, we allow FC4 to ship with a 5CD count for both (all) archs. Then we target FC5 to move some packages to Extras, and some packages to an online RH controlled repo much like the RHEL extras. Its still RH maintained, but not shipped on the CD iso sets. This would allow us to drop down to 2CDs or so in size for the shippable media, but still allow installing to the full package set. A side goal would be to ease the process to create installs sets from a given package list. This would allow people that have done one install using various repos to create a CD set from those packages and redistribute. Yes I know this brings up the problem that the CDs themselves do not represent the entire Fedora Core product, something that RH has been against for a long time (notice the lack of Magazine versions of Red Hat Linux and FC), but given the emergence of Fedora Extras, I think this has become less of an issue. Thoughts? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From aoliva at redhat.com Mon Feb 21 22:05:33 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Feb 2005 19:05:33 -0300 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: On Feb 21, 2005, Elliot Lee wrote: > The companies that create CD sets for magazines or resale will see > their media costs go up by 25%. Remember the Wide Open Magazine, that included Fedora Core 1, somehow fit into 3 CDs instead of the 4 official CDs from the FC1 official release? Why couldn't companies that create CD sets for magazines or resale do something similar? We could surely amend the trademark guidelines to enable anyone to distribute slim versions of fedora containing a subset of the binary packages that we ship in the official CDs, imposing a requirement such as that a list of the omitted packages be made prominently visible. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From alan at redhat.com Mon Feb 21 22:07:31 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 17:07:31 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221220731.GB11759@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote: > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. What suddenely got so much larger ? > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. Really some games need to stay - they are one of the things that make people use Linux and choose it. To be quite frank I'd rather see all the java stuff dumped off to a java-extras CD or fedora extras. Ditto eclipse with it. GFS is also clearly obscure extras material From cmadams at hiwaay.net Mon Feb 21 22:07:47 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Feb 2005 16:07:47 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050221211934.GD31765@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> Message-ID: <20050221220747.GD1027233@hiwaay.net> Once upon a time, Bill Nottingham said: > (1) The problem with moving any large package from Core to Extras is that, > until anaconda grows support for multiple repositories, upgrades > will cause failures. If you move stuff that isn't *yet* in a Core > release, you avoid that. That's also why I think there should be ISOs of Fedora Extras available. Maybe not for FC4 (if pushing something significant from FC3 to FE4 can be avoided), but down the road. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 21 22:09:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 21 Feb 2005 23:09:25 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221230925.7a9fabf8@python2> Elliot Lee wrote : > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. For me, can go (into Extras) : - desktop-backgrounds-extra - compat-gcc-8-3.3.4.2 (if nothing in FC4 relies on it to be built anymore) - tuxracer (nothing new in ages, and not a really exciting game) - abiword, gnumeric (I use them a lot, but OOo is included) I'd definitely like to see xfce kept, as it's a nice light desktop manager alternative. Looking at Eclipse and other java related stuff... wow, it's huge, and represents an amazing number of packages... I definitely don't know enough about it to identify anything that could be considered optional, but if part of it is, I'd definitely agree to have it go back into a specialized location. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.69 0.29 0.15 From alan at redhat.com Mon Feb 21 22:10:23 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 17:10:23 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <604aa791050221130614784876@mail.gmail.com> References: <421A4A7C.3000002@bluga.net> <604aa791050221130614784876@mail.gmail.com> Message-ID: <20050221221023.GD11759@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 04:06:27PM -0500, Jeff Spaleta wrote: > On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn wrote: > > It would be a shame to lose gnome-games, every computer needs easy > > access to solitaire. > > why? so office workers can be less productive? Many people first used Linux because "the solitaire was better". Seriously. From alan at redhat.com Mon Feb 21 22:11:22 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 17:11:22 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221221122.GE11759@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 04:10:15PM -0500, Dan Williams wrote: > Furthermore, I think it's time for 'ggv' and 'gpdf' to go as well, in favor of > Evince as the Single Gnome Document Viewer for PS/PDF files. Its going to > happen at some point anyway, might as well be now. They all suck so shipping the one that people will make cool I agree with. Is there a gnome plan for this ? From esr at thyrsus.com Mon Feb 21 22:11:16 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 21 Feb 2005 17:11:16 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109020521.24448.1.camel@opus.phy.duke.edu> References: <20050221130721.B21733@tiki-lounge.com> <1109020521.24448.1.camel@opus.phy.duke.edu> Message-ID: <20050221221116.GB31916@thyrsus.com> seth vidal : > No, That's the point - if fedora is going to work and going to have a > constantly increasing number of packages then people OUTSIDE of red hat > need to play ball. > > if you don't know how to get on the team go here: > http://fedoraproject.org/wiki/Extras/CvsAccess OK. There are a couple of packages I want to push into extras: 1. doclifter, for the document-conversion master plan. 2. gpsd, because David Zeuthen wants it for HAL 3. shipper, for reasons I explained at FUDcon. Anyone willing to sponsor me? -- Eric S. Raymond From dwmw2 at infradead.org Mon Feb 21 22:12:05 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 22:12:05 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050221220747.GD1027233@hiwaay.net> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> Message-ID: <1109023925.26578.46.camel@localhost.localdomain> On Mon, 2005-02-21 at 16:07 -0600, Chris Adams wrote: >Once upon a time, Bill Nottingham said: >> (1) The problem with moving any large package from Core to Extras is that, >> until anaconda grows support for multiple repositories, upgrades >> will cause failures. If you move stuff that isn't *yet* in a Core >> release, you avoid that. > >That's also why I think there should be ISOs of Fedora Extras available. >Maybe not for FC4 (if pushing something significant from FC3 to FE4 can >be avoided), but down the road. Perhaps we should teach anaconda about multiple repositories, and then both CD 5 and the Extras CDs can be optional parts of the install. And of course the DVD will have them all anyway. -- dwmw2 From alan at redhat.com Mon Feb 21 22:13:14 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 17:13:14 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109020788.24391.3.camel@one.myworld> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> Message-ID: <20050221221314.GF11759@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 10:19:48PM +0100, F?liciano Matias wrote: > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > > I am not agree. If we provide exim, we provide *all* exim. Shove exim in extras then. Lets have one of everything (including databases) in the base except where the are real divides (Gnome/KDE) From moe at blagblagblag.org Mon Feb 21 22:14:29 2005 From: moe at blagblagblag.org (jeff) Date: Mon, 21 Feb 2005 15:14:29 -0700 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <200502211514.29635.moe@blagblagblag.org> Alexandre Oliva wrote: > How about 1 DVD? The binaries for FC1 up to FC3 fit in that, > and I very much doubt FC4's wouldn't. CDs are *so* small... Few folks have DVD burners... > How about moving Gnome and KDE to extras? That would save a > lot of space. Then the same clueless users that would be > driven away by the additional half-CD would think: hey, cool, > this distro is a single CD (or maybe two), why not give it a > try? That's what I've done--reduced FC to one CD. This makes it easy for folks to download & hand out. I got tired of burning 3+ CDs each time I wanted to spread a copy. It still has gnome, xfce, firefox, gimp, abiword, etc., plus some FreshRPMS/Dag packages (inkscape, scribus, mplayer, ...). All -devel packages, KDE, OOo, & developer tools are removed from the CD, but in the repository. There's a DVD version that has everything though. I'm not suggesting Fedora do this... But perhaps Fedora could move the -devel & devel tools to the last CDs so people wouldn't have to download as large of a set. This would make it easier for book/magazine publishers too. Developers know yum... -Jeff ftp://ftp.blagblagblag.org/pub/BLAG/linux/30000/en/iso/ From dwmw2 at infradead.org Mon Feb 21 22:14:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 22:14:33 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109020788.24391.3.camel@one.myworld> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> Message-ID: <1109024073.26578.49.camel@localhost.localdomain> On Mon, 2005-02-21 at 22:19 +0100, F?liciano Matias wrote: >Le lundi 21 f?vrier 2005 ? 13:54 -0700, Joshua Eichorn a ?crit : >> How about dropping some of the random documentation rpms we keep around, >> they don't follow a pattern anyway (ie we have exim-doc but no >> postfix-doc, we have python-doc but no php-doc or perl-doc) >> > >I am not agree. If we provide exim, we provide *all* exim. Exim has the best documentation ever I've seen for any Free Software project; it'd be a shame to drop it. But then again, it's available on the web too, and the HTML version is probably the most usable because of the indexing etc. So we could reasonably drop it. -- dwmw2 From ville.skytta at iki.fi Mon Feb 21 22:15:03 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 22 Feb 2005 00:15:03 +0200 Subject: FC4 slimfast slimfest In-Reply-To: <1109019857.30173.4.camel@scriabin.tannenrauch.ch> References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: <1109024103.6386.265.camel@bobcat.mine.nu> On Mon, 2005-02-21 at 22:04 +0100, G?rard Milmeister wrote: > I admit I am a bit biased since I use XEmacs regularly. Me too, s/regularly/all the time/. But I don't think there's anything wrong with moving it to Extras. From skvidal at phy.duke.edu Mon Feb 21 22:15:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 17:15:09 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221116.GB31916@thyrsus.com> References: <20050221130721.B21733@tiki-lounge.com> <1109020521.24448.1.camel@opus.phy.duke.edu> <20050221221116.GB31916@thyrsus.com> Message-ID: <1109024109.24448.12.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 17:11 -0500, Eric S. Raymond wrote: > seth vidal : > > No, That's the point - if fedora is going to work and going to have a > > constantly increasing number of packages then people OUTSIDE of red hat > > need to play ball. > > > > if you don't know how to get on the team go here: > > http://fedoraproject.org/wiki/Extras/CvsAccess > > OK. There are a couple of packages I want to push into extras: > > 1. doclifter, for the document-conversion master plan. > > 2. gpsd, because David Zeuthen wants it for HAL > > 3. shipper, for reasons I explained at FUDcon. > > Anyone willing to sponsor me? Take this to fedora-extras-list, please. thanks -sv From alan at redhat.com Mon Feb 21 22:15:23 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 17:15:23 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213354.GD17531@redhat.com> References: <20050221213354.GD17531@redhat.com> Message-ID: <20050221221523.GG11759@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote: > If Eclipse goes then so does all of the Java stuff since Eclipse is our > bytecode compiler. Suits me fine. Java can all live in a java repository. There is a vast amount of it and we don't have room. Not only that but a java repository set has a natural focus and since most of it is in java it can run asynchronously to the OS updates too From dwmw2 at infradead.org Mon Feb 21 22:17:18 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 22:17:18 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221314.GF11759@devserv.devel.redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> Message-ID: <1109024238.26578.52.camel@localhost.localdomain> On Mon, 2005-02-21 at 17:13 -0500, Alan Cox wrote: >Shove exim in extras then. Lets have one of everything (including databases) >in the base except where the are real divides (Gnome/KDE) I'd rather put sendmail and/or postfix in Extras instead. There's a reason Debian has the default it does. -- dwmw2 From nutello at sweetness.com Mon Feb 21 22:20:36 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Mon, 21 Feb 2005 23:20:36 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221222036.GT18441@plain.rackshack.net> > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may Tuxracer is definitely a candidate there. The last games to go should probably be the standard KDE or GNOME games - if anything, for the reason that they are expected to be part of the full desktop environment release. Cfengine is IMHO not only worth keeping, but also documenting and supporting elsewhere - hint: you could use it with kickstarts and yum. How many people are actually installing Mailman? Webalizer? xcdroast? Is there a decent CD burning tool for GNOME? Is OO.o ever going to drop the private Python tree it has always shipped with? lynx, elinks and w3m all have a noble purpose. One or two of them could be moved to Extras, though. -- Rudi From cmadams at hiwaay.net Mon Feb 21 22:18:56 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Feb 2005 16:18:56 -0600 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050221221856.GF1027233@hiwaay.net> If Eclipse and the other Java stuff were moved to extras, gcc4 could go as well. Drop that and compat-gcc (and maybe the other compat-packages) and it would be close. Unpopular choices: - emacs vs. xemacs - mysql vs. postgresql - mozilla vs. firefox/thunderbird - openoffice.org vs. koffice vs. abiword I don't see GNOME vs. KDE as an option; both are pretty much required to provide a complete desktop. XFCE however could go. Would there be a way to divide up the i18n stuff? Maybe move the Asian support (which seems to be a large bit of space) to a separate disc? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From overholt at redhat.com Mon Feb 21 22:22:00 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:22:00 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221523.GG11759@devserv.devel.redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> Message-ID: <20050221222200.GH17531@redhat.com> * Alan Cox [2005-02-21 17:17]: > On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote: > > If Eclipse goes then so does all of the Java stuff since Eclipse is our > > bytecode compiler. [...] > Java can all live in a java repository. There is a vast amount of it and we > don't have room. I would like to see at least a minimal free Java toolchain/environment in Fedora. This is a slippery slope that leads to language-ism, IMHO. Why stop with Java? Let's put all python stuff in its own repository as well. > Not only that but a java repository set has a natural focus and since > most of it is in java it can run asynchronously to the OS updates too Except for the natively-compiled stuff. Plus, I believe Sopwith said this kind of 3rd party repository isn't possible ATM. Andrew From tmus at tmus.dk Mon Feb 21 22:22:28 2005 From: tmus at tmus.dk (Thomas Steenholdt) Date: Mon, 21 Feb 2005 23:22:28 +0100 Subject: FC4 slimfast slimfest Message-ID: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> Seems to me, that the non-default gcc bundle could go in extras as well... That is, keep the version that the system was built with and throw the other in extras. Pretty significant savings there as well (when we're trying to loose a CD) Also, since OOo is default office app. in both KDE and Gnome, and actually seems to have become quite useful, perhaps abiword, gnumeric, koffice and friends to go to extras too. Anyway, just thoughts! /Thomas From fkooman at tuxed.net Mon Feb 21 22:22:42 2005 From: fkooman at tuxed.net (F. Kooman) Date: Mon, 21 Feb 2005 23:22:42 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109019724l.6648l.2l@devel.mpeters.us> References: <1109019724l.6648l.2l@devel.mpeters.us> Message-ID: <1109024562.10604.6.camel@dilithium.bromstraat.net> On Mon, 2005-02-21 at 21:02 +0000, Michael A. Peters wrote: > Epiphany is another one - I was a die hard epiphany fan, but firefox > really is that good. I'm also using Firefox myself, but I think Epiphany is a better choice for normal users. So move Firefox to Extras / Alternatives. GNOME (evolution for SSL, gnome-panel, Epiphany) depend on Mozilla, so Mozilla is needed anyway, and Epiphany is small, Firefox is 21779238 bytes (rpm -qi firefox). Fran?ois -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From cmadams at hiwaay.net Mon Feb 21 22:24:00 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Feb 2005 16:24:00 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222200.GH17531@redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> Message-ID: <20050221222400.GG1027233@hiwaay.net> Once upon a time, Andrew Overholt said: > I would like to see at least a minimal free Java toolchain/environment in > Fedora. This is a slippery slope that leads to language-ism, IMHO. Why > stop with Java? Let's put all python stuff in its own repository as well. Well, in part because it wasn't there before (while python, perl, etc. were). However, right now, Java requires a second C compiler (gcc4), which is a significant penalty. Once the standard gcc can handle Java, then maybe some base can be included. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From alan at redhat.com Mon Feb 21 22:25:08 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 17:25:08 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222200.GH17531@redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> Message-ID: <20050221222508.GJ11759@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 05:22:00PM -0500, Andrew Overholt wrote: > I would like to see at least a minimal free Java toolchain/environment in > Fedora. This is a slippery slope that leads to language-ism, IMHO. Why > stop with Java? Let's put all python stuff in its own repository as well. The java stuff is new, its huge and its the easiest to push out for now > > Not only that but a java repository set has a natural focus and since > > most of it is in java it can run asynchronously to the OS updates too > > Except for the natively-compiled stuff. Plus, I believe Sopwith said this > kind of 3rd party repository isn't possible ATM. Then how are we proposing to do Fedora extras ? It is definitely possible. A Java themed disk may be trickier as a part of base. If we can't do it then in my opinion its even more critical we keep the current stuff and java should go into fedora extras or Fedora 5 when the tools are fixed. I'd much rather see a Java yum repository and a non-install time java .iso (which is easy to do as a standalone) From dwmw2 at infradead.org Mon Feb 21 22:26:45 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 22:26:45 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222036.GT18441@plain.rackshack.net> References: <20050221222036.GT18441@plain.rackshack.net> Message-ID: <1109024805.26578.62.camel@localhost.localdomain> On Mon, 2005-02-21 at 23:20 +0100, Rudi Chiarito wrote: >How many people are actually installing Mailman? Webalizer? I think Mailman is fairly frequently used. >Is OO.o ever going to drop the private Python tree it has always >shipped with? It's planned. They're working on making it use more of the system libraries instead of its own. See http://people.redhat.com/caolanm/progress/progress.png -- dwmw2 From davej at redhat.com Mon Feb 21 22:28:49 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 21 Feb 2005 17:28:49 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222200.GH17531@redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> Message-ID: <20050221222849.GF3827@redhat.com> On Mon, Feb 21, 2005 at 05:22:00PM -0500, Andrew Overholt wrote: > > Java can all live in a java repository. There is a vast amount of it and we > > don't have room. > > I would like to see at least a minimal free Java toolchain/environment in > Fedora. This is a slippery slope that leads to language-ism, IMHO. Why > stop with Java? Let's put all python stuff in its own repository as well. The important difference here is that system-config-*, yum, up2date, rhn-applet and various other 'core' components are written in python, not java, so the comparison is meaningless imo. Dave From tmus at tmus.dk Mon Feb 21 22:30:45 2005 From: tmus at tmus.dk (Thomas Steenholdt) Date: Mon, 21 Feb 2005 23:30:45 +0100 Subject: Proposal for CD count in FC4 Message-ID: <1f234798489bd415a440704fdb6aa626@192.168.1.254> Jesse Keating wrote: >Here is my proposal: > >Given that x86_64 platform will remain at 5CDs unless we do something >drastic, and that FC5 is targeted to have the ability to install from >other repos during anaconda install, we allow FC4 to ship with a 5CD >count for both (all) archs. Then we target FC5 to move some packages to >Extras, and some packages to an online RH controlled repo much like the >RHEL extras. Its still RH maintained, but not shipped on the CD iso >sets. This would allow us to drop down to 2CDs or so in size for the >shippable media, but still allow installing to the full package set. > >A side goal would be to ease the process to create installs sets from a >given package list. This would allow people that have done one install >using various repos to create a CD set from those packages and >redistribute. > >Yes I know this brings up the problem that the CDs themselves do not >represent the entire Fedora Core product, something that RH has been >against for a long time (notice the lack of Magazine versions of Red Hat >Linux and FC), but given the emergence of Fedora Extras, I think this >has become less of an issue. > >Thoughts? > With an easy option to build a DVD (or even 2) with EVERYTHING from these repositories on them, I'm all for it. I especially like the 2 CD core distro, without-really-loosing-packages idea! /Thomas From toshio at tiki-lounge.com Mon Feb 21 22:26:49 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 21 Feb 2005 14:26:49 -0800 Subject: FC4 slimfast slimfest In-Reply-To: <1109020521.24448.1.camel@opus.phy.duke.edu>; from skvidal@phy.duke.edu on Mon, Feb 21, 2005 at 04:15:20PM -0500 References: <20050221130721.B21733@tiki-lounge.com> <1109020521.24448.1.camel@opus.phy.duke.edu> Message-ID: <20050221142649.D21733@tiki-lounge.com> On Mon, Feb 21, 2005 at 04:15:20PM -0500, seth vidal wrote: > On Mon, 2005-02-21 at 13:07 -0800, Toshio Kuratomi wrote: > > On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote: > > > Hi all, > > > > > > Here's a heads up that we need to get rid of about 300M of packages to > > > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > > > xemacs, cfengine, and all the games are leading candidates. We also may > > > try to start removing stuff from Core in hopes that it will appear in > > > Extras if someone cares about it. > > > > > Has anyone answered the question of whether RedHat will provide manpower to > > maintain packages in Extras? (I wasn't at FUDCon -- I was hoping it would > > get tossed about there.) > > > > It's one thing to talk about keeping FC4 to 4 CDs so we don't burden users > > with downloading extra programs. It's another to say RedHat needs to keep > > its maintenance of packages down; currently we can only support about 4 CDs > > worth of stuff. > > > > No, That's the point - if fedora is going to work and going to have a > constantly increasing number of packages then people OUTSIDE of red hat > need to play ball. > Well yeah. But that's neither here nor there. You're stating that Core is defined as RedHat's contribution and Extras as The Community contribution to the Fedora Project. But that's never been stated. I want that clarified because it's a very different thing to look at Core and say I wouldn't mind having to download that separate from the Core CDs versus I wouldn't mind maintaining that package or seeing it go to /dev/null. This, of course, leads into the complementary question of whether RedHat is willing to open up maintenance of Core packages to Community contributers. So there's a different set of criteria for choosing packages and a different set of helpful suggestions outside the scope of adding/removing packages depending on what we're actually trying to limit (disk space or RedHat maintenence burden.) > if you don't know how to get on the team go here: > http://fedoraproject.org/wiki/Extras/CvsAccess > Yep. But fear of rejection has always kept me shy :-) -Toshio From fitzsim at redhat.com Mon Feb 21 22:38:46 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 21 Feb 2005 17:38:46 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221213354.GD17531@redhat.com> Message-ID: <1109025526.11102.134.camel@tortoise.toronto.redhat.com> On Mon, 2005-02-21 at 16:37 -0500, Elliot Lee wrote: >On Mon, 21 Feb 2005, Andrew Overholt wrote: > >> > Nothing is set in stone, but if you want to write in favor of keeping >> > something, you'll have to suggest something else of equal or greater size >> > to axe instead. >> >> I'm sorry, but I think this is silly and leads to finger-pointing. >> Just because I work on and use Eclipse and lots of the Java-related >> stuff doesn't mean that others don't see other things as being just as >> useful. >> >> My only other comments are the following: >> >> . there is a very active and vibrant "open source/free java" community >> . having these in Core brings in a large segment of Java users who would >> normally just download the non-free JVMs >> . Eclipse is a well-supported upstream project >> . we have people within RH working on all of this > >I agree 100%, and I for one want Java to become much more widely used. At >the same time, we need to stick with a hard constraint of 4 CD's for >Fedora Core, and that means cutting out /something/. > Where does this hard constraint come from? Tom From mrsam at courier-mta.com Mon Feb 21 22:40:00 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 21 Feb 2005 17:40:00 -0500 Subject: FC4 slimfast slimfest References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> Message-ID: Alan Cox writes: > On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote: >> If Eclipse goes then so does all of the Java stuff since Eclipse is our >> bytecode compiler. > > Suits me fine. > > Java can all live in a java repository. There is a vast amount of it and we > don't have room. Not only that but a java repository set has a natural focus > and since most of it is in java it can run asynchronously to the OS updates too I think that it makes sense to have just a JVM in the base distro. Of course, we don't really have a JVM, last time I checked. But, in theory, it makes sense to have a JVM in the distro, with all the java stuff somewhere else. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bdpepple at ameritech.net Mon Feb 21 22:40:52 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 21 Feb 2005 17:40:52 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221142649.D21733@tiki-lounge.com> References: <20050221130721.B21733@tiki-lounge.com> <1109020521.24448.1.camel@opus.phy.duke.edu> <20050221142649.D21733@tiki-lounge.com> Message-ID: <1109025652.24220.0.camel@shuttle.273piedmont.org> On Mon, 2005-02-21 at 14:26 -0800, Toshio Kuratomi wrote: > > if you don't know how to get on the team go here: > > http://fedoraproject.org/wiki/Extras/CvsAccess > > > Yep. But fear of rejection has always kept me shy :-) > > -Toshio > Same here. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A 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 overholt at redhat.com Mon Feb 21 22:46:40 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:46:40 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222849.GF3827@redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222849.GF3827@redhat.com> Message-ID: <20050221224639.GN17531@redhat.com> * Dave Jones [2005-02-21 17:29]: > On Mon, Feb 21, 2005 at 05:22:00PM -0500, Andrew Overholt wrote: > > > > Java can all live in a java repository. There is a vast amount of it and we > > > don't have room. > > > > I would like to see at least a minimal free Java toolchain/environment in > > Fedora. This is a slippery slope that leads to language-ism, IMHO. Why > > stop with Java? Let's put all python stuff in its own repository as well. > > The important difference here is that system-config-*, yum, up2date, rhn-applet and > various other 'core' components are written in python, not java, so the > comparison is meaningless imo. I obviously wasn't serious :) . I really do think that a re-evaluation of what is 'Core' and what is 'Extras' (which I really do believe is a misnomer, BTW) is necessary. Or at least a clarification. Andrew From overholt at redhat.com Mon Feb 21 22:48:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:48:36 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109022821.24448.9.camel@opus.phy.duke.edu> References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> <1109021034.30549.4.camel@scriabin.tannenrauch.ch> <1109022821.24448.9.camel@opus.phy.duke.edu> Message-ID: <20050221224836.GO17531@redhat.com> * seth vidal [2005-02-21 16:55]: > > > Ok, I understand your reasoning. However I think moving packages from > > Core to Extras can only be done, if access to Extras is immediate after > > Core has been installed. Which means: no manual setting up of repository > > files in /etc/yum.repos.d or /etc/apt. And a usable graphical package > > manager like synaptic instead of the braindead system-config-packages. > > As I said, a set of optional Extras CDs, downloadable from the same > > location as the Core CDs would be a benefit. > > 1. extras repo should ship, enabled, in yum.conf for fc4, I think. > 2. system-config-packages is going away for pup - hopefully in fc4 - but > let's be clear about something - sometimes we have to take iterative > steps to get somewhere. We can't do everything all at once. I agree completely. Moving things to Extras without 1. being a given is premature IMO. Andrew From aluchko at redhat.com Mon Feb 21 22:50:03 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Mon, 21 Feb 2005 17:50:03 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213354.GD17531@redhat.com> References: <20050221213354.GD17531@redhat.com> Message-ID: <1109026204.30819.28.camel@tomaluk.toronto.redhat.com> On Mon, 2005-02-21 at 16:33 -0500, Andrew Overholt wrote: > * Elliot Lee [2005-02-21 15:36]: > > > > Right now eclipse, xfce, xemacs, cfengine, and all the games are leading > > candidates. We also may try to start removing stuff from Core in hopes > > that it will appear in Extras if someone cares about it. > > If Eclipse goes then so does all of the Java stuff since Eclipse is our > bytecode compiler. Is it really necessary that we have mozilla and firefox, thunderbird and evolution, abiword, gnumeric and OpenOffice.org, there are a lot of areas with redundant packages in core. As well larger games like tuxracer while nice aren't really necessary for something like core. I'd hate for these packages which aren't adding much in the way of functionality to push out java which really is missing functionality. As it is currently a jvm is one of the first things downloaded by a significant portion of users and java is used by a wide variety of apps. I think functionality as important as java really needs to be left in core. For the aid of the discussion you can find all of the packages currently in the development tree here. http://download.fedora.redhat.com/pub/fedora/linux/core/development/ Aaron From notting at redhat.com Mon Feb 21 22:50:37 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 17:50:37 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221220747.GD1027233@hiwaay.net> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> Message-ID: <20050221225037.GA398@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > That's also why I think there should be ISOs of Fedora Extras available. > Maybe not for FC4 (if pushing something significant from FC3 to FE4 can > be avoided), but down the road. Having ISOs doesn't solve this at install/upgrade time, without the support in the installer. Bill From notting at redhat.com Mon Feb 21 22:50:58 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 17:50:58 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109023925.26578.46.camel@localhost.localdomain> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> Message-ID: <20050221225058.GB398@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > Perhaps we should teach anaconda about multiple repositories, and then > both CD 5 and the Extras CDs can be optional parts of the install. And > of course the DVD will have them all anyway. Multi-repository support for anaconda is planned for FC5. Bill From overholt at redhat.com Mon Feb 21 22:53:15 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:53:15 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> Message-ID: <20050221225315.GP17531@redhat.com> * Elliot Lee [2005-02-21 16:18]: > > The mirror sites with limited bandwidth and disk space will be > likely to stop mirroring Fedora Core. What about Fedora Extras? If it's just as "first class" as Core is, we'll want just as many mirrors there, no? People don't want things moved to Extras if they're going to be (pseudo- or not) second-class packages and that includes mirroring and ease of installation at initial install time IMHO. Andrew From notting at redhat.com Mon Feb 21 22:53:29 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 17:53:29 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> Message-ID: <20050221225329.GC398@nostromo.devel.redhat.com> Thomas Steenholdt (tmus at tmus.dk) said: > Seems to me, that the non-default gcc bundle could go in extras as well... > > That is, keep the version that the system was built with and throw the other > in extras. Alternatively, move to GCC 4, and drop a compiler that way. Bill From fitzsim at redhat.com Mon Feb 21 22:53:44 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 21 Feb 2005 17:53:44 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109025526.11102.134.camel@tortoise.toronto.redhat.com> References: <20050221213354.GD17531@redhat.com> <1109025526.11102.134.camel@tortoise.toronto.redhat.com> Message-ID: <1109026424.11102.144.camel@tortoise.toronto.redhat.com> On Mon, 2005-02-21 at 17:38 -0500, Thomas Fitzsimmons wrote: >On Mon, 2005-02-21 at 16:37 -0500, Elliot Lee wrote: >>On Mon, 21 Feb 2005, Andrew Overholt wrote: >> >>> > Nothing is set in stone, but if you want to write in favor of keeping >>> > something, you'll have to suggest something else of equal or greater size >>> > to axe instead. >>> >>> I'm sorry, but I think this is silly and leads to finger-pointing. >>> Just because I work on and use Eclipse and lots of the Java-related >>> stuff doesn't mean that others don't see other things as being just as >>> useful. >>> >>> My only other comments are the following: >>> >>> . there is a very active and vibrant "open source/free java" community >>> . having these in Core brings in a large segment of Java users who would >>> normally just download the non-free JVMs >>> . Eclipse is a well-supported upstream project >>> . we have people within RH working on all of this >> >>I agree 100%, and I for one want Java to become much more widely used. At >>the same time, we need to stick with a hard constraint of 4 CD's for >>Fedora Core, and that means cutting out /something/. >> > >Where does this hard constraint come from? > Sorry, hadn't read the rest of the thread. I saw Elliot's reasoning and Alexandre's responses -- where he made all the arguments I was going to make :) Tom From skvidal at phy.duke.edu Mon Feb 21 22:54:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 17:54:16 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221225315.GP17531@redhat.com> References: <421A4A7C.3000002@bluga.net> <1109019857.30173.4.camel@scriabin.tannenrauch.ch> <20050221225315.GP17531@redhat.com> Message-ID: <1109026456.24448.21.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 17:53 -0500, Andrew Overholt wrote: > * Elliot Lee [2005-02-21 16:18]: > > > > The mirror sites with limited bandwidth and disk space will be > > likely to stop mirroring Fedora Core. > > What about Fedora Extras? If it's just as "first class" as Core is, we'll > want just as many mirrors there, no? People don't want things moved to > Extras if they're going to be (pseudo- or not) second-class packages and > that includes mirroring and ease of installation at initial install time > IMHO. no isos for extras. that's the difference, by a long shot. -sv From overholt at redhat.com Mon Feb 21 22:55:24 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:55:24 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222400.GG1027233@hiwaay.net> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222400.GG1027233@hiwaay.net> Message-ID: <20050221225524.GQ17531@redhat.com> * Chris Adams [2005-02-21 17:29]: > Once upon a time, Andrew Overholt said: > > I would like to see at least a minimal free Java toolchain/environment in > > Fedora. This is a slippery slope that leads to language-ism, IMHO. Why > > stop with Java? Let's put all python stuff in its own repository as well. > > Well, in part because it wasn't there before (while python, perl, etc. > were). It's sad that much of the java stuff wasn't in FC3 because a lot of it was in FC2 and prior releases (IIRC). Correct me if I'm wrong here (and I know that Eclipse wasn't there :) . > However, right now, Java requires a second C compiler (gcc4), which is a > significant penalty. Once the standard gcc can handle Java, then maybe > some base can be included. This leads me to one suggestion ... Andrew From overholt at redhat.com Mon Feb 21 22:57:42 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:57:42 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221225058.GB398@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <20050221225058.GB398@nostromo.devel.redhat.com> Message-ID: <20050221225742.GR17531@redhat.com> * Bill Nottingham [2005-02-21 17:55]: > David Woodhouse (dwmw2 at infradead.org) said: > > Perhaps we should teach anaconda about multiple repositories, and then > > both CD 5 and the Extras CDs can be optional parts of the install. And > > of course the DVD will have them all anyway. > > Multi-repository support for anaconda is planned for FC5. Then I think we should slim down to extra repositories then. Andrew From overholt at redhat.com Mon Feb 21 22:58:01 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:58:01 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221225329.GC398@nostromo.devel.redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> Message-ID: <20050221225801.GS17531@redhat.com> * Bill Nottingham [2005-02-21 17:55]: > Thomas Steenholdt (tmus at tmus.dk) said: > > Seems to me, that the non-default gcc bundle could go in extras as well... > > > > That is, keep the version that the system was built with and throw the other > > in extras. > > Alternatively, move to GCC 4, and drop a compiler that way. +1 Andrew From jakub at redhat.com Mon Feb 21 22:58:45 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 21 Feb 2005 17:58:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221225329.GC398@nostromo.devel.redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> Message-ID: <20050221225844.GF853@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 05:53:29PM -0500, Bill Nottingham wrote: > Thomas Steenholdt (tmus at tmus.dk) said: > > Seems to me, that the non-default gcc bundle could go in extras as well... > > > > That is, keep the version that the system was built with and throw the other > > in extras. > > Alternatively, move to GCC 4, and drop a compiler that way. Yeah, already in the works. Jakub From overholt at redhat.com Mon Feb 21 22:59:06 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 17:59:06 -0500 Subject: Proposal for CD count in FC4 In-Reply-To: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> References: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050221225906.GT17531@redhat.com> * Jesse Keating [2005-02-21 17:06]: > > Given that x86_64 platform will remain at 5CDs unless we do something > drastic, and that FC5 is targeted to have the ability to install from > other repos during anaconda install, we allow FC4 to ship with a 5CD > count for both (all) archs. Then we target FC5 to move some packages to > Extras, and some packages to an online RH controlled repo much like the > RHEL extras. Its still RH maintained, but not shipped on the CD iso > sets. This would allow us to drop down to 2CDs or so in size for the > shippable media, but still allow installing to the full package set. I really like this idea. Andrew From notting at redhat.com Mon Feb 21 23:00:07 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Feb 2005 18:00:07 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221225742.GR17531@redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <20050221225058.GB398@nostromo.devel.redhat.com> <20050221225742.GR17531@redhat.com> Message-ID: <20050221230007.GD398@nostromo.devel.redhat.com> Andrew Overholt (overholt at redhat.com) said: > > > Perhaps we should teach anaconda about multiple repositories, and then > > > both CD 5 and the Extras CDs can be optional parts of the install. And > > > of course the DVD will have them all anyway. > > > > Multi-repository support for anaconda is planned for FC5. > > Then I think we should slim down to extra repositories then. Sorry, you've lost me here. Bill From lists at donut.dk Mon Feb 21 23:01:30 2005 From: lists at donut.dk (Cream) Date: Tue, 22 Feb 2005 00:01:30 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <421A684A.2090601@donut.dk> Keep XFce, i love that i can totally control my desktop layout from a few XML files. (or my mom's, or a few hundred office pc's). It really makes for a clutter free, productive enviroment. The entire WM in FC3 is 16mb and what about moving the OpenOffice dictionaries to extras? From cra at WPI.EDU Mon Feb 21 23:04:18 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 21 Feb 2005 18:04:18 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109026204.30819.28.camel@tomaluk.toronto.redhat.com> References: <20050221213354.GD17531@redhat.com> <1109026204.30819.28.camel@tomaluk.toronto.redhat.com> Message-ID: <20050221230418.GF5061@angus.ind.WPI.EDU> On Mon, Feb 21, 2005 at 05:50:03PM -0500, Aaron Luchko wrote: > Is it really necessary that we have mozilla and firefox, thunderbird and I recently had a situation where a .swf wouldn't work using the Macromedia repo's flash plugin on firefox, but it worked fine in mozilla. Not sure why. > evolution, abiword, gnumeric and OpenOffice.org, there are a lot of > areas with redundant packages in core. As well larger games like > tuxracer while nice aren't really necessary for something like core. I agree that games aren't really "core" and could be moved to Extras. Maybe just keep the basic games that are included with GNOME/KDE. > As it is currently a jvm is one of the first things downloaded by a > significant portion of users and java is used by a wide variety of apps. > I think functionality as important as java really needs to be left in > core. If I'm not mistaken, I don't think the stuff in FC-devel can be used to replace a jvm for web applets. From mpeters at mac.com Mon Feb 21 23:07:11 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 21 Feb 2005 23:07:11 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221314.GF11759@devserv.devel.redhat.com> (from alan@redhat.com on Mon Feb 21 14:13:14 2005) References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> Message-ID: <1109027231l.6648l.3l@devel.mpeters.us> On 02/21/2005 02:13:14 PM, Alan Cox wrote: > On Mon, Feb 21, 2005 at 10:19:48PM +0100, F?liciano Matias wrote: > > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > > > > I am not agree. If we provide exim, we provide *all* exim. > > Shove exim in extras then. Lets have one of everything (including > databases) > in the base except where the are real divides (Gnome/KDE) Yes - that is why Abiword, Gnumeric, Balsa should be in extras - even though I personally prefer them to OO.o and Evolution, the vast majority of users never install them - but go with OO.o and Evolution, so until that changes, it does not need to be downloaded by the users. There are probably plenty of other apps like those as well. -- Michael A. Peters http://mpeters.us/ From overholt at redhat.com Mon Feb 21 23:08:09 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Feb 2005 18:08:09 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221230007.GD398@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <20050221225058.GB398@nostromo.devel.redhat.com> <20050221225742.GR17531@redhat.com> <20050221230007.GD398@nostromo.devel.redhat.com> Message-ID: <20050221230809.GV17531@redhat.com> * Bill Nottingham [2005-02-21 18:01]: > Andrew Overholt (overholt at redhat.com) said: > > > > Perhaps we should teach anaconda about multiple repositories, and then > > > > both CD 5 and the Extras CDs can be optional parts of the install. And > > > > of course the DVD will have them all anyway. > > > > > > Multi-repository support for anaconda is planned for FC5. > > > > Then I think we should slim down to extra repositories then. > > Sorry, you've lost me here. Sorry, I meant that we should only slim Core down when that support is in anaconda (ie. for FC5). Andrew From balay at fastmail.fm Mon Feb 21 23:11:10 2005 From: balay at fastmail.fm (Satish Balay) Date: Mon, 21 Feb 2005 17:11:10 -0600 (CST) Subject: FC4 slimfast slimfest In-Reply-To: <20050221225801.GS17531@redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> Message-ID: On Mon, 21 Feb 2005, Andrew Overholt wrote: > * Bill Nottingham [2005-02-21 17:55]: > > Thomas Steenholdt (tmus at tmus.dk) said: > > > Seems to me, that the non-default gcc bundle could go in extras as well... > > > > > > That is, keep the version that the system was built with and throw the other > > > in extras. > > > > Alternatively, move to GCC 4, and drop a compiler that way. > > +1 I hope the fortran part of gcc4 has caught up [to do everything gcc3-f77 does]. I guess I should go back and try gcc4 again. Satish From mpeters at mac.com Mon Feb 21 23:11:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 21 Feb 2005 23:11:49 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109023925.26578.46.camel@localhost.localdomain> (from dwmw2@infradead.org on Mon Feb 21 14:12:05 2005) References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> Message-ID: <1109027509l.6648l.4l@devel.mpeters.us> On 02/21/2005 02:12:05 PM, David Woodhouse wrote: > > Perhaps we should teach anaconda about multiple repositories, and > then > both CD 5 and the Extras CDs can be optional parts of the install. > And > of course the DVD will have them all anyway. They should imho be a second DVD even if they would fit on a single. -- Michael A. Peters http://mpeters.us/ From dwmw2 at infradead.org Mon Feb 21 23:11:43 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 23:11:43 +0000 Subject: Proposal for CD count in FC4 In-Reply-To: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> References: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> Message-ID: <1109027503.26578.70.camel@localhost.localdomain> On Mon, 2005-02-21 at 14:04 -0800, Jesse Keating wrote: >Given that x86_64 platform will remain at 5CDs unless we do something >drastic, and that FC5 is targeted to have the ability to install from >other repos during anaconda install, we allow FC4 to ship with a 5CD >count for both (all) archs. PPC is also going to be 5 CDs either way, unless we do something drastic like dropping the PPC64 support. I agree that we should do this for FC5 when anaconda can handle multiple repositories. -- dwmw2 From davej at redhat.com Mon Feb 21 23:18:10 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 21 Feb 2005 18:18:10 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> Message-ID: <20050221231810.GI3827@redhat.com> On Mon, Feb 21, 2005 at 05:11:10PM -0600, Satish Balay wrote: > On Mon, 21 Feb 2005, Andrew Overholt wrote: > > > * Bill Nottingham [2005-02-21 17:55]: > > > Thomas Steenholdt (tmus at tmus.dk) said: > > > > Seems to me, that the non-default gcc bundle could go in extras as well... > > > > > > > > That is, keep the version that the system was built with and throw the other > > > > in extras. > > > > > > Alternatively, move to GCC 4, and drop a compiler that way. > > > > +1 > > I hope the fortran part of gcc4 has caught up [to do everything > gcc3-f77 does]. I guess I should go back and try gcc4 again. Which reminds me. Is fortran really used by enough people to justify its presence in -core ? (Even if so, does it really need to be in the default install?) Dave From pmuldoon at redhat.com Mon Feb 21 23:20:54 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Feb 2005 17:20:54 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050221230925.7a9fabf8@python2> References: <20050221230925.7a9fabf8@python2> Message-ID: <1109028054.5795.121.camel@dhcp-12.hsv.redhat.com> The eclipse packages are sub packages of a single source rpm, and that is the basic eclipse distribution. All the other eclipse packages are already going into Extras (C support/Bugzilla/Python Support and so on), and there is little room to make changes there. On Mon, 2005-02-21 at 23:09 +0100, Matthias Saou wrote: > Elliot Lee wrote : > > > Here's a heads up that we need to get rid of about 300M of packages to > > make sure that FC4 continues to fit on 4 CD's. > > For me, can go (into Extras) : > > - desktop-backgrounds-extra > - compat-gcc-8-3.3.4.2 > (if nothing in FC4 relies on it to be built anymore) > - tuxracer > (nothing new in ages, and not a really exciting game) > - abiword, gnumeric > (I use them a lot, but OOo is included) > > I'd definitely like to see xfce kept, as it's a nice light desktop manager > alternative. > Looking at Eclipse and other java related stuff... wow, it's huge, and > represents an amazing number of packages... I definitely don't know enough > about it to identify anything that could be considered optional, but if > part of it is, I'd definitely agree to have it go back into a specialized > location. > > Matthias > > -- > Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ > Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 > Load : 0.69 0.29 0.15 > From dwmw2 at infradead.org Mon Feb 21 23:22:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 21 Feb 2005 23:22:17 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109027509l.6648l.4l@devel.mpeters.us> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> Message-ID: <1109028137.26578.72.camel@localhost.localdomain> On Mon, 2005-02-21 at 23:11 +0000, Michael A. Peters wrote: > >> Perhaps we should teach anaconda about multiple repositories, and then >> both CD 5 and the Extras CDs can be optional parts of the install. >> And of course the DVD will have them all anyway. > >They should imho be a second DVD even if they would fit on a single. What's the point in that? If you want to force the user to _ask_ for them and not install them by default, OK -- but why actually put them on a separate DVD? -- dwmw2 From alan at redhat.com Mon Feb 21 23:23:57 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Feb 2005 18:23:57 -0500 Subject: Proposal for CD count in FC4 In-Reply-To: <1109027503.26578.70.camel@localhost.localdomain> References: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> <1109027503.26578.70.camel@localhost.localdomain> Message-ID: <20050221232357.GA3568@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 11:11:43PM +0000, David Woodhouse wrote: > I agree that we should do this for FC5 when anaconda can handle multiple > repositories. Ditto - even if it means pushing java off to extras / java repository and using them as the test victi^H^H^H^H^Hcase From cra at WPI.EDU Mon Feb 21 23:25:41 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 21 Feb 2005 18:25:41 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221231810.GI3827@redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> Message-ID: <20050221232541.GG5061@angus.ind.WPI.EDU> On Mon, Feb 21, 2005 at 06:18:10PM -0500, Dave Jones wrote: > > I hope the fortran part of gcc4 has caught up [to do everything > > gcc3-f77 does]. I guess I should go back and try gcc4 again. > > Which reminds me. Is fortran really used by enough people to justify > its presence in -core ? (Even if so, does it really need to be in the > default install?) I've never once in my life ever used fortran or needed it to compile/run anything. However, does it build from the same src.rpm? How would it be packaged in Extras if it does? From pmuldoon at redhat.com Mon Feb 21 23:26:36 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Feb 2005 17:26:36 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222508.GJ11759@devserv.devel.redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> Message-ID: <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> > The java stuff is new, its huge and its the easiest to push out for now Easiest in what metric? I guess the confusing thing here is if this really was a slim down of Fedora (IE AbiWord vs OpenOffice, and other arguments throughout the thread), then there would be plenty of room; there are lots of cross-over areas where duplication exists throughout core. It's difficult to rank one language, package, or set of tools over another, but for me, personally, a free java stack is of great importance. And that includes Eclipse which is integral to that area. Regards Phil > > > > Not only that but a java repository set has a natural focus and since > > > most of it is in java it can run asynchronously to the OS updates too > > > > Except for the natively-compiled stuff. Plus, I believe Sopwith said this > > kind of 3rd party repository isn't possible ATM. > > Then how are we proposing to do Fedora extras ? It is definitely possible. > A Java themed disk may be trickier as a part of base. > > If we can't do it then in my opinion its even more critical we keep the current > stuff and java should go into fedora extras or Fedora 5 when the tools are > fixed. > > I'd much rather see a Java yum repository and a non-install time java .iso > (which is easy to do as a standalone) > From eric at snowmoon.com Mon Feb 21 23:32:10 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 21 Feb 2005 18:32:10 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221142649.D21733@tiki-lounge.com> References: <20050221130721.B21733@tiki-lounge.com> <1109020521.24448.1.camel@opus.phy.duke.edu> <20050221142649.D21733@tiki-lounge.com> Message-ID: <421A6F7A.8040201@snowmoon.com> I think the point made here is quite important. Another package that could be droped from core is nss_db because it's been half broken since FC3 ( possibly before ) and is using at least 1mb of space needlessly. It has been statically linked against db4.0 thereby driving up the size of the binaries. Also, thrid party tools linked against db4.2 ( now default ) libraries are incompatible with nss_db because it is statically linked against 4.0. I submitted a patched .src.rpm file that corrects those problems so that not only are the libraries much smaller, but third party db generator tools work ( since they are generally statically linked ) and it has just sat there without any changes. So, please, move it to extras so that someone can maintain it. There may be dozens of packages like nss_db where the average person does not use it, it has been poorly maintined, and it get isntalled by default on all systems. Cheers, Eric Toshio Kuratomi wrote: >>No, That's the point - if fedora is going to work and going to have a >>constantly increasing number of packages then people OUTSIDE of red hat >>need to play ball. >> > > Well yeah. But that's neither here nor there. You're stating that Core is > defined as RedHat's contribution and Extras as The Community contribution to > the Fedora Project. But that's never been stated. > > I want that clarified because it's a very different thing to look at Core > and say I wouldn't mind having to download that separate from the Core CDs > versus I wouldn't mind maintaining that package or seeing it go to > /dev/null. > > This, of course, leads into the complementary question of whether RedHat > is willing to open up maintenance of Core packages to Community > contributers. > > So there's a different set of criteria for choosing packages and a different > set of helpful suggestions outside the scope of adding/removing packages > depending on what we're actually trying to limit (disk space or RedHat > maintenence burden.) > > >>if you don't know how to get on the team go here: >>http://fedoraproject.org/wiki/Extras/CvsAccess >> > > Yep. But fear of rejection has always kept me shy :-) > > -Toshio > -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From lists at donut.dk Mon Feb 21 23:36:01 2005 From: lists at donut.dk (Cream) Date: Tue, 22 Feb 2005 00:36:01 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <421A7061.6020406@donut.dk> what about moving aspell to extras? 150mb "saved" From jwz at jwz.org Mon Feb 21 23:36:42 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Mon, 21 Feb 2005 15:36:42 -0800 Subject: FC4 slimfast slimfest References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> Message-ID: <421A708A.3B9939A6@jwz.org> Phil Muldoon wrote: > > It's difficult to rank one language, package, or set of tools over > another, No, it's really not. Useful metrics include: - how many of the critical packages already depend on them; - how many widely-used packages are written in them. Regardless of your opinions of the merits of the Java language, it's just not heavily used by any of the things that desktop users bump into every day. (Except, *possibly*, web page applets, but I gather you're talking about a much bigger scope than that.) You may argue that it would be more heavily used if it was more widely available, but I don't think language advocacy is a good enough reason to make people download more stuff that they don't *yet* want or need. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From feliciano.matias at free.fr Mon Feb 21 23:48:55 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 22 Feb 2005 00:48:55 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <421A52E6.4070407@bluga.net> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <421A52E6.4070407@bluga.net> Message-ID: <1109029735.25890.2.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 14:30 -0700, Joshua Eichorn a ?crit : > So we should drop packages used by high % of fedora users for the doc > for tetex or exim which are used by a very small % users, and which are > also available online? > Move exim to extra. > And we should be held hostage in the future by any project that decides > that bundling there docs (no matter how big) with the program is a good > idea. > > I would also like to point out, the exim docs are a good example of > general space waste on docs packages, it contains html, pdf, ps, and > texinfo docs so the same content 4 times (so im guessing just with some > new configure flags could take 1/4 the space). Package only one format. -------------- 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 mpeters at mac.com Mon Feb 21 23:49:40 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 21 Feb 2005 23:49:40 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109028137.26578.72.camel@localhost.localdomain> (from dwmw2@infradead.org on Mon Feb 21 15:22:17 2005) References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> <1109028137.26578.72.camel@localhost.localdomain> Message-ID: <1109029780l.6648l.5l@devel.mpeters.us> On 02/21/2005 03:22:17 PM, David Woodhouse wrote: > On Mon, 2005-02-21 at 23:11 +0000, Michael A. Peters wrote: > > > >> Perhaps we should teach anaconda about multiple repositories, and > then > >> both CD 5 and the Extras CDs can be optional parts of the install. > > >> And of course the DVD will have them all anyway. > > > >They should imho be a second DVD even if they would fit on a single. > > What's the point in that? If you want to force the user to _ask_ for > them and not install them by default, OK -- but why actually put them > on > a separate DVD? I don't want to have to download all of extras just to get the convenience of a DVD install (no disk swapping) - especially since in a month or so, a good portion of those extras will have updates that would need to be individually downloaded anyway. Most of extras I don't use - I would rather download a smaller install iso and just yum install the extras that I do use. -- Michael A. Peters http://mpeters.us/ From feliciano.matias at free.fr Mon Feb 21 23:54:42 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 22 Feb 2005 00:54:42 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109024073.26578.49.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <1109024073.26578.49.camel@localhost.localdomain> Message-ID: <1109030082.25890.7.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 22:14 +0000, David Woodhouse a ?crit : > On Mon, 2005-02-21 at 22:19 +0100, F?liciano Matias wrote: > >Le lundi 21 f?vrier 2005 ? 13:54 -0700, Joshua Eichorn a ?crit : > >> How about dropping some of the random documentation rpms we keep around, > >> they don't follow a pattern anyway (ie we have exim-doc but no > >> postfix-doc, we have python-doc but no php-doc or perl-doc) > >> > > > >I am not agree. If we provide exim, we provide *all* exim. > > Exim has the best documentation ever I've seen for any Free Software > project; it'd be a shame to drop it. But then again, it's available on > the web too, and the HTML version is probably the most usable because of > the indexing etc. So we could reasonably drop it. So we could "reasonably" drop gcc, *-devel, ... Not a good idea. > > -- > dwmw2 > -------------- 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 pmuldoon at redhat.com Mon Feb 21 23:58:23 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Feb 2005 17:58:23 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <421A708A.3B9939A6@jwz.org> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> Message-ID: <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> > Regardless of your opinions of the merits of the Java language, it's > just not heavily used by any of the things that desktop users bump into > every day. (Except, *possibly*, web page applets, but I gather you're > talking about a much bigger scope than that.) One of the products we have in RHEL is Red Hat Developer Suite, which is based on java. We do active development on this, and we'd like to bring it to Fedora. There is a huge community of Eclipse users out there. Also, there is a large sphere of java usage out there. I'm not going to argue usage metrics, but suffice to say there is enough usage that warrants interest im(h)o. > You may argue that it would be more heavily used if it was more widely > available, but I don't think language advocacy is a good enough reason > to make people download more stuff that they don't *yet* want or need. I'm trying to avoid turning this into advocacy or philosophy of languages. But having a free java solution in hand, that could be put in Fedora, but we choose not to (and instead invite people to seek non open java solutions elsewhere) just sends a conflicting message. The open source java solution needs work. The open source Eclipse IDE needs work. These are already well established and populated projects. Regards Phil > > -- > Jamie Zawinski jwz at jwz.org http://www.jwz.org/ > jwz at dnalounge.com http://www.dnalounge.com/ > http://jwz.livejournal.com/ > From mricon at gmail.com Mon Feb 21 23:58:51 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 21 Feb 2005 18:58:51 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221231810.GI3827@redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> Message-ID: On Mon, 21 Feb 2005 18:18:10 -0500, Dave Jones wrote: > > I hope the fortran part of gcc4 has caught up [to do everything > > gcc3-f77 does]. I guess I should go back and try gcc4 again. > > Which reminds me. Is fortran really used by enough people to justify > its presence in -core ? (Even if so, does it really need to be in the > default install?) It's still used quite a bit in natural sciences (e.g. Physics, Chemistry, etc), but if it's moved to extras, nobody will miss it, since the admins will know where to find it. The question is -- can it be successfully unmarried from the rest of gcc? Regards, -- Konstantin Ryabitsev Zlotniks, INC From mricon at gmail.com Mon Feb 21 23:59:39 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 21 Feb 2005 18:59:39 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421A7061.6020406@donut.dk> References: <421A7061.6020406@donut.dk> Message-ID: On Tue, 22 Feb 2005 00:36:01 +0100, Cream wrote: > what about moving aspell to extras? 150mb "saved" I don't think removing the spellchecker is a good idea. :) -- Konstantin Ryabitsev Zlotniks, INC From feliciano.matias at free.fr Tue Feb 22 00:03:30 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 22 Feb 2005 01:03:30 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213044.GF31765@nostromo.devel.redhat.com> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> Message-ID: <1109030610.25890.13.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 16:30 -0500, Bill Nottingham a ?crit : > F?liciano Matias (feliciano.matias at free.fr) said: > > > You can view the list of new packages since FC3 (sorted by package size) > > > at http://people.redhat.com/sopwith/new-packages.txt > > > > Increase the CD size to 700 or 720 Mo ? > > This was tried around Red Hat Linux 8.0. More than 2 years ago. FC3 require at least a pentium class cpu, 64 Mo of ram, ... Hardware changes. > There were too many failures, > really. Mandrake use 700 Mo iso. > > Bill > -------------- 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 gemi at bluewin.ch Tue Feb 22 00:05:06 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 22 Feb 2005 01:05:06 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109029780l.6648l.5l@devel.mpeters.us> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> <1109028137.26578.72.camel@localhost.localdomain> <1109029780l.6648l.5l@devel.mpeters.us> Message-ID: <1109030706.27605.2.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-21 at 23:49 +0000, Michael A. Peters wrote: > I don't want to have to download all of extras just to get the > convenience of a DVD install (no disk swapping) - especially since in a > month or so, a good portion of those extras will have updates that > would need to be individually downloaded anyway. > > Most of extras I don't use - I would rather download a smaller install > iso and just yum install the extras that I do use. A problem is, that many people don't have fast internet connections, therefore relying solely on yum install from remote repositories for getting all the good stuff is not a good idea, IMHO. On the other hand if someone has downloaded a couple of CDs or DVDs it is lot easier to distribute it to those who cannot afford downloading large chunks. Agreed the problem of updates will still exist. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From davej at redhat.com Tue Feb 22 00:06:11 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 21 Feb 2005 19:06:11 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109030610.25890.13.camel@one.myworld> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <1109030610.25890.13.camel@one.myworld> Message-ID: <20050222000611.GJ3827@redhat.com> On Tue, Feb 22, 2005 at 01:03:30AM +0100, F?liciano Matias wrote: > Le lundi 21 f?vrier 2005 ? 16:30 -0500, Bill Nottingham a ?crit : > > F?liciano Matias (feliciano.matias at free.fr) said: > > > > You can view the list of new packages since FC3 (sorted by package size) > > > > at http://people.redhat.com/sopwith/new-packages.txt > > > > > > Increase the CD size to 700 or 720 Mo ? > > > > This was tried around Red Hat Linux 8.0. > > More than 2 years ago. FC3 require at least a pentium class cpu, 64 Mo > of ram, ... > Hardware changes. That doesn't necessarily mean it gets any better. We already get far too many bugs about media-check failures. Doing this is a recipe for disaster. > > There were too many failures, > > really. > Mandrake use 700 Mo iso. Mandrake also included half-baked patches that ate CD drives firmware at one point. Just because one distro does something doesn't mean its a good idea for everyone to do it. Dave From gemi at bluewin.ch Tue Feb 22 00:06:42 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 22 Feb 2005 01:06:42 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> Message-ID: <1109030802.27605.4.camel@scriabin.tannenrauch.ch> On Mon, 2005-02-21 at 18:58 -0500, Konstantin Ryabitsev wrote: > On Mon, 21 Feb 2005 18:18:10 -0500, Dave Jones wrote: > > > I hope the fortran part of gcc4 has caught up [to do everything > > > gcc3-f77 does]. I guess I should go back and try gcc4 again. > > > > Which reminds me. Is fortran really used by enough people to justify > > its presence in -core ? (Even if so, does it really need to be in the > > default install?) > > It's still used quite a bit in natural sciences (e.g. Physics, > Chemistry, etc), but if it's moved to extras, nobody will miss it, > since the admins will know where to find it. The question is -- can it > be successfully unmarried from the rest of gcc? Doesn't octave require it to build? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From cmadams at hiwaay.net Tue Feb 22 00:15:53 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Feb 2005 18:15:53 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109030706.27605.2.camel@scriabin.tannenrauch.ch> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> <1109028137.26578.72.camel@localhost.localdomain> <1109029780l.6648l.5l@devel.mpeters.us> <1109030706.27605.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050222001553.GA663812@hiwaay.net> Once upon a time, Grard Milmeister said: > A problem is, that many people don't have fast internet connections, > therefore relying solely on yum install from remote repositories for > getting all the good stuff is not a good idea, IMHO. On the other hand > if someone has downloaded a couple of CDs or DVDs it is lot easier to > distribute it to those who cannot afford downloading large chunks. Install-fests are another time that having media in hand is much more convenient (bandwidth may be slow or non-existant at such events). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at phy.duke.edu Tue Feb 22 00:37:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 19:37:22 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A7061.6020406@donut.dk> Message-ID: <1109032642.28235.1.camel@cutter> On Mon, 2005-02-21 at 18:59 -0500, Konstantin Ryabitsev wrote: >On Tue, 22 Feb 2005 00:36:01 +0100, Cream wrote: >> what about moving aspell to extras? 150mb "saved" > >I don't think removing the spellchecker is a good idea. :) > no but the lang packs for the spellchecker are separate srpms. So splitting off the non-major languages would be a savings. with no offense to those people in bulgaria the aspell-bg pkg is 30mb - maybe it could be somewhere else. -sv From jspaleta at gmail.com Tue Feb 22 00:35:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 21 Feb 2005 19:35:06 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221232541.GG5061@angus.ind.WPI.EDU> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> <20050221232541.GG5061@angus.ind.WPI.EDU> Message-ID: <604aa79105022116357968e6bc@mail.gmail.com> On Mon, 21 Feb 2005 18:25:41 -0500, Chuck R. Anderson wrote: > I've never once in my life ever used fortran or needed it to > compile/run anything. However, does it build from the same src.rpm? > How would it be packaged in Extras if it does? count yourself extremely lucky. Sadly its packaged as a sub-package of gcc srpm, so it cant be easily handed off over the Core/Extras barrier. And if the sub-package were simply not included the people who need it, like me, will end up rebuilding the gcc srpm to renable the gcc-f77 subpackage. -jef From dcbw at redhat.com Tue Feb 22 00:39:16 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 21 Feb 2005 19:39:16 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <20050221222036.GT18441@plain.rackshack.net> References: <20050221222036.GT18441@plain.rackshack.net> Message-ID: On Mon, 21 Feb 2005, Rudi Chiarito wrote: > Is OO.o ever going to drop the private Python tree it has always shipped > with? Yes, since there's now a libpython.so, we can drop the internal one. That should save around 8MB, IIRC. Dan From davej at redhat.com Tue Feb 22 00:39:23 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 21 Feb 2005 19:39:23 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <604aa79105022116357968e6bc@mail.gmail.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> <20050221232541.GG5061@angus.ind.WPI.EDU> <604aa79105022116357968e6bc@mail.gmail.com> Message-ID: <20050222003923.GL3827@redhat.com> On Mon, Feb 21, 2005 at 07:35:06PM -0500, Jeff Spaleta wrote: > On Mon, 21 Feb 2005 18:25:41 -0500, Chuck R. Anderson wrote: > > I've never once in my life ever used fortran or needed it to > > compile/run anything. However, does it build from the same src.rpm? > > How would it be packaged in Extras if it does? > > count yourself extremely lucky. Sadly its packaged as a sub-package > of gcc srpm, so it cant be easily handed off over the Core/Extras > barrier. And if the sub-package were simply not included the people > who need it, like me, will end up rebuilding the gcc srpm to renable > the gcc-f77 subpackage. That still doesn't justify it being always installed for every user by default IMO. Dave From jwz at jwz.org Tue Feb 22 00:52:14 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Mon, 21 Feb 2005 16:52:14 -0800 Subject: FC4 slimfast slimfest References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> Message-ID: <421A823E.5F30B8FB@jwz.org> Phil Muldoon wrote: > > I'm trying to avoid turning this into advocacy or philosophy of > languages. But having a free java solution in hand, that could be put in > Fedora, but we choose not to (and instead invite people to seek non open > java solutions elsewhere) just sends a conflicting message. The open > source java solution needs work. The open source Eclipse IDE needs work. > These are already well established and populated projects. There's a lot of space between "include it on the Fedora install CDs that absolutely everyone who uses Fedora must acquire" and invite people to use non-free solutions." For example, "put it on an optional Fedora Java CD." -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From mpeters at mac.com Tue Feb 22 00:53:58 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 22 Feb 2005 00:53:58 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109030706.27605.2.camel@scriabin.tannenrauch.ch> (from gemi@bluewin.ch on Mon Feb 21 16:05:06 2005) References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> <1109028137.26578.72.camel@localhost.localdomain> <1109029780l.6648l.5l@devel.mpeters.us> <1109030706.27605.2.camel@scriabin.tannenrauch.ch> Message-ID: <1109033638l.6648l.6l@devel.mpeters.us> On 02/21/2005 04:05:06 PM, G?rard Milmeister wrote: > > A problem is, that many people don't have fast internet connections, > therefore relying solely on yum install from remote repositories for > getting all the good stuff is not a good idea which is why you have a second DVD iso that has the extras - and not put them on the first. Those who want both at install time simply download and install two iso's. Of course - using something jigdo would be even better - as you could have one jigdo image for just core, that creates just a core iso, and second jigdo that creates a single dvd with core and extras. (and jigdo's to create the CD's as well - all mirrors would need are the packages and the jigdo files - works quite nicely for Debian) -- Michael A. Peters http://mpeters.us/ From mpeters at mac.com Tue Feb 22 00:55:11 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 22 Feb 2005 00:55:11 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050222001553.GA663812@hiwaay.net> (from cmadams@hiwaay.net on Mon Feb 21 16:15:53 2005) References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> <1109028137.26578.72.camel@localhost.localdomain> <1109029780l.6648l.5l@devel.mpeters.us> <1109030706.27605.2.camel@scriabin.tannenrauch.ch> <20050222001553.GA663812@hiwaay.net> Message-ID: <1109033711l.6648l.7l@devel.mpeters.us> On 02/21/2005 04:15:53 PM, Chris Adams wrote: > > Install-fests are another time that having media in hand is much more > convenient (bandwidth may be slow or non-existant at such events). Install-fests typicall have one or two boxes acting as ftp/nfs servers allowing boxes to install that way - needing nothing more than a small boot iso. -- Michael A. Peters http://mpeters.us/ From mrdocs at gmail.com Tue Feb 22 00:55:09 2005 From: mrdocs at gmail.com (P Linnell) Date: Tue, 22 Feb 2005 01:55:09 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213401.AA9EA7387D@hormel.redhat.com> References: <20050221213401.AA9EA7387D@hormel.redhat.com> Message-ID: <49e94b5105022116556669de41@mail.gmail.com> > Message: 6 > Date: Mon, 21 Feb 2005 16:10:15 -0500 (EST) > From: Dan Williams > Subject: Re: FC4 slimfast slimfest > To: Development discussions related to Fedora Core > > Message-ID: > > Is there any particular reason to keep 'gv'? How important is it to keep around > pure X11 versions of tools like this? There are gnome & KDE versions of > PostScript & PDF viewers that are much more capable, and far less ugly. > > Furthermore, I think it's time for 'ggv' and 'gpdf' to go as well, in favor of > Evince as the Single Gnome Document Viewer for PS/PDF files. Its going to > happen at some point anyway, might as well be now. > > Total savings from these three would be: > > 169938 gv-3.5.8-29.i386.rpm > 936623 ggv-2.8.3-1.i386.rpm > 775003 gpdf-2.9.3-1.i386.rpm > ---------------------------- > 1881564 > > Dan > > PS (I think xpdf has to stick around for now...) > No and correct. I've not used evince enough to comment. GSview is actually superior and already packaged, but wrt the others please make them go away. Here is why from the 1.2.2cvs docs for Scribus: "Two plus years of working with Scribus has led me to the current conclusion that the following three viewers are the most reliable at displaying PS/EPS/PDF created by Scribus: Acrobat Reader 5.0.8+ for Linux - GSview 4.6+ - with the latest version of Ghostscript available. Xpdf 3.00+ -..." KPDF in KDE 3.4 is also a major improvement. Peter From feliciano.matias at free.fr Tue Feb 22 00:55:43 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 22 Feb 2005 01:55:43 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050222000611.GJ3827@redhat.com> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <1109030610.25890.13.camel@one.myworld> <20050222000611.GJ3827@redhat.com> Message-ID: <1109033743.25890.18.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 19:06 -0500, Dave Jones a ?crit : > On Tue, Feb 22, 2005 at 01:03:30AM +0100, F?liciano Matias wrote: > > Mandrake use 700 Mo iso. > > Mandrake also included half-baked patches that ate CD drives > firmware at one point. And FC2 eat the mbr. That's not the point. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From davej at redhat.com Tue Feb 22 01:02:59 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 21 Feb 2005 20:02:59 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109033743.25890.18.camel@one.myworld> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <1109030610.25890.13.camel@one.myworld> <20050222000611.GJ3827@redhat.com> <1109033743.25890.18.camel@one.myworld> Message-ID: <20050222010259.GM3827@redhat.com> On Tue, Feb 22, 2005 at 01:55:43AM +0100, F?liciano Matias wrote: > Le lundi 21 f?vrier 2005 ? 19:06 -0500, Dave Jones a ?crit : > > On Tue, Feb 22, 2005 at 01:03:30AM +0100, F?liciano Matias wrote: > > > Mandrake use 700 Mo iso. > > > > Mandrake also included half-baked patches that ate CD drives > > firmware at one point. > > And FC2 eat the mbr. That's not the point. No, it isn't. You chose to delete my second sentence which contained my point, so I'll reiterate it. Just because one distro jumps off a cliff does not mean all others have to follow. When trying to come up with something that works on as many different combinations of crappy hardware and/or media as possible, being conservative is the only option. Dave From perbj at stanford.edu Tue Feb 22 01:05:03 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 21 Feb 2005 17:05:03 -0800 Subject: FC4 slimfast slimfest In-Reply-To: <49e94b5105022116556669de41@mail.gmail.com> References: <20050221213401.AA9EA7387D@hormel.redhat.com> <49e94b5105022116556669de41@mail.gmail.com> Message-ID: <1109034304.5319.44.camel@localhost.localdomain> On Tue, 2005-02-22 at 01:55 +0100, P Linnell wrote: > I've not used evince enough to comment. It's a definite step up from the others mentioned IMHO. > GSview is actually superior > and already packaged, but wrt the others please make them go away. Superior to the others, yes; superior to Evince - less definite I'd say. Also, GSview is AFPL-licensed isn't it? Is that license actually considered Fedora-compatible? http://www.cs.wisc.edu/~ghost/gsview/LICENCE We don't have AFPL Ghostscript... /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From pmuldoon at redhat.com Tue Feb 22 01:19:47 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Feb 2005 19:19:47 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <421A823E.5F30B8FB@jwz.org> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> <421A823E.5F30B8FB@jwz.org> Message-ID: <1109035188.6303.11.camel@unknown.local.lan> > There's a lot of space between "include it on the Fedora install CDs > that absolutely everyone who uses Fedora must acquire" and invite > people to use non-free solutions." For example, "put it on an > optional Fedora Java CD." You know in the long term, we agree. I absolutely believe Fedora should be slimmer (even to the point of one basic CD and everything else being optional). However, the argument that: "include it on the Fedora install CDs that absolutely everyone who uses Fedora must acquire" is sort of bogus when you cast your eyes over 4 CDs worth of Fedora Core software that everyone in going to acquire anyway, and that there is no room for Eclipse and the related open source Java stack there. In the future, I could see the Java CD option being a great option. But this exercise is getting FC4 down to a fixed size for the upcoming deadline. Right now the most compelling argument is that it is big, and therefore a good target to clip. There's no other metric being used, like usage in the community, or how active a project it is, or value to the open source community. There might be merit in the pure size argument; we all have to make hard decisions in the light of deadlines, but I'm trying to appeal to the notion that the size of the install is worth it, and bring valuation to other aspects of Eclipse. In the future, say FC5 and beyond there is much merit in the division of layers into separate CDs/Repos. Regards Phil From feliciano.matias at free.fr Tue Feb 22 01:28:36 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 22 Feb 2005 02:28:36 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050222010259.GM3827@redhat.com> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <1109030610.25890.13.camel@one.myworld> <20050222000611.GJ3827@redhat.com> <1109033743.25890.18.camel@one.myworld> <20050222010259.GM3827@redhat.com> Message-ID: <1109035716.25890.28.camel@one.myworld> Le lundi 21 f?vrier 2005 ? 20:02 -0500, Dave Jones a ?crit : > On Tue, Feb 22, 2005 at 01:55:43AM +0100, F?liciano Matias wrote: > > Le lundi 21 f?vrier 2005 ? 19:06 -0500, Dave Jones a ?crit : > > > On Tue, Feb 22, 2005 at 01:03:30AM +0100, F?liciano Matias wrote: > > > > Mandrake use 700 Mo iso. > > > > > > Mandrake also included half-baked patches that ate CD drives > > > firmware at one point. > > > > And FC2 eat the mbr. That's not the point. > > No, it isn't. You chose to delete my second sentence I don't reply to the second sentence. Any problems ? > which > contained my point, so I'll reiterate it. > Just because one distro jumps off a cliff does not mean all others have to follow. > I don't say Fedora have to follow Mandrake. I just give a proposition. It seems you want to wait all other distros to switch to more than +650 Mo to do a new try (last one is for RH8.0). So, wait and see (I hope other distros don't follow your reasoning). > When trying to come up with something that works on as many > different combinations of crappy hardware and/or media as > possible, being conservative is the only option. > > Dave > -------------- 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 rc040203 at freenet.de Tue Feb 22 01:39:05 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 22 Feb 2005 02:39:05 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109030706.27605.2.camel@scriabin.tannenrauch.ch> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <1109023925.26578.46.camel@localhost.localdomain> <1109027509l.6648l.4l@devel.mpeters.us> <1109028137.26578.72.camel@localhost.localdomain> <1109029780l.6648l.5l@devel.mpeters.us> <1109030706.27605.2.camel@scriabin.tannenrauch.ch> Message-ID: <1109036346.15184.391.camel@mccallum.corsepiu.local> On Tue, 2005-02-22 at 01:05 +0100, G?rard Milmeister wrote: > On Mon, 2005-02-21 at 23:49 +0000, Michael A. Peters wrote: > > > I don't want to have to download all of extras just to get the > > convenience of a DVD install (no disk swapping) - especially since in a > > month or so, a good portion of those extras will have updates that > > would need to be individually downloaded anyway. > > > > Most of extras I don't use - I would rather download a smaller install > > iso and just yum install the extras that I do use. > > A problem is, that many people don't have fast internet connections, > therefore relying solely on yum install from remote repositories for > getting all the good stuff is not a good idea, IMHO. Yes, but .. why do you think I am permanently nagging Seth to finally implement a --download-only option into yum. I think, the problem is yum, not "internet connections". > On the other hand > if someone has downloaded a couple of CDs or DVDs it is lot easier to > distribute it to those who cannot afford downloading large chunks. Pardon? When using yum/apt to install on a single-seat/home-desktop you actually spare a lot of downloads, in comparison to downloading CDs, because using yum/apt you'll only download a subset of all available packages, in contrast to using CDs, which means to download everything. > Agreed the problem of updates will still exist. I don't see this as a problem. Using the "download on demand strategy" as I outlined above, I actually fail to see the need for having more CDs than a "minimalistic bootstrap/installer CD" for "users on a small bandwidth connection". Ralf From fedora at wir-sind-cool.org Tue Feb 22 01:41:04 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 22 Feb 2005 02:41:04 +0100 Subject: extras cvs sponsoring (was: Re: FC4 slimfast slimfest) In-Reply-To: <1109025652.24220.0.camel@shuttle.273piedmont.org> References: <20050221130721.B21733@tiki-lounge.com> <1109020521.24448.1.camel@opus.phy.duke.edu> <20050221142649.D21733@tiki-lounge.com> <1109025652.24220.0.camel@shuttle.273piedmont.org> Message-ID: <20050222024104.14b3a240.fedora@wir-sind-cool.org> On Mon, 21 Feb 2005 17:40:52 -0500, Brian Pepple wrote: > On Mon, 2005-02-21 at 14:26 -0800, Toshio Kuratomi wrote: > > > if you don't know how to get on the team go here: > > > http://fedoraproject.org/wiki/Extras/CvsAccess > > > > > Yep. But fear of rejection has always kept me shy :-) > > > > -Toshio > > > Same here. > > /B I agree with the suggestion which has been made on fedora-extras-list. Submit clean ready-to-ship updates (i.e. diffs against CVS, or complete src.rpms) which can be imported into CVS without the QA overhead as known from fedora.us. Then more developers (e.g. via extras-commits-list) will see your changes and can build an opinion. For packagers, who've met me in fedora.us QA queue, I'm willing to serve as proxy to CVS. Before we see how this sponsoring works out in practice, I'm somewhat conservative with whom to sponsor immediately. And I think the CVS accounts maintenance thing is not ready yet either. Private mail or a bugzilla ticket with proper CC should do (bugs.michael AT gmx.net is my address in bugzilla). From rc040203 at freenet.de Tue Feb 22 01:40:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 22 Feb 2005 02:40:50 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109032642.28235.1.camel@cutter> References: <421A7061.6020406@donut.dk> <1109032642.28235.1.camel@cutter> Message-ID: <1109036451.15184.394.camel@mccallum.corsepiu.local> On Mon, 2005-02-21 at 19:37 -0500, seth vidal wrote: > On Mon, 2005-02-21 at 18:59 -0500, Konstantin Ryabitsev wrote: > >On Tue, 22 Feb 2005 00:36:01 +0100, Cream wrote: > >> what about moving aspell to extras? 150mb "saved" > > > >I don't think removing the spellchecker is a good idea. :) > > > > no but the lang packs for the spellchecker are separate srpms. So > splitting off the non-major languages would be a savings. People will read this as "the typical US" arrogance, ignorance and nationalism. Ralf From aoliva at redhat.com Tue Feb 22 01:46:45 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Feb 2005 22:46:45 -0300 Subject: FC4 slimfast slimfest In-Reply-To: <20050221225037.GA398@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> Message-ID: On Feb 21, 2005, Bill Nottingham wrote: > Chris Adams (cmadams at hiwaay.net) said: >> That's also why I think there should be ISOs of Fedora Extras available. >> Maybe not for FC4 (if pushing something significant from FC3 to FE4 can >> be avoided), but down the road. > Having ISOs doesn't solve this at install/upgrade time, without the > support in the installer. Then we're about to make the big mistake of introducing extras before being able to make it *feel* like part of the distribution. Think of it this way: would you push OOo to extras? Why not? If so, why insist on pushing other very, perhaps even more useful pieces of software there, before they have be regarded as actually part of the distro, not as second-class citizens? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From pbrobinson at gmail.com Tue Feb 22 01:47:23 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 22 Feb 2005 09:47:23 +0800 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221523.GG11759@devserv.devel.redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> Message-ID: <5256d0b05022117475f4013f6@mail.gmail.com> > On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote: > > If Eclipse goes then so does all of the Java stuff since Eclipse is our > > bytecode compiler. > > Suits me fine. > > Java can all live in a java repository. There is a vast amount of it and we > don't have room. Not only that but a java repository set has a natural focus > and since most of it is in java it can run asynchronously to the OS updates too Is there any way to put all the java stuff on it own on cd 5 and call it 'CD 5 - Java' with a comment in the release notes saying 'if you don't want or need Java related bits you don't need to download CD5' With fear of beating a dead horse - all the Gnome 1 stuff (excluding gtk1/xmms - not going to start that flame again :-) comes to around 20Mb. And by moving it to extras might encourage gnucash to bring on the gtk2 release. And afterall we are lead to believe that extras isn't second grade. Also the original mozilla is around 16 meg as well and with 3 other browsers (firefox, epiphany and the kde konkeror (sp?) do we need it. Also is there a valid reason for have 3 versions of gcc, 5 versions of automake and 2 versions of autoconf? Peter Pete From aoliva at redhat.com Tue Feb 22 01:52:24 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Feb 2005 22:52:24 -0300 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A7061.6020406@donut.dk> Message-ID: On Feb 21, 2005, Konstantin Ryabitsev wrote: > On Tue, 22 Feb 2005 00:36:01 +0100, Cream wrote: >> what about moving aspell to extras? 150mb "saved" > I don't think removing the spellchecker is a good idea. :) why nto? hwo neeeds aspel cheker anway? :)- -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mricon at gmail.com Tue Feb 22 01:53:24 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 21 Feb 2005 20:53:24 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109036451.15184.394.camel@mccallum.corsepiu.local> References: <421A7061.6020406@donut.dk> <1109032642.28235.1.camel@cutter> <1109036451.15184.394.camel@mccallum.corsepiu.local> Message-ID: On Tue, 22 Feb 2005 02:40:50 +0100, Ralf Corsepius wrote: > > no but the lang packs for the spellchecker are separate srpms. So > > splitting off the non-major languages would be a savings. > > People will read this as "the typical US" arrogance, ignorance and > nationalism. Well, tell them that the Russian agrees with the American. They can blame the Russians for a change. It seems increasingly popular these days anyway. :) Most countries have their own local distros that commonly re-roll Fedora to reflect their regional needs, so I don't think making spellcheck dictionaries for minor languages a download-only thing for vanilla Fedora is a bad idea (let's say minor == fewer than a hundred million speakers). Regards, -- Konstantin Ryabitsev Zlotniks, INC From ed at eh3.com Tue Feb 22 02:08:45 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 21 Feb 2005 21:08:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <604aa79105022116357968e6bc@mail.gmail.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> <20050221232541.GG5061@angus.ind.WPI.EDU> <604aa79105022116357968e6bc@mail.gmail.com> Message-ID: <1109038125.30620.138.camel@localhost.localdomain> On Mon, 2005-02-21 at 19:35 -0500, Jeff Spaleta wrote: > On Mon, 21 Feb 2005 18:25:41 -0500, Chuck R. Anderson wrote: > > I've never once in my life ever used fortran or needed it to > > compile/run anything. However, does it build from the same src.rpm? > > How would it be packaged in Extras if it does? > > count yourself extremely lucky. Sadly its packaged as a sub-package > of gcc srpm, so it cant be easily handed off over the Core/Extras > barrier. And if the sub-package were simply not included the people > who need it, like me, will end up rebuilding the gcc srpm to renable > the gcc-f77 subpackage. *Please* keep the gcc-g77 package (or the gcc4 equivalent) in the default Fedora Core install. Its small. And there are many scientists and researchers "out there" who are neither particularly skilled programmers nor experienced admins. And they rely on gcc-g77 being easily available. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From cmadams at hiwaay.net Tue Feb 22 02:11:00 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Feb 2005 20:11:00 -0600 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> Message-ID: <20050222021100.GB663812@hiwaay.net> Once upon a time, Alexandre Oliva said: > Think of it this way: would you push OOo to extras? Why not? If so, > why insist on pushing other very, perhaps even more useful pieces of > software there, before they have be regarded as actually part of the > distro, not as second-class citizens? How many Fedora users will use OOo vs. how many will use Java development tools? The main use most users have for Java is applets, and Fedora doesn't have anything for applets yet (you still have to use Sun's JRE which can't be included in Fedora). I think you are overestimating the importance of Java to the average user. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rjune at bravegnuworld.com Tue Feb 22 02:13:41 2005 From: rjune at bravegnuworld.com (Richard June) Date: Mon, 21 Feb 2005 21:13:41 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221314.GF11759@devserv.devel.redhat.com> References: <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> Message-ID: <200502212113.45405.rjune@bravegnuworld.com> On Monday 21 February 2005 17:13, Alan Cox wrote: > On Mon, Feb 21, 2005 at 10:19:48PM +0100, F?liciano Matias wrote: > > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > > > I am not agree. If we provide exim, we provide *all* exim. > > Shove exim in extras then. Lets have one of everything (including > databases) in the base except where the are real divides (Gnome/KDE) As a KDE user, I say shove KDE into extras. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Feb 22 02:14:39 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 22 Feb 2005 03:14:39 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A7061.6020406@donut.dk> <1109032642.28235.1.camel@cutter> <1109036451.15184.394.camel@mccallum.corsepiu.local> Message-ID: <1109038479.15184.409.camel@mccallum.corsepiu.local> On Mon, 2005-02-21 at 20:53 -0500, Konstantin Ryabitsev wrote: > On Tue, 22 Feb 2005 02:40:50 +0100, Ralf Corsepius wrote: > > > no but the lang packs for the spellchecker are separate srpms. So > > > splitting off the non-major languages would be a savings. > > > > People will read this as "the typical US" arrogance, ignorance and > > nationalism. > > Well, tell them that the Russian agrees with the American. They can > blame the Russians for a change. It seems increasingly popular these > days anyway. :) I realize, to have entered dangerous political grounds ... IMO, if you remove one language you must remove all and make all languages optional (Including English) and reduce Fedora Core to "C". > Most countries have their own local distros that commonly re-roll > Fedora to reflect their regional needs, so I don't think making > spellcheck dictionaries for minor languages a download-only thing for > vanilla Fedora is a bad idea (let's say minor == fewer than a hundred > million speakers). 100 mill. speaker? This would exclude large groups and major languages. You should be aware that i18n for "less spread" languages makes distributions attractive to "niches". Ralf From mricon at gmail.com Tue Feb 22 02:17:56 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 21 Feb 2005 21:17:56 -0500 Subject: Wubi for iiimf Message-ID: Hello, all: The topic of Wubi input for iiimf has been discussed previously about a year ago, but at that time, from what I understood by perusing archives, there were licensing issues. Is there any movement on this front since then? Gimlet has greatly improved between FC2 and FC3, but Chinese input is still limited to Cangjie (Traditional, very obscure for novices), or Pinyin, which is tied to the Northern Mandarin dialect. While Pinyin is great for newbies like me, it also ulimately hurtsss usss, because of its ties to one dialect and because it's impossible to type in unfamiliar characters -- must know how it's pronounced, which is more often than not... difficult... to divine from the character itself. The Wubi input method solves the latter problem, and is increasingly popular for Hanzi/Kanji input. I understand it's part of SCIM, but it's unclear to me how SCIM ties to IIIMF. Can anyone shed some light on the status of Wubi input in Fedora? Cheers, -- Konstantin Ryabitsev Zlotniks, INC From pmuldoon at redhat.com Tue Feb 22 02:27:48 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 21 Feb 2005 20:27:48 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050222021100.GB663812@hiwaay.net> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> Message-ID: <1109039269.6303.39.camel@unknown.local.lan> On Mon, 2005-02-21 at 20:11 -0600, Chris Adams wrote: > Once upon a time, Alexandre Oliva said: > > Think of it this way: would you push OOo to extras? Why not? If so, > > why insist on pushing other very, perhaps even more useful pieces of > > software there, before they have be regarded as actually part of the > > distro, not as second-class citizens? > > How many Fedora users will use OOo vs. how many will use Java > development tools? The main use most users have for Java is applets, > and Fedora doesn't have anything for applets yet (you still have to use > Sun's JRE which can't be included in Fedora). I must respectfully disagree. You can reduce any package set to a negligible corner case usage, but often I think the reality is different. We need Java in some form to run Eclipse, which is an (open source) IDE. Until now there has been no viable open source Java stack available to support Eclipse (it requires a very decent implementation). Now there is. The way that Eclipse is written is just one example of Java applications that aren't the infamous applet example. Regardless of whether you like Java, or Eclipse, there is a lot of open source work going on with both. The Eclipse community is huge and thriving community (eclipse.org), that has coverage for many, many languages and environments (including C/C++/Python/Perl et al). Several other distributions (like Debian, Gentoo etc) already have it integrated into their systems. > I think you are overestimating the importance of Java to the average > user. Which raises an interesting point. We are on tricky ground when we try to define the median user of Fedora. More developers than user level consumers? More academic than commercial? Who knows. We could have a community just thirsting for Java ;) Regards Phil From dan_young at parkrose.k12.or.us Tue Feb 22 02:30:31 2005 From: dan_young at parkrose.k12.or.us (Dan Young) Date: Mon, 21 Feb 2005 18:30:31 -0800 Subject: FC4 slimfast slimfest In-Reply-To: <200502212113.45405.rjune@bravegnuworld.com> References: <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <200502212113.45405.rjune@bravegnuworld.com> Message-ID: <1109039431.31964.1.camel@localhost.localdomain> On Mon, 2005-02-21 at 21:13 -0500, Richard June wrote: > On Monday 21 February 2005 17:13, Alan Cox wrote: > > On Mon, Feb 21, 2005 at 10:19:48PM +0100, F?liciano Matias wrote: > > > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > > > > > I am not agree. If we provide exim, we provide *all* exim. > > > > Shove exim in extras then. Lets have one of everything (including > > databases) in the base except where the are real divides (Gnome/KDE) > As a KDE user, I say shove KDE into extras. What about kdeedu weighing in at 23M and having it's own SRPM? -- Dan Young Parkrose School District From balay at fastmail.fm Tue Feb 22 03:03:02 2005 From: balay at fastmail.fm (Satish Balay) Date: Mon, 21 Feb 2005 21:03:02 -0600 (CST) Subject: FC4 slimfast slimfest In-Reply-To: <20050222003923.GL3827@redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> <20050221232541.GG5061@angus.ind.WPI.EDU> <604aa79105022116357968e6bc@mail.gmail.com> <20050222003923.GL3827@redhat.com> Message-ID: On Mon, 21 Feb 2005, Dave Jones wrote: > On Mon, Feb 21, 2005 at 07:35:06PM -0500, Jeff Spaleta wrote: > > On Mon, 21 Feb 2005 18:25:41 -0500, Chuck R. Anderson wrote: > > > I've never once in my life ever used fortran or needed it to > > > compile/run anything. However, does it build from the same src.rpm? > > > How would it be packaged in Extras if it does? > > > > count yourself extremely lucky. Sadly its packaged as a sub-package > > of gcc srpm, so it cant be easily handed off over the Core/Extras > > barrier. And if the sub-package were simply not included the people > > who need it, like me, will end up rebuilding the gcc srpm to renable > > the gcc-f77 subpackage. > > That still doesn't justify it being always installed for every user > by default IMO. Every user doesn't get g77 by default. It is part of 'Development Tools' group. Satish From djotaku1282 at yahoo.com Tue Feb 22 03:03:20 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Mon, 21 Feb 2005 19:03:20 -0800 (PST) Subject: cd count Message-ID: <20050222030320.30486.qmail@web50801.mail.yahoo.com> Wow, 7 digests were spawned from today's back and forth on this topic. About two digests from the latest ones people made the following suggestion and I wanted to ditto: At the rate I've noticed, from finish of FCX to finish of FCX+1 is about 8 months. (Give or take a month) So why not let FC4 be 5 CDs. When FC5 comes out at the end of the year, we will have anaconda installing from repos anyway, and we can trim down all the way to 1 or 2 CDs. Perhaps I'm the atypical user, but going through all of the packages in yum and trying to figure out what to install from the "extras" is a lot more of a hassle than downloading another iso. Just leave it going over night...does anyone pay by the hour anymore? (And don't use AOL cuz it may kick you off) Finally, about FC3 not being in magazines...that is a false statement. Linux Format Magazine recently included FC3 in the DVD edition of their magazine. So while the issue of trimming down Fedora may be moot after this distro (with the anaconda fix/update/hack), I don't think having just 300mb (not even half a 700mb cd) extra is a big deal. I think that's been lost over all of these emails - it's not really an extra CD it's an extra half-cd. So one wait's 1.5 times as long as they do now, no biggie. I really think it would save a lot of hassle. Vote with me 5 CDs in FC4 and 2 CDs in FC5 __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From smooge at gmail.com Tue Feb 22 03:06:33 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 21 Feb 2005 20:06:33 -0700 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <80d7e40905022119065b922cda@mail.gmail.com> On Mon, 21 Feb 2005 15:35:34 -0500 (EST), Elliot Lee wrote: > Hi all, > > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. We also may > try to start removing stuff from Core in hopes that it will appear in > Extras if someone cares about it. > I will try to take over cfengine and xfce if they are to be dropped. I need them more than I need the distro. -- Stephen J Smoogen. CSIRT/Linux System Administrator From mpeters at mac.com Tue Feb 22 03:09:53 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 22 Feb 2005 03:09:53 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050222021100.GB663812@hiwaay.net> (from cmadams@hiwaay.net on Mon Feb 21 18:11:00 2005) References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> Message-ID: <1109041793l.10858l.0l@devel.mpeters.us> On 02/21/2005 06:11:00 PM, Chris Adams wrote: > > I think you are overestimating the importance of Java to the average > user. I also would prefer JPackage handle Java. Here's why - JPackage is very good at making things available on many distributions. I've already sent e-mails to several developers of Java apps suggesting they package their product in an rpm with the dependencies satisfied by what is in JPackage, so that Linux users can simply add the JPackage repository, and then yum localinstall the rpm - and whatever is needed will just be grabbed. Some developers e-mailed me saying they had not heard of JPackage but they liked what they saw. In many cases this work for several distributions with just a single rpm from the vendor, but if Fedora deviates from JPackage, then install instructions for Fedora would have to be different than instructions for other distro's. I'm not a Java developer, I honestly don't like GUI Java apps in most cases (it's the interface - not pretty) though I do like a few because they are very good at what they do. As far as packaging Java, JPackage is very good at what it does - I have never before had such an easy time getting Java applications to just work. I would rather see support (and I do see it) of RH and Fedora for the JPackage project, and let JPackage handle everything Java. Maybe ship a JVM but not until it can do applets. Ship with a jpackage.org repo file installed that a user just needs to enable to use. -- Michael A. Peters http://mpeters.us/ From skvidal at phy.duke.edu Tue Feb 22 03:28:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 22:28:40 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109036451.15184.394.camel@mccallum.corsepiu.local> References: <421A7061.6020406@donut.dk> <1109032642.28235.1.camel@cutter> <1109036451.15184.394.camel@mccallum.corsepiu.local> Message-ID: <1109042920.28235.13.camel@cutter> >People will read this as "the typical US" arrogance, ignorance and >nationalism. > *yawn* - you got me - I was suggesting moving lesser-used language packs to extras as a secret move toward american hegemeony. yep. that's it. and you'll never stop me! You'll never foil my plans!!!! *eye roll* -sv From hp at redhat.com Tue Feb 22 03:31:23 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 21 Feb 2005 22:31:23 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <1109043083.29658.5.camel@localhost.localdomain> Hi, Can I suggest two possible approaches... 1) we aren't willing to remove anything that was in FC3 due to the upgrade problem, so we basically have to remove the stuff that's new since FC3; just do that 2) maybe we are willing to consider removing anything, if so I propose this approach: - create "profiles" of complete sets of packages that some common audiences would want; avoid duplicate-functionality/ indecision as much as possible in those - try to include/exclude complete profiles for example, a complete "corporate desktop", "mail server", "print server", "file server", "sysadmin workstation", "C programming environment", "java programming environment", etc. dump entire use cases like that; and dump multiple ways to do a single use case. Rationale: it's stupid to include half of a use case, since you are already causing that person to go to Extras, you may as well send them there for everything. Havoc From alex at darkhonor.com Tue Feb 22 03:42:26 2005 From: alex at darkhonor.com (Alex Ackerman) Date: Mon, 21 Feb 2005 22:42:26 -0500 Subject: FC4 slimfast slimfest Message-ID: > From: Michael A. Peters > Sent: Monday, February 21, 2005 10:10 PM > To: fedora-devel-list at redhat.com > Subject: Re: FC4 slimfast slimfest > > > On 02/21/2005 06:11:00 PM, Chris Adams wrote: > > > > > I think you are overestimating the importance of Java to the average > > user. > > I also would prefer JPackage handle Java. > Here's why - JPackage is very good at making things available on many > distributions. I've already sent e-mails to several developers of Java > apps suggesting they package their product in an rpm with the > dependencies satisfied by what is in JPackage, so that Linux users can > simply add the JPackage repository, and then yum localinstall the rpm - > and whatever is needed will just be grabbed. Some developers e-mailed > me saying they had not heard of JPackage but they liked what they saw. > In many cases this work for several distributions with just a single > rpm from the vendor, but if Fedora deviates from JPackage, then install > instructions for Fedora would have to be different than instructions > for other distro's. > > I'm not a Java developer, I honestly don't like GUI Java apps in most > cases (it's the interface - not pretty) though I do like a few because > they are very good at what they do. > > As far as packaging Java, JPackage is very good at what it does - I > have never before had such an easy time getting Java applications to > just work. > > I would rather see support (and I do see it) of RH and Fedora for the > JPackage project, and let JPackage handle everything Java. Maybe ship a > JVM but not until it can do applets. > > Ship with a jpackage.org repo file installed that a user just needs to > enable to use. > > -- > Michael A. Peters > http://mpeters.us/ +1. The added bonus for this option is that the maintenance of the packages themselves is left to the community rather than to an already overworked Redhat staff which is maintaining 2 distros (FC and RHEL). Alex Ackerman From rjune at bravegnuworld.com Tue Feb 22 03:53:26 2005 From: rjune at bravegnuworld.com (Richard June) Date: Mon, 21 Feb 2005 22:53:26 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109039431.31964.1.camel@localhost.localdomain> References: <200502212113.45405.rjune@bravegnuworld.com> <1109039431.31964.1.camel@localhost.localdomain> Message-ID: <200502212253.29756.rjune@bravegnuworld.com> [snip] > > As a KDE user, I say shove KDE into extras. > > What about kdeedu weighing in at 23M and having it's own SRPM? > > -- > Dan Young > Parkrose School District core, n : a central and often foundational part usually distinct from the enveloping part by a difference in nature. Fedora core should be just that, *core* ideally I would like to see it down to one or two CDs push dev stuff extras, push docs to extras push all the alternatives to extras. why? because quite frankly that's what core is. so by all means push all the alternative stuff to core. *but* also make it easy to add stuff from extras. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ghenriks at rogers.com Tue Feb 22 03:58:34 2005 From: ghenriks at rogers.com (Gerald Henriksen) Date: Mon, 21 Feb 2005 22:58:34 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421A708A.3B9939A6@jwz.org> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> Message-ID: <9g6l11p7ue9pcmk7nb65fjqq2v592ies5f@4ax.com> On Mon, 21 Feb 2005 15:36:42 -0800, you wrote: >Phil Muldoon wrote: >> >> It's difficult to rank one language, package, or set of tools over >> another, > >No, it's really not. Useful metrics include: > > - how many of the critical packages already depend on them; > - how many widely-used packages are written in them. None of which requires that the languages themselves need to be included. >Regardless of your opinions of the merits of the Java language, it's >just not heavily used by any of the things that desktop users bump into >every day. (Except, *possibly*, web page applets, but I gather you're >talking about a much bigger scope than that.) And how many desktop users bump into or need gcc? Apache? Sendmail? Fedora, like almost any of the Linux distributions is aimed at several different audiences. If one of those target audiences is developers then Java is a valid thing to include. Otherwise remove all the compilers and just leave in the required runtimes. >You may argue that it would be more heavily used if it was more widely >available, but I don't think language advocacy is a good enough reason >to make people download more stuff that they don't *yet* want or need. There are a lot of people who need Java, whether it be students at school or working developers or anyone else who is interested. Perhaps most importantly though is that Novell is pushing Mono (C#) and Red Hat is pushing Java. If Red Hat doesn't even include Java in Fedora then that compromises the Red Hat message. Is this advocacy? Yes. But sometimes you just can't avoid it. Gerald From webmaster at margo.bijoux.nom.br Tue Feb 22 04:00:55 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Tue, 22 Feb 2005 01:00:55 -0300 Subject: FC4 slimfast slimfest In-Reply-To: <1109024238.26578.52.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> Message-ID: <421AAE77.5080704@margo.bijoux.nom.br> David Woodhouse wrote: >On Mon, 2005-02-21 at 17:13 -0500, Alan Cox wrote: > > >>Shove exim in extras then. Lets have one of everything (including databases) >>in the base except where the are real divides (Gnome/KDE) >> >> > >I'd rather put sendmail and/or postfix in Extras instead. There's a >reason Debian has the default it does. > > I dont want to make this a sendmail/postfix/exim/other email server war, but I think that is a little too much... Just because one distribution ships exim/koffice/put your favourite app here as default , it doesnt necessarily mean that's the right choice for all distributions. IMHO , Fedora should ship only one mail server/one app (maybe chosen by % of users?) in the main CDs. My suggestion: in FC4 , ship only one server of each type (no alternatives) and put them on an alternatives repository (after all, most users that require something different already know how to use yum or apt). Then , for the next Fedora releases , it would be interesting if anaconda was hacked to be able to use extra cds. This way , it would be possible to use an "alternatives" cd during install , for example. As for the space spent on mirrors , we could always use jigdo ;) -- Pedro Macedo From fedora-devel at tlarson.com Tue Feb 22 04:01:29 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Mon, 21 Feb 2005 21:01:29 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <1109043083.29658.5.camel@localhost.localdomain> References: <1109043083.29658.5.camel@localhost.localdomain> Message-ID: <421AAE99.8030705@tlarson.com> Havoc Pennington wrote: > [...] > 2) maybe we are willing to consider removing anything, > if so I propose this approach: > > - create "profiles" of complete sets of packages that some > common audiences would want; avoid duplicate-functionality/ > indecision as much as possible in those > > - try to include/exclude complete profiles > > for example, a complete "corporate desktop", > "mail server", "print server", "file server", "sysadmin > workstation", "C programming environment", > "java programming environment", etc. > > dump entire use cases like that; and dump multiple ways > to do a single use case. > > Rationale: it's stupid to include half of a use case, since > you are already causing that person to go to Extras, you > may as well send them there for everything. > > Havoc > Brilliant idea. Solves all our problems, but creates a set of new one. Like, for example, what will the ISOs look like? From skvidal at phy.duke.edu Tue Feb 22 04:06:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 23:06:02 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421AAE77.5080704@margo.bijoux.nom.br> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> Message-ID: <1109045162.28235.32.camel@cutter> >IMHO , Fedora should ship only one mail server/one app (maybe chosen by >% of users?) in the main CDs. >My suggestion: in FC4 , ship only one server of each type (no >alternatives) and put them on an alternatives repository (after all, >most users that require something different >already know how to use yum or apt). Then , for the next Fedora releases >, it would be interesting if anaconda was hacked to be able to use extra >cds. This way , it would be possible >to use an "alternatives" cd during install , for example. > anaconda using multiple repos is in the plans for fc5. -sv From reuben-fedora-devel at reub.net Tue Feb 22 04:29:23 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Tue, 22 Feb 2005 17:29:23 +1300 Subject: FC4 slimfast slimfest In-Reply-To: <421AAE99.8030705@tlarson.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> Message-ID: <421AB523.4060906@reub.net> Hi, Tyler Larson wrote: > Havoc Pennington wrote: > >> [...] >> 2) maybe we are willing to consider removing anything, >> if so I propose this approach: >> - create "profiles" of complete sets of packages that some >> common audiences would want; avoid duplicate-functionality/ >> indecision as much as possible in those >> >> - try to include/exclude complete profiles >> >> for example, a complete "corporate desktop", >> "mail server", "print server", "file server", "sysadmin >> workstation", "C programming environment", "java programming >> environment", etc. >> >> dump entire use cases like that; and dump multiple ways to do a >> single use case. >> >> Rationale: it's stupid to include half of a use case, since >> you are already causing that person to go to Extras, you >> may as well send them there for everything. >> >> Havoc >> > > > Brilliant idea. Solves all our problems, but creates a set of new one. > > Like, for example, what will the ISOs look like? Well, the most obvious way is to just use the 'profiles' guidelines which are currently used for the installation - I imagine Havoc had this in mind with his suggestion. The distribution is clearly already partially divided up in the sense that when installing, one is asked to choose between package groups like 'network server', 'workstation' etc preselected with roughly the right RPM's. Seems to me that the logical way this should be split is: * 1 core/common CD which contains things like glibc, kernel, initscripts and basic system stuff that everyone requires, enough to get a machine up to runlevel 3 awaiting a login, with some basic stuff such as network connectivity, python ready to go etc If someone had loads of bandwidth from that point on they could even pull down whatever they wanted over the network and install it. * 1 desktop CD that has KDE/Gnome + + OpenOffice + X stuff eg games (enough for the casual or home user to do what they want). For those who love their spell checker, that can go here too ;) * 1 server CD which contains servers and development applications (probably where more packages of interest in RHEL live) The future possibility of a packager shipping their own CD as #4 with their own custom apps then looks quite easy, literally a 'bolt on' CD that follows on from the core/common #1 CD. The flexibility is there at this stage such that what won't fit on each CD should be pushed to extras online, and on the other hand, if there is spare space, possibly content from extras online could be pre-loaded into an 'extras' directory on the CD to fill it up. Given the number of mails from this list today, I think that the suggestion of trimming packages to make space was very definitely done on Monday morning at the start of the week ;) I imagine there was some faint hope of a consensus of sorts being reached by Friday............... reuben From webmaster at margo.bijoux.nom.br Tue Feb 22 04:40:33 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Tue, 22 Feb 2005 01:40:33 -0300 Subject: cd count In-Reply-To: <20050222030320.30486.qmail@web50801.mail.yahoo.com> References: <20050222030320.30486.qmail@web50801.mail.yahoo.com> Message-ID: <421AB7C1.9090704@margo.bijoux.nom.br> The DJ wrote: >Wow, 7 digests were spawned from today's back and >forth on this topic. About two digests from the >latest ones people made the following suggestion and I >wanted to ditto: > >At the rate I've noticed, from finish of FCX to finish >of FCX+1 is about 8 months. (Give or take a month) >So why not let FC4 be 5 CDs. When FC5 comes out at >the end of the year, we will have anaconda installing >from repos anyway, and we can trim down all the way to >1 or 2 CDs. > > I like this idea. However , knowing (and living) in Brazil and having an idea of how the distribution of high speed (or even cheap) internet connections around 3rd world countries is, I'd vote for this choice only if there was a way (specially a simple one) for someone with enough bandwidth to download all the packages from those extra repositories and create a set of CDs/DVDs that can install the whole distribution without the need of extra downloads afterwards (except for updates). After all , that's what happens around here... Someone downloads the distribution and burns the isos for the friends/coworkers/LUG members who need them (or in some cases, people buy the CDs online from stores like cheapbytes , since the dialup costs for downloading a whole distribution like fedora are almost three times the price of the CDs + shipping)... -- Pedro Macedo From wtogami at redhat.com Tue Feb 22 07:02:18 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 21 Feb 2005 21:02:18 -1000 Subject: Wubi for iiimf In-Reply-To: References: Message-ID: <421AD8FA.9080509@redhat.com> Konstantin Ryabitsev wrote: > > The Wubi input method solves the latter problem, and is increasingly > popular for Hanzi/Kanji input. I understand it's part of SCIM, but > it's unclear to me how SCIM ties to IIIMF. Can anyone shed some light > on the status of Wubi input in Fedora? > > Cheers, I personally don't know anything about wubi, but I heard from RH's i18n engineering that the data needed for wubi is not open source, so we are stuck there for now. Warren Togami wtogami at redhat.com From yaneti at declera.com Tue Feb 22 08:00:26 2005 From: yaneti at declera.com (Yanko Kaneti) Date: Tue, 22 Feb 2005 10:00:26 +0200 Subject: FC4 slimfast slimfest In-Reply-To: <1109032642.28235.1.camel@cutter> References: <421A7061.6020406@donut.dk> <1109032642.28235.1.camel@cutter> Message-ID: <1109059226.16429.38.camel@indigo.declera.com> On Mon, 2005-02-21 at 19:37 -0500, seth vidal wrote: >On Mon, 2005-02-21 at 18:59 -0500, Konstantin Ryabitsev wrote: >>On Tue, 22 Feb 2005 00:36:01 +0100, Cream wrote: >>> what about moving aspell to extras? 150mb "saved" >> >>I don't think removing the spellchecker is a good idea. :) >> > >no but the lang packs for the spellchecker are separate srpms. So >splitting off the non-major languages would be a savings. > >with no offense to those people in bulgaria the aspell-bg pkg is 30mb - >maybe it could be somewhere else. aspell-bg is currently (FC3+updates and rawhide) unusable, see #142238 Redoing it in the manner proposed in the bug-report shaves half the size. Fix seems to be held back by lack of rh manpower. Cheers Yanko From nick.thorley at btinternet.com Tue Feb 22 09:26:02 2005 From: nick.thorley at btinternet.com (Nick Thorley) Date: Tue, 22 Feb 2005 09:26:02 +0000 Subject: fedora-devel-list Digest, Vol 12, Issue 56 In-Reply-To: <20050221220947.78A5773323@hormel.redhat.com> References: <20050221220947.78A5773323@hormel.redhat.com> Message-ID: <421AFAAA.8060902@btinternet.com> fedora-devel-list-request at redhat.com wrote: >Send fedora-devel-list mailing list submissions to > fedora-devel-list at redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.redhat.com/mailman/listinfo/fedora-devel-list >or, via email, send a message with subject or body 'help' to > fedora-devel-list-request at redhat.com > >You can reach the person managing the list at > fedora-devel-list-owner at redhat.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of fedora-devel-list digest..." > > >Today's Topics: > > 1. Re: FC4 slimfast slimfest (Eric Warnke) > 2. Re: FC4 slimfast slimfest (Jesse Keating) > 3. Re: FC4 slimfast slimfest (Elliot Lee) > 4. Re: FC4 slimfast slimfest (Ronny Buchmann) > 5. Re: FC4 slimfast slimfest (Phil Muldoon) > 6. Re: FC4 slimfast slimfest (Andrew Overholt) > 7. Re: FC4 slimfast slimfest (Ronny Buchmann) > 8. Re: FC4 slimfast slimfest (seth vidal) > 9. Re: FC4 slimfast slimfest (Mail Lists) > 10. Re: FC4 slimfast slimfest (Alexandre Oliva) > 11. Re: FC4 slimfast slimfest (Alexandre Oliva) > 12. Re: FC4 slimfast slimfest (Bill Nottingham) > 13. Re: FC4 slimfast slimfest (Bill Nottingham) > 14. Re: FC4 slimfast slimfest (Bill Nottingham) > 15. Proposal for CD count in FC4 (Jesse Keating) > 16. Re: FC4 slimfast slimfest (Alexandre Oliva) > 17. Re: FC4 slimfast slimfest (Alan Cox) > 18. Re: FC4 slimfast slimfest (Chris Adams) > 19. Re: FC4 slimfast slimfest (Matthias Saou) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 21 Feb 2005 16:34:45 -0500 >From: Eric Warnke >Subject: Re: FC4 slimfast slimfest >To: Development discussions related to Fedora Core > >Message-ID: <421A53F5.2060302 at snowmoon.com> >Content-Type: text/plain; charset="iso-8859-1" > > >I know this will be an unpopular suggestion, but 300MB is a lot to >loose. So I'm just throwing this out there..... > >KDE by my estimates is 350mb, move it into extras. > >Cheers, > >Elliot Lee wrote: > > >>Hi all, >> >>Here's a heads up that we need to get rid of about 300M of packages to >>make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, >> >> > > > I agree that a cd two install would be good and have packages available from online. However I think there does need to be an option for a full cd set download. I do many installs that are on machines with no internet connection and also do jobs onsite where there is only a dialup option. Many people I speak to say that they would have tried suse except for the need to download packages from an ftp server on install has stopped this as the install was a nightmare. If the number of cd's is getting too much - why not refer onto dvd installs as most machines these days have them and this would then reduce the amount of disks to two and provide the cd download for people who required it. Please feel free to comment. From rodd at clarkson.id.au Tue Feb 22 10:19:03 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 22 Feb 2005 21:19:03 +1100 Subject: FC4 slimfast slimfest In-Reply-To: <1109027231l.6648l.3l@devel.mpeters.us> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109027231l.6648l.3l@devel.mpeters.us> Message-ID: <1109067544.4022.3.camel@goose> On Mon, 2005-02-21 at 23:07 +0000, Michael A. Peters wrote: >Yes - that is why Abiword, Gnumeric, Balsa should be in extras - even >though I personally prefer them to OO.o and Evolution, the vast >majority of users never install them - but go with OO.o and Evolution, >so until that changes, it does not need to be downloaded by the users. As someone who uses Gnumeric I say toss it into extras. In fact toss it, abiword, balsa and koffice into extras. Why? Well, as far as I am aware, these packages aren't installed by default anyway. You have to manually add them (either at install, or after the fact). If this is the case, then assuming extras is made easy to access, installing them later should be easy enough. So dump them in extras and those that want them can get them there. Rodd From esr at thyrsus.com Tue Feb 22 11:15:40 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 22 Feb 2005 06:15:40 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222102323.54203.qmail@web8507.mail.in.yahoo.com> References: <20050221221116.GB31916@thyrsus.com> <20050222102323.54203.qmail@web8507.mail.in.yahoo.com> Message-ID: <20050222111540.GA6409@thyrsus.com> Rahul Sundaram : > can you make your explanation available online in the > FUDcon page please and that applies rest of the > people who made presentations but didnt provide them > online too I presume you're talking about a wiki somewhere. Care to give an URL? -- Eric S. Raymond From alan at redhat.com Tue Feb 22 11:20:21 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 22 Feb 2005 06:20:21 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421AAE99.8030705@tlarson.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> Message-ID: <20050222112021.GA28474@devserv.devel.redhat.com> On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote: > Brilliant idea. Solves all our problems, but creates a set of new one. > Like, for example, what will the ISOs look like? CD #1 Download only this CD for a base install and use yum to add packages CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs via CD/DVD Java CD Optional Download for java packages Games CD Optional Download for extra games etc.. From dwmw2 at infradead.org Tue Feb 22 11:21:13 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 11:21:13 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <5256d0b05022117475f4013f6@mail.gmail.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <5256d0b05022117475f4013f6@mail.gmail.com> Message-ID: <1109071273.26578.89.camel@localhost.localdomain> On Tue, 2005-02-22 at 09:47 +0800, Peter Robinson wrote: >Is there any way to put all the java stuff on it own on cd 5 and call >it 'CD 5 - Java' with a comment in the release notes saying 'if you >don't want or need Java related bits you don't need to download CD5' As I understand it, this will be possible in FC5 when Extras can be supported similarly. I think we should wait for FC5 before undertaking the task of slimming i386 down to 4 CDs. The PPC and x86_64 releases are going to be 5CDs anyway. -- dwmw2 From malists at epon.ro Tue Feb 22 11:38:56 2005 From: malists at epon.ro (Marius Andreiana) Date: Tue, 22 Feb 2005 13:38:56 +0200 Subject: gnome-office, koffice (was Re: FC4 slimfast slimfest) In-Reply-To: <1109019724l.6648l.2l@devel.mpeters.us> References: <1109019724l.6648l.2l@devel.mpeters.us> Message-ID: <1109072337.3337.16.camel@venus.epon.ro> On Mon, 2005-02-21 at 21:02 +0000, Michael A. Peters wrote: > I would take a look at the alternatives that aren't planned to be > pushed - like AbiWord, Gnumeric, Balsa yes, and koffice too. These could be maintained in extras by people who still use them, but the default OOo is quite good. abiword, gnumeric and koffice aren't even installed by default when you check Office Productivity category, -- Marius Andreiana Epon Business Applications http://www.epon.ro From esr at thyrsus.com Tue Feb 22 12:45:35 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 22 Feb 2005 07:45:35 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222111751.47093.qmail@web8501.mail.in.yahoo.com> References: <20050222111540.GA6409@thyrsus.com> <20050222111751.47093.qmail@web8501.mail.in.yahoo.com> Message-ID: <20050222124535.GA25562@thyrsus.com> Rahul Sundaram : > > --- "Eric S. Raymond" wrote: > > > Rahul Sundaram : > > > can you make your explanation available online in > > the > > > FUDcon page please and that applies rest of the > > > people who made presentations but didnt provide > > them > > > online too > > > > I presume you're talking about a wiki somewhere. > > Care to give an URL? > > not sure about the wiki part but here > > http://fedoraproject.org/fudcon/ How do you suggest I go about making my explanation available? -- Eric S. Raymond From jspaleta at gmail.com Tue Feb 22 13:20:54 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 08:20:54 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <200502212253.29756.rjune@bravegnuworld.com> References: <200502212113.45405.rjune@bravegnuworld.com> <1109039431.31964.1.camel@localhost.localdomain> <200502212253.29756.rjune@bravegnuworld.com> Message-ID: <604aa7910502220520523763b1@mail.gmail.com> On Mon, 21 Feb 2005 22:53:26 -0500, Richard June wrote: > core, n : a central and often foundational part usually distinct from the > enveloping part by a difference in nature. > How about we don't get caught up the text book imagery of the word 'core' . I can do you one better and quote the textbook definition of the word 'fedora'.. and then cry about how fedora core isn't actually the central and often foundational part of a man's wide brimmed HAT. 'Core' like 'Fedora' is just a silly name. Instead of a dictionary, i refer you instead to the objective list spelled out so far for the project: Objectives of Fedora Core: 1. Create a COMPLETE general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community ? those who not only consume, but also produce for the good of other community members -jef From ph18 at cornell.edu Tue Feb 22 13:27:49 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 22 Feb 2005 08:27:49 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421A52E6.4070407@bluga.net> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <421A52E6.4070407@bluga.net> Message-ID: On Mon, 21 Feb 2005 14:30:14 -0700, Joshua Eichorn wrote: > > I would also like to point out, the exim docs are a good example of > general space waste on docs packages, it contains html, pdf, ps, and > texinfo docs so the same content 4 times (so im guessing just with some > new configure flags could take 1/4 the space). > -josh > The thing I hate most about modern *nix is the proliferation of different documation formats. In the good old days we had man pages. Then Sun came along and introduced it's own system that was graphical and all but was really worse than man pages. Then there's info and docbook and programs that have HTML documentation and PDF documentation, and... This nonsense caused about ten minutes of extra downtime for a production system when I did something dumb that overwrote the module utilities: the 2.6 module utilities source doesn't just have man page source in it, but it compiles the pages out of docbook source. Well, this is RHEL 3 and you wouldn't expect it to have packages that work, so to get "make install" to work I had to smash the Makefile so it wouldn't try to compile them. From ph18 at cornell.edu Tue Feb 22 13:34:46 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 22 Feb 2005 08:34:46 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221211934.GD31765@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> Message-ID: On Mon, 21 Feb 2005 16:19:34 -0500, Bill Nottingham wrote: > > - non-IIIMF input methods - they are now obsolete for a few releases Input methods are a big annoyance to people who don't use them; when we installed RH 9 on my sister-in-law's computer, her first complaint was that it "took too long to boot." I went in and cleaned up the boot sequence and found that a number of different input methods that I'd never heard of wasted many seconds at boot time. > - mozilla (classic) - superseded by firefox, thunderbird, epiphany, etc I have no idea why the world has embraced firefox after rejecting mozilla. Perhaps there's a hidden way to do it, but I've had much better luck configuring the pop-up blocker in mozilla... The are lots of little features in mozilla I find myself missing in firefox. On the other hand, RH always seems to ship a Mozilla that's hopelessly out of date so I usually end up installing my own in /usr/local and rpm --erasing the one that came with the OS. (Funny enough, I do that for all of the software that I actually care about.) From ph18 at cornell.edu Tue Feb 22 13:38:15 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 22 Feb 2005 08:38:15 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221230925.7a9fabf8@python2> References: <20050221230925.7a9fabf8@python2> Message-ID: On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou wrote: > - tuxracer > (nothing new in ages, and not a really exciting game) This is my toddler's favorite game. It's the best way to put him to sleep. > - abiword, gnumeric > (I use them a lot, but OOo is included) > So far as I'm concerned, all the "office" packages can go. I've found that 90% compatibility with MS Office isn't enough to work with the groups I work with and just wind up running the real thing under crossover. From rdieter at math.unl.edu Tue Feb 22 13:57:15 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Feb 2005 07:57:15 -0600 Subject: kde-3.4 (3.3.92) in fc4 Message-ID: <421B3A3B.1070100@math.unl.edu> I know it's getting close, but I think it's important to try to get kde-3.4 (3.3.92beta2 at the moment) into fc4. If not, fedora users will have to wait for fc5 before seeing this (please correct me if I'm wrong). -- Rex From fedora-devel at camperquake.de Tue Feb 22 13:56:27 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 22 Feb 2005 14:56:27 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109071273.26578.89.camel@localhost.localdomain>; from dwmw2@infradead.org on Tue, Feb 22, 2005 at 11:21:13AM +0000 References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <5256d0b05022117475f4013f6@mail.gmail.com> <1109071273.26578.89.camel@localhost.localdomain> Message-ID: <20050222145627.A1035@kushana.camperquake.de> On Tue, Feb 22, 2005 at 11:21:13AM +0000, David Woodhouse wrote: > As I understand it, this will be possible in FC5 when Extras can be > supported similarly. I think we should wait for FC5 before undertaking > the task of slimming i386 down to 4 CDs. The PPC and x86_64 releases are > going to be 5CDs anyway. Unless I am very much mistaken, this is possible right now. If you put all the Java stuff on CD 5 (for example), and do not select any of it in the anaconda, then anaconda will not request the fifth CD, so you do not need it. In a similar way, I'd put all the development stuff on a seperate CD, too (*-devel, gcc), so you'd be able to skip downloading that if you know that you'd want a non-developer desktop, anyway. And yes, I personally consider a Unix without a compiler crippled. But I do not mind downloading that extra CD, either. But for the people I give FC to (my girlfriend, my parents...) the devel part is just wasted space. From fedora at wir-sind-cool.org Tue Feb 22 14:07:53 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 22 Feb 2005 15:07:53 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050222124535.GA25562@thyrsus.com> References: <20050222111540.GA6409@thyrsus.com> <20050222111751.47093.qmail@web8501.mail.in.yahoo.com> <20050222124535.GA25562@thyrsus.com> Message-ID: <20050222150753.37f985c5.fedora@wir-sind-cool.org> On Tue, 22 Feb 2005 07:45:35 -0500, Eric S. Raymond wrote: > > > Rahul Sundaram wrote: > > > > can you make your explanation available online in > > > the > > > > FUDcon page please and that applies rest of the > > > > people who made presentations but didnt provide > > > them > > > > online too > > > > > > I presume you're talking about a wiki somewhere. > > > Care to give an URL? > > > > not sure about the wiki part but here > > > > http://fedoraproject.org/fudcon/ > > How do you suggest I go about making my explanation available? For modifications of the FUDCon website, mail your links or documents to either Seth Vidal Colin Charles The old Wiki planning-page is at http://fedoraproject.org/wiki/FUDCon1 but there's no point anymore in editing it or in getting Wiki edit access just for that old page. From jspaleta at gmail.com Tue Feb 22 14:11:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 09:11:24 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222145627.A1035@kushana.camperquake.de> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <5256d0b05022117475f4013f6@mail.gmail.com> <1109071273.26578.89.camel@localhost.localdomain> <20050222145627.A1035@kushana.camperquake.de> Message-ID: <604aa7910502220611706747d0@mail.gmail.com> On Tue, 22 Feb 2005 14:56:27 +0100, Ralf Ertzinger > Unless I am very much mistaken, this is possible right now. If you put all > the Java stuff on CD 5 (for example), and do not select any of it in the > anaconda, then anaconda will not request the fifth CD, so you do not need > it. In a similar way, I'd put all the development stuff on a seperate CD, > too (*-devel, gcc), so you'd be able to skip downloading that if you know > that you'd want a non-developer desktop, anyway. Careful, you have to consider the problems of space packing. Moving -devel off onto its own cd and java on its own cd.. etc..etc.. might actually end up with 6+ partially full cds. Once you start grouping things into cds based function there's no garuntee you'll be able to pack them as efficiently into the same number of isos. I'm not saying this is a bad idea... im just saying that using this approach to drill down to an 1 cd installable desktop.. might end up costing you 7 or 8 partially full cd iso images in the end if the requirement to ship all of Core on isos remains. -jef From laroche at redhat.com Tue Feb 22 14:15:41 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 22 Feb 2005 15:15:41 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050221221314.GF11759@devserv.devel.redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> Message-ID: <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> On Mon, Feb 21, 2005 at 05:13:14PM -0500, Alan Cox wrote: > On Mon, Feb 21, 2005 at 10:19:48PM +0100, F?liciano Matias wrote: > > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > > > > I am not agree. If we provide exim, we provide *all* exim. > > Shove exim in extras then. Lets have one of everything (including databases) > in the base except where the are real divides (Gnome/KDE) I think exim still has potential to become our future default MTA. greetings, Florian La Roche From dwmw2 at infradead.org Tue Feb 22 14:16:29 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 14:16:29 +0000 Subject: FC for ia64? In-Reply-To: <200502021441.58659.jbarnes@engr.sgi.com> References: <200502021441.58659.jbarnes@engr.sgi.com> Message-ID: <1109081789.26578.121.camel@localhost.localdomain> On Wed, 2005-02-02 at 14:41 -0800, Jesse Barnes wrote: >What would it take to make ia64 support in Fedora bit more official? I.e. >part of core releases, part of the Extras build process, etc. I might be >interested in taking it on if it's not something huge... > >FWIW, I've been using it pretty regularly on an Altix 350 I have here and it's >working pretty well for the most part (at least as well as it does on my >PowerBook). There's no magic bullet but here's what was done for PPC, which seems to be having the desired effect. - Take snapshots of rawhide at the time of a Fedora Core release, put them up for download so that people don't need to be on rawhide. - Create a tracker bug like the Fedora/PPC one (121179), and make sure stuff in it gets fixed. Make sure the install works and new hardware is well supported. - Create a mailing list and try to get people involved. - Build updated kernel packages if necessary, and feed fixes upstream so that they get into the rawhide kernels. - Find packages which aren't built on your architecture and work out why. Fix the problems and persuade the package maintainer to include your arch in future. - Get someone to push the FC4 updates which are built internally to a publicly-accessible yum repository. - Build Extras and Livna packages for your architecture too. - Make sure qemu works, so those who need i386 binaries can run them. Of course, it's easier for architectures like PPC and IA64 which are already present in the internal Red Hat build system and hence in rawhide -- for Alpha and SPARC it'll be more work because the whole distro needs to be built, and there may well be GCC work needed. -- dwmw2 From fedora-devel at camperquake.de Tue Feb 22 14:24:26 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 22 Feb 2005 15:24:26 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <604aa7910502220611706747d0@mail.gmail.com>; from jspaleta@gmail.com on Tue, Feb 22, 2005 at 09:11:24AM -0500 References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <5256d0b05022117475f4013f6@mail.gmail.com> <1109071273.26578.89.camel@localhost.localdomain> <20050222145627.A1035@kushana.camperquake.de> <604aa7910502220611706747d0@mail.gmail.com> Message-ID: <20050222152426.A6391@ryoko.camperquake.de> On Tue, Feb 22, 2005 at 09:11:24AM -0500, Jeff Spaleta wrote: > Careful, you have to consider the problems of space packing. Yes, of course. I just wanted to point put that anaconda is right now capable of installing a system without requiring all of the CDs. From harald at redhat.com Tue Feb 22 14:30:41 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 22 Feb 2005 15:30:41 +0100 Subject: udev + usb2 kernel race? In-Reply-To: <1108684064.4328.10.camel@galvatron.localdomain> References: <1108684064.4328.10.camel@galvatron.localdomain> Message-ID: <421B4211.9010600@redhat.com> Sitsofe Wheeler wrote: > Hi, > > We have a computer acting as a server that locks hard (PS2 keyboard > stops responding, prompt never returns, boot gets no further) when USB2 > is enabled on FC3 (there were no lockups with FC1). I finally traced > this down to being some sort of interaction between udev and USB2. The > following steps reproduce the problem: > > Boot the kernel with init=/bin/sh > mount -n -t proc /proc /proc > mount -n -t sysfs /sys /sys > /sbin/start_udev > /sbin/modprobe uhci-hcd > > The machine will hang and not get any further nor will it respond to a > ctrl-alt-del or sysrq commands. > > modprobing uhci-hcd before starting udev causes the problem to disappear > as does disabling USB2 (but leaving USB1 on) in the BIOS. Kernels tested > are kernel-2.6.9-1.667 and kernel-2.6.10-1.766_FC3. lspci prints the > following USB controller: > 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 > Controller (rev 16) > > Does this sound like a known issue? > not to me and the solution is strange... could you add a set -x after the first line of start_udev and look, where it hangs? From mattdm at mattdm.org Tue Feb 22 14:34:37 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 22 Feb 2005 09:34:37 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221231810.GI3827@redhat.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> Message-ID: <20050222143437.GA14648@jadzia.bu.edu> On Mon, Feb 21, 2005 at 06:18:10PM -0500, Dave Jones wrote: > Which reminds me. Is fortran really used by enough people to justify > its presence in -core ? (Even if so, does it really need to be in the > default install?) I know people use it here. But moving it to extras makes sense to me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tiemann at redhat.com Tue Feb 22 14:35:45 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Tue, 22 Feb 2005 09:35:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222112021.GA28474@devserv.devel.redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> Message-ID: <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> On Tue, 2005-02-22 at 06:20, Alan Cox wrote: > On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote: > > Brilliant idea. Solves all our problems, but creates a set of new one. > > Like, for example, what will the ISOs look like? > > CD #1 Download only this CD for a base install and use yum to add packages ...with optional Live installer > CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs > via CD/DVD > > Java CD Optional Download for java packages > Games CD Optional Download for extra games > > etc.. +10 M From than at redhat.com Tue Feb 22 14:42:00 2005 From: than at redhat.com (Than Ngo) Date: Tue, 22 Feb 2005 15:42:00 +0100 Subject: kde-3.4 (3.3.92) in fc4 In-Reply-To: <421B3A3B.1070100@math.unl.edu> References: <421B3A3B.1070100@math.unl.edu> Message-ID: <421B44B8.4070603@redhat.com> Rex Dieter wrote: > I know it's getting close, but I think it's important to try to get > kde-3.4 (3.3.92beta2 at the moment) into fc4. If not, fedora users > will have to wait for fc5 before seeing this (please correct me if I'm > wrong). > > -- Rex > i'm still waiting for KDE-3.4 RC1, which will be released on Feb 22. Than ** From dpaun at rogers.com Tue Feb 22 14:57:11 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Tue, 22 Feb 2005 09:57:11 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> Message-ID: <20050222145711.GA25805@rogers.com> On Tue, Feb 22, 2005 at 09:35:45AM -0500, Michael Tiemann wrote: > > CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs > > via CD/DVD > > > > Java CD Optional Download for java packages > > Games CD Optional Download for extra games > > > > etc.. > > +10 Agreed. Even though we may end up with a few more CDs this way (as some may end up partially full), we get some room to grow so we don't have to go through such painful reorganziation every FCx. And you get the huge advantage that you would know apriori what CDs you need: no need to download, burn, verify the images you don't care about. I think it would end up saving time for many folks. -- Dimi. From rjune at bravegnuworld.com Tue Feb 22 14:59:33 2005 From: rjune at bravegnuworld.com (Richard June) Date: Tue, 22 Feb 2005 09:59:33 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221230925.7a9fabf8@python2> Message-ID: <200502220959.38111.rjune@bravegnuworld.com> On Tuesday 22 February 2005 08:38, Paul A. Houle wrote: > On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou > > > wrote: > > - tuxracer > > (nothing new in ages, and not a really exciting game) > > This is my toddler's favorite game. It's the best way to put him to > sleep. I agree, this is a great game to have in core. it's not huge, but it is a lot of fun. > > - abiword, gnumeric > > (I use them a lot, but OOo is included) > > So far as I'm concerned, all the "office" packages can go. I've > found that 90% compatibility with MS Office isn't enough to work with the > groups I work with and just wind up running the real thing under crossover. I would disagree with you here. for the groups I work with 90% is great, not only that, some have wound up moving to OO.o on windows as well. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From balay at fastmail.fm Tue Feb 22 15:05:20 2005 From: balay at fastmail.fm (Satish Balay) Date: Tue, 22 Feb 2005 09:05:20 -0600 (CST) Subject: FC4 slimfast slimfest In-Reply-To: <604aa79105022116357968e6bc@mail.gmail.com> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> <20050221232541.GG5061@angus.ind.WPI.EDU> <604aa79105022116357968e6bc@mail.gmail.com> Message-ID: On Mon, 21 Feb 2005, Jeff Spaleta wrote: > Sadly its packaged as a sub-package of gcc srpm, so it cant be > easily handed off over the Core/Extras barrier. And if the > sub-package were simply not included the people who need it, like > me, will end up rebuilding the gcc srpm to renable the gcc-f77 > subpackage. To chime in a bit more into this g77 issue - gcc-g77 acts as both: provides:g77[compiler], libf2c-devel[libraries] If a user[/developer] needs to compile a piece of scientific c++ code which uses a fancy c++ foobar package - which inturn offloads some work to fortran libraries like 'blas' - then the following depencency exists [even though this user never has to compile any F77 code] user-code -> foobar-package -> blas [aka devel] -> libf2c-devel i.e needs gcc-g77 package to be installed. Also - making it difficult to get g77 makes fedora difficult for cluster computing [where codes of the above type are pretty common] Satish From jspaleta at gmail.com Tue Feb 22 15:10:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 10:10:44 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> Message-ID: <604aa79105022207102e24a420@mail.gmail.com> On Tue, 22 Feb 2005 09:35:45 -0500, Michael Tiemann wrote: > +10 Yes i agree, doing things that way would end up meaning +10 partially full isos. This approach snowballs very quickly: office cd desktop-art cd games cd kde cd java cd devel cd emacs cd perl cd All of them optional for a basic fedora install... whatever that means. Now, this approach definitely is a benifit to fresh installers who do targetted installs, and people who are networked with hi-band and can do network installs. But I'm not so sure how an explosion of partially full isos works out for people doing non-networked upgrades or people with low-band who are forced to buy or manufacture mediasets. Those 'optional' disks look highly less optional once you start doing upgrades.. and each extra partially full iso increases the overhead of producing full mediasets for sale or give away. Oh and there has to be a 'clever' way for 'fedora' to tell people which 'optional' cds they are going to want to burn before they burn them. And clever does not mean a flat package list with associated cd #/cd name next to it on the fedora website. Anyone doing an upgrade via mediasets will want to know before they start downloading which 'optional' disks they will continue to need to do the full upgrade. -jef From hk at isphuset.no Tue Feb 22 15:14:26 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 22 Feb 2005 16:14:26 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <604aa79105022207102e24a420@mail.gmail.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> Message-ID: <1109085265.12204.1.camel@linux.local> On Tue, 2005-02-22 at 16:10, Jeff Spaleta wrote: > On Tue, 22 Feb 2005 09:35:45 -0500, Michael Tiemann wrote: > > +10 > > Yes i agree, doing things that way would end up meaning +10 partially > full isos. This approach snowballs very quickly: > office cd > desktop-art cd > games cd > kde cd > java cd > devel cd > emacs cd > perl cd Partial isos could be joined together. Java + devel + emacs on one cd for example games + kde + office on one? -HK From jspaleta at gmail.com Tue Feb 22 15:18:10 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 10:18:10 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222145711.GA25805@rogers.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> <20050222145711.GA25805@rogers.com> Message-ID: <604aa7910502220718421e63f1@mail.gmail.com> On Tue, 22 Feb 2005 09:57:11 -0500, Dimitrie O. Paun wrote: > And you get the huge > advantage that you would know apriori what CDs you need: no need to > download, burn, verify the images you don't care about. I think it would > end up saving time for many folks. i highly doubt that.... for upgrades... its going to be a HUGE time suck trying to avoid downloading optional cds. Sure you might install fc6 just using the cds you need.. .but then you used yum and installed a game or two... and a little java.. and then a few -devel packages because you wanted to compile something up from srpm. 3 months later.... yer ready to install fc7.. have fun writing the comparative scripts to figure out which 'optional' cds you now need to download. Unless some in-distro tools are created to help work it out for you.. its going to be a huge frelling mess for a large class of users who want to upgrade from release to release. -jef From dcbw at redhat.com Tue Feb 22 15:21:05 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 22 Feb 2005 10:21:05 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <200502220959.38111.rjune@bravegnuworld.com> References: <20050221230925.7a9fabf8@python2> <200502220959.38111.rjune@bravegnuworld.com> Message-ID: <1109085665.341.1.camel@dcbw.boston.redhat.com> On Tue, 2005-02-22 at 09:59 -0500, Richard June wrote: > On Tuesday 22 February 2005 08:38, Paul A. Houle wrote: > > On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou > > > > So far as I'm concerned, all the "office" packages can go. I've > > found that 90% compatibility with MS Office isn't enough to work with the > > groups I work with and just wind up running the real thing under crossover. > I would disagree with you here. for the groups I work with 90% is great, not > only that, some have wound up moving to OO.o on windows as well. For 2.0 a bunch of work went into the Word & Excel filters, so compatibility there is much greater than just 90%. A lot also depends on the fonts you have, even on Windows with Office if you don't have the same fonts as the document requires, Office has to do some guessing same as OOo does. Dan From jspaleta at gmail.com Tue Feb 22 15:24:37 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 10:24:37 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109085265.12204.1.camel@linux.local> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> <604aa79105022207102e24a420@mail.gmail.com> <1109085265.12204.1.camel@linux.local> Message-ID: <604aa791050222072431f32b65@mail.gmail.com> On Tue, 22 Feb 2005 16:14:26 +0100, Hans Kristian Rosbach wrote: > Java + devel + emacs on one cd for example > games + kde + office on one? not sure how thats functionally better than what we have right now... which i remind you goes something like this: 2 cds to do a default desktop install (does anyone actually do these) 3 cds to do workstation or install with kde (workstation installs are probably the most common) 4 cds if yer a lunatic and want xfce if fc4 went to 5 cds java without doing anything else... we'd end up with pretty much what you are talking about.. -jef From dnjinc at wowway.com Tue Feb 22 15:27:41 2005 From: dnjinc at wowway.com (Demond James) Date: Tue, 22 Feb 2005 10:27:41 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221211934.GD31765@nostromo.devel.redhat.com> Message-ID: <421B4F6D.5060304@wowway.com> Paul A. Houle wrote: >> - mozilla (classic) - superseded by firefox, thunderbird, epiphany, etc > > > I have no idea why the world has embraced firefox after rejecting > mozilla. Perhaps there's a hidden way to do it, but I've had much > better luck configuring the pop-up blocker in mozilla... The are > lots of little features in mozilla I find myself missing in firefox. > > On the other hand, RH always seems to ship a Mozilla that's > hopelessly out of date so I usually end up installing my own in > /usr/local and rpm --erasing the one that came with the OS. (Funny > enough, I do that for all of the software that I actually care about.) > Then perhaps this is a good reason to move mozilla to Extras where someone from the community can better maintain the packages. Demond "Extras != Extinction" From ph18 at cornell.edu Tue Feb 22 15:40:08 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 22 Feb 2005 10:40:08 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109085665.341.1.camel@dcbw.boston.redhat.com> References: <20050221230925.7a9fabf8@python2> <200502220959.38111.rjune@bravegnuworld.com> <1109085665.341.1.camel@dcbw.boston.redhat.com> Message-ID: On Tue, 22 Feb 2005 10:21:05 -0500, Dan Williams wrote: > For 2.0 a bunch of work went into the Word & Excel filters, so > compatibility there is much greater than just 90%. A lot also depends > on the fonts you have, even on Windows with Office if you don't have the > same fonts as the document requires, Office has to do some guessing same > as OOo does. > For me the showstopper is lacking the ability to write comments on documents. This is almost 100% of what I use MS word for. Even back in '99 when OO was called Star Office I felt that it was adequate for writing documents... I'd convert it to word and send it to the publisher and everything was cool. But then I'd get it back in word format with comments and I'd need to use Microsoft word in order to see the comments, reply to them, make edits that the system could track with "track changes". Since my publisher went out of business, I've rarely used any kind of office program to create a document -- I generally use "emacs". I think that e-mail attachments are a great way to pass unimportant business documents around, but if you really want me to read something (rather than put it off to something I might do next week) you'd best do it as ordinary text, and that's true even if I'm reading my mail on Windows. I think the "import filter" idea is 100% of what's wrong with workflows that involve office programs and other software (such as CMS systems.) It's necessary, because different systems use different representations, but then even 99.9% accuracy isn't enough because the kind of people that exchange office documents with other people expect to be able to do round-trip scenarios and even the slightest bit of mangling is a huge annoyance when it has to get unmangled again and again. (Or doesn't get noticed until you get back 1500 copies from the printer.) My wife's sister works for a social service agency where they'd bought one copy of MS word and installed it on all the machines. At some point they realized they weren't in compliance with the license but they couldn't afford to buy MS Office for all their computers -- so they switched to Star Office. They had the kind of "round trip" problems dealing with outside agencies and found it just wasn't worth the bother and they finally found the cash to pay the troll. From dnjinc at wowway.com Tue Feb 22 15:40:34 2005 From: dnjinc at wowway.com (Demond James) Date: Tue, 22 Feb 2005 10:40:34 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050221220731.GB11759@devserv.devel.redhat.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> Message-ID: <421B5272.90603@wowway.com> Alan Cox wrote: >On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote: > > >Really some games need to stay - they are one of the things that make people >use Linux and choose it. To be quite frank I'd rather see all the java stuff >dumped off to a java-extras CD or fedora extras. Ditto eclipse with it. > > > I say let's look elsewhere before we start swinging the axe at Java stuff. We can still keep them on the list, but I say start with the bigger games and the redundant applications first. From kmaraas at broadpark.no Tue Feb 22 15:57:52 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Tue, 22 Feb 2005 16:57:52 +0100 Subject: glibc versioning Message-ID: <1109087873.8388.8.camel@localhost.localdomain> Hi. Tried compiling valgrind against the current glibc from CVS today and it broke since glibc now defines __GLIBC_MINOR__ = 4 even though the version is 2.3.x. Is this done on purpose or is it an oversight when merging fixes from CVS? Cheers Kjartan From abo at kth.se Tue Feb 22 16:02:08 2005 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 22 Feb 2005 17:02:08 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050221222508.GJ11759@devserv.devel.redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> Message-ID: <1109088127.30096.199.camel@endor.e.kth.se> On Mon, 2005-02-21 at 23:25, Alan Cox wrote: > A Java themed disk may be trickier as a part of base. > I'd much rather see a Java yum repository and a non-install time java .iso > (which is easy to do as a standalone) Yeah, isn't that what the "Additional CDs" button in firstboot is for anyway? Though. this means not telling Anaconda about the Java stuff, which has the disadvantage of excluding Java in network installs. /abo From josha at sgi.com Tue Feb 22 16:17:29 2005 From: josha at sgi.com (Josh Aas) Date: Tue, 22 Feb 2005 10:17:29 -0600 Subject: refactoring rc.sysinit In-Reply-To: <20050211202204.GB18471@nostromo.devel.redhat.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> <20050211202204.GB18471@nostromo.devel.redhat.com> Message-ID: <421B5B19.70100@sgi.com> Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: > >>In the past, I found myself in some situations where I would have loved >>to do things before or after a certain stage in rc.sysinit. How things >>were, I had to change the file itself which either made me retrofit >>these changes to a new rc.sysinit or lead to surprises when updating >>initscripts. > > > Got example usage cases? I'm just skeptical of making things more > complicated and slower if the only usage cases are theoretical. Here are some of the things SGI does now, which requires us to respin the initscripts RPM. This is not a complete list, but a quick look at some of the small patches should give you an idea of what we're doing: diff -Nur initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit --- initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 10:45:56.000000000 -0600 +++ initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 10:46:49.000000000 -0600 @@ -348,6 +348,11 @@ fi mount --bind /hwgfs/hw /dev/hw +# Mount the PCI Hot-Plug virtual filesystem +if [ -d /proc/bus/pci/slots ]; then + mount -t pcihpfs none /proc/bus/pci/slots +fi + # LVM initialization if [ -f /etc/lvmtab ]; then [ -e /proc/lvm ] || modprobe lvm-mod > /dev/null 2>&1 diff -Nur initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit --- initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 09:52:42.000000000 -0600 +++ initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 10:04:04.000000000 -0600 @@ -333,6 +333,21 @@ [ "$state" != "rw" ] && \ action $"Remounting root filesystem in read-write mode: " mount -n -o remount,rw / +if [ ! -d /hwgfs ]; then + mkdir /hwgfs +fi + +mount -t hwgfs none /hwgfs +if [ ! -d /hw ]; then + mkdir /hw +fi +mount --bind /hwgfs/hw /hw + +if [ ! -d /dev/hw ]; then + mkdir /dev/hw +fi +mount --bind /hwgfs/hw /dev/hw + # LVM initialization if [ -f /etc/lvmtab ]; then [ -e /proc/lvm ] || modprobe lvm-mod > /dev/null 2>&1 diff -Nur initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit --- initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 10:38:04.000000000 -0600 +++ initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 10:38:36.000000000 -0600 @@ -598,6 +598,20 @@ RHGB_STARTED=1 fi +# +# Configure lkcd dump driver based on parameters in: +# /etc/sysconfig/dump +# and save crash dump data (if any). +# +if [ -x /sbin/lkcd ]; then + # Don't use last 1024 KBytes of disk during dump. + tmp=`(. /etc/sysconfig/dump && mktemp $DUMPDIR/tmp.XXXXXX) 2>/dev/null` + test -f "$tmp" && dd "$tmp" bs=1k count=1024 2>/dev/null + action "Saving crash dump data (if any)" /sbin/lkcd save + rm -f "$tmp" + action "Configuring system to save crash dumps" /sbin/lkcd config +fi + # Start up swapping. update_boot_stage RCswap action $"Activating swap partitions: " swapon -a -e @@ -834,6 +848,16 @@ ln -s -f System.map-$unamer /boot/System.map fi +# Adjust symlinks as necessary in /boot to capture Kerntypes for +# crash dumps +if [ -L /boot/Kerntypes -a -r /boot/Kerntypes-`uname -r` -a \ + ! /boot/Kerntypes -ef /boot/Kerntypes-`uname -r` ] ; then + ln -s -f Kerntypes-`uname -r` /boot/Kerntypes +fi +if [ ! -e /boot/Kerntypes -a -r /boot/Kerntypes-`uname -r` ] ; then + ln -s -f Kerntypes-`uname -r` /boot/Kerntypes +fi + # The special Red Hat kernel library symlink must point to the right library # We need to deal with cases where there is no library, and we need to # deal with any version numbers that show up. diff -Nur initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit --- initscripts-sgi/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 09:44:26.000000000 -0600 +++ initscripts-work/initscripts-7.31.13.EL/rc.d/rc.sysinit 2004-01-17 09:47:48.000000000 -0600 @@ -83,6 +83,17 @@ # Configure kernel parameters update_boot_stage RCkernelparam +# Set shmmax to reasonable value (70% of main memory), before +# sysctl.conf is read, so any settings in sysctl.conf override +# normally. + +awk < /proc/meminfo ' + $1 == "MemTotal:" && $3 == "kB" { + shmmax = int($2 * 1024 * 0.7) + printf "sysctl -w kernel.shmmax=%d\n", shmmax + } +' | bash >/dev/null 2>&1 + action $"Configuring kernel parameters: " sysctl -e -p /etc/sysctl.conf # Set the system clock. -- Josh Aas Silicon Graphics, Inc. (SGI) Linux System Software 651-683-3068 From alan at redhat.com Tue Feb 22 16:17:34 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 22 Feb 2005 11:17:34 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421B5272.90603@wowway.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> Message-ID: <20050222161734.GA14590@devserv.devel.redhat.com> On Tue, Feb 22, 2005 at 10:40:34AM -0500, Demond James wrote: > I say let's look elsewhere before we start swinging the axe at Java > stuff. We can still keep them on the list, but I say start with the > bigger games and the redundant applications first. The few really redundant applications we have don't make a tiny dent in the space required for java. The more I think about it the more it seems to come down to "Gnome, KDE, Java, Open Office" pick any three. From dcbw at redhat.com Tue Feb 22 16:19:06 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 22 Feb 2005 11:19:06 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221230925.7a9fabf8@python2> <200502220959.38111.rjune@bravegnuworld.com> <1109085665.341.1.camel@dcbw.boston.redhat.com> Message-ID: <1109089146.341.9.camel@dcbw.boston.redhat.com> On Tue, 2005-02-22 at 10:40 -0500, Paul A. Houle wrote: > On Tue, 22 Feb 2005 10:21:05 -0500, Dan Williams wrote: > > > For 2.0 a bunch of work went into the Word & Excel filters, so > > compatibility there is much greater than just 90%. A lot also depends > > on the fonts you have, even on Windows with Office if you don't have the > > same fonts as the document requires, Office has to do some guessing same > > as OOo does. > > > > For me the showstopper is lacking the ability to write comments on > documents. Umm, Insert->Note? > > This is almost 100% of what I use MS word for. Even back in '99 when OO > was called Star Office I felt that it was adequate for writing > documents... I'd convert it to word and send it to the publisher and > everything was cool. But then I'd get it back in word format with > comments and I'd need to use Microsoft word in order to see the comments, > reply to them, make edits that the system could track with "track > changes". Umm, File->Versions? Edit->Changes? All these things have been around for more than a year. They are supposed to be more or less equivalent to the Word features they refer to, and if there is missing functionality for them, that is a bug that needs to get fixed. > I think the "import filter" idea is 100% of what's wrong with workflows > that involve office programs and other software (such as CMS systems.) > It's necessary, because different systems use different representations, > but then even 99.9% accuracy isn't enough because the kind of people that > exchange office documents with other people expect to be able to do > round-trip scenarios and even the slightest bit of mangling is a huge > annoyance when it has to get unmangled again and again. (Or doesn't get > noticed until you get back 1500 copies from the printer.) For most people, the functionality offered by at least OpenOffice.org, and possibly KOffice/Abiword/Gnumeric is sufficient. We're not trying to get 100% compatibility overnight here, that's impossible. But what the project does try to do is be "Good Enough", which is the formula that Microsoft itself uses for most things. When you're Good Enough for most people, the product starts to get used, and you gain marketshare. When you gain marketshare, people start having to deal with your file format, and more and more people eventually are able to do both formats. Its a gradual thing that takes a while, even MS Word took quite a while to overtake WordStar (or whatever that was), as Excel too time to overtake 123 and VisiCalc. It took years before Word & Excel were "Good Enough", but when they were, people really started to use them. Dan From harald at redhat.com Tue Feb 22 16:23:59 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 22 Feb 2005 17:23:59 +0100 Subject: RFE: Put fedora on a diet In-Reply-To: <1108888503.5960.15.camel@pensja.lam.pl> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> <9f50a7a005021922376f3c2baf@mail.gmail.com> <1108888503.5960.15.camel@pensja.lam.pl> Message-ID: <421B5C9F.5060303@redhat.com> Leszek Matok wrote: > requirements for desktop - try to run Mozilla on 400 MHz Pentium 2 - > pointless). > > Lam > Works... xfce, thunderbird, firefox on a 450 MHz, only slow because of "only" 128MB RAM and the slow laptop HD. From dnjinc at wowway.com Tue Feb 22 16:32:07 2005 From: dnjinc at wowway.com (Demond James) Date: Tue, 22 Feb 2005 11:32:07 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109043083.29658.5.camel@localhost.localdomain> References: <1109043083.29658.5.camel@localhost.localdomain> Message-ID: <421B5E87.1080809@wowway.com> Havoc Pennington wrote: >Hi, > >Can I suggest two possible approaches... > > 1) we aren't willing to remove anything that was in FC3 due to the > upgrade problem, so we basically have to remove the stuff that's > new since FC3; just do that > > If this is the case then maybe we should go with 5 CD for FC4 and wait 'til anaconda can handle multiple repos to trim packages. We run the risk of releasing a FC3 with updated versions of the packages if you do this. There no innovation there. I think some of the newer packages need to be included in core to facilitate innovation in this distro. From rjune at bravegnuworld.com Tue Feb 22 16:33:55 2005 From: rjune at bravegnuworld.com (Richard June) Date: Tue, 22 Feb 2005 11:33:55 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109085665.341.1.camel@dcbw.boston.redhat.com> References: <200502220959.38111.rjune@bravegnuworld.com> <1109085665.341.1.camel@dcbw.boston.redhat.com> Message-ID: <200502221133.59102.rjune@bravegnuworld.com> On Tuesday 22 February 2005 10:21, Dan Williams wrote: > On Tue, 2005-02-22 at 09:59 -0500, Richard June wrote: > > On Tuesday 22 February 2005 08:38, Paul A. Houle wrote: > > > On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou > > > > > > So far as I'm concerned, all the "office" packages can go. > > > I've found that 90% compatibility with MS Office isn't enough to work > > > with the groups I work with and just wind up running the real thing > > > under crossover. > > > > I would disagree with you here. for the groups I work with 90% is great, > > not only that, some have wound up moving to OO.o on windows as well. > > For 2.0 a bunch of work went into the Word & Excel filters, so > compatibility there is much greater than just 90%. A lot also depends > on the fonts you have, even on Windows with Office if you don't have the > same fonts as the document requires, Office has to do some guessing same > as OOo does. I went through the trouble of installing a number of fonts for my users. so fonts aren't much of an issue. I am looking forward to OO.o 2.0 though -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Feb 22 16:39:07 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 16:39:07 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050222161734.GA14590@devserv.devel.redhat.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> Message-ID: <1109090347.26578.141.camel@localhost.localdomain> On Tue, 2005-02-22 at 11:17 -0500, Alan Cox wrote: >The few really redundant applications we have don't make a tiny dent in the >space required for java. The more I think about it the more it seems to come >down to "Gnome, KDE, Java, Open Office" pick any three None of which is really going to work. The answer is to just ship it with 15 (5+5+4) CDs instead of the 14 (5+5+5) people are beating themselves up to achieve, and sort it out for FC5 when anaconda can handle multiple repositories during the install. >. -- dwmw2 From daly at rio.sci.ccny.cuny.edu Tue Feb 22 17:17:12 2005 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 22 Feb 2005 12:17:12 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109090347.26578.141.camel@localhost.localdomain> (message from David Woodhouse on Tue, 22 Feb 2005 16:39:07 +0000) References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <1109090347.26578.141.camel@localhost.localdomain> Message-ID: <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> An alternative approach is to adopt the Knoppix compressed file system. Knoppix manages to get about 2.3Gig on a single CD. Tim Daly From mpeters at mac.com Tue Feb 22 16:41:16 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 22 Feb 2005 16:41:16 +0000 Subject: FC4 slimfast slimfest In-Reply-To: (from ph18@cornell.edu on Tue Feb 22 05:27:49 2005) References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <421A52E6.4070407@bluga.net> Message-ID: <1109090476l.10188l.0l@devel.mpeters.us> On 02/22/2005 05:27:49 AM, Paul A. Houle wrote: > The thing I hate most about modern *nix is the proliferation of > different documation formats. Yes. I think every command expected to be run from the cli should have a man page. And not a man page that says "please see the info page" Every gui app should have documentation in scrollkeeper. That's my opinion, but whatever is chosen - it should be chosen and stuck with, and projects that use different documentation methods should have bugs files against them so that document writers can know what needs to be done. Huge documentation such as the php manual etc. obviously are not a man page, and are not a gui app and thus not a scrollkeeper issue - for those, texinfo has a high value because they can be exported from texinfo to many types of documentation as needed (pdf, html, etc.) following the documentation guidelines could (should?) even be imposed as a requirement for a new package being excepted in Fedora Extras. -- Michael A. Peters http://mpeters.us/ From n3npq at nc.rr.com Tue Feb 22 16:44:18 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 22 Feb 2005 11:44:18 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222161734.GA14590@devserv.devel.redhat.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> Message-ID: <421B6162.3090505@nc.rr.com> Alan Cox wrote: >On Tue, Feb 22, 2005 at 10:40:34AM -0500, Demond James wrote: > > >>I say let's look elsewhere before we start swinging the axe at Java >>stuff. We can still keep them on the list, but I say start with the >>bigger games and the redundant applications first. >> >> > >The few really redundant applications we have don't make a tiny dent in the >space required for java. The more I think about it the more it seems to come >down to "Gnome, KDE, Java, Open Office" pick any three. > > I happen to agree with 3 out of 4, makes perfect sense to me. However, I'm obligated to point out that there is some mechanical drudgery that might put off the day of reckoning for what packages should be in FC4. The space constraints are approximately 4*650Mb = 2.3Gb. Current overage is 300Mb, so package real estate is currently (estimated) 2.6Gb. Headers are (or were) ~12-15% of package real estate. Let's use 10% for the analysis, or 260Mb of headers in current FC4. Compressing headers would save about half of that, or ~130Mb, more if changelogs were truncated during build. Much learned discussion (jnovy in particular iirc) points out additional savings achievable by choosing to use bzip2 for certain large package payloads. I'll wave my hands here, but I'm pretty sure that a big chunk of 170Mb could be saved. Yes new rpm features, but zlib ain't exactly hard coding, nor is a date comparison loop for truncating changelogs, nor is configuring bzip2 payloads for certain package payloads. And yes, there's a knapsack problem fitting packages onto 4 CD's in priority order that is not addressed above at all. Again, my personal belief is that 3 out of 4 is sounder (as in soundboard) starting point for FC discussion. 73 de Jeff From mpeters at mac.com Tue Feb 22 16:45:58 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 22 Feb 2005 16:45:58 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> (from laroche@redhat.com on Tue Feb 22 06:15:41 2005) References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> Message-ID: <1109090758l.10188l.1l@devel.mpeters.us> On 02/22/2005 06:15:41 AM, Florian La Roche wrote: > On Mon, Feb 21, 2005 at 05:13:14PM -0500, Alan Cox wrote: > > On Mon, Feb 21, 2005 at 10:19:48PM +0100, F?liciano Matias wrote: > > > > postfix-doc, we have python-doc but no php-doc or perl-doc) > > > > > > > I am not agree. If we provide exim, we provide *all* exim. > > > > Shove exim in extras then. Lets have one of everything (including > databases) > > in the base except where the are real divides (Gnome/KDE) > > I think exim still has potential to become our future default MTA. That doesn't mean it has to sit in core while it is not. I'm seriously hoping that AbiWord and Gnumeric someday will be the default office apps in core, OOo imho is bloated and has a code base that is just too big, I personally think OOo was a poor choice to default to - and had the resources by various distros been put into AbiWord/Gnumeric that were put into OOo - they would absolutely rock even more than they already do. But while OOo is what is being pushed and defaulted to, AbiWord/ Gnumeric need to live in Extras so that they do not add to what a user who sticks with defaults has to download. -- Michael A. Peters http://mpeters.us/ From mattdm at mattdm.org Tue Feb 22 16:48:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 22 Feb 2005 11:48:55 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <1109090347.26578.141.camel@localhost.localdomain> <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> Message-ID: <20050222164855.GA19603@jadzia.bu.edu> On Tue, Feb 22, 2005 at 12:17:12PM -0500, Tim Daly wrote: > An alternative approach is to adopt the Knoppix compressed file system. > Knoppix manages to get about 2.3Gig on a single CD. The RPMs are already compressed; that's not going to help much. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From harald at redhat.com Tue Feb 22 16:56:43 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 22 Feb 2005 17:56:43 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <604aa7910502220611706747d0@mail.gmail.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <5256d0b05022117475f4013f6@mail.gmail.com> <1109071273.26578.89.camel@localhost.localdomain> <20050222145627.A1035@kushana.camperquake.de> <604aa7910502220611706747d0@mail.gmail.com> Message-ID: <421B644B.3010900@redhat.com> Jeff Spaleta wrote: > On Tue, 22 Feb 2005 14:56:27 +0100, Ralf Ertzinger > >>Unless I am very much mistaken, this is possible right now. If you put all >>the Java stuff on CD 5 (for example), and do not select any of it in the >>anaconda, then anaconda will not request the fifth CD, so you do not need >>it. In a similar way, I'd put all the development stuff on a seperate CD, >>too (*-devel, gcc), so you'd be able to skip downloading that if you know >>that you'd want a non-developer desktop, anyway. > > > Careful, you have to consider the problems of space packing. Moving > -devel off onto its own cd and java on its own cd.. etc..etc.. might > actually end up with 6+ partially full cds. Once you start grouping > things into cds based function there's no garuntee you'll be able to > pack them as efficiently into the same number of isos. I'm not saying > this is a bad idea... im just saying that using this approach to drill > down to an 1 cd installable desktop.. might end up costing you 7 or 8 > partially full cd iso images in the end if the requirement to ship all > of Core on isos remains. > > -jef > And would it be a problem to end with 8 partially full CDs? We could also make a 3/4 CD set for every use case and one DVD for the magazines/books/stores. What would have then is: 50% of the users only need to download CD 1 and 2 30% install CD 1-3 of their use case 15% install CD 1-4 of their use case 5% want everything (the DVD) (numbers made up / guessed) :) From dnjinc at wowway.com Tue Feb 22 17:01:59 2005 From: dnjinc at wowway.com (Demond James) Date: Tue, 22 Feb 2005 12:01:59 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221230925.7a9fabf8@python2> Message-ID: <421B6587.4060006@wowway.com> Paul A. Houle wrote: > On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou > > wrote: > >> - tuxracer >> (nothing new in ages, and not a really exciting game) > > > This is my toddler's favorite game. It's the best way to put him > to sleep. > >> - abiword, gnumeric >> (I use them a lot, but OOo is included) >> > > So far as I'm concerned, all the "office" packages can go. > I've found that 90% compatibility with MS Office isn't enough to work > with the groups I work with and just wind up running the real thing > under crossover. > OK, that's your experience. That's still not an argument for not having an office suite in Fedora Core. It's not there for MS compatibility. It also make abiword & gnumeric redundant and "extras" so they should be moved to FE. From jspaleta at gmail.com Tue Feb 22 17:16:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 12:16:07 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421B644B.3010900@redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <5256d0b05022117475f4013f6@mail.gmail.com> <1109071273.26578.89.camel@localhost.localdomain> <20050222145627.A1035@kushana.camperquake.de> <604aa7910502220611706747d0@mail.gmail.com> <421B644B.3010900@redhat.com> Message-ID: <604aa79105022209161b2a6e25@mail.gmail.com> On Tue, 22 Feb 2005 17:56:43 +0100, Harald Hoyer wrote: > And would it be a problem to end with 8 partially full CDs? No matter what Red Hat decides to do for Fedora Core.. you will have problems. Pick your poison.. i suggest the one that tastes like cherries. > > We could also make a 3/4 CD set for every use case and one DVD for the > magazines/books/stores. Long term... i think this is the start of an equitable solution. If Core is going to continue to be 'general purpose' there must be a way to repackage Core for 'specific purposes.' However from my perspective over here on the grassy knoll outside the red hat fenceline... I honestly don't think Red Hat currently has the ability or political will to expend the resources to make spinning up mutliple 'official' usage case mediasets. For this to work, I believe that the sheparding of use case mediasets needs to be expanded to include community and the trademark guidelines re-worked to allow for anyone in the community to pull packages from Core and Extras to create use-case media sets as they see fit without official blessing. I would point to mozilla's new tiered trademark policy that allows for community editions to be built as an example of how to expand trademark policy in a community inclusive way to allow community to accomplish use-case oriented mediasets that are instantly distinguishable from the 'official' sets. Mozilla's model would lead to things named like Community Core - Usage Case Edition Release Number, for community built mediasets that include only unmodified Core packages to serve a defined usage role. Community Core - Mail Server Edition Release 7.003 for example. -jef > > What would have then is: > > 50% of the users only need to download CD 1 and 2 > 30% install CD 1-3 of their use case > 15% install CD 1-4 of their use case > 5% want everything (the DVD) > > (numbers made up / guessed) :) > From poelstra at redhat.com Tue Feb 22 17:32:52 2005 From: poelstra at redhat.com (John Poelstra) Date: Tue, 22 Feb 2005 12:32:52 -0500 Subject: RFE: Put fedora on a diet In-Reply-To: <421B5C9F.5060303@redhat.com> References: <5cf776b8050218172539ce5544@mail.gmail.com> <20050219094202.87231.qmail@web8506.mail.in.yahoo.com> <9f50a7a005021922376f3c2baf@mail.gmail.com> <1108888503.5960.15.camel@pensja.lam.pl> <421B5C9F.5060303@redhat.com> Message-ID: <421B6CC4.5010402@redhat.com> Harald Hoyer wrote: > Leszek Matok wrote: > >> requirements for desktop - try to run Mozilla on 400 MHz Pentium 2 - >> pointless). >> >> Lam >> > > Works... xfce, thunderbird, firefox on a 450 MHz, only slow because of > "only" 128MB RAM and the slow laptop HD. > Or for even less memory consumption use iceWM. http://linuxgazette.net/108/bilbrey.html I'm running fine on a 300 Mhz PII dell w/ 128MB RAM and FC3 From n3npq at nc.rr.com Tue Feb 22 17:36:35 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 22 Feb 2005 12:36:35 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421B6162.3090505@nc.rr.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <421B6162.3090505@nc.rr.com> Message-ID: <421B6DA3.9000606@nc.rr.com> Jeff Johnson wrote: > Alan Cox wrote: > >> On Tue, Feb 22, 2005 at 10:40:34AM -0500, Demond James wrote: >> >> >>> I say let's look elsewhere before we start swinging the axe at Java >>> stuff. We can still keep them on the list, but I say start with the >>> bigger games and the redundant applications first. >>> >> >> The few really redundant applications we have don't make a tiny dent >> in the >> space required for java. The more I think about it the more it seems >> to come >> down to "Gnome, KDE, Java, Open Office" pick any three. >> >> > > I happen to agree with 3 out of 4, makes perfect sense to me. > > However, I'm obligated to point out that there is some mechanical > drudgery > that might put off the day of reckoning for what packages should be in > FC4. > > The space constraints are approximately 4*650Mb = 2.3Gb. Eeep, serves me right for multiplying in public, sigh. s/2.3/2.6/ > > > Current overage is 300Mb, so package real estate is currently > (estimated) 2.6Gb. s/2.6/2.9/ > > Headers are (or were) ~12-15% of package real estate. > > Let's use 10% for the analysis, or 260Mb of headers in current FC4. s/260/290/ > > Compressing headers would save about half of that, or ~130Mb, more if > changelogs > were truncated during build. s/130/145/ > > Much learned discussion (jnovy in particular iirc) points out > additional savings achievable > by choosing to use bzip2 for certain large package payloads. I'll wave > my hands here, > but I'm pretty sure that a big chunk of 170Mb could be saved. s/170/155/ > > Yes new rpm features, but zlib ain't exactly hard coding, nor is a > date comparison loop > for truncating changelogs, nor is configuring bzip2 payloads for > certain package payloads. > > And yes, there's a knapsack problem fitting packages onto 4 CD's in > priority order > that is not addressed above at all. > > Again, my personal belief is that 3 out of 4 is sounder (as in > soundboard) starting point > for FC discussion. The analysis is more important than the computational details ... And 3 out of 4 is still my personal choice. Sorry for the confusion. 73 de Jeff From notting at redhat.com Tue Feb 22 17:36:53 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Feb 2005 12:36:53 -0500 Subject: refactoring rc.sysinit In-Reply-To: <421B5B19.70100@sgi.com> References: <420BDB79.2060505@sgi.com> <20050210222027.GA26361@nostromo.devel.redhat.com> <1108085322.6187.17.camel@pensja.lam.pl> <20050211032105.GF29375@nostromo.devel.redhat.com> <1108111892.455.10.camel@gibraltar.stuttgart.redhat.com> <20050211202204.GB18471@nostromo.devel.redhat.com> <421B5B19.70100@sgi.com> Message-ID: <20050222173653.GB23623@nostromo.devel.redhat.com> Josh Aas (josha at sgi.com) said: > +if [ ! -d /hwgfs ]; then > + mkdir /hwgfs > +fi > + > +mount -t hwgfs none /hwgfs > +if [ ! -d /hw ]; then > + mkdir /hw > +fi > +mount --bind /hwgfs/hw /hw > + > +if [ ! -d /dev/hw ]; then > + mkdir /dev/hw > +fi > +mount --bind /hwgfs/hw /dev/hw > + Oh, yuk. A sysfs-alike for IRIX compatibility? :) > > +# > +# Configure lkcd dump driver based on parameters in: > +# /etc/sysconfig/dump > +# and save crash dump data (if any). > +# > +if [ -x /sbin/lkcd ]; then > + # Don't use last 1024 KBytes of disk during dump. > + tmp=`(. /etc/sysconfig/dump && mktemp $DUMPDIR/tmp.XXXXXX) > 2>/dev/null` > + test -f "$tmp" && dd "$tmp" bs=1k count=1024 2>/dev/null > + action "Saving crash dump data (if any)" /sbin/lkcd save > + rm -f "$tmp" > + action "Configuring system to save crash dumps" /sbin/lkcd config > +fi > + ... > +# Adjust symlinks as necessary in /boot to capture Kerntypes for > +# crash dumps > +if [ -L /boot/Kerntypes -a -r /boot/Kerntypes-`uname -r` -a \ > + ! /boot/Kerntypes -ef /boot/Kerntypes-`uname -r` ] ; then > + ln -s -f Kerntypes-`uname -r` /boot/Kerntypes > +fi > +if [ ! -e /boot/Kerntypes -a -r /boot/Kerntypes-`uname -r` ] ; then > + ln -s -f Kerntypes-`uname -r` /boot/Kerntypes > +fi > + Probably should be in its own script. Bill From fedora-devel at tlarson.com Tue Feb 22 17:44:56 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 22 Feb 2005 10:44:56 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <604aa7910502220718421e63f1@mail.gmail.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <1109082945.5422.30.camel@dhcp63-240.rdu.redhat.com> <20050222145711.GA25805@rogers.com> <604aa7910502220718421e63f1@mail.gmail.com> Message-ID: <421B6F98.1080801@tlarson.com> Jeff Spaleta wrote: > On Tue, 22 Feb 2005 09:57:11 -0500, Dimitrie O. Paun wrote: > >>And you get the huge >>advantage that you would know apriori what CDs you need: no need to >>download, burn, verify the images you don't care about. I think it would >>end up saving time for many folks. > > > i highly doubt that.... for upgrades... its going to be a HUGE time > suck trying to avoid downloading optional cds. > > Sure you might install fc6 just using the cds you need.. .but then you > used yum and installed a game or two... and a little java.. and then a > few -devel packages because you wanted to compile something up from > srpm. 3 months later.... yer ready to install fc7.. have fun writing > the comparative scripts to figure out which 'optional' cds you now > need to download. Unless some in-distro tools are created to help > work it out for you.. its going to be a huge frelling mess for a large > class of users who want to upgrade from release to release. > > -jef > What it sounds like Alan is suggesting is taking Havoc's "profiles" (there may be 10 to 20 of them) and using them a guide to determine which packages go on which of the 4 or 5 install CDs. This way, perhaps each CD will be less full, but at least some people won't have to download all of them. Furthermore, the CDs will (should) be marked to show which profiles they fulfill. Something like "CD #3: print server, file server, mail server". In this scenario, very little actually changes. We maybe add a CD or two, but hopefully gain a little better organization of the packages in the process. People who are upgrading can download the CD's they think they'll need based on what software they have installed. If they want to play it safe, they can download all the CDs before they begin. This isn't at all different than what they do already. From dwmw2 at infradead.org Tue Feb 22 17:45:58 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 17:45:58 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <421B6DA3.9000606@nc.rr.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <421B6162.3090505@nc.rr.com> <421B6DA3.9000606@nc.rr.com> Message-ID: <1109094358.13684.1.camel@localhost.localdomain> On Tue, 2005-02-22 at 12:36 -0500, Jeff Johnson wrote: >Eeep, serves me right for multiplying in public, sigh. >s/2.3/2.6/ I wouldn't worry too much -- you probably should have just kept quiet. I just claimed that 5+5+5=14 and 5+5+4=15, and nobody seemed to care :) -- dwmw2 From sopwith at redhat.com Tue Feb 22 17:47:45 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 22 Feb 2005 12:47:45 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> Message-ID: On Mon, 21 Feb 2005, Phil Muldoon wrote: > > Regardless of your opinions of the merits of the Java language, it's > > just not heavily used by any of the things that desktop users bump into > > every day. (Except, *possibly*, web page applets, but I gather you're > > talking about a much bigger scope than that.) > > One of the products we have in RHEL is Red Hat Developer Suite, which is > based on java. We do active development on this, and we'd like to bring > it to Fedora. There is a huge community of Eclipse users out there. > Also, there is a large sphere of java usage out there. I'm not going to > argue usage metrics, but suffice to say there is enough usage that > warrants interest im(h)o. Java is critical because it's the only language and development environment that's a serious alternative to .NET. So why am I leaning towards pulling eclipse (and Java stuff) out of FC4test1? Because it seems like that's part of the best short-term solution to a short-term problem. All we need to do is have FC4 come out on four CDs. If we can wind up removing enough "other" stuff from FC to allow putting eclipse back for test2, that'll be awesome. These removals aren't permanent by any means, but for now they seem the best way to go. We already know what the long-term solution is - multi-repo support in anaconda, and moving stuff to Extras (hopefully allowing us to slim Core down even more). Another problem is the distribution of ecj - having the main Java compiler be part of the eclipse tarball is really an aweful situation. Fortunately, gcjx will help solve this - hopefully we won't need ecj at all in the future. Cheers, -- Elliot From sopwith at redhat.com Tue Feb 22 17:49:22 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 22 Feb 2005 12:49:22 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <1109030802.27605.4.camel@scriabin.tannenrauch.ch> References: <74be2a270aca29b56528a13cb1edb8cd@192.168.1.254> <20050221225329.GC398@nostromo.devel.redhat.com> <20050221225801.GS17531@redhat.com> <20050221231810.GI3827@redhat.com> <1109030802.27605.4.camel@scriabin.tannenrauch.ch> Message-ID: On Tue, 22 Feb 2005, [ISO-8859-1] G?rard Milmeister wrote: > On Mon, 2005-02-21 at 18:58 -0500, Konstantin Ryabitsev wrote: > > On Mon, 21 Feb 2005 18:18:10 -0500, Dave Jones wrote: > > > > I hope the fortran part of gcc4 has caught up [to do everything > > > > gcc3-f77 does]. I guess I should go back and try gcc4 again. > > > > > > Which reminds me. Is fortran really used by enough people to justify > > > its presence in -core ? (Even if so, does it really need to be in the > > > default install?) > > > > It's still used quite a bit in natural sciences (e.g. Physics, > > Chemistry, etc), but if it's moved to extras, nobody will miss it, > > since the admins will know where to find it. The question is -- can it > > be successfully unmarried from the rest of gcc? > > Doesn't octave require it to build? octave is a personal favorite of mine (I use it as my "calculator" app on Linux). It really needs to move to Extras, though. -- Elliot From fedora-devel at tlarson.com Tue Feb 22 17:52:14 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 22 Feb 2005 10:52:14 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <20050222112021.GA28474@devserv.devel.redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> Message-ID: <421B714E.2080701@tlarson.com> Alan Cox wrote: > On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote: > >>Brilliant idea. Solves all our problems, but creates a set of new one. >>Like, for example, what will the ISOs look like? > > > CD #1 Download only this CD for a base install and use yum to add packages > CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs > via CD/DVD > > Java CD Optional Download for java packages > Games CD Optional Download for extra games > > etc.. > This still sounds like most people will download all (or almost all) of the CDs in order to install the packages they want. However, I really like the idea of installing a base OS from just one CD and installing the rest of the system using yum or up2date. After all, most users will have to update the majority of the packages they've just installed immediately after their first boot. From dnjinc at wowway.com Tue Feb 22 18:00:07 2005 From: dnjinc at wowway.com (Demond James) Date: Tue, 22 Feb 2005 13:00:07 -0500 Subject: Proposal for CD count in FC4 In-Reply-To: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> References: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> Message-ID: <421B7327.9020502@wowway.com> Jesse Keating wrote: >Here is my proposal: > >Given that x86_64 platform will remain at 5CDs unless we do something >drastic, and that FC5 is targeted to have the ability to install from >other repos during anaconda install, we allow FC4 to ship with a 5CD >count for both (all) archs. Then we target FC5 to move some packages to >Extras, and some packages to an online RH controlled repo much like the >RHEL extras. Its still RH maintained, but not shipped on the CD iso >sets. This would allow us to drop down to 2CDs or so in size for the >shippable media, but still allow installing to the full package set. > > > +1 Given the constraint of not being able to remove packages that were in FC3 and I think this is the best approach for now. It's going to either be the main packages like OO.o, Gnome, KDE, etc. or many smaller one since we need to shave 300mb. At the very least at least package the 5th CD so that it's optional in most scenarios. From perbj at stanford.edu Tue Feb 22 18:22:02 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 22 Feb 2005 10:22:02 -0800 Subject: FC4 slimfast slimfest In-Reply-To: <1109089146.341.9.camel@dcbw.boston.redhat.com> References: <20050221230925.7a9fabf8@python2> <200502220959.38111.rjune@bravegnuworld.com> <1109085665.341.1.camel@dcbw.boston.redhat.com> <1109089146.341.9.camel@dcbw.boston.redhat.com> Message-ID: <1109096522.5289.8.camel@localhost.localdomain> On Tue, 2005-02-22 at 11:19 -0500, Dan Williams wrote: > Umm, File->Versions? Edit->Changes? > > All these things have been around for more than a year. They are > supposed to be more or less equivalent to the Word features they refer > to, and if there is missing functionality for them, that is a bug that > needs to get fixed. Well, when I tried to do that yesterday on a Word document the menu item was grayed out until I saved it as an OpenOffice.org document (.sxw). Is it actually supposed to be handled in Word format documents? That would be _wonderful_ for interoperability. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From sopwith at redhat.com Tue Feb 22 18:22:47 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 22 Feb 2005 13:22:47 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <1109090347.26578.141.camel@localhost.localdomain> <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> Message-ID: On Tue, 22 Feb 2005, Tim Daly wrote: > An alternative approach is to adopt the Knoppix compressed file system. > Knoppix manages to get about 2.3Gig on a single CD. The .rpm packages are already compressed, so a compressed file system won't help here. Thanks for thinking outside the box, though! Best, -- Elliot From dwmw2 at infradead.org Tue Feb 22 18:24:29 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 18:24:29 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <421AAE77.5080704@margo.bijoux.nom.br> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> Message-ID: <1109096669.13684.14.camel@localhost.localdomain> On Tue, 2005-02-22 at 01:00 -0300, Pedro Fernandes Macedo wrote: >I dont want to make this a sendmail/postfix/exim/other email server war, >but I think that is a little too much... >Just because one distribution ships exim/koffice/put your favourite app >here as default , it doesnt necessarily mean that's the right choice for >all distributions. That's true, but in this case Debian happens to have it right. We should do what Debian does here because they're _right_, not just because they're doing it and we have to follow. >IMHO , Fedora should ship only one mail server/one app (maybe chosen by >% of users?) in the main CDs. Whatever we ship as default will have the largest percentage of users -- if it worked like that we'd never make any progress. If we switch the default, people who already have experience of a mail server can always switch to whatever they prefer, while the newbies get something which is well-documented, versatile and easy to work with. -- dwmw2 From mricon at gmail.com Tue Feb 22 18:29:45 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 22 Feb 2005 13:29:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221211934.GD31765@nostromo.devel.redhat.com> Message-ID: On Tue, 22 Feb 2005 08:34:46 -0500, Paul A. Houle wrote: > Input methods are a big annoyance to people who don't use them; when we > installed RH 9 on my sister-in-law's computer, her first complaint was > that it "took too long to boot." I went in and cleaned up the boot > sequence and found that a number of different input methods that I'd never > heard of wasted many seconds at boot time. They only get installed when you select that language for installation in Anaconda. You must have selected "install all languages". If you had selected "English only" none of the CJK input methods would have been installed. Regards, -- Konstantin Ryabitsev Zlotniks, INC From cmadams at hiwaay.net Tue Feb 22 18:45:52 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 22 Feb 2005 12:45:52 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <421B714E.2080701@tlarson.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> Message-ID: <20050222184552.GA1444243@hiwaay.net> Once upon a time, Tyler Larson said: > However, I really like the idea of installing a base OS from just one CD > and installing the rest of the system using yum or up2date. After all, most > users will have to update the majority of the packages they've just > installed immediately after their first boot. That still assumes everyone has high-speed bandwidth available, which is a broken assumption. If you think everyone should be downloading to get most packages, why not make boot.iso the only distributed image and make everything else downloaded? That "solves" all the CD/DVD count and distribution issues. I am disappointed that the setup for Fedora Extras is to just have a rolling-update tree with no ISOs. That makes FE packages second class citizens. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Tue Feb 22 18:47:04 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 22 Feb 2005 12:47:04 -0600 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> Message-ID: <20050222184704.GB1444243@hiwaay.net> Once upon a time, Elliot Lee said: > We already know what the long-term solution is - multi-repo support in > anaconda, and moving stuff to Extras (hopefully allowing us to slim Core > down even more). What exactly is "multi-repo support in anaconda"? Does that mean that all installs will have to be network installs and anaconda will download stuff from different repos during install? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at phy.duke.edu Tue Feb 22 18:49:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 13:49:08 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222184704.GB1444243@hiwaay.net> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> <20050222184704.GB1444243@hiwaay.net> Message-ID: <1109098148.15038.31.camel@opus.phy.duke.edu> On Tue, 2005-02-22 at 12:47 -0600, Chris Adams wrote: > Once upon a time, Elliot Lee said: > > We already know what the long-term solution is - multi-repo support in > > anaconda, and moving stuff to Extras (hopefully allowing us to slim Core > > down even more). > > What exactly is "multi-repo support in anaconda"? Does that mean that > all installs will have to be network installs and anaconda will download > stuff from different repos during install? > no. It means that anaconda will not have to know about all possible cds in the hdlist information on the first cd. it will be able to assemble a list of packages from the individual metadata on a set of cds (or, alternatively, from network repos) -sv From cmadams at hiwaay.net Tue Feb 22 18:51:58 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 22 Feb 2005 12:51:58 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109098148.15038.31.camel@opus.phy.duke.edu> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> <20050222184704.GB1444243@hiwaay.net> <1109098148.15038.31.camel@opus.phy.duke.edu> Message-ID: <20050222185158.GC1444243@hiwaay.net> Once upon a time, seth vidal said: > no. It means that anaconda will not have to know about all possible cds > in the hdlist information on the first cd. > > it will be able to assemble a list of packages from the individual > metadata on a set of cds (or, alternatively, from network repos) Okay, but since there are not going to be ISOs of Fedora Extras, we're back to requiring a high-speed network connection to upgrade. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From aoliva at redhat.com Tue Feb 22 18:53:36 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Feb 2005 15:53:36 -0300 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <1109090347.26578.141.camel@localhost.localdomain> <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> Message-ID: On Feb 22, 2005, Elliot Lee wrote: > On Tue, 22 Feb 2005, Tim Daly wrote: >> An alternative approach is to adopt the Knoppix compressed file system. >> Knoppix manages to get about 2.3Gig on a single CD. > The .rpm packages are already compressed, so a compressed file system > won't help here. Thanks for thinking outside the box, though! Talking of compressing stuff... Couldn't we perhaps compress the hdlist and hdlist2 files in Fedora/base? Could we perhaps merge the contents of hdstg2.img and netstg2.img that, given their similar size, might be assumed to contain mostly the same contents? And how about stage2.img, if that's a superset? This certainly wouldn't get us the 300MB we need, but it could get us 5-15% of that. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From alan at redhat.com Tue Feb 22 18:53:45 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 22 Feb 2005 13:53:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222185158.GC1444243@hiwaay.net> References: <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <1109030303.5795.139.camel@dhcp-12.hsv.redhat.com> <20050222184704.GB1444243@hiwaay.net> <1109098148.15038.31.camel@opus.phy.duke.edu> <20050222185158.GC1444243@hiwaay.net> Message-ID: <20050222185345.GA3729@devserv.devel.redhat.com> On Tue, Feb 22, 2005 at 12:51:58PM -0600, Chris Adams wrote: > > it will be able to assemble a list of packages from the individual > > metadata on a set of cds (or, alternatively, from network repos) > > Okay, but since there are not going to be ISOs of Fedora Extras, we're > back to requiring a high-speed network connection to upgrade. Or for someone to write 'extras to iso' From josh at bluga.net Tue Feb 22 18:59:53 2005 From: josh at bluga.net (Joshua Eichorn) Date: Tue, 22 Feb 2005 11:59:53 -0700 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <1109090347.26578.141.camel@localhost.localdomain> <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> Message-ID: <421B8129.1060809@bluga.net> Alexandre Oliva wrote: >On Feb 22, 2005, Elliot Lee wrote: > > > >>On Tue, 22 Feb 2005, Tim Daly wrote: >> >> >>>An alternative approach is to adopt the Knoppix compressed file system. >>>Knoppix manages to get about 2.3Gig on a single CD. >>> >>> > > > >>The .rpm packages are already compressed, so a compressed file system >>won't help here. Thanks for thinking outside the box, though! >> >> > >Talking of compressing stuff... Couldn't we perhaps compress the >hdlist and hdlist2 files in Fedora/base? Could we perhaps merge the >contents of hdstg2.img and netstg2.img that, given their similar size, >might be assumed to contain mostly the same contents? And how about >stage2.img, if that's a superset? This certainly wouldn't get us the >300MB we need, but it could get us 5-15% of that. > > > You could also save similar amounts by only shipping either the postscript or pdf version of docs and not both. (more if you ship 1 of html,ps,pdf) There really are some easy to get size savings around that don't entail dropping packages. -josh From katzj at redhat.com Tue Feb 22 19:03:00 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 22 Feb 2005 14:03:00 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> <1109090347.26578.141.camel@localhost.localdomain> <200502221717.j1MHHC614143@rio.sci.ccny.cuny.edu> Message-ID: <1109098980.4977.38.camel@bree.local.net> On Tue, 2005-02-22 at 15:53 -0300, Alexandre Oliva wrote: >Talking of compressing stuff... Couldn't we perhaps compress the >hdlist and hdlist2 files in Fedora/base? Only if we increase the memory requirements to do an install >Could we perhaps merge the >contents of hdstg2.img and netstg2.img that, given their similar size, >might be assumed to contain mostly the same contents? There are chunks that are the same, but the kernel modules are different. If all of the kernel modules move into the initrd (probably going to happen, although this does increase the memory requirements in general), then these can merge. >And how about >stage2.img, if that's a superset? This certainly wouldn't get us the >300MB we need, but it could get us 5-15% of that. It's a superset, but it's not really merge-able with the other images without major filesystem work. Jeremy From buildsys at redhat.com Tue Feb 22 19:07:26 2005 From: buildsys at redhat.com (Build System) Date: Tue, 22 Feb 2005 14:07:26 -0500 Subject: rawhide report: 20050222 changes Message-ID: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> New package Numeric Numerical Extension to Python Removed package tuxracer Removed package struts11 Updated Packages: Omni-0.9.2-2 ------------ * Fri Feb 18 2005 Tim Waugh 0.9.2-2 - Fix build with GCC 4. anacron-2.3-33 -------------- * Mon Feb 21 2005 Jason Vas Dias 2.3-33 - Rebuild for FC4 . booty-0.48-1 ------------ * Mon Feb 21 2005 Peter Jones 0.48-1 - removed silo debug crap - fixed device.map generation when using LVM * Mon Feb 21 2005 Chris Lumens 0.47-1 - Fixed typo on silo import. * Fri Feb 18 2005 Peter Jones 0.46-1 - add in silo.conf handling, so spot will stop harassing me. cman-kernel-2.6.10-0.10 ----------------------- dhcp-10:3.0.2-1 --------------- * Mon Feb 21 2005 Jason Vas Dias 10:3.0.2-1 - Upgrade to ISC 3.0.2 Final Release (documentation change only). dlm-kernel-2.6.10-0.4 --------------------- findutils-1:4.2.18-1 -------------------- * Mon Feb 21 2005 Tim Waugh 1:4.2.18-1 - 4.2.18. gaim-1:1.1.3-3 -------------- * Mon Feb 21 2005 Dan Williams 1:1.1.3-3 - Work around #149190 gaim-1.1.3-2 segfaults when calling g_stat() gdb-6.3.0.0-0.28 ---------------- * Sun Feb 20 2005 Andrew Cagney 6.3.0.0-0.28 - Back port patch adding symfile-mem.o to all GNU/Linux builds. Fix BZ 146087. * Wed Feb 16 2005 Jeff Johnston 6.3.0.0-0.27 - Bump up release number. * Wed Feb 16 2005 Jeff Johnston 6.3.0.0-0.26 - Fix unload.exp testcase. ghostscript-7.07-38 ------------------- * Mon Feb 21 2005 Tim Waugh 7.07-38 - Fixed inspired by GCC 4. * Tue Jan 18 2005 Tim Waugh - Correct permissions for %{_datadir}/ghostscript/Resource (bug #145420). gnbd-kernel-2.6.10-0.2 ---------------------- gnome-bluetooth-0.5.1-9 ----------------------- * Mon Feb 21 2005 Harald Hoyer - 0.5.1-9 - added gnome hbox patch for bug rh#149215 gnome-desktop-2.9.91-2 ---------------------- * Mon Feb 21 2005 Than Ngo 2.9.91-2 - gnome-about only in GNOME-menu kernel-2.6.10-1.1149_FC4 ------------------------ * Mon Feb 21 2005 Dave Jones - 2.6.11-rc4-bk9 libgnomedb-1:1.2.0-2 -------------------- * Mon Feb 21 2005 Caolan McNamara 1.2.0-2 - rh#149232#/rh#149222# install .desktop to /usr/share/applications libselinux-1.21.10-3 -------------------- * Mon Feb 21 2005 Dan Walsh 1.21.10-3 - Fix matchpathcon on eof. mgetty-1.1.31-3 --------------- * Mon Feb 21 2005 Jason Vas Dias 1.1.31-3 - fix bug 145582: wrong path to sendmail - Rebuild for FC4 octave-6:2.1.57-12 ------------------ * Mon Feb 21 2005 Ivana Varekova 2.1.57-12 - Fix problem with symlinks using ldconfig (bug 147922) openssh-3.9p1-11 ---------------- * Mon Feb 21 2005 Tomas Mraz 3.9p1-11 - don't call syslog in signal handler - allow password authentication when copying from remote to remote machine (#103364) * Wed Feb 09 2005 Tomas Mraz - add spaces to messages in initscript (#138508) openswan-2.3.0-4 ---------------- * Mon Feb 21 2005 Harald Hoyer - 2.3.0-4 - fixed bug rh#149164 pcmcia-cs-3.2.8-4.10 -------------------- * Mon Feb 21 2005 Dave Jones - Fix double fclose in parse_cis() (#146113) policycoreutils-1.21.18-2 ------------------------- * Mon Feb 21 2005 Dan Walsh 1.21.18-2 - Apply Uli patch * The Makefiles should use the -Wall option even if compiled in beehive * Add -W, too * use -Werror when used outside of beehive. This could also be used unconditionally * setfiles/setfiles.c: fix resulting warning * restorecon/restorecon.c: Likewise * run_init/open_init_pty.c: argc hasn't been checked, the program would crash if called without parameters. ignore the return value of nice properly. * run_init: don't link with -ldl lutil * load_policy: that's the bad bug. pointer to unsigned int is passed, size_t is written to. fails on 64-bit archs * sestatus: signed vs unsigned problem * newrole: don't link with -ldl python-2.4-4 ------------ * Wed Feb 02 2005 Mihai Ibanescu 2.4-4 - Fixed security issue in SimpleXMLRPCServer.py (#146647) * Wed Jan 12 2005 Tim Waugh 2.4-3 - Rebuilt for new readline. * Mon Dec 06 2004 Jeff Johnson 2.4-2 - db-4.3.21 returns DB_BUFFER_SMALL rather than ENOMEM (#141994). - add Provide: python(abi) = 2.4 - include msgfmt/pygettext *.pyc and *.pyo from brp-python-bytecompile. python-twisted-1.3.0-3 ---------------------- * Mon Feb 21 2005 Jeremy Katz - 1.3.0-3 - disable the -docs subpackage for now radvd-0.7.2-10 -------------- * Mon Feb 21 2005 Jason Vas Dias - rebuild for FC4 rpmdb-fedora-1:4-0.20050222 --------------------------- selinux-policy-strict-1.21.14-2 ------------------------------- * Mon Feb 21 2005 Dan Walsh 1.21.14-2 - Lots of fix patches from Ivan selinux-policy-targeted-1.21.14-2 --------------------------------- * Mon Feb 21 2005 Dan Walsh 1.21.14-2 - Lots of fix patches from Ivan tetex-3.0-2 ----------- * Fri Feb 18 2005 Jindrich Novy 3.0-2 - update dvipsk-5.95a-p1.6a.tar.gz and dvipsk-jpatch-p1.6a1-pdvips.patch because of portability problems (#148947) totem-0.101-4 ------------- * Mon Feb 21 2005 Bill Nottingham - 0.101-4 - fix %post xffm-4.2.0-2 ------------ * Mon Feb 21 2005 Than Ngo 4.2.0-2 - cleanup menu xscreensaver-1:4.18-18 ---------------------- * Mon Feb 21 2005 Ray Strode 1:4.18-18 - Install desktop files to /usr/share/applications instead of /usr/share/control-center-2.0 (should fix bug 149229). yum-2.3.0-1 ----------- * Mon Feb 21 2005 Jeremy Katz - 2.3.0-1 - update to 2.3.0 From aoliva at redhat.com Tue Feb 22 19:14:31 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Feb 2005 16:14:31 -0300 Subject: FC4 slimfast slimfest In-Reply-To: <20050222021100.GB663812@hiwaay.net> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> Message-ID: On Feb 21, 2005, Chris Adams wrote: > Once upon a time, Alexandre Oliva said: >> Think of it this way: would you push OOo to extras? Why not? If so, >> why insist on pushing other very, perhaps even more useful pieces of >> software there, before they have be regarded as actually part of the >> distro, not as second-class citizens? > How many Fedora users will use OOo vs. how many will use Java > development tools? That's not my point. My point is that people claim pushing to extras makes little to no difference to end users. If that *was* the case, why not pushing OOo there? It's a very big package, and nothing else depends on it. I'm not seriously advocating for us to do that, it's more of a thought experiment to point out the flaw in the argument of people who say `you can always get it from extras'. The point that OOo is a very big download offsets the higher costs of bandwidth and slower network connections in most of the world, so you can get an idea of how inconvenient it can be for most of the world to get to extras if it's not available in CDs like the core of the distro. The other annoyance with having to install packages from extras is that the install can have a significant number of drawbacks: - it's slower: anaconda/rpm can take a number of shortcuts when doing an install from scratch that they can't when the database is in a fully consistent state. - it pretty much requires network connection: you have to download packages, and unless you have them all already downloaded onto your box, and you have an alternate repo config to use them, you're out of luck if your network goes down - it requires far more storage: yum, up2date and all other depsolvers/installers first download all packages you need, then start installing them. So you need local space for the rpms plus space for the installed packages. Compare that with having the rpms in installable media, be it CD, DVD or a local NFS server. - longer down time: it requires at least one box to remain down while all packages that are not in the install media are downloaded, have deps solved and then installed, adding one more interactive step to the install, unlike the ideal model of `make all decisions, go', which means the box is fully operational as soon as it comes up. It means you can't start installing 50 boxes and go out to have dinner, you have to stay around until they get to the first boot, then do whatever amount of interaction it takes to get them functional, and by then restaurants will all be closed so you go straight home, hungry :-) The advantages? Can't really think of any. Mirrors will want to carry extras anyway. Not making them available as ISOs means they will get more requests for smaller files, which thrash their disks, and pushes people away from bittorrent et al. Users will be sad to find that their favorite apps are no longer available in the CD set they got in a magazine or on a store, and might not even realize they're still available in extras, *if* they have the network connection and the bandwidth to get to it. The DVD will be half-full instead of half-empty. Maybe that's a good one :-) FWIW, I don't have a DVD burner myself, and most if not all of my installs are over NFS; I have a reasonably fast and reliable network connection, but I happen to know the reality of most that live around. Just getting updates is a lot of trouble already. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Tue Feb 22 19:25:28 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Feb 2005 16:25:28 -0300 Subject: FC4 slimfast slimfest In-Reply-To: <20050222184552.GA1444243@hiwaay.net> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> Message-ID: On Feb 22, 2005, Chris Adams wrote: > That still assumes everyone has high-speed bandwidth available, which is > a broken assumption. If you think everyone should be downloading to get > most packages, why not make boot.iso the only distributed image and make > everything else downloaded? That "solves" all the CD/DVD count and > distribution issues. > I am disappointed that the setup for Fedora Extras is to just have a > rolling-update tree with no ISOs. That makes FE packages second class > citizens. How about rolling out ISOs of Fedora Extras *and* Core weekly or so, including all updates? This would address the issue of people who install FC3 now and then have to download an additional 1.5 CD just to get all of the available updates, then have them all installed overnight. If we keep the distribution of packages inside ISOs relatively stable, rsync (which all? mirrors use to get contents from the master server) would do a great job limiting the transferred data to the new packages, and perhaps even less than that, since rsync could then take advantage of similarities between the old version of the package and the new build. If we had tools to look into ISOs built into yum, then mirrors could even refrain from carrying the exploded trees. Just like yum 2.1 uses byte ranges to download the header portion of an rpm, it could extract rpms from isos. Failing that, there's always loopback mount or isoinfo. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From fedora-devel at camperquake.de Tue Feb 22 19:30:35 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 22 Feb 2005 20:30:35 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> Message-ID: <20050222203035.5f99b61d@nausicaa.camperquake.de> Hi. Alexandre Oliva wrote: > If we had tools to look into ISOs built into yum, then mirrors could > even refrain from carrying the exploded trees. Err, I am quite happy that I am able to download individual RPMs by hand, and I'd like to be able to continue to do so. If (and that's a big if) it is either the ISOs or the trees, I'd vote for the ISOs. Building an bit identical ISO file from scratch is relatively easy, jidgo has been mentioned several times. -- "This isn't all true." -- Steven Wright From notting at redhat.com Tue Feb 22 19:42:35 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Feb 2005 14:42:35 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> Message-ID: <20050222194235.GA25243@nostromo.devel.redhat.com> Alexandre Oliva (aoliva at redhat.com) said: > The point that OOo is a very big download offsets the higher costs of > bandwidth and slower network connections in most of the world, so you > can get an idea of how inconvenient it can be for most of the world to > get to extras if it's not available in CDs like the core of the > distro. Except... Core isn't available on CDs, except from third parties. I don't see a reason why Extras couldn't have ISOs made from it by those same third parties. Bill From fedora-devel at tlarson.com Tue Feb 22 19:43:11 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 22 Feb 2005 12:43:11 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <20050222184552.GA1444243@hiwaay.net> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> Message-ID: <421B8B4F.3020107@tlarson.com> Chris Adams wrote: > Once upon a time, Tyler Larson said: > >>However, I really like the idea of installing a base OS from just one CD >>and installing the rest of the system using yum or up2date. After all, most >>users will have to update the majority of the packages they've just >>installed immediately after their first boot. > > > That still assumes everyone has high-speed bandwidth available, which is > a broken assumption. I'm certainly not suggesting that EVERYONE needs to install that way. But it would be nice if it were easy to do. > I am disappointed that the setup for Fedora Extras is to just have a > rolling-update tree with no ISOs. That makes FE packages second class > citizens. That's a good point. There really SHOULD be a set of Extras ISOs available. Even if those ISOs are nothing more than a snapshot of the Extras tree at the time the release. And those extras SHOULD be installable from Anaconda/S-C-P -- even if they're put under a separate "Extras" heading. Moving packages to Extras is tantamount to removing them completely if those packages--to paraphrase Pirates of the Caribbean--"cannot be found except by those who know where they are." These things will have to be installable from a user-friendly interface. Otherwise, Extras is just another 3rd party repo. From skvidal at phy.duke.edu Tue Feb 22 19:45:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 14:45:20 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421B8B4F.3020107@tlarson.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <421B8B4F.3020107@tlarson.com> Message-ID: <1109101520.15038.40.camel@opus.phy.duke.edu> > That's a good point. There really SHOULD be a set of Extras ISOs available. > Even if those ISOs are nothing more than a snapshot of the Extras tree at the > time the release. And those extras SHOULD be installable from Anaconda/S-C-P > -- even if they're put under a separate "Extras" heading. > Then let's be completely clear. The only way isos are getting made from extras is if SOMEONE steps up and does them. We don't have time, period. we barely have time to do the infrastructure bits that we have to get done for fc4. so step up. do the work, then you can get what you want. -sv From notting at redhat.com Tue Feb 22 19:48:54 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Feb 2005 14:48:54 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> Message-ID: <20050222194854.GB25243@nostromo.devel.redhat.com> Alexandre Oliva (aoliva at redhat.com) said: > > I am disappointed that the setup for Fedora Extras is to just have a > > rolling-update tree with no ISOs. That makes FE packages second class > > citizens. > > How about rolling out ISOs of Fedora Extras *and* Core weekly or so, > including all updates? This would address the issue of people who > install FC3 now and then have to download an additional 1.5 CD just to > get all of the available updates, then have them all installed > overnight. OK, all that discussion of how 5 CDs is bad for mirrors? This is worse. Much worse. Even with rsync handling mirroring, you're doubling the bandwidth used for updates. Bill From cmadams at hiwaay.net Tue Feb 22 19:56:07 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 22 Feb 2005 13:56:07 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050222194235.GA25243@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> <20050222194235.GA25243@nostromo.devel.redhat.com> Message-ID: <20050222195607.GG1444243@hiwaay.net> Once upon a time, Bill Nottingham said: > Except... Core isn't available on CDs, except from third parties. I > don't see a reason why Extras couldn't have ISOs made from it > by those same third parties. Okay, then why does the Fedora Project provide ISO images of Core but not Extras? Also, see https://bugzilla.redhat.com/beta/show_bug.cgi?id=117647 - there is currently no way to verify the validity of third-party CD/DVD images since anaconda is not signed (the actual install run-time, not the RPMs). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jspaleta at gmail.com Tue Feb 22 19:59:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 14:59:15 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222194235.GA25243@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> <20050222194235.GA25243@nostromo.devel.redhat.com> Message-ID: <604aa7910502221159881d7f@mail.gmail.com> On Tue, 22 Feb 2005 14:42:35 -0500, Bill Nottingham wrote: > Except... Core isn't available on CDs, except from third parties. I > don't see a reason why Extras couldn't have ISOs made from it > by those same third parties. All you need is cookie-cutter instructions or an easy-bake tool.. and the legal room to brand them as Fedora Extras (and co-brand them) inside the trademark guidelines. "Fedora Extras CD 1 - 12 brought to you by cruftyrpms.net" has to be permissible under established trademark guidelines if the burden to produce isos is going to be thrown out to 3rd parties like cruftyrpms.net. My reading of the current trademark guidelines doesn't lend me to believe that 3rd parties have the ability to brand a locally spun up iso set as Fedora. -jef From roland at redhat.com Tue Feb 22 20:59:03 2005 From: roland at redhat.com (Roland McGrath) Date: Tue, 22 Feb 2005 12:59:03 -0800 Subject: glibc versioning In-Reply-To: Kjartan Maraas's message of Tuesday, 22 February 2005 16:57:52 +0100 <1109087873.8388.8.camel@localhost.localdomain> Message-ID: <200502222059.j1MKx3SW024354@magilla.sf.frob.com> > Tried compiling valgrind against the current glibc from CVS today and it > broke since glibc now defines __GLIBC_MINOR__ = 4 even though the > version is 2.3.x. Is this done on purpose or is it an oversight when > merging fixes from CVS? We'll be changing it in the next rawhide glibc build. From veillard at redhat.com Tue Feb 22 21:13:11 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 22 Feb 2005 16:13:11 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222112021.GA28474@devserv.devel.redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> Message-ID: <20050222211311.GS15979@redhat.com> On Tue, Feb 22, 2005 at 06:20:21AM -0500, Alan Cox wrote: > On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote: > > Brilliant idea. Solves all our problems, but creates a set of new one. > > Like, for example, what will the ISOs look like? > > CD #1 Download only this CD for a base install and use yum to add packages > CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs > via CD/DVD > > Java CD Optional Download for java packages > Games CD Optional Download for extra games Some people argued that mirror maintainers would complain about the extra space needed, from that angle I don't care too much about 500 extra MB (on the other hand if you could reduce the debuginfo packaging size in *some* ways !!!), but I do care about my bandwidth, and I prefer users picking the 3 ISO they really need instead of downloading the 4 ISO blindly because it is not identified clearly what will be needed. So from a mirror POV clearly labelled data chunks are better than one glob a bit smaller than the sum to me. From a distro user I also think clearly labelled ISO lead to less confusion and also nobody should face "Installation will need CD1 CD2 CD3 CD4" "Okay" "Reboot" and have to reboot/download/burn/restart because they forgot CD4, if CD4 is not available it should be marked as such somewhere and admin tools should suggest later on to insert the missing CDs if needed or download the packages. I'm not saying it is easy but it's the polish needed to try to get more desktop users IMHO. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jspaleta at gmail.com Tue Feb 22 21:23:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 16:23:55 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050222211311.GS15979@redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> Message-ID: <604aa79105022213234003daf6@mail.gmail.com> On Tue, 22 Feb 2005 16:13:11 -0500, Daniel Veillard wrote: > From a distro user I also think clearly labelled ISO lead to less > confusion and also nobody should face > "Installation will need CD1 CD2 CD3 CD4" > "Okay" "Reboot" Clearly labeled? what does that mean exactly? The only way to be sure you have the cds you need.. is to know exactly what is on each cd... package by package. You aren't going to break out things with easily digestable labels in such a way that makes sense to everyone. You have a KDE cd and a game cd... which cd has the kde game you want? Items can and will be intuitive members of multiple simple labels. You have a development tools cd and a java cd... which one intuitively has the development tools for java? And god forbid we ever see a java based game. The only way to be absolutely sure is to have a mechanism likr say a webpage.. people can go to before they download anything.. where they run through a mock install-time package selection session and that form spits out the isos they 'need' -jef From aoliva at redhat.com Tue Feb 22 21:33:01 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Feb 2005 18:33:01 -0300 Subject: FC4 slimfast slimfest In-Reply-To: <20050222194235.GA25243@nostromo.devel.redhat.com> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> <20050222194235.GA25243@nostromo.devel.redhat.com> Message-ID: On Feb 22, 2005, Bill Nottingham wrote: > Alexandre Oliva (aoliva at redhat.com) said: >> The point that OOo is a very big download offsets the higher costs of >> bandwidth and slower network connections in most of the world, so you >> can get an idea of how inconvenient it can be for most of the world to >> get to extras if it's not available in CDs like the core of the >> distro. > Except... Core isn't available on CDs, except from third parties. I > don't see a reason why Extras couldn't have ISOs made from it > by those same third parties. Third parties get the core isos from us. And they can't label it Fedora if it's not our ISOs. How could they take Fedora Extras and label it as such, especially if it's not the entire collection? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Tue Feb 22 21:35:45 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Feb 2005 18:35:45 -0300 Subject: FC4 slimfast slimfest In-Reply-To: <20050222194854.GB25243@nostromo.devel.redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <20050222194854.GB25243@nostromo.devel.redhat.com> Message-ID: On Feb 22, 2005, Bill Nottingham wrote: > Alexandre Oliva (aoliva at redhat.com) said: >> > I am disappointed that the setup for Fedora Extras is to just have a >> > rolling-update tree with no ISOs. That makes FE packages second class >> > citizens. >> >> How about rolling out ISOs of Fedora Extras *and* Core weekly or so, >> including all updates? This would address the issue of people who >> install FC3 now and then have to download an additional 1.5 CD just to >> get all of the available updates, then have them all installed >> overnight. > OK, all that discussion of how 5 CDs is bad for mirrors? This is worse. > Much worse. Even with rsync handling mirroring, you're doubling the > bandwidth used for updates. How so? Wouldn't you'd be downloading the updates only once, in the rolling ISOs? We already push most updates out on Monday mornings anyway, so we might as well push them out in batch in the form of ISOs. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From andy.grover at gmail.com Tue Feb 22 21:36:39 2005 From: andy.grover at gmail.com (Andrew Grover) Date: Tue, 22 Feb 2005 13:36:39 -0800 Subject: RPM needs to go on a diet. In-Reply-To: <20050217112257.755a4fc2@nausicaa.camperquake.de> References: <421413BB.3030106@nc.rr.com> <20050217112257.755a4fc2@nausicaa.camperquake.de> Message-ID: On Thu, 17 Feb 2005 11:22:57 +0100, Ralf Ertzinger wrote: > Hi. > > Jeff Johnson wrote: > > > Hardlinks's identical files to save space. > > Does this really pay off? I for one would be glad for a switch to disable > this. An option to disable this would be really nice. I have kernel sources in a bk repo, and some kernels built from these in grub.conf. Whenever hardlink runs, I guess it's hardlinking with the files in the bk repo, which are read-only (seems to be only Makefiles), and changing them to rw-r--r--. This causes bk to complain. Or is there something I could do to make this problem go away? Thanks -- Andy From fedora-devel at tlarson.com Tue Feb 22 21:51:00 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 22 Feb 2005 14:51:00 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <604aa79105022213234003daf6@mail.gmail.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> Message-ID: <421BA944.4010808@tlarson.com> Jeff Spaleta wrote: > On Tue, 22 Feb 2005 16:13:11 -0500, Daniel Veillard wrote: > >> From a distro user I also think clearly labelled ISO lead to less >>confusion and also nobody should face >> "Installation will need CD1 CD2 CD3 CD4" >> "Okay" "Reboot" > > > Clearly labeled? what does that mean exactly? The only way to be sure > you have the cds you need.. is to know exactly what is on each cd... > package by package. You aren't going to break out things with easily > digestable labels in such a way that makes sense to everyone. > Mandrake had (has?) a mechanism where, at the beginning of the installation, you'd tell the installer which CDs you have. The installer would then disable the package selections that weren't available with the selected CD set. I think such a solution would be good enough for most users, even with relatively vague labels on each CD. For the uber-curious, a listing of the RPMS directory posted on some server would be fine. The "OK, Reboot" solution is not really a solution at all. If you only have 3 CDs, the last thing you want to do is play "find the offending package", spending 20 minutes creating a package selection, partition scheme, and system setup; then find out that you still need CD4, and lather, reboot, repeat. From dwmw2 at infradead.org Tue Feb 22 21:50:46 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 21:50:46 +0000 Subject: Exim as default MTA. In-Reply-To: <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> Message-ID: <1109109046.30247.5.camel@localhost.localdomain> On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote: >I think exim still has potential to become our future default MTA. I agree. We really shouldn't be inflicting sendmail on newcomers as the default MTA. That's a far better candidate for going to Extras, for those who really want it because they've already suffered the brain damage its configuration inflicts. Exim would be a far better default, because it's far easier to configure and far better documented. In FC4 it ships with TLS enabled by default, and SMTP AUTH support present but commented out in the specfile. It also has built-in SpamAssassin support for rejecting spam at SMTP time, which again is enabled by merely uncommenting it in the specfile. I keep meaning to add more features there, like relaying all mail to a smarthost. If we reach a consensus on making the default, I'll make sure it all gets done. -- dwmw2 From michael.favia at insitesinc.com Tue Feb 22 21:54:38 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 22 Feb 2005 15:54:38 -0600 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <421BAA1E.4040006@insitesinc.com> Elliot Lee wrote: >Hi all, > >Here's a heads up that we need to get rid of about 300M of packages to >make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, >xemacs, cfengine, and all the games are leading candidates. We also may >try to start removing stuff from Core in hopes that it will appear in >Extras if someone cares about it. > >Nothing is set in stone, but if you want to write in favor of keeping >something, you'll have to suggest something else of equal or greater size >to axe instead. > >You can view the list of new packages since FC3 (sorted by package size) >at http://people.redhat.com/sopwith/new-packages.txt > >FYI, >-- Elliot > > > *Abridged Version* Developers can be expected to work a little harder to establish a working environment and have the knowledge skills and abilities to make that happen. Consumers neither know how nor want to know how to work the magic that makes everything the way they like it they would just like it done for them. Towards this goals improve the end user experience so that the developers continue to develop for a growing audience instead of a shrinking one. I don't know if this is possible on short niotice for FC4 but may be worth review for architecting fc5. Thank you and good luck. *Unabridged Version * this seems like a discussion that is held frequently and is always contentious. Instead of arguing the acceptability and merit of a particular package perhaps our time is better spent working up a rough framework of what our *specifications* are first. I think we are designing the perfect solution to the indescribable problem here. I would like to propose the following for consideration: New/Average consumers represent the least experienced and the largest growth segment for Fedora. They are most fickle in their adoption and most skeptical in their approach. Developers, server administrators and every other use case is commited to fedora for more substantial reasons in most cases (development model, release cycles, etc) and have the knowledge, skills and ability to take the time and perform and extra step to transform the default working environment into their desired mode. * New users that have little or no Linux experience seem to be interested in Fedora at an increasing rate. I argue that they will choose to adopt fedora if we make the dfeault environment as smooth as possible for these users who have no knowledge and arguably shoudl require no knowledge of repos and configuration files for things to Just Work. * Developers are basically knowledgable and communicative. If something is not as we expected we ask each other on IRC or in a mailing list or forum. We know how to configure repos and upgrade and install new packages. If we don't it can at least be argued that we should be able/required to learn. * Fedora adoption of both consumers and developers is a good thin and there are many more consumers than there are developers out there. * Fedora relies on developers and will do so at an increasing rate with the launch of fedora-extras No I'm not arguing to purposefully make life more difficult for developers. Instead i am arguing for the "greater good" created by the developers ease of overcoming simple deviations and how detrimental those same obstacles would be to the average/new user. To that end i am suggesting that the user runtime environments (including a java runtime that is differentiated from eclipse if they are currently bundled for some odd reason), default desktop , and default applications (office, web, file, mail, message) should take priority on the first CD['s] (including required desktop libs to satisfy default apps). Once the requirements for that are met than either place the alternatives on the next/remaining cd's followed by the development tools or vice versa depending on which user segment you think will benefit greater. -mf From dwmw2 at infradead.org Tue Feb 22 21:54:58 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 21:54:58 +0000 Subject: Exim as default MTA. In-Reply-To: <1109109046.30247.5.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> Message-ID: <1109109298.30247.7.camel@localhost.localdomain> On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote: >Exim would be a far better default, because it's far easier to configure >and far better documented. In FC4 it ships with TLS enabled by default, >and SMTP AUTH support present but commented out in the specfile. It also >has built-in SpamAssassin support for rejecting spam at SMTP time, which >again is enabled by merely uncommenting it in the specfile. Bah. s/specfile/config file/g -- dwmw2 From dpaun at rogers.com Tue Feb 22 21:55:17 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Tue, 22 Feb 2005 16:55:17 -0500 Subject: Exim as default MTA. In-Reply-To: <1109109046.30247.5.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> Message-ID: <20050222215517.GB25805@rogers.com> On Tue, Feb 22, 2005 at 09:50:46PM +0000, David Woodhouse wrote: > I keep meaning to add more features there, like relaying all mail to a > smarthost. If we reach a consensus on making the default, I'll make sure > it all gets done. I think we should go ahead and make it the default. It doesn't help anyone perpetuating sendmail as default, I don't think it's a long term option. Users that know how to control it, know where to get it from. -- Dimi. From mattdm at mattdm.org Tue Feb 22 21:57:45 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 22 Feb 2005 16:57:45 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <20050222194854.GB25243@nostromo.devel.redhat.com> Message-ID: <20050222215745.GA30788@jadzia.bu.edu> On Tue, Feb 22, 2005 at 06:35:45PM -0300, Alexandre Oliva wrote: > > OK, all that discussion of how 5 CDs is bad for mirrors? This is worse. > > Much worse. Even with rsync handling mirroring, you're doubling the > > bandwidth used for updates. > How so? Wouldn't you'd be downloading the updates only once, in the > rolling ISOs? We already push most updates out on Monday mornings > anyway, so we might as well push them out in batch in the form of > ISOs. So, wait, there'd be entirely new, small, iso images for each set of weekly updates? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From carwyn at carwyn.com Tue Feb 22 21:59:22 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Tue, 22 Feb 2005 21:59:22 +0000 Subject: Exim as default MTA. In-Reply-To: <1109109046.30247.5.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> Message-ID: <421BAB3A.1080406@carwyn.com> David Woodhouse wrote: >Exim would be a far better default > > How does the argument stack up against postfix? I've found postfix + procmail (optional) + dovecot + squirrelmail (optional) to be very easy to manage. I agree that sendmail is not something to inflict on people though. Carwyn From alan at redhat.com Tue Feb 22 22:00:21 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 22 Feb 2005 17:00:21 -0500 Subject: Exim as default MTA. In-Reply-To: <1109109046.30247.5.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> Message-ID: <20050222220021.GB23838@devserv.devel.redhat.com> On Tue, Feb 22, 2005 at 09:50:46PM +0000, David Woodhouse wrote: > Exim would be a far better default, because it's far easier to configure > and far better documented. In FC4 it ships with TLS enabled by default, > and SMTP AUTH support present but commented out in the specfile. It also I must disagree. If the user has to know what the mail system is you've already failed the main usability test for "the general user". If they know what they are doing then they probably have an opinion already and a preferred app, and can also work yum/up2date. The point at which you start saying things like "we should use sendmail" with that kind of user I think personally is the point at which you ship xyz mailer because the GUI configuration tool supports it seamlessly From dwmw2 at infradead.org Tue Feb 22 22:10:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 22:10:17 +0000 Subject: Exim as default MTA. In-Reply-To: <421BAB3A.1080406@carwyn.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> Message-ID: <1109110217.30247.19.camel@localhost.localdomain> On Tue, 2005-02-22 at 21:59 +0000, Carwyn Edwards wrote: >How does the argument stack up against postfix? I've found postfix + >procmail (optional) + dovecot + squirrelmail (optional) to be very easy >to manage. I haven't had that much experience of postfix. On the occasions I've looked at its configuration I've found it far more difficult than Exim but that's partly because I'm familiar with Exim's configuration so I find it hard to judge. I'm also somewhat put off postfix by the fact that even the postfix 'experts' who insist on using it freedesktop.org were completely unable to make it route mail properly to a domain with an IPv6-only primary MX. Possibly something to do with the recent 'open relay' erratum for postfix. The thing that really tips the balance, though, is the documentation. As I said, it's the best documentation I've ever seen for a Free Software project. Set yourself a few common tasks which a basic Fedora sysadmin might want to do, and have a play with http://www.exim.org/exim-html-4.40/doc/html/spec.html and http://www.exim.org/exim-html-4.40/doc/html/FAQ.html -- dwmw2 From dwmw2 at infradead.org Tue Feb 22 22:10:32 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 22:10:32 +0000 Subject: Exim as default MTA. In-Reply-To: <20050222220021.GB23838@devserv.devel.redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <20050222220021.GB23838@devserv.devel.redhat.com> Message-ID: <1109110232.30247.20.camel@localhost.localdomain> On Tue, 2005-02-22 at 17:00 -0500, Alan Cox wrote: >I must disagree. If the user has to know what the mail system is you've >already failed the main usability test for "the general user". If they know >what they are doing then they probably have an opinion already and a preferred >app, and can also work yum/up2date. > >The point at which you start saying things like "we should use sendmail" with >that kind of user I think personally is the point at which you ship xyz >mailer because the GUI configuration tool supports it seamlessly You haven't been watching #fedora much recently, have you? I'm far more adamant about "it shouldn't be sendmail" than "it should be exim" but sendmail definitely needs to go, and on balance I think Exim would make a better choice than Postfix, because it's so much better documented. -- dwmw2 From jspaleta at gmail.com Tue Feb 22 22:29:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Feb 2005 17:29:20 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421BA944.4010808@tlarson.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> <421BA944.4010808@tlarson.com> Message-ID: <604aa791050222142956f5fb85@mail.gmail.com> On Tue, 22 Feb 2005 14:51:00 -0700, Tyler Larson wrote: > > I think such a solution would be good enough for most users, even with > relatively vague labels on each CD. For the uber-curious, a listing of the > RPMS directory posted on some server would be fine. There are 2 different but related problems. 1) Making sure users have the disks they need for what they want. 2) Making sure the installer doesn't let users try to install items don't have the disks for. (assuming of course a non-networked install) The solution you propose addresses problem 2. Whether or not its good enough for 'most' users is an open question. This solution supposes that the default package selection isn't good enough for most users. If most users are customizing the package selection at install time, i would argue they do so with specific items in mind and not finding what they are looking for would be as frustrating as being told to get extra cds. I think you would have to make absolutely clear that certain packages aren't available at install time because they do not have the full media set, so the user knows the missing crap can be installed later after firstboot from media or from the network. Even then.. solving problem 1.. prevents this all together. -jef From carwyn at carwyn.com Tue Feb 22 22:33:51 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Tue, 22 Feb 2005 22:33:51 +0000 Subject: Exim as default MTA. In-Reply-To: <1109110217.30247.19.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> Message-ID: <421BB34F.6050102@carwyn.com> David Woodhouse wrote: >On the occasions I've looked at its configuration I've found it far more >difficult than Exim > > About a two years ago I sat down to evaluate an MTA to replace sendmail - I specifically chose postfix because it was simpler to configure from the point of view of transitioning from sendmail. Carwyn From fedora-devel at tlarson.com Tue Feb 22 22:53:18 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 22 Feb 2005 15:53:18 -0700 Subject: FC4 slimfast slimfest In-Reply-To: <604aa791050222142956f5fb85@mail.gmail.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> <421BA944.4010808@tlarson.com> <604aa791050222142956f5fb85@mail.gmail.com> Message-ID: <421BB7DE.7060408@tlarson.com> Jeff Spaleta wrote: > On Tue, 22 Feb 2005 14:51:00 -0700, Tyler Larson > wrote: > > There are 2 different but related problems. > 1) Making sure users have the disks they need for what they want. > 2) Making sure the installer doesn't let users try to install items > don't have the disks for. (assuming of course a non-networked install) > > [...] > > installed later after firstboot from media or from the network. Even > then.. solving problem 1.. prevents this all together. > > -jef > True, but as you pointed out, solving problem 1 is a difficult task. And then, even with a sophisticated CD-selection web application, you can rest assured that most people won't use it. They'll get the CDs from their friends, or from their network administrator, or they'll just download all of the ones they think they might use, just in case. My opinion is that we solve problem 2 ('cause it need solving anyway), and give some general guidelines for problem 1 (e.g. I would certainly not download a Java CD). From rms at 1407.org Tue Feb 22 22:06:23 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 22 Feb 2005 22:06:23 +0000 Subject: Exim as default MTA. In-Reply-To: <1109109046.30247.5.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> Message-ID: <1109109984.3714.1.camel@roque> On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote: >On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote: >>I think exim still has potential to become our future default MTA. > >I agree. We really shouldn't be inflicting sendmail What shouldn't be inflicted upon the users is bugware. Exim isn't particularly famous (in a good way) as far as MTAs go in terms of security. I would favour postfix, under this POV, but of course if features is the chosen way, Exim might be your choice. 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 dwmw2 at infradead.org Tue Feb 22 23:05:37 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 23:05:37 +0000 Subject: Exim as default MTA. In-Reply-To: <421BB34F.6050102@carwyn.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> Message-ID: <1109113537.30247.31.camel@localhost.localdomain> On Tue, 2005-02-22 at 22:33 +0000, Carwyn Edwards wrote: >About a two years ago I sat down to evaluate an MTA to replace sendmail >- I specifically chose postfix because it was simpler to configure from >the point of view of transitioning from sendmail. Given that sendmail is widely acknowledged to cause brain damage, that is hardly a resounding endorsement. :) Seriously though, I'm not sure it's a criterion we're interested in. We should be interested in what's easy to use for someone who's entirely new to it. If they're already running sendmail, they can continue to use sendmail -- and if they don't want to do so, they can make a choice about what to replace it with. Our default should be what's best for the newbie; not for the sendmail victim in recovery. I think Alan's wrong to suggest that there's no middle ground between caring about how easy stuff is to configure, and needing a complete point-and-drool configuration GUI for it. We don't _have_ a GUI configuration tool for any MTA, but we do have a web browser and the excellent and fully indexed Exim documentation, and a bunch of useful default features commented out but ready to use in the default config file. -- dwmw2 From ken at bonsai.com Tue Feb 22 23:09:08 2005 From: ken at bonsai.com (Ken Sedgwick) Date: Tue, 22 Feb 2005 15:09:08 -0800 Subject: Self-Introduction: Ken Sedgwick In-Reply-To: <1108589052.5668.7.camel@localhost.localdomain> References: <421385DE.3060503@bonsai.com> <1108589052.5668.7.camel@localhost.localdomain> Message-ID: <421BBB94.5060502@bonsai.com> Jules Colding wrote: > On Wed, 2005-02-16 at 09:41 -0800, Ken Sedgwick wrote: > >>5. My immediate goal in the Fedora Project is to publish the ACE and >>~ TAO packages. >> >>~ Official ACE Site http://www.cs.wustl.edu/~schmidt/ACE.html >> >>~ Official TAO Site http://www.cs.wustl.edu/~schmidt/TAO.html > > > I for one would love to see ACE and TAO in Fedora Extras. > > Info for the uninitiated: ACE is a *very* versatile C++ wrapper > framework. It has platform wrappers for threads, networking, loggin and > everything you could possibly think of. Think of ACE as glib on > steroids. TAO is a very complete CORBA implementation with C++ bindings > build upon ACE. > I've submitted the ACE+TAO source rpm in the QA queue per the directions and requirements in the Wiki. I'd appreciate feedback/guidance; I'm a little unsure what is supposed to happens next ... Would it help for me to QA check other submitted packages? Am I qualified to do this? How do I tell which packages are most important to do next? Many thanks in advance ... Ken -- Ken Sedgwick Bonsai Software, Inc. (510) 610-4162 ken+5a4 at bonsai.com From dwmw2 at infradead.org Tue Feb 22 23:15:00 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 23:15:00 +0000 Subject: Exim as default MTA. In-Reply-To: <1109109984.3714.1.camel@roque> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> Message-ID: <1109114101.30247.37.camel@localhost.localdomain> On Tue, 2005-02-22 at 22:06 +0000, Rui Miguel Seabra wrote: >Exim isn't particularly famous (in a good way) as far as MTAs go in >terms of security. Exim has fairly good record. There's not really a lot of difference between it and postfix from this POV. In fact even sendmail hasn't been so bad recently as it used to be, but postfix and exim are probably still ahead. It was Postfix which had the most recent erratum for the open relay thing, wasn't it? It's ease of use and documentation which tips the balance, I think. -- dwmw2 From lists at donut.dk Tue Feb 22 23:20:47 2005 From: lists at donut.dk (Cream) Date: Wed, 23 Feb 2005 00:20:47 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109101520.15038.40.camel@opus.phy.duke.edu> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <421B8B4F.3020107@tlarson.com> <1109101520.15038.40.camel@opus.phy.duke.edu> Message-ID: <421BBE4F.1090009@donut.dk> So, A simple menu driven download & burn program, that lets you browse a yum repository, could be like selecting individual packages in anaconda, you could even have it check dependencies, and download those aswell. And then burn your selection to a cd/dvd. (possibly spanning several cd's) Then a set of "yum cd-list/cd-install/cd-etc.." commands to access your newly homebuilt yum-repository-on-a-cd. That way you can build your own up to date extra's cd, and go deploy it offline. And it would be easy to imagine: - a shiny X manager/installer - online cd sellers that would let you mix your own Extra's packages cd, burn and ship it to you, or burn-to-order updated everything-included-dvd's an idea? From plazonic at Math.Princeton.EDU Tue Feb 22 23:38:04 2005 From: plazonic at Math.Princeton.EDU (Josko Plazonic) Date: Tue, 22 Feb 2005 18:38:04 -0500 Subject: Exim as default MTA. In-Reply-To: <1109114101.30247.37.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> Message-ID: <421BC25C.9030703@math.princeton.edu> David Woodhouse wrote: > still ahead. It was Postfix which had the most recent erratum for the > open relay thing, wasn't it? Not really true, it was a 3rd party patch that Ubuntu chose to integrate. This was sent to bugtraq by Wietse Venema: > FYI, > > This is a bug in a third-party IPv6 patch that is not part of Postfix. > > Neither the official Postfix release, nor the work-in-progress > version are not affected by this. > > Wietse Josko P. From Lam at Lam.pl Tue Feb 22 23:39:25 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 00:39:25 +0100 Subject: kde-3.4 (3.3.92) in fc4 In-Reply-To: <421B44B8.4070603@redhat.com> References: <421B3A3B.1070100@math.unl.edu> <421B44B8.4070603@redhat.com> Message-ID: <1109115565.9858.23.camel@pensja.lam.pl> Dnia 22-02-2005, wto o godzinie 15:42 +0100, Than Ngo napisa?(a): > i'm still waiting for KDE-3.4 RC1, which will be released on Feb 22. Which year? It's Feb 23 already (in KDE TZ too, latest news are "Posted by Philip Rodrigues on Tuesday 22/Feb/2005, @23:56") :) Lam From tdiehl at rogueind.com Tue Feb 22 23:44:34 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 22 Feb 2005 18:44:34 -0500 (EST) Subject: Exim as default MTA. In-Reply-To: <1109114101.30247.37.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> Message-ID: On Tue, 22 Feb 2005, David Woodhouse wrote: > On Tue, 2005-02-22 at 22:06 +0000, Rui Miguel Seabra wrote: > >Exim isn't particularly famous (in a good way) as far as MTAs go in > >terms of security. > > Exim has fairly good record. There's not really a lot of difference > between it and postfix from this POV. In fact even sendmail hasn't been > so bad recently as it used to be, but postfix and exim are probably > still ahead. It was Postfix which had the most recent erratum for the > open relay thing, wasn't it? No, not really. It was a third party patch added by some distros to their version of postfix. It was not included in the upstream code. > It's ease of use and documentation which tips the balance, I think. Have you looked at the postfix docs lately? I cannot comment on Exim at all, since I have never used it but the docs here: http://www.postfix.org/documentation.html seem pretty good to me. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From dwmw2 at infradead.org Tue Feb 22 23:47:30 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 23:47:30 +0000 Subject: Exim as default MTA. In-Reply-To: <421BC25C.9030703@math.princeton.edu> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <421BC25C.9030703@math.princeton.edu> Message-ID: <1109116050.30247.39.camel@localhost.localdomain> On Tue, 2005-02-22 at 18:38 -0500, Josko Plazonic wrote: >Not really true, it was a 3rd party patch that Ubuntu chose to >integrate. This was sent to bugtraq by Wietse Venema: Ah, OK. Does the postfix we ship not support IPv6 then? That's definitely a point against it. -- dwmw2 From csm at redhat.com Tue Feb 22 23:50:30 2005 From: csm at redhat.com (Chuck Mead) Date: Tue, 22 Feb 2005 18:50:30 -0500 Subject: Exim as default MTA. In-Reply-To: <1109116050.30247.39.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <421BC25C.9030703@math.princeton.edu> <1109116050.30247.39.camel@localhost.localdomain> Message-ID: <421BC546.8030304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Woodhouse wrote: | On Tue, 2005-02-22 at 18:38 -0500, Josko Plazonic wrote: | |>Not really true, it was a 3rd party patch that Ubuntu chose to |>integrate. This was sent to bugtraq by Wietse Venema: | | | Ah, OK. Does the postfix we ship not support IPv6 then? That's | definitely a point against it. * Mon Oct 04 2004 Thomas Woerner 2:2.1.5-1 - - new version 2.1.5 - - new ipv6 and tls+ipv6 patches: 1.25-pf-2.1.5 - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG8VGZfy0juH51WsRAiAuAJ0V9iPWTKbkC0nmuApJb37LGMmSMACdExGP ejFZ7oYUmnVyIktQcBuUohs= =7489 -----END PGP SIGNATURE----- From dwmw2 at infradead.org Tue Feb 22 23:52:25 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Feb 2005 23:52:25 +0000 Subject: Exim as default MTA. In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> Message-ID: <1109116346.30247.45.camel@localhost.localdomain> On Tue, 2005-02-22 at 18:44 -0500, Tom Diehl wrote: > >Have you looked at the postfix docs lately? I cannot comment on Exim at >all, since I have never used it but the docs here: >http://www.postfix.org/documentation.html seem pretty good to me. That looks a lot better than I remember. Certainly sendmail should go -- if our postfix actually supports IPv6 completely and can do the other things like SpamAssassin on incoming mail at SMTP time, then I can't see a lot to choose either way between it and Exim, although I'd personally lean towards Exim. -- dwmw2 From csm at redhat.com Tue Feb 22 23:57:54 2005 From: csm at redhat.com (Chuck Mead) Date: Tue, 22 Feb 2005 18:57:54 -0500 Subject: Exim as default MTA. In-Reply-To: <1109116346.30247.45.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> Message-ID: <421BC702.1010101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Woodhouse wrote: | On Tue, 2005-02-22 at 18:44 -0500, Tom Diehl wrote: | |>Have you looked at the postfix docs lately? I cannot comment on Exim at |>all, since I have never used it but the docs here: |>http://www.postfix.org/documentation.html seem pretty good to me. | | | That looks a lot better than I remember. Certainly sendmail should go -- | if our postfix actually supports IPv6 completely and can do the other | things like SpamAssassin on incoming mail at SMTP time, then I can't see | a lot to choose either way between it and Exim, although I'd personally | lean towards Exim. ~From my master.cf file: spamassassin unix - n n - - pipe flags=Rq user=mail argv=/usr/local/bin/safilter.sh -f ${sender} ${recipient} - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG8cCZfy0juH51WsRAq4cAJ9HJPNdSL/p7GWssQNOgr974Kq2nwCdGYUJ AnCzxjmS70qsVXeuxH23S5M= =QBSt -----END PGP SIGNATURE----- From dwmw2 at infradead.org Wed Feb 23 00:11:00 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 00:11:00 +0000 Subject: Exim as default MTA. In-Reply-To: <421BC702.1010101@redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> <421BC702.1010101@redhat.com> Message-ID: <1109117460.30247.56.camel@localhost.localdomain> On Tue, 2005-02-22 at 18:57 -0500, Chuck Mead wrote: >spamassassin unix - n n - - pipe flags=Rq user=mail >argv=/usr/local/bin/safilter.sh -f ${sender} ${recipient} And how do you control the threshold at which it actually rejects the mail for the failure? The equivalent of this part of Fedora's default exim.conf and my http://david.woodhou.se/eximconf/include/acl-content, for example: # Reject spam messages with score over 10, using an extra condition. deny message = This message scored $spam_score points. Congratulations! spam = nobody:true condition = ${if >{$spam_score_int}{100} {1}} For that matter, can it do the rest of what's in that ACL? And can it do what's in acl-helo and acl-helo-csv? Some of those, particularly the CSV bit, aren't good examples of "simple" configuration -- they're the baroque stuff I did when I was bored and felt like improving my mailer configuration. But they're good examples of "versatile". -- dwmw2 From breeze at smsonline.com Wed Feb 23 00:06:30 2005 From: breeze at smsonline.com (Bill Rees) Date: Tue, 22 Feb 2005 16:06:30 -0800 Subject: fc3 install hangs at "configuring kernel parameters" In-Reply-To: <421BBE4F.1090009@donut.dk> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <421B8B4F.3020107@tlarson.com> <1109101520.15038.40.camel@opus.phy.duke.edu> <421BBE4F.1090009@donut.dk> Message-ID: <421BC906.3010907@smsonline.com> Hi All, I've tried installing FC3 several times with differing setups and for each install, the final reboot hangs right as "configuring kernel parameters" prints out. What is going on at this stage and what may be the problem? I've done one FC3 install before on the same motherboard (shuttle AK32v3.1) that worked just fine. The only difference I can see is the processor is different (faster). Any thoughts anyone? I'm going to try a live cd image boot and replace the kernel with a 2.6.8 variant and see if that makes any difference. Bill Rees Nascar Sillicon Motor Speedway From fedora at wir-sind-cool.org Wed Feb 23 00:12:09 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 23 Feb 2005 01:12:09 +0100 Subject: Self-Introduction: Ken Sedgwick In-Reply-To: <421BBB94.5060502@bonsai.com> References: <421385DE.3060503@bonsai.com> <1108589052.5668.7.camel@localhost.localdomain> <421BBB94.5060502@bonsai.com> Message-ID: <20050223011209.726bd942.fedora@wir-sind-cool.org> On Tue, 22 Feb 2005 15:09:08 -0800, Ken Sedgwick wrote: > I've submitted the ACE+TAO source rpm in the QA queue per the directions > and requirements in the Wiki. > > I'd appreciate feedback/guidance; I'm a little unsure what is supposed > to happens next ... > > Would it help for me to QA check other submitted packages? Am I > qualified to do this? How do I tell which packages are most important > to do next? > > Many thanks in advance ... > > Ken > Guidance... Okay, let's see. Here are some random brain dumps: The old fedora.us project is dying a slow death. For some reason you've managed to ignore the warnings on the front page of the website and the wiki, that it's only kept alive for extras for FC2 and older. ;) The Fedora Project has moved on to "Fedora Extras" and is creating new package submission and QA guidelines from scratch. Well, experience from the old fedora.us procedures is taken into consideration. But so far, there is no well-defined package submission process for Fedora Extras. Instead, an "Interim New Package Process" is in use and has been used several times already: https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00208.html With Fedora Extras comes different infrastructure, too: - http://bugzilla.redhat.com instead of bugzilla.fedora.us - http://download.fedora.redhat.com/pub/fedora/linux/extras/ instead of download.fedora.us - http://fedoraproject.org/wiki instead of fedora.us/wiki Sure, some of the old package submissions in bugzilla.fedora.us are still processed, and others keep being work-in-progress. But bugzilla.fedora.us is just not the intended place where to submit a package for Fedora Extras anymore. Unless your submission is approved in accordance with the old fedora.us policies, don't expect quick feedback there. The interim new package process linked above currently is the way how to advertise your packages and seek for a package sponsor. No other package submission policies and infrastructure are in place yet. And yes, posting to fedora-extras-list bears the risk that, if nobody has immediate interest in sponsoring your package, the request is not handled. From csm at redhat.com Wed Feb 23 00:17:18 2005 From: csm at redhat.com (Chuck Mead) Date: Tue, 22 Feb 2005 19:17:18 -0500 Subject: Exim as default MTA. In-Reply-To: <1109117460.30247.56.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> <421BC702.1010101@redhat.com> <1109117460.30247.56.camel@localhost.localdomain> Message-ID: <421BCB8E.9020606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Woodhouse wrote: | On Tue, 2005-02-22 at 18:57 -0500, Chuck Mead wrote: | |>spamassassin unix - n n - - pipe flags=Rq user=mail |>argv=/usr/local/bin/safilter.sh -f ${sender} ${recipient} | | | And how do you control the threshold at which it actually rejects the | mail for the failure? The equivalent of this part of Fedora's default | exim.conf and my http://david.woodhou.se/eximconf/include/acl-content, | for example: | | # Reject spam messages with score over 10, using an extra condition. | deny message = This message scored $spam_score points. Congratulations! | spam = nobody:true | condition = ${if >{$spam_score_int}{100} {1}} | | For that matter, can it do the rest of what's in that ACL? And can it do | what's in acl-helo and acl-helo-csv? | | Some of those, particularly the CSV bit, aren't good examples of | "simple" configuration -- they're the baroque stuff I did when I was | bored and felt like improving my mailer configuration. But they're good | examples of "versatile". Well... it ain't that complicated... :-) #!/bin/bash /usr/bin/spamc | /usr/sbin/sendmail -i "$@" exit $? - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG8uOZfy0juH51WsRAuZKAJ94XXdQxctVMFyW9sKEBV3qejRxVwCgoc4N zalHCvTBUHzdjwtbl+TcN50= =082h -----END PGP SIGNATURE----- From esm at logic.net Tue Feb 22 17:04:49 2005 From: esm at logic.net (esm at logic.net) Date: Tue, 22 Feb 2005 11:04:49 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <604aa791050221130614784876@mail.gmail.com> References: <421A4A7C.3000002@bluga.net> <604aa791050221130614784876@mail.gmail.com> Message-ID: <20050222170448.GA31206@talus.logic.net> On Mon, Feb 21, 2005 at 04:06:27PM -0500, Jeff Spaleta wrote: > On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn wrote: > > It would be a shame to lose gnome-games, every computer needs easy > > access to solitaire. > > why? so office workers can be less productive? I'll tackle this one. There's very few other applications provided by an operating system that are both fun/engaging, and a good learning tool for most of the basic actions that a mouse requires. After seeing my 73-year-old mother go from "what do you mean, drag it?" to double clicking like she was born at a computer in a couple of days of playing solitaire, I'm sold on it: it's an ingenious tool for teaching how to use the mouse that doesn't bore the hell out of the student. Does Fedora need all of gnome-games? No, that's just silly. But a few basic games which emphasize the range of mouse interactions with the system widget set should be there, IMHO. -- Edward S. Marshall http://esm.logic.net/ Felix qui potuit rerum cognoscere causas. From dwmw2 at infradead.org Wed Feb 23 00:20:53 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 00:20:53 +0000 Subject: Exim as default MTA. In-Reply-To: <421BCB8E.9020606@redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> <421BC702.1010101@redhat.com> <1109117460.30247.56.camel@localhost.localdomain> <421BCB8E.9020606@redhat.com> Message-ID: <1109118053.30247.64.camel@localhost.localdomain> On Tue, 2005-02-22 at 19:17 -0500, Chuck Mead wrote: >Well... it ain't that complicated... :-) > >#!/bin/bash >/usr/bin/spamc | /usr/sbin/sendmail -i "$@" >exit $? Oh, I see. It looks like the old hacks for reintroducing mail into Exim after SA checking then, before proper SA support was merged. -- dwmw2 From csm at redhat.com Wed Feb 23 00:24:35 2005 From: csm at redhat.com (Chuck Mead) Date: Tue, 22 Feb 2005 19:24:35 -0500 Subject: Exim as default MTA. In-Reply-To: <1109118053.30247.64.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> <421BC702.1010101@redhat.com> <1109117460.30247.56.camel@localhost.localdomain> <421BCB8E.9020606@redhat.com> <1109118053.30247.64.camel@localhost.localdomain> Message-ID: <421BCD43.6060108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Woodhouse wrote: | On Tue, 2005-02-22 at 19:17 -0500, Chuck Mead wrote: | |>Well... it ain't that complicated... :-) |> |>#!/bin/bash |>/usr/bin/spamc | /usr/sbin/sendmail -i "$@" |>exit $? | | | Oh, I see. It looks like the old hacks for reintroducing mail into Exim | after SA checking then, before proper SA support was merged. Prolly... I do most of my work at the SMTP port via mime_header_checks and other regexp/pcre stuff anyway. SA is a very small part of what I do. :-) - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG81DZfy0juH51WsRAr2HAJ0dcVx9cyBudWZgm0XUo1Bb2EesrgCglRJ+ i8r/Rfs0RP73u7nRWdqOflA= =xKzT -----END PGP SIGNATURE----- From notting at redhat.com Wed Feb 23 00:30:08 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Feb 2005 19:30:08 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <20050222194854.GB25243@nostromo.devel.redhat.com> Message-ID: <20050223003008.GE27227@nostromo.devel.redhat.com> Alexandre Oliva (aoliva at redhat.com) said: > > OK, all that discussion of how 5 CDs is bad for mirrors? This is worse. > > Much worse. Even with rsync handling mirroring, you're doubling the > > bandwidth used for updates. > > How so? Wouldn't you'd be downloading the updates only once, in the > rolling ISOs? Wait, you want to push them *only* as ISOs? That breaks every tool out there right now, and destroys the point of the metadata. > We already push most updates out on Monday mornings anyway No, we don't. Bill From ken at bonsai.com Wed Feb 23 00:33:08 2005 From: ken at bonsai.com (Ken Sedgwick) Date: Tue, 22 Feb 2005 16:33:08 -0800 Subject: Self-Introduction: Ken Sedgwick In-Reply-To: <20050223011209.726bd942.fedora@wir-sind-cool.org> References: <421385DE.3060503@bonsai.com> <1108589052.5668.7.camel@localhost.localdomain> <421BBB94.5060502@bonsai.com> <20050223011209.726bd942.fedora@wir-sind-cool.org> Message-ID: <421BCF44.4080104@bonsai.com> Michael Schwendt wrote: > Guidance... Okay, let's see. Here are some random brain dumps: > > The old fedora.us project is dying a slow death. For some reason > you've managed to ignore the warnings on the front page of the > website and the wiki, that it's only kept alive for extras for FC2 > and older. ;) Wow! Glad I asked! Thank you for pointing me in the right direction! Unfortunately someone had given me links to *inside* the website ... so I don't think I ever encountered the front page ... Ken -- Ken Sedgwick Bonsai Software, Inc. (510) 610-4162 ken+5a4 at bonsai.com From ken at bonsai.com Wed Feb 23 00:43:39 2005 From: ken at bonsai.com (Ken Sedgwick) Date: Tue, 22 Feb 2005 16:43:39 -0800 Subject: Sponsor needed for ACE+TAO package Message-ID: <421BD1BB.8080001@bonsai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I'm looking for a sponsor for the inclusion of the ACE+TAO libraries into Fedora Extras. Official ACE Site http://www.cs.wustl.edu/~schmidt/ACE.html Official TAO Site http://www.cs.wustl.edu/~schmidt/TAO.html My package site: http://dist.bonsai.com/ken/ace_tao_rpm/ Source RPM: http://dist.bonsai.com/ken/ace_tao_rpm/5.4.4-2.SRC/ace+tao-5.4.4-2.src.rpm There are no legal issues: http://www.cs.wustl.edu/~schmidt/ACE-copying.html I believe that the source rpm and generated packages meet the Fedora packaging guidelines as posted on the wiki. Ken - -- Ken Sedgwick Bonsai Software, Inc. (510) 610-4162 ken+5a4 at bonsai.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCG9G6QDM7mz8/lkARAr4UAJ9dAu3V16BTtPEljnw6yJOFvVyfWACaArJy 3MB1UEfZFRHit2gRmFvJYrQ= =0DVI -----END PGP SIGNATURE----- From cs at zip.com.au Wed Feb 23 01:03:11 2005 From: cs at zip.com.au (Cameron Simpson) Date: Wed, 23 Feb 2005 12:03:11 +1100 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: <20050223010311.GA21564@cskk.homeip.net> On 15:35 21 Feb 2005, Elliot Lee wrote: | Here's a heads up that we need to get rid of about 300M of packages to | make sure that FC4 continues to fit on 4 CD's. Something of an arbitrary limit, yes? The "we don't need lots of apps to do the same thing" I can see, but this one? | Right now eclipse, xfce, | xemacs, cfengine, and all the games are leading candidates. We also may | try to start removing stuff from Core in hopes that it will appear in | Extras if someone cares about it. Um, can't you "push it into extras and hope someone maintains it" instead of this "drop it on the floor and hope someone picks it up and puts it on another shelf" thing? -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Prepare thy ablutions, worship the bean, and shun the abomination that is decaf, and one day you too shall walk among the Blessd, whose blood flows thick and brown with God's Chemical and whose hearts have been replaced with the more efficient mechanism of a Mr. Coffee. - Keith Morris From jwboyer at jdub.homelinux.org Wed Feb 23 01:18:06 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 22 Feb 2005 19:18:06 -0600 Subject: Exim as default MTA. In-Reply-To: <1109113537.30247.31.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> Message-ID: <1109121487.17468.13.camel@jdub.homelinux.org> On Tue, 2005-02-22 at 23:05 +0000, David Woodhouse wrote: > On Tue, 2005-02-22 at 22:33 +0000, Carwyn Edwards wrote: > >About a two years ago I sat down to evaluate an MTA to replace sendmail > >- I specifically chose postfix because it was simpler to configure from > >the point of view of transitioning from sendmail. > > Given that sendmail is widely acknowledged to cause brain damage, that > is hardly a resounding endorsement. :) > > Seriously though, I'm not sure it's a criterion we're interested in. > > We should be interested in what's easy to use for someone who's entirely > new to it. If they're already running sendmail, they can continue to use > sendmail -- and if they don't want to do so, they can make a choice > about what to replace it with. Ok, I consider myself a "newbie" when it comes to MTAs. I currently run sendmail, but I've done as little as possible to get it working. I have no spam filtering at SMTP, no auto-sorting of messages into folders, basically nothing more than "get the mail to the spool". Why? Because sendmail frightens me, I'm lazy, and what I have now basically "works" and I don't want to break anything. Now if exim can be used as a drop in replacement with just a bit of tweaking for site specific stuff, great. If I can enable some of the features I'd like by uncommenting a few options in the default config, even better. So I'll bite and look at the latest exim package in FC3 (I am running a server, so I can't really use rawhide). I'd be glad to report how it goes if anyone is interested. > I think Alan's wrong to suggest that there's no middle ground between > caring about how easy stuff is to configure, and needing a complete > point-and-drool configuration GUI for it. We don't _have_ a GUI > configuration tool for any MTA, but we do have a web browser and the > excellent and fully indexed Exim documentation, and a bunch of useful > default features commented out but ready to use in the default config > file. As a newbie, I don't really care about a GUI either. As long as the documentation is easily accessible and the package provides sane defaults, I don't see the need for a GUI. Realistically, it would probably only be used once to setup the mail server initially. After that, it'd just sit there on the hard drive taking up space. Newbies have a tendency not to remove anything, whether it's being used or note. josh From rodd at clarkson.id.au Wed Feb 23 01:19:25 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 23 Feb 2005 12:19:25 +1100 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> Message-ID: <1109121565.4609.26.camel@localhost.localdomain> While updating to the current rawhide I'm getting lots of errors (scriptlets failing) running: sudo yum update. I run this every morning, so the system was 'synced' with rawhide yesterday. Interesting to note that it claims to have installed (or updated packages) even though earlier output said that it wasn't going to try. For example, the kernel package. During install: error: %pre(kernel-2.6.10-1.1149_FC4.i686) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kernel-2.6.10-1.1149_FC4 After the install: Installed: kernel-devel.i686 0:2.6.10-1.1149_FC4 kernel.i686 0:2.6.10-1.1149_FC4 Something is not right here. ;-] Rodd Here's the output from yum: [rodd at localhost plugins]$ sudo yum update Password: Setting up Update Process Setting up Repos development 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files developmen: ################################################## 3752/3752 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package tetex-dvips.i386 0:3.0-2 set to be updated ---> Package ghostscript.i386 0:7.07-38 set to be updated ---> Package openssh-clients.i386 0:3.9p1-11 set to be updated ---> Package gnome-desktop-devel.i386 0:2.9.91-2 set to be updated ---> Package mgetty.i386 0:1.1.31-3 set to be updated ---> Package xscreensaver-base.i386 1:4.18-18 set to be updated ---> Package gaim.i386 1:1.1.3-3 set to be updated ---> Package Omni.i386 0:0.9.2-2 set to be updated ---> Package openssh-server.i386 0:3.9p1-11 set to be updated ---> Package tetex-fonts.i386 0:3.0-2 set to be updated ---> Package dhclient.i386 10:3.0.2-1 set to be updated ---> Package anacron.i386 0:2.3-33 set to be updated ---> Package pcmcia-cs.i386 0:3.2.8-4.10 set to be updated ---> Package selinux-policy-targeted.noarch 0:1.21.14-2 set to be updated ---> Package libselinux.i386 0:1.21.10-3 set to be updated ---> Package tetex.i386 0:3.0-2 set to be updated ---> Package Omni-foomatic.i386 0:0.9.2-2 set to be updated ---> Package openssh-askpass-gnome.i386 0:3.9p1-11 set to be updated ---> Package tetex-latex.i386 0:3.0-2 set to be updated ---> Package openssh-askpass.i386 0:3.9p1-11 set to be updated ---> Package python-devel.i386 0:2.4-4 set to be updated ---> Package kernel-devel.i686 0:2.6.10-1.1149_FC4 set to be installed ---> Package findutils.i386 1:4.2.18-1 set to be updated ---> Package openssh.i386 0:3.9p1-11 set to be updated ---> Package kernel.i686 0:2.6.10-1.1149_FC4 set to be installed ---> Package python.i386 0:2.4-4 set to be updated ---> Package gnome-desktop.i386 0:2.9.91-2 set to be updated ---> Package libgnomedb.i386 1:1.2.0-2 set to be updated ---> Package libselinux-devel.i386 0:1.21.10-3 set to be updated ---> Package gdb.i386 0:6.3.0.0-0.28 set to be updated ---> Package yum.noarch 0:2.3.0-1 set to be updated ---> Package policycoreutils.i386 0:1.21.18-2 set to be updated --> Running transaction check Dependencies Resolved Transaction Listing: Install: kernel-devel.i686 0:2.6.10-1.1149_FC4 - development Install: kernel.i686 0:2.6.10-1.1149_FC4 - development Update: openssh-server.i386 0:3.9p1-11 - development Update: Omni-foomatic.i386 0:0.9.2-2 - development Update: pcmcia-cs.i386 0:3.2.8-4.10 - development Update: tetex-dvips.i386 0:3.0-2 - development Update: python.i386 0:2.4-4 - development Update: python-devel.i386 0:2.4-4 - development Update: anacron.i386 0:2.3-33 - development Update: gnome-desktop.i386 0:2.9.91-2 - development Update: yum.noarch 0:2.3.0-1 - development Update: gdb.i386 0:6.3.0.0-0.28 - development Update: mgetty.i386 0:1.1.31-3 - development Update: tetex-fonts.i386 0:3.0-2 - development Update: policycoreutils.i386 0:1.21.18-2 - development Update: libgnomedb.i386 1:1.2.0-2 - development Update: gaim.i386 1:1.1.3-3 - development Update: libselinux-devel.i386 0:1.21.10-3 - development Update: libselinux.i386 0:1.21.10-3 - development Update: Omni.i386 0:0.9.2-2 - development Update: openssh-clients.i386 0:3.9p1-11 - development Update: gnome-desktop-devel.i386 0:2.9.91-2 - development Update: openssh.i386 0:3.9p1-11 - development Update: findutils.i386 1:4.2.18-1 - development Update: ghostscript.i386 0:7.07-38 - development Update: tetex-latex.i386 0:3.0-2 - development Update: openssh-askpass.i386 0:3.9p1-11 - development Update: tetex.i386 0:3.0-2 - development Update: xscreensaver-base.i386 1:4.18-18 - development Update: selinux-policy-targeted.noarch 0:1.21.14-2 - development Update: openssh-askpass-gnome.i386 0:3.9p1-11 - development Update: dhclient.i386 10:3.0.2-1 - development Total download size: 119 M Is this ok [y/N]: y Downloading Packages: (1/22): dhclient-3.0.2-1. 100% |=========================| 222 kB 00:09 (2/22): anacron-2.3-33.i3 100% |=========================| 32 kB 00:03 (3/22): pcmcia-cs-3.2.8-4 100% |=========================| 485 kB 00:19 (4/22): selinux-policy-ta 100% |=========================| 556 kB 00:24 (5/22): libselinux-1.21.1 100% |=========================| 60 kB 00:02 (6/22): tetex-3.0-2.i386. 100% |=========================| 13 MB 11:09 (7/22): Omni-foomatic-0.9 100% |=========================| 201 kB 00:10 (8/22): openssh-askpass-g 100% |=========================| 30 kB 00:01 (9/22): tetex-latex-3.0-2 100% |=========================| 5.4 MB 04:35 (10/22): openssh-askpass- 100% |=========================| 48 kB 00:02 (11/22): python-devel-2.4 100% |=========================| 1.8 MB 01:25 (12/22): kernel-devel-2.6 100% |=========================| 3.9 MB 03:10 (13/22): findutils-4.2.18 100% |=========================| 210 kB 00:09 (14/22): openssh-3.9p1-11 100% |=========================| 293 kB 00:21 (15/22): kernel-2.6.10-1. 100% |=========================| 13 MB 09:54 (16/22): python-2.4-4.i38 100% |=========================| 5.5 MB 04:13 (17/22): gnome-desktop-2. 100% |=========================| 665 kB 01:12 (18/22): libgnomedb-1.2.0 100% |=========================| 272 kB 00:15 (19/22): libselinux-devel 100% |=========================| 91 kB 00:07 (20/22): gdb-6.3.0.0-0.28 100% |=========================| 2.6 MB 01:58 (21/22): yum-2.3.0-1.noar 100% |=========================| 393 kB 00:15 (22/22): policycoreutils- 100% |=========================| 60 kB 00:02 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating: libselinux 100 % done 1/62 error: %post(libselinux-1.21.10-3.i386) scriptlet failed, exit status 255 Updating: python 100 % done 2/62 Updating: openssh 100 % done 3/62 error: %pre(kernel-2.6.10-1.1149_FC4.i686) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kernel-2.6.10-1.1149_FC4 Updating: tetex-fonts 100 % done 5/62 error: %post(tetex-fonts-3.0-2.i386) scriptlet failed, exit status 255 Updating: tetex-dvips 100 % done 6/62 error: %post(tetex-dvips-3.0-2.i386) scriptlet failed, exit status 255 Updating: tetex 100 % done 7/62 error: %post(tetex-3.0-2.i386) scriptlet failed, exit status 255 Updating: policycoreutils 100 % done 8/62 Updating: Omni 100 % done 9/62 Updating: libgnomedb 100 % done 10/62 error: %post(libgnomedb-1.2.0-2.i386) scriptlet failed, exit status 255 Updating: gnome-desktop 100 % done 11/62 error: %post(gnome-desktop-2.9.91-2.i386) scriptlet failed, exit status 255 Updating: gaim 100 % done 12/62 error: %post(gaim-1.1.3-3.i386) scriptlet failed, exit status 255 Updating: ghostscript 100 % done 13/62 error: %post(ghostscript-7.07-38.i386) scriptlet failed, exit status 255 Updating: openssh-clients 100 % done 14/62 Updating: gnome-desktop-devel 100 % done 15/62 Updating: mgetty 100 % done 16/62 error: %post(mgetty-1.1.31-3.i386) scriptlet failed, exit status 255 Updating: xscreensaver-base 100 % done 17/62 error: %pre(openssh-server-3.9p1-11.i386) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping openssh-server-3.9p1-11 Updating: dhclient 100 % done 19/62 Updating: anacron 100 % done 20/62 error: %post(anacron-2.3-33.i386) scriptlet failed, exit status 255 Updating: pcmcia-cs 100 % done 21/62 error: %post(pcmcia-cs-3.2.8-4.10.i386) scriptlet failed, exit status 255 error: %pre(selinux-policy-targeted-1.21.14-2.noarch) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping selinux-policy-targeted-1.21.14-2 Updating: Omni-foomatic 100 % done 23/62 error: %post(Omni-foomatic-0.9.2-2.i386) scriptlet failed, exit status 255 Updating: openssh-askpass-gnome 100 % done 24/62 Updating: tetex-latex 100 % done 25/62 error: %post(tetex-latex-3.0-2.i386) scriptlet failed, exit status 255 Updating: openssh-askpass 100 % done 26/62 Updating: python-devel 100 % done 27/62 Installing: kernel-devel 100 % done 28/62 error: %post(kernel-devel-2.6.10-1.1149_FC4.i686) scriptlet failed, exit status 255 Updating: findutils 100 % done 29/62 error: %post(findutils-4.2.18-1.i386) scriptlet failed, exit status 255 Updating: libselinux-devel 100 % done 30/62 Updating: gdb 100 % done 31/62 error: %post(gdb-6.3.0.0-0.28.i386) scriptlet failed, exit status 255 Updating: yum 100 % done 32/62 error: %post(yum-2.3.0-1.noarch) scriptlet failed, exit status 255 error: %preun(tetex-dvips-3.0-1.i386) scriptlet failed, exit status 255 Completing update for ghostscript - 33/62 error: %postun(ghostscript-7.07-37.i386) scriptlet failed, exit status 255 Completing update for openssh-clients - 34/62 Completing update for gnome-desktop-devel - 35/62 error: %preun(mgetty-1.1.31-2.i386) scriptlet failed, exit status 255 Completing update for xscreensaver-base - 36/62 Completing update for gaim - 37/62 error: %postun(gaim-1.1.3-2.i386) scriptlet failed, exit status 255 Completing update for Omni - 38/62 error: %preun(openssh-server-3.9p1-10.i386) scriptlet failed, exit status 255 error: %preun(tetex-fonts-3.0-1.i386) scriptlet failed, exit status 255 Completing update for dhclient - 39/62 error: %preun(anacron-2.3-32.i386) scriptlet failed, exit status 255 error: %preun(pcmcia-cs-3.2.8-4.9.i386) scriptlet failed, exit status 255 Completing update for selinux-policy-targeted - 40/62 Completing update for libselinux - 41/62 error: %postun(libselinux-1.21.10-1.i386) scriptlet failed, exit status 255 Completing update for tetex - 42/62 error: %postun(tetex-3.0-1.i386) scriptlet failed, exit status 255 Completing update for Omni-foomatic - 43/62 Completing update for openssh-askpass-gnome - 44/62 error: %preun(tetex-latex-3.0-1.i386) scriptlet failed, exit status 255 Completing update for openssh-askpass - 45/62 Completing update for python-devel - 46/62 error: %preun(findutils-4.2.15-2.i386) scriptlet failed, exit status 255 Completing update for openssh - 47/62 Completing update for python - 48/62 Completing update for gnome-desktop - 49/62 error: %postun(gnome-desktop-2.9.91-1.i386) scriptlet failed, exit status 255 Completing update for libgnomedb - 50/62 Completing update for libselinux-devel - 51/62 error: %preun(gdb-6.3.0.0-0.25.i386) scriptlet failed, exit status 255 Completing update for policycoreutils - 52/62 Installed: kernel-devel.i686 0:2.6.10-1.1149_FC4 kernel.i686 0:2.6.10-1.1149_FC4Updated: openssh-server.i386 0:3.9p1-11 Omni-foomatic.i386 0:0.9.2-2 pcmcia-cs.i386 0:3.2.8-4.10 tetex-dvips.i386 0:3.0-2 python.i386 0:2.4-4 python-devel.i386 0:2.4-4 anacron.i386 0:2.3-33 gnome-desktop.i386 0:2.9.91-2 yum.noarch 0:2.3.0-1 gdb.i386 0:6.3.0.0-0.28 mgetty.i386 0:1.1.31-3 tetex-fonts.i386 0:3.0-2 policycoreutils.i386 0:1.21.18-2 libgnomedb.i386 1:1.2.0-2 gaim.i386 1:1.1.3-3 libselinux-devel.i386 0:1.21.10-3 libselinux.i386 0:1.21.10-3 Omni.i386 0:0.9.2-2 openssh-clients.i386 0:3.9p1-11 gnome-desktop-devel.i386 0:2.9.91-2 openssh.i386 0:3.9p1-11 findutils.i386 1:4.2.18-1 ghostscript.i386 0:7.07-38 tetex-latex.i386 0:3.0-2 openssh-askpass.i386 0:3.9p1-11 tetex.i386 0:3.0-2 xscreensaver-base.i386 1:4.18-18 selinux-policy-targeted.noarch 0:1.21.14-2 openssh-askpass-gnome.i386 0:3.9p1-11 dhclient.i386 10:3.0.2-1 Complete! [rodd at localhost plugins]$ From mpeters at mac.com Wed Feb 23 01:41:04 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 23 Feb 2005 01:41:04 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <200502220959.38111.rjune@bravegnuworld.com> (from rjune@bravegnuworld.com on Tue Feb 22 06:59:33 2005) References: <20050221230925.7a9fabf8@python2> <200502220959.38111.rjune@bravegnuworld.com> Message-ID: <1109122864l.6367l.0l@devel.mpeters.us> On 02/22/2005 06:59:33 AM, Richard June wrote: > I agree, this is a great game to have in core. it's not huge, but it > is a lot > of fun. Except it pukes on a lot of systems if you don't install kernel tainting drivers. -- Michael A. Peters http://mpeters.us/ From skvidal at phy.duke.edu Wed Feb 23 01:50:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 20:50:50 -0500 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <1109121565.4609.26.camel@localhost.localdomain> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <1109121565.4609.26.camel@localhost.localdomain> Message-ID: <1109123450.2361.4.camel@cutter> On Wed, 2005-02-23 at 12:19 +1100, Rodd Clarkson wrote: >While updating to the current rawhide I'm getting lots of errors >(scriptlets failing) running: > >sudo yum update. > >I run this every morning, so the system was 'synced' with rawhide >yesterday. > >Interesting to note that it claims to have installed (or updated >packages) even though earlier output said that it wasn't going to try. >For example, the kernel package. > >During install: So I'm not 100% sure but I think that: >Updating: libselinux 100 % done 1/62 >error: %post(libselinux-1.21.10-3.i386) scriptlet failed, exit status 255 is where your problem(s) began. it's possible the selinux updates in rawhide are doing odd things with commands like ldconfig :) -sv From rodd at clarkson.id.au Wed Feb 23 02:05:44 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 23 Feb 2005 13:05:44 +1100 Subject: FC4 slimfast slimfest In-Reply-To: <604aa79105022213234003daf6@mail.gmail.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> Message-ID: <1109124345.4609.43.camel@localhost.localdomain> On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote: >On Tue, 22 Feb 2005 16:13:11 -0500, Daniel Veillard wrote: >> From a distro user I also think clearly labelled ISO lead to less >> confusion and also nobody should face >> "Installation will need CD1 CD2 CD3 CD4" >> "Okay" "Reboot" > >Clearly labeled? what does that mean exactly? The only way to be sure >you have the cds you need.. is to know exactly what is on each cd... >package by package. You aren't going to break out things with easily >digestable labels in such a way that makes sense to everyone. I think better labeled disks is a great idea. disc1, disc2, etc isn't exactly helpful. Having core1, core1, gnome, kde, games, devel, java, etc would be much easier to understand. > >You have a KDE cd and a game cd... which cd has the kde game you >want? Items can and will be intuitive members of multiple simple >labels. Sure, you're going to have some overlap, but in general this could be solved without too much pain. For example, gnome-games and kde-games are, at the end of the day, games so put them on the games disk. If the user really wants them and expected them on the Gnome or KDE disk, then all they have to do is yum install them, so no biggy (as far as I'm concerned). I'd much prefer to only have to download half the volume of four disks (even if it still involved four disks) and then hvae to yum install a couple of packages (using that tasty GUI yum tool that's planned) than have to download a whole bunch of stuff I don't intend to use just for the sake of 'simplicity'. >You have a development tools cd and a java cd... which one >intuitively has the development tools for java? And god forbid we ever >see a java based game. Ah, but if you think about java like everything else, then you've really got java and java-devel. >The only way to be absolutely sure is to have a mechanism likr say a >webpage.. people can go to before they download anything.. where they >run through a mock install-time package selection session and that >form spits out the isos they 'need' What a great idea. A simple but elegant way to solve this limited confusion where you can go and select the packages you want to install (in a very similar way to the current installer) and then it tells you what disks you'll need and maybe even how much of the particular disk you actually need. Say for example, you select gnome, OOo and gnome-games. The installer *might* tell you that gnome-games is on the games disk but that it's the only file you need from that disk and that you could just install it as a single case after the fact. While this is a dream case, it could tell you that you need 90% or core1, 85% or core2, 90% of gnome, 55% of OOo (who needs all the languages) and 3% of games. Because so little of games is needed, it might break down the few packages needed and look at dependancies (and offer alternative ways to install these few packages). Rodd From rodd at clarkson.id.au Wed Feb 23 02:12:21 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 23 Feb 2005 13:12:21 +1100 Subject: fc3 install hangs at "configuring kernel parameters" In-Reply-To: <421BC906.3010907@smsonline.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <421B714E.2080701@tlarson.com> <20050222184552.GA1444243@hiwaay.net> <421B8B4F.3020107@tlarson.com> <1109101520.15038.40.camel@opus.phy.duke.edu> <421BBE4F.1090009@donut.dk> <421BC906.3010907@smsonline.com> Message-ID: <1109124741.4609.47.camel@localhost.localdomain> Bill, You might want to repost this questions so that it doesn't appear as part of an existing thread (bad form). As a rule of thumb, if your post isn't part of the current thread, don't click on reply to start a new one. (You could click on the email address for the list instead and then go from there). Also, this question is off-topic for devel (a list for develpoment issues). Try fedora-list instead. Rodd On Tue, 2005-02-22 at 16:06 -0800, Bill Rees wrote: >Hi All, > I've tried installing FC3 several times with differing setups and >for each install, the final reboot hangs right as "configuring kernel >parameters" prints out. What is going on at this stage and what may be >the problem? I've done one FC3 install before on the same motherboard >(shuttle AK32v3.1) that worked just fine. The only difference I can see >is the processor is different (faster). > > Any thoughts anyone? I'm going to try a live cd image boot and >replace the kernel with a 2.6.8 variant and see if that makes any >difference. > >Bill Rees >Nascar Sillicon Motor Speedway > From riel at redhat.com Wed Feb 23 02:14:21 2005 From: riel at redhat.com (Rik van Riel) Date: Tue, 22 Feb 2005 21:14:21 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <20050222161734.GA14590@devserv.devel.redhat.com> References: <20050221220731.GB11759@devserv.devel.redhat.com> <421B5272.90603@wowway.com> <20050222161734.GA14590@devserv.devel.redhat.com> Message-ID: On Tue, 22 Feb 2005, Alan Cox wrote: > The few really redundant applications we have don't make a tiny dent in > the space required for java. The more I think about it the more it seems > to come down to "Gnome, KDE, Java, Open Office" pick any three. Also, these are all so big - surely it should be possible to shrink all of them by a bit ? -- "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 rodd at clarkson.id.au Wed Feb 23 02:16:12 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 23 Feb 2005 13:16:12 +1100 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <1109123450.2361.4.camel@cutter> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <1109121565.4609.26.camel@localhost.localdomain> <1109123450.2361.4.camel@cutter> Message-ID: <1109124972.4609.52.camel@localhost.localdomain> >So I'm not 100% sure but I think that: > >>Updating: libselinux 100 % done 1/62 >>error: %post(libselinux-1.21.10-3.i386) scriptlet failed, exit status 255 > >is where your problem(s) began. > >it's possible the selinux updates in rawhide are doing odd things with >commands like ldconfig :) Hmmm, so what would be the solution to this problem? Obviously I've got a bunch of packages that need to have the %post scripts run manually, along with still needing to install kernel and openssh-server. Would turning off selinux do it (as a work around)? Rodd From katzj at redhat.com Wed Feb 23 02:31:26 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 22 Feb 2005 21:31:26 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109124345.4609.43.camel@localhost.localdomain> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> <1109124345.4609.43.camel@localhost.localdomain> Message-ID: <421BEAFE.7030104@redhat.com> Rodd Clarkson wrote: > On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote: >>You have a KDE cd and a game cd... which cd has the kde game you >>want? Items can and will be intuitive members of multiple simple >>labels. > > Sure, you're going to have some overlap, but in general this could be > solved without too much pain. For example, gnome-games and kde-games > are, at the end of the day, games so put them on the games disk. If the > user really wants them and expected them on the Gnome or KDE disk, then > all they have to do is yum install them, so no biggy (as far as I'm > concerned). I'd much prefer to only have to download half the volume of > four disks (even if it still involved four disks) and then hvae to yum > install a couple of packages (using that tasty GUI yum tool that's > planned) than have to download a whole bunch of stuff I don't intend to > use just for the sake of 'simplicity'. Except that now my games cd depends on both the gnome disc and the kde disc. So I don't have a deterministic way to tell what CDs I need again. So now I'm back to where I basically end up needing all the CDs. Or I sometimes need all of them. And I don't know until I select my packages. Jeremy From mattdm at mattdm.org Wed Feb 23 04:18:28 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 22 Feb 2005 23:18:28 -0500 Subject: Exim as default MTA. In-Reply-To: <1109116346.30247.45.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> Message-ID: <20050223041828.GA10319@jadzia.bu.edu> On Tue, Feb 22, 2005 at 11:52:25PM +0000, David Woodhouse wrote: > That looks a lot better than I remember. Certainly sendmail should go -- > if our postfix actually supports IPv6 completely and can do the other > things like SpamAssassin on incoming mail at SMTP time, then I can't see > a lot to choose either way between it and Exim, although I'd personally > lean towards Exim. Can exim easily do the "username+anystring at host" (or "username-anystring at host") thing? I took a quick look at the much-vaunted documentation :) and couldn't find anything about it. This is something I really love with postfix. (The 'recipient_delimiter' option.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From florin at andrei.myip.org Wed Feb 23 04:44:06 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 22 Feb 2005 20:44:06 -0800 Subject: Exim as default MTA. In-Reply-To: <1109109046.30247.5.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> Message-ID: <1109133846.8101.7.camel@rivendell.home.local> On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote: > On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote: > >I think exim still has potential to become our future default MTA. Here we go again. > I agree. We really shouldn't be inflicting sendmail on newcomers as the > default MTA. That's a far better candidate for going to Extras, for > those who really want it because they've already suffered the brain > damage its configuration inflicts. > Exim would be a far better default, because it's far easier to configure > and far better documented. Far easier/better than what? Sendmail? Postfix? I agree that Sendmail is harder to configure than pretty much any other MTA, but as for the documentation part, it's actually pretty damn well documented. To say that Sendmail lacks documentation just shows ignorance on the subject and makes your whole position much weaker in the debate. Now, i still don't see any rational motive to inflict Exim upon users when Postfix is comparable, if not better, on all accounts _and_ has been already included for quite a while with Fedora / Red Hat and the users are just getting used to it by now. In fact, many Fedora users that i know switch to Postfix immediately after installing the OS. Please leave the partisan propaganda aside and start thinking rationally. -- Florin Andrei http://florin.myip.org/ From mark at talios.com Wed Feb 23 05:54:43 2005 From: mark at talios.com (Mark Derricutt) Date: Wed, 23 Feb 2005 18:54:43 +1300 Subject: Dell 2005FPW Flat Panel and xorg Message-ID: <421C1AA3.4080204@talios.com> Hi all, I just got a Dell 2005FP ( 20" widescreen flatpanel ) and noticed Xorg didn't like it, nor did system-config-display. I did manage to find a reference to this monitor in fedoraforums.com which had a copy of what I needed to add to xorg.conf[1], but I was wondering if support for this monitor was available in whatever xorg/system-config-display is going to be in FC4? [1] xorg.conf settings Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "DELL 2005FPW" UseModes "16:10" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 75.0 Option "dpms" EndSection Section "Modes" Identifier "16:10" ModeLine "1680x1050" 146.2 1680 1784 1968 2256 1050 1051 1054 1087 \ -hsync -vsync EndSection From skvidal at phy.duke.edu Wed Feb 23 06:30:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 01:30:26 -0500 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <1109124972.4609.52.camel@localhost.localdomain> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <1109121565.4609.26.camel@localhost.localdomain> <1109123450.2361.4.camel@cutter> <1109124972.4609.52.camel@localhost.localdomain> Message-ID: <1109140226.2361.21.camel@cutter> On Wed, 2005-02-23 at 13:16 +1100, Rodd Clarkson wrote: >>So I'm not 100% sure but I think that: >> >>>Updating: libselinux 100 % done 1/62 >>>error: %post(libselinux-1.21.10-3.i386) scriptlet failed, exit status 255 >> >>is where your problem(s) began. >> >>it's possible the selinux updates in rawhide are doing odd things with >>commands like ldconfig :) > >Hmmm, so what would be the solution to this problem? > >Obviously I've got a bunch of packages that need to have the %post >scripts run manually, along with still needing to install kernel and >openssh-server. > >Would turning off selinux do it (as a work around)? > setenforce 0 might be a good start, I dunno, for certain if it is selinux causing it, though. -sv From ghenry at suretecsystems.com Wed Feb 23 07:37:56 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 07:37:56 +0000 Subject: Exim as default MTA. In-Reply-To: <1109121487.17468.13.camel@jdub.homelinux.org> References: <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> Message-ID: <200502230737.56941.ghenry@suretecsystems.com> > So I'll bite and look at the latest exim package in FC3 (I am running a > server, so I can't really use rawhide). I'd be glad to report how it > goes if anyone is interested. Do the FC3 RPMS actually have the exiscan patch built in? I had to get the exim rpms for that feature: ftp://ftp.exim.org/pub/rpms-for-exim/fedora-3-i386-updates Why do we build our own, if they proivde FC3 ones? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From Nigel.Metheringham at dev.intechnology.co.uk Wed Feb 23 08:48:46 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 23 Feb 2005 08:48:46 +0000 Subject: Exim as default MTA. In-Reply-To: <20050223041828.GA10319@jadzia.bu.edu> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> <20050223041828.GA10319@jadzia.bu.edu> Message-ID: <1109148526.5708.2.camel@angua.localnet> On Tue, 2005-02-22 at 23:18 -0500, Matthew Miller wrote: > Can exim easily do the "username+anystring at host" (or > "username-anystring at host") thing? I took a quick look at the much-vaunted > documentation :) and couldn't find anything about it. This is something I > really love with postfix. (The 'recipient_delimiter' option.) Yes. The magic keyword is local_part_suffix - you can use whatever delimiter you like (I use both + and - since some places won't accept + in email addresses). Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From Nigel.Metheringham at dev.intechnology.co.uk Wed Feb 23 09:01:42 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 23 Feb 2005 09:01:42 +0000 Subject: Exim as default MTA. In-Reply-To: <200502230737.56941.ghenry@suretecsystems.com> References: <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> <200502230737.56941.ghenry@suretecsystems.com> Message-ID: <1109149302.5862.3.camel@angua.localnet> On Wed, 2005-02-23 at 07:37 +0000, Gavin Henry wrote: > > So I'll bite and look at the latest exim package in FC3 (I am running a > > server, so I can't really use rawhide). I'd be glad to report how it > > goes if anyone is interested. > > Do the FC3 RPMS actually have the exiscan patch built in? Yes. There is much common ground between the exim.org rpms (which I used to maintain) and the RH ones. Both Tim Waugh and I have unashamedly stolen rpm spec features from each other in the past. The main difference is that the FC/RH rpms do a single set of feature support tailored for whats available on FC by default, and the exim.org ones have flavours for different databases etc. > I had to get the exim rpms for that feature: No idea why - exiscan has been in for a year or two. Certainly before exim went into FC (was previously in rawhide for RHEL). Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From giallu at gmail.com Wed Feb 23 09:08:30 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 23 Feb 2005 10:08:30 +0100 Subject: Exim as default MTA. In-Reply-To: <1109133846.8101.7.camel@rivendell.home.local> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> Message-ID: On Tue, 22 Feb 2005 20:44:06 -0800, Florin Andrei wrote: > In fact, many Fedora users that i know switch to Postfix immediately > after installing the OS. I am one of those, never used sendmail anymore since I found postfix. From lkml at mac.com Wed Feb 23 09:30:04 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Wed, 23 Feb 2005 10:30:04 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <421A53F5.2060302@snowmoon.com> References: <421A53F5.2060302@snowmoon.com> Message-ID: On 21 Feb 2005, at 22:34, Eric Warnke wrote: > > I know this will be an unpopular suggestion, but 300MB is a lot to > loose. So I'm just throwing this out there..... > > KDE by my estimates is 350mb, move it into extras. No, instead move GNOME. From seyman at wanadoo.fr Wed Feb 23 09:47:06 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 23 Feb 2005 10:47:06 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A53F5.2060302@snowmoon.com> Message-ID: <20050223094706.GA7767@orient.maison.moi> On Wed, Feb 23, 2005 at 10:30:04AM +0100, Felipe Alfaro Solana wrote: > > No, instead move GNOME. Gnome is the default desktop. It makes better sense to move KDE. Emmanuel From jamatos at fc.up.pt Wed Feb 23 10:17:05 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 23 Feb 2005 10:17:05 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050223094706.GA7767@orient.maison.moi> References: <20050223094706.GA7767@orient.maison.moi> Message-ID: <200502231017.05733.jamatos@fc.up.pt> On Wednesday 23 February 2005 09:47, Emmanuel Seyman wrote: > On Wed, Feb 23, 2005 at 10:30:04AM +0100, Felipe Alfaro Solana wrote: > > No, instead move GNOME. > > Gnome is the default desktop. It makes better sense to move KDE. Are we condemned to have this same discussion for every version of the Fedora Core? ;-) Both GNOME and KDE are more than simple programs they have all the libraries associated. Is that framework what we want to exclude from Fedora Core? :-) > Emmanuel -- Jos? Ab?lio From jerone at gmail.com Wed Feb 23 10:22:53 2005 From: jerone at gmail.com (Jerone Young) Date: Wed, 23 Feb 2005 04:22:53 -0600 Subject: Dell 2005FPW Flat Panel and xorg In-Reply-To: <421C1AA3.4080204@talios.com> References: <421C1AA3.4080204@talios.com> Message-ID: <9f50a7a0050223022214105daf@mail.gmail.com> file a bugzilla report so that this can be added. On Wed, 23 Feb 2005 18:54:43 +1300, Mark Derricutt wrote: > Hi all, I just got a Dell 2005FP ( 20" widescreen flatpanel ) and > noticed Xorg didn't like it, nor did system-config-display. > > I did manage to find a reference to this monitor in fedoraforums.com > which had a copy of what I needed to add to xorg.conf[1], but I was > wondering if support for this monitor was available in whatever > xorg/system-config-display is going to be in FC4? > > [1] xorg.conf settings > > Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName "DELL 2005FPW" > UseModes "16:10" > HorizSync 30.0 - 83.0 > VertRefresh 56.0 - 75.0 > Option "dpms" > EndSection > > Section "Modes" > Identifier "16:10" > ModeLine "1680x1050" 146.2 1680 1784 1968 2256 1050 1051 1054 1087 \ > -hsync -vsync > EndSection > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From shiva at sewingwitch.com Wed Feb 23 10:39:09 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 23 Feb 2005 02:39:09 -0800 Subject: Dell 2005FPW Flat Panel and xorg In-Reply-To: <9f50a7a0050223022214105daf@mail.gmail.com> References: <421C1AA3.4080204@talios.com> <9f50a7a0050223022214105daf@mail.gmail.com> Message-ID: <48D597703EA47B08FCF5BCB8@[10.0.0.4]> --On Wednesday, February 23, 2005 4:22 AM -0600 Jerone Young wrote: > file a bugzilla report so that this can be added. File it against hwdata: From webmaster at margo.bijoux.nom.br Wed Feb 23 10:52:38 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Wed, 23 Feb 2005 07:52:38 -0300 Subject: Exim as default MTA. In-Reply-To: <1109121487.17468.13.camel@jdub.homelinux.org> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> Message-ID: <421C6076.2050107@margo.bijoux.nom.br> Josh Boyer wrote: >So I'll bite and look at the latest exim package in FC3 (I am running a >server, so I can't really use rawhide). I'd be glad to report how it >goes if anyone is interested. > > Can you please look at postfix too and tell us what you think about both? This could be interesting.. I cant comment much about this postfix/exim issue, since: 1 - I only used exim in debian and I configured it following a badly written guide (the guide was written by one of my coworkers when I was still a newbie) 2 - I moved from sendmail to postfix , so I suffered heavy cerebral damage :P -- Pedro Macedo From dwmw2 at infradead.org Wed Feb 23 10:54:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 10:54:14 +0000 Subject: Exim as default MTA. In-Reply-To: <1109121487.17468.13.camel@jdub.homelinux.org> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> Message-ID: <1109156055.30247.79.camel@localhost.localdomain> On Tue, 2005-02-22 at 19:18 -0600, Josh Boyer wrote: >Ok, I consider myself a "newbie" when it comes to MTAs. > >I currently run sendmail, but I've done as little as possible to get it >working. I have no spam filtering at SMTP, no auto-sorting of messages >into folders, basically nothing more than "get the mail to the spool". Sounds like you're a reasonably good test candidate; thanks for volunteeering. >So I'll bite and look at the latest exim package in FC3 (I am running a >server, so I can't really use rawhide). I'd be glad to report how it >goes if anyone is interested. If you have time, please could you also try the same with postfix? And if your own setup isn't very interesting, pick some other tasks like configuring mailman etc. to amuse yourself. Like I said -- I'm far more adamant that sendmail should go, than I am that Exim should be its replacement. I just happen to think that Exim is a better choice. -- dwmw2 From laroche at redhat.com Wed Feb 23 10:57:27 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 23 Feb 2005 11:57:27 +0100 Subject: Exim as default MTA. In-Reply-To: <1109110232.30247.20.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <20050222220021.GB23838@devserv.devel.redhat.com> <1109110232.30247.20.camel@localhost.localdomain> Message-ID: <20050223105727.GA6756@dudweiler.stuttgart.redhat.com> > I'm far more adamant about "it shouldn't be sendmail" than "it should be > exim" but sendmail definitely needs to go, and on balance I think Exim > would make a better choice than Postfix, because it's so much better > documented. And a good development community caring about stability on how exim works. greetings, Florian La Roche From ghenry at suretecsystems.com Wed Feb 23 11:06:27 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 11:06:27 -0000 (GMT) Subject: Bluemote RPM http://freshmeat.net/projects/bluemote/ Message-ID: <43583.193.195.148.66.1109156787.squirrel@webmail.suretecsystems.com> Dear all, Would anyone like to see this in extras? http://freshmeat.net/projects/bluemote/ I will volunteer. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From jwboyer at jdub.homelinux.org Wed Feb 23 12:25:13 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 23 Feb 2005 06:25:13 -0600 Subject: Exim as default MTA. In-Reply-To: <1109156055.30247.79.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> <1109156055.30247.79.camel@localhost.localdomain> Message-ID: <1109161513.17468.29.camel@jdub.homelinux.org> On Wed, 2005-02-23 at 10:54 +0000, David Woodhouse wrote: > On Tue, 2005-02-22 at 19:18 -0600, Josh Boyer wrote: > >Ok, I consider myself a "newbie" when it comes to MTAs. > > > >I currently run sendmail, but I've done as little as possible to get it > >working. I have no spam filtering at SMTP, no auto-sorting of messages > >into folders, basically nothing more than "get the mail to the spool". > > Sounds like you're a reasonably good test candidate; thanks for > volunteeering. Ok, so far I'm finding exim to be much better than sendmail. The default exim.conf file is heavily documented and I only had to set 2 lines in order to get the equivalent functionality that I did with sendmail. The only suggestion I have for the default config file is to use the defered_ok switch on the malware and spam ACL entries. I uncommented the acl_smtp_data = acl_check_content line and my server promptly started rejecting mail because I don't have sophie installed. If defered_ok had been used, the mail would have come through just fine. Remember, we're looking at this from a newbie point of view. Getting email is always better than rejecting everything when it's a setup type issue. > > If you have time, please could you also try the same with postfix? And > if your own setup isn't very interesting, pick some other tasks like > configuring mailman etc. to amuse yourself. I'll try and take a look at postfix in the next day or two. Probably tomorrow since my one user will be gone most of the evening :). > > Like I said -- I'm far more adamant that sendmail should go, than I am > that Exim should be its replacement. I just happen to think that Exim is > a better choice. I'd have to agree that exim is better than sendmail from a usability standpoint. It was easier to configure, and the default config file already has some of the features I'm looking for. Unless postfix proves to be even better, I'll probably be sticking with exim. josh From ralph+fedora at strg-alt-entf.org Wed Feb 23 12:26:14 2005 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Wed, 23 Feb 2005 13:26:14 +0100 Subject: Exim as default MTA. In-Reply-To: <1109110232.30247.20.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <20050222220021.GB23838@devserv.devel.redhat.com> <1109110232.30247.20.camel@localhost.localdomain> Message-ID: <20050223122614.GF14170@br-online.de> David Woodhouse wrote: > I'm far more adamant about "it shouldn't be sendmail" than "it should be > exim" but sendmail definitely needs to go, and on balance I think Exim > would make a better choice than Postfix, because it's so much better > documented. OTOH I think, that exim4's configuration files are close to unreadable and far to many parentheses in it. If you want to use a simple MTA as default mailer, I'd opt to go to postfix - but I am biased, because I switched from Exim3 to Exim4, as I disliked some of the new configuration stuff (especially its readability, as stated above). As to documentation: postfix 2.1 is very well documented, the documentation cannot be compared to what was delivered with 2.0 or earlier. But that's just me. Regards, Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ralph+fedora at strg-alt-entf.org Wed Feb 23 12:31:39 2005 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Wed, 23 Feb 2005 13:31:39 +0100 Subject: Exim as default MTA. In-Reply-To: <20050223122614.GF14170@br-online.de> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <20050222220021.GB23838@devserv.devel.redhat.com> <1109110232.30247.20.camel@localhost.localdomain> <20050223122614.GF14170@br-online.de> Message-ID: <20050223123139.GG14170@br-online.de> Ralph Angenendt wrote: > [...] I'd opt to go to postfix - but I am biased, because I > switched from Exim3 to Exim4, as I disliked some of the new > configuration stuff (especially its readability, as stated above). Okay, what was I thinking when I wrote that? This should of course read "... switched from Exim3 to Postfix ...". Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Wed Feb 23 12:37:25 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 23 Feb 2005 07:37:25 -0500 (EST) Subject: Dell 2005FPW Flat Panel and xorg In-Reply-To: <421C1AA3.4080204@talios.com> References: <421C1AA3.4080204@talios.com> Message-ID: On Wed, 23 Feb 2005, Mark Derricutt wrote: > Hi all, I just got a Dell 2005FP ( 20" widescreen flatpanel ) and > noticed Xorg didn't like it, nor did system-config-display. > > I did manage to find a reference to this monitor in fedoraforums.com > which had a copy of what I needed to add to xorg.conf[1], but I was > wondering if support for this monitor was available in whatever > xorg/system-config-display is going to be in FC4? > > [1] xorg.conf settings > > Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName "DELL 2005FPW" > UseModes "16:10" > HorizSync 30.0 - 83.0 > VertRefresh 56.0 - 75.0 > Option "dpms" > EndSection > > Section "Modes" > Identifier "16:10" > ModeLine "1680x1050" 146.2 1680 1784 1968 2256 1050 1051 1054 1087 \ > -hsync -vsync > EndSection When you file the bug, could you also attach the monitor's .inf file from its CD? There is some info there about modelines that's necessary for hwdata to know. Dan From dwmw2 at infradead.org Wed Feb 23 12:49:25 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 12:49:25 +0000 Subject: Exim as default MTA. In-Reply-To: <1109161513.17468.29.camel@jdub.homelinux.org> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> <1109156055.30247.79.camel@localhost.localdomain> <1109161513.17468.29.camel@jdub.homelinux.org> Message-ID: <1109162966.17808.12.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 06:25 -0600, Josh Boyer wrote: > The only suggestion I have for the default config file is to use the > defered_ok switch on the malware and spam ACL entries. I uncommented > the acl_smtp_data = acl_check_content line and my server promptly > started rejecting mail because I don't have sophie installed. If > defered_ok had been used, the mail would have come through just fine. If you really mean 'rejecting' mail then let me know and I'll look into it right now. If as I suspect you just mean 'deferring' -- it was giving a temporary error and no mail was lost, then I'm less sure. One might argue that deferral is the correct behaviour -- if you enabled the spam checking and your spamd is broken, it's better to keep the mail in the queue elsewhere until your spamd is fixed than it is to just accept the incoming mail, spam and all. If the checking were enabled by default then I'd agree with you -- but since you have to actually _ask_ for spam checking, I'm inclined to suggest that it's better the way it is. We can certainly add the defer_ok option to the comments though, so it stares you in the face if you do enable the checking. Would that be sufficient? -- dwmw2 From lists at donut.dk Wed Feb 23 13:16:03 2005 From: lists at donut.dk (Cream) Date: Wed, 23 Feb 2005 14:16:03 +0100 Subject: Exim as default MTA. In-Reply-To: <1109133846.8101.7.camel@rivendell.home.local> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> Message-ID: <421C8213.30502@donut.dk> Florin Andrei wrote: > In fact, many Fedora users that i know switch to Postfix immediately > after installing the OS. I switch to Qmail+vpopmail, since dumping sendmail 4 years ago :) How are Exim & Postfix at handling several virtual domains? (with same user@ names?) From fedora-devel at camperquake.de Wed Feb 23 13:21:19 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 23 Feb 2005 14:21:19 +0100 Subject: Exim as default MTA. In-Reply-To: <421C8213.30502@donut.dk> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> <421C8213.30502@donut.dk> Message-ID: <20050223142119.5b597365@nausicaa.camperquake.de> Hi. Cream wrote: > How are Exim & Postfix at handling several virtual domains? (with same > user@ names?) A mailserver that is unable to do that is not worth being called by that name. Exim is similar to sendmail in being more like a construction set for mail servers than a mailserver. There are a lot of parts doing different things that you can arrange at your leisure in order to route and transport mail through the system. This means that there are usually several ways do do something. exims advantage is that it's config readable by human beings (ok, there are a lot of {}). -- Confucius say, "Man who sink into woman's arms soon have arms in woman's sink." From jwboyer at jdub.homelinux.org Wed Feb 23 13:34:46 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 23 Feb 2005 07:34:46 -0600 Subject: Exim as default MTA. In-Reply-To: <1109162966.17808.12.camel@hades.cambridge.redhat.com> References: <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> <1109156055.30247.79.camel@localhost.localdomain> <1109161513.17468.29.camel@jdub.homelinux.org> <1109162966.17808.12.camel@hades.cambridge.redhat.com> Message-ID: <20050223133446.GA15339@yoda.jdub.homelinux.org> On Wed, Feb 23, 2005 at 12:49:25PM +0000, David Woodhouse wrote: > On Wed, 2005-02-23 at 06:25 -0600, Josh Boyer wrote: > > The only suggestion I have for the default config file is to use the > > defered_ok switch on the malware and spam ACL entries. I uncommented > > the acl_smtp_data = acl_check_content line and my server promptly > > started rejecting mail because I don't have sophie installed. If > > defered_ok had been used, the mail would have come through just fine. > > If you really mean 'rejecting' mail then let me know and I'll look into > it right now. If as I suspect you just mean 'deferring' -- it was giving > a temporary error and no mail was lost, then I'm less sure. Yes, I meant deferring. But in my case, it was continually defering until I bothered to check the logs, which to a newbie looks like rejecting. After I commented the line out and restarted exim, the mail came through fine. > > One might argue that deferral is the correct behaviour -- if you enabled > the spam checking and your spamd is broken, it's better to keep the mail > in the queue elsewhere until your spamd is fixed than it is to just > accept the incoming mail, spam and all. Maybe. But I know some list maintainers that get cranky if they notice email that is stuck in their queue ;). > > If the checking were enabled by default then I'd agree with you -- but > since you have to actually _ask_ for spam checking, I'm inclined to > suggest that it's better the way it is. That's just it. I _did_ ask for spam checking. I started spamassassin and then uncommented that line. What I didn't expect is for it to defer email when I don't even have a virus checker installed. Call it a newbie mistake. > > We can certainly add the defer_ok option to the comments though, so it > stares you in the face if you do enable the checking. Would that be > sufficient? Sure, adding that to the comments would be fine IMHO. That way newbies will at least know what happens when they don't have spamassassin or a virus checker running, and how to work around it if they don't want to do one or the other. josh From dwmw2 at infradead.org Wed Feb 23 13:55:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 13:55:33 +0000 Subject: Exim as default MTA. In-Reply-To: <20050223142119.5b597365@nausicaa.camperquake.de> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> <421C8213.30502@donut.dk> <20050223142119.5b597365@nausicaa.camperquake.de> Message-ID: <1109166934.17808.19.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 14:21 +0100, Ralf Ertzinger wrote: > A mailserver that is unable to do that is not worth being called by that > name. Exim is similar to sendmail in being more like a construction set > for mail servers than a mailserver. There are a lot of parts doing different > things that you can arrange at your leisure in order to route and transport > mail through the system. This means that there are usually several ways do > do something. Exim does offer a lot of flexibility, yes. Although you _can_ contrive many ways to do simple things, and even more ways to do compilated things, the default configuration file ships with examples of the easy way to do useful things -- and can have more such examples added on request. -- dwmw2 From dragoran at feuerpokemon.de Wed Feb 23 13:59:52 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 23 Feb 2005 14:59:52 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050221213044.GF31765@nostromo.devel.redhat.com> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> Message-ID: <421C8C58.9020004@feuerpokemon.de> Bill Nottingham wrote: >F?liciano Matias (feliciano.matias at free.fr) said: > > >>>You can view the list of new packages since FC3 (sorted by package size) >>>at http://people.redhat.com/sopwith/new-packages.txt >>> >>> >>Increase the CD size to 700 or 720 Mo ? >> >> > >This was tried around Red Hat Linux 8.0. There were too many failures, >really. > >Bill > > > Whe should try it again. 700MB CDs aren't something rare now ... I haven't seen any 650MB CD for some months now.And the price is the same for both, so vendors will not have problems to keep their price. Increasing the CD size from 650 to 700MB would give us 4*50MB =200MB more space without increasing the CD count. From dwmw2 at infradead.org Wed Feb 23 14:24:45 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 14:24:45 +0000 Subject: Exim as default MTA. In-Reply-To: <20050223123139.GG14170@br-online.de> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <20050222220021.GB23838@devserv.devel.redhat.com> <1109110232.30247.20.camel@localhost.localdomain> <20050223122614.GF14170@br-online.de> <20050223123139.GG14170@br-online.de> Message-ID: <1109168685.17808.28.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 13:31 +0100, Ralph Angenendt wrote: > > > [...] I'd opt to go to postfix - but I am biased, because I > > switched from Exim3 to Exim4, as I disliked some of the new > > configuration stuff (especially its readability, as stated above). > > Okay, what was I thinking when I wrote that? This should of course read > "... switched from Exim3 to Postfix ...". Yeah, Exim3 was somewhat arcane, but has now been obsolete for a number of years. Exim4 is a lot more logical in its configuration and has relatively few parentheses unless you're trying to do something evil with it. :) If course, if you _like_ it weird, you can do that too.... http://david.woodhou.se/eximconf/include/routers-ses or http://david.woodhou.se/eximconf/include/acl-helo-csv being examples of what you can do if you just want to be silly about it and do stuff purely in Exim configuration rather than falling back to hacking it up in C like normal people might. -- dwmw2 From Lam at Lam.pl Wed Feb 23 14:27:18 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 15:27:18 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <421C8C58.9020004@feuerpokemon.de> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> Message-ID: <1109168838.6581.25.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 14:59 +0100, dragoran napisa?(a): > Whe should try it again. 700MB CDs aren't something rare now ... IIRC, it was tried in RHL 7.3.93, it was 2,5 years ago, and even then I thought the same as you. 2,5 years ago 700 MiB CD-R-s were cheaper than 650 MiB and now it's even hard to get 650 MiB blank disc (with an exception on some "audio" 74 min CD-R-s worth 10 times the price of standard 80 min CD-R). My 8-year-old CD burner can burn 90 min CD-R-s with no problem at all. But if all of it wasn't enough 2 years ago, it's not enough today, either. I guess the problems were connected to older hardware, but remmeber today Fedora doesn't include support for machines older than i586 and doesn't even include support for some low-end 586s. Remember Anaconda won't run on system with less than 64 MiB memory (the RULE project looked nice, but it's not very active nowadays) and for graphical install (Fedora is the desktop distro, remember) it requires 192 MiB of system RAM according to FC3 release notes. Do we really still need to think about machines that cannot use 700 MiB discs? :) Lam From rdieter at math.unl.edu Wed Feb 23 14:25:12 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Feb 2005 08:25:12 -0600 Subject: kde-3.4 (3.3.92) in fc4 In-Reply-To: <421B44B8.4070603@redhat.com> References: <421B3A3B.1070100@math.unl.edu> <421B44B8.4070603@redhat.com> Message-ID: Than Ngo wrote: > Rex Dieter wrote: > >> I know it's getting close, but I think it's important to try to get >> kde-3.4 (3.3.92beta2 at the moment) into fc4. If not, fedora users >> will have to wait for fc5 before seeing this (please correct me if I'm >> wrong). > i'm still waiting for KDE-3.4 RC1, which will be released on Feb 22. Don't you mean Feb 26? That is what is posted on http://developer.kde.org/development-versions/kde-3.4-release-plan.html -- Rex From walters at redhat.com Wed Feb 23 14:47:04 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 23 Feb 2005 09:47:04 -0500 Subject: Exim as default MTA. In-Reply-To: <1109110217.30247.19.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> Message-ID: <1109170025.3928.17.camel@nexus.verbum.private> On Tue, 2005-02-22 at 22:10 +0000, David Woodhouse wrote: >On Tue, 2005-02-22 at 21:59 +0000, Carwyn Edwards wrote: >>How does the argument stack up against postfix? I've found postfix + >>procmail (optional) + dovecot + squirrelmail (optional) to be very easy >>to manage. > >I haven't had that much experience of postfix. One data point I'd like to add to this is that specifically in the Fedora context (i.e. outside of the general exim vs postfix debate), Postfix has the advantage in that its design (multiple independent mutually untrusting processes?) allows a strong SELinux policy to be easily applied, further enhancing Postfix's already good security. Exim re-execs itself to drop privilege, but this doesn't work well with SELinux without source code changes (unwritten as of yet AFAIK) to determine which context to transition to. ? http://www.postfix.org/big-picture.html From mattdm at mattdm.org Wed Feb 23 14:47:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 23 Feb 2005 09:47:09 -0500 Subject: Exim as default MTA. In-Reply-To: <1109148526.5708.2.camel@angua.localnet> References: <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109109984.3714.1.camel@roque> <1109114101.30247.37.camel@localhost.localdomain> <1109116346.30247.45.camel@localhost.localdomain> <20050223041828.GA10319@jadzia.bu.edu> <1109148526.5708.2.camel@angua.localnet> Message-ID: <20050223144709.GA25849@jadzia.bu.edu> On Wed, Feb 23, 2005 at 08:48:46AM +0000, Nigel Metheringham wrote: > > Can exim easily do the "username+anystring at host" (or > > "username-anystring at host") thing? I took a quick look at the much-vaunted > Yes. The magic keyword is local_part_suffix - you can use whatever > delimiter you like (I use both + and - since some places won't accept + > in email addresses). In that case, postfix, exim, I don't really care. But I have a slight preference for postfix since I've been using it for a while, it's been in the distro longer, and we've been encouraging people to use it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ghenry at suretecsystems.com Wed Feb 23 15:04:06 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 23 Feb 2005 15:04:06 -0000 (GMT) Subject: Orphaned Packages - where are the bugzilla pages located? Message-ID: <53136.193.195.148.66.1109171046.squirrel@webmail.suretecsystems.com> Dear all, From: http://fedoraproject.org/wiki/Extras/OrphanedPackages I would like to look after: librsync tidy rdiff-backup cpan2rpm john Who do I need to speak to to save these? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From cmadams at hiwaay.net Wed Feb 23 15:08:24 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Feb 2005 09:08:24 -0600 Subject: Exim as default MTA. In-Reply-To: <1109170025.3928.17.camel@nexus.verbum.private> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> Message-ID: <20050223150824.GA924815@hiwaay.net> Once upon a time, Colin Walters said: > One data point I'd like to add to this is that specifically in the > Fedora context (i.e. outside of the general exim vs postfix debate), > Postfix has the advantage in that its design (multiple independent > mutually untrusting processes??) allows a strong SELinux policy to be > easily applied, further enhancing Postfix's already good security. I would definately give the edge to Postfix then. I use sendmail everywhere myself, but for my main servers I have to roll my own RPMs anyway to get additional things turned on (also I use the same source RPM on Linux, Tru64, and Solaris). Having sendmail removed wouldn't bother me. The biggest question is still the upgrade issue; if sendmail is removed from Core, what will happen on upgrades? Users will be left with the old version of sendmail running. What would be "nice" would be a hack in anaconda to check for a default config sendmail install (i.e. nothing has been changed since install) and replace it with the new default MTA (postfix or exim). If anything has changed, just leave it alone. There currently isn't really a way to handle changing the default provider of a service from one package to another. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From arjanv at redhat.com Wed Feb 23 15:19:13 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 23 Feb 2005 16:19:13 +0100 Subject: Exim as default MTA. In-Reply-To: <20050223150824.GA924815@hiwaay.net> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> Message-ID: <1109171953.6290.76.camel@laptopd505.fenrus.org> > What would be "nice" would be a hack in anaconda to check for a default > config sendmail install (i.e. nothing has been changed since install) > and replace it with the new default MTA (postfix or exim). If anything > has changed, just leave it alone. There currently isn't really a way to > handle changing the default provider of a service from one package to > another. actually if the default install is still there, not exim or postfix should be installed but ssmtp or smail or such; at least a very simple "send only" mail app that has a smarthost as only configuration parameter. lots nicer for security overall ;) -------------- next part -------------- A 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 stan at ccs.neu.edu Wed Feb 23 15:23:28 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 23 Feb 2005 10:23:28 -0500 Subject: Exim as default MTA. In-Reply-To: <1109133846.8101.7.camel@rivendell.home.local> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> Message-ID: <421C9FF0.4060000@ccs.neu.edu> Florin Andrei wrote: > On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote: > >>On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote: >> >>>I think exim still has potential to become our future default MTA. > > > > > Here we go again. > I was just thinking the same thing myself. > >>I agree. We really shouldn't be inflicting sendmail on newcomers as the >>default MTA. That's a far better candidate for going to Extras, for >>those who really want it because they've already suffered the brain >>damage its configuration inflicts. >>Exim would be a far better default, because it's far easier to configure >>and far better documented. > > > Far easier/better than what? Sendmail? Postfix? > > I agree that Sendmail is harder to configure than pretty much any other > MTA, but as for the documentation part, it's actually pretty damn well > documented. To say that Sendmail lacks documentation just shows > ignorance on the subject and makes your whole position much weaker in > the debate. > He never said sendmail lacks documentation, he said exim and postfix were better documented. And they are. Sendmail's documentation is so needlessly complex people have it sitting in front of them and still can't make heads or tails of how to configure it. So your position just went out the window. > Now, i still don't see any rational motive to inflict Exim upon users > when Postfix is comparable, if not better, on all accounts _and_ has > been already included for quite a while with Fedora / Red Hat and the > users are just getting used to it by now. Both Exim and Postfix were added to RH Linux 6.2 Powertools at the same time. > In fact, many Fedora users that i know switch to Postfix immediately > after installing the OS. > Biased are we? Not once do you mention why Exim shouldn't be the default MTA, you merely claim that because you and your friends use Postfix everyone should? > Please leave the partisan propaganda aside and start thinking > rationally. > Look who's talking. You twisted words, ignored Exim all together, dissed someone who didn't say what you claimed, and then accuse them of spreading Exim propoganda while you spread your postfix propaganda. You could be a little nicer about it? That said: my vote is Postfix simply because I like the configuration files better than Exim. In terms of my needs both Exim and Postfix have all the features anyone may need in an MTA. Sendmail's draconian configuration files and basically extensive, but confusing documentation really give a huge boost to Exim and Postfix in general. From stan at ccs.neu.edu Wed Feb 23 15:28:24 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 23 Feb 2005 10:28:24 -0500 Subject: Exim as default MTA. In-Reply-To: <20050223150824.GA924815@hiwaay.net> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> Message-ID: <421CA118.70706@ccs.neu.edu> Chris Adams wrote: > > I would definately give the edge to Postfix then. > > I use sendmail everywhere myself, but for my main servers I have to roll > my own RPMs anyway to get additional things turned on (also I use the > same source RPM on Linux, Tru64, and Solaris). Having sendmail removed > wouldn't bother me. I dunno if the suggestion is actually to remove it (move it to Extras) rather than just make Postfix the default MTA. > > The biggest question is still the upgrade issue; if sendmail is removed > from Core, what will happen on upgrades? Users will be left with the > old version of sendmail running. > See above for one thought. OTOH if it were removed Postfix would just obselete sendmail and well... you'd have to reconfigure :) > What would be "nice" would be a hack in anaconda to check for a default > config sendmail install (i.e. nothing has been changed since install) > and replace it with the new default MTA (postfix or exim). If anything > has changed, just leave it alone. There currently isn't really a way to > handle changing the default provider of a service from one package to > another. > Well one way to look at it is, rpm lets you remove a package but leave the config files behind anyways, automatically converting between 2 very different MTA's isn't feasible at this juncture (unless tools exist?) since they have different features and vastly different config parameters. Good thoughts though Chris, you made some good points I forgot about :) -sb From mattdm at mattdm.org Wed Feb 23 15:30:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 23 Feb 2005 10:30:32 -0500 Subject: Exim as default MTA. In-Reply-To: <421C9FF0.4060000@ccs.neu.edu> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> <421C9FF0.4060000@ccs.neu.edu> Message-ID: <20050223153032.GA27018@jadzia.bu.edu> On Wed, Feb 23, 2005 at 10:23:28AM -0500, Stan Bubrouski wrote: > Both Exim and Postfix were added to RH Linux 6.2 Powertools at the same > time. But only postfix made the jump to the distro proper in RHL 7.3. (For whatever that's worth -- not much, really. I think the SE Linux thing is the biggest deal.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From stan at ccs.neu.edu Wed Feb 23 15:40:28 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 23 Feb 2005 10:40:28 -0500 Subject: Exim as default MTA. In-Reply-To: <20050223153032.GA27018@jadzia.bu.edu> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> <421C9FF0.4060000@ccs.neu.edu> <20050223153032.GA27018@jadzia.bu.edu> Message-ID: <421CA3EC.6040802@ccs.neu.edu> Matthew Miller wrote: > But only postfix made the jump to the distro proper in RHL 7.3. (For > whatever that's worth -- not much, really. I think the SE Linux thing is the > biggest deal.) I didn't see Arjan's message before i typed mine :D -sb From walters at redhat.com Wed Feb 23 15:41:38 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 23 Feb 2005 10:41:38 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <421BEAFE.7030104@redhat.com> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> <1109124345.4609.43.camel@localhost.localdomain> <421BEAFE.7030104@redhat.com> Message-ID: <1109173299.3820.6.camel@nexus.verbum.private> On Tue, 2005-02-22 at 21:31 -0500, Jeremy Katz wrote: >Rodd Clarkson wrote: >> On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote: >>>You have a KDE cd and a game cd... which cd has the kde game you >>>want? Items can and will be intuitive members of multiple simple >>>labels. >> >> Sure, you're going to have some overlap, but in general this could be >> solved without too much pain. For example, gnome-games and kde-games >> are, at the end of the day, games so put them on the games disk. If the >> user really wants them and expected them on the Gnome or KDE disk, then >> all they have to do is yum install them, so no biggy (as far as I'm >> concerned). I'd much prefer to only have to download half the volume of >> four disks (even if it still involved four disks) and then hvae to yum >> install a couple of packages (using that tasty GUI yum tool that's >> planned) than have to download a whole bunch of stuff I don't intend to >> use just for the sake of 'simplicity'. > >Except that now my games cd depends on both the gnome disc and the kde >disc. I don't think it's unreasonable to include the e.g. just KDE runtime libraries on disc 1, but not necessarily all of KDE. The runtime libraries should be fairly small relative to the entire desktop. Right? From stan at ccs.neu.edu Wed Feb 23 15:59:47 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 23 Feb 2005 10:59:47 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109173299.3820.6.camel@nexus.verbum.private> References: <1109043083.29658.5.camel@localhost.localdomain> <421AAE99.8030705@tlarson.com> <20050222112021.GA28474@devserv.devel.redhat.com> <20050222211311.GS15979@redhat.com> <604aa79105022213234003daf6@mail.gmail.com> <1109124345.4609.43.camel@localhost.localdomain> <421BEAFE.7030104@redhat.com> <1109173299.3820.6.camel@nexus.verbum.private> Message-ID: <421CA873.9050902@ccs.neu.edu> Colin Walters wrote: > On Tue, 2005-02-22 at 21:31 -0500, Jeremy Katz wrote: > >>Rodd Clarkson wrote: >> >>>On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote: >>> >>>>You have a KDE cd and a game cd... which cd has the kde game you >>>>want? Items can and will be intuitive members of multiple simple >>>>labels. >>> >>>Sure, you're going to have some overlap, but in general this could be >>>solved without too much pain. For example, gnome-games and kde-games >>>are, at the end of the day, games so put them on the games disk. If the >>>user really wants them and expected them on the Gnome or KDE disk, then >>>all they have to do is yum install them, so no biggy (as far as I'm >>>concerned). I'd much prefer to only have to download half the volume of >>>four disks (even if it still involved four disks) and then hvae to yum >>>install a couple of packages (using that tasty GUI yum tool that's >>>planned) than have to download a whole bunch of stuff I don't intend to >>>use just for the sake of 'simplicity'. >> >>Except that now my games cd depends on both the gnome disc and the kde >>disc. > > > I don't think it's unreasonable to include the e.g. just KDE runtime > libraries on disc 1, but not necessarily all of KDE. The runtime > libraries should be fairly small relative to the entire desktop. Right? > > If by small you mean huge, then yes :) -sb From kmaraas at broadpark.no Wed Feb 23 16:06:07 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Wed, 23 Feb 2005 17:06:07 +0100 Subject: setgroups() moved? Message-ID: <1109174768.3349.6.camel@localhost.localdomain> Hi. It looks like this function moved? The man page says: SYNOPSIS #include #include but it seems like it's really living in : [kmaraas at localhost xpl]$ grep setgroups /usr/include/*.h /usr/include/grp.h:extern int setgroups (size_t __n, __const __gid_t *__groups) __THROW; What's the right way of getting at this function? Preferrably in a way that works with other distros/OSes? Cheers Kjartan From gildas.bayard at ac6.fr Wed Feb 23 16:07:03 2005 From: gildas.bayard at ac6.fr (Gildas Bayard) Date: Wed, 23 Feb 2005 17:07:03 +0100 Subject: nash, cpio and linuxrc Message-ID: <1109174824.6309.16.camel@localhost.localdomain> Hello, First of all, please direct me to an other mailing list if I'm going off topic. I've investigated a bit the initrd system and there are some questions I could no find answers for: - why are regular desktop distributions always using the initrd system? I understand that this system is mandatory to load exotic scsi drivers or add a pause when booting to usb but I wonder why it is always used - on kernel 2.4 (red hat 9) the initrd image is an ext2 filesystems. It contains a linuxrc nash script. On kernel 2.6 (fedora 3) the initrd is a cpio archive and does not contains a linuxrc script. Could someone briefly explain me why these differences? Particularly I wondering about 3 things: 1) I tried to repack my custom initrd ext2 filesystem into a cpio archive and found that when packed as a cpio archive it's not executing my linuxrc script (is it the way it's supposed to be?) 2) What are the differences between pivot_root and switch_root (new in 2.6) ? 3) Why using nash in the first place? Could we just wait until the end of the linuxrc script? At that time the kernel would move to the new root fs (whitout the need for pivot_root or switch_root) And finally, if I'm right the end of the nash script (after switch_root) is never executed? Gildas From jakub at redhat.com Wed Feb 23 16:12:08 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 23 Feb 2005 11:12:08 -0500 Subject: setgroups() moved? In-Reply-To: <1109174768.3349.6.camel@localhost.localdomain> References: <1109174768.3349.6.camel@localhost.localdomain> Message-ID: <20050223161208.GR853@devserv.devel.redhat.com> On Wed, Feb 23, 2005 at 05:06:07PM +0100, Kjartan Maraas wrote: > Hi. > > It looks like this function moved? The man page says: > > SYNOPSIS > #include > #include > > but it seems like it's really living in : > > [kmaraas at localhost xpl]$ grep setgroups /usr/include/*.h > /usr/include/grp.h:extern int setgroups (size_t __n, __const __gid_t > *__groups) __THROW; > > What's the right way of getting at this function? Preferrably in a way > that works with other distros/OSes? You haven't read the man page carefully: SYNOPSIS #include #include int getgroups(int size, gid_t list[]); #include int setgroups(size_t size, const gid_t *list); I.e. for getgroups you need sys/types.h and unistd.h and for setgroups also grp.h. Jakub From stan at ccs.neu.edu Wed Feb 23 16:14:18 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 23 Feb 2005 11:14:18 -0500 Subject: setgroups() moved? In-Reply-To: <1109174768.3349.6.camel@localhost.localdomain> References: <1109174768.3349.6.camel@localhost.localdomain> Message-ID: <421CABDA.6050907@ccs.neu.edu> A quick grep shows that Kjartan is right, grp.h is not included by sys/types.h or unistd.h or any of their includes so it seems the manual page is indeed out of date. -sb Kjartan Maraas wrote: > Hi. > > It looks like this function moved? The man page says: > > SYNOPSIS > #include > #include > > but it seems like it's really living in : > > [kmaraas at localhost xpl]$ grep setgroups /usr/include/*.h > /usr/include/grp.h:extern int setgroups (size_t __n, __const __gid_t > *__groups) __THROW; > > What's the right way of getting at this function? Preferrably in a way > that works with other distros/OSes? > > Cheers > Kjartan > > From ph18 at cornell.edu Wed Feb 23 16:19:25 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Wed, 23 Feb 2005 11:19:25 -0500 Subject: Exim as default MTA. In-Reply-To: <1109121487.17468.13.camel@jdub.homelinux.org> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> Message-ID: On Tue, 22 Feb 2005 19:18:06 -0600, Josh Boyer wrote: > > Ok, I consider myself a "newbie" when it comes to MTAs. > > I currently run sendmail, but I've done as little as possible to get it > working. I have no spam filtering at SMTP, no auto-sorting of messages > into folders, basically nothing more than "get the mail to the spool". > > Why? Because sendmail frightens me, I'm lazy, and what I have now > basically "works" and I don't want to break anything. I've run sendmail, qmail and postfix. I had a love affair with qmail -- I used to love how it would push the load average on my little cobalt qube (16 M of RAM) to 20 while sending more than 1000 messages per minute. In bigger installations I had all sorts of trouble, but the killer is that Dan Bernstein doesn't want to maintain qmail and his license doesn't let anybody fork it. You ~can~ put together a system that can do spam filtering, sender authentication, you name it, but you're going to put in a ~lot~ of patches and have a frankensystem that's different from anybody elses frankensystem. I've run a postfix installation, and I've been pretty happy with it. It's pretty easy to set up virus and spam filtering with postfix, and cyrus is a great back end, although there's more system integration involved than average newbie would want. I had trouble during the virus crises last year, and had to abandon an old email address that would get 50,000+ viruses a day. (/var fills up with log entries from the virus checker, etc.) Since then the system will go for months without intervention. I've had a job where we use sendmail, and have even had to deal with RHEL 3 kernel bugs that caused sendmail to fail. (Upgrade to 2.6 solved this) Sendmail isn't so bad, but the trouble is that the online documentation is useless; if you can get the big O'Reilly book on it, Sendmail isn't hard to configure at all. > > >> I think Alan's wrong to suggest that there's no middle ground between >> caring about how easy stuff is to configure, and needing a complete >> point-and-drool configuration GUI for it. We don't _have_ a GUI >> configuration tool for any MTA, but we do have a web browser and the >> excellent and fully indexed Exim documentation, and a bunch of useful >> default features commented out but ready to use in the default config >> file. > I really like the way configuration files work in Red Hat and Fedora. I love /etc/sysconfig. I hate the graphical configuration tools. It's not that I hate the idea of them; the user interfaces for most of them are sound. (They ought to be since they rip off Windows) The trouble is that the authors seemed to quit working on them at the time they reached the 80% working level. A graphical configuration tool that screws up occasionally and needs workarounds is a big waste of time -- particularly when I know my way around /etc/sysconfig and can make any changes I want in thirty seconds with "sudo emacs." I'm all for graphical configuration tools, but configuration tools that work 80% are worse than graphical configuration tools that don't work at all. From ph18 at cornell.edu Wed Feb 23 16:21:38 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Wed, 23 Feb 2005 11:21:38 -0500 Subject: Exim as default MTA. In-Reply-To: <421C8213.30502@donut.dk> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <1109133846.8101.7.camel@rivendell.home.local> <421C8213.30502@donut.dk> Message-ID: On Wed, 23 Feb 2005 14:16:03 +0100, Cream wrote: > How are Exim & Postfix at handling several virtual domains? (with same > user@ names?) Postfix is great at this. It's solution isn't as elegant and flexible as qmail's, but it's fine. From cmadams at hiwaay.net Wed Feb 23 16:37:09 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Feb 2005 10:37:09 -0600 Subject: setgroups() moved? In-Reply-To: <20050223161208.GR853@devserv.devel.redhat.com> References: <1109174768.3349.6.camel@localhost.localdomain> <20050223161208.GR853@devserv.devel.redhat.com> Message-ID: <20050223163709.GB924815@hiwaay.net> Once upon a time, Jakub Jelinek said: > You haven't read the man page carefully: > SYNOPSIS > #include > #include > > int getgroups(int size, gid_t list[]); > > #include > > int setgroups(size_t size, const gid_t *list); > > I.e. for getgroups you need sys/types.h and unistd.h and for setgroups > also grp.h. Why is it done this way? The other OSes I have access to (Tru64 4.0G/5.1A and Solaris 9) don't require grp.h to get setgroups(). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kmaraas at broadpark.no Wed Feb 23 16:51:26 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Wed, 23 Feb 2005 17:51:26 +0100 Subject: setgroups() moved? In-Reply-To: <20050223161208.GR853@devserv.devel.redhat.com> References: <1109174768.3349.6.camel@localhost.localdomain> <20050223161208.GR853@devserv.devel.redhat.com> Message-ID: <1109177486.3349.8.camel@localhost.localdomain> ons, 23,.02.2005 kl. 11.12 -0500, skrev Jakub Jelinek: >On Wed, Feb 23, 2005 at 05:06:07PM +0100, Kjartan Maraas wrote: >> Hi. >> >> It looks like this function moved? The man page says: >> >> SYNOPSIS >> #include >> #include >> >> but it seems like it's really living in : >> >> [kmaraas at localhost xpl]$ grep setgroups /usr/include/*.h >> /usr/include/grp.h:extern int setgroups (size_t __n, __const __gid_t >> *__groups) __THROW; >> >> What's the right way of getting at this function? Preferrably in a way >> that works with other distros/OSes? > >You haven't read the man page carefully: >SYNOPSIS > #include > #include > > int getgroups(int size, gid_t list[]); > > #include > > int setgroups(size_t size, const gid_t *list); > >I.e. for getgroups you need sys/types.h and unistd.h and for setgroups >also grp.h. Indeed, sorry for being a bit quick on the trigger. Cheers Kjartan From dragoran at feuerpokemon.de Wed Feb 23 16:52:17 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 23 Feb 2005 17:52:17 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109168838.6581.25.camel@pensja.lam.pl> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> Message-ID: <421CB4C1.9010108@feuerpokemon.de> Leszek Matok wrote: >Dnia 23-02-2005, ?ro o godzinie 14:59 +0100, dragoran napisa?(a): > > >>Whe should try it again. 700MB CDs aren't something rare now ... >> >> >IIRC, it was tried in RHL 7.3.93, it was 2,5 years ago, and even then I >thought the same as you. 2,5 years ago 700 MiB CD-R-s were cheaper than >650 MiB and now it's even hard to get 650 MiB blank disc (with an >exception on some "audio" 74 min CD-R-s worth 10 times the price of >standard 80 min CD-R). My 8-year-old CD burner can burn 90 min CD-R-s >with no problem at all. But if all of it wasn't enough 2 years ago, it's >not enough today, either. > >I guess the problems were connected to older hardware, but remmeber >today Fedora doesn't include support for machines older than i586 and >doesn't even include support for some low-end 586s. Remember Anaconda >won't run on system with less than 64 MiB memory (the RULE project >looked nice, but it's not very active nowadays) and for graphical >install (Fedora is the desktop distro, remember) it requires 192 MiB of >system RAM according to FC3 release notes. Do we really still need to >think about machines that cannot use 700 MiB discs? :) > >Lam > > > Which kind of hardware cannot use 700Mib discs? Can't think of any (atleast any which has the minimum requiments to run fedora...) From pmatilai at welho.com Wed Feb 23 16:55:50 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 23 Feb 2005 18:55:50 +0200 Subject: FC4 slimfast slimfest In-Reply-To: <421CB4C1.9010108@feuerpokemon.de> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> Message-ID: <1109177751.24989.1.camel@chip.laiskiainen.org> On Wed, 2005-02-23 at 17:52 +0100, dragoran wrote: > > > Which kind of hardware cannot use 700Mib discs? Can't think of any > (atleast any which has the minimum requiments to run fedora...) People have all sorts of weird hardware on their test systems etc. My testbox which is a PIII/500Mhz and meeting the minimum requirements otherwise has a truly ancient 4x cd-drive for example :) - Panu - From tsilims at gmail.com Wed Feb 23 17:03:58 2005 From: tsilims at gmail.com (m g) Date: Wed, 23 Feb 2005 11:03:58 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <200502212237.38864.ronny-vlug@vlugnet.org> References: <200502212237.38864.ronny-vlug@vlugnet.org> Message-ID: > HelixPlayer and/or xmms HelixPlayer, perhaps. But *not* xmms. The # of new users on fedora-list and #fedora asking about mp3 support is already too high. I understand the reasoning for separating xmms and xmms-mp3 (although I think putting a warning on xmms telling how to get mp3 support would be nice) but removing xmms altogether will just make things worse. -- MG From buildsys at redhat.com Wed Feb 23 17:33:00 2005 From: buildsys at redhat.com (Build System) Date: Wed, 23 Feb 2005 12:33:00 -0500 Subject: rawhide report: 20050223 changes Message-ID: <200502231733.j1NHX0sF028880@porkchop.devel.redhat.com> New package gv A X front-end for the Ghostscript PostScript(TM) interpreter. Removed package xffm Removed package pccts Removed package xfwm4-themes Removed package xfprint Removed package xfdesktop Removed package xfwm4 Removed package xemacs-sumo Removed package xffm-icons Updated Packages: Canna-3.7p3-11 -------------- * Tue Feb 22 2005 Akira TAGOH - 3.7p3-11 - updates to cannadic-0.95c abiword-1:2.2.4-1 ----------------- * Tue Feb 22 2005 Caolan McNamara - 1:2.2.4-1 - bump to latest stable version - drop integrated nautilus depend patch - drop integrated libwpd depend patch apel-10.6-6 ----------- * Tue Feb 22 2005 Elliot Lee 10.6-6 - Remove xemacs cdrdao-1.1.9-8 -------------- * Tue Feb 22 2005 Karsten Hopp 1.1.9-8 - cdrdao builds just fine without the pccts package and uses its own pccts copy. cups-1:1.1.23-11 ---------------- * Tue Feb 22 2005 Tim Waugh 1:1.1.23-11 - UTF-8-ify spec file (bug #149293). gdb-6.3.0.0-0.29 ---------------- * Tue Feb 22 2005 Andrew Cagney 6.3.0.0-0.29 - Modify gdb-6.3-dwattype0-20050201.patch to check for a zero address and not zero unsnd. Fix BE 32- vs 64-bit problem. * Mon Feb 21 2005 Andrew Cagney 6.3.0.0-0.28 - Back port patch adding symfile-mem.o to all GNU/Linux builds. Fix BZ 146087. * Wed Feb 16 2005 Jeff Johnston 6.3.0.0-0.27 - Bump up release number. logrotate-3.7.1-7 ----------------- * Tue Feb 22 2005 Peter Vrabec - do not use tmpfile to run script anymore (#149270) netatalk-2:2.0.2-1 ------------------ * Mon Feb 21 2005 Jason Vas Dias - Upgraded to upstream version 2.0.2 . * Tue Jun 15 2004 Elliot Lee - rebuilt * Tue Mar 02 2004 Elliot Lee - rebuilt postgresql-8.0.1-2 ------------------ * Mon Feb 21 2005 Tom Lane 8.0.1-2 - Repair improper error message in init script when PGVERSION doesn't match. - Arrange for auto update of version embedded in init script. qt-1:3.3.4-5 ------------ * Tue Feb 22 2005 Than Ngo 1:3.3.4-5 - fix application crash when input methode not available (bug #140658) - remove .moc/.obj - add qt-copy patch to fix KDE #80072 radvd-0.7.3-1 ------------- * Mon Feb 21 2005 Jason Vas Dias 0.7.3-1 - Upgrade to radvd-0.7.3 - add execshield -fPIE / -pie compile / link options * Mon Feb 21 2005 Pekka Savola 0.7.3-1 - 0.7.3. * Mon Oct 28 2002 Pekka Savola - 0.7.2. rpmdb-fedora-1:4-0.20050223 --------------------------- ttcp-1.12-12 ------------ * Tue Feb 22 2005 Radek Vokal - implement full IPv6 support (server uses ipv6 mapped addresses for ipv4) - fix a few warnings - added -I option to specify network interface - added multicast support - added -w option to specify microsecond delay between each write - multiple processes can listen to same port - previous patch cleaned w3m-el-1.4.3-4 -------------- * Tue Feb 22 2005 Elliot Lee 1.4.3-4 - Remove xemacs From Nicolas.Mailhot at laPoste.net Wed Feb 23 18:44:16 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 23 Feb 2005 19:44:16 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <9g6l11p7ue9pcmk7nb65fjqq2v592ies5f@4ax.com> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <9g6l11p7ue9pcmk7nb65fjqq2v592ies5f@4ax.com> Message-ID: <1109184257.3076.31.camel@rousalka.dyndns.org> Le lundi 21 f?vrier 2005 ? 22:58 -0500, Gerald Henriksen a ?crit : >Perhaps most importantly though is that Novell is pushing Mono (C#) >and Red Hat is pushing Java. If Red Hat doesn't even include Java in >Fedora then that compromises the Red Hat message. Is this advocacy? >Yes. But sometimes you just can't avoid it. Moreover Red Hat pushes *free* java, and there are precious few other supporters. At one point you have to be realistic - if you want linux to keep the traction it currently has in the server/entreprise space (traction of which FC is a direct side effect) you need a high-level langage with rich libraries such as java. If you want this successful linux to be free that includes the high-level langage stack itself. For this to happen someone that cares about the free part and has a large developer mindshare must release this stack in a form that does not require days of installations to start coding. Right now that means RH+FC+gcj. Sure you can cull java. Users won't care. Don't come back crying by FC5/6 time when RHEL goes closed java, FC has to accept mono, the free java stacks fades like blackdown, and a lot of talented people that contributed to it are lost to the FOSS movement (getting free java to the level it is now is no small feat, the easy way is just to accept being herded by Sun and big vendors, if after all this work an emblematic Linux player like Red Hat closes the door I can imagine a lot of people will give up in disgust). One of the reasons I like FC (and Red Hat Linux before that) is it dares taking difficult decisions like going full UTF-8, testing SELinux, knowing the eventual result is worth the pain of including stuff no one tried before. I'd be disappointed if FC where to lose that long-term view and refuse to include stuff because it's not mainstream yet. Without early adopters like FC Linux development will slow down drastically. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Wed Feb 23 18:53:33 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 23 Feb 2005 19:53:33 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109039269.6303.39.camel@unknown.local.lan> References: <20050221211934.GD31765@nostromo.devel.redhat.com> <20050221220747.GD1027233@hiwaay.net> <20050221225037.GA398@nostromo.devel.redhat.com> <20050222021100.GB663812@hiwaay.net> <1109039269.6303.39.camel@unknown.local.lan> Message-ID: <1109184815.3076.38.camel@rousalka.dyndns.org> Le lundi 21 f?vrier 2005 ? 20:27 -0600, Phil Muldoon a ?crit : > applications that aren't the infamous applet example. > >Regardless of whether you like Java, or Eclipse, there is a lot of open >source work going on with both. The Eclipse community is huge and >thriving community (eclipse.org), that has coverage for many, many >languages and environments (including C/C++/Python/Perl et al). Several >other distributions (like Debian, Gentoo etc) already have it integrated >into their systems. One point to remember however is that a lot of contributors to FOSS java projects are quite happy with a sort-of-free java platform (with the core part being controlled by Sun). There are precious few actors that can make a completely free java a reality if even Red Hat closes the door on it. Just take a look at the mp3 situation. Free java will require some changes in upstream java projects. How easy do you think it'll be to ask for them if FC does not even eats its own dog food ? -------------- 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 Lam at Lam.pl Wed Feb 23 18:57:56 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 19:57:56 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109177751.24989.1.camel@chip.laiskiainen.org> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> Message-ID: <1109185076.6581.29.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 18:55 +0200, Panu Matilainen napisa?(a): > People have all sorts of weird hardware on their test systems etc. My > testbox which is a PIII/500Mhz and meeting the minimum requirements > otherwise has a truly ancient 4x cd-drive for example :) All right, but doesn't it read 700 MiB CD-R-s? I have one ancient 2x drive (in a computer which doesn't meet any of the requirements) and it does! :) Lam From Lam at Lam.pl Wed Feb 23 19:05:00 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 20:05:00 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <200502212237.38864.ronny-vlug@vlugnet.org> Message-ID: <1109185501.6581.34.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 11:03 -0600, m g napisa?(a): > I think putting a warning on xmms telling how to get mp3 support would > be nice Isn't it called "contributory infrigement"? I vote for non-US version of Fedora Core including all the goodies we Europeans can have legally :) Lam From rdieter at math.unl.edu Wed Feb 23 19:08:20 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Feb 2005 13:08:20 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109185501.6581.34.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> Message-ID: <421CD4A4.7030407@math.unl.edu> Leszek Matok wrote: > Dnia 23-02-2005, ?ro o godzinie 11:03 -0600, m g napisa?(a): > >>I think putting a warning on xmms telling how to get mp3 support would >>be nice > > Isn't it called "contributory infrigement"? > > I vote for non-US version of Fedora Core including all the goodies we > Europeans can have legally :) You mean something like http://rpm.livna.org/ (-: -- Rex From dwmw2 at infradead.org Wed Feb 23 19:10:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 19:10:22 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109185501.6581.34.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> Message-ID: <1109185822.5420.1.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 20:05 +0100, Leszek Matok wrote: > I vote for non-US version of Fedora Core including all the goodies we > Europeans can have legally :) There's not _that_ much which we in the Free World would add back to Fedora -- what's wrong with having it in Livna? -- dwmw2 From Lam at Lam.pl Wed Feb 23 19:15:27 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 20:15:27 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109185822.5420.1.camel@hades.cambridge.redhat.com> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> Message-ID: <1109186127.6581.39.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 19:10 +0000, David Woodhouse napisa?(a): > There's not _that_ much which we in the Free World would add back to > Fedora -- what's wrong with having it in Livna? Anvil's repo is almost all I need, but I'd like to have the packages on the CD, I don't want to be ashamed every time I give my copy of Fedora to someone and this someone comes back and says "your stupid Linux doesn't even play MP3-s". I play making such disks for my own joy, but I'm not the only person who can benefit from having such version. It's not a big deal to do this kind of isos and populate among the "more free" mirrors. Lam From Nicolas.Mailhot at laPoste.net Wed Feb 23 19:15:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 23 Feb 2005 20:15:07 +0100 Subject: Exim as default MTA. In-Reply-To: <1109156055.30247.79.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> <1109156055.30247.79.camel@localhost.localdomain> Message-ID: <1109186110.3076.49.camel@rousalka.dyndns.org> Le mercredi 23 f?vrier 2005 ? 10:54 +0000, David Woodhouse a ?crit : >On Tue, 2005-02-22 at 19:18 -0600, Josh Boyer wrote: >>Ok, I consider myself a "newbie" when it comes to MTAs. >> >>I currently run sendmail, but I've done as little as possible to get it >>working. I have no spam filtering at SMTP, no auto-sorting of messages >>into folders, basically nothing more than "get the mail to the spool". > >Sounds like you're a reasonably good test candidate; thanks for >volunteeering. > >>So I'll bite and look at the latest exim package in FC3 (I am running a >>server, so I can't really use rawhide). I'd be glad to report how it >>goes if anyone is interested. > >If you have time, please could you also try the same with postfix? And >if your own setup isn't very interesting, pick some other tasks like >configuring mailman etc. to amuse yourself. > >Like I said -- I'm far more adamant that sendmail should go, than I am >that Exim should be its replacement. I just happen to think that Exim is >a better choice. Right. I think most postfix users are not rabid exim haters either (at least I'm not). It seems both postfix and exim are good choices without any of the big warts that make people hate sendmail. IMHO it'd be a shame to drop postfix - it has spent quite a long time as a sendmail alternative in powertools then RHL and FC waiting for RH management to realise sendmail should die. I think the only reason the postfix crowd is silent right now people can't even imagine RH relenting on sendmail, while exim users still have some hope left. 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 dwmw2 at infradead.org Wed Feb 23 19:24:15 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 19:24:15 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109186127.6581.39.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> Message-ID: <1109186655.5420.4.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 20:15 +0100, Leszek Matok wrote: > Anvil's repo is almost all I need, but I'd like to have the packages > on the CD, I don't want to be ashamed every time I give my copy of > Fedora to someone and this someone comes back and says "your stupid > Linux doesn't even play MP3-s". I play making such disks for my own > joy, but I'm not the only person who can benefit from having such > version. It's not a big deal to do this kind of isos and populate > among the "more free" mirrors. As I understand it, FC5's anaconda should be able to handle additional repositories like Extras and Livna at install time -- isn't that enough? -- dwmw2 From Lam at Lam.pl Wed Feb 23 19:28:59 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 20:28:59 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109186655.5420.4.camel@hades.cambridge.redhat.com> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> Message-ID: <1109186939.6581.48.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 19:24 +0000, David Woodhouse napisa?(a): > As I understand it, FC5's anaconda should be able to handle additional > repositories like Extras and Livna at install time -- isn't that enough? Extras - yes, Livna - no. Only option for non-US repositories will be to enter its address by hand (and how can Linux newbie in Europe know the address of additional repository containing MP3 support if they don't even know MP3-s don't work out of the box?). Lam From pmatilai at welho.com Wed Feb 23 19:37:26 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 23 Feb 2005 21:37:26 +0200 Subject: FC4 slimfast slimfest In-Reply-To: <1109185076.6581.29.camel@pensja.lam.pl> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> Message-ID: <1109187446.24989.4.camel@chip.laiskiainen.org> On Wed, 2005-02-23 at 19:57 +0100, Leszek Matok wrote: > Dnia 23-02-2005, ?ro o godzinie 18:55 +0200, Panu Matilainen napisa?(a): > > People have all sorts of weird hardware on their test systems etc. My > > testbox which is a PIII/500Mhz and meeting the minimum requirements > > otherwise has a truly ancient 4x cd-drive for example :) > All right, but doesn't it read 700 MiB CD-R-s? I have one ancient 2x > drive (in a computer which doesn't meet any of the requirements) and it > does! :) Hmm, actually I don't know, haven't tried :) I do know the damn box wont boot from CD-RW's which is a major PITA for regular rawhide-testing. - Panu - From dwmw2 at infradead.org Wed Feb 23 19:49:08 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 19:49:08 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109186939.6581.48.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> Message-ID: <1109188148.5420.23.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 20:28 +0100, Leszek Matok wrote: > Extras - yes, Livna - no. Only option for non-US repositories will be to > enter its address by hand (and how can Linux newbie in Europe know the > address of additional repository containing MP3 support if they don't > even know MP3-s don't work out of the box?). You seem to know more about how anaconda will work with multiple repositories than I do. Given that the Extras ISOs will be built separately from the Core install ISOs, how will it know about them and have them hard-coded? Surely it has to be flexible enough to accept extra CDs which are generated _later_ than the Core install tree? -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 23 19:51:43 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 23 Feb 2005 20:51:43 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109187446.24989.4.camel@chip.laiskiainen.org> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> <1109187446.24989.4.camel@chip.laiskiainen.org> Message-ID: <20050223205143.49296f4d@python2> Panu Matilainen wrote : > On Wed, 2005-02-23 at 19:57 +0100, Leszek Matok wrote: > > Dnia 23-02-2005, ?ro o godzinie 18:55 +0200, Panu Matilainen napisa?(a): > > > People have all sorts of weird hardware on their test systems etc. My > > > testbox which is a PIII/500Mhz and meeting the minimum requirements > > > otherwise has a truly ancient 4x cd-drive for example :) > > All right, but doesn't it read 700 MiB CD-R-s? I have one ancient 2x > > drive (in a computer which doesn't meet any of the requirements) and it > > does! :) > > Hmm, actually I don't know, haven't tried :) I do know the damn box wont > boot from CD-RW's which is a major PITA for regular rawhide-testing. Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing Rawhide installs on those machines ever since the default boot media doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide boot images are just too volatile! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.19 0.44 0.41 From dwmw2 at infradead.org Wed Feb 23 19:58:03 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 19:58:03 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050223205143.49296f4d@python2> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> <1109187446.24989.4.camel@chip.laiskiainen.org> <20050223205143.49296f4d@python2> Message-ID: <1109188683.5420.26.camel@hades.cambridge.redhat.com> On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote: > Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing > Rawhide installs on those machines ever since the default boot media > doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide > boot images are just too volatile! I'm confused -- who tests rawhide with images anyway? Surely you just do a network install from an rsync'd install tree, and all you need for that is a TFTP-capable Grub on a boot floppy (or on a bootable CD)? -- dwmw2 From than at redhat.com Wed Feb 23 19:58:42 2005 From: than at redhat.com (Than Ngo) Date: Wed, 23 Feb 2005 20:58:42 +0100 Subject: kde-3.4 (3.3.92) in fc4 In-Reply-To: References: <421B3A3B.1070100@math.unl.edu> <421B44B8.4070603@redhat.com> Message-ID: <421CE072.30004@redhat.com> Rex Dieter wrote: > Than Ngo wrote: > >> Rex Dieter wrote: >> >>> I know it's getting close, but I think it's important to try to get >>> kde-3.4 (3.3.92beta2 at the moment) into fc4. If not, fedora users >>> will have to wait for fc5 before seeing this (please correct me if >>> I'm wrong). >> > >> i'm still waiting for KDE-3.4 RC1, which will be released on Feb 22. > > > Don't you mean Feb 26? That is what is posted on > http://developer.kde.org/development-versions/kde-3.4-release-plan.html > > -- Rex > yes, i mean Feb 26., sorry for typo ! Than From pmatilai at welho.com Wed Feb 23 20:03:16 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 23 Feb 2005 22:03:16 +0200 Subject: FC4 slimfast slimfest In-Reply-To: <1109188683.5420.26.camel@hades.cambridge.redhat.com> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> <1109187446.24989.4.camel@chip.laiskiainen.org> <20050223205143.49296f4d@python2> <1109188683.5420.26.camel@hades.cambridge.redhat.com> Message-ID: <1109188996.24989.20.camel@chip.laiskiainen.org> On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote: > On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote: > > Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing > > Rawhide installs on those machines ever since the default boot media > > doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide > > boot images are just too volatile! > > I'm confused -- who tests rawhide with images anyway? Heh, I do, and apparently Matthias as well. > Surely you just do a network install from an rsync'd install tree, and > all you need for that is a TFTP-capable Grub on a boot floppy (or on a > bootable CD)? I've never gotten around to try that :) - Panu - From feliciano.matias at free.fr Wed Feb 23 20:05:33 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 23 Feb 2005 21:05:33 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109184257.3076.31.camel@rousalka.dyndns.org> References: <20050221213354.GD17531@redhat.com> <20050221221523.GG11759@devserv.devel.redhat.com> <20050221222200.GH17531@redhat.com> <20050221222508.GJ11759@devserv.devel.redhat.com> <1109028396.5795.127.camel@dhcp-12.hsv.redhat.com> <421A708A.3B9939A6@jwz.org> <9g6l11p7ue9pcmk7nb65fjqq2v592ies5f@4ax.com> <1109184257.3076.31.camel@rousalka.dyndns.org> Message-ID: <1109189133.2622.6.camel@one.myworld> Le mercredi 23 f?vrier 2005 ? 19:44 +0100, Nicolas Mailhot a ?crit : > One of the reasons I like FC (and Red Hat Linux before that) is it dares > taking difficult decisions like going full UTF-8, testing SELinux, > knowing the eventual result is worth the pain of including stuff no one > tried before. +10 :-) -------------- 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 Lam at Lam.pl Wed Feb 23 20:07:13 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 21:07:13 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109188148.5420.23.camel@hades.cambridge.redhat.com> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> Message-ID: <1109189233.6581.60.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 19:49 +0000, David Woodhouse napisa?(a): > Given that the Extras ISOs will be built > separately from the Core install ISOs, how will it know about them and > have them hard-coded? Surely it has to be flexible enough to accept > extra CDs which are generated _later_ than the Core install tree? Yes, but Extras will be distributed by the same vendor, and Livna won't. The user will have to know about it and download additional iso from some site he doesn't know about and burn additional few-megabytes CD, or type in the yum/apt repository address of the same site (which he doesn't know about) upon/after install. Although it's possible to respin FC including Livna or Freshrpms, no magazine I know of have decided to do that on their cover disks, providing Fedora users incomplete desktop experience, while the other cover distros seem much more complete out of the box. I can make such disks and sell them/give them out to my friends, but how many people will still think Fedora simply "doesn't work"? Correct me if I'm wrong, but is Fedora aiming at being the desktop distro to steal marketshare from Windows, or being a distro for enthusiast Linux gurus loving to type three-line commands on their terminals in order to print file or burn it onto CD-R? I thought we're at least aiming to eventually becoming the former... Lam From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 23 20:12:09 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 23 Feb 2005 21:12:09 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109188996.24989.20.camel@chip.laiskiainen.org> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> <1109187446.24989.4.camel@chip.laiskiainen.org> <20050223205143.49296f4d@python2> <1109188683.5420.26.camel@hades.cambridge.redhat.com> <1109188996.24989.20.camel@chip.laiskiainen.org> Message-ID: <20050223211209.2b3fff03@python2> Panu Matilainen wrote : > On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote: > > On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote: > > > Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing > > > Rawhide installs on those machines ever since the default boot media > > > doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide > > > boot images are just too volatile! > > > > I'm confused -- who tests rawhide with images anyway? > > Heh, I do, and apparently Matthias as well. Yup :-) > > Surely you just do a network install from an rsync'd install tree, and > > all you need for that is a TFTP-capable Grub on a boot floppy (or on a > > bootable CD)? > > I've never gotten around to try that :) Neither have I. I guess I should try some day now that I know it can be done. But for me, the 2nd easiest after pure CD/DVD media install (w/o network) is booting off the tiny ISO image burnt to a CD-RW and doing a network install from a simple ftp, http or nfs server. This reminds me that I've just made a bootable DVD of RHEL4 yesterday, with all source rpms and html docs... works like a charm! (all new servers I purchased have DVD-ROMs, and yes, I'm lazy ;-)) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.51 0.50 0.37 From fedora at wir-sind-cool.org Wed Feb 23 20:16:41 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 23 Feb 2005 21:16:41 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109186127.6581.39.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> Message-ID: <20050223211641.34262885.fedora@wir-sind-cool.org> On Wed, 23 Feb 2005 20:15:27 +0100, Leszek Matok wrote: > Dnia 23-02-2005, __ro o godzinie 19:10 +0000, David Woodhouse napisa__(a): > > There's not _that_ much which we in the Free World would add back to > > Fedora -- what's wrong with having it in Livna? > > Anvil's repo is almost all I need, but I'd like to have the packages on > the CD, I don't want to be ashamed every time I give my copy of Fedora > to someone and this someone comes back and says "your stupid Linux > doesn't even play MP3-s". Then do a better job at educating that person about extra packages and how to get them easily. His choice of words ("stupid") is inappropriate already. More friendlier of him would be to ask about how to add mp3 support, in case you had not warned him earlier. From brugolsky at telemetry-investments.com Wed Feb 23 20:18:49 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 23 Feb 2005 15:18:49 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <1109188996.24989.20.camel@chip.laiskiainen.org> References: <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> <1109187446.24989.4.camel@chip.laiskiainen.org> <20050223205143.49296f4d@python2> <1109188683.5420.26.camel@hades.cambridge.redhat.com> <1109188996.24989.20.camel@chip.laiskiainen.org> Message-ID: <20050223201849.GB11385@ti64.telemetry-investments.com> On Wed, Feb 23, 2005 at 10:03:16PM +0200, Panu Matilainen wrote: > On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote: > > On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote: > > > Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing > > > Rawhide installs on those machines ever since the default boot media > > > doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide > > > boot images are just too volatile! > > > > I'm confused -- who tests rawhide with images anyway? > > Heh, I do, and apparently Matthias as well. I recently installed the FC3 i386 DVD into a spare LV on my FC3 x86-64 box using QEMU. A bit slow, but usable. It now boots with either QEMU or UML. It should be quite easy to create a few scripts to test various install scenarios. Bill Rugolsky From cmadams at hiwaay.net Wed Feb 23 20:21:01 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Feb 2005 14:21:01 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109188148.5420.23.camel@hades.cambridge.redhat.com> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> Message-ID: <20050223202101.GF924815@hiwaay.net> Once upon a time, David Woodhouse said: > Given that the Extras ISOs will be built > separately from the Core install ISOs, There are no plans currently to make ISOs of Extras. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dwmw2 at infradead.org Wed Feb 23 20:49:20 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Feb 2005 20:49:20 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050223202101.GF924815@hiwaay.net> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> <20050223202101.GF924815@hiwaay.net> Message-ID: <1109191760.14445.1.camel@baythorne.infradead.org> On Wed, 2005-02-23 at 14:21 -0600, Chris Adams wrote: > Once upon a time, David Woodhouse said: > > Given that the Extras ISOs will be built > > separately from the Core install ISOs, > > There are no plans currently to make ISOs of Extras. I plan to make CDs of Extras/PPC. I don't know if people plan to do them for other architectures, but I suspect it'll happen. -- dwmw2 From Lam at Lam.pl Wed Feb 23 20:52:35 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 21:52:35 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050223211641.34262885.fedora@wir-sind-cool.org> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <20050223211641.34262885.fedora@wir-sind-cool.org> Message-ID: <1109191955.6581.78.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 21:16 +0100, Michael Schwendt napisa? (a): > Then do a better job at educating that person about extra packages and > how to get them easily. His choice of words ("stupid") is inappropriate > already. More friendlier of him would be to ask about how to add mp3 > support, in case you had not warned him earlier. In fact I warn and give instruction how to install xmms-mp3, disable librh_mp3.so, install mplayer etc., but only to few of my friends who want to try out Linux and can count on my support. I don't sell copies, but I can imagine the hell any Fedora CD/DVD seller has to go through :) The typical user who wants to try out Fedora is disappointed when they install for the first time. I for one don't want Linux to be 31337, I want it to be seen as an alternative to Windows or MacOS even by Windows/MacOS users, and that can happen only if such user doesn't get disgusted after even test installation. I don't care if the users go back to their systems if only they get the impression that Linux works. The bad thing is only if they go back and say "I had Linux on my box once, but it doesn't do this, this and this, and I had to find some third-party packages which I didn't know how to install, so it sucks". Of course the technical-savvy users will find the packages they need and find instructions on how to install them, but I thought we're aiming at making Fedora every-user-friendly :) Lam From tdiehl at rogueind.com Wed Feb 23 20:55:08 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 23 Feb 2005 15:55:08 -0500 (EST) Subject: FC4 slimfast slimfest In-Reply-To: <1109188996.24989.20.camel@chip.laiskiainen.org> References: <1109021140.24391.4.camel@one.myworld> <20050221213044.GF31765@nostromo.devel.redhat.com> <421C8C58.9020004@feuerpokemon.de> <1109168838.6581.25.camel@pensja.lam.pl> <421CB4C1.9010108@feuerpokemon.de> <1109177751.24989.1.camel@chip.laiskiainen.org> <1109185076.6581.29.camel@pensja.lam.pl> <1109187446.24989.4.camel@chip.laiskiainen.org> <20050223205143.49296f4d@python2> <1109188683.5420.26.camel@hades.cambridge.redhat.com> <1109188996.24989.20.camel@chip.laiskiainen.org> Message-ID: On Wed, 23 Feb 2005, Panu Matilainen wrote: > On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote: > > On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote: > > > Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing > > > Rawhide installs on those machines ever since the default boot media > > > doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide > > > boot images are just too volatile! > > > > I'm confused -- who tests rawhide with images anyway? > > Heh, I do, and apparently Matthias as well. > > > Surely you just do a network install from an rsync'd install tree, and > > all you need for that is a TFTP-capable Grub on a boot floppy (or on a > > bootable CD)? > > I've never gotten around to try that :) And if you already have grub installed on the machine another way to do it is to add something like this: title anaconda rawhide install root (hd0,0) kernel /grub/pxeboot/vmlinuz initrd /grub/pxeboot/initrd.img to the grub.conf and put the pxeboot kernel and initrd somewhere grub can find it. Obviously season it to taste. If you want to get fancy you can easially call a ks.cfg file to automate things more. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From fedora at wir-sind-cool.org Wed Feb 23 21:08:22 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 23 Feb 2005 22:08:22 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109189233.6581.60.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> <1109189233.6581.60.camel@pensja.lam.pl> Message-ID: <20050223220822.44d6e39d.fedora@wir-sind-cool.org> On Wed, 23 Feb 2005 21:07:13 +0100, Leszek Matok wrote: > Dnia 23-02-2005, __ro o godzinie 19:49 +0000, David Woodhouse napisa__(a): > > Given that the Extras ISOs will be built > > separately from the Core install ISOs, how will it know about them and > > have them hard-coded? Surely it has to be flexible enough to accept > > extra CDs which are generated _later_ than the Core install tree? > > Yes, but Extras will be distributed by the same vendor, and Livna won't. > The user will have to know about it and download additional iso from > some site he doesn't know about and burn additional few-megabytes CD, Users of a popular other operating system do that always for many (!) additional applications. Widely spread FAQs and HOWTOs will guide newbies appropriately, e.g. like http://fedorafaq.org does nowadays already. From fedora at wir-sind-cool.org Wed Feb 23 21:18:46 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 23 Feb 2005 22:18:46 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109191955.6581.78.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <20050223211641.34262885.fedora@wir-sind-cool.org> <1109191955.6581.78.camel@pensja.lam.pl> Message-ID: <20050223221846.57210620.fedora@wir-sind-cool.org> On Wed, 23 Feb 2005 21:52:35 +0100, Leszek Matok wrote: > Dnia 23-02-2005, __ro o godzinie 21:16 +0100, Michael Schwendt napisa__ > (a): > > Then do a better job at educating that person about extra packages and > > how to get them easily. His choice of words ("stupid") is inappropriate > > already. More friendlier of him would be to ask about how to add mp3 > > support, in case you had not warned him earlier. > > In fact I warn and give instruction how to install xmms-mp3, disable > librh_mp3.so, install mplayer etc., but only to few of my friends who > want to try out Linux and can count on my support. I don't sell copies, > but I can imagine the hell any Fedora CD/DVD seller has to go through :) > > The typical user who wants to try out Fedora is disappointed when they > install for the first time. I for one don't want Linux to be 31337, I > want it to be seen as an alternative to Windows or MacOS even by > Windows/MacOS users, and that can happen only if such user doesn't get > disgusted after even test installation. Don't you think you are exaggerating a lot here? Not only do you reduce the target group to "mp3 focused users who are not willing to read and learn how to add more software", you also judge about the entire distribution based on one or two missing features. If everything else works amazingly well and just mp3 support is missing and can be added quickly, a user is certainly not disgusted. As of FC3, additional repositories can be added to Yum by clicking on a single package on a well-configured web server. The graphical package utilities will become more capable and more user-friendly, too. From Lam at Lam.pl Wed Feb 23 21:30:31 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 22:30:31 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050223220822.44d6e39d.fedora@wir-sind-cool.org> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> <1109189233.6581.60.camel@pensja.lam.pl> <20050223220822.44d6e39d.fedora@wir-sind-cool.org> Message-ID: <1109194231.6581.98.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 22:08 +0100, Michael Schwendt napisa? (a): > Users of a popular other operating system do that always for many (!) > additional applications. Well, you may be right about applications which aren't present on the system. But XMMS is expected to be included and it is included, only it doesn't play most of music people have in their libraries. It can encourage them to encode oggs using grip if they have the CD-s (it only takes time), but some of their music will remain in MP3-s. Inclusion of castrated XMMS version makes impression that Linux has WinAmp-clone, only it doesn't play music :) Of course this is the first impression, but first impression is the most important! :) > Widely spread FAQs and HOWTOs will guide newbies > appropriately, e.g. like http://fedorafaq.org does nowadays already. Straight that up for me again: if fedorafaq.org tells about ways to enable MP3 support and others, can Red Hat make link to it from the Mozilla home page (file:///usr/share/doc/HTML/index.html in FC3) or would it be contributory infringement? Lam From moe at blagblagblag.org Wed Feb 23 21:48:08 2005 From: moe at blagblagblag.org (jeff) Date: Wed, 23 Feb 2005 14:48:08 -0700 Subject: FC4 slimfast slimfest [minifc3] In-Reply-To: References: Message-ID: <200502231448.08729.moe@blagblagblag.org> As an exercise I made the "smallest" FC3 CD image possible that installs, boots normal, brings up net, and can use yum. There are no broken dependencies. It uses 95 megs of RPMs. The full CD image is 288 megs, due to size of Fedora/base/*.img which could also be shrunk. If you're interested, take a look here: ftp://ftp.blagblagblag.org/pub/BLAG/contrib/minifc3/ -Jeff From Lam at Lam.pl Wed Feb 23 21:48:15 2005 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 23 Feb 2005 22:48:15 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <20050223221846.57210620.fedora@wir-sind-cool.org> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <20050223211641.34262885.fedora@wir-sind-cool.org> <1109191955.6581.78.camel@pensja.lam.pl> <20050223221846.57210620.fedora@wir-sind-cool.org> Message-ID: <1109195295.6581.118.camel@pensja.lam.pl> Dnia 23-02-2005, ?ro o godzinie 22:18 +0100, Michael Schwendt napisa? (a): > Not only do you reduce > the target group to "mp3 focused users who are not willing to read and > learn how to add more software", I didn't want to say that. But such people exist, don't deny it :) Also, there are people, who are willing to read and learn, but don't know, where to start and I think we could help them more with that (like my homepage proposal - release notes describing differences between FC(X-1) and FC(X) aren't interesting at all for a new user). > you also judge about the entire > distribution based on one or two missing features Not me - I'm the user who even hacked in-kernel device drivers to get his system running properly and I'm not afraid to use Google if I need an app, besides I know about many packages which aren't included in Fedora (I'll try to push some of them into Extras when I'm ready :)). I'm only saying there are people judging this way and the less reasons they will have to grumble, the better. > The graphical package utilities will become > more capable and more user-friendly, too. I'm counting on it and I want to say while there always is room for improvement, they do good job already. up2date refreshes its windows strangely when downloading, shows 0 KiB file size, doesn't show errata info (without RHN that is), but it's all my friends need to stay updated :) I'm all excited about the things going in Fedora Core, and if I say something can be done better, it's only because I think this will make Fedora better. Really! :) Lam From fedora at wir-sind-cool.org Wed Feb 23 21:57:49 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 23 Feb 2005 22:57:49 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109194231.6581.98.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> <1109189233.6581.60.camel@pensja.lam.pl> <20050223220822.44d6e39d.fedora@wir-sind-cool.org> <1109194231.6581.98.camel@pensja.lam.pl> Message-ID: <20050223225749.5bf6d45c.fedora@wir-sind-cool.org> On Wed, 23 Feb 2005 22:30:31 +0100, Leszek Matok wrote: > Dnia 23-02-2005, __ro o godzinie 22:08 +0100, Michael Schwendt napisa__ > (a): > > Users of a popular other operating system do that always for many (!) > > additional applications. > > Well, you may be right about applications which aren't present on the > system. But XMMS is expected to be included and it is included, only it > doesn't play most of music people have in their libraries. It can > encourage them to encode oggs using grip if they have the CD-s (it only > takes time), but some of their music will remain in MP3-s. Inclusion of > castrated XMMS version makes impression that Linux has WinAmp-clone, > only it doesn't play music :) Of course this is the first impression, > but first impression is the most important! :) No. The first impression is a graphical dialogue which pops up and explains the situation. Because exactly that is what happens in XMMS when user tries to play an mp3 file. User will then see where to get a full version of XMMS or an alternative media player. E.g. rpm.livna.org has BMP now. > > Widely spread FAQs and HOWTOs will guide newbies > > appropriately, e.g. like http://fedorafaq.org does nowadays already. > > Straight that up for me again: if fedorafaq.org tells about ways to > enable MP3 support and others, can Red Hat make link to it from the > Mozilla home page (file:///usr/share/doc/HTML/index.html in FC3) or > would it be contributory infringement? IANAL. Future will tell us. It's not possible to generalise. With regard to mp3, I believe that pointing end-users to software like XMMS can be done. -- http://www.newsforge.com/business/02/08/29/1633205.shtml?tid=17 "No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users." From alan at redhat.com Wed Feb 23 21:59:55 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 23 Feb 2005 16:59:55 -0500 Subject: FC4 slimfast slimfest In-Reply-To: <20050223202101.GF924815@hiwaay.net> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> <20050223202101.GF924815@hiwaay.net> Message-ID: <20050223215955.GB30934@devserv.devel.redhat.com> On Wed, Feb 23, 2005 at 02:21:01PM -0600, Chris Adams wrote: > Once upon a time, David Woodhouse said: > > Given that the Extras ISOs will be built > > separately from the Core install ISOs, > > There are no plans currently to make ISOs of Extras. There are no plans for anyone in Red Hat to make ISO's of extras.. From notting at redhat.com Wed Feb 23 22:06:34 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 17:06:34 -0500 Subject: Fedora Core 4 Test 1 Status - Slip Message-ID: <20050223220634.GA5849@nostromo.devel.redhat.com> Looking at the overlap of the FC4 schedule with the GCC 4.0 schedule, it appears that shipping GCC 4.0 in FC4 has become viable. In order to avoid a large duplication of bandwidth by rebuilding with GCC 4.0 between test releases, Fedora Core 4 Test 1 has now slipped two weeks to allow for integration of a GCC 4.0 snapshot, and rebuilds against it. Fedora Core 4 Test 1 is now scheduled for March 14; the schedule at http://fedora.redhat.com/participate/schedule/ will be updated shortly. Quick FAQs: - Is GCC 4.0 released yet? No. It's likely to be released around mid-April. - Does that mean Fedora Core 4 will ship with a pre-release compiler? We're not *that* crazy. If GCC 4.0 is delayed, we will either revert, or slip. - What's so cool about GCC 4.0? GCC 4.0 includes: - new intermediate languages that allow for new/better optimizations http://gcc.gnu.org/projects/tree-ssa/ As part of this, this allows for better compile and run-time memory checking and overflow protection. - better and more complete Java support - Fortran 95 support - Is GCC 4.0 ABI compatbile with GCC-3.4.x? - For C/C++, yes. Bill From cmadams at hiwaay.net Wed Feb 23 22:12:40 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Feb 2005 16:12:40 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <20050223090158.17108.qmail@web8501.mail.in.yahoo.com> References: <20050222194235.GA25243@nostromo.devel.redhat.com> <20050223090158.17108.qmail@web8501.mail.in.yahoo.com> Message-ID: <20050223221240.GH924815@hiwaay.net> Once upon a time, Rahul Sundaram said: > again relying on third parties who might not have the > knowledge or infrastructure is not very useful. its > trivially easy to burn a set of ISO images and > redistribute the CD's. creating ISO images from the > rpms doesnt seem to be that easy. Am I mistaken? Making a DVD probably isn't too hard (it somewhat depends on how anaconda will handle things), since the total size of Extras for one arch is under 4.5G. Making CDs will not be as straight-forward, since it won't all fit on one. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwboyer at jdub.homelinux.org Wed Feb 23 22:17:10 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 23 Feb 2005 16:17:10 -0600 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223220634.GA5849@nostromo.devel.redhat.com> References: <20050223220634.GA5849@nostromo.devel.redhat.com> Message-ID: <20050223221710.GA15975@yoda.jdub.homelinux.org> On Wed, Feb 23, 2005 at 05:06:34PM -0500, Bill Nottingham wrote: > Looking at the overlap of the FC4 schedule with the GCC 4.0 schedule, > it appears that shipping GCC 4.0 in FC4 has become viable. > > In order to avoid a large duplication of bandwidth by rebuilding > with GCC 4.0 between test releases, Fedora Core 4 Test 1 has now > slipped two weeks to allow for integration of a GCC 4.0 snapshot, > and rebuilds against it. This may be an obvious question, but how do non-x86 architectures play into this? If there issues with these architectures and GCC 4.0, will Fedora Core 4 revert to GCC 3? I ask because I saw rumblings of some ppc32/gcc4 problems today. It may be a false alarm, but the question still stands. Feel free to add it to the FAQ :). josh From jakub at redhat.com Wed Feb 23 22:24:36 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 23 Feb 2005 17:24:36 -0500 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223221710.GA15975@yoda.jdub.homelinux.org> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <20050223221710.GA15975@yoda.jdub.homelinux.org> Message-ID: <20050223222436.GV853@devserv.devel.redhat.com> On Wed, Feb 23, 2005 at 04:17:10PM -0600, Josh Boyer wrote: > This may be an obvious question, but how do non-x86 architectures play into > this? If there issues with these architectures and GCC 4.0, will Fedora Core 4 > revert to GCC 3? > > I ask because I saw rumblings of some ppc32/gcc4 problems today. It may be a > false alarm, but the question still stands. Feel free to add it to the FAQ :). Would appreciate to know about any such rumblings ;). If it is reported upstream, then upstream PRs numbers, otherwise file bugs in our bugzilla. For the rebuild gcc4 needs to work on all 7 arches rawhide is built on. Jakub From davej at redhat.com Wed Feb 23 22:28:20 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 23 Feb 2005 17:28:20 -0500 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223222436.GV853@devserv.devel.redhat.com> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <20050223221710.GA15975@yoda.jdub.homelinux.org> <20050223222436.GV853@devserv.devel.redhat.com> Message-ID: <20050223222819.GA22253@redhat.com> On Wed, Feb 23, 2005 at 05:24:36PM -0500, Jakub Jelinek wrote: > On Wed, Feb 23, 2005 at 04:17:10PM -0600, Josh Boyer wrote: > > This may be an obvious question, but how do non-x86 architectures play into > > this? If there issues with these architectures and GCC 4.0, will Fedora Core 4 > > revert to GCC 3? > > > > I ask because I saw rumblings of some ppc32/gcc4 problems today. It may be a > > false alarm, but the question still stands. Feel free to add it to the FAQ :). > > Would appreciate to know about any such rumblings ;). > If it is reported upstream, then upstream PRs numbers, otherwise file bugs in our > bugzilla. > For the rebuild gcc4 needs to work on all 7 arches rawhide is built on. http://lkml.org/lkml/2005/2/23/119 Dave From djotaku1282 at yahoo.com Wed Feb 23 22:29:25 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Wed, 23 Feb 2005 14:29:25 -0800 (PST) Subject: pup Message-ID: <20050223222925.45377.qmail@web50801.mail.yahoo.com> I think about a dozen digests ago someone mentioned a program called pup replacing yum. Is there somewhere I can look to see information about this program? Is pup to yum as synaptic to apt-get or is it completely independent? Thanks, Eric ---- http://www.ericsbinaryworld.com __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From elanthis at awesomeplay.com Wed Feb 23 22:41:02 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 23 Feb 2005 17:41:02 -0500 Subject: pup In-Reply-To: <20050223222925.45377.qmail@web50801.mail.yahoo.com> References: <20050223222925.45377.qmail@web50801.mail.yahoo.com> Message-ID: <1109198463.15371.0.camel@stargrazer.home.awesomeplay.com> On Wed, 2005-02-23 at 14:29 -0800, The DJ wrote: >I think about a dozen digests ago someone mentioned a >program called pup replacing yum. Is there somewhere >I can look to see information about this program? Is >pup to yum as synaptic to apt-get or is it completely >independent? https://www.redhat.com/archives/fedora-config-list/2005-January/msg00017.html > >Thanks, >Eric >---- >http://www.ericsbinaryworld.com > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - Helps protect you from nasty viruses. >http://promotions.yahoo.com/new_mail > -- Sean Middleditch From paul at all-the-johnsons.co.uk Wed Feb 23 22:50:07 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 23 Feb 2005 22:50:07 +0000 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223220634.GA5849@nostromo.devel.redhat.com> References: <20050223220634.GA5849@nostromo.devel.redhat.com> Message-ID: <1109199008.26638.28.camel@localhost.localdomain> Hi, >Looking at the overlap of the FC4 schedule with the GCC 4.0 schedule, >it appears that shipping GCC 4.0 in FC4 has become viable. Can we take it then that OOo2 should also be included given this slipage? TTFN Paul -- "I like blinking me" - Helen, Big Brother 2 contestant -------------- next part -------------- A 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 jwboyer at jdub.homelinux.org Wed Feb 23 22:53:01 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 23 Feb 2005 16:53:01 -0600 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223222819.GA22253@redhat.com> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <20050223221710.GA15975@yoda.jdub.homelinux.org> <20050223222436.GV853@devserv.devel.redhat.com> <20050223222819.GA22253@redhat.com> Message-ID: <20050223225301.GA15999@yoda.jdub.homelinux.org> On Wed, Feb 23, 2005 at 05:28:20PM -0500, Dave Jones wrote: > On Wed, Feb 23, 2005 at 05:24:36PM -0500, Jakub Jelinek wrote: > > > > Would appreciate to know about any such rumblings ;). > > If it is reported upstream, then upstream PRs numbers, otherwise file bugs in our > > bugzilla. > > For the rebuild gcc4 needs to work on all 7 arches rawhide is built on. > > http://lkml.org/lkml/2005/2/23/119 Yep, that's what I was talking about. I called it a rumbling because nobody has responded yet. josh From dcbw at redhat.com Wed Feb 23 22:56:56 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 23 Feb 2005 17:56:56 -0500 (EST) Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <1109199008.26638.28.camel@localhost.localdomain> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <1109199008.26638.28.camel@localhost.localdomain> Message-ID: On Wed, 23 Feb 2005, Paul wrote: > >Looking at the overlap of the FC4 schedule with the GCC 4.0 schedule, > >it appears that shipping GCC 4.0 in FC4 has become viable. > > Can we take it then that OOo2 should also be included given this > slipage? Given a May 26th Absolute Freeze, it gets a lot more likely, doesn't it :) But as with all things, it depends on whether OOo upstream keeps its release schedule. Dan From smooge at gmail.com Wed Feb 23 23:44:42 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 23 Feb 2005 16:44:42 -0700 Subject: Summary of Dropped Packages Message-ID: <80d7e409050223154464743b99@mail.gmail.com> I am trying to play pickup as quickly as possible while juggling my normal job. Is there a summary of all the packages that have been dropped to meet the 4 CDRom limit? I think xfce and cfengine are on that list.. but what else? -- Stephen J Smoogen. CSIRT/Linux System Administrator From rodd at clarkson.id.au Thu Feb 24 00:44:24 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 24 Feb 2005 11:44:24 +1100 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <1109140226.2361.21.camel@cutter> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <1109121565.4609.26.camel@localhost.localdomain> <1109123450.2361.4.camel@cutter> <1109124972.4609.52.camel@localhost.localdomain> <1109140226.2361.21.camel@cutter> Message-ID: <1109205864.3684.4.camel@trevally.redfishdemo.com> >>Would turning off selinux do it (as a work around)? >> > >setenforce 0 might be a good start, I dunno, for certain if it is >selinux causing it, though. > Yeah, turning of selinux fixed it (although I'm still not sure how to run the post scripts for all the packages that fails (hint hint)) I've actually been running without selinux for a couple of weeks now because my nose is to the grind stone and I need to use apache and mysql and for some reason I need to configure this to work (haven't had time to do so). With the update I turned selinux on by accident and it caused all this stuff. Turning if off I was able to run yum update and get the kernel and openssh-server to install. R From skvidal at phy.duke.edu Thu Feb 24 01:16:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 20:16:52 -0500 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <1109205864.3684.4.camel@trevally.redfishdemo.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <1109121565.4609.26.camel@localhost.localdomain> <1109123450.2361.4.camel@cutter> <1109124972.4609.52.camel@localhost.localdomain> <1109140226.2361.21.camel@cutter> <1109205864.3684.4.camel@trevally.redfishdemo.com> Message-ID: <1109207812.10915.41.camel@cutter> On Thu, 2005-02-24 at 11:44 +1100, Rodd Clarkson wrote: >>>Would turning off selinux do it (as a work around)? >>> >> >>setenforce 0 might be a good start, I dunno, for certain if it is >>selinux causing it, though. >> > >Yeah, turning of selinux fixed it (although I'm still not sure how to >run the post scripts for all the packages that fails (hint hint)) > >I've actually been running without selinux for a couple of weeks now >because my nose is to the grind stone and I need to use apache and mysql >and for some reason I need to configure this to work (haven't had time >to do so). > >With the update I turned selinux on by accident and it caused all this >stuff. Turning if off I was able to run yum update and get the kernel >and openssh-server to install. try this: touch /.autorelabel reboot. see if it works after that. it might not, of course, rawhide eats babies. -sv From pedro.lamarao at mndfck.org Thu Feb 24 03:28:55 2005 From: pedro.lamarao at mndfck.org (=?ISO-8859-1?Q?Pedro_Lamar=E3o?=) Date: Thu, 24 Feb 2005 00:28:55 -0300 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223220634.GA5849@nostromo.devel.redhat.com> References: <20050223220634.GA5849@nostromo.devel.redhat.com> Message-ID: <421D49F7.2010303@mndfck.org> Bill Nottingham wrote: [SNIP] > - What's so cool about GCC 4.0? > > GCC 4.0 includes: > > - new intermediate languages that allow for new/better optimizations > http://gcc.gnu.org/projects/tree-ssa/ > > As part of this, this allows for better compile and run-time memory > checking and overflow protection. > > - better and more complete Java support > - Fortran 95 support - The default C++ allocator is non-generic and optimized for multithreaded applications. If I recall correctly, OpenOffice.org relies on libstdc++. http://gcc.gnu.org/ml/libstdc++/2005-02/msg00061.html - GCC 4.0 offers the possibility of defining symbols as "hidden", minimizing the overhead of shared object dynamic loading. There's some information on how this is useful here: http://people.redhat.com/drepper/dsohowto.pdf A full list of the great new features is on: http://gcc.gnu.org/gcc-4.0/changes.html -- Pedro Lamar?o From notting at redhat.com Thu Feb 24 04:19:24 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 23:19:24 -0500 Subject: Summary of Dropped Packages In-Reply-To: <80d7e409050223154464743b99@mail.gmail.com> References: <80d7e409050223154464743b99@mail.gmail.com> Message-ID: <20050224041924.GA5236@nostromo.devel.redhat.com> Stephen J. Smoogen (smooge at gmail.com) said: > I am trying to play pickup as quickly as possible while juggling my > normal job. Is there a summary of all the packages that have been > dropped to meet the 4 CDRom limit? I think xfce and cfengine are on > that list.. but what else? >From http://fedoraproject.org/wiki/Extras_2fOrphanedPackages: Packages removed from Fedora Core 4 development tree on 2005-02-23 abiword ash asp2php aumix balsa bzflag cdp comsat dietlibc diskcheck exim freeciv ggv gnuchess gnumeric gpdf grip gv kdetoys koffice lapack lesstif libesmtp libtool-libs13 libxfce4mcs libxfce4util libxfcegui4 Maelstrom mew-xemacs octave openssl096 openssl096b pan pccts Regina sylpheed THE tuxracer wl-xemacs xboard xemacs xemacs-sumo xfce4-iconbox xfce4-panel xfce4-systray xfce-mcs-manager xfce-mcs-plugins xfce-utils xfdesktop xffm xffm-icons xfprint xfwm4 xfwm4-themes xloadimage xosview xsnow ytalk cfengine is not listed in this group simply because it wasn't in an actual FC release. But it's 'removed' as well. Bill From skvidal at phy.duke.edu Thu Feb 24 04:33:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 23:33:30 -0500 Subject: pup In-Reply-To: <20050223222925.45377.qmail@web50801.mail.yahoo.com> References: <20050223222925.45377.qmail@web50801.mail.yahoo.com> Message-ID: <1109219610.10915.52.camel@cutter> On Wed, 2005-02-23 at 14:29 -0800, The DJ wrote: >I think about a dozen digests ago someone mentioned a >program called pup replacing yum. Is there somewhere >I can look to see information about this program? Is >pup to yum as synaptic to apt-get or is it completely >independent? > pup is currently using the yum modules as a backend. -sv From notting at redhat.com Thu Feb 24 04:37:51 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Feb 2005 23:37:51 -0500 Subject: Summary of Dropped Packages In-Reply-To: <20050224041924.GA5236@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> Message-ID: <20050224043750.GB5490@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Stephen J. Smoogen (smooge at gmail.com) said: > > I am trying to play pickup as quickly as possible while juggling my > > normal job. Is there a summary of all the packages that have been > > dropped to meet the 4 CDRom limit? I think xfce and cfengine are on > > that list.. but what else? > > >From http://fedoraproject.org/wiki/Extras_2fOrphanedPackages: > > Packages removed from Fedora Core 4 development tree on 2005-02-23 > > abiword > ash > asp2php > aumix > balsa > bzflag > cdp > comsat > dietlibc > diskcheck > exim > freeciv > ggv > gnuchess > gnumeric > gpdf > grip > gv > kdetoys > koffice > lapack > lesstif > libesmtp > libtool-libs13 > libxfce4mcs > libxfce4util > libxfcegui4 > Maelstrom > mew-xemacs > octave > openssl096 > openssl096b > pan > pccts > Regina > sylpheed > THE > tuxracer > wl-xemacs > xboard > xemacs > xemacs-sumo > xfce4-iconbox > xfce4-panel > xfce4-systray > xfce-mcs-manager > xfce-mcs-plugins > xfce-utils > xfdesktop > xffm > xffm-icons > xfprint > xfwm4 > xfwm4-themes > xloadimage > xosview > xsnow > ytalk > > cfengine is not listed in this group simply because it wasn't > in an actual FC release. But it's 'removed' as well. Also: dbskkd-cdb FreeWnn kinput2 miniChinput nabi skkinput system-switch-im xcin (Non-IIMF input methods.) Bill From feliciano.matias at free.fr Thu Feb 24 04:57:36 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 05:57:36 +0100 Subject: Summary of Dropped Packages In-Reply-To: <20050224041924.GA5236@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> Message-ID: <1109221057.3817.5.camel@one.myworld> Le mercredi 23 f?vrier 2005 ? 23:19 -0500, Bill Nottingham a ?crit : > Stephen J. Smoogen (smooge at gmail.com) said: > > I am trying to play pickup as quickly as possible while juggling my > > normal job. Is there a summary of all the packages that have been > > dropped to meet the 4 CDRom limit? I think xfce and cfengine are on > > that list.. but what else? > > >From http://fedoraproject.org/wiki/Extras_2fOrphanedPackages: > > Packages removed from Fedora Core 4 development tree on 2005-02-23 > > (...) > exim ?!? Isn't sendmail "obsolete" and exim (or postfix) the future default ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Thu Feb 24 05:08:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 00:08:23 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109221057.3817.5.camel@one.myworld> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> Message-ID: <1109221703.10915.63.camel@cutter> >?!? >Isn't sendmail "obsolete" and exim (or postfix) the future default ? despite some rampant discussion on this list I don't remember that being decided anywhere. -sv From esr at thyrsus.com Thu Feb 24 05:08:26 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 24 Feb 2005 00:08:26 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109221703.10915.63.camel@cutter> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> <1109221703.10915.63.camel@cutter> Message-ID: <20050224050826.GA2934@thyrsus.com> seth vidal : > > >?!? > >Isn't sendmail "obsolete" and exim (or postfix) the future default ? > > despite some rampant discussion on this list I don't remember that being > decided anywhere. I've been staying out of the whole what-should-be-dropped discussion. But let me add my voice to the "sendmail's got to go" contingent. I don't care much what replaces it, either of postfix or exim would be an improvement. -- Eric S. Raymond From feliciano.matias at free.fr Thu Feb 24 05:15:28 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 06:15:28 +0100 Subject: Summary of Dropped Packages In-Reply-To: <1109221703.10915.63.camel@cutter> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> <1109221703.10915.63.camel@cutter> Message-ID: <1109222129.3817.12.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 00:08 -0500, seth vidal a ?crit : > >?!? > >Isn't sendmail "obsolete" and exim (or postfix) the future default ? > > despite some rampant discussion on this list I don't remember that being > decided anywhere. > OK, but in this case why only exim and not exim *and* postfix. If exim is the default for FC5, i don't think it's good idea to remove it in FC4. Or "Fedora team" decide to use postfix as default MTA and keep sendmail for compatibility. -------------- 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 fedora at wir-sind-cool.org Thu Feb 24 05:59:46 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 24 Feb 2005 06:59:46 +0100 Subject: Summary of Dropped Packages In-Reply-To: <20050224041924.GA5236@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> Message-ID: <20050224065946.2e97068f.fedora@wir-sind-cool.org> On Wed, 23 Feb 2005 23:19:24 -0500, Bill Nottingham wrote: > From http://fedoraproject.org/wiki/Extras/OrphanedPackages: > > Packages removed from Fedora Core 4 development tree on 2005-02-23 > -snip- > sylpheed -snip- I've planned to take that one if nobody else is more interested than me and after taking another look at the tarball and bugzilla. There's also the possibility to maintain it with more than one primary package owner. But maybe I like Evolution these days or give Sylpheed-claws another try (which is in Extras already), so claiming sylheed package ownership doesn't have high priority for me. When FC-3 split in Extras CVS happens, is it possible to transfer the "sylpheed" module from FC CVS, or do we simply import the last src.rpm from Rawhide? From manjil.dahal at gmail.com Thu Feb 24 06:27:38 2005 From: manjil.dahal at gmail.com (Manjil Dahal) Date: Wed, 23 Feb 2005 22:27:38 -0800 Subject: Summary of Dropped Packages In-Reply-To: <80d7e409050223154464743b99@mail.gmail.com> References: <80d7e409050223154464743b99@mail.gmail.com> Message-ID: hello, i am terying to make aan video player so can u tell me the necessary to develop the media player. i will be gratefull. if u give me nay idea about that. From dwmw2 at infradead.org Thu Feb 24 07:59:51 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 07:59:51 +0000 Subject: Summary of Dropped Packages In-Reply-To: <20050224043750.GB5490@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> Message-ID: <1109231991.4631.7.camel@localhost.localdomain> On Wed, 2005-02-23 at 23:37 -0500, Bill Nottingham wrote: >> Packages removed from Fedora Core 4 development tree on 2005-02-23 >> ... >> exim Er, do you mean exim-doc, which was split into a separate package? Exim itself is fairly tiny and is a potential candidate for being the default MTA. There was no discussion of removing Exim entirely, and it was shipped in FC3. -- dwmw2 From gildas.bayard at ac6.fr Thu Feb 24 08:15:08 2005 From: gildas.bayard at ac6.fr (Gildas Bayard) Date: Thu, 24 Feb 2005 09:15:08 +0100 Subject: nash, initrd, cpio... Message-ID: <1109232908.3603.3.camel@localhost.localdomain> Does anyone knows who I should ask about nash and cpio initrd support? (see my yesterday post) Or at least where to ask for someone who knows? Documentation is often out of date and I could not find any information about why does FC3 changes initrd format from ext2 fs to cpio archive... Gildas From laroche at redhat.com Thu Feb 24 08:14:36 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 24 Feb 2005 09:14:36 +0100 Subject: Summary of Dropped Packages In-Reply-To: <1109231991.4631.7.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> Message-ID: <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> On Thu, Feb 24, 2005 at 07:59:51AM +0000, David Woodhouse wrote: > On Wed, 2005-02-23 at 23:37 -0500, Bill Nottingham wrote: > >> Packages removed from Fedora Core 4 development tree on 2005-02-23 > >> ... > >> exim > > Er, do you mean exim-doc, which was split into a separate package? Exim > itself is fairly tiny and is a potential candidate for being the default > MTA. There was no discussion of removing Exim entirely, and it was > shipped in FC3. For exim I think we should continue to put it into FC-devel, but only exclude it from FC4 if the space requirements need this removal. greetings, Florian La Roche From skvidal at phy.duke.edu Thu Feb 24 08:20:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 03:20:59 -0500 Subject: Summary of Dropped Packages In-Reply-To: <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> Message-ID: <1109233259.10915.70.camel@cutter> >> >> Er, do you mean exim-doc, which was split into a separate package? Exim >> itself is fairly tiny and is a potential candidate for being the default >> MTA. There was no discussion of removing Exim entirely, and it was >> shipped in FC3. > >For exim I think we should continue to put it into FC-devel, but >only exclude it from FC4 if the space requirements need this removal. > >greetings, I'm thinking for the future - why don't we consider pulling this discussion off of fedora-devel and onto fedora-maintainers? Sound reasonable? -sv From feliciano.matias at free.fr Thu Feb 24 08:24:55 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 09:24:55 +0100 Subject: Summary of Dropped Packages In-Reply-To: <1109231991.4631.7.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> Message-ID: <1109233496.3817.25.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 07:59 +0000, David Woodhouse a ?crit : > On Wed, 2005-02-23 at 23:37 -0500, Bill Nottingham wrote: > >> Packages removed from Fedora Core 4 development tree on 2005-02-23 > >> ... > >> exim > > Er, do you mean exim-doc, which was split into a separate package? I am really again this idea ! Perhaps we could reduce the size of exim-doc. from exim-doc-4.43-1.FC3.1 : $ du -s /usr/share/doc/exim-doc-4.43/* /usr/share/doc/exim-doc-4.43/ 152 /usr/share/doc/exim-doc-4.43/config.samples 1340 /usr/share/doc/exim-doc-4.43/faq 3336 /usr/share/doc/exim-doc-4.43/html 1320 /usr/share/doc/exim-doc-4.43/pdf 2540 /usr/share/doc/exim-doc-4.43/ps 1512 /usr/share/doc/exim-doc-4.43/texinfo 10204 /usr/share/doc/exim-doc-4.43/ We can remove faq/ (already in html/) pdf/ ps/ and texinfo/ . In this case, we have : $ du -s /usr/share/doc/exim-doc-4.43/ 3492 /usr/share/doc/exim-doc-4.43/ Some examples : $ du -s gcc-3.4.2 postgresql-7.4.7 libxml2-devel-2.6.16 xorg-x11- doc-6.8.1.902 rpm-devel-4.3.2 qt-devel-3.3.3 8088 gcc-3.4.2 6956 postgresql-7.4.7 7832 libxml2-devel-2.6.16 10752 xorg-x11-doc-6.8.1.902 21852 rpm-devel-4.3.2 37136 qt-devel-3.3.3 Should we remove gcc, postgresql, libxml2, xorg-x11, rpm-devel, qt-devel doc ? Too bad. -------------- 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 laroche at redhat.com Thu Feb 24 08:27:30 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 24 Feb 2005 09:27:30 +0100 Subject: Summary of Dropped Packages In-Reply-To: <1109233259.10915.70.camel@cutter> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <20050224081436.GA6566@dudweiler.stuttgart.redhat.com> <1109233259.10915.70.camel@cutter> Message-ID: <20050224082730.GA6877@dudweiler.stuttgart.redhat.com> On Thu, Feb 24, 2005 at 03:20:59AM -0500, seth vidal wrote: > >> > >> Er, do you mean exim-doc, which was split into a separate package? Exim > >> itself is fairly tiny and is a potential candidate for being the default > >> MTA. There was no discussion of removing Exim entirely, and it was > >> shipped in FC3. > > > >For exim I think we should continue to put it into FC-devel, but > >only exclude it from FC4 if the space requirements need this removal. > > > >greetings, > > I'm thinking for the future - why don't we consider pulling this > discussion off of fedora-devel and onto fedora-maintainers? Sound > reasonable? Yes, that will be the right spot. greetings, Florian La Roche From feliciano.matias at free.fr Thu Feb 24 08:35:48 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 09:35:48 +0100 Subject: nash, cpio and linuxrc In-Reply-To: <1109174824.6309.16.camel@localhost.localdomain> References: <1109174824.6309.16.camel@localhost.localdomain> Message-ID: <1109234148.3817.35.camel@one.myworld> Le mercredi 23 f?vrier 2005 ? 17:07 +0100, Gildas Bayard a ?crit : > Hello, > > First of all, please direct me to an other mailing list if I'm going off > topic. > I've investigated a bit the initrd system and there are some questions I > could no find answers for: > - why are regular desktop distributions always using the initrd system? It's require for "root=LABEL=/" and udev. > I understand that this system is mandatory to load exotic scsi drivers > or add a pause when booting to usb but I wonder why it is always used > - on kernel 2.4 (red hat 9) the initrd image is an ext2 filesystems. For *your* system. My initrd also contain raid0 and dm-mod (see /sbin/mkinitrd and "man mkinitrd"). > It > contains a linuxrc nash script. On kernel 2.6 (fedora 3) the initrd is a > cpio archive and does not contains a linuxrc script. Could someone > briefly explain me why these differences? Particularly I wondering about > 3 things: > 1) I tried to repack my custom initrd ext2 filesystem into a cpio > archive and found that when packed as a cpio archive it's not executing > my linuxrc script (is it the way it's supposed to be?) use "/init". > 2) What are the differences between pivot_root and switch_root (new in > 2.6) ? > 3) Why using nash in the first place? nash is a mini-mini-mini-shell (bash is TTOOOO big). See "man nash". > Could we just wait until the end > of the linuxrc script? At that time the kernel would move to the new > root fs (whitout the need for pivot_root or switch_root) > > And finally, if I'm right the end of the nash script (after switch_root) > is never executed? > > Gildas > -------------- 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 sitsofe at yahoo.com Thu Feb 24 08:46:28 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Thu, 24 Feb 2005 08:46:28 +0000 Subject: udev + usb2 kernel race? In-Reply-To: <421B4211.9010600@redhat.com> References: <1108684064.4328.10.camel@galvatron.localdomain> <421B4211.9010600@redhat.com> Message-ID: <1109234788.4280.13.camel@galvatron.localdomain> On Tue, 2005-02-22 at 15:30 +0100, Harald Hoyer wrote: > Sitsofe Wheeler wrote: > > We have a computer acting as a server that locks hard (PS2 keyboard > > stops responding, prompt never returns, boot gets no further) when USB2 > > is enabled on FC3 (there were no lockups with FC1). I finally traced > > this down to being some sort of interaction between udev and USB2. The > > following steps reproduce the problem: > > > > Boot the kernel with init=/bin/sh > > mount -n -t proc /proc /proc > > mount -n -t sysfs /sys /sys > > /sbin/start_udev > > /sbin/modprobe uhci-hcd > > Does this sound like a known issue? > > > > not to me and the solution is strange... could you add a > > set -x > > after the first line of start_udev and look, where it hangs? I'll set up it up but I don't know when I can get results to you. People were pretty angry at me for taking the server down for one hour to debug the issue ("you have a workaround - isn't that enough?") and that time I had the excuse that a new kernel release had been issued for FC3. If there's anything else I can do at the same time please let me know because I can't take the server down at will... I've also reported the issue in bugzilla - https://bugzilla.redhat.com/beta/show_bug.cgi?id=149171 -- Sitsofe | http://sucs.org/~sits/ From pbrobinson at gmail.com Thu Feb 24 09:03:27 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 24 Feb 2005 17:03:27 +0800 Subject: Summary of Dropped Packages In-Reply-To: <20050224041924.GA5236@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> Message-ID: <5256d0b0502240103681d582b@mail.gmail.com> > Packages removed from Fedora Core 4 development tree on 2005-02-23 > > abiword > ash > asp2php > aumix > balsa > bzflag > cdp > comsat > dietlibc > diskcheck > exim > freeciv > ggv > gnuchess > gnumeric > gpdf > grip > gv > kdetoys > koffice > lapack > lesstif > libesmtp > libtool-libs13 > libxfce4mcs > libxfce4util > libxfcegui4 > Maelstrom > mew-xemacs > octave > openssl096 > openssl096b > pan > pccts > Regina > sylpheed > THE > tuxracer > wl-xemacs > xboard > xemacs > xemacs-sumo > xfce4-iconbox > xfce4-panel > xfce4-systray > xfce-mcs-manager > xfce-mcs-plugins > xfce-utils > xfdesktop > xffm > xffm-icons > xfprint > xfwm4 > xfwm4-themes > xloadimage > xosview > xsnow > ytalk > > cfengine is not listed in this group simply because it wasn't > in an actual FC release. But it's 'removed' as well. So with these removed from Core I assume they are going to be in Extras. Correct? In Extras will they continue to be maintained as before or will they need someone to step up and maintain them? The reason I ask is it would be a pity to see abiword and gnumeric disappear as I find them considerably faster than OOo and in the case of Abiword it supports a number of word files that don't work to well with OOo.I also use grip. While I'm happy for them to be in extras rather than core I would still like them to be around. Pete From crisppyf at gmail.com Thu Feb 24 09:08:11 2005 From: crisppyf at gmail.com (crisppy fernandes) Date: Thu, 24 Feb 2005 14:38:11 +0530 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <421D49F7.2010303@mndfck.org> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <421D49F7.2010303@mndfck.org> Message-ID: Hi all Apart from this list what all the places from where i can get the update information about FC4 if any known to you all then please give the pointer towards that. crisppy f From gildas.bayard at ac6.fr Thu Feb 24 09:13:19 2005 From: gildas.bayard at ac6.fr (Gildas Bayard) Date: Thu, 24 Feb 2005 10:13:19 +0100 Subject: nash, cpio and linuxrc In-Reply-To: <1109234148.3817.35.camel@one.myworld> References: <1109174824.6309.16.camel@localhost.localdomain> <1109234148.3817.35.camel@one.myworld> Message-ID: <1109236399.3603.15.camel@localhost.localdomain> Le jeudi 24 f?vrier 2005 ? 09:35 +0100, F?liciano Matias a ?crit : > Le mercredi 23 f?vrier 2005 ? 17:07 +0100, Gildas Bayard a ?crit : > > Hello, > > > > First of all, please direct me to an other mailing list if I'm going off > > topic. > > I've investigated a bit the initrd system and there are some questions I > > could no find answers for: > > - why are regular desktop distributions always using the initrd system? > > It's require for "root=LABEL=/" and udev. Ok. I'll look at that deeper. Thanx > > > I understand that this system is mandatory to load exotic scsi drivers > > or add a pause when booting to usb but I wonder why it is always used > > - on kernel 2.4 (red hat 9) the initrd image is an ext2 filesystems. > > For *your* system. My initrd also contain raid0 and dm-mod > (see /sbin/mkinitrd and "man mkinitrd"). No I mean the initrd file is an ext2 filesystem (whatever it contains) On FC3 it is a cpio archive. Why? And why when initrd is a cpio archive it would not load linuxrc? Answers to these question are not in man initrd, man nash... > > > It > > contains a linuxrc nash script. On kernel 2.6 (fedora 3) the initrd is a > > cpio archive and does not contains a linuxrc script. Could someone > > briefly explain me why these differences? Particularly I wondering about > > 3 things: > > 1) I tried to repack my custom initrd ext2 filesystem into a cpio > > archive and found that when packed as a cpio archive it's not executing > > my linuxrc script (is it the way it's supposed to be?) > > use "/init". Well I want to understand why my linuxrc is not run when in a cpio archive and again what the matter with the cpio archive > > > 2) What are the differences between pivot_root and switch_root (new in > > 2.6) ? > > 3) Why using nash in the first place? > > nash is a mini-mini-mini-shell (bash is TTOOOO big). See "man nash". man nash does not explain what is the rational for both pivot_root and switch_root (just give a small description). => Why pivot_root was not enough? => Why not wait until the end of linuxrc to jump to the new root fs? I would like to know how to get in touch with nash coders. On which forum or mailing list could they be hanging on? > > Could we just wait until the end > > of the linuxrc script? At that time the kernel would move to the new > > root fs (whitout the need for pivot_root or switch_root) > > > > And finally, if I'm right the end of the nash script (after switch_root) > > is never executed? > > > > Gildas > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From josh at bluga.net Thu Feb 24 09:20:57 2005 From: josh at bluga.net (Joshua Eichorn) Date: Thu, 24 Feb 2005 02:20:57 -0700 Subject: Summary of Dropped Packages In-Reply-To: <1109233496.3817.25.camel@one.myworld> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <20050224043750.GB5490@nostromo.devel.redhat.com> <1109231991.4631.7.camel@localhost.localdomain> <1109233496.3817.25.camel@one.myworld> Message-ID: <421D9C79.2040404@bluga.net> F?liciano Matias wrote: >Le jeudi 24 f?vrier 2005 ? 07:59 +0000, David Woodhouse a ?crit : > > >>On Wed, 2005-02-23 at 23:37 -0500, Bill Nottingham wrote: >> >> >>>>Packages removed from Fedora Core 4 development tree on 2005-02-23 >>>> ... >>>> exim >>>> >>>> >>Er, do you mean exim-doc, which was split into a separate package? >> >> > >I am really again this idea ! >Perhaps we could reduce the size of exim-doc. >from exim-doc-4.43-1.FC3.1 : >$ du -s /usr/share/doc/exim-doc-4.43/* /usr/share/doc/exim-doc-4.43/ >152 /usr/share/doc/exim-doc-4.43/config.samples >1340 /usr/share/doc/exim-doc-4.43/faq >3336 /usr/share/doc/exim-doc-4.43/html >1320 /usr/share/doc/exim-doc-4.43/pdf >2540 /usr/share/doc/exim-doc-4.43/ps >1512 /usr/share/doc/exim-doc-4.43/texinfo >10204 /usr/share/doc/exim-doc-4.43/ > >We can remove faq/ (already in html/) pdf/ ps/ and texinfo/ . >In this case, we have : >$ du -s /usr/share/doc/exim-doc-4.43/ >3492 /usr/share/doc/exim-doc-4.43/ > >Some examples : >$ du -s gcc-3.4.2 postgresql-7.4.7 libxml2-devel-2.6.16 xorg-x11- >doc-6.8.1.902 rpm-devel-4.3.2 qt-devel-3.3.3 >8088 gcc-3.4.2 >6956 postgresql-7.4.7 >7832 libxml2-devel-2.6.16 >10752 xorg-x11-doc-6.8.1.902 >21852 rpm-devel-4.3.2 >37136 qt-devel-3.3.3 > >Should we remove gcc, postgresql, libxml2, xorg-x11, rpm-devel, qt-devel >doc ? > >Too bad. > > Well in current rawhide there isn't much of a gain left except for tetex-doc. It almost seems silly to be worry about dropping exim when the 3rd largest package in the system (openoffice.org-i18n and eclipse-platform being larger), could at least be cut down in size a bit, it was only 30meg in fc2, and i doubt someone wrote 200 new pages of docs for it. Its kinda a confusing layout but it looks like most documents in it are both in pdf and dvi, plus there is a bunch of html documents and make files. 52M tetex-doc-3.0-2.i386.rpm 6.1M xorg-x11-doc-6.8.2-1.i386.rpm 4.7M postgresql-docs-8.0.1-2.i386.rpm 3.3M exim-doc-4.44-1.i386.rpm 2.8M openswan-doc-2.3.0-4.i386.rpm 2.5M python-docs-2.4-4.i386.rpm 2.2M kernel-doc-2.6.10-1.1149_FC4.noarch.rpm 1.5M docbook-style-xsl-1.68.1-1.noarch.rpm 1.2M ruby-docs-1.8.2-4.i386.rpm -josh From jakub at redhat.com Thu Feb 24 09:21:22 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 24 Feb 2005 04:21:22 -0500 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <421D49F7.2010303@mndfck.org> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <421D49F7.2010303@mndfck.org> Message-ID: <20050224092122.GZ853@devserv.devel.redhat.com> On Thu, Feb 24, 2005 at 12:28:55AM -0300, Pedro Lamar?o wrote: > - GCC 4.0 offers the possibility of defining symbols as "hidden", > minimizing the overhead of shared object dynamic loading. Well, visibility attribute have been there already in GCC 3.2.3-RH. -fvisibility=* and visibility attribute for classes that is new in upstream 4.0 has been backported to GCC 3.4.2-RH and later, so is already available in FC3/RHEL4 GCC. Jakub From feliciano.matias at free.fr Thu Feb 24 09:53:01 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 10:53:01 +0100 Subject: nash, cpio and linuxrc In-Reply-To: <1109236399.3603.15.camel@localhost.localdomain> References: <1109174824.6309.16.camel@localhost.localdomain> <1109234148.3817.35.camel@one.myworld> <1109236399.3603.15.camel@localhost.localdomain> Message-ID: <1109238782.3817.46.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 10:13 +0100, Gildas Bayard a ?crit : > Le jeudi 24 f?vrier 2005 ? 09:35 +0100, F?liciano Matias a ?crit : > > Le mercredi 23 f?vrier 2005 ? 17:07 +0100, Gildas Bayard a ?crit : > > > I understand that this system is mandatory to load exotic scsi drivers > > > or add a pause when booting to usb but I wonder why it is always used > > > - on kernel 2.4 (red hat 9) the initrd image is an ext2 filesystems. > > > > For *your* system. My initrd also contain raid0 and dm-mod > > (see /sbin/mkinitrd and "man mkinitrd"). > No I mean the initrd file is an ext2 filesystem (whatever it contains) > On FC3 it is a cpio archive. Why? Not sure, but I think because cpio archive is smaller. > And why when initrd is a cpio archive > it would not load linuxrc? I don't know. > Answers to these question are not in man initrd, man nash... > > > > > It > > > contains a linuxrc nash script. On kernel 2.6 (fedora 3) the initrd is a > > > cpio archive and does not contains a linuxrc script. Could someone > > > briefly explain me why these differences? Particularly I wondering about > > > 3 things: > > > 1) I tried to repack my custom initrd ext2 filesystem into a cpio > > > archive and found that when packed as a cpio archive it's not executing > > > my linuxrc script (is it the way it's supposed to be?) > > > > use "/init". > Well I want to understand why my linuxrc is not run when in a cpio > archive and again what the matter with the cpio archive > > > > > 2) What are the differences between pivot_root and switch_root (new in > > > 2.6) ? > > > 3) Why using nash in the first place? > > > > nash is a mini-mini-mini-shell (bash is TTOOOO big). See "man nash". > man nash does not explain what is the rational for both pivot_root and > switch_root (just give a small description). > => Why pivot_root was not enough? From rom nash.c : /* 2.6 magic not-pivot-root but kind of similar stuff. * This is based on code from klibc/utils/run_init.c */ int switchrootCommand(char * cmd, char * end) { > => Why not wait until the end of linuxrc to jump to the new root fs? > ??? > I would like to know how to get in touch with nash coders. From rom nash.c : * Erik Troan (ewt _AT_ redhat.com) * Jeremy Katz (katzj _AT_ redhat.com) > On which > forum or mailing list could they be hanging on? fedora-devel :-) > > > Could we just wait until the end > > > of the linuxrc script? At that time the kernel would move to the new > > > root fs (whitout the need for pivot_root or switch_root) > > > > > > And finally, if I'm right the end of the nash script (after switch_root) > > > is never executed? > > > > > > Gildas > > > > > -- -------------- 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 Thu Feb 24 12:40:00 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 24 Feb 2005 13:40:00 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109096669.13684.14.camel@localhost.localdomain> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> Message-ID: <1109248801.28890.4.camel@wombat.tiptoe.de> On Tue, 2005-02-22 at 18:24 +0000, David Woodhouse wrote: > On Tue, 2005-02-22 at 01:00 -0300, Pedro Fernandes Macedo wrote: > >I dont want to make this a sendmail/postfix/exim/other email server war, > >but I think that is a little too much... > >Just because one distribution ships exim/koffice/put your favourite app > >here as default , it doesnt necessarily mean that's the right choice for > >all distributions. > > That's true, but in this case Debian happens to have it right. We should > do what Debian does here because they're _right_, not just because > they're doing it and we have to follow. In that case I would be curious about the reasons which make exim more "right" than say postfix, otherwise it's only an "everyone wants his pet MTA" thing. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From ivg2 at cornell.edu Thu Feb 24 13:02:31 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 24 Feb 2005 08:02:31 -0500 Subject: Summary of Dropped Packages In-Reply-To: <20050224041924.GA5236@nostromo.devel.redhat.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> Message-ID: <1109250151.20399.2.camel@cobra.ivg2.net> > ggv > gpdf > gv What about xpdf? Is that staying? -- Ivan Gyurdiev Cornell University From strange at nsk.no-ip.org Thu Feb 24 13:05:34 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 24 Feb 2005 13:05:34 +0000 Subject: nash, initrd, cpio... In-Reply-To: <1109232908.3603.3.camel@localhost.localdomain> References: <1109232908.3603.3.camel@localhost.localdomain> Message-ID: <20050224130534.GA4119@nsk.no-ip.org> On Thu, Feb 24, 2005 at 09:15:08AM +0100, Gildas Bayard wrote: > > Does anyone knows who I should ask about nash and cpio initrd support? > (see my yesterday post) fedora users list? This is for questions regarding the development of the distribution. > Documentation is often out of date and I could not find any information > about why does FC3 changes initrd format from ext2 fs to cpio archive... Cpio brings many advantages: 1. you create an initrd directly from your working copy by using a simple command: find . | cpio -co | gzip -9 > ../new-initrd (don't forget the option -c to cpio) instead of: dd if=/dev/zero of=img bs=1k count=16k mke2fs -f img tune2fs -c0 -i0 img mount img /mnt -o loop rmdir /mnt/lost+found cp -a files /mnt umount /mnt gzip -9 < img > new-initrd 2. The files will be extracted to a tmpfs, so it will consume only the space the files use, and can grow accordingly to free ram and swap. the initrd image is limited by the size it was created with, and will consume that full size. (and no space wasted on filesystem structures and old data) 3. no need to complex filesystems and block devices in the kernel 4. there is a libc in development designed for booting the system (loading modules, configuring network, mounting filesystems, etc) 5. you can append several cpio archives together. the boot process will extract all files. 6. unified boot process (linuxrc, init, etc) 7. etc. I'm not an expert :) You can find a cpio archive that boots with support for lvm, ext3, busybox and other stuff in: http://users.gil.di.uminho.pt/strange/initrd-e2tools.img (modules in the image are for kernel 2.6.10-1.1110_FC4) Regards, Luciano Rocha From dwmw2 at infradead.org Thu Feb 24 13:07:30 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 13:07:30 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109248801.28890.4.camel@wombat.tiptoe.de> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> Message-ID: <1109250450.5420.48.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 13:40 +0100, Nils Philippsen wrote: > In that case I would be curious about the reasons which make exim more > "right" than say postfix, otherwise it's only an "everyone wants his > pet MTA" thing. Exim and Postfix are way ahead of sendmail, which should probably be dropped in FC5 when it's sane to start dropping packages to Extras; more than that is somewhat subjective. Both Postfix and Exim should remain, but it's just a question of which is the default. I'd go for Exim -- it's very well documented, fully IPv6 capable, at least as easy for the newbie to configure as postfix is, and seems to be far more versatile for those who want to go a little further. We ship it ready to do SMTP AUTH and automatically use SpamAssassin to reject mail at incoming SMTP time, for example, rather than only feeding it to SA later when it's too late because we've already accepted it. Right now, Postfix scores some points back by being SE-enabled, but Exim will catch up on that front very soon; probably before test 1 even. Postfix loses points for the fact that the admins of freedesktop.org were unable for months to persuade it to send mail to a domain whose primary MX was IPv6-only. I don't know if it's fixed even now the open relay thing has been fixed -- they put an explicit route in for me in the end, I think. That's not something I'd want a Fedora newbie trying to diagnose. -- dwmw2 From dwmw2 at infradead.org Thu Feb 24 13:13:35 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 13:13:35 +0000 Subject: Other ways to cut FC4 down from 15 CDs to 14? Message-ID: <1109250815.5420.53.camel@hades.cambridge.redhat.com> Has anyone looked at the possibility of having a shared CD or two between the x86_64 and i386 installs? There's 412300KiB of noarch packages which are present in both x86_64 and i386, and 436108KiB of i[36]86 packages in the x86_64 tree. If a package ordering can be found which allows a bunch of those to go onto a CD which is shared between x86_64 and i386 installations, we get to lose a CD out of the set without running around like headless chickens trying to excise useful packages to make the i386 tree smaller. -- dwmw2 From gildas.bayard at ac6.fr Thu Feb 24 13:37:54 2005 From: gildas.bayard at ac6.fr (Gildas Bayard) Date: Thu, 24 Feb 2005 14:37:54 +0100 Subject: nash, initrd, cpio... In-Reply-To: <20050224130534.GA4119@nsk.no-ip.org> References: <1109232908.3603.3.camel@localhost.localdomain> <20050224130534.GA4119@nsk.no-ip.org> Message-ID: <1109252274.3603.58.camel@localhost.localdomain> Ok. Now I clearly see the advantages of using cpio instead of an ext2 filesystem. It seems like when initrd is a cpio archive then "init" is executed instead of "linuxrc". So I converted my FC3 initrd cpio archive into an ext2 (just to test, I understand I should switch to the cpio way). I changed "init" into "linuxrc" and though it would do it. But it did not. The ext2 (linuxrc) version jumps to the new root fs but init complains about missing parameter (runlevel) and quits. Do you know what's happening? Comparing red hat 9 (ext2 way) and fedora 3 (cpio way) I changed the end of the initrd sequence, replacing switchroot /sysroot by echo 0x0100 > /proc/sys/kernel/real-root-dev pivot_root /sysroot /sysroot/initrd It now works fine but I don't really understand why... I'm booting on usual /dev/hda# so why should I report the kernel that the real-root-dev is 0x0100 (which corresponds to the first ram disk)? Now I have the solution but I'm frustrated not to understand it! :'| Gildas Le jeudi 24 f?vrier 2005 ? 13:05 +0000, Luciano Miguel Ferreira Rocha a ?crit : > On Thu, Feb 24, 2005 at 09:15:08AM +0100, Gildas Bayard wrote: > > > > Does anyone knows who I should ask about nash and cpio initrd support? > > (see my yesterday post) > > fedora users list? This is for questions regarding the development of > the distribution. > > > Documentation is often out of date and I could not find any information > > about why does FC3 changes initrd format from ext2 fs to cpio archive... > > Cpio brings many advantages: > > 1. you create an initrd directly from your working copy by using a > simple command: > find . | cpio -co | gzip -9 > ../new-initrd > (don't forget the option -c to cpio) > > instead of: > dd if=/dev/zero of=img bs=1k count=16k > mke2fs -f img > tune2fs -c0 -i0 img > mount img /mnt -o loop > rmdir /mnt/lost+found > cp -a files /mnt > umount /mnt > gzip -9 < img > new-initrd > > 2. The files will be extracted to a tmpfs, so it will consume only the > space the files use, and can grow accordingly to free ram and swap. the > initrd image is limited by the size it was created with, and will > consume that full size. > (and no space wasted on filesystem structures and old data) > > 3. no need to complex filesystems and block devices in the kernel > > 4. there is a libc in development designed for booting the system > (loading modules, configuring network, mounting filesystems, etc) > > 5. you can append several cpio archives together. the boot process will > extract all files. > > 6. unified boot process (linuxrc, init, etc) > > 7. etc. I'm not an expert :) > > You can find a cpio archive that boots with support for lvm, ext3, > busybox and other stuff in: > http://users.gil.di.uminho.pt/strange/initrd-e2tools.img > (modules in the image are for kernel 2.6.10-1.1110_FC4) > > Regards, > Luciano Rocha > From laroche at redhat.com Thu Feb 24 14:02:08 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 24 Feb 2005 15:02:08 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109248801.28890.4.camel@wombat.tiptoe.de> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> Message-ID: <20050224140208.GB4030@dudweiler.stuttgart.redhat.com> On Thu, Feb 24, 2005 at 01:40:00PM +0100, Nils Philippsen wrote: > On Tue, 2005-02-22 at 18:24 +0000, David Woodhouse wrote: > > On Tue, 2005-02-22 at 01:00 -0300, Pedro Fernandes Macedo wrote: > > >I dont want to make this a sendmail/postfix/exim/other email server war, > > >but I think that is a little too much... > > >Just because one distribution ships exim/koffice/put your favourite app > > >here as default , it doesnt necessarily mean that's the right choice for > > >all distributions. > > > > That's true, but in this case Debian happens to have it right. We should > > do what Debian does here because they're _right_, not just because > > they're doing it and we have to follow. > > In that case I would be curious about the reasons which make exim more > "right" than say postfix, otherwise it's only an "everyone wants his pet > MTA" thing. The config file is more stable and the way they maintain the package more longterm. That's what I heard. greetings, Florian La Roche From czar at czarc.net Thu Feb 24 14:06:20 2005 From: czar at czarc.net (Gene C.) Date: Thu, 24 Feb 2005 09:06:20 -0500 Subject: reducing distribution CD count Message-ID: <200502240906.20729.czar@czarc.net> I have been following the various discussions of reducing the CD count and have the following comments: 1. I agree with those who want to expand the FC4 set to 5 CD images and then put the big reduction effort into the FC5 timeframe when anaconda can/should be able to handle multiple "respositories" (and, homefully, pup also). 2. Lets say something major which a lot of users will want is move out of the "core core" and into a secondary "repository" which will still be fully maintained by Red Hat employees. No flaming intended, but lets say this is kde and all kde associated applications. Now that would be a big chunk but it would also be something a lot of users would want. What is the current thinking about how this "secondary repository" will be available to the user? Furthermore, this must be done in such a manner that it is obvious that Red Hat is NOT slighting the packages involved. 3. Can someone point me to the mailing list where the discussions are being held about this future multiple repository? 4. I am a little concerned about the discussion of multiple repositories and getting the CD count does to below four. What I am reading into the "multiple repository" discussions so far is that there would be a small number of CD images but then the rest of the packages would be pulled in off the Internet. While this should work in most cases, there does exist a need to have stand-alone systems or small networks of systems which have no connectivity to the Internet. Currently, with everything on CD or DVD images, things work for these stand-alone systems. True, getting updates to these systems is a bit more work requiring downloading, burning to DVD or CD and then moving to the unconnected systems but it does work. If large pieces of the "core" is only available via the Internet, then this can cause a great deal of additional effort. 5. There was some mention of RHEL having "extra" packages which are not part of the RHEL on CDs. How does RHEL handle the extra packages for stand-alone systems? 6. Currently, I pick and choose a small number of extra packages from Fedora Extras and other rpm repositories. If large number of packages which a lot of individuals may want are moved into secondary repositories, how will things be handled? Will there be CD and/or DVD images available of these repositories? 7. Currently, I do everything installs of Fedora Core for many installations simply because it is easier than adding a lot of stuff manually ... even if this does include a lot of packages that I have no need to install ... it is just simpler to include them. However, doing "everything everything" installs which would include packages from a Core, Extended Core, Extras, and other repositories, does not sound like it would work. There must be a better way. My view of how installation should work is that the basic installation should be just that ... basic. Then, during firstboot (and available at later times too), you run something like pup (I hope this is the intent) to add additional packages and groupings of packages ... this does need to have the ability to select package installation/removal on an individual package basis. Large groupings of packages (e.g., KDE) should be available as CD or DVD images. Comments? -- Gene From prarit at sgi.com Thu Feb 24 14:06:30 2005 From: prarit at sgi.com (Prarit Bhargava) Date: Thu, 24 Feb 2005 09:06:30 -0500 Subject: [ANNOUNCE]: ia64 FC4 Development Message-ID: <421DDF66.8030404@sgi.com> Hello everyone, Last week at FUDCon, I presented a 10-15 minute discussion on the an ia64 FC4 (hopefully ;)) distribution. I've had interest from several developers and now am going to make a general call onto the devel list for others who wish to participate. Please email prarit at sgi.com and we'll see where we go from here. Thanks, P. From dwmw2 at infradead.org Thu Feb 24 14:09:50 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 14:09:50 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <20050224140208.GB4030@dudweiler.stuttgart.redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <20050224140208.GB4030@dudweiler.stuttgart.redhat.com> Message-ID: <1109254190.5420.73.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 15:02 +0100, Florian La Roche wrote: > > In that case I would be curious about the reasons which make exim more > > "right" than say postfix, otherwise it's only an "everyone wants his pet > > MTA" thing. > > The config file is more stable and the way they maintain the package > more longterm. That's what I heard. Yeah -- Phil refuses to make changes like defaulting the header_sender callout to using a _real_ reverse-path instead of the empty sender, because it would change the behaviour for existing users. It's a pain at times, but overall it makes sense. It means you can upgrade with a very good expectation that nothing will break. That reminds me -- Exim's SMTP callouts correctly use the null sender, where I believe Postfix's do not. I've had to implement a workaround for broken Postfix callouts for certain addresses which only ever _send_ mail and shouldn't receive it. -- dwmw2 From dcbw at redhat.com Thu Feb 24 14:18:08 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 24 Feb 2005 09:18:08 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109250151.20399.2.camel@cobra.ivg2.net> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109250151.20399.2.camel@cobra.ivg2.net> Message-ID: <1109254688.8085.0.camel@dcbw.boston.redhat.com> On Thu, 2005-02-24 at 08:02 -0500, Ivan Gyurdiev wrote: > > ggv > > gpdf > > gv > > What about xpdf? > Is that staying? Yes, it was generally agreed that xpdf needs to stick around. Dan From mattdm at mattdm.org Thu Feb 24 14:19:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 09:19:44 -0500 Subject: pup In-Reply-To: <1109219610.10915.52.camel@cutter> References: <20050223222925.45377.qmail@web50801.mail.yahoo.com> <1109219610.10915.52.camel@cutter> Message-ID: <20050224141944.GA2114@jadzia.bu.edu> On Wed, Feb 23, 2005 at 11:33:30PM -0500, seth vidal wrote: > >I think about a dozen digests ago someone mentioned a > >program called pup replacing yum. Is there somewhere > >I can look to see information about this program? Is > >pup to yum as synaptic to apt-get or is it completely > >independent? > pup is currently using the yum modules as a backend. But, the pup:yum::synaptic:apt-get thing isn't quite correct, as pup is designed specifically to only address the issue of package updating, and isn't meant to be a general GUI frontend. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Feb 24 15:38:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 10:38:06 -0500 Subject: hello? festival update.... Message-ID: <20050224153806.GA4663@jadzia.bu.edu> I did this three weeks ago, hoping to get it in for FC4. No response at all from anyone. This also resolves bug #75645 ("Messes /usr/bin directory") which is tagged as blocking FC4. What can I do at this point? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dcbw at redhat.com Thu Feb 24 15:48:39 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 24 Feb 2005 10:48:39 -0500 Subject: hello? festival update.... In-Reply-To: <20050224153806.GA4663@jadzia.bu.edu> References: <20050224153806.GA4663@jadzia.bu.edu> Message-ID: <1109260119.8085.4.camel@dcbw.boston.redhat.com> On Thu, 2005-02-24 at 10:38 -0500, Matthew Miller wrote: > I did this three weeks ago, hoping to get it in for FC4. No response at all > from anyone. > > > > > > > This also resolves bug #75645 ("Messes /usr/bin directory") > > which is tagged as blocking FC4. > > > What can I do at this point? The owner of #147315 was on vacation for most of early Feb and recently returned. Lots of catching up to do I'd assume. You might want to just add a comment to bug to remind him. Dan From mattdm at mattdm.org Thu Feb 24 15:59:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 10:59:21 -0500 Subject: hello? festival update.... In-Reply-To: <1109260119.8085.4.camel@dcbw.boston.redhat.com> References: <20050224153806.GA4663@jadzia.bu.edu> <1109260119.8085.4.camel@dcbw.boston.redhat.com> Message-ID: <20050224155921.GA5729@jadzia.bu.edu> On Thu, Feb 24, 2005 at 10:48:39AM -0500, Dan Williams wrote: > The owner of #147315 was on vacation for most of early Feb and recently > returned. Lots of catching up to do I'd assume. > You might want to just add a comment to bug to remind him. Okay, thank you; I will. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From walters at redhat.com Thu Feb 24 16:18:16 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 24 Feb 2005 11:18:16 -0500 Subject: Lots of erros in Yum doing update (was Re: rawhide report: 20050222 changes) In-Reply-To: <1109205864.3684.4.camel@trevally.redfishdemo.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <1109121565.4609.26.camel@localhost.localdomain> <1109123450.2361.4.camel@cutter> <1109124972.4609.52.camel@localhost.localdomain> <1109140226.2361.21.camel@cutter> <1109205864.3684.4.camel@trevally.redfishdemo.com> Message-ID: <1109261897.3934.6.camel@nexus.verbum.private> On Thu, 2005-02-24 at 11:44 +1100, Rodd Clarkson wrote: >Yeah, turning of selinux fixed it (although I'm still not sure how to >run the post scripts for all the packages that fails (hint hint)) If you have to disable it for some reason, please please post the "avc: denied" messages in /var/log/messages to fedora-selinux-list (or file a Bugzilla) to give us a chance to figure out what the problem is. Often too you can just disable protection for one service or just temporarily "setenforce 0" without disabling it permanently. Also let me second Seth's statement wrt rawhide and babies :) >I've actually been running without selinux for a couple of weeks now >because my nose is to the grind stone and I need to use apache and mysql >and for some reason I need to configure this to work (haven't had time >to do so). It seems like a bad idea to be depending on stuff to work in rawhide when your nose is to the grind stone... >With the update I turned selinux on by accident and it caused all this >stuff. Turning if off I was able to run yum update and get the kernel >and openssh-server to install. Hopefully we can track down the problem once we get the avc messages. From sopwith at redhat.com Thu Feb 24 16:38:24 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 11:38:24 -0500 (EST) Subject: reducing distribution CD count In-Reply-To: <200502240906.20729.czar@czarc.net> References: <200502240906.20729.czar@czarc.net> Message-ID: On Thu, 24 Feb 2005, Gene C. wrote: > 1. I agree with those who want to expand the FC4 set to 5 CD images and > then put the big reduction effort into the FC5 timeframe when anaconda > can/should be able to handle multiple "respositories" (and, homefully, > pup also). Something that needs to be mentioned - it was decided that it was better to go to 5 CDs for now than to kick eclipse and the Java stuff out. However, there is plenty of other stuff that can be moved to Extras right now, and as you've seen that has already been happening (maintainers still wanted for some of that stuff!). -- Elliot From sopwith at redhat.com Thu Feb 24 16:48:54 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 11:48:54 -0500 (EST) Subject: Summary of Dropped Packages In-Reply-To: <5256d0b0502240103681d582b@mail.gmail.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <5256d0b0502240103681d582b@mail.gmail.com> Message-ID: On Thu, 24 Feb 2005, Peter Robinson wrote: > So with these removed from Core I assume they are going to be in Extras. > Correct? In Extras will they continue to be maintained as before or will > they need someone to step up and maintain them? The reason I ask is it > would be a pity to see abiword and gnumeric disappear as I find them > considerably faster than OOo and in the case of Abiword it supports a > number of word files that don't work to well with OOo.I also use grip. > While I'm happy for them to be in extras rather than core I would still > like them to be around. The plan is to add these packages to Extras as demand requires. Volunteers are always wanted to help maintain packages. Are you interested? Please see http://fedoraproject.org/wiki/Extras_2fCvsAccess Cheers, -- Elliot From tibbs at math.uh.edu Thu Feb 24 16:49:39 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 24 Feb 2005 10:49:39 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109250450.5420.48.camel@hades.cambridge.redhat.com> (David Woodhouse's message of "Thu, 24 Feb 2005 13:07:30 +0000") References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Both Postfix and Exim should remain, but it's just a question of DW> which is the default. Honestly I would prefer that neither is the default. Both have far too much functionality for hosts which are not mail servers. What's really needed is something tiny, optimized for a machine that rarely sends mail, has a highly-available smarthost, and never receives mail from the network: Starts from xinetd on port 25 (localhost only). Will queue if smarthost is unavailable. Runs from cron to flush queue. Submission interface is not setuid; it talks SMTP to smarthost or localhost. Nothing else. Exim has a mode which is close, but it rejects the message if it can't talk to the smarthost. Someone who really wants to run a mail server can install one. - J< From jbarnes at sgi.com Thu Feb 24 16:50:24 2005 From: jbarnes at sgi.com (Jesse Barnes) Date: Thu, 24 Feb 2005 08:50:24 -0800 Subject: [ANNOUNCE]: ia64 FC4 Development In-Reply-To: <421DDF66.8030404@sgi.com> References: <421DDF66.8030404@sgi.com> Message-ID: <200502240850.24819.jbarnes@sgi.com> On Thursday, February 24, 2005 6:06 am, Prarit Bhargava wrote: > Hello everyone, > > Last week at FUDCon, I presented a 10-15 minute discussion on the an > ia64 FC4 (hopefully ;)) distribution. > > I've had interest from several developers and now am going to make a > general call onto the devel list for others who wish to participate. > > Please email prarit at sgi.com and we'll see where we go from here. Yes! Thanks for organizing this, Prarit, I'm definitely interested in helping (testing, coding, whatever). I'd really like to see Fedora continue be a quality ia64 distribution, maybe we can target FC5 as the first ia64 core release? Or do you think we can pull of getting into FC4? Thanks, Jesse From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 16:50:35 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 17:50:35 +0100 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> Message-ID: <20050224175035.22391185@python2> Elliot Lee wrote : > On Thu, 24 Feb 2005, Gene C. wrote: > > > 1. I agree with those who want to expand the FC4 set to 5 CD images and > > then put the big reduction effort into the FC5 timeframe when anaconda > > can/should be able to handle multiple "respositories" (and, homefully, > > pup also). > > Something that needs to be mentioned - it was decided that it was better > to go to 5 CDs for now than to kick eclipse and the Java stuff out. > However, there is plenty of other stuff that can be moved to Extras right > now, and as you've seen that has already been happening (maintainers > still wanted for some of that stuff!). For clearly obsolete stuff (input methods...) I really don't mind packages being removed, but I see at least 3 issues with what got dropped : - Exim was removed... it's tiny, and was in FC3, so that's probably a bad idea. - Xfce was removed... this leaves FC with no lightweight desktop manager, and it was in FC3 AFAIR, so again... - Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off". I don't have strong feelings about sylpheed, abiword/gnumeric and most (if not all) of the others, but for these 3 points, I definitely do. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 3.11 3.23 5.00 From j.w.r.degoede at hhs.nl Thu Feb 24 17:02:08 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 24 Feb 2005 18:02:08 +0100 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> Message-ID: <421E0890.3020302@hhs.nl> Elliot Lee wrote: > On Thu, 24 Feb 2005, Gene C. wrote: > > >>1. I agree with those who want to expand the FC4 set to 5 CD images and >>then put the big reduction effort into the FC5 timeframe when anaconda >>can/should be able to handle multiple "respositories" (and, homefully, >>pup also). > > > Something that needs to be mentioned - it was decided that it was better > to go to 5 CDs for now than to kick eclipse and the Java stuff out. > However, there is plenty of other stuff that can be moved to Extras right > now, and as you've seen that has already been happening (maintainers > still wanted for some of that stuff!). > 1) I would like to volunteer ti maintain some packages 2) list of packages please which need maintainer please. Regards, Hans From esr at thyrsus.com Thu Feb 24 17:16:58 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 24 Feb 2005 12:16:58 -0500 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109250815.5420.53.camel@hades.cambridge.redhat.com> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> Message-ID: <20050224171658.GA19840@thyrsus.com> David Woodhouse : > Has anyone looked at the possibility of having a shared CD or two > between the x86_64 and i386 installs? > > There's 412300KiB of noarch packages which are present in both x86_64 > and i386, and 436108KiB of i[36]86 packages in the x86_64 tree. > > If a package ordering can be found which allows a bunch of those to go > onto a CD which is shared between x86_64 and i386 installations, we get > to lose a CD out of the set without running around like headless > chickens trying to excise useful packages to make the i386 tree smaller. As an Opteron user, I strongly support this suggestion. -- Eric S. Raymond From prarit at sgi.com Thu Feb 24 17:17:44 2005 From: prarit at sgi.com (Prarit Bhargava) Date: Thu, 24 Feb 2005 12:17:44 -0500 Subject: [ANNOUNCE]: ia64 FC4 Development In-Reply-To: <200502240850.24819.jbarnes@sgi.com> References: <421DDF66.8030404@sgi.com> <200502240850.24819.jbarnes@sgi.com> Message-ID: <421E0C38.5020603@sgi.com> It looks like the "freeze" is mid-March -- I would hope to get in there, but I dunno yet ... Let's see how many volunteer. P. Jesse Barnes wrote: >On Thursday, February 24, 2005 6:06 am, Prarit Bhargava wrote: > > >>Hello everyone, >> >>Last week at FUDCon, I presented a 10-15 minute discussion on the an >>ia64 FC4 (hopefully ;)) distribution. >> >>I've had interest from several developers and now am going to make a >>general call onto the devel list for others who wish to participate. >> >>Please email prarit at sgi.com and we'll see where we go from here. >> >> > >Yes! Thanks for organizing this, Prarit, I'm definitely interested in helping >(testing, coding, whatever). I'd really like to see Fedora continue be a >quality ia64 distribution, maybe we can target FC5 as the first ia64 core >release? Or do you think we can pull of getting into FC4? > >Thanks, >Jesse > > > From thacker at math.cornell.edu Thu Feb 24 17:21:07 2005 From: thacker at math.cornell.edu (John Thacker) Date: Thu, 24 Feb 2005 12:21:07 -0500 Subject: Update website to mention CVS, Extras? Message-ID: <20050224172107.GA2066@thacker.dyndns.org> Is there any reason why the main Fedora website still doesn't contain any links or hints that the public CVS server exists or that Fedora Extras exists? No mention on the front page, no "CVS Server" on the left sidebar except when you're actually on the CVS Server page, and plenty of references like on http://fedora.redhat.com/participate/ , which suggests contributing to fedora.us, "the older Fedora Linux project with which the Fedora Project will be merging," and promises that the public CVS server (which already exists) "is intended to be available real soon now." There's no mention on any of the Download pages about Fedora Extras, either, though users may figure out to look at that "extras" directory when they click on the "Download Server" button. Is there rhyme or reason behind having Fedora Extras and the CVS server nearly impossible to find from the main site for a new user? Or have things merely just not been updated yet? John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sopwith at redhat.com Thu Feb 24 17:21:26 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 12:21:26 -0500 (EST) Subject: reducing distribution CD count In-Reply-To: <20050224175035.22391185@python2> References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> Message-ID: On Thu, 24 Feb 2005, Matthias Saou wrote: > - Exim was removed... it's tiny, and was in FC3, so that's > probably a bad idea. > - Xfce was removed... this leaves FC with no lightweight desktop > manager, and it was in FC3 AFAIR, so again... Packages aren't being removed because they're not useful. Nobody is disputing that exim is useful to people or that xfce is a good thing for some users. The question is not whether it's useful, it's whether it's an essential to the goal of Fedora Core as the "Core", as a general purpose OS. The package removals so far are just a start. We're not there yet. There's still plenty more to move from Core to Extras (or just drop altogether). The advantage for you is that moving things from Core to Extras gives you more control over the package. It becomes a lot easier for you to contribute more directly as a packager. The disadvantage is that people somehow see moving from Core to Extras as an insult against their package, which couldn't be farther from the intention. > - Both tuxracer and bzflag were removed, but many people (Havoc, > Alan) definitely want at least one good 3D game to "show off". It can be showed off without being included in Core. -- Elliot From sopwith at redhat.com Thu Feb 24 17:24:28 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 12:24:28 -0500 (EST) Subject: Update website to mention CVS, Extras? In-Reply-To: <20050224172107.GA2066@thacker.dyndns.org> References: <20050224172107.GA2066@thacker.dyndns.org> Message-ID: The web site is really out of date. The intent is to move it into cvs.fedora.redhat.com Real Soon Now so more people can make more updates more easily. Please keep bugging us until this happens :) Thanks, -- Elliot On Thu, 24 Feb 2005, John Thacker wrote: > > Is there any reason why the main Fedora website still doesn't contain any > links or hints that the public CVS server exists or that Fedora Extras > exists? No mention on the front page, no "CVS Server" on the left sidebar > except when you're actually on the CVS Server page, and plenty of references > like on http://fedora.redhat.com/participate/ , which suggests contributing > to fedora.us, "the older Fedora Linux project with which the Fedora Project > will be merging," and promises that the public CVS server (which already > exists) "is intended to be available real soon now." There's no mention > on any of the Download pages about Fedora Extras, either, though users > may figure out to look at that "extras" directory when they click on the > "Download Server" button. > > Is there rhyme or reason behind having Fedora Extras and the CVS server > nearly impossible to find from the main site for a new user? Or have > things merely just not been updated yet? From dwmw2 at infradead.org Thu Feb 24 17:28:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 17:28:17 +0000 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> Message-ID: <1109266098.5420.104.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 12:21 -0500, Elliot Lee wrote: > The disadvantage is that people somehow see moving from Core to Extras as > an insult against their package, which couldn't be farther from the > intention. If we've given up the goal of cutting the i386 install down to 4CDs, we really ought to wait till anaconda can handle Extras properly in FC5 before we go dumping packages there. For upgrades to FC4, if the package is in Extras it might as well not exist. > > - Both tuxracer and bzflag were removed, but many people (Havoc, > > Alan) definitely want at least one good 3D game to "show off". > > It can be showed off without being included in Core. Not until FC5, it can't. -- dwmw2 From aoliva at redhat.com Thu Feb 24 17:34:49 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Feb 2005 14:34:49 -0300 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109250815.5420.53.camel@hades.cambridge.redhat.com> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> Message-ID: On Feb 24, 2005, David Woodhouse wrote: > Has anyone looked at the possibility of having a shared CD or two > between the x86_64 and i386 installs? As good as an idea as it might sound, it poses some interesting infrastructure problems, and it doesn't address the most important issue in my understanding. As for infrastructure, it requires the entire CD set to be regarded as part of the same distro spin, as opposed to having each arch being spun separately as it stands now. This is why you see different SRPMS isos for x86_64 and i386, for example, and why fedora-release has a different build number between them. Yes, this would be great to fix, and would further reduce the amount of space mirrors get to carry. In fact, fixing this is probably *far* more important that cutting out half a CD from the i386 binary set. As for the most important issue, which is the i386 CD count, it won't make any difference: CD distributors will still have to print 5 instead of 4 CDs to offer the complete FC4/i386. Not that I find this all that important, personally, nor that I agree with the current pursuit of such goal, but I thought I'd point out that it unfortunately fails to help. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From shiva at sewingwitch.com Thu Feb 24 17:34:54 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 24 Feb 2005 09:34:54 -0800 Subject: Update website to mention CVS, Extras? In-Reply-To: References: <20050224172107.GA2066@thacker.dyndns.org> Message-ID: <970CC4DA9262E2A64D6A7F00@[10.169.6.246]> --On Thursday, February 24, 2005 12:24 PM -0500 Elliot Lee wrote: > Please keep bugging us until this happens :) Bugging ;) in progress: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 17:42:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 18:42:50 +0100 Subject: reducing distribution CD count In-Reply-To: <1109266098.5420.104.camel@hades.cambridge.redhat.com> References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> <1109266098.5420.104.camel@hades.cambridge.redhat.com> Message-ID: <20050224184250.543d0e59@python2> David Woodhouse wrote : > On Thu, 2005-02-24 at 12:21 -0500, Elliot Lee wrote: > > The disadvantage is that people somehow see moving from Core to Extras as > > an insult against their package, which couldn't be farther from the > > intention. > > If we've given up the goal of cutting the i386 install down to 4CDs, we > really ought to wait till anaconda can handle Extras properly in FC5 > before we go dumping packages there. For upgrades to FC4, if the package > is in Extras it might as well not exist. > > > > - Both tuxracer and bzflag were removed, but many people (Havoc, > > > Alan) definitely want at least one good 3D game to "show off". > > > > It can be showed off without being included in Core. > > Not until FC5, it can't. My thoughts exactly. The cutting off is a bit too premature IMHO, and my concerns aren't related to certain software being perceived as becoming "2nd class", but more to the fact that we won't be able to trivially get this software on FC4 systems (I'm not thinking of my own computers but those like my dad's, sitting behind a modem connection with only s-c-p to manage installed software). Given how we are headed for FC4, things _can't_ be showed off easily without being included in Core, or at least that's the impression I have, and will still have until anaconda evolves or that we're sure to have rebuilt Extras on the day a new FC is released... Alright... ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 1.31 1.35 1.48 From skvidal at phy.duke.edu Thu Feb 24 17:56:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 12:56:10 -0500 Subject: reducing distribution CD count In-Reply-To: <421E0890.3020302@hhs.nl> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> Message-ID: <1109267770.15658.0.camel@opus.phy.duke.edu> On Thu, 2005-02-24 at 18:02 +0100, Hans de Goede wrote: > Elliot Lee wrote: > > On Thu, 24 Feb 2005, Gene C. wrote: > > > > > >>1. I agree with those who want to expand the FC4 set to 5 CD images and > >>then put the big reduction effort into the FC5 timeframe when anaconda > >>can/should be able to handle multiple "respositories" (and, homefully, > >>pup also). > > > > > > Something that needs to be mentioned - it was decided that it was better > > to go to 5 CDs for now than to kick eclipse and the Java stuff out. > > However, there is plenty of other stuff that can be moved to Extras right > > now, and as you've seen that has already been happening (maintainers > > still wanted for some of that stuff!). > > > > 1) I would like to volunteer ti maintain some packages > 2) list of packages please which need maintainer please. > http://fedoraproject.org/wiki/Extras_2fOrphanedPackages -sv From jamatos at fc.up.pt Thu Feb 24 18:13:15 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 24 Feb 2005 18:13:15 +0000 Subject: reducing distribution CD count In-Reply-To: <1109267770.15658.0.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> Message-ID: <200502241813.15779.jamatos@fc.up.pt> On Thursday 24 February 2005 17:56, seth vidal wrote: > > http://fedoraproject.org/wiki/Extras_2fOrphanedPackages Notice that there it appears: Packages without maintainer in Fedora Extras ... python-numeric ... Yet according to the rawhide report of 20050222 we have: New package Numeric Numerical Extension to Python This is interesting in the sense that it also raises the question regarding the package name that is being taken by Tom 'spot' Callaway: http://fedoraproject.org/wiki/PackageNamingGuidelines Probably this is a good time for a definitive for this package. :-) > -sv Just my 0.02 ?. :-) -- Jos? Ab?lio From dwmw2 at infradead.org Thu Feb 24 18:15:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 18:15:57 +0000 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> Message-ID: <1109268957.5420.122.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 10:49 -0600, Jason L Tibbitts III wrote: > Exim has a mode which is close, but it rejects the message if it can't > talk to the smarthost. Someone who really wants to run a mail server > can install one. Either you want it capable of queueing, or you don't -- you can't have both ;) The SE Linux patches for Exim should result in a submission interface which is not setuid even when you're using it as a real MTA so that it can queue stuff up for the smarthost. If there are no local deliveries, it doesn't need to be setuid. -- dwmw2 From skvidal at phy.duke.edu Thu Feb 24 18:20:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 13:20:32 -0500 Subject: reducing distribution CD count In-Reply-To: <200502241813.15779.jamatos@fc.up.pt> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <200502241813.15779.jamatos@fc.up.pt> Message-ID: <1109269232.15658.10.camel@opus.phy.duke.edu> On Thu, 2005-02-24 at 18:13 +0000, Jose' Matos wrote: > On Thursday 24 February 2005 17:56, seth vidal wrote: > > > > http://fedoraproject.org/wiki/Extras_2fOrphanedPackages > > Notice that there it appears: > > Packages without maintainer in Fedora Extras > ... > python-numeric > ... > > Yet according to the rawhide report of 20050222 we have: > New package Numeric > Numerical Extension to Python > > This is interesting in the sense that it also raises the question > regarding the package name that is being taken by Tom 'spot' Callaway: > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > Probably this is a good time for a definitive for this package. :-) > And this is currently being fixed. The package Numeric is coming out of core and python-numeric is moving to core. Thanks for pointing it out, you have a good point. -sv From sopwith at redhat.com Thu Feb 24 18:22:52 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 13:22:52 -0500 (EST) Subject: reducing distribution CD count In-Reply-To: <200502241813.15779.jamatos@fc.up.pt> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <200502241813.15779.jamatos@fc.up.pt> Message-ID: On Thu, 24 Feb 2005, Jose' Matos wrote: > On Thursday 24 February 2005 17:56, seth vidal wrote: > > > > http://fedoraproject.org/wiki/Extras_2fOrphanedPackages > > Notice that there it appears: > > Packages without maintainer in Fedora Extras > ... > python-numeric > ... > > Yet according to the rawhide report of 20050222 we have: > New package Numeric > Numerical Extension to Python > > This is interesting in the sense that it also raises the question > regarding the package name that is being taken by Tom 'spot' Callaway: I believe it should change to python-numeric in Core - RSN. -- Elliot From dwmw2 at infradead.org Thu Feb 24 18:23:45 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 18:23:45 +0000 Subject: reducing distribution CD count In-Reply-To: <200502241813.15779.jamatos@fc.up.pt> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <200502241813.15779.jamatos@fc.up.pt> Message-ID: <1109269425.5420.126.camel@hades.cambridge.redhat.com> On Thu, 2005-02-24 at 18:13 +0000, Jose' Matos wrote: > Packages without maintainer in Fedora Extras > ... > python-numeric > ... > > Yet according to the rawhide report of 20050222 we have: > New package Numeric > Numerical Extension to Python Yeah, but someone went a little nutty last night and a whole load of stuff got trashed which hadn't been expected to disappear -- hopefully only temporarily, since we've now acknowledged that we'd not going to manage to fit FC4/i386 onto 4 CDs. So nutty that the i386 install tree didn't even build this morning, and no new mail was sent, afaict. -- dwmw2 From aoliva at redhat.com Thu Feb 24 18:24:30 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Feb 2005 15:24:30 -0300 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> Message-ID: On Feb 24, 2005, Elliot Lee wrote: > The question is not whether it's useful, it's whether it's an essential to > the goal of Fedora Core as the "Core", as a general purpose OS. > The package removals so far are just a start. We're not there yet. Yup. We're not there yet. Since the insanity of taking packages out just because we had a 4-CD limit is gone, let's bring the useful packages back into core until we can offer users a *reasonable* solution to get those packages onto their systems. Extras as it stands isn't such a solution. > The disadvantage is that people somehow see moving from Core to Extras as > an insult against their package, which couldn't be farther from the > intention. Pushing them anywhere before anaconda can support installing them is equivalent to removing them from the distro. Sure, you could still pick it up from elsewhere or build it yourself. Which is exactly what removing a package from the distro would accomplish. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jwboyer at jdub.homelinux.org Thu Feb 24 18:28:54 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 24 Feb 2005 12:28:54 -0600 Subject: Update website to mention CVS, Extras? In-Reply-To: References: <20050224172107.GA2066@thacker.dyndns.org> Message-ID: <20050224182854.GA17505@yoda.jdub.homelinux.org> On Thu, Feb 24, 2005 at 12:24:28PM -0500, Elliot Lee wrote: > The web site is really out of date. The intent is to move it into > cvs.fedora.redhat.com Real Soon Now so more people can make more updates > more easily. Please keep bugging us until this happens :) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149585 josh From jamatos at fc.up.pt Thu Feb 24 18:38:50 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 24 Feb 2005 18:38:50 +0000 Subject: reducing distribution CD count In-Reply-To: <1109269232.15658.10.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <200502241813.15779.jamatos@fc.up.pt> <1109269232.15658.10.camel@opus.phy.duke.edu> Message-ID: <200502241838.51403.jamatos@fc.up.pt> On Thursday 24 February 2005 18:20, seth vidal wrote: > And this is currently being fixed. > The package Numeric is coming out of core and python-numeric is moving > to core. That is good to know. Thanks. > -sv -- Jos? Ab?lio From buildsys at redhat.com Thu Feb 24 18:52:30 2005 From: buildsys at redhat.com (Build System) Date: Thu, 24 Feb 2005 13:52:30 -0500 Subject: rawhide report: 20050224 changes Message-ID: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> Removed package abiword Removed package Numeric Removed package octave Removed package bzflag Removed package gnumeric Removed package koffice Removed package ggv Removed package gpdf Removed package kinput2 Removed package xemacs Removed package xfce4-panel Removed package xfce4-iconbox Removed package xfce-utils Removed package xfce4-systray Removed package xfce-mcs-plugins Removed package xfce-mcs-manager Removed package libxfce4mcs Removed package libxfcegui4 Removed package libxfce4util Removed package Maelstrom Removed package exim Removed package lapack Removed package cfengine Removed package kdetoys Removed package FreeWnn Removed package nabi Removed package system-switch-im Removed package gv Removed package skkinput Removed package miniChinput Removed package xcin Removed package dbskkd-cdb Updated Packages: ddskk-12.2.0-5 -------------- * Wed Feb 23 2005 Elliot Lee 12.2.0-5 - Remove xemacs flim-1.14.7-2 ------------- * Wed Feb 23 2005 Elliot Lee 1.14.7-2 - Remove xemacs subpackage gaim-1:1.1.3-4 -------------- * Tue Feb 22 2005 Warren Togami 1:1.1.3-4 - Test fixes for #149190 and #149304 gcc-3.4.3-20 ------------ * Tue Feb 22 2005 Jakub Jelinek 3.4.3-20 - update from gcc-3_4-branch - PRs c++/14479, c++/19487, c++/19739, c++/19755, c++/19762, c++/19787, c++/20028, libstdc++/19829, libstdc++/19946, libstdc++/19955, middle-end/19697, preprocessor/19077, target/19019, target/19715 - rename PowerPC IBM long double helper routines _xlq* to __gcc_*, but keep _xlq*@GCC_3.4 aliases around (#148841, PR target/19019) - change __cxa_demangle to match cxx-abi change http://www.codesourcery.com/archives/cxx-abi-dev/msg01877.html (Jason Merrill, #133406) - only obsolete < NVR gcc-gnat and libgnat if %{build_ada} is 0 (#139537) - revert the alloca vs. VLA patch, it has too many false positives (#147758) - make sure libjava GC memory is executable for libffi trampolines sake (#149348, PR libgcj/19823) * Thu Feb 10 2005 Jakub Jelinek 3.4.3-19 - use crtendS.o instead of crtend.o on ppc -pie - use execv instead of execl in libgcc_post_upgrade to avoid bringing in malloc and friends into the statically linked binary (which increases its size ~ 10 times) * Thu Feb 10 2005 Jakub Jelinek 3.4.3-18 - update from gcc-3_4-branch - PRs c++/18370, c++/19366, c++/19499, c++/19733, libstdc++/19642, middle-end/19775, target/15384, target/16201, target/17771, target/19293, target/19329, target/19393, target/19803 - fix c++filt/__cxa_demangle segfault on invalidly mangled names generated by G++ 3.4 (#145781, PR c++/16240) - make sure libgcj.so is not PT_GNU_STACK RWE - disallow dlopening libgnat-3*.so, as it must be PT_GNU_STACK RWE due to its extensive use of trampolines - fix PRs c++/18838 and c++/19367 (Mark Mitchell, backported by Alexandro Oliva) - fix ICE in fold_convert (Andrew Pinski, #146385, PR c++/19666) hal-cups-utils-0.5.2-9 ---------------------- * Tue Feb 22 2005 John (J5) Palmieri - 0.5.2-9 - For some reason -8 was never built into rawhide. Bumping the release to 9 and rebuilding for smooth upgrade from fc3 * Fri Oct 22 2004 John (J5) Palmieri - 0.5.2-8 - use_usb_if_null patch makes sure that the make and model of the printer is never null even if hal does not populate the printer.vendor and info.product fields. (Bug #136666) - (printer_update.hal, printer_remove.hal): Use $UDI instead of $HAL_PROP_INFO_UDI which in some instances may not be populated mew-4.1-2 --------- * Wed Feb 23 2005 Elliot Lee 4.1-2 - Remove xemacs redhat-rpm-config-8.0.33-2 -------------------------- * Wed Feb 23 2005 Arjan van de Ven 8.0.33-2 - add -Wall on Ulrichs request rpmdb-fedora-1:4-0.20050224 --------------------------- wl-2.10.1-5 ----------- * Wed Feb 23 2005 Elliot Lee 2.10.1-5 - Remove xemacs From tadams-lists at myrealbox.com Thu Feb 24 19:10:13 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 24 Feb 2005 12:10:13 -0700 Subject: Summary of Dropped Packages In-Reply-To: <20050224050826.GA2934@thyrsus.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> <1109221703.10915.63.camel@cutter> <20050224050826.GA2934@thyrsus.com> Message-ID: <1109272214.3369.6.camel@localhost.localdomain> I am not very familiar with exim, but I like postfix very much. Yes, kill sendmail. However, please make postfix the default and if exim is good, please keep it around as a choice for those who like it. Postfix is the sane default I think. Trever On Thu, 2005-02-24 at 00:08 -0500, Eric S. Raymond wrote: >seth vidal : >> >> >?!? >> >Isn't sendmail "obsolete" and exim (or postfix) the future default ? >> >> despite some rampant discussion on this list I don't remember that being >> decided anywhere. > >I've been staying out of the whole what-should-be-dropped discussion. >But let me add my voice to the "sendmail's got to go" contingent. I >don't care much what replaces it, either of postfix or exim would be >an improvement. >-- > Eric S. Raymond > -- "I am not sure what this is, but an `F' would only dignify it." -- English Professor From remco at rvt.com Thu Feb 24 19:13:27 2005 From: remco at rvt.com (Remco Treffkorn) Date: Thu, 24 Feb 2005 11:13:27 -0800 Subject: Fedora Core 4 Test 1 Status - Slip In-Reply-To: <20050223225301.GA15999@yoda.jdub.homelinux.org> References: <20050223220634.GA5849@nostromo.devel.redhat.com> <20050223222819.GA22253@redhat.com> <20050223225301.GA15999@yoda.jdub.homelinux.org> Message-ID: <200502241113.28182.remco@rvt.com> Just in case it was missed: It looks like Jakub found the problem and has a fix. No worries! On Wednesday 23 February 2005 14:53, Josh Boyer wrote: > On Wed, Feb 23, 2005 at 05:28:20PM -0500, Dave Jones wrote: > > On Wed, Feb 23, 2005 at 05:24:36PM -0500, Jakub Jelinek wrote: > > > Would appreciate to know about any such rumblings ;). > > > If it is reported upstream, then upstream PRs numbers, otherwise file > > > bugs in our bugzilla. > > > For the rebuild gcc4 needs to work on all 7 arches rawhide is built > > > on. > > > > http://lkml.org/lkml/2005/2/23/119 > > Yep, that's what I was talking about. I called it a rumbling because > nobody has responded yet. > > josh -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From jkeating at j2solutions.net Thu Feb 24 19:30:02 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 24 Feb 2005 11:30:02 -0800 Subject: Summary of Dropped Packages In-Reply-To: <1109272214.3369.6.camel@localhost.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> <1109221703.10915.63.camel@cutter> <20050224050826.GA2934@thyrsus.com> <1109272214.3369.6.camel@localhost.localdomain> Message-ID: <1109273402.28467.23.camel@jkeating2.hq.pogolinux.com> On Thu, 2005-02-24 at 12:10 -0700, Trever L. Adams wrote: > I am not very familiar with exim, but I like postfix very much. Yes, > kill sendmail. However, please make postfix the default and if exim is > good, please keep it around as a choice for those who like it. Postfix > is the sane default I think. > > So postfix being the 'sane' replacement is based only on it being what you prefer? Unfortunately single user preferences aren't what decisions are made on at a distro level. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From skvidal at phy.duke.edu Thu Feb 24 19:34:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 14:34:42 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109273402.28467.23.camel@jkeating2.hq.pogolinux.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> <1109221703.10915.63.camel@cutter> <20050224050826.GA2934@thyrsus.com> <1109272214.3369.6.camel@localhost.localdomain> <1109273402.28467.23.camel@jkeating2.hq.pogolinux.com> Message-ID: <1109273682.15658.19.camel@opus.phy.duke.edu> > So postfix being the 'sane' replacement is based only on it being what > you prefer? Unfortunately single user preferences aren't what decisions > are made on at a distro level. Sure it is. you just have to be the 'right' single user. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:36:06 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:36:06 +0100 Subject: rawhide report: 20050224 changes In-Reply-To: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> Message-ID: <20050224203606.2e3abaea@python2> Build System wrote : > redhat-rpm-config-8.0.33-2 > -------------------------- > * Wed Feb 23 2005 Arjan van de Ven 8.0.33-2 > - add -Wall on Ulrichs request Hmmm, is this temporary, or there to stay? Maybe -Wno-unused would be nice to add too since I'm already scared about all the warnings that'll start being spit out by rebuilds... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.13 0.17 0.16 From shiva at sewingwitch.com Thu Feb 24 19:45:15 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 24 Feb 2005 11:45:15 -0800 Subject: Why is sendmail bad? Message-ID: There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details? I'm using sendmail together with MIMEDefang to run SpamAssassin and ClamAV against messages during the SMTP transaction so that I can reject obvious spam and viruses before they're committed to a queue. MIMEDefang uses a user-edited Perl script to establish the exact rules for acceptance, making the system very flexible. How hard is that to set up in Postfix or Exim? From djotaku1282 at yahoo.com Thu Feb 24 19:49:03 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Thu, 24 Feb 2005 11:49:03 -0800 (PST) Subject: pup Message-ID: <20050224194904.4810.qmail@web50802.mail.yahoo.com> Thanks for the pointer to pup stuff. you wrote:----- But, the pup:yum::synaptic:apt-get thing isn't quite correct, as pup is designed specifically to only address the issue of package updating, and isn't meant to be a general GUI frontend. --------------- Does this mean it won't be able to be used for yum install or yum remove commands? What a shame. Or is there some other aspect of synaptic that you're assuming I know about (not your fault - mine for using it in the comparison) because I have only used it once almost a year ago. Are there screenshots of pup anywhere? --------------------------------- Do you Yahoo!? Yahoo! Mail - You care about security. So do we. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Thu Feb 24 19:53:43 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 24 Feb 2005 13:53:43 -0600 Subject: Why is sendmail bad? In-Reply-To: References: Message-ID: <20050224195343.GA17633@yoda.jdub.homelinux.org> On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote: > There seems to be a lot of dissatisfaction with sendmail in the call to > replace it with Exim or Postfix, but I didn't see any specifics about why > people object to it. Anyone care to give details? Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful. That's not to say that sendmail isn't useful or does't work properly. It does. But if a package is going to be the default for a distribution, it should also be fairly simple for new users to configure and adapt to. > > I'm using sendmail together with MIMEDefang to run SpamAssassin and ClamAV > against messages during the SMTP transaction so that I can reject obvious > spam and viruses before they're committed to a queue. MIMEDefang uses a > user-edited Perl script to establish the exact rules for acceptance, making > the system very flexible. How hard is that to set up in Postfix or Exim? I haven't looked at postfix yet (will tonight maybe), but for exim all one has to do is uncomment one line in the default config file once spamassassin and a virus checker are installed. Very easy. josh From notting at redhat.com Thu Feb 24 20:01:33 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 15:01:33 -0500 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109250815.5420.53.camel@hades.cambridge.redhat.com> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> Message-ID: <20050224200133.GE11644@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > Has anyone looked at the possibility of having a shared CD or two > between the x86_64 and i386 installs? Due to dependency ordering of libraries, you'd almost certainly need to do *more* CD swaps if you went this way. (Infrastructure issues aside.) Bill From katzj at redhat.com Thu Feb 24 20:02:59 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Feb 2005 15:02:59 -0500 Subject: reducing distribution CD count In-Reply-To: <1109269425.5420.126.camel@hades.cambridge.redhat.com> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <200502241813.15779.jamatos@fc.up.pt> <1109269425.5420.126.camel@hades.cambridge.redhat.com> Message-ID: <421E32F3.3090005@redhat.com> David Woodhouse wrote: > So nutty that the i386 install tree didn't even build this morning, and > no new mail was sent, afaict. Actually, things just got a little stuck and were completely unrelated to the package removals. Please, leave the conspiracy theories for elsewhere. Jeremy From rjune at bravegnuworld.com Thu Feb 24 20:04:40 2005 From: rjune at bravegnuworld.com (Richard June) Date: Thu, 24 Feb 2005 15:04:40 -0500 Subject: Why is sendmail bad? In-Reply-To: <20050224195343.GA17633@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> Message-ID: <200502241504.44676.rjune@bravegnuworld.com> On Thursday 24 February 2005 14:53, Josh Boyer wrote: > On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote: > > There seems to be a lot of dissatisfaction with sendmail in the call to > > replace it with Exim or Postfix, but I didn't see any specifics about why > > people object to it. Anyone care to give details? > > Most of the discusion has been about what should be the default. For > "newbies" sendmail can be a pain to configure. It's documentation leaves > something to be desired, and the default sendmail.cf file isn't all that > helpful. > > That's not to say that sendmail isn't useful or does't work properly. It > does. But if a package is going to be the default for a distribution, it > should also be fairly simple for new users to configure and adapt to. I take issue to that. sendmail has always been *TONS* easier for me to configure then postfix/exim. the sendmail.mc file is simple to understand and edit. > > I'm using sendmail together with MIMEDefang to run SpamAssassin and > > ClamAV against messages during the SMTP transaction so that I can reject > > obvious spam and viruses before they're committed to a queue. MIMEDefang > > uses a user-edited Perl script to establish the exact rules for > > acceptance, making the system very flexible. How hard is that to set up > > in Postfix or Exim? > > I haven't looked at postfix yet (will tonight maybe), but for exim all one > has to do is uncomment one line in the default config file once > spamassassin and a virus checker are installed. Very easy. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Feb 24 20:06:44 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 15:06:44 -0500 Subject: reducing distribution CD count In-Reply-To: <200502240906.20729.czar@czarc.net> References: <200502240906.20729.czar@czarc.net> Message-ID: <20050224200644.GF11644@nostromo.devel.redhat.com> Gene C. (czar at czarc.net) said: > 2. Lets say something major which a lot of users will want is move out of the > "core core" and into a secondary "repository" which will still be fully > maintained by Red Hat employees. No flaming intended, but lets say this is > kde and all kde associated applications. Now that would be a big chunk but > it would also be something a lot of users would want. What is the current > thinking about how this "secondary repository" will be available to the user? > Furthermore, this must be done in such a manner that it is obvious that Red > Hat is NOT slighting the packages involved. I don't see the reason why something like this would need to exist. It's almost sounds like a slight against Extras, that people wouldn't want to use it. What I would expect to happen is subdivsions of Extras into arbitrary groups that could be CD-ified; I don't think this is technically much work. > 5. There was some mention of RHEL having "extra" packages which are not part > of the RHEL on CDs. How does RHEL handle the extra packages for stand-alone > systems? They're available only in the RHN channel. Bill From ad+lists at uni-x.org Thu Feb 24 20:06:48 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Thu, 24 Feb 2005 21:06:48 +0100 Subject: Why is sendmail bad? In-Reply-To: <20050224195343.GA17633@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> Message-ID: <1109275608.7775.239.camel@serendipity.dogma.lan> Am Do, den 24.02.2005 schrieb Josh Boyer um 20:53: > Most of the discusion has been about what should be the default. For "newbies" > sendmail can be a pain to configure. It's documentation leaves something to be > desired, and the default sendmail.cf file isn't all that helpful. Nobody is advised to edit sendmail.cf and submit.cf directly. Everybody should always use the .mc files and use m4 to generate the .cf files from that. Even a "newbie" can do simple setups this way. The makefile under /etc/mail makes it simple to rebuild the .cf file or even a service restart rebuilds the .cf if .mc files were changed. More complex setup always require a deeper understanding of the whole mail server (MTA side as well IMAP/POP3 side) topic. The basic Sendmail setup shipped with Fedora Core runs out-of-the-box locally. The change to open it for outside connections is a 1 line change. Well understandable documented. A good understanding with running an MTA is needed because a misconfigured MTA not only can influence communication faults with other MTAs but even lead to lost mail. > I haven't looked at postfix yet (will tonight maybe), but for exim all one has > to do is uncomment one line in the default config file once spamassassin and a > virus checker are installed. Very easy. So with Sendmail by calling these kind of applications as a milter entry in the sendmail.mc. > josh Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.10-1.14_FC2smp Serendipity 20:58:22 up 3 days, 8:07, load average: 0.27, 0.37, 0.39 -------------- 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 tadams-lists at myrealbox.com Thu Feb 24 20:13:13 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 24 Feb 2005 13:13:13 -0700 Subject: Summary of Dropped Packages In-Reply-To: <1109273402.28467.23.camel@jkeating2.hq.pogolinux.com> References: <80d7e409050223154464743b99@mail.gmail.com> <20050224041924.GA5236@nostromo.devel.redhat.com> <1109221057.3817.5.camel@one.myworld> <1109221703.10915.63.camel@cutter> <20050224050826.GA2934@thyrsus.com> <1109272214.3369.6.camel@localhost.localdomain> <1109273402.28467.23.camel@jkeating2.hq.pogolinux.com> Message-ID: <1109275994.4574.2.camel@localhost.localdomain> Ok, how about, sendmail is harder to configure to be secure, historically has had more security bugs, and is over kill for most installations. Postfix offers many of the same features, is historically more secure, etc. I didn't go into this, but this is why I like it. It is also a fresher code base, which I tend to like because it often means more maintainability (but not always). Sane does not mean I like it (there are a lot of sane things that I don't care for...), I am sorry I gave that impression. Trever P.S. All of these things may actually mean exim should be the default... but as I said, I don't know much about it. On Thu, 2005-02-24 at 11:30 -0800, Jesse Keating wrote: >On Thu, 2005-02-24 at 12:10 -0700, Trever L. Adams wrote: >> I am not very familiar with exim, but I like postfix very much. Yes, >> kill sendmail. However, please make postfix the default and if exim is >> good, please keep it around as a choice for those who like it. Postfix >> is the sane default I think. >> >> > >So postfix being the 'sane' replacement is based only on it being what >you prefer? Unfortunately single user preferences aren't what decisions >are made on at a distro level. > >-- >Jesse Keating RHCE (geek.j2solutions.net) >Fedora Legacy Team (www.fedoralegacy.org) >GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > >Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating > -- The Feynman problem solving Algorithm 1) Write down the problem 2) Think real hard 3) Write down the answer -- Murray Gell-mann in the NY Times From dwmw2 at infradead.org Thu Feb 24 20:17:04 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 20:17:04 +0000 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <20050224200133.GE11644@nostromo.devel.redhat.com> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> <20050224200133.GE11644@nostromo.devel.redhat.com> Message-ID: <1109276224.26364.33.camel@localhost.localdomain> On Thu, 2005-02-24 at 15:01 -0500, Bill Nottingham wrote: >Due to dependency ordering of libraries, you'd almost certainly >need to do *more* CD swaps if you went this way. Why so? The i386 packages available on the x86_64 installation are a set with complete dependency closure, surely? So they could reasonably be first in the i386 pkgorder, and hence on the i386 CD 1? If we also include as many of the noarch packages as we can on i386 CD 1, could we not have a reasonable expectation of fitting that into the x86_64 pkgorder -- as a block which is a fairly independent set? Or does anaconda actually have to install both packages in an {i386,x86_64} multilib set simultaneously? -- dwmw2 From Axel.Thimm at ATrpms.net Thu Feb 24 20:18:53 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 Feb 2005 21:18:53 +0100 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109250815.5420.53.camel@hades.cambridge.redhat.com> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> Message-ID: <20050224201853.GB31775@neu.nirvana> On Thu, Feb 24, 2005 at 01:13:35PM +0000, David Woodhouse wrote: > Has anyone looked at the possibility of having a shared CD or two > between the x86_64 and i386 installs? > > There's 412300KiB of noarch packages which are present in both x86_64 > and i386, and 436108KiB of i[36]86 packages in the x86_64 tree. and you can probably double this number if some packages would cast out their noarch stuff disguised as arch-dependend. For example almost all of tetex is noarch in essence (the whole texmf tree), which already adds up to 150-200M. Splitting out the texmf tree is a bit painful, it requires two src.rpms. > If a package ordering can be found which allows a bunch of those to go > onto a CD which is shared between x86_64 and i386 installations, we get > to lose a CD out of the set without running around like headless > chickens trying to excise useful packages to make the i386 tree smaller. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Thu Feb 24 20:17:57 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 24 Feb 2005 12:17:57 -0800 Subject: rawhide report: 20050222 changes In-Reply-To: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com>; from buildsys@redhat.com on Tue, Feb 22, 2005 at 02:07:26PM -0500 References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> Message-ID: <20050224121757.A29720@tiki-lounge.com> On Tue, Feb 22, 2005 at 02:07:26PM -0500, Build System wrote: > python-twisted-1.3.0-3 > ---------------------- > * Mon Feb 21 2005 Jeremy Katz - 1.3.0-3 > - disable the -docs subpackage for now I understand we're trying to trim sizes down at the moment, but I would hate to see this trend taken too far. Having local docs is very valuable when networks are not available (plane rides, dialup, etc) or when trying to quickly find information on a package. (I've used the online docs for python and php's standard libraries in preference to the local copies. But for add-on libraries and programs I always check /usr/share/docs first. It's because the quality of online docs is sometimes excellent and sometimes not worth the effort of searching. /usr/share/docs is easy to access and grep.) *Note: In twisted's particular case it looks as though the documentation is downloadable separately from the code. So if we were to make the change permanent a good course of action would be to use Twisted_NoDocs-1.3.0.tar.bz2 in the Core SRPM and have a separate python-twisted-docs package in Extras that uses the TwistedDocs-1.3.0.tar.bz2 tarball. -Toshio From dwmw2 at infradead.org Thu Feb 24 20:22:50 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 20:22:50 +0000 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <20050224201853.GB31775@neu.nirvana> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> <20050224201853.GB31775@neu.nirvana> Message-ID: <1109276570.26364.35.camel@localhost.localdomain> On Thu, 2005-02-24 at 21:18 +0100, Axel Thimm wrote: >and you can probably double this number if some packages would cast >out their noarch stuff disguised as arch-dependend. > >For example almost all of tetex is noarch in essence (the whole texmf >tree), which already adds up to 150-200M. > >Splitting out the texmf tree is a bit painful, it requires two >src.rpms. The kernel manages to build both arch-specific and noarch rpms from the same source. Why couldn't tetex? -- dwmw2 From katzj at redhat.com Thu Feb 24 20:24:48 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Feb 2005 15:24:48 -0500 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109276224.26364.33.camel@localhost.localdomain> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> <20050224200133.GE11644@nostromo.devel.redhat.com> <1109276224.26364.33.camel@localhost.localdomain> Message-ID: <421E3810.3020309@redhat.com> David Woodhouse wrote: > Or does anaconda actually have to install both packages in an > {i386,x86_64} multilib set simultaneously? In a lot of cases, yes, due to details of how things work within rpmlib. Jeremy From michael.favia at insitesinc.com Thu Feb 24 20:25:24 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 24 Feb 2005 14:25:24 -0600 Subject: reducing distribution CD count In-Reply-To: <20050224200644.GF11644@nostromo.devel.redhat.com> References: <200502240906.20729.czar@czarc.net> <20050224200644.GF11644@nostromo.devel.redhat.com> Message-ID: <421E3834.6050707@insitesinc.com> Bill Nottingham wrote: >Gene C. (czar at czarc.net) said: > > >>2. Lets say something major which a lot of users will want is move out of the >>"core core" and into a secondary "repository" which will still be fully >>maintained by Red Hat employees. No flaming intended, but lets say this is >>kde and all kde associated applications. Now that would be a big chunk but >>it would also be something a lot of users would want. What is the current >>thinking about how this "secondary repository" will be available to the user? >>Furthermore, this must be done in such a manner that it is obvious that Red >>Hat is NOT slighting the packages involved. >> >> > >I don't see the reason why something like this would need to exist. >It's almost sounds like a slight against Extras, that people wouldn't >want to use it. > > I dont think that it was intended as a slight but rather a response to the general hands off approach [seemingly] surrounding extras. What Gene was getting at i think was that RetHat expressed its desire to drop the aforementioned packages becuase of space limitation on the distribution media not developer maintenance limitations. Perhaps i am misunderstanding both the nature of extras and the intent of the original author but this is the feeling i have from the outside as well. As a result i think he was looking for a safe place for RedHat to continue maintenance of these packages even if they arent distributed by default (for obvious reasons). Is it a misstatement that packages in extras are relinquished to community maintenance? or does redhat continue maintenance as well? -mf From katzj at redhat.com Thu Feb 24 20:30:25 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Feb 2005 15:30:25 -0500 Subject: New fedora-maintainers-readonly list Message-ID: <421E3961.80508@redhat.com> A new list (well, two actually) has been created for maintainers of packages in Fedora Core and/or Extras. At this time, you will be subscribed to this list when you get access to CVS. For people interested in following discussions who do not own packages, you can subscribe to a readonly copy of the list at http://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly. And, for reference again, information on becoming a package maintainer for a package in Fedora Extras is available at http://www.fedoraproject.org/wiki/Extras_2fCvsAccess Jeremy From Axel.Thimm at ATrpms.net Thu Feb 24 20:35:48 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 Feb 2005 21:35:48 +0100 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109276570.26364.35.camel@localhost.localdomain> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> <20050224201853.GB31775@neu.nirvana> <1109276570.26364.35.camel@localhost.localdomain> Message-ID: <20050224203548.GC31775@neu.nirvana> On Thu, Feb 24, 2005 at 08:22:50PM +0000, David Woodhouse wrote: > On Thu, 2005-02-24 at 21:18 +0100, Axel Thimm wrote: > >and you can probably double this number if some packages would cast > >out their noarch stuff disguised as arch-dependend. > > > >For example almost all of tetex is noarch in essence (the whole texmf > >tree), which already adds up to 150-200M. > > > >Splitting out the texmf tree is a bit painful, it requires two > >src.rpms. > > The kernel manages to build both arch-specific and noarch rpms from the > same source. Why couldn't tetex? It could if called multiple times like the kernel is called. But the kernel package and support calls on creating the noarch parts show that this is not trivial for the users, no matter how well documented in the release notes. Anyway the potential is there, but OTOH that would save on the total number of CDs (by having common CDs), not on the number of CDs required per platform (don't know which is the harder request). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From leonard at den.ottolander.nl Thu Feb 24 20:40:29 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 24 Feb 2005 21:40:29 +0100 Subject: Summary of Dropped Packages In-Reply-To: <80d7e409050223154464743b99@mail.gmail.com> References: <80d7e409050223154464743b99@mail.gmail.com> Message-ID: <1109277629.4808.49.camel@athlon.localdomain> Hi, On Thu, 2005-02-24 at 00:44, Stephen J. Smoogen wrote: > Is there a summary of all the packages that have been > dropped to meet the 4 CDRom limit? Knowing that packages usually grow in size, will we have to go through a package killing spree for every upcoming release of Fedora to keep the distro size down to 4 CDs? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jwboyer at jdub.homelinux.org Thu Feb 24 20:42:45 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 24 Feb 2005 14:42:45 -0600 Subject: Why is sendmail bad? In-Reply-To: <200502241504.44676.rjune@bravegnuworld.com> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <200502241504.44676.rjune@bravegnuworld.com> Message-ID: <20050224204245.GA17728@yoda.jdub.homelinux.org> On Thu, Feb 24, 2005 at 03:04:40PM -0500, Richard June wrote: > On Thursday 24 February 2005 14:53, Josh Boyer wrote: > > On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote: > > > There seems to be a lot of dissatisfaction with sendmail in the call to > > > replace it with Exim or Postfix, but I didn't see any specifics about why > > > people object to it. Anyone care to give details? > > > > Most of the discusion has been about what should be the default. For > > "newbies" sendmail can be a pain to configure. It's documentation leaves > > something to be desired, and the default sendmail.cf file isn't all that > > helpful. > > > > That's not to say that sendmail isn't useful or does't work properly. It > > does. But if a package is going to be the default for a distribution, it > > should also be fairly simple for new users to configure and adapt to. > > I take issue to that. sendmail has always been *TONS* easier for me to > configure then postfix/exim. the sendmail.mc file is simple to understand and > edit. I guess we'll have to agree to disagree. Anything that requires using m4 after editing a config file isn't intuitive IMHO. josh From pekkas at netcore.fi Thu Feb 24 20:44:35 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 24 Feb 2005 22:44:35 +0200 (EET) Subject: New fedora-maintainers-readonly list In-Reply-To: <421E3961.80508@redhat.com> References: <421E3961.80508@redhat.com> Message-ID: On Thu, 24 Feb 2005, Jeremy Katz wrote: > http://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly. Please make the archives readable by non-subscribers. Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jspaleta at gmail.com Thu Feb 24 20:46:37 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Feb 2005 15:46:37 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109277629.4808.49.camel@athlon.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <1109277629.4808.49.camel@athlon.localdomain> Message-ID: <604aa79105022412462531b6ad@mail.gmail.com> On Thu, 24 Feb 2005 21:40:29 +0100, Leonard den Ottolander > Knowing that packages usually grow in size, will we have to go through a > package killing spree for every upcoming release of Fedora to keep the > distro size down to 4 CDs? Yes.. eventually OO.org will grow to take up 4 cds. But by that point it will be a general purpose operating system in its own right, so we won't notice a difference in the end. All this nashing of teeth is just growing pains. -jef"or maybe i mean emacs.. substitute whatever application sounds funniest"spaleta From katzj at redhat.com Thu Feb 24 20:50:40 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Feb 2005 15:50:40 -0500 Subject: New fedora-maintainers-readonly list In-Reply-To: References: <421E3961.80508@redhat.com> Message-ID: <421E3E20.70107@redhat.com> Pekka Savola wrote: > On Thu, 24 Feb 2005, Jeremy Katz wrote: >> http://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly. > > Please make the archives readable by non-subscribers. Thanks. Please read the text on the listinfo page ;-) This is a read-only copy of the fedora-maintainers mailing list. This list is not archived; please use the fedora-maintainers archive instead. Unfortunately, mailman is stupid and doesn't disable the archive link if a list doesn't archive things :-) Jeremy From florin at andrei.myip.org Thu Feb 24 20:54:06 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 24 Feb 2005 12:54:06 -0800 Subject: Exim as default MTA. In-Reply-To: <20050223150824.GA924815@hiwaay.net> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> Message-ID: <1109278446.11626.31.camel@stantz.corp.sgi.com> On Wed, 2005-02-23 at 09:08 -0600, Chris Adams wrote: > The biggest question is still the upgrade issue; if sendmail is removed > from Core, what will happen on upgrades? Users will be left with the > old version of sendmail running. As much as i hate saying it, probably dropping Sendmail is not a good move. After all, it still is the standard MTA in many places. The current situation (Sendmail as default, another MTA as an alternative, plus an easy way to switch between them) is best at the moment. If Sendmail's "market share" declines drastically, then switching the default should be easy. -- Florin Andrei http://florin.myip.org/ From nalin at redhat.com Thu Feb 24 20:55:51 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 24 Feb 2005 15:55:51 -0500 Subject: New fedora-maintainers-readonly list In-Reply-To: <421E3E20.70107@redhat.com> References: <421E3961.80508@redhat.com> <421E3E20.70107@redhat.com> Message-ID: <20050224205551.GB27432@redhat.com> On Thu, Feb 24, 2005 at 03:50:40PM -0500, Jeremy Katz wrote: > Pekka Savola wrote: > >On Thu, 24 Feb 2005, Jeremy Katz wrote: > >>http://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly. > > > >Please make the archives readable by non-subscribers. Thanks. > > Please read the text on the listinfo page ;-) Please fix the link on the above page to point to the correct location. ATM it points to https://www.redhat.com/mailman/private/fedora-maintainers/, when it should point to https://www.redhat.com/archives/fedora-maintainers/. Wow, writing one-liner replies is fun! Nalin From jwboyer at jdub.homelinux.org Thu Feb 24 20:56:11 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 24 Feb 2005 14:56:11 -0600 Subject: Why is sendmail bad? In-Reply-To: <1109275608.7775.239.camel@serendipity.dogma.lan> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> Message-ID: <20050224205611.GB17728@yoda.jdub.homelinux.org> On Thu, Feb 24, 2005 at 09:06:48PM +0100, Alexander Dalloz wrote: > Am Do, den 24.02.2005 schrieb Josh Boyer um 20:53: > > > Most of the discusion has been about what should be the default. For "newbies" > > sendmail can be a pain to configure. It's documentation leaves something to be > > desired, and the default sendmail.cf file isn't all that helpful. > > Nobody is advised to edit sendmail.cf and submit.cf directly. Everybody > should always use the .mc files and use m4 to generate the .cf files > from that. Yes, sorry. I meant sendmail.mc. > Even a "newbie" can do simple setups this way. The makefile under > /etc/mail makes it simple to rebuild the .cf file or even a service > restart rebuilds the .cf if .mc files were changed. Yes, but with exim you don't need to run make. You just edit the config file and you're done. > More complex setup always require a deeper understanding of the whole > mail server (MTA side as well IMAP/POP3 side) topic. The basic Sendmail > setup shipped with Fedora Core runs out-of-the-box locally. The change > to open it for outside connections is a 1 line change. Well > understandable documented. Really? I disagree. I hardly know anything about mail servers, yet I exim allows me to run spam and virus checking by simply uncommenting one line. And unlike sendmail, I didn't have to explicitly enable outside connections. > A good understanding with running an MTA is needed because a > misconfigured MTA not only can influence communication faults with other > MTAs but even lead to lost mail. I'll agree that it's always a good idea to learn about things. But that doesn't mean that an MTA can't be configured to do more advanced feature out of the box. > > So with Sendmail by calling these kind of applications as a milter entry > in the sendmail.mc. Sure, but a user needs to know what a milter entry is right? And how to set it up to do what you need it to do, etc. I don't have a clue what a milter entry is. I'm not saying sendmail can't do equivalent (or even more) things. I don't claim to know a lot about MTAs, what makes them good, what doesn't, and why one is better than the other. I'm just saying that from a newbie perspective (mine), exim was easier for me to use. josh From florin at andrei.myip.org Thu Feb 24 20:59:48 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 24 Feb 2005 12:59:48 -0800 Subject: Why is sendmail bad? In-Reply-To: References: Message-ID: <1109278788.11626.36.camel@stantz.corp.sgi.com> On Thu, 2005-02-24 at 11:45 -0800, Kenneth Porter wrote: > There seems to be a lot of dissatisfaction with sendmail in the call to > replace it with Exim or Postfix, but I didn't see any specifics about why > people object to it. Anyone care to give details? When i switched from Sendmail to Qmail then to Postfix, the biggest reason was Qmail's and Postfix's modular architecture, which allows not only much better security, but more flexibility and better performance. The same argument worked for Postfix and Qmail, but against Sendmail and Exim. I would have stayed with Qmail, were it not for it's weird licence and lack of active development. -- Florin Andrei http://florin.myip.org/ From katzj at redhat.com Thu Feb 24 21:00:12 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Feb 2005 16:00:12 -0500 Subject: New fedora-maintainers-readonly list In-Reply-To: <20050224205551.GB27432@redhat.com> References: <421E3961.80508@redhat.com> <421E3E20.70107@redhat.com> <20050224205551.GB27432@redhat.com> Message-ID: <421E405C.1000407@redhat.com> Nalin Dahyabhai wrote: > On Thu, Feb 24, 2005 at 03:50:40PM -0500, Jeremy Katz wrote: > >>Pekka Savola wrote: >> >>>On Thu, 24 Feb 2005, Jeremy Katz wrote: >>> >>>>http://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly. >>> >>>Please make the archives readable by non-subscribers. Thanks. >> >>Please read the text on the listinfo page ;-) > > > Please fix the link on the above page to point to the correct location. > > ATM it points to https://www.redhat.com/mailman/private/fedora-maintainers/, > when it should point to https://www.redhat.com/archives/fedora-maintainers/. > > Wow, writing one-liner replies is fun! Erk. Sorry about that. Fixed Jeremy From strange at nsk.no-ip.org Thu Feb 24 21:01:33 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 24 Feb 2005 21:01:33 +0000 Subject: nash, initrd, cpio... In-Reply-To: <1109252274.3603.58.camel@localhost.localdomain> References: <1109232908.3603.3.camel@localhost.localdomain> <20050224130534.GA4119@nsk.no-ip.org> <1109252274.3603.58.camel@localhost.localdomain> Message-ID: <20050224210133.GB17007@nsk.no-ip.org> On Thu, Feb 24, 2005 at 02:37:54PM +0100, Gildas Bayard wrote: > Ok. Now I clearly see the advantages of using cpio instead of an ext2 > filesystem. > > It seems like when initrd is a cpio archive then "init" is executed > instead of "linuxrc". So I converted my FC3 initrd cpio archive into an > ext2 (just to test, I understand I should switch to the cpio way). I > changed "init" into "linuxrc" and though it would do it. > But it did not. > The ext2 (linuxrc) version jumps to the new root fs but init complains > about missing parameter (runlevel) and quits. > Do you know what's happening? Yes. You're exec'ing the new init with pid != 1. In initrds, the linuxrc doesn't run as init. You may have the effect you want booting the kernel with init=/linuxrc root=/dev/ram0 Also, the state of the kernel when running the cpio's init is very different than when running initrd's linuxrc/init. http://www.ubuntulinux.org/wiki/Initramfs and Documentation/early-userspace have more information about initramfs (the new process). > echo 0x0100 > /proc/sys/kernel/real-root-dev > pivot_root /sysroot /sysroot/initrd > It now works fine but I don't really understand why... > I'm booting on usual /dev/hda# so why should I report the kernel that > the real-root-dev is 0x0100 (which corresponds to the first ram disk)? Because you've already mounted the root partition. Why 0x0100 is special, in that the kernel uses the current root partition, I don't know. Regards, Luciano Rocha From leonard at den.ottolander.nl Thu Feb 24 21:08:40 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 24 Feb 2005 22:08:40 +0100 Subject: Summary of Dropped Packages In-Reply-To: <604aa79105022412462531b6ad@mail.gmail.com> References: <80d7e409050223154464743b99@mail.gmail.com> <1109277629.4808.49.camel@athlon.localdomain> <604aa79105022412462531b6ad@mail.gmail.com> Message-ID: <1109279320.4808.55.camel@athlon.localdomain> Hi Jef, On Thu, 2005-02-24 at 21:46, Jeff Spaleta wrote: > Yes.. eventually OO.org will grow to take up 4 cds. But by that point > it will be a general purpose operating system in its own right, so we > won't notice a difference in the end. All this nashing of teeth is > just growing pains. Seems more like a case of shrinking pains to me. Anyway, not really an answer to my question is it? With individual packages growing we will have lack of room on the 4 CDs for the next release as well. Long before OOo grows to 4 CDs all by itself. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From sopwith at redhat.com Thu Feb 24 21:11:13 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 16:11:13 -0500 (EST) Subject: Summary of Dropped Packages In-Reply-To: <1109277629.4808.49.camel@athlon.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <1109277629.4808.49.camel@athlon.localdomain> Message-ID: On Thu, 24 Feb 2005, Leonard den Ottolander wrote: > On Thu, 2005-02-24 at 00:44, Stephen J. Smoogen wrote: > > Is there a summary of all the packages that have been > > dropped to meet the 4 CDRom limit? > > Knowing that packages usually grow in size, will we have to go through a > package killing spree for every upcoming release of Fedora to keep the > distro size down to 4 CDs? Pretty much, yea. It's really easy to let the distro grow without bounds. We have to be disciplined enough to take on a little bit of pain now so that things don't become unmanageable later. Cheers, -- Elliot From ad+lists at uni-x.org Thu Feb 24 21:17:13 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Thu, 24 Feb 2005 22:17:13 +0100 Subject: Why is sendmail bad? In-Reply-To: <20050224205611.GB17728@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> Message-ID: <1109279833.7775.251.camel@serendipity.dogma.lan> Am Do, den 24.02.2005 schrieb Josh Boyer um 21:56: > > Even a "newbie" can do simple setups this way. The makefile under > > /etc/mail makes it simple to rebuild the .cf file or even a service > > restart rebuilds the .cf if .mc files were changed. > > Yes, but with exim you don't need to run make. You just edit the config file > and you're done. As said too, same with Sendmail: just restart the service so that it rereads his configuration. > > More complex setup always require a deeper understanding of the whole > > mail server (MTA side as well IMAP/POP3 side) topic. The basic Sendmail > > setup shipped with Fedora Core runs out-of-the-box locally. The change > > to open it for outside connections is a 1 line change. Well > > understandable documented. > > Really? I disagree. I hardly know anything about mail servers, yet I exim > allows me to run spam and virus checking by simply uncommenting one line. And > unlike sendmail, I didn't have to explicitly enable outside connections. That is an argument to "improve" the default setup Sendmail is shipping with Fedora Core. I wonder a bit that Exim is shipped wide open to the net, because both Sendmail and Postfix are limited to localhost with good reasons. > > So with Sendmail by calling these kind of applications as a milter entry > > in the sendmail.mc. > > Sure, but a user needs to know what a milter entry is right? And how to set it > up to do what you need it to do, etc. I don't have a clue what a milter entry > is. You don't know because you didn't read the documentation. It is ok as you don't run Sendmail. My argument was different: anyone running an MTA reachable from the public internet should know well about his service. This is very obvious for all who's daily business is mail administration. > I'm not saying sendmail can't do equivalent (or even more) things. I don't > claim to know a lot about MTAs, what makes them good, what doesn't, and why one > is better than the other. I'm just saying that from a newbie perspective > (mine), exim was easier for me to use. If you feel so, ok. From reading the Exim documentation I don't have the impression that the Exim configuration is that intuitive. > josh Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.10-1.14_FC2smp Serendipity 22:09:50 up 3 days, 9:18, load average: 0.13, 0.34, 0.44 -------------- 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 thacker at math.cornell.edu Thu Feb 24 21:17:26 2005 From: thacker at math.cornell.edu (John Thacker) Date: Thu, 24 Feb 2005 16:17:26 -0500 Subject: Why is sendmail bad? In-Reply-To: <20050224205611.GB17728@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> Message-ID: <20050224211726.GA2713@thacker.dyndns.org> On Thu, Feb 24, 2005 at 02:56:11PM -0600, Josh Boyer wrote: > Really? I disagree. I hardly know anything about mail servers, yet I exim > allows me to run spam and virus checking by simply uncommenting one line. > And unlike sendmail, I didn't have to explicitly enable outside connections. Bug not feature. The default sendmail configuration explicitly disables outside connections for a reason. They shouldn't be enabled unless you're running a real server that needs outside connections, and you shouldn't be running one if you "hardly know anything about mail servers." Besides, enabling outside connetions is simply commenting one line which is heavily documented in the four lines above it in the default sendmail.mc. As you yourself already stated, commenting and uncommenting one line is a simple matter, easy to do, especially with such explicit instructions. :) John -------------- 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 Thu Feb 24 21:21:33 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 24 Feb 2005 22:21:33 +0100 Subject: Summary of Dropped Packages In-Reply-To: References: <80d7e409050223154464743b99@mail.gmail.com> <1109277629.4808.49.camel@athlon.localdomain> Message-ID: <1109280092.4808.61.camel@athlon.localdomain> Hi Elliot, On Thu, 2005-02-24 at 22:11, Elliot Lee wrote: > Pretty much, yea. It's really easy to let the distro grow without bounds. > We have to be disciplined enough to take on a little bit of pain now so > that things don't become unmanageable later. Do we already have a list of likely candidates? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From shiva at sewingwitch.com Thu Feb 24 21:22:14 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 24 Feb 2005 13:22:14 -0800 Subject: Why is sendmail bad? In-Reply-To: <20050224205611.GB17728@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> Message-ID: --On Thursday, February 24, 2005 2:56 PM -0600 Josh Boyer wrote: > Yes, but with exim you don't need to run make. You just edit the config > file and you're done. So typing "make" is hard for someone who's able to use a text editor? Currently sendmail is launched via a symlink used to enable MTA switching. I suppose one could add more indirection and invoke it by a script that runs Make first. > Really? I disagree. I hardly know anything about mail servers, yet I > exim allows me to run spam and virus checking by simply uncommenting one > line. And unlike sendmail, I didn't have to explicitly enable outside > connections. So should RH ship sendmail's config set to accept incoming connections, or close Exim for workstation users who have no business receiving SMTP connections? That's a packaging bug, not a usability issue; one of the packages is shipped with the wrong setting. If uncommenting a line to enable inbound connections is "hard" for a newbie sendmail user, wouldn't the same action to enable scanning in Exim be just as hard? > Sure, but a user needs to know what a milter entry is right? And how to > set it up to do what you need it to do, etc. I don't have a clue what a > milter entry is. milter = mail filter. A sendmail plug-in. It gets called for each step of the SMTP conversation. Milters exist for several AV's and spam scanners, and MIMEDefang lets you run arbitrary Perl to perform complex matching and decisions. From tibbs at math.uh.edu Thu Feb 24 21:24:12 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 24 Feb 2005 15:24:12 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109268957.5420.122.camel@hades.cambridge.redhat.com> (David Woodhouse's message of "Thu, 24 Feb 2005 18:15:57 +0000") References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> <1109268957.5420.122.camel@hades.cambridge.redhat.com> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Either you want it capable of queueing, or you don't -- you can't DW> have both ;) Well, uh, yeah. The point is that even Exim's restricted mode isn't a good fit because it won't queue. But then I stated earlier that Exim (along with Postfix) posses far more functionality than is necessary (or safe) for the average machine. I have used Exim exclusively for years, BTW. But it and the other SMTP servers really are the wrong tools for the job here. Or, to be more precise, they are far too much tool for the job. - J< From mattdm at mattdm.org Thu Feb 24 21:25:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 16:25:21 -0500 Subject: Exim as default MTA. In-Reply-To: <1109278446.11626.31.camel@stantz.corp.sgi.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> <1109278446.11626.31.camel@stantz.corp.sgi.com> Message-ID: <20050224212521.GA19244@jadzia.bu.edu> On Thu, Feb 24, 2005 at 12:54:06PM -0800, Florin Andrei wrote: > As much as i hate saying it, probably dropping Sendmail is not a good > move. After all, it still is the standard MTA in many places. > The current situation (Sendmail as default, another MTA as an > alternative, plus an easy way to switch between them) is best at the > moment. If Sendmail's "market share" declines drastically, then > switching the default should be easy. Dropping it may be drastic; it could be moved to extras. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From elanthis at awesomeplay.com Thu Feb 24 21:25:16 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 24 Feb 2005 16:25:16 -0500 Subject: Summary of Dropped Packages In-Reply-To: <1109279320.4808.55.camel@athlon.localdomain> References: <80d7e409050223154464743b99@mail.gmail.com> <1109277629.4808.49.camel@athlon.localdomain> <604aa79105022412462531b6ad@mail.gmail.com> <1109279320.4808.55.camel@athlon.localdomain> Message-ID: <1109280317.29835.2.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2005-02-24 at 22:08 +0100, Leonard den Ottolander wrote: >Hi Jef, > >On Thu, 2005-02-24 at 21:46, Jeff Spaleta wrote: >> Yes.. eventually OO.org will grow to take up 4 cds. But by that point >> it will be a general purpose operating system in its own right, so we >> won't notice a difference in the end. All this nashing of teeth is >> just growing pains. > >Seems more like a case of shrinking pains to me. Anyway, not really an >answer to my question is it? With individual packages growing we will >have lack of room on the 4 CDs for the next release as well. Long before >OOo grows to 4 CDs all by itself. Packages always growing? Bah, every programmer knows that the most useful tool is the delete key. ;-) In all seriousness, a lot of the best software development manages to add features *and* shrink the codebase *and* make everything faster. Eventually, yes, it will probably become impossible to fit a complete OS (and mainstream apps) on a couple CDs. By that time, though, one would hope that DVDs would be more common place as a software distribution mechanism. Not much longer than a decade ago it was rather far-fetched to think that you could distribute software without offering a floppy version. ;-) > >Leonard. > >-- >mount -t life -o ro /dev/dna /genetic/research > > -- Sean Middleditch From dwmw2 at infradead.org Thu Feb 24 21:26:26 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 21:26:26 +0000 Subject: Exim as default MTA. In-Reply-To: <20050224212521.GA19244@jadzia.bu.edu> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> <1109278446.11626.31.camel@stantz.corp.sgi.com> <20050224212521.GA19244@jadzia.bu.edu> Message-ID: <1109280386.26364.40.camel@localhost.localdomain> On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote: >Dropping it may be drastic; it could be moved to extras. Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't going to fit onto 4 CDs, we have no need to drop _anything_ until then, when we can do it in a controlled fashion. > -- dwmw2 From feliciano.matias at free.fr Thu Feb 24 21:28:35 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 22:28:35 +0100 Subject: reducing distribution CD count In-Reply-To: <200502240906.20729.czar@czarc.net> References: <200502240906.20729.czar@czarc.net> Message-ID: <1109280515.3817.123.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 09:06 -0500, Gene C. a ?crit : > (...) > Comments? Sorry for my English. Sad news : > On Tue, Feb 22, 2005 at 02:07:26PM -0500, Build System wrote: > python-twisted-1.3.0-3 > ---------------------- > * Mon Feb 21 2005 Jeremy Katz - 1.3.0-3 > - disable the -docs subpackage for now I read many things about how to reduce CD count. Nothing really "shocking". But what I *really* don't like is the split of project between FC and FE like exim in FC and exim-doc in FE *only* because exim-doc is "too big". I want exim in FC or in FE and not some parts in FC and other parts in FE. 1- The documentation is *important*. Documenting is not a pleasant job. 2- Red Hat does not provide clear rules to chose which documentation "deserve" to be in FC. 3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing. If Red Hat state "*all* documentation will be in FE" I'll said "OK, go for it" (this imply to create a lot of prog-doc packages). If someone ask me where is the documentation I will point FE (end of the story). But with this new policy I'll reply with "I don't really know, it's depend on the feeling of Red Hat". Other point I don't like, Red Hat is introducing the size criteria : - "Sorry, good project but too big". Until now, Fedora is a meritocracy and not a "weightwatcherscracy". I know that FC can't provide all softwares around the world. I this case increase the level of admittance and forget the weightwatchers dictatorship. The big KDE deserve to be in FC (even if I don't use it) but with this new policy you see some people requesting to move KDE to FE. Other want to drop i18n, ... It's bad(tm). -devel package : 15O Mo Perhaps we can move all development packages and tools to FE. Fedora need clear rules. -------------- 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 shiva at sewingwitch.com Thu Feb 24 21:29:39 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 24 Feb 2005 13:29:39 -0800 Subject: Why is sendmail bad? In-Reply-To: <20050224195343.GA17633@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> Message-ID: <2DEC1D3143F202D81A683349@[10.169.6.246]> --On Thursday, February 24, 2005 1:53 PM -0600 Josh Boyer wrote: > But if a package is going to be the default for a distribution, it should > also be fairly simple for new users to configure and adapt to. What MTA configuration would a new user be expected to do? It sounds like the big one is enabling inbound scanning. How "RPM-friendly" are Exim and Postfix to adding plug-ins? Can I just run the install RPM for the plug-in and these MTA's pick them up? Or is manual configuration necessary? (For comparison, most sendmail plug-ins currently require manual configuration, usually by copying some lines from the plug-in's readme to the sendmail.mc file. But a smarter plug-in could just provide an M4 file to include in sendmail's cf "feature" files and the user could just re-make the mc file to incorporate it.) From mattdm at mattdm.org Thu Feb 24 21:31:43 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 16:31:43 -0500 Subject: Exim as default MTA. In-Reply-To: <1109280386.26364.40.camel@localhost.localdomain> References: <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> <1109278446.11626.31.camel@stantz.corp.sgi.com> <20050224212521.GA19244@jadzia.bu.edu> <1109280386.26364.40.camel@localhost.localdomain> Message-ID: <20050224213143.GA19552@jadzia.bu.edu> On Thu, Feb 24, 2005 at 09:26:26PM +0000, David Woodhouse wrote: > On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote: > >Dropping it may be drastic; it could be moved to extras. > Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't > going to fit onto 4 CDs, we have no need to drop _anything_ until then, > when we can do it in a controlled fashion. Sounds reasonable. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sopwith at redhat.com Thu Feb 24 21:32:16 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 16:32:16 -0500 (EST) Subject: reducing distribution CD count In-Reply-To: <1109280515.3817.123.camel@one.myworld> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> Message-ID: On Thu, 24 Feb 2005, [ISO-8859-1] F?liciano Matias wrote: > But what I *really* don't like is the split of project between FC and FE > like exim in FC and exim-doc in FE *only* because exim-doc is "too big". > I want exim in FC or in FE and not some parts in FC and other parts in > FE. Yea, that split was crack. At this point the plan is to have exim entirely in Extras. -- Elliot From jwz at jwz.org Thu Feb 24 21:32:33 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Thu, 24 Feb 2005 13:32:33 -0800 Subject: reducing distribution CD count References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> Message-ID: <421E47F1.1E43FD74@jwz.org> Filiciano Matias wrote: > > 3- The average joe (me) expect to find the documentation in the same > place than the program. A program with its documentation is the same > whole thing. Perhaps I'm not an "average joe" in this matter, but I never look for documentation on the local disk. I *always* use Google first. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From tibbs at math.uh.edu Thu Feb 24 21:33:04 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 24 Feb 2005 15:33:04 -0600 Subject: reducing distribution CD count In-Reply-To: <1109267770.15658.0.camel@opus.phy.duke.edu> (seth vidal's message of "Thu, 24 Feb 2005 12:56:10 -0500") References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> Message-ID: >>>>> "sv" == seth vidal writes: sv> http://fedoraproject.org/wiki/Extras_2fOrphanedPackages Does the fact that a package has been dropped from Core imply that it is orphaned? - J< From Nicolas.Mailhot at laPoste.net Thu Feb 24 21:33:32 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 24 Feb 2005 22:33:32 +0100 Subject: Exim as default MTA. In-Reply-To: <1109278446.11626.31.camel@stantz.corp.sgi.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> <1109278446.11626.31.camel@stantz.corp.sgi.com> Message-ID: <1109280814.15454.18.camel@rousalka.dyndns.org> Le jeudi 24 f?vrier 2005 ? 12:54 -0800, Florin Andrei a ?crit : >On Wed, 2005-02-23 at 09:08 -0600, Chris Adams wrote: > >> The biggest question is still the upgrade issue; if sendmail is removed >> from Core, what will happen on upgrades? Users will be left with the >> old version of sendmail running. > >As much as i hate saying it, probably dropping Sendmail is not a good >move. After all, it still is the standard MTA in many places. Really someone should have the courage to drive the stake in sendmail's heart. Else it'll still rise from its coffin in ten years. Being not entreprise-oriented FC is the place to do so. We've made much more impacting changes in the past. The few people who really need sendmail can install it from extras - but I doubt there will be so many of them (entreprise people will replace the distribution sendmail with the one bundled in their favorite proprietary enterprise bundle anyway). Most users either don't care about advanced features and will be happy with the default config shipped by FC (regardless of the MTA) or will be perfectly able to master postfix or exim syntax. Despite what people think MTA config is not the same in 2005 as it was in the 1990s. After all with the level spam reaches nowadays any admin worth this name should have spend some time learning how to plug new filters in his system. This is usually much more difficult than adapting to the simplicity of postfix/exim config. 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 cra at WPI.EDU Thu Feb 24 21:35:00 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Thu, 24 Feb 2005 16:35:00 -0500 Subject: Why is sendmail bad? In-Reply-To: References: Message-ID: <20050224213500.GJ28055@angus.ind.WPI.EDU> On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote: > There seems to be a lot of dissatisfaction with sendmail in the call to > replace it with Exim or Postfix, but I didn't see any specifics about why > people object to it. Anyone care to give details? In my environment, on 99% of all systems, I've never needed anything but a simple queue-to-smarthost mail sending daemon, with no receive functionality at all. Therefore, I don't care which mail daemon is included, as long as it can do that and supports some type of /etc/aliases file. I'd actually prefer to see a simple ssmtp-like program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't expand local aliases). On the 1 or 2 systems that do need a full mail server, our mail admins roll their own builds/installs of sendmail anyway. From feliciano.matias at free.fr Thu Feb 24 21:37:50 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 22:37:50 +0100 Subject: Update website to mention CVS, Extras? In-Reply-To: References: <20050224172107.GA2066@thacker.dyndns.org> Message-ID: <1109281070.3817.127.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 12:24 -0500, Elliot Lee a ?crit : > The web site is really out of date. The intent is to move it into > cvs.fedora.redhat.com Real Soon Now Real Soon Now(tm Red Hat) mean one week to two years. > so more people can make more updates > more easily. Please keep bugging us until this happens :) Done :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Thu Feb 24 21:39:39 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 24 Feb 2005 22:39:39 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> <1109268957.5420.122.camel@hades.cambridge.redhat.com> Message-ID: <1109281180.15454.23.camel@rousalka.dyndns.org> Le jeudi 24 f?vrier 2005 ? 15:24 -0600, Jason L Tibbitts III a ?crit : >>>>>> "DW" == David Woodhouse writes: > >DW> Either you want it capable of queueing, or you don't -- you can't >DW> have both ;) > >Well, uh, yeah. The point is that even Exim's restricted mode isn't a >good fit because it won't queue. But then I stated earlier that Exim >(along with Postfix) posses far more functionality than is necessary >(or safe) for the average machine. You do know that postfix design is a common example in advanced security CS courses right ? Moreover postfix default conf mostly works as-is so there is little risk of someone compromising the setup by adding scores of directives he does not understand because the damn thing doesn't work and he only got an outdated howto to work from. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Thu Feb 24 21:42:41 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 24 Feb 2005 22:42:41 +0100 Subject: Why is sendmail bad? In-Reply-To: <20050224213500.GJ28055@angus.ind.WPI.EDU> References: <20050224213500.GJ28055@angus.ind.WPI.EDU> Message-ID: <1109281362.15454.27.camel@rousalka.dyndns.org> Le jeudi 24 f?vrier 2005 ? 16:35 -0500, Chuck R. Anderson a ?crit : >On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote: >> There seems to be a lot of dissatisfaction with sendmail in the call to >> replace it with Exim or Postfix, but I didn't see any specifics about why >> people object to it. Anyone care to give details? > >In my environment, on 99% of all systems, I've never needed anything >but a simple queue-to-smarthost mail sending daemon, with no receive >functionality at all. Therefore, I don't care which mail daemon is >included, as long as it can do that and supports some type of >/etc/aliases file. I'd actually prefer to see a simple ssmtp-like >program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't >expand local aliases). > >On the 1 or 2 systems that do need a full mail server, our mail admins >roll their own builds/installs of sendmail anyway. Funny I just wrote the same thing (and I do think they are wrong btw, but then they did chose sendmail in the first place) -- 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 dwmw2 at infradead.org Thu Feb 24 21:42:41 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 21:42:41 +0000 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> Message-ID: <1109281361.26364.51.camel@localhost.localdomain> On Thu, 2005-02-24 at 16:32 -0500, Elliot Lee wrote: >Yea, that split was crack. Splitting the documentation packages out into a separate SRPM from the Exim binaries makes a lot of sense -- the docs are distributed separately, updated at different times, and built into a separate RPM package which should have been noarch. There is no overlap between them and the Exim d?mon itself. There was never any real reason for them to be inside the main exim SRPM in the first place. The point in fixing that now was to make it easier to drop the docs? if it was really necessary to make space, because upgrades won't suffer just due to the docs being older. >At this point the plan is to have exim entirely in Extras. I thought that _even_ while we thought there was a point to this exercise and we thought we could make FC4/i386 fit in 4 CDs, we had acknowledged that we couldn't drop packages which were in FC3 because that would make upgrades problematic? -- dwmw2 ? or move them to Extras -- the two are basically equivalent for FC4. From sopwith at redhat.com Thu Feb 24 21:48:27 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 16:48:27 -0500 (EST) Subject: reducing distribution CD count In-Reply-To: <1109281361.26364.51.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <1109281361.26364.51.camel@localhost.localdomain> Message-ID: On Thu, 24 Feb 2005, David Woodhouse wrote: > On Thu, 2005-02-24 at 16:32 -0500, Elliot Lee wrote: > >Yea, that split was crack. > > Splitting the documentation packages out into a separate SRPM from the > Exim binaries makes a lot of sense -- the docs are distributed > separately, updated at different times, and built into a separate RPM > package which should have been noarch. There is no overlap between them > and the Exim d?mon itself. There was never any real reason for them to > be inside the main exim SRPM in the first place. The point in fixing > that now was to make it easier to drop the docs? if it was really > necessary to make space, because upgrades won't suffer just due to the > docs being older. Yea, the split was not crack. ;-) -- Elliot From Nicolas.Mailhot at laPoste.net Thu Feb 24 21:52:56 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 24 Feb 2005 22:52:56 +0100 Subject: rawhide report: 20050222 changes In-Reply-To: <20050224121757.A29720@tiki-lounge.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <20050224121757.A29720@tiki-lounge.com> Message-ID: <1109281980.15454.36.camel@rousalka.dyndns.org> BTW on the whole slimming process : I do think more will be achieved by making network installations more convenient than putting a hard limit on the disk number. After all even if a floppy FC was possible today no one would go through the hassle of feeding hundreds of disks in the reader to make use of it. Just have the network install kick ass (a one-stage install from the first CD not like I heard minimal install then boot then yum then whatever) and no one will care the about number of isos anymore (because mags will only ship the first CD and people with no network connectivity will the the last to complain FC isos are numerous enough they won't miss anything once they burnt them). If you can do full livecds now it's certainly possible to pack a smart network installer on a single disk right ? 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 feliciano.matias at free.fr Thu Feb 24 21:56:59 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 22:56:59 +0100 Subject: reducing distribution CD count In-Reply-To: <1109281361.26364.51.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <1109281361.26364.51.camel@localhost.localdomain> Message-ID: <1109282219.3817.132.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 21:42 +0000, David Woodhouse a ?crit : > On Thu, 2005-02-24 at 16:32 -0500, Elliot Lee wrote: > >Yea, that split was crack. > > Splitting the documentation packages out into a separate SRPM from the > Exim binaries makes a lot of sense I was not talking about this split (sub-package or multi SRPM, ...) but about FC/FE split. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Thu Feb 24 22:22:36 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 17:22:36 -0500 Subject: Exim as default MTA. In-Reply-To: <1109280386.26364.40.camel@localhost.localdomain> References: <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <1109170025.3928.17.camel@nexus.verbum.private> <20050223150824.GA924815@hiwaay.net> <1109278446.11626.31.camel@stantz.corp.sgi.com> <20050224212521.GA19244@jadzia.bu.edu> <1109280386.26364.40.camel@localhost.localdomain> Message-ID: <20050224222236.GO11644@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote: > >Dropping it may be drastic; it could be moved to extras. > > Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't > going to fit onto 4 CDs FC4 i386 *is* going to fit on 4 CDs (almost certainly). It's x86_64 and possibly ppc that is over. Bill From notting at redhat.com Thu Feb 24 22:24:05 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 17:24:05 -0500 Subject: Other ways to cut FC4 down from 15 CDs to 14? In-Reply-To: <1109276570.26364.35.camel@localhost.localdomain> References: <1109250815.5420.53.camel@hades.cambridge.redhat.com> <20050224201853.GB31775@neu.nirvana> <1109276570.26364.35.camel@localhost.localdomain> Message-ID: <20050224222405.GP11644@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > The kernel manages to build both arch-specific and noarch rpms from the > same source. Why couldn't tetex? The kernel does it by going through the buildsystem twice with different --target= lines. Bill From notting at redhat.com Thu Feb 24 22:25:30 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 17:25:30 -0500 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> Message-ID: <20050224222530.GQ11644@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > sv> http://fedoraproject.org/wiki/Extras_2fOrphanedPackages > > Does the fact that a package has been dropped from Core imply that it > is orphaned? Um, 'maybe'. I think some of the input method stuff was going to be imported by the i18n group. I'd suggest asking the maintainer if they're intending on maintaining any package you're interested in picking up. Even if they do want to maintain it in Extras, I doubt they'd mind a helping hand. Bill From peter.backlund at home.se Thu Feb 24 22:41:20 2005 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 24 Feb 2005 23:41:20 +0100 Subject: rawhide report: 20050222 changes In-Reply-To: <1109281980.15454.36.camel@rousalka.dyndns.org> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <20050224121757.A29720@tiki-lounge.com> <1109281980.15454.36.camel@rousalka.dyndns.org> Message-ID: <1109284880.5110.10.camel@localhost.localdomain> tor 2005-02-24 klockan 22:52 +0100 skrev Nicolas Mailhot: >BTW on the whole slimming process : > >I do think more will be achieved by making network installations more >convenient than putting a hard limit on the disk number. After all even >if a floppy FC was possible today no one would go through the hassle of >feeding hundreds of disks in the reader to make use of it. > >Just have the network install kick ass (a one-stage install from the >first CD not like I heard minimal install then boot then yum then >whatever) and no one will care the about number of isos anymore (because >mags will only ship the first CD and people with no network connectivity >will the the last to complain FC isos are numerous enough they won't >miss anything once they burnt them). > >If you can do full livecds now it's certainly possible to pack a smart >network installer on a single disk right ? The biggest hassle when doing a network install is having to type in an ftp/http URL manually. Having a central mirror list accessible by XML-RPC or similar, with a failsafe list on the CD and the possibility to supply it manually would greatly simplify network installs. Ideally, one would select location/timezone first, then get a sane mirror suggestion based on geographical proximity. I guess probing the subnet for NFS/SMB servers (and ftp/http for that matter) would be nice too :-) /Peter Backlund From jos at xos.nl Thu Feb 24 22:38:54 2005 From: jos at xos.nl (Jos Vos) Date: Thu, 24 Feb 2005 23:38:54 +0100 Subject: XFCE packages gone? Message-ID: <200502242238.j1OMcsO02013@xos037.xos.nl> Hi, Why did the XFCE packages disappear from rawhide? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From skvidal at phy.duke.edu Thu Feb 24 22:44:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 17:44:09 -0500 Subject: reducing distribution CD count In-Reply-To: <421E47F1.1E43FD74@jwz.org> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> Message-ID: <1109285049.15658.38.camel@opus.phy.duke.edu> On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote: > Filiciano Matias wrote: > > > > 3- The average joe (me) expect to find the documentation in the same > > place than the program. A program with its documentation is the same > > whole thing. > > Perhaps I'm not an "average joe" in this matter, but I never look for > documentation on the local disk. I *always* use Google first. +1 people use local docs? -sv From tibbs at math.uh.edu Thu Feb 24 22:50:55 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 24 Feb 2005 16:50:55 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109281180.15454.23.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Thu, 24 Feb 2005 22:39:39 +0100") References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> <1109268957.5420.122.camel@hades.cambridge.redhat.com> <1109281180.15454.23.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> You do know that postfix design is a common example in advanced NM> security CS courses right ? What on Earth does that have to do with anything? I'm sure advanced race mechanics study Ferrari engines, but I don't need one to drive to the store. I guess what you're trying to say is that all of the extra stuff that Postfix comes with is secure, so it doesn't hurt anything to have it on the machine. That's something definitely contradicted by those advanced security CS courses you speak of. - J< From feliciano.matias at free.fr Thu Feb 24 22:57:03 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 24 Feb 2005 23:57:03 +0100 Subject: reducing distribution CD count In-Reply-To: <1109285049.15658.38.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> Message-ID: <1109285823.3817.137.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 17:44 -0500, seth vidal a ?crit : > On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote: > > Filiciano Matias wrote: > > > > > > 3- The average joe (me) expect to find the documentation in the same > > > place than the program. A program with its documentation is the same > > > whole thing. > > > > Perhaps I'm not an "average joe" in this matter, but I never look for > > documentation on the local disk. I *always* use Google first. > > +1 > > people use local docs? > Yes ! Many documentations are not online (think yum for example). -------------- 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 jwz at jwz.org Thu Feb 24 23:00:39 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Thu, 24 Feb 2005 15:00:39 -0800 Subject: reducing distribution CD count References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> Message-ID: <421E5C97.69BD2CD6@jwz.org> Filiciano Matias wrote: > > Many documentations are not online (think yum for example). Results 1 - 10 of about 167,000 for yum documentation -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From skvidal at phy.duke.edu Thu Feb 24 23:04:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 18:04:00 -0500 Subject: reducing distribution CD count In-Reply-To: <1109285823.3817.137.camel@one.myworld> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> Message-ID: <1109286240.15658.40.camel@opus.phy.duke.edu> > Yes ! > Many documentations are not online (think yum for example). There are local yum docs?! -sv From josh at bluga.net Thu Feb 24 23:04:29 2005 From: josh at bluga.net (Joshua Eichorn) Date: Thu, 24 Feb 2005 16:04:29 -0700 Subject: reducing distribution CD count In-Reply-To: <421E5C97.69BD2CD6@jwz.org> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> <421E5C97.69BD2CD6@jwz.org> Message-ID: <421E5D7D.7010602@bluga.net> Jamie Zawinski wrote: >Filiciano Matias wrote: > > >>Many documentations are not online (think yum for example). >> >> > >Results 1 - 10 of about 167,000 for yum documentation > > > There really is a big difference between man page style docs and python programming language manual anyway. -josh From feliciano.matias at free.fr Thu Feb 24 23:10:16 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 25 Feb 2005 00:10:16 +0100 Subject: reducing distribution CD count In-Reply-To: <421E5C97.69BD2CD6@jwz.org> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> <421E5C97.69BD2CD6@jwz.org> Message-ID: <1109286617.3817.140.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 15:00 -0800, Jamie Zawinski a ?crit : > Filiciano Matias wrote: > > > > Many documentations are not online (think yum for example). > > Results 1 - 10 of about 167,000 for yum documentation > I prefer this : $ rpm -q -l yum | egrep "(man)|(doc)" /usr/share/doc/yum-2.1.13 /usr/share/doc/yum-2.1.13/AUTHORS /usr/share/doc/yum-2.1.13/COPYING /usr/share/doc/yum-2.1.13/ChangeLog /usr/share/doc/yum-2.1.13/INSTALL /usr/share/doc/yum-2.1.13/README /usr/share/doc/yum-2.1.13/TODO /usr/share/man/man5/yum.conf.5.gz /usr/share/man/man8/yum-arch.8.gz /usr/share/man/man8/yum.8.gz It's quicker and more accurate. > -- > Jamie Zawinski jwz at jwz.org http://www.jwz.org/ > jwz at dnalounge.com http://www.dnalounge.com/ > http://jwz.livejournal.com/ > -------------- 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 feliciano.matias at free.fr Thu Feb 24 23:14:14 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 25 Feb 2005 00:14:14 +0100 Subject: reducing distribution CD count In-Reply-To: <1109286240.15658.40.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> <1109286240.15658.40.camel@opus.phy.duke.edu> Message-ID: <1109286854.3817.145.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 18:04 -0500, seth vidal a ?crit : > > Yes ! > > Many documentations are not online (think yum for example). > > There are local yum docs?! > Yes. Should I file bug report in bugzilla because yum seems too big ? > -sv -------------- 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 jwz at jwz.org Thu Feb 24 23:20:37 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Thu, 24 Feb 2005 15:20:37 -0800 Subject: reducing distribution CD count References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> <421E5C97.69BD2CD6@jwz.org> <1109286617.3817.140.camel@one.myworld> Message-ID: <421E6145.4324A6D0@jwz.org> Filiciano Matias wrote: > > I prefer this : > $ rpm -q -l yum | egrep "(man)|(doc)" > /usr/share/doc/yum-2.1.13 > /usr/share/doc/yum-2.1.13/AUTHORS > /usr/share/doc/yum-2.1.13/COPYING > /usr/share/doc/yum-2.1.13/ChangeLog > /usr/share/doc/yum-2.1.13/INSTALL > /usr/share/doc/yum-2.1.13/TODO I'd classify those files as "useless bloat." I could not possibly be interested in those files if I didn't have the source code installed. > /usr/share/doc/yum-2.1.13/README > /usr/share/man/man5/yum.conf.5.gz > /usr/share/man/man8/yum-arch.8.gz > /usr/share/man/man8/yum.8.gz *That* is documentation. > It's quicker and more accurate. See, in general, I find that not to be the case. I find popularly-linked documents on the web to *always* be clearer, more informative, and less full of lies than local man pages. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From dwmw2 at infradead.org Thu Feb 24 23:31:54 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Feb 2005 23:31:54 +0000 Subject: reducing distribution CD count In-Reply-To: <20050224222530.GQ11644@nostromo.devel.redhat.com> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> Message-ID: <1109287914.26364.69.camel@localhost.localdomain> On Thu, 2005-02-24 at 17:25 -0500, Bill Nottingham wrote: >> Does the fact that a package has been dropped from Core imply that it >> is orphaned? > >Um, 'maybe'. I think some of the input method stuff was going >to be imported by the i18n group. I'd suggest asking the maintainer >if they're intending on maintaining any package you're interested >in picking up. Even if they do want to maintain it in Extras, I >doubt they'd mind a helping hand. There's no point in maintaining dropped packages in Extras until Fedora can actually handle Extras properly. People who require the overzealously pruned packages can just skip FC4 and wait until FC5, at which point upgrades from FC3 should hopefully be working again. Unless the slip for GCC4 is going to give us enough time to do the multi-repo thing in anaconda? -- dwmw2 From sta282 at astradyne.co.uk Thu Feb 24 23:37:57 2005 From: sta282 at astradyne.co.uk (Tet) Date: Thu, 24 Feb 2005 23:37:57 +0000 Subject: reducing distribution CD count In-Reply-To: Your message of "Fri, 25 Feb 2005 00:10:16 +0100." <1109286617.3817.140.camel@one.myworld> Message-ID: <200502242337.j1ONbvNF003205@leto.astradyne.corp> =?ISO-8859-1?Q?F=E9liciano?= Matias writes: >I prefer this : >$ rpm -q -l yum | egrep "(man)|(doc)" You can achieve the same thing without the grep: rpm -qld yum Tet From jwboyer at jdub.homelinux.org Thu Feb 24 23:41:22 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 24 Feb 2005 17:41:22 -0600 Subject: Why is sendmail bad? In-Reply-To: <1109279833.7775.251.camel@serendipity.dogma.lan> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> Message-ID: <1109288482.17967.28.camel@jdub.homelinux.org> On Thu, 2005-02-24 at 22:17 +0100, Alexander Dalloz wrote: > Am Do, den 24.02.2005 schrieb Josh Boyer um 21:56: > > As said too, same with Sendmail: just restart the service so that it > rereads his configuration. Restarting the service runs m4 on sendmail.mc? If so, I didn't know that. > > > > Really? I disagree. I hardly know anything about mail servers, yet I exim > > allows me to run spam and virus checking by simply uncommenting one line. And > > unlike sendmail, I didn't have to explicitly enable outside connections. > > That is an argument to "improve" the default setup Sendmail is shipping > with Fedora Core. Yes, sure. > > > > Sure, but a user needs to know what a milter entry is right? And how to set it > > up to do what you need it to do, etc. I don't have a clue what a milter entry > > is. > > You don't know because you didn't read the documentation. It is ok as > you don't run Sendmail. I did run Sendmail. For almost a year. In fact, I first tried exim 2 days ago. Yes, I didn't read any documentation other than what's in sendmail.mc (at first). Yes, that makes me lazy. But I only read the exim.conf file too, and now I have spamassassin running at SMTP time. And yes, that also could be an argument for improving Sendmail's default configuration. > My argument was different: anyone running an MTA reachable from the > public internet should know well about his service. This is very obvious > for all who's daily business is mail administration. Eventually. I was in a situation where I switched ISPs and didn't have an email address anymore. I hate hotmail, and didn't have access to gmail yet. So, I got a mail server running as fast as I could. _Then_ I learned more about it. Had Sendmail come with some spam filtering stuff built in, I'd have used it from day one. As it stood, it didn't and I never found the time to figure out how to enable that. It took me about a day to get me and my one other mail user up and running on the simple setup that I have. Probably half of that was messing with the Sendmail configs. With exim, it took me 20 minutes and that included getting spam filtering running. And again, all I did was read the config files for each. > > > I'm not saying sendmail can't do equivalent (or even more) things. I don't > > claim to know a lot about MTAs, what makes them good, what doesn't, and why one > > is better than the other. I'm just saying that from a newbie perspective > > (mine), exim was easier for me to use. > > If you feel so, ok. From reading the Exim documentation I don't have the > impression that the Exim configuration is that intuitive. This is quickly turning into a flame. I'm partly to blame for it, but that's not what I intended. I don't think Sendmail is "bad". I just think other MTAs are easier to use out of the box. That's just my opinion. Me, and the mail server that shouldn't be running by all accounts I've read in this thread, are bowing out now. josh From thacker at math.cornell.edu Thu Feb 24 23:41:47 2005 From: thacker at math.cornell.edu (John Thacker) Date: Thu, 24 Feb 2005 18:41:47 -0500 Subject: reducing distribution CD count In-Reply-To: <1109287914.26364.69.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> Message-ID: <20050224234147.GA3633@thacker.dyndns.org> On Thu, Feb 24, 2005 at 11:31:54PM +0000, David Woodhouse wrote: > There's no point in maintaining dropped packages in Extras until Fedora > can actually handle Extras properly. > > People who require the overzealously pruned packages can just skip FC4 > and wait until FC5, at which point upgrades from FC3 should hopefully be > working again. Or at the very least there's actually a link from the FC webpage to Extras so that people can find it. (Continuing to bug and remind, per request.) John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Feb 24 23:48:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Feb 2005 18:48:40 -0500 Subject: reducing distribution CD count In-Reply-To: <1109287914.26364.69.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> Message-ID: <604aa79105022415481de1fee4@mail.gmail.com> On Thu, 24 Feb 2005 23:31:54 +0000, David Woodhouse wrote: > There's no point in maintaining dropped packages in Extras until Fedora > can actually handle Extras properly. That's a bit over the top.... there is most certaintly benefit it maintaining dropped packages in Extras. is it the ideal situation? no... but if Red Hat decides to drop anything for whatever reason... space constraints, labor constraints, phase of the moon, or pure malicious spite, whatever reason... there is certaintly benefit to the community at large in providing those packages in Extras if there is a community member willing to maintain the package. We can argue all day and all night about the reasons why packages are dropped from Core... as the multiple threads on the topic have proven....but if the alternative is to not have the package available at all or to have the package available in Extras... clearly.. there is benefit in maintaining it in Extras compared to letting go unpackaged. Holding our collective breath while we cross our arms and make 4 year old pouting faces in an effort to demand the decision be reversed only makes a bad situation worse. Packages are dropped pretty much every release.. even back in rhl. We can dislike the decision... but at the end of the day its better of having the packages available than not if there are people to maintain it in Extras and a demand for it. -jef"takes his ball and goes home... oh wait i am home"spaleta From perbj at stanford.edu Thu Feb 24 23:54:03 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 24 Feb 2005 15:54:03 -0800 Subject: reducing distribution CD count In-Reply-To: <1109287914.26364.69.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> Message-ID: <1109289244.5265.29.camel@localhost.localdomain> On Thu, 2005-02-24 at 23:31 +0000, David Woodhouse wrote: > There's no point in maintaining dropped packages in Extras until Fedora > can actually handle Extras properly. Isn't that a bit of an overstatement? Realistically, if you install FC4 later than on the day it is released you'll likely want to do a "yum update" pretty much immediately. If Extras is enabled by default in Yum (and any other package managers that are deemed to matter), this will also pull in the updates for anything that was moved into Extras. Sure, that's a two-stage upgrade (anaconda + yum), but with the amount of package updates that Fedora has been seeing, it basically is anyways. >From what I have understood it sure sounds like the Extras repo is supposed to be enabled by default? Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From pjones at redhat.com Fri Feb 25 00:10:04 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 24 Feb 2005 19:10:04 -0500 Subject: reducing distribution CD count In-Reply-To: <421E3834.6050707@insitesinc.com> References: <200502240906.20729.czar@czarc.net> <20050224200644.GF11644@nostromo.devel.redhat.com> <421E3834.6050707@insitesinc.com> Message-ID: <1109290204.6564.17.camel@localhost.localdomain> On Thu, 2005-02-24 at 14:25 -0600, Michael Favia wrote: > Is it a misstatement that packages in > extras are relinquished to community maintenance? I think so, yes. > or does redhat continue maintenance as well? Is there any reason either one couldn't be true? That is, some packages which RH isn't interested in maintaining, but also some that we recognize are worth effort but shouldn't be part of Core? -- Peter From mricon at gmail.com Fri Feb 25 00:53:21 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 24 Feb 2005 19:53:21 -0500 Subject: XFCE packages gone? In-Reply-To: <200502242238.j1OMcsO02013@xos037.xos.nl> References: <200502242238.j1OMcsO02013@xos037.xos.nl> Message-ID: On Thu, 24 Feb 2005 23:38:54 +0100, Jos Vos wrote: > Why did the XFCE packages disappear from rawhide? Read the last 512 messages sent to the list. Sheesh. :) Regards, -- Konstantin Ryabitsev Zlotniks, INC From pbrobinson at gmail.com Fri Feb 25 00:57:50 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 25 Feb 2005 08:57:50 +0800 Subject: rawhide report: 20050222 changes In-Reply-To: <1109281980.15454.36.camel@rousalka.dyndns.org> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <20050224121757.A29720@tiki-lounge.com> <1109281980.15454.36.camel@rousalka.dyndns.org> Message-ID: <5256d0b050224165738eb7a0a@mail.gmail.com> > I do think more will be achieved by making network installations more > convenient than putting a hard limit on the disk number. After all even > if a floppy FC was possible today no one would go through the hassle of > feeding hundreds of disks in the reader to make use of it. > > Just have the network install kick ass (a one-stage install from the > first CD not like I heard minimal install then boot then yum then > whatever) and no one will care the about number of isos anymore (because > mags will only ship the first CD and people with no network connectivity > will the the last to complain FC isos are numerous enough they won't > miss anything once they burnt them). Network install is fine for those that have big network pipes. Some of us live at the end of a crappy 28K dialup because we have 25Kms of copper from the exchange and the encumbant Aussie telco won't do anything about it :-) Pete From michael.favia at insitesinc.com Fri Feb 25 01:16:52 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 24 Feb 2005 19:16:52 -0600 Subject: reducing distribution CD count In-Reply-To: <1109290204.6564.17.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <20050224200644.GF11644@nostromo.devel.redhat.com> <421E3834.6050707@insitesinc.com> <1109290204.6564.17.camel@localhost.localdomain> Message-ID: <421E7C84.5060702@insitesinc.com> Peter Jones wrote: >Is there any reason either one couldn't be true? That is, some packages >which RH isn't interested in maintaining, but also some that we >recognize are worth effort but shouldn't be part of Core? > > I agree completely but i have formed the impression [perhaps mistakenly] that packages moved to extras are "orphaned" packages as far as RH is concerned. Or is that just the norm and not the "law"? I think you will allay a great many fears and improve the perception of extras if this is the case and it is communicated to the user/dev base a little better. In case i am completely mistaken is there a reference document that spells out the distinctions and flow of this type of information? I would much rather read up on it than learn bit by bit pestering people over mailing lists. -mf From michael.favia at insitesinc.com Fri Feb 25 01:20:32 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 24 Feb 2005 19:20:32 -0600 Subject: rawhide report: 20050222 changes In-Reply-To: <5256d0b050224165738eb7a0a@mail.gmail.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <20050224121757.A29720@tiki-lounge.com> <1109281980.15454.36.camel@rousalka.dyndns.org> <5256d0b050224165738eb7a0a@mail.gmail.com> Message-ID: <421E7D60.3020806@insitesinc.com> Peter Robinson wrote: > Network install is fine for those that have big network pipes. Some of > >us live at the end of a crappy 28K dialup because we have 25Kms of >copper from the exchange and the encumbant Aussie telco won't do >anything about it :-) > > And a viable CD based alternative should be provided. Including the ability to make "extras" cd's on the fly perhaps. but i dont think that the fedora project should organize itself around your problems because you represent the past. I think it is important to embrace the future (network installs from truncated media) and still provide for those who [for whatever reason] are stuck in the past (28.8). On the fly CD's/DVD's are a great gapping tool for this IMO. -mf From hp at redhat.com Fri Feb 25 01:38:41 2005 From: hp at redhat.com (Havoc Pennington) Date: Thu, 24 Feb 2005 20:38:41 -0500 Subject: reducing distribution CD count In-Reply-To: <421E7C84.5060702@insitesinc.com> References: <200502240906.20729.czar@czarc.net> <20050224200644.GF11644@nostromo.devel.redhat.com> <421E3834.6050707@insitesinc.com> <1109290204.6564.17.camel@localhost.localdomain> <421E7C84.5060702@insitesinc.com> Message-ID: <1109295521.19762.10.camel@localhost.localdomain> On Thu, 2005-02-24 at 19:16 -0600, Michael Favia wrote: > Peter Jones wrote: > > >Is there any reason either one couldn't be true? That is, some packages > >which RH isn't interested in maintaining, but also some that we > >recognize are worth effort but shouldn't be part of Core? > > > > > I agree completely but i have formed the impression [perhaps mistakenly] > that packages moved to extras are "orphaned" packages as far as RH is > concerned. Or is that just the norm and not the "law"? I think you will > allay a great many fears and improve the perception of extras if this is > the case and it is communicated to the user/dev base a little better. In > case i am completely mistaken is there a reference document that spells > out the distinctions and flow of this type of information? I would much > rather read up on it than learn bit by bit pestering people over mailing > lists. I think it's accurate that Red Hat would like to be maintaining fewer packages and focusing more on the basics, but at the same time I don't know why people are so terrified of that. It will probably make both the basics and the non-basics higher quality to do this since there's more focus on each one. At the same time I doubt the core/extras line will end up being Red Hat maintenance vs. external maintenance. I think we're heading toward some other definition of core vs. extras. My personal preference leans toward saying core is roughly the union of default install classes, but I'm sure others have thought about it more. Havoc From cmadams at hiwaay.net Fri Feb 25 01:56:54 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 24 Feb 2005 19:56:54 -0600 Subject: rawhide report: 20050222 changes In-Reply-To: <421E7D60.3020806@insitesinc.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <20050224121757.A29720@tiki-lounge.com> <1109281980.15454.36.camel@rousalka.dyndns.org> <5256d0b050224165738eb7a0a@mail.gmail.com> <421E7D60.3020806@insitesinc.com> Message-ID: <20050225015654.GA966383@hiwaay.net> Once upon a time, Michael Favia said: > And a viable CD based alternative should be provided. Including the > ability to make "extras" cd's on the fly perhaps. but i dont think that > the fedora project should organize itself around your problems because > you represent the past. I hardly think that not having "fast" network access everywhere you want to install is "the past". Network speed is relative; I have multiple T3s at the office so I can download ISOs fast and burn them and carry them home. I have 1.5M DSL at home, but it would still take way too long to install over that link. For Fedora 3, Core + Extras = 3.5G. If I even installed 50% of that, it would take 2.6 hours to install (if the install downloaded at 100% speed continuously, which it won't). Also, I don't always install where I have network access. A significant part of the world does not have access to high speed Internet access (and probably will not for the foreseeable future). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From thomasz at hostmaster.org Fri Feb 25 02:15:06 2005 From: thomasz at hostmaster.org (Thomas Zehetbauer) Date: Fri, 25 Feb 2005 03:15:06 +0100 Subject: fedora-extras/xplanet orphaned? Message-ID: <1109297706.4387.65.camel@hostmaster.org> Hi, it seems that the xplanet package from Fedora Extras is very much orphaned. According to the change log it was last modified 2003-05-12 and xplanet-1.1.2 that fixes some problems and introduces many new features is available since 2004-12-05. Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger thomasz at hostmaster.org for key I hate beeing a DNA molecule - there's so much to remember! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part URL: From herrold at owlriver.com Fri Feb 25 02:52:03 2005 From: herrold at owlriver.com (R P Herrold) Date: Thu, 24 Feb 2005 21:52:03 -0500 (EST) Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: References: <200502242238.j1OMcsO02013@xos037.xos.nl> Message-ID: On Thu, 24 Feb 2005, Konstantin Ryabitsev wrote: > On Thu, 24 Feb 2005 23:38:54 +0100, Jos Vos wrote: >> Why did the XFCE packages disappear from rawhide? > > Read the last 512 messages sent to the list. Sheesh. :) One has to suppose you mean the thread: Subject: Re: Summary of Dropped Packages and as I took this, it was a removal from Fedora Core packages to an Extras status -- and NOT a removal from RawHide. The xfce packages are actively maintained, they are straightforward to mesh with a switchdesk environment, and frankly they are the opposite of the bloat which more flashy WM's induce, in many ways. So, why DID the xfce suite disappear from RawHide; does a banishment to Extras entail this step as well? -- Russ Herrold From feliciano.matias at free.fr Fri Feb 25 03:05:19 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 25 Feb 2005 04:05:19 +0100 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: References: <200502242238.j1OMcsO02013@xos037.xos.nl> Message-ID: <1109300719.10447.4.camel@one.myworld> Le jeudi 24 f?vrier 2005 ? 21:52 -0500, R P Herrold a ?crit : > On Thu, 24 Feb 2005, Konstantin Ryabitsev wrote: > > > On Thu, 24 Feb 2005 23:38:54 +0100, Jos Vos wrote: > >> Why did the XFCE packages disappear from rawhide? > > > > Read the last 512 messages sent to the list. Sheesh. :) > > One has to suppose you mean the thread: > Subject: Re: Summary of Dropped Packages > > and as I took this, it was a removal from Fedora Core packages > to an Extras status -- and NOT a removal from RawHide. Rawhide *is* FC (development branch). And FC is *not* all Fedora. Now Fedora is Fedora Core *and* Fedora extra. I don't take a close look but it seems Fedora Extra also have its development branch : http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ Ooops, it's empty :-) Take a look here : http://www.fedoraproject.org/wiki/Extras I don't know if xfce will be FE. -------------- 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 byte at aeon.com.my Fri Feb 25 03:19:56 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 25 Feb 2005 11:19:56 +0800 Subject: fedora-extras/xplanet orphaned? In-Reply-To: <1109297706.4387.65.camel@hostmaster.org> References: <1109297706.4387.65.camel@hostmaster.org> Message-ID: <1109301596.5676.41.camel@localhost.localdomain> On Fri, 2005-02-25 at 03:15 +0100, Thomas Zehetbauer wrote: > it seems that the xplanet package from Fedora Extras is very much > orphaned. According to the change log it was last modified 2003-05-12 > and xplanet-1.1.2 that fixes some problems and introduces many new > features is available since 2004-12-05. fedora-extras-list at redhat.com is the right place for this Reply-to set appropriately.... -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From bojan at rexursive.com Fri Feb 25 03:29:37 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 25 Feb 2005 14:29:37 +1100 Subject: GFS inside Xen In-Reply-To: <1108350721.42101701ea3d2@imp.rexursive.com> References: <1108350721.42101701ea3d2@imp.rexursive.com> Message-ID: <1109302177.421e9ba174322@imp.rexursive.com> Quoting Bojan Smojver : > This may sound like a very strange thing to do, but it may be useful in > situations where you have only one physical machine and want to play with GFS > based clusters. So the real question is, did anyone try this (with current > development branch) and if yes, was there some kind of "magic" setup involved > or did it just work? OK, kernel 2.6.10-1.1149_FC4xenU, got GFS to compile with a minor patch: ----------------------------------------- diff -ruN gfs-kernel-2.6.9-5-vanilla/src/gfs/quota.c gfs-kernel-2.6.9-5/src/gfs/ quota.c --- gfs-kernel-2.6.9-5-vanilla/src/gfs/quota.c 2004-12-20 10:14:33.000000000 -0 500 +++ gfs-kernel-2.6.9-5/src/gfs/quota.c 2005-02-24 20:28:07.000000000 -0500 @@ -954,7 +954,7 @@ if (current->signal) { tty = current->signal->tty; if (tty && tty->driver->write) - tty->driver->write(tty, 0, line, len); + tty->driver->write(tty, line, len); } kfree(line); ----------------------------------------- GFS loads and I can make the file system, no worries. However, mounting still doesn't work, unless lock_nolock is used (which is kinda pointless for what I'm trying to do): ----------------------------------------- mount -v -t gfs /dev/sda2 /gfs GFS: Trying to join cluster "lock_gulm", "cluster:gfs" lock_gulm: Unknown symbol in6addr_loopback lock_harness: can't find protocol lock_gulm GFS: can't mount proto = lock_gulm, table = cluster:gfs, hostdata = mount: No such file or directory ----------------------------------------- I'm guessing recompile of the xenU kernel is in order to get the correct symbols exported out of ipv6? -- Bojan From aoliva at redhat.com Fri Feb 25 03:32:54 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Feb 2005 00:32:54 -0300 Subject: Why is sendmail bad? In-Reply-To: <20050224204245.GA17728@yoda.jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <200502241504.44676.rjune@bravegnuworld.com> <20050224204245.GA17728@yoda.jdub.homelinux.org> Message-ID: On Feb 24, 2005, Josh Boyer wrote: > I guess we'll have to agree to disagree. Anything that requires > using m4 after editing a config file isn't intuitive IMHO. FWIW, it doesn't require you to actually run m4. There's a Makefile to do that for you. I take it that you dislike autoconf scripts for similar reasons? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From michael.favia at insitesinc.com Fri Feb 25 03:47:14 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 24 Feb 2005 21:47:14 -0600 Subject: reducing distribution CD count In-Reply-To: <1109295521.19762.10.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <20050224200644.GF11644@nostromo.devel.redhat.com> <421E3834.6050707@insitesinc.com> <1109290204.6564.17.camel@localhost.localdomain> <421E7C84.5060702@insitesinc.com> <1109295521.19762.10.camel@localhost.localdomain> Message-ID: <421E9FC2.8010302@insitesinc.com> Havoc Pennington wrote: >I think it's accurate that Red Hat would like to be maintaining fewer >packages and focusing more on the basics, but at the same time I don't >know why people are so terrified of that. It will probably make both the >basics and the non-basics higher quality to do this since there's more >focus on each one. > >At the same time I doubt the core/extras line will end up being Red Hat >maintenance vs. external maintenance. I think we're heading toward some >other definition of core vs. extras. My personal preference leans toward >saying core is roughly the union of default install classes, but I'm >sure others have thought about it more. > > I am of the same persuasion. And i agree completely on the simplification of the distro and the focus on fewer "default" packages because it means the half-life of innovation will decrease dramatically with respect to the "normal users experience". I harbor no fears of abondonment and i think others could be placated as well but believe many are complaining because of the dirth of information available on future plans (possibly because they arent known). As we all know uncertainty shakes even steely-eyed missle men hesitent. Many of the political battles (kde/gnome, exim/sendmail, etc) shoudl be put to rest (finally) when this time comes. I think that "core" as a non duplicating set of functionalites is a great idea that decreases the installation media requirement, bandwidth and overall workload per innovative step. The rest can and should be maintained by the community with RH picking up the ball where it is in its best interest (e.g. angel coding, switching or providing compatability). The key to making this work without alienating a contigent userbase will be the simplicity of selecting and installing non-default (core) packages on installation and after the fact (via network and "extras" cd's). Will the slip of test1 have any effect on the possible availability of a multirepo anaconda up to such a task (fully realizing that there are other hurdles like "extras" installation cd creation)? Assuming the same amount of resources are comitted to the project a slimmer, more agile, faster moving fedora core will be the result of moving in this direction and i for one welcome it. Thanks for the feedback on the earlier post. -michael From rodd at clarkson.id.au Fri Feb 25 04:21:36 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 25 Feb 2005 15:21:36 +1100 Subject: Strange 100% CPU state after 2005022[3|4] updates Message-ID: <1109305296.4123.17.camel@clownfish.redfishdemo.com> Every now and again my CPU goes into a 100% usage state after recent rawhide updates (last two days). IN one case I couldn't figure out what was causing it and had to shutdown anyway, so just turned the system off. In another, I tried killing gnome-vfs-daemon, gnome-settings-daemon, nautilus, gamin and finally stopped it killing gnome-panel. in both cases I don't know what triggered it, but the usage was roughly 30-40% user, 60-70% system. Just now I've discovered I can trigger a similar state as follows: 1. Open Applications > Accessories > Dictionary 2. Type Role into the Word field and hit enter 3. Click on the hyperlink Roll (this should bring up the meaning of Roll) Doing this sends my CPU 100% (about 30% user and 70% system) Closing the Dictionary fixes this immediately. Is anyone else seeing this (I'll file a bug report if so, or if someone tells me) and has anyone got any ideas why? Rodd From bojan at rexursive.com Fri Feb 25 04:59:48 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 25 Feb 2005 15:59:48 +1100 Subject: GFS inside Xen In-Reply-To: <1109302177.421e9ba174322@imp.rexursive.com> References: <1108350721.42101701ea3d2@imp.rexursive.com> <1109302177.421e9ba174322@imp.rexursive.com> Message-ID: <1109307588.421eb0c4e0733@imp.rexursive.com> Quoting Bojan Smojver : > I'm guessing recompile of the xenU kernel is in order to get the correct > symbols exported out of ipv6? I think I wasn't clear here... Sorry :-( One can find this line in modules.symbols of kernel-2.6.10-1.766_FC3: alias symbol:in6addr_loopback ipv6 No such thing in modules.symbols of any of the FC4 devel kernels... Not sure why. -- Bojan From stan at ccs.neu.edu Fri Feb 25 05:28:12 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Fri, 25 Feb 2005 00:28:12 -0500 Subject: Why is sendmail bad? In-Reply-To: References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <200502241504.44676.rjune@bravegnuworld.com> <20050224204245.GA17728@yoda.jdub.homelinux.org> Message-ID: <421EB76C.5070808@ccs.neu.edu> Alexandre Oliva wrote: > On Feb 24, 2005, Josh Boyer wrote: > > >>I guess we'll have to agree to disagree. Anything that requires >>using m4 after editing a config file isn't intuitive IMHO. > > > FWIW, it doesn't require you to actually run m4. There's a Makefile > to do that for you. > > I take it that you dislike autoconf scripts for similar reasons? > autoconf scripts only need to be run when a program is compiled, m4 either directly or indirectly needs to be run whenever you change the config file for sendmail, there is a difference :) -sb From Nicolas.Mailhot at laPoste.net Fri Feb 25 07:09:12 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 25 Feb 2005 08:09:12 +0100 Subject: rawhide report: 20050222 changes In-Reply-To: <5256d0b050224165738eb7a0a@mail.gmail.com> References: <200502221907.j1MJ7QRi019833@porkchop.devel.redhat.com> <20050224121757.A29720@tiki-lounge.com> <1109281980.15454.36.camel@rousalka.dyndns.org> <5256d0b050224165738eb7a0a@mail.gmail.com> Message-ID: <1109315352.5140.3.camel@rousalka.dyndns.org> Le vendredi 25 f?vrier 2005 ? 08:57 +0800, Peter Robinson a ?crit : >> I do think more will be achieved by making network installations more >> convenient than putting a hard limit on the disk number. After all even >> if a floppy FC was possible today no one would go through the hassle of >> feeding hundreds of disks in the reader to make use of it. >> >> Just have the network install kick ass (a one-stage install from the >> first CD not like I heard minimal install then boot then yum then >> whatever) and no one will care the about number of isos anymore (because >> mags will only ship the first CD and people with no network connectivity >> will the the last to complain FC isos are numerous enough they won't >> miss anything once they burnt them). > >Network install is fine for those that have big network pipes. Some of >us live at the end of a crappy 28K dialup because we have 25Kms of >copper from the exchange and the encumbant Aussie telco won't do >anything about it :-) Well, in your case wouldn't you prefer having more CDs not less ? This way once you have them you won't have to do lots of networking just to complete a barebones initial installation. I do think the "we need to shrunk the distro so it fits in a small cd set" is a false problem. Network installs don't care, people without good networking would rather have a complete CD set. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Fri Feb 25 07:16:55 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 25 Feb 2005 08:16:55 +0100 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> <1109268957.5420.122.camel@hades.cambridge.redhat.com> <1109281180.15454.23.camel@rousalka.dyndns.org> Message-ID: <1109315815.5140.9.camel@rousalka.dyndns.org> Le jeudi 24 f?vrier 2005 ? 16:50 -0600, Jason L Tibbitts III a ?crit : >>>>>> "NM" == Nicolas Mailhot writes: > >NM> You do know that postfix design is a common example in advanced >NM> security CS courses right ? > >What on Earth does that have to do with anything? I'm sure advanced >race mechanics study Ferrari engines, but I don't need one to drive to >the store. > >I guess what you're trying to say is that all of the extra stuff that >Postfix comes with is secure, so it doesn't hurt anything to have it >on the machine. That's something definitely contradicted by those >advanced security CS courses you speak of. I'd rather have a full-featured secure program than a small one full of holes because it's never been widely deployed by people who care. If you take a look a security advisories they are not limited to big software, far from it. Postfix is secure because 1. it's well coded and 2. its multiple-processes design make it very difficult for an error to propagate enough to be exploited 3. it's deployed widely enough on big setups any exploit would come to light quickly. This wouldn't be the case of a small desktop-only util. Who's auditing linux desktop systems nowadays ? Small is beautiful. But that's not the only security factor you know. 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 tibbs at math.uh.edu Fri Feb 25 07:50:32 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 25 Feb 2005 01:50:32 -0600 Subject: FC4 slimfast slimfest In-Reply-To: <1109315815.5140.9.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 25 Feb 2005 08:16:55 +0100") References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> <1109268957.5420.122.camel@hades.cambridge.redhat.com> <1109281180.15454.23.camel@rousalka.dyndns.org> <1109315815.5140.9.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> I'd rather have a full-featured secure program than a small one NM> full of holes because it's never been widely deployed by people NM> who care. Who was advocating deploying something full of holes? Certainly not me, as I haven't even suggested a program to use. In fact I'm not sure if any program meeting the criteria exists; I was hoping that someone would provide suggestions, but it seems that people would rather argue. Debian shipped ssmtp for this purpose, but it and its replacement seem to have been abandoned (and it didn't queue, which the author admits as a problem). I suspect OpenBSD has something, because they seem to have the same ideas as I do about needless functionality in general. (Hence openntpd instead of xntpd.) - J< From malists at epon.ro Fri Feb 25 08:04:18 2005 From: malists at epon.ro (Marius Andreiana) Date: Fri, 25 Feb 2005 10:04:18 +0200 Subject: reducing distribution CD count In-Reply-To: <421E6145.4324A6D0@jwz.org> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> <421E5C97.69BD2CD6@jwz.org> <1109286617.3817.140.camel@one.myworld> <421E6145.4324A6D0@jwz.org> Message-ID: <1109318658.3578.1.camel@marte.biciclete.ro> On Thu, 2005-02-24 at 15:20 -0800, Jamie Zawinski wrote: > Filiciano Matias wrote: > > > > I prefer this : > > $ rpm -q -l yum | egrep "(man)|(doc)" > > /usr/share/doc/yum-2.1.13 > > /usr/share/doc/yum-2.1.13/AUTHORS > > /usr/share/doc/yum-2.1.13/COPYING > > /usr/share/doc/yum-2.1.13/ChangeLog > > /usr/share/doc/yum-2.1.13/INSTALL > > /usr/share/doc/yum-2.1.13/TODO > > I'd classify those files as "useless bloat." I could not possibly be > interested in those files if I didn't have the source code installed. I could. It describes the software package, I can see what new features are planned, how it changed in the last year (is it under active development?) -- Marius Andreiana Epon Business Applications http://www.epon.ro From peter.backlund at home.se Fri Feb 25 08:25:50 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 25 Feb 2005 09:25:50 +0100 Subject: ITE 8212 and pwc drivers absent in Rawhide Message-ID: <1109319950.5110.22.camel@localhost.localdomain> Hello. I'd like to see the ITE 8212 IDE/RAID pci card driver ( CONFIG_BLK_DEV_IT8212) and the pwc webcam driver back in the kernel. Is there any reason why they were removed? /Peter From davej at redhat.com Fri Feb 25 08:22:08 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 25 Feb 2005 03:22:08 -0500 Subject: ITE 8212 and pwc drivers absent in Rawhide In-Reply-To: <1109319950.5110.22.camel@localhost.localdomain> References: <1109319950.5110.22.camel@localhost.localdomain> Message-ID: <20050225082208.GA14931@redhat.com> On Fri, Feb 25, 2005 at 09:25:50AM +0100, Peter Backlund wrote: > Hello. > > I'd like to see the ITE 8212 IDE/RAID pci card driver > ( CONFIG_BLK_DEV_IT8212) and the pwc webcam driver back in the kernel. > Is there any reason why they were removed? Right now, they're only in Alan Cox's -ac tree, for which there is no patch that applies to the 2.6.11rc tree that FC3 is tracking. Dave From mpeters at mac.com Fri Feb 25 08:29:57 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 25 Feb 2005 08:29:57 +0000 Subject: Exim as default MTA. In-Reply-To: <1109186110.3076.49.camel@rousalka.dyndns.org> (from Nicolas.Mailhot@laPoste.net on Wed Feb 23 11:15:07 2005) References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <421BAB3A.1080406@carwyn.com> <1109110217.30247.19.camel@localhost.localdomain> <421BB34F.6050102@carwyn.com> <1109113537.30247.31.camel@localhost.localdomain> <1109121487.17468.13.camel@jdub.homelinux.org> <1109156055.30247.79.camel@localhost.localdomain> <1109186110.3076.49.camel@rousalka.dyndns.org> Message-ID: <1109320197l.7697l.2l@devel.mpeters.us> On 02/23/2005 11:15:07 AM, Nicolas Mailhot wrote: > I think the only reason the > postfix crowd is silent right now people can't even imagine RH > relenting > on sendmail, while exim users still have some hope left. I'm a postfix fan because it was easy (as in cake) to set it up to run in a chroot jail back when I first started using it, which was when sendmail exploit after exploit ad infinitum were being found (a couple years ago) - I was running an LFS system at the time, and that was a PITA. postfix didn't have those vulnerabilities, and I could chroot it as an extra measure. Now I just use the default Fedora rpm and don't run it in a chroot, but OTOH I'm also now only using it for mail on a lan and not to talk to (or receive from) outside world, so chroot isn't as critical to set up. I'm not speaking up here though because I know nothing about exim. -- Michael A. Peters http://mpeters.us/ From kms at passback.co.uk Fri Feb 25 09:15:19 2005 From: kms at passback.co.uk (Keith Sharp) Date: Fri, 25 Feb 2005 09:15:19 +0000 Subject: reducing distribution CD count In-Reply-To: <1109285049.15658.38.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> Message-ID: <1109322919.22897.11.camel@animal.passback.co.uk> On Thu, 2005-02-24 at 17:44 -0500, seth vidal wrote: > On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote: > > Filiciano Matias wrote: > > > > > > 3- The average joe (me) expect to find the documentation in the same > > > place than the program. A program with its documentation is the same > > > whole thing. > > > > Perhaps I'm not an "average joe" in this matter, but I never look for > > documentation on the local disk. I *always* use Google first. > > +1 > > people use local docs? Yes, frequently. Mostly on my laptop when I cannot get an Internet connection. But I am happy to explicitly install the docs I need for a separate source to keep the CD count down. Keith. From arnaud.abelard at univ-nantes.fr Fri Feb 25 09:29:34 2005 From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=) Date: Fri, 25 Feb 2005 10:29:34 +0100 Subject: debug about NetworkManager & resolv.conf being erased Message-ID: <421EEFFE.30003@univ-nantes.fr> Dan, you've been asking for debug infos about NetworkManager & the resolv.conf problem, so here it comes: I've been trying to use NetworkManager to manage my ethernet and wireless devices on FC3. As it was previously said on the list, NetworkManager sometimes erase the current resolv.conf file with en empty one. I did some tests: NetworkManager will only do the dhcp request when detecting a new network connection. Which means that if you run NetworkManager when the network cable is already plugged on the NIC, NetworkManager will not do the dhcp request and will erase the resolv.conf file with an empty one. I ran NetworkManager after booting. the network cable is already plugged on the NIC: [root at gallilee ~]# NetworkManager --no-daemon NetworkManager: starting... NetworkManager: eth0: Driver support level is fully-supported NetworkManager: nm_create_device_and_add_to_list(): adding device 'eth0' (wired) NetworkManager: eth1: Driver support level is fully-supported NetworkManager: nm_create_device_and_add_to_list(): adding device 'eth1' (wireless) NetworkManager: running mainloop... NetworkManager: nm_dbus_get_networks(): org.freedesktop.NetworkManagerInfo.NoNetworks raised There were are no wireless networks stored. NetworkManager: AUTO: Best wired device = eth0, best wireless device = eth1 () NetworkManager: SWITCH: best device changed NetworkManager: nm_state_modification_monitor(): beginning activation for device 'eth0' NetworkManager: nm_state_modification_monitor() activated device eth0 Result: resolv.conf has been erased. Now, i stop NetworkManager and unplug the network cable then run NetworkManager once more before replugging the cable: [root at gallilee ~]# NetworkManager --no-daemon NetworkManager: starting... NetworkManager: eth0: Driver support level is fully-supported NetworkManager: nm_create_device_and_add_to_list(): adding device 'eth0' (wired) NetworkManager: eth1: Driver support level is fully-supported NetworkManager: nm_create_device_and_add_to_list(): adding device 'eth1' (wireless) NetworkManager: running mainloop... NetworkManager: nm_dbus_get_networks(): org.freedesktop.NetworkManagerInfo.NoNetworks raised There were are no wireless networks stored. NetworkManager: AUTO: Best wired device = (null), best wireless device = eth1 () NetworkManager: SWITCH: best device changed NetworkManager: nm_state_modification_monitor(): beginning activation for device 'eth1' NetworkManager: nm_device_activation_worker (eth1) started... NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: nm_device_activate_wireless(eth1): waiting for an access point. NetworkManager: HAL signaled link state change for device eth0. NetworkManager: AUTO: Best wired device = eth0, best wireless device = eth1 () NetworkManager: SWITCH: best device changed NetworkManager: nm_device_activation_cancel(eth1): cancelling... NetworkManager: nm_device_activation_worker(eth1): activation canceled. NetworkManager: Activation (eth1) IP configuration/DHCP returned = 0 NetworkManager: Activation (eth1) IP configuration/DHCP unsuccessful! Ending activation... NetworkManager: Activation (eth1) ending thread. NetworkManager: nm_device_activation_cancel(eth1): cancelled. NetworkManager: nm_state_modification_monitor(): beginning activation for device 'eth0' NetworkManager: nm_device_activation_worker (eth0) started... NetworkManager: dhcp_interface_init: MAC address = 00:0f:1f:fe:9d:2f NetworkManager: ClassID = "Linux 2.6.10-1.766_FC3 i686" ClientID = "1.0.15.1F.FE.9D.2F.00.00" NetworkManager: Broadcasting DHCP_DISCOVER NetworkManager: DHCP: Starting request loop NetworkManager: DHCP: Sending request packet... NetworkManager: DHCP: Sent request packet. NetworkManager: DHCP: Waiting for reply... NetworkManager: DHCP waiting for data, overall end_time = {1109323109s, 138338us} NetworkManager: DHCP waiting for data of minimum size 28, remaining timeout = {5s, 96347us} NetworkManager: DHCP: Got some data to check for reply packet. NetworkManager: DHCP: actual data length was 339 NetworkManager: debug_dump_dhcp_options: 7 options received: NetworkManager: i=1 (subnetMask) len=4 option = 255.255.255.0 NetworkManager: i=3 (routersOnSubnet) len=4 option = xxxxxxxx NetworkManager: i=6 (dns) len=8 option = xxxxxxxx NetworkManager: i=6 (dns) len=8 option = xxxxxx NetworkManager: i=15 (domainName) len=31 option = "xxxxxxxxxxxxxx" NetworkManager: i=51 (dhcpMessageType) len=4 option = 43200 NetworkManager: i=53 (dhcpParamRequest) len=1 option = 2 NetworkManager: i=54 (dhcpMsg) len=4 option = xxxxxx NetworkManager: dhcp_msg->yiaddr = xxxxxx NetworkManager: dhcp_msg->siaddr = xxxxxxx NetworkManager: dhcp_msg->giaddr = 0.0.0.0 NetworkManager: dhcp_msg->sname = "" NetworkManager: Server Hardware Address = 00.10.5A.DE.FF.B1 NetworkManager: broadcastAddr option is missing in DHCP server response. Assuming xxxxxx.255 NetworkManager: dhcpIPaddrLeaseTime = 43200 in DHCP server response. NetworkManager: dhcpT1value is missing in DHCP server response. Assuming 21600 sec NetworkManager: dhcpT2value is missing in DHCP server response. Assuming 37800 sec NetworkManager: DHCP_OFFER received from (xxxxxxxx) NetworkManager: Broadcasting DHCP_REQUEST for xxxxxxxx NetworkManager: DHCP: Starting request loop NetworkManager: DHCP: Sending request packet... NetworkManager: DHCP: Sent request packet. NetworkManager: DHCP: Waiting for reply... NetworkManager: DHCP waiting for data, overall end_time = {1109323110s, -600706us} NetworkManager: DHCP waiting for data of minimum size 28, remaining timeout = {5s, 132041us} NetworkManager: DHCP: Got some data to check for reply packet. NetworkManager: DHCP: actual data length was 339 NetworkManager: debug_dump_dhcp_options: 10 options received: NetworkManager: i=1 (subnetMask) len=4 option = xxxxxx.0 NetworkManager: i=3 (routersOnSubnet) len=4 option = xxxxxxxx NetworkManager: i=6 (dns) len=8 option = xxxxxxxx NetworkManager: i=6 (dns) len=8 option = xxxxxxx NetworkManager: i=15 (domainName) len=31 option = "xxxxxxxx" NetworkManager: i=28 (broadcastAddr) len=4 option = xxxxxx.255 NetworkManager: i=51 (dhcpMessageType) len=4 option = 43200 NetworkManager: i=53 (dhcpParamRequest) len=1 option = 5 NetworkManager: i=54 (dhcpMsg) len=4 option = xxxxxxxxx NetworkManager: i=58 (dhcpClassIdentifier) len=4 option = 0 NetworkManager: i=59 (dhcpClientIdentifier) len=4 option = 0 NetworkManager: dhcp_msg->yiaddr = xxxxxxxx NetworkManager: dhcp_msg->siaddr = xxxxxxxx NetworkManager: dhcp_msg->giaddr = 0.0.0.0 NetworkManager: dhcp_msg->sname = "" NetworkManager: Server Hardware Address = 00.10.5A.DE.FF.B1 NetworkManager: dhcpIPaddrLeaseTime = 43200 in DHCP server response. NetworkManager: dhcpT1value is missing in DHCP server response. Assuming 21600 sec NetworkManager: dhcpT2value is missing in DHCP server response. Assuming 37800 sec NetworkManager: DHCP_ACK received from (xxxxxxxx) NetworkManager: Your IP address = xxxxxxxx NetworkManager: : Adding nameserver: xxxxxxx NetworkManager: : Adding nameserver: xxxxxxx NetworkManager: : Adding domain search: xxxxxxx NetworkManager: Activation (eth0) IP configuration/DHCP returned = 1 NetworkManager: Activation (eth0) IP configuration/DHCP successful! NetworkManager: nm_state_modification_monitor() activated device eth0 NetworkManager: nm_device_activation_worker(eth0): device activated Result: the resolv.conf file is properly filled. -- Arnaud Ab?lard Administrateur Syst?mes et R?seaux Facult? de Sciences et Techniques Universit? de Nantes From marcel at mesa.nl Fri Feb 25 09:39:41 2005 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Fri, 25 Feb 2005 10:39:41 +0100 Subject: Update website to mention CVS, Extras? In-Reply-To: <1109281070.3817.127.camel@one.myworld> References: <20050224172107.GA2066@thacker.dyndns.org> <1109281070.3817.127.camel@one.myworld> Message-ID: <20050225093941.GA319@joshua.mesa.nl> On Thu, Feb 24, 2005 at 10:37:50PM +0100, F?liciano Matias wrote: > Le jeudi 24 f??vrier 2005 ?? 12:24 -0500, Elliot Lee a ??crit : > > The web site is really out of date. The intent is to move it into > > cvs.fedora.redhat.com Real Soon Now > > Real Soon Now(tm Red Hat) mean one week to two years. ^^^^^^^^^^ This is wrong. We used this terms back in the eighies when waiting for 128 kB memory upgrade for a decvax :-) -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From laroche at redhat.com Fri Feb 25 09:55:21 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 25 Feb 2005 10:55:21 +0100 Subject: reducing distribution CD count In-Reply-To: <1109295521.19762.10.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <20050224200644.GF11644@nostromo.devel.redhat.com> <421E3834.6050707@insitesinc.com> <1109290204.6564.17.camel@localhost.localdomain> <421E7C84.5060702@insitesinc.com> <1109295521.19762.10.camel@localhost.localdomain> Message-ID: <20050225095521.GB5685@dudweiler.stuttgart.redhat.com> > I think it's accurate that Red Hat would like to be maintaining fewer > packages and focusing more on the basics, but at the same time I don't > know why people are so terrified of that. It will probably make both the > basics and the non-basics higher quality to do this since there's more > focus on each one. Until infrastructure is in place, development in FC-extras will be slower than in Fedora Core. Maybe the current way to push the FC-extra resolves this, but I fear lots of additional work for package maintainers. greetings, Florian La Roche From tarjei.knapstad at predichem.com Fri Feb 25 11:03:32 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Fri, 25 Feb 2005 12:03:32 +0100 Subject: Proposal for CD count in FC4 In-Reply-To: <421B7327.9020502@wowway.com> References: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> <421B7327.9020502@wowway.com> Message-ID: <1109329412.30363.5.camel@tarjei.predichem.nett> On Tue, 2005-02-22 at 19:00, Demond James wrote: > Jesse Keating wrote: > > > Given the constraint of not being able to remove packages that were in > FC3 and I think this is the best approach for now. It's going to either > be the main packages like OO.o, Gnome, KDE, etc. or many smaller one > since we need to shave 300mb. Reducing packages is one thing, but is there anything going against pushing the ISO sizes up towards the 700MB barrier? I just checked, and I can't even find anywhere to buy those old 650MB blank CD's, but there may be other problems of course...? If you take this into account there's roughly 200 megs of "free space" on the first 3 FC3 ISO's (roughly 500MB in total as CD4 is only half full). Just a thought... -- Tarjei From rmy at tigress.co.uk Fri Feb 25 11:10:38 2005 From: rmy at tigress.co.uk (Ron Yorston) Date: Fri, 25 Feb 2005 11:10:38 GMT Subject: Exim as default MTA. Message-ID: <200502251110.LAA17130@internal.tigress.co.uk> Bill Nottingham wrote: >David Woodhouse (dwmw2 at infradead.org) said: >> On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote: >> >Dropping it may be drastic; it could be moved to extras. >> >> Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't >> going to fit onto 4 CDs > >FC4 i386 *is* going to fit on 4 CDs (almost certainly). It's x86_64 >and possibly ppc that is over. and, earlier, Elliot Lee wrote: >Something that needs to be mentioned - it was decided that it was better >to go to 5 CDs for now than to kick eclipse and the Java stuff out. Will you @redhat.com people please get your stories straight? And if it is 5 CDs can we have Xfce back, please? Ron From thomas at apestaart.org Fri Feb 25 11:11:29 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 25 Feb 2005 12:11:29 +0100 Subject: reducing distribution CD count In-Reply-To: <1109285049.15658.38.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> Message-ID: <1109329889.5534.7.camel@otto.amantes> On Thu, 2005-02-24 at 17:44 -0500, seth vidal wrote: > On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote: > > Filiciano Matias wrote: > > > > > > 3- The average joe (me) expect to find the documentation in the same > > > place than the program. A program with its documentation is the same > > > whole thing. > > > > Perhaps I'm not an "average joe" in this matter, but I never look for > > documentation on the local disk. I *always* use Google first. > > +1 > > people use local docs? Yes. There is *very little* worse, when looking for documentation, than finding documentation that doesn't match your version and only realizing that tiny little fact after you've spent a whole day trying to understand why something is not working as they should. I *always* install and browse locally docs for stuff I use. People who look on the net first probably also wrote a browser :) Not to mention devhelp is a godsend for anyone who is doing programming. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you ain?t there ain?t nobody else to impress <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From softexpert at libertysurf.fr Fri Feb 25 11:08:07 2005 From: softexpert at libertysurf.fr (Marian POPESCU) Date: Fri, 25 Feb 2005 12:08:07 +0100 Subject: Strange 100% CPU state after 2005022[3|4] updates In-Reply-To: <1109305296.4123.17.camel@clownfish.redfishdemo.com> References: <1109305296.4123.17.camel@clownfish.redfishdemo.com> Message-ID: Rodd Clarkson wrote: > Every now and again my CPU goes into a 100% usage state after recent > rawhide updates (last two days). > > IN one case I couldn't figure out what was causing it and had to > shutdown anyway, so just turned the system off. > > In another, I tried killing gnome-vfs-daemon, gnome-settings-daemon, > nautilus, gamin and finally stopped it killing gnome-panel. > > in both cases I don't know what triggered it, but the usage was roughly > 30-40% user, 60-70% system. > > Just now I've discovered I can trigger a similar state as follows: > > 1. Open Applications > Accessories > Dictionary > 2. Type Role into the Word field and hit enter > 3. Click on the hyperlink Roll (this should bring up the meaning of > Roll) > > Doing this sends my CPU 100% (about 30% user and 70% system) > > Closing the Dictionary fixes this immediately. > > > Is anyone else seeing this (I'll file a bug report if so, or if someone > tells me) and has anyone got any ideas why? > > > Rodd > > I have the same with latest Krusader compiled from CVS. Just leaving it open for a couple of minutes and the CPU jumps to 100%. I have latest rawhide. Marian From arjanv at redhat.com Fri Feb 25 11:19:05 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 25 Feb 2005 12:19:05 +0100 Subject: Proposal for CD count in FC4 In-Reply-To: <1109329412.30363.5.camel@tarjei.predichem.nett> References: <1109023440.5710.163.camel@jkeating2.hq.pogolinux.com> <421B7327.9020502@wowway.com> <1109329412.30363.5.camel@tarjei.predichem.nett> Message-ID: <1109330346.6290.46.camel@laptopd505.fenrus.org> On Fri, 2005-02-25 at 12:03 +0100, Tarjei Knapstad wrote: > On Tue, 2005-02-22 at 19:00, Demond James wrote: > > Jesse Keating wrote: > > > > > > > Given the constraint of not being able to remove packages that were in > > FC3 and I think this is the best approach for now. It's going to either > > be the main packages like OO.o, Gnome, KDE, etc. or many smaller one > > since we need to shave 300mb. > > Reducing packages is one thing, but is there anything going against > pushing the ISO sizes up towards the 700MB barrier? I just checked, and > I can't even find anywhere to buy those old 650MB blank CD's, but there > may be other problems of course...? the point is not availability of media. It's cd drives being able to read the extra stuff reliable. Even if 1% can't read them, that will result in a HUGE bug inflow for the anaconda guys and a lot of negative sentiment. -------------- next part -------------- A 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 jos at xos.nl Fri Feb 25 11:39:54 2005 From: jos at xos.nl (Jos Vos) Date: Fri, 25 Feb 2005 12:39:54 +0100 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: <1109300719.10447.4.camel@one.myworld>; from feliciano.matias@free.fr on Fri, Feb 25, 2005 at 04:05:19AM +0100 References: <200502242238.j1OMcsO02013@xos037.xos.nl> <1109300719.10447.4.camel@one.myworld> Message-ID: <20050225123954.A4334@xos037.xos.nl> On Fri, Feb 25, 2005 at 04:05:19AM +0100, F?liciano Matias wrote: > Rawhide *is* FC (development branch). > And FC is *not* all Fedora. Now Fedora is Fedora Core *and* Fedora > extra. > > I don't take a close look but it seems Fedora Extra also have its > development branch : > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ > > Ooops, it's empty :-) Yes, it is :-(. So, assuming that XFCE packages are "in transit" from FC to FE, is there a way to access them *now*? I would like to have all the XFCE 4.2.0 (and related) src.rpm packages, that I saw two days ago on my ftp mirror, but then I was so stupid to think they would be there today too... ;-). Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From skvidal at phy.duke.edu Fri Feb 25 13:05:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 08:05:27 -0500 Subject: Update website to mention CVS, Extras? In-Reply-To: <20050225093941.GA319@joshua.mesa.nl> References: <20050224172107.GA2066@thacker.dyndns.org> <1109281070.3817.127.camel@one.myworld> <20050225093941.GA319@joshua.mesa.nl> Message-ID: <1109336727.16521.73.camel@cutter> On Fri, 2005-02-25 at 10:39 +0100, Marcel J.E. Mol wrote: >On Thu, Feb 24, 2005 at 10:37:50PM +0100, F?liciano Matias wrote: >> Le jeudi 24 f??vrier 2005 ?? 12:24 -0500, Elliot Lee a ??crit : >> > The web site is really out of date. The intent is to move it into >> > cvs.fedora.redhat.com Real Soon Now >> >> Real Soon Now(tm Red Hat) mean one week to two years. > ^^^^^^^^^^ > >This is wrong. We used this terms back in the eighies when >waiting for 128 kB memory upgrade for a decvax :-) You used (tm Red Hat) in the eighties?! Wow! :) -sv From skvidal at phy.duke.edu Fri Feb 25 13:12:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 08:12:31 -0500 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: <20050225123954.A4334@xos037.xos.nl> References: <200502242238.j1OMcsO02013@xos037.xos.nl> <1109300719.10447.4.camel@one.myworld> <20050225123954.A4334@xos037.xos.nl> Message-ID: <1109337151.16521.75.camel@cutter> >Yes, it is :-(. > >So, assuming that XFCE packages are "in transit" from FC to FE, is there >a way to access them *now*? I would like to have all the XFCE 4.2.0 >(and related) src.rpm packages, that I saw two days ago on my ftp mirror, >but then I was so stupid to think they would be there today too... ;-). > development branch of fedora extras is empty b/c we're only waiting on the new branch to be opened. Right now it's still populated with the fc3 packages. -sv From paul at permanentmail.com Fri Feb 25 13:34:27 2005 From: paul at permanentmail.com (Paul Dickson) Date: Fri, 25 Feb 2005 06:34:27 -0700 Subject: reducing distribution CD count In-Reply-To: <421E6145.4324A6D0@jwz.org> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> <1109285823.3817.137.camel@one.myworld> <421E5C97.69BD2CD6@jwz.org> <1109286617.3817.140.camel@one.myworld> <421E6145.4324A6D0@jwz.org> Message-ID: <20050225063427.439b22c6.paul@permanentmail.com> On Thu, 24 Feb 2005 15:20:37 -0800, Jamie Zawinski wrote: > Filiciano Matias wrote: > > > > I prefer this : > > $ rpm -q -l yum | egrep "(man)|(doc)" > > /usr/share/doc/yum-2.1.13 > > /usr/share/doc/yum-2.1.13/AUTHORS > > /usr/share/doc/yum-2.1.13/COPYING > > /usr/share/doc/yum-2.1.13/ChangeLog > > /usr/share/doc/yum-2.1.13/INSTALL > > /usr/share/doc/yum-2.1.13/TODO > > I'd classify those files as "useless bloat." I could not possibly be > interested in those files if I didn't have the source code installed. Then this was a bad example for you. :-) Yum files are python source code. I copied the files and created a version that used wget for downloading, which works much better than the python code over a dialup connection. -Paul From ph18 at cornell.edu Fri Feb 25 14:01:11 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Fri, 25 Feb 2005 09:01:11 -0500 Subject: FC4 slimfast slimfest In-Reply-To: References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <1109024238.26578.52.camel@localhost.localdomain> <421AAE77.5080704@margo.bijoux.nom.br> <1109096669.13684.14.camel@localhost.localdomain> <1109248801.28890.4.camel@wombat.tiptoe.de> <1109250450.5420.48.camel@hades.cambridge.redhat.com> <1109268957.5420.122.camel@hades.cambridge.redhat.com> <1109281180.15454.23.camel@rousalka.dyndns.org> Message-ID: On Thu, 24 Feb 2005 16:50:55 -0600, Jason L Tibbitts III wrote: >>>>>> "NM" == Nicolas Mailhot writes: > > NM> You do know that postfix design is a common example in advanced > NM> security CS courses right ? > > What on Earth does that have to do with anything? I'm sure advanced > race mechanics study Ferrari engines, but I don't need one to drive to > the store. > > I guess what you're trying to say is that all of the extra stuff that > Postfix comes with is secure, so it doesn't hurt anything to have it > on the machine. That's something definitely contradicted by those > advanced security CS courses you speak of. > Most real postfix installations aren't going to be qualified as secure by the authors of postfix, because if you want to implement POP authentication you need to install Cyrus SASL -- which is the kind of "security" software that introduces two buffer overflows for every security hole it plugs. Throw in an average virus filter (see http://news.com.com/Take+three+Antivirus+apps+could+spread+infection/2100-1002_3-5589439.html?tag=nefd.top) and spam filter and I know it can be cracked. If you made a homebrew system, it's likely that nobody's going to spend the time to weaponize an attack, but ship an integrated system with every copy of FC4 and it's worth the effort. From dcbw at redhat.com Fri Feb 25 14:15:11 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 25 Feb 2005 09:15:11 -0500 Subject: debug about NetworkManager & resolv.conf being erased In-Reply-To: <421EEFFE.30003@univ-nantes.fr> References: <421EEFFE.30003@univ-nantes.fr> Message-ID: <1109340911.22812.2.camel@dcbw.boston.redhat.com> On Fri, 2005-02-25 at 10:29 +0100, Arnaud Ab?lard wrote: > Dan, you've been asking for debug infos about NetworkManager & the > resolv.conf problem, so here it comes: > > I've been trying to use NetworkManager to manage my ethernet and > wireless devices on FC3. As it was previously said on the list, > NetworkManager sometimes erase the current resolv.conf file with en > empty one. Ok, I think I know what's going on here. NM used to have a "feature" where it would not attempt touch a wired connection that was active when NM started up. This was present to allow users with network-mounted home directories to use NM (if you bring down the network device, your computer basically freezes because your homedir is network mounted). I removed that "feature" quite a few weeks ago because it caused too many problems, like this one. Current CVS and the builds in rawhide shouldn't have this problem, but FC3 builds have lagged behind a bit. What version of NetworkManager are you running? Is this the one from fc3-updates or fc3-updates-testing? Dan From ellson at research.att.com Fri Feb 25 14:25:21 2005 From: ellson at research.att.com (John Ellson) Date: Fri, 25 Feb 2005 09:25:21 -0500 Subject: Strange 100% CPU state after 2005022[3|4] updates In-Reply-To: <1109305296.4123.17.camel@clownfish.redfishdemo.com> References: <1109305296.4123.17.camel@clownfish.redfishdemo.com> Message-ID: <421F3551.8010900@research.att.com> Rodd Clarkson wrote: >Every now and again my CPU goes into a 100% usage state after recent >rawhide updates (last two days). > >IN one case I couldn't figure out what was causing it and had to >shutdown anyway, so just turned the system off. > >In another, I tried killing gnome-vfs-daemon, gnome-settings-daemon, >nautilus, gamin and finally stopped it killing gnome-panel. > >in both cases I don't know what triggered it, but the usage was roughly >30-40% user, 60-70% system. > >Just now I've discovered I can trigger a similar state as follows: > >1. Open Applications > Accessories > Dictionary >2. Type Role into the Word field and hit enter >3. Click on the hyperlink Roll (this should bring up the meaning of >Roll) > >Doing this sends my CPU 100% (about 30% user and 70% system) > >Closing the Dictionary fixes this immediately. > > >Is anyone else seeing this (I'll file a bug report if so, or if someone >tells me) and has anyone got any ideas why? > > >Rodd > > > > I think Jim Cornette was seeing something very similar recently, reported on fedora-test-list. Let me see if I can hook you up... John From aaron.bennett at olin.edu Fri Feb 25 14:31:02 2005 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Fri, 25 Feb 2005 09:31:02 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109287914.26364.69.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> Message-ID: <421F36A6.8040401@olin.edu> David Woodhouse wrote: > >People who require the overzealously pruned packages can just skip FC4 >and wait until FC5, at which point upgrades from FC3 should hopefully be >working again. > > > Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have missed something. Can someone confirm that this is true, or better yet, not true? If there's no upgrade path from FCX -> FCY, then the six month release cycle + Red Hat's EOL policy will orphan users on un-upgradeable systems. -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From skvidal at phy.duke.edu Fri Feb 25 14:38:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 09:38:42 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F36A6.8040401@olin.edu> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> Message-ID: <1109342322.16521.84.camel@cutter> >Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have >missed something. Can someone confirm that this is true, or better yet, >not true? If there's no upgrade path from FCX -> FCY, then the six >month release cycle + Red Hat's EOL policy will orphan users on >un-upgradeable systems. > upgrades from fc3->fc4 will work, just like anything else. David is fear-mongering a bit. At the worst case once the system is upgraded via anaconda you'll need to run yum update to make sure any packages once in extras are moved over. -sv From ghenry at suretecsystems.com Fri Feb 25 14:35:37 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 25 Feb 2005 14:35:37 -0000 (GMT) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F36A6.8040401@olin.edu> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl><1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com><1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> Message-ID: <40818.193.195.148.66.1109342137.squirrel@webmail.suretecsystems.com> > David Woodhouse wrote: > >> >>People who require the overzealously pruned packages can just skip FC4 >>and wait until FC5, at which point upgrades from FC3 should hopefully be >>working again. >> >> >> > Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have > missed something. Can someone confirm that this is true, or better yet, > not true? If there's no upgrade path from FCX -> FCY, then the six > month release cycle + Red Hat's EOL policy will orphan users on > un-upgradeable systems. > Is this not the nature of RPMS? A seemless upgrade path? > > -- > Aaron Bennett > UNIX Administrator > Franklin W. Olin College of Engineering > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From aaron.bennett at olin.edu Fri Feb 25 14:42:09 2005 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Fri, 25 Feb 2005 09:42:09 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109342322.16521.84.camel@cutter> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342322.16521.84.camel@cutter> Message-ID: <421F3941.5000501@olin.edu> seth vidal wrote: > >upgrades from fc3->fc4 will work, just like anything else. David is >fear-mongering a bit. > >At the worst case once the system is upgraded via anaconda you'll need >to run yum update to make sure any packages once in extras are moved >over. > >-sv > > Excellent. I hoped that would be the case. Was I just trolled? :-) -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From dwmw2 at infradead.org Fri Feb 25 14:43:05 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 14:43:05 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F36A6.8040401@olin.edu> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> Message-ID: <1109342585.26364.163.camel@localhost.localdomain> On Fri, 2005-02-25 at 09:31 -0500, Aaron Bennett wrote: >Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have >missed something. Can someone confirm that this is true, or better >yet, not true? If there's no upgrade path from FCX -> FCY, then the >six month release cycle + Red Hat's EOL policy will orphan users on >un-upgradeable systems. It depends on the packages you have installed. As it stands, some packages which were in FC3 are missing from the rawhide tree -- so an upgrade will not be able to update the complete package set. The will leave outdated packages installed -- whether that causes problems or not depends on the package and its dependencies. If it's built against versions of shared libraries which are no longer present, then I believe the installer will have removed the old version of those libraries and will have left the package in question broken. That may be your MTA or your X environment -- nothing important :) As Seth says, you may be able to update the missing packages separately to remedy this, if Extras has actually come together and has those packages in a usable form by the time you upgrade. By the time FC5 happens, however, Extras should be working properly and the installer should handle it -- an upgrade should work properly as before. That's why many people are requesting that we postpone the package-killing spree until FC5 instead of doing it now. The upgrade/EOL schedules basically give you the leeway to skip a Fedora release and upgrade from N to N+2. If FC4 doesn't regain the missing packages, I suspect I'll just be leaving most of my machines running FC3 until FC5 is released, and update them then. The ones which were FC2 and waiting till FC4 will be updated to FC3 and then wait till FC5. -- dwmw2 From cmadams at hiwaay.net Fri Feb 25 14:53:25 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Feb 2005 08:53:25 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109342585.26364.163.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> Message-ID: <20050225145325.GB1048932@hiwaay.net> Once upon a time, David Woodhouse said: > If it's built against > versions of shared libraries which are no longer present, then I believe > the installer will have removed the old version of those libraries and > will have left the package in question broken. Do you have evidence to back that up? Does anaconda somehow disable the normal dependency checking? Normally, rpm would refuse to remove a library that is still required by another installed RPM. I can see that you would be unable to upgrade if: - existing RPM xyzzy required libfoo.so.1 - existing RPM libfoo-1.0 provides libfoo.so.1 - RPM xyzzy was moved from Core to Extras (so unavailable for FC4 install) - new RPM libfoo-2.0 provides libfoo.so.2 - new RPM system-config-bar requires libfoo.so.2 and is in the default install If there isn't a compat-libfoo that provides libfoo.so.1, you would be stuck. The question is: what would anaconda do in that case? Would it abort installation because dependencies cannot be satisfied, or would it attempt to upgrade anyway (and break either RPM xyzzy or RPM system-config-bar)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fedora-devel at camperquake.de Fri Feb 25 14:56:15 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 25 Feb 2005 15:56:15 +0100 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225145325.GB1048932@hiwaay.net> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> Message-ID: <20050225155615.49496189@nausicaa.camperquake.de> Hi. Chris Adams wrote: > Does anaconda somehow disable the > normal dependency checking? Yes. From elanthis at awesomeplay.com Fri Feb 25 15:05:00 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 25 Feb 2005 10:05:00 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225145325.GB1048932@hiwaay.net> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> Message-ID: <1109343900.30366.23.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-02-25 at 08:53 -0600, Chris Adams wrote: >Once upon a time, David Woodhouse said: >> If it's built against >> versions of shared libraries which are no longer present, then I believe >> the installer will have removed the old version of those libraries and >> will have left the package in question broken. > >Do you have evidence to back that up? Does anaconda somehow disable the >normal dependency checking? Normally, rpm would refuse to remove a >library that is still required by another installed RPM. > >I can see that you would be unable to upgrade if: > >- existing RPM xyzzy required libfoo.so.1 >- existing RPM libfoo-1.0 provides libfoo.so.1 >- RPM xyzzy was moved from Core to Extras (so unavailable for FC4 install) >- new RPM libfoo-2.0 provides libfoo.so.2 >- new RPM system-config-bar requires libfoo.so.2 and is in the default install Unfortunately, most library packages in Fedora aren't packaged nearly so intelligently. Worse, many library packages aren't even split from applications (curl utility vs libcurl, for example - both come in a single package) so all sorts of unfortunate situations arise when you use a package not in Core (or Extras, once that's fully integrated) that depends on a library that gets upgraded in the next release. And, unfortunately, real people generally do need or want a package or three not supplied by Fedora, so these issues pop up regularly. Every bug I've filed pointing out the problem caused by poorly packaged libraries gets closed with a message that's the equivalent of, "This isn't worth our time, you must eat babies if you use packages outside of Core, and there's no real advantage at all to not breaking stuff, so go away." Kind of frustrating, to say the least... > >If there isn't a compat-libfoo that provides libfoo.so.1, you would be >stuck. The question is: what would anaconda do in that case? Would it Or what happens in FC+2 where compat-libfoo doesn't provide libfoo.so.1 anymore, but now only provides libfoo.so.2? The entire compat-* is so incredibly brain damaged and poorly conceived that I am honestly shocked it's actually lived this long. If you're going to have multiple packages provide multiple versions of a library, name the package according to the version it supplies, so you can actually have *many* versions of a library installed (if you need it) without needing to do manual rpm -i foo-hackery that tends to break all sorts of useful things (like upgrades). >abort installation because dependencies cannot be satisfied, or would it >attempt to upgrade anyway (and break either RPM xyzzy or RPM >system-config-bar)? > >-- >Chris Adams >Systems and Network Administrator - HiWAAY Internet Services >I don't speak for anybody but myself - that's enough trouble. > -- Sean Middleditch From skvidal at phy.duke.edu Fri Feb 25 15:08:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 10:08:45 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225145325.GB1048932@hiwaay.net> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> Message-ID: <1109344125.10989.0.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 08:53 -0600, Chris Adams wrote: > Once upon a time, David Woodhouse said: > > If it's built against > > versions of shared libraries which are no longer present, then I believe > > the installer will have removed the old version of those libraries and > > will have left the package in question broken. > > Do you have evidence to back that up? Does anaconda somehow disable the > normal dependency checking? Normally, rpm would refuse to remove a > library that is still required by another installed RPM. anaconda does disable normal dep checking if it can't resolve something, that's true - however, it doesn't remove stuff. -sv From dwmw2 at infradead.org Fri Feb 25 15:47:28 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 15:47:28 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109344125.10989.0.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> Message-ID: <1109346448.26364.177.camel@localhost.localdomain> On Fri, 2005-02-25 at 10:08 -0500, seth vidal wrote: >anaconda does disable normal dep checking if it can't resolve something, >that's true - however, it doesn't remove stuff. Let's consider an example. You have an FC2 system with Acrobat 7 installed, which uses libcurl.so.2. You update to FC3. What does anaconda do with the curl-7.11.1-1 package and hence /usr/lib/libcurl.so.2? Does it not remove it and replace it with a new package that no longer provides libcurl.so.2? My understanding is that anaconda will remove the old curl package and install a new one, and that the Acrobat reader will no longer run. Are you suggesting that that's that _not_ what happens? That anaconda doesn't remove stuff? That out-of-Core packages don't ever get broken by upgrades? By FC5, anaconda should handle Extras properly and everything should be fine. We can start moving packages to Extras in a controlled fashion and cut Core down to a minimum -- that makes a lot of sense. What _doesn't_ make sense is doing it right now in a mad rush. Especially if we're not going to achieve the goal of cutting the i386 install to 4 CDs anyway -- regardless of the question of whether that's a worthwhile thing to be attempting in the first place. -- dwmw2 From skvidal at phy.duke.edu Fri Feb 25 15:52:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 10:52:21 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109342585.26364.163.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> Message-ID: <1109346741.10989.13.camel@opus.phy.duke.edu> > It depends on the packages you have installed. As it stands, some > packages which were in FC3 are missing from the rawhide tree -- so an > upgrade will not be able to update the complete package set. The will > leave outdated packages installed -- whether that causes problems or not > depends on the package and its dependencies. If it's built against > versions of shared libraries which are no longer present, then I believe > the installer will have removed the old version of those libraries and > will have left the package in question broken. That may be your MTA or > your X environment -- nothing important :) > > As Seth says, you may be able to update the missing packages separately > to remedy this, if Extras has actually come together and has those > packages in a usable form by the time you upgrade. So the way I see it here are the items needed to make extras work for fc4: 1. branch fc3 off of devel in extras cvs 2. get release updates in extras cvs spec files 3. build world 4. look for things that break 5. wash, rinse, repeat. What we don't need right now is a lot of fatalism. -sv From mricon at gmail.com Fri Feb 25 15:54:28 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 25 Feb 2005 10:54:28 -0500 Subject: Update website to mention CVS, Extras? In-Reply-To: <1109336727.16521.73.camel@cutter> References: <20050224172107.GA2066@thacker.dyndns.org> <1109281070.3817.127.camel@one.myworld> <20050225093941.GA319@joshua.mesa.nl> <1109336727.16521.73.camel@cutter> Message-ID: On Fri, 25 Feb 2005 08:05:27 -0500, seth vidal wrote: > You used (tm Red Hat) in the eighties?! Wow! > :) Russia had lots of red hats in the eighties. I even wore one with my dress school uniform for pioneers day. :) Cheers, -- Konstantin Ryabitsev Zlotniks, INC From skvidal at phy.duke.edu Fri Feb 25 15:56:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 10:56:03 -0500 Subject: Update website to mention CVS, Extras? In-Reply-To: References: <20050224172107.GA2066@thacker.dyndns.org> <1109281070.3817.127.camel@one.myworld> <20050225093941.GA319@joshua.mesa.nl> <1109336727.16521.73.camel@cutter> Message-ID: <1109346963.10989.17.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 10:54 -0500, Konstantin Ryabitsev wrote: > On Fri, 25 Feb 2005 08:05:27 -0500, seth vidal wrote: > > You used (tm Red Hat) in the eighties?! Wow! > > :) > > Russia had lots of red hats in the eighties. I even wore one with my > dress school uniform for pioneers day. :) damn commie ;) -sv ps: before anyone gets upset I know Icon personally and I'm joking around. From dwmw2 at infradead.org Fri Feb 25 15:56:13 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 15:56:13 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109346741.10989.13.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> Message-ID: <1109346973.26364.181.camel@localhost.localdomain> On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote: >So the way I see it here are the items needed to make extras work for >fc4: > >1. branch fc3 off of devel in extras cvs >2. get release updates in extras cvs spec files >3. build world >4. look for things that break >5. wash, rinse, repeat. > 6. Add support to anaconda for multiple repositories (planned for FC5) >What we don't need right now is a lot of fatalism. What we need is to do it in a controlled fashion; not just dump random packages when a release is imminent. Doing it in rawhide just after the release of FC4 would make sense, and then it will be fine in FC5. -- dwmw2 From pmatilai at welho.com Fri Feb 25 15:59:51 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Feb 2005 17:59:51 +0200 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109346448.26364.177.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> Message-ID: <1109347191.621.2.camel@chip.laiskiainen.org> On Fri, 2005-02-25 at 15:47 +0000, David Woodhouse wrote: > On Fri, 2005-02-25 at 10:08 -0500, seth vidal wrote: > >anaconda does disable normal dep checking if it can't resolve something, > >that's true - however, it doesn't remove stuff. > > Let's consider an example. You have an FC2 system with Acrobat 7 > installed, which uses libcurl.so.2. > > You update to FC3. What does anaconda do with the curl-7.11.1-1 package > and hence /usr/lib/libcurl.so.2? Does it not remove it and replace it > with a new package that no longer provides libcurl.so.2? > > My understanding is that anaconda will remove the old curl package and > install a new one, That's called upgrading, not removing stuff :) > and that the Acrobat reader will no longer run. Are > you suggesting that that's that _not_ what happens? That anaconda > doesn't remove stuff? That out-of-Core packages don't ever get broken by > upgrades? What Seth means by anaconda not removing stuff is that in your example, assuming that acroread was installed as an rpm, anaconda wouldn't remove acroread because it's dependencies couldn't be matched, it just leaves the package with it's broken dependencies alone. - Panu - From dwmw2 at infradead.org Fri Feb 25 16:03:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 16:03:31 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109347191.621.2.camel@chip.laiskiainen.org> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> Message-ID: <1109347412.26364.185.camel@localhost.localdomain> On Fri, 2005-02-25 at 17:59 +0200, Panu Matilainen wrote: >What Seth means by anaconda not removing stuff is that in your example, >assuming that acroread was installed as an rpm, anaconda wouldn't remove >acroread because it's dependencies couldn't be matched, it just leaves >the package with it's broken dependencies alone. Right. Anaconda doesn't actually remove the out-of-Core package itself -- nobody suggested that it does. But it still doesn't actually _work_ if the libraries on which it depends have been removed. Btw, http://angryflower.com/itsits.gif :) -- dwmw2 From skvidal at phy.duke.edu Fri Feb 25 16:11:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 11:11:28 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109347412.26364.185.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> Message-ID: <1109347888.10989.20.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 16:03 +0000, David Woodhouse wrote: > On Fri, 2005-02-25 at 17:59 +0200, Panu Matilainen wrote: > >What Seth means by anaconda not removing stuff is that in your example, > >assuming that acroread was installed as an rpm, anaconda wouldn't remove > >acroread because it's dependencies couldn't be matched, it just leaves > >the package with it's broken dependencies alone. > > Right. Anaconda doesn't actually remove the out-of-Core package itself > -- nobody suggested that it does. But it still doesn't actually _work_ > if the libraries on which it depends have been removed. so you're really only dealing with obsoletes. oh and anaconda has no way of dealing with closed source binaries really anyway - on any version of anaconda, ever. and since things have been removed from rhl and fc in the past - your argument is just a straw man. > > Btw, http://angryflower.com/itsits.gif :) BTW,. you're being a dick. -sv From skvidal at phy.duke.edu Fri Feb 25 16:15:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 11:15:24 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109346973.26364.181.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> Message-ID: <1109348125.10989.22.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 15:56 +0000, David Woodhouse wrote: > On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote: > >So the way I see it here are the items needed to make extras work for > >fc4: > > > >1. branch fc3 off of devel in extras cvs > >2. get release updates in extras cvs spec files > >3. build world > >4. look for things that break > >5. wash, rinse, repeat. > > > 6. Add support to anaconda for multiple repositories (planned for FC5) > > >What we don't need right now is a lot of fatalism. > > What we need is to do it in a controlled fashion; not just dump random > packages when a release is imminent. Doing it in rawhide just after the > release of FC4 would make sense, and then it will be fine in FC5. Packages have been removed in every release. This isn't new. -sv From nicolas.mailhot at laposte.net Fri Feb 25 16:17:22 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Feb 2005 17:17:22 +0100 (CET) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109346973.26364.181.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> Message-ID: <6554.192.54.193.137.1109348242.squirrel@rousalka.dyndns.org> On Ven 25 f?vrier 2005 16:56, David Woodhouse a ?crit : > On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote: >>So the way I see it here are the items needed to make extras work for >>fc4: >> >>1. branch fc3 off of devel in extras cvs >>2. get release updates in extras cvs spec files >>3. build world >>4. look for things that break >>5. wash, rinse, repeat. >> > 6. Add support to anaconda for multiple repositories (planned for FC5) > >>What we don't need right now is a lot of fatalism. > > What we need is to do it in a controlled fashion; not just dump random > packages when a release is imminent. Doing it in rawhide just after the > release of FC4 would make sense, and then it will be fine in FC5. If there was an extra branch synched with rawhide and if all the packages dumped from rawhide these past days were to appear there at lot of people would feel less nervous. It's not as if these packages need special work - they were already working in rawhide before. FC3 extras are more difficult - they never were synched with devel so all their problems will need to be fixed at once (which also means it might be a good idea to keep and extra devel branch dogfoodable at all times if we even want extras to be released as the same time as FC in the future) Regards, -- Nicolas Mailhot From cmadams at hiwaay.net Fri Feb 25 16:19:27 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Feb 2005 10:19:27 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109347888.10989.20.camel@opus.phy.duke.edu> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> Message-ID: <20050225161927.GC1048932@hiwaay.net> Once upon a time, seth vidal said: > On Fri, 2005-02-25 at 16:03 +0000, David Woodhouse wrote: > > Right. Anaconda doesn't actually remove the out-of-Core package itself > > -- nobody suggested that it does. But it still doesn't actually _work_ > > if the libraries on which it depends have been removed. > > so you're really only dealing with obsoletes. You are dealing with the fact that anaconda can't handle non-Core packages and that it can break any installed non-Core package (including packages that were previously in Core but now are not). > oh and anaconda has no way of dealing with closed source binaries really > anyway - on any version of anaconda, ever. Red herring - anaconda has no way of dealing with any kind of source and it doesn't know (or care) about the difference in the license or where the package came from (other than "current Core"). Throwing the "closed source" arguement is just trying to ignore the problem or blame it on someone else. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at phy.duke.edu Fri Feb 25 16:21:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 11:21:08 -0500 Subject: Exim as default MTA. In-Reply-To: <200502251110.LAA17130@internal.tigress.co.uk> References: <200502251110.LAA17130@internal.tigress.co.uk> Message-ID: <1109348468.10989.26.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 11:10 +0000, Ron Yorston wrote: > Bill Nottingham wrote: > >David Woodhouse (dwmw2 at infradead.org) said: > >> On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote: > >> >Dropping it may be drastic; it could be moved to extras. > >> > >> Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't > >> going to fit onto 4 CDs > > > >FC4 i386 *is* going to fit on 4 CDs (almost certainly). It's x86_64 > >and possibly ppc that is over. > > and, earlier, > > Elliot Lee wrote: > >Something that needs to be mentioned - it was decided that it was better > >to go to 5 CDs for now than to kick eclipse and the Java stuff out. > > Will you @redhat.com people please get your stories straight? > > And if it is 5 CDs can we have Xfce back, please? > Ron, This isn't about 'getting stories straight' it's not like red hat is a single mind acting in unison. It's not like any open source project is like that either. Here's the deal. Xfce got dropped out of core b/c we're trying to shave off some misc packages. Do I think it'll be in extras? Yes. I actually think it will: 1. be in extras 2. be kept more updated from extras 3. not be a problem for you. I know it's hard to believe but we're trying to get everything together and sometimes it just takes a little time. -sv From cmadams at hiwaay.net Fri Feb 25 16:22:19 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Feb 2005 10:22:19 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109348125.10989.22.camel@opus.phy.duke.edu> References: <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> Message-ID: <20050225162219.GD1048932@hiwaay.net> Once upon a time, seth vidal said: > Packages have been removed in every release. This isn't new. In the past, packages were removed because they were no longer functional, not widely used, etc. They weren't just pushed to another location, they were dropped altogether. What we are seeing now is a large scale dumping of packages with the excuse that they can go to Extras. However, since Extras isn't available at install, ISOs are not available for download, and anaconda can't handle dependencies, currently running software can be broken by upgrades. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at phy.duke.edu Fri Feb 25 16:23:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 11:23:56 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225161927.GC1048932@hiwaay.net> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> Message-ID: <1109348636.10989.30.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 10:19 -0600, Chris Adams wrote: > Once upon a time, seth vidal said: > > On Fri, 2005-02-25 at 16:03 +0000, David Woodhouse wrote: > > > Right. Anaconda doesn't actually remove the out-of-Core package itself > > > -- nobody suggested that it does. But it still doesn't actually _work_ > > > if the libraries on which it depends have been removed. > > > > so you're really only dealing with obsoletes. > > You are dealing with the fact that anaconda can't handle non-Core > packages and that it can break any installed non-Core package (including > packages that were previously in Core but now are not). but it doesn't break them in the since that it's non-functional - it just makes them go away for the first boot. > > oh and anaconda has no way of dealing with closed source binaries really > > anyway - on any version of anaconda, ever. > > Red herring - anaconda has no way of dealing with any kind of source and > it doesn't know (or care) about the difference in the license or where > the package came from (other than "current Core"). Throwing the "closed > source" arguement is just trying to ignore the problem or blame it on > someone else. Not really, the open source ones could feasibly be included in fedora core and therefore could deal with it. The closed source items cannot. -sv From skvidal at phy.duke.edu Fri Feb 25 16:25:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 11:25:30 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225162219.GD1048932@hiwaay.net> References: <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> Message-ID: <1109348730.10989.33.camel@opus.phy.duke.edu> > In the past, packages were removed because they were no longer > functional, not widely used, etc. They weren't just pushed to another > location, they were dropped altogether. > > What we are seeing now is a large scale dumping of packages with the > excuse that they can go to Extras. However, since Extras isn't > available at install, ISOs are not available for download, and anaconda > can't handle dependencies, currently running software can be broken by > upgrades. anaconda can so handle dependencies it just doesn't currently have a way to talk to those repositories that have the dependencies. -sv From dnjinc at wowway.com Fri Feb 25 16:27:28 2005 From: dnjinc at wowway.com (Demond James) Date: Fri, 25 Feb 2005 11:27:28 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109346973.26364.181.camel@localhost.localdomain> References: <200502240906.20729.czar@czarc.net> <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> Message-ID: <421F51F0.2090907@wowway.com> David Woodhouse wrote: >On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote: > > >>So the way I see it here are the items needed to make extras work for >>fc4: >> >>1. branch fc3 off of devel in extras cvs >>2. get release updates in extras cvs spec files >>3. build world >>4. look for things that break >>5. wash, rinse, repeat. >> >> >> >6. Add support to anaconda for multiple repositories (planned for FC5) > > > >>What we don't need right now is a lot of fatalism. >> >> > >What we need is to do it in a controlled fashion; not just dump random >packages when a release is imminent. Doing it in rawhide just after the >release of FC4 would make sense, and then it will be fine in FC5. > > > I have to agree that the timing is a little bad, but package were added to rawhide after FC3 release so now that test1 release is coming up things move into perspective. The packages are being removed. I say lets leave the horror stories until test1 is out there then 4. look for things that break 5. wash, rinse, repeat. From dwmw2 at infradead.org Fri Feb 25 16:30:40 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 16:30:40 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109348730.10989.33.camel@opus.phy.duke.edu> References: <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> Message-ID: <1109349041.26364.190.camel@localhost.localdomain> On Fri, 2005-02-25 at 11:25 -0500, seth vidal wrote: >anaconda can so handle dependencies >it just doesn't currently have a way to talk to those repositories that >have the dependencies. ....so it can't handle them. Seth, you seem to be deliberately muddying the issue, just as with the red herring 'closed source' thing. I chose acroread 7 as an example of a package with dependencies on a library which is absent from a later version of Core. Whether you can get the source or not is entirely irrelevant. Getting back to the point you were deviating from -- apparently the intention is that anaconda _will_ be able to handle such out-of-Core dependencies in FC5, which is why so many people are suggesting that the package-killing spree be postponed until FC5. -- dwmw2 From jspaleta at gmail.com Fri Feb 25 16:36:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Feb 2005 11:36:27 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225161927.GC1048932@hiwaay.net> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> Message-ID: <604aa7910502250836415a5f6e@mail.gmail.com> On Fri, 25 Feb 2005 10:19:27 -0600, Chris Adams wrote: > Red herring - anaconda has no way of dealing with any kind of source and > it doesn't know (or care) about the difference in the license or where > the package came from (other than "current Core"). Throwing the "closed > source" arguement is just trying to ignore the problem or blame it on > someone else. No one is ignoring the problem... he's pointing out this problem has always existed and will continue to exist for a class of software for which repositories won't exist. My Absoft fortran compiler for example.. won't ever show up in an online repository built explicitly for fedora... but i am able to upgrade the system and fix its deps once i reboot. No one is ignoring the problem... packages have been dropped in previous releases even way back in rhl... when there was no Extras. If all the java stuff was ready for fc1 or fc2 or rhl9.. we have the same problem... with the same solution. If anything the fact that there is a plan for fc5 to resolve the "long term" problem says that its not being ignored. There is a constant balancing between long term interests and short term interests... this round is not very different than the last 8 releases. -jef From eric at snowmoon.com Fri Feb 25 16:56:03 2005 From: eric at snowmoon.com (Eric Warnke) Date: Fri, 25 Feb 2005 11:56:03 -0500 (EST) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <604aa7910502250836415a5f6e@mail.gmail.com> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> Message-ID: <20050225114242.P98262@malkav.snowmoon.com> On Fri, 25 Feb 2005, Jeff Spaleta wrote: > No one is ignoring the problem... packages have been dropped in > previous releases even way back in rhl... when there was no Extras. If > all the java stuff was ready for fc1 or fc2 or rhl9.. we have the same > problem... with the same solution. If anything the fact that there is I think everyone wants the same things, to make sure FC4 does not turn into an end user nightmare. Personally my vote would be for 5 cd's until a true fix can be applied rather than a last minute pulling of packages. But seeing as that may not be happening. The problem that I and others see is that people using core could update and find a broken system. Yes, this is something yum could fix, but if the user is using CD's they may not have access to update at that point. So the people that use CD because they don't have broadband are going to be the poeple hardest hit by these changes. I just don't wat to alienate those users who just invested a number of hours to upgrade to fc4. ( forgive me if this exists already ) What if anaconda mearly warned people that the following packages will have unsatified dependancies at the end of the install and that the person may/will need access to extras and or access to the internet to complete installation? This would allow people to know what they were getting into and decide if the wanted to upgrade immediatly and break things or wait. It's not the perfect solution, but at least it allows users to make an informed decision about proceeding with the upgrade IF they are affected by the loss of packages in core. People unaffected would install as they always have. Cheers, Eric Warnke Systems Admin - Research Technology SUNY at Albany From cmadams at hiwaay.net Fri Feb 25 17:18:36 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Feb 2005 11:18:36 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109348636.10989.30.camel@opus.phy.duke.edu> References: <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <1109348636.10989.30.camel@opus.phy.duke.edu> Message-ID: <20050225171836.GE1048932@hiwaay.net> Once upon a time, seth vidal said: > > Red herring - anaconda has no way of dealing with any kind of source and > > it doesn't know (or care) about the difference in the license or where > > the package came from (other than "current Core"). Throwing the "closed > > source" arguement is just trying to ignore the problem or blame it on > > someone else. > > Not really, the open source ones could feasibly be included in fedora > core and therefore could deal with it. The closed source items cannot. So then we'd be back to Fedora Core being 11 CDs, because everything would have to be included. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ndbecker2 at verizon.net Fri Feb 25 17:50:57 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Fri, 25 Feb 2005 12:50:57 -0500 Subject: system-config-network profiles and hard links Message-ID: I don't understand why system-config-network is creating new profiles using hard links. AFAICT, this is totally broken on my FC3 system. Every time I try to change an existing wireless profile, it seems to change them all. Guess why? They are all hard linked together. For example: ls -l /etc/sysconfig/networking/profiles/home/ total 20 -rw-r--r-- 1 root root 131 Feb 25 12:43 hosts -rw-r--r-- 6 root root 349 Feb 25 12:43 ifcfg-eth1 -rw------- 6 root root 15 Feb 25 12:43 keys-eth1 -rw-r--r-- 1 root root 0 Feb 25 12:43 network -rw-r--r-- 1 root root 92 Feb 25 12:43 resolv.conf -rw-r--r-- 6 root root 120 Feb 25 12:43 route-eth1 Something is really wrong here. From notting at redhat.com Fri Feb 25 18:05:53 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Feb 2005 13:05:53 -0500 Subject: Exim as default MTA. In-Reply-To: <200502251110.LAA17130@internal.tigress.co.uk> References: <200502251110.LAA17130@internal.tigress.co.uk> Message-ID: <20050225180553.GB24018@nostromo.devel.redhat.com> Ron Yorston (rmy at tigress.co.uk) said: > Bill Nottingham wrote: > >David Woodhouse (dwmw2 at infradead.org) said: > >> On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote: > >> >Dropping it may be drastic; it could be moved to extras. > >> > >> Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't > >> going to fit onto 4 CDs > > > >FC4 i386 *is* going to fit on 4 CDs (almost certainly). It's x86_64 > >and possibly ppc that is over. > > and, earlier, > > Elliot Lee wrote: > >Something that needs to be mentioned - it was decided that it was better > >to go to 5 CDs for now than to kick eclipse and the Java stuff out. > > Will you @redhat.com people please get your stories straight? i386 is 4 CDs. It was decided to leave x86_64 at 5 CDs rather than remove Eclipse. Bill From stan at ccs.neu.edu Fri Feb 25 18:17:24 2005 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Fri, 25 Feb 2005 13:17:24 -0500 Subject: Exim as default MTA. In-Reply-To: <20050225180553.GB24018@nostromo.devel.redhat.com> References: <200502251110.LAA17130@internal.tigress.co.uk> <20050225180553.GB24018@nostromo.devel.redhat.com> Message-ID: <421F6BB4.9050309@ccs.neu.edu> Bill Nottingham wrote: > > i386 is 4 CDs. It was decided to leave x86_64 at 5 CDs rather than > remove Eclipse. I really really like the decision to leave eclipse in the main distro. IMHO it has really matured to the point where it is a very viable IDE and I use it frequently for class and personal work. In general I think the packages being removed are all excellent candidates, you all deserve special brownies for this ;-) -sb > > Bill > From skvidal at phy.duke.edu Fri Feb 25 18:17:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 13:17:07 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109349041.26364.190.camel@localhost.localdomain> References: <421E0890.3020302@hhs.nl> <1109267770.15658.0.camel@opus.phy.duke.edu> <20050224222530.GQ11644@nostromo.devel.redhat.com> <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> Message-ID: <1109355427.10989.39.camel@opus.phy.duke.edu> > Getting back to the point you were deviating from -- apparently the > intention is that anaconda _will_ be able to handle such out-of-Core > dependencies in FC5, which is why so many people are suggesting that the > package-killing spree be postponed until FC5. and I'm explaining that the 'package killing spree' as you so colorfully have put it, is not anything new. it's happened in EVERY RELEASE. It just wasn't discussed. which leads me to believe that, due to the reaction this time around, it won't be discussed in the future. It'll just happen. -sv From skvidal at phy.duke.edu Fri Feb 25 18:19:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 13:19:05 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225114242.P98262@malkav.snowmoon.com> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> Message-ID: <1109355545.10989.41.camel@opus.phy.duke.edu> On Fri, 2005-02-25 at 11:56 -0500, Eric Warnke wrote: > > On Fri, 25 Feb 2005, Jeff Spaleta wrote: > > > No one is ignoring the problem... packages have been dropped in > > previous releases even way back in rhl... when there was no Extras. If > > all the java stuff was ready for fc1 or fc2 or rhl9.. we have the same > > problem... with the same solution. If anything the fact that there is > > I think everyone wants the same things, to make sure FC4 does not turn > into an end user nightmare. Personally my vote would be for 5 cd's until > a true fix can be applied rather than a last minute pulling of packages. > But seeing as that may not be happening. That's been true forever if you EVER installed a former release and either: 1. had ANY package removed which you used (lprng anyone?) 2. ever installed something from fedora.us, freshrpms, dagrpms, atrpms, etc etc etc b/c those deps wouldn't be accounted for in the installer. This isn't new. -sv From mricon at gmail.com Fri Feb 25 18:42:05 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 25 Feb 2005 13:42:05 -0500 Subject: Update website to mention CVS, Extras? In-Reply-To: <1109346963.10989.17.camel@opus.phy.duke.edu> References: <20050224172107.GA2066@thacker.dyndns.org> <1109281070.3817.127.camel@one.myworld> <20050225093941.GA319@joshua.mesa.nl> <1109336727.16521.73.camel@cutter> <1109346963.10989.17.camel@opus.phy.duke.edu> Message-ID: On Fri, 25 Feb 2005 10:56:03 -0500, seth vidal wrote: > > Russia had lots of red hats in the eighties. I even wore one with my > > dress school uniform for pioneers day. :) > > damn commie ;) Hey, I'm switching distributions on my laptop. Seeing smiling half-naked athletic people holding and caressing each-other doesn't bring up the memories of saluting to a disembodied alabaster head. :) In fact, I'm not sure what memories it brings... ...hm. -- Konstantin Ryabitsev Zlotniks, INC From balay at fastmail.fm Fri Feb 25 18:52:37 2005 From: balay at fastmail.fm (Satish Balay) Date: Fri, 25 Feb 2005 12:52:37 -0600 (CST) Subject: system-config-network profiles and hard links In-Reply-To: References: Message-ID: On Fri, 25 Feb 2005, Neal Becker wrote: > I don't understand why system-config-network is creating new profiles using > hard links. AFAICT, this is totally broken on my FC3 system. Every time I > try to change an existing wireless profile, it seems to change them all. > Guess why? They are all hard linked together. > > For example: > ls -l /etc/sysconfig/networking/profiles/home/ > total 20 > -rw-r--r-- 1 root root 131 Feb 25 12:43 hosts > -rw-r--r-- 6 root root 349 Feb 25 12:43 ifcfg-eth1 > -rw------- 6 root root 15 Feb 25 12:43 keys-eth1 > -rw-r--r-- 1 root root 0 Feb 25 12:43 network > -rw-r--r-- 1 root root 92 Feb 25 12:43 resolv.conf > -rw-r--r-- 6 root root 120 Feb 25 12:43 route-eth1 > > Something is really wrong here. For one - this looks like a topic for fedora-list. And I think the current behavior is correct - because I (as a user) might want some devices with the SAME settings in all profiles. And to have different settings - you can make a 'copy' of the device [lets say eth0]- change settings in the copy. Now one profile will have - eth0 active - and the other will have eth0Copy0 active. [the nick-names can be changed from eth0/eth0Copy0 to more appropriate names] Satish From cmadams at hiwaay.net Fri Feb 25 19:08:29 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Feb 2005 13:08:29 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109355427.10989.39.camel@opus.phy.duke.edu> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> Message-ID: <20050225190829.GG1048932@hiwaay.net> Once upon a time, seth vidal said: > and I'm explaining that the 'package killing spree' as you so colorfully > have put it, is not anything new. > > it's happened in EVERY RELEASE. And as I've said, it didn't on such a large scale to things lots of people still used regularly. > It just wasn't discussed. > > which leads me to believe that, due to the reaction this time around, it > won't be discussed in the future. It'll just happen. So much for Fedora being an "open" project. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sta282 at astradyne.co.uk Fri Feb 25 19:09:26 2005 From: sta282 at astradyne.co.uk (Tet) Date: Fri, 25 Feb 2005 19:09:26 +0000 Subject: FC4 slimfast slimfest In-Reply-To: Your message of "Fri, 25 Feb 2005 01:50:32 CST." Message-ID: <200502251909.j1PJ9QTm020110@leto.astradyne.corp> Jason L Tibbitts III writes: >Debian shipped ssmtp for this purpose, but it and its replacement seem >to have been abandoned (and it didn't queue, which the author admits >as a problem). I suspect OpenBSD has something, because they seem to >have the same ideas as I do about needless functionality in general. OpenBSD has sendmail... Tet From skvidal at phy.duke.edu Fri Feb 25 19:15:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 14:15:12 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225190829.GG1048932@hiwaay.net> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> Message-ID: <1109358912.23111.1.camel@cutter> On Fri, 2005-02-25 at 13:08 -0600, Chris Adams wrote: >Once upon a time, seth vidal said: >> and I'm explaining that the 'package killing spree' as you so colorfully >> have put it, is not anything new. >> >> it's happened in EVERY RELEASE. > >And as I've said, it didn't on such a large scale to things lots of >people still used regularly. > >> It just wasn't discussed. >> >> which leads me to believe that, due to the reaction this time around, it >> won't be discussed in the future. It'll just happen. > >So much for Fedora being an "open" project. So maybe I'm confused here. Maybe I'm lost, but what the hell do you think I'm doing? do you think red hat is secretly paying me to do this stuff? B/c if they are then i missed the pay checks. open doesn't mean everyone's opinion is equal. it means there is a way to understand what's happening. But everytime someone brings up something on this list that is going to change the response is: NOOOOOOOOOOOOOOOOOOOOOOO IT CANNOT CHANGE. CHANGE IS BAD. DON'T CHANGE THINGS. and it gets old. why do you think fedora-maintainers is closed to posts from non-maintainers? -sv From tibbs at math.uh.edu Fri Feb 25 19:11:58 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 25 Feb 2005 13:11:58 -0600 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: <20050225123954.A4334@xos037.xos.nl> (Jos Vos's message of "Fri, 25 Feb 2005 12:39:54 +0100") References: <200502242238.j1OMcsO02013@xos037.xos.nl> <1109300719.10447.4.camel@one.myworld> <20050225123954.A4334@xos037.xos.nl> Message-ID: >>>>> "JV" == Jos Vos writes: JV> I would like to have all the XFCE 4.2.0 (and related) src.rpm JV> packages, that I saw two days ago on my ftp mirror, but then I was JV> so stupid to think they would be there today too... ;-). I have a local copy from a couple of days ago, which has these packages: xfce4-iconbox-4.2.0-1.src.rpm xfce4-panel-4.2.0-2.src.rpm xfce4-systray-4.2.0-1.src.rpm xfce-mcs-manager-4.2.0-1.src.rpm xfce-mcs-plugins-4.2.0-1.src.rpm xfce-utils-4.2.0-1.src.rpm Is that what you're looking for? If so, contact me privately and I'll give you a URL. - J< From buildsys at redhat.com Fri Feb 25 19:17:52 2005 From: buildsys at redhat.com (Build System) Date: Fri, 25 Feb 2005 14:17:52 -0500 Subject: rawhide report: 20050225 changes Message-ID: <200502251917.j1PJHq9T017295@porkchop.devel.redhat.com> New package fonts-japanese Free Japanese Bitmap/TrueType fonts New package fonts-korean Free Korean Bitmap/TrueType fonts New package python-numeric Numerical Extension to Python Updated Packages: SysVinit-2.85-37 ---------------- * Wed Feb 23 2005 Bill Nottingham - 2.85-37 - add patch for SELinux user configs () - disable readlink patch while it's being fixed aspell-bg-50:0.50-9 ------------------- * Thu Feb 24 2005 Ivana Varekova 50:0.50-8 - build new version (tarball 0.50-2), bug #142238 * Tue Oct 26 2004 Adrian Havill 50:0.50-4 - aspell already owns cp1251.dat (#137022) * Tue Oct 19 2004 Adrian Havill 50:0.50-3 - fix version in changelog; incorrect - fix corrupted word list; incorrect, wrong codeset (#128137) audit-0.6.4-1 ------------- * Wed Feb 23 2005 Steve Grubb 0.6.4-1 - Rename pam_audit to pam_loginuid to reflect what it does - Fix bug in detecting space left on partition - Fix bug in handling of suspended logging * Wed Feb 23 2005 David Woodhouse 0.6.3-3 - Include stdint.h in libaudit.h and require new glibc-kernheaders chkconfig-1.3.17-1 ------------------ * Tue Feb 22 2005 Bill Nottingham 1.3.17-1 - more chkconfig: vs. LSB fixes (#149066) dhcpv6-0.10-11_FC4 ------------------ flac-1.1.0-8 ------------ * Wed Feb 23 2005 Colin Walters 1.1.0-8 - New patch flac-1.1.0-gnu-stack.patch from Ulrich Drepper to mark asm as not requiring an executable stack gaim-1:1.1.4-1 -------------- * Thu Feb 24 2005 Warren Togami 1:1.1.4-1 - 1.1.4 with MSN crash fix, g_stat() crash workaround CAN-2005-0208 Gaim HTML parsing DoS (another one) gcc4-4.0.0-0.29 --------------- * Thu Feb 24 2005 Jakub Jelinek 4.0.0-0.29 - fix -Wmissing-braces in C++ (PR c++/20175) - fix PowerPC sCC splitters (PR target/20196) * Wed Feb 23 2005 Jakub Jelinek 4.0.0-0.28 - update from trunk - rename PowerPC IBM long double helper routines _xlq* to __gcc_*, but keep _xlq*@GCC_3.4 aliases around (#148841, PR target/19019) - make sure libjava GC memory is executable for libffi trampolines sake (#149348, PR libgcj/19823) - remove java abstract method check (#147968) - change __cxa_demangle to match cxx-abi change http://www.codesourcery.com/archives/cxx-abi-dev/msg01877.html (Jason Merrill, #133406) - fix ivopts (Zdenek Dvorak, PR tree-optimization/19937) - workaround ia64 BImode issues (Roger Sayle, PRs target/20018, rtl-optimization/20097) gimp-2:2.2.4-1 -------------- * Wed Feb 23 2005 Nils Philippsen - version 2.2.4 - require newer versions of gtk2 (#143840), glib2 and pango gimp-help-2-0.1.0.7.1 --------------------- * Wed Feb 23 2005 Nils Philippsen - version 2-0.7 glibc-kernheaders-2.4-9.1.90 ---------------------------- * Wed Feb 23 2005 David Woodhouse 2.4.9-1.90 - Add linux/audit.h im-sdk-1:12.1.1-3.svn2208 ------------------------- * Thu Feb 24 2005 Akira TAGOH - 1:12.1.1-3.svn2208 - update to svn2208. - removed iiimgcf-fix-gtk_im_context_reset.patch. * Thu Feb 17 2005 Akira TAGOH - iiimgcf-fix-gtk_im_context_reset.patch: applied to implement gtk_im_context_reset(). (#137398) * Wed Feb 09 2005 Akira TAGOH - 1:12.1.1-2.svn2191 - leif-sch_le_sun-fix-build.patch: applied to fix the build issue on x86-64. - leif-tch_le_sun-fix-build.patch: applied to fix the build issue on x86-64. iproute-2.6.10-1 ---------------- * Wed Feb 16 2005 Radek Vokal 2.6.10-1 - update to iproute-2.6.10 jadetex-3.12-12 --------------- * Wed Feb 23 2005 Tim Waugh 3.12-12 - Applied fixes from Ulrich Drepper to work with tetex3 (bug #111309). kernel-2.6.10-1.1153_FC4 ------------------------ * Thu Feb 24 2005 Dave Jones - 2.6.11-rc5 * Wed Feb 23 2005 Rik van Riel - get rid of unknown symbols in kernel-xen0 (#149495) * Wed Feb 23 2005 Dave Jones - 2.6.11-rc4-bk11 kudzu-1.1.109-1 --------------- * Thu Feb 24 2005 Bill Nottingham 1.1.109-1 - use synaptics for ALPS touchpad (#149619, ) libselinux-1.21.11-1 -------------------- * Tue Feb 22 2005 Dan Walsh 1.21.11-1 - Update from NSA * Merged several fixes from Ulrich Drepper. libsepol-1.3.6-1 ---------------- * Thu Feb 17 2005 Dan Walsh 1.3.6-1 - Update to latest from NSA * Changed sepol_genusers to also use getline and correctly handle EOL. * Thu Feb 17 2005 Dan Walsh 1.3.5-1 - Update to latest from NSA * Merged endianness and compute_av patches from Darrel Goeddel (TCS). * Merged range_transition support from Darrel Goeddel (TCS). * Added sepol_genusers function. * Thu Feb 10 2005 Dan Walsh 1.3.2-1 - Update to latest from NSA * Changed relabel Makefile target to use restorecon. linuxdoc-tools-0.9.21-4 ----------------------- * Thu Feb 24 2005 Tim Waugh 0.9.21-4 - Another try at bug #149588. * Thu Feb 24 2005 Tim Waugh 0.9.21-2 - Jindrich Novy's mapping fix (bug #149588). lockdev-1.0.1-6 --------------- * Wed Feb 23 2005 Karel Zak 1.0.1-5 - lockdev errs on /dev/input/ttyACM0 (3-component pathname) (#126082, #98160, #74454) man-pages-ja-20050215-1 ----------------------- * Wed Feb 23 2005 Akira TAGOH - 20050215-1 - updates to 20050215. - fixed wrong argument type and structure member variable type in shmget(2) (#149217) net-snmp-5.2.1-3 ---------------- * Wed Feb 23 2005 Radek Vokal - 5.1.2-3 - patch from CVS - kill extra carriage return (#144917) - removed patch for interface indexing - doesn't show virtual interfaces nfs-utils-1.0.7-1 ----------------- policycoreutils-1.21.19-4 ------------------------- * Wed Feb 23 2005 Dan Walsh 1.21.19-4 - Fix genhomedircon to handle root - Fix fixfiles to better handle file system types * Wed Feb 23 2005 Dan Walsh 1.21.19-2 - Fix genhomedircon to handle spaces in SELINUXPOLICYTYPE * Tue Feb 22 2005 Dan Walsh 1.21.19-1 - Update to latest from NSA * Merged several fixes from Ulrich Drepper. rpmdb-fedora-1:4-0.20050225 --------------------------- samba-0:3.0.11-4 ---------------- * Thu Feb 24 2005 Jay Fenlason 3.0.11-4 - Use the updated filter-requires-samba.sh file, so we don't accidentally pick up a dependency on perl(Crypt::SmbHash) * Fri Feb 18 2005 Jay Fenlason 3.0.11-3 - add -gcc4 patch to compile with gcc 4. - remove the now obsolete -smbclient-kerberos.patch - Include four upstream patches from http://samba.org/~jerry/patches/post-3.0.11/ (Slightly modified the winbind_find_dc_v2 patch to apply easily with rpmbuild). * Fri Feb 04 2005 Jay Fenlason 3.0.11-2 - include -smbspool patch to close bz#104136 selinux-policy-strict-1.21.14-4 ------------------------------- * Wed Feb 23 2005 Dan Walsh 1.21.14-4 - Lots of fix patches from Ivan * Mon Feb 21 2005 Dan Walsh 1.21.14-3 - Lots of fix patches from Ivan selinux-policy-targeted-1.21.14-4 --------------------------------- * Wed Feb 23 2005 Dan Walsh 1.21.14-4 - Lots of fix patches from Ivan sysklogd-1.4.1-26_FC4 --------------------- urw-fonts-2.2-8 --------------- * Thu Feb 24 2005 Than Ngo 2.2-8 - update to 1.0.7pre40 * Thu Feb 24 2005 Than Ngo 2.2-7 - change descender/ascender in "NimbusMonL" #140584 vnc-4.0-14 ---------- * Wed Feb 23 2005 Tim Waugh 4.0-14 - Render support from Peter ??strand. * Thu Feb 03 2005 Tim Waugh - Don't restart the vncserver service on upgrade. w3c-libwww-5.4.0-12 ------------------- * Thu Feb 24 2005 Harald Hoyer - 5.4.0-12 - built with ssl xen-2-20050222 -------------- * Wed Feb 23 2005 Rik van Riel 2-20050222 - upgraded to last night's Xen snapshot - compile warning fixes are now upstream, drop patch xmlsec1-1.2.7-1 --------------- * Wed Feb 23 2005 Daniel Veillard 1.2.7-1 - Upstream release of 1.2.7, mostly bug fixes plus new functions to GetKeys from simple store and X509 handling. yum-2.3.0-2 ----------- * Tue Feb 22 2005 Jeremy Katz - 2.3.0-2 - fix the duplicate repos with the same id bug From skvidal at phy.duke.edu Fri Feb 25 19:24:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 14:24:49 -0500 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: References: <200502242238.j1OMcsO02013@xos037.xos.nl> <1109300719.10447.4.camel@one.myworld> <20050225123954.A4334@xos037.xos.nl> Message-ID: <1109359489.23111.5.camel@cutter> On Fri, 2005-02-25 at 13:11 -0600, Jason L Tibbitts III wrote: >>>>>> "JV" == Jos Vos writes: > >JV> I would like to have all the XFCE 4.2.0 (and related) src.rpm >JV> packages, that I saw two days ago on my ftp mirror, but then I was >JV> so stupid to think they would be there today too... ;-). > >I have a local copy from a couple of days ago, which has these >packages: > >xfce4-iconbox-4.2.0-1.src.rpm >xfce4-panel-4.2.0-2.src.rpm >xfce4-systray-4.2.0-1.src.rpm >xfce-mcs-manager-4.2.0-1.src.rpm >xfce-mcs-plugins-4.2.0-1.src.rpm >xfce-utils-4.2.0-1.src.rpm > >Is that what you're looking for? If so, contact me privately and I'll >give you a URL. or you could just check out xfce from cvs.fedora.redhat.com and run 'make srpm' in the fc3 or devel directories. -sv From nutello at sweetness.com Fri Feb 25 19:33:14 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Fri, 25 Feb 2005 20:33:14 +0100 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225190829.GG1048932@hiwaay.net> References: <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> Message-ID: <20050225193314.GC15224@plain.rackshack.net> On Fri, Feb 25, 2005 at 01:08:29PM -0600, Chris Adams wrote: > And as I've said, it didn't on such a large scale to things lots of > people still used regularly. Plus, most of the time they were marked as obsolete/deprecated one or two releases before the actual removal. > So much for Fedora being an "open" project. This is mostly going to give fodder to critics. If it is indeed the plan to basically ignore any of the consequences of the "mass Core eviction", I'd suggest littering the release notes, the installer and the first boot with warnings about the problems that might arise and the proper way to address them. They need to be in big, flashing, red letters. FC3 release notes covered the subject, but people are still inquiring about the kernel-source package. -- Rudi From sta282 at astradyne.co.uk Fri Feb 25 19:44:17 2005 From: sta282 at astradyne.co.uk (Tet) Date: Fri, 25 Feb 2005 19:44:17 +0000 Subject: XFCE packages gone? In-Reply-To: Your message of "Thu, 24 Feb 2005 19:53:21 EST." Message-ID: <200502251944.j1PJiHoa020239@leto.astradyne.corp> Konstantin Ryabitsev writes: >> Why did the XFCE packages disappear from rawhide? > >Read the last 512 messages sent to the list. Sheesh. :) You have a point. But at the same time, there are still unanswered questions. Who made the final decision about which packages were to go? Bill Nottingham? Elliot? Someone else? What was the rationale for their selection -- space saving, obviously, but why package A rather than package B? Although I personally disagree with some of the choices[1], I don't see anything going that is critical to be in Core (although see below). But it would be nice to know who made the decisions, and the reasons they made them. Something that needs to be addressed formally at some point, though, is the line between Core and Extras and where it's drawn. The stated objective is for Core to provide "a complete general-purpose operating system". There is no equivalent statement of intent regarding Extras. It would seem logical to have the objectives be something like: Core: A general purpose OS with the functionality required by the majority of end users. Core + Extras: A complete general purpose OS, with extra functionality used by niche groups, and alternate packages that provide similar functionality to the defaults in Core. Thus a package could be measured against those objectives to help decide whether it belonged in Core or Extras. It's probably too late to do this for FC4, but it should be seriously considered for FC5. Tet [1] The list includes 4 apps (gnumeric, abiword, gv and aumix) that I use on a fairly regular basis. Personally, I think OO.o should have been removed, but I realise I'm in the minority there... From dwmw2 at infradead.org Fri Feb 25 19:46:46 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 25 Feb 2005 19:46:46 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109358912.23111.1.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> Message-ID: <1109360807.26364.217.camel@localhost.localdomain> On Fri, 2005-02-25 at 14:15 -0500, seth vidal wrote: >So maybe I'm confused here. Maybe I'm lost, but what the hell do you >think I'm doing? Mostly being a muppet, since you ask. >But everytime someone brings up something on this list that is going to >change the response is: >NOOOOOOOOOOOOOOOOOOOOOOO IT CANNOT CHANGE. CHANGE IS BAD. DON'T CHANGE >THINGS. That's a very disingenuous misstatement of what people have asked for. A more honest summary would be: "Don't make this change so hastily -- since we can do this properly in FC5, please let's do it then, when Extras is workable". -- dwmw2 From skvidal at phy.duke.edu Fri Feb 25 19:55:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 14:55:34 -0500 Subject: XFCE packages gone? In-Reply-To: <200502251944.j1PJiHoa020239@leto.astradyne.corp> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> Message-ID: <1109361334.23111.14.camel@cutter> On Fri, 2005-02-25 at 19:44 +0000, Tet wrote: >Konstantin Ryabitsev writes: > >>> Why did the XFCE packages disappear from rawhide? >> >>Read the last 512 messages sent to the list. Sheesh. :) > >You have a point. But at the same time, there are still unanswered >questions. Who made the final decision about which packages were to >go? Bill Nottingham? Elliot? Someone else? What was the rationale >for their selection -- space saving, obviously, but why package A >rather than package B? Although I personally disagree with some >of the choices[1], I don't see anything going that is critical >to be in Core (although see below). But it would be nice to know >who made the decisions, and the reasons they made them. The Fedora Core Technical Committee made the decisions. That's Cristian Gafton, Jeremy Katz, Elliot Lee and Bill Nottingham. I know you're unlikely to accept this but could we go with 'b/c these guys have been doing this for a long time so trust them'. Hell, I'm unlikely to accept this but despite what most people think - fedora is not a place where everyone's opinion is equal. The opinions of specific people at red hat count for a lot more. Right now the process is such that getting more say in fedora means doing more work. How do you go about doing more work you ask? Step up, and genuinely offer, you'll find plenty to do. -sv From skvidal at phy.duke.edu Fri Feb 25 19:58:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 14:58:14 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109360807.26364.217.camel@localhost.localdomain> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> Message-ID: <1109361494.23111.18.camel@cutter> On Fri, 2005-02-25 at 19:46 +0000, David Woodhouse wrote: >On Fri, 2005-02-25 at 14:15 -0500, seth vidal wrote: >>So maybe I'm confused here. Maybe I'm lost, but what the hell do you >>think I'm doing? > >Mostly being a muppet, since you ask. A muppet? wow. Jim Henson's intellectual property aside, who do you think is doing the controlling? Got a good theory for me? >>But everytime someone brings up something on this list that is going to >>change the response is: >>NOOOOOOOOOOOOOOOOOOOOOOO IT CANNOT CHANGE. CHANGE IS BAD. DON'T CHANGE >>THINGS. > >That's a very disingenuous misstatement of what people have asked for. A >more honest summary would be: > >"Don't make this change so hastily -- since we can do this properly in >FC5, please let's do it then, when Extras is workable". That's a very disingenuous statement too. I think extras is workable now. If it's not I wonder what I've been building every night for the past N weeks. -sv From aoliva at redhat.com Fri Feb 25 19:57:30 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Feb 2005 16:57:30 -0300 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109358912.23111.1.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> Message-ID: On Feb 25, 2005, seth vidal wrote: > why do you think fedora-maintainers is closed to posts from > non-maintainers? Because someone wasn't in their right mind when this idea came up? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From notting at redhat.com Fri Feb 25 20:02:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Feb 2005 15:02:40 -0500 Subject: XFCE packages gone? In-Reply-To: <200502251944.j1PJiHoa020239@leto.astradyne.corp> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> Message-ID: <20050225200240.GC25441@nostromo.devel.redhat.com> Tet (sta282 at astradyne.co.uk) said: > >Read the last 512 messages sent to the list. Sheesh. :) > > You have a point. But at the same time, there are still unanswered > questions. Who made the final decision about which packages were to > go? Bill Nottingham? Elliot? Someone else? What passes for the Technical Committee made the decisions via consensus; there was a meeting a couple of days ago. > What was the rationale > for their selection -- space saving, obviously, but why package A > rather than package B? http://fedoraproject.org/wiki/Extras_2fCoreVsExtras is a short description of some of the criteria uses. Applying this to the deletions: - aumix: replaced by alsamixer/amixer/etc - abiword/gnumeric/koffice: office suite work is concentrated on OOo - xemacs: duplicate of Emacs functionality - cfengine: not Core functionality, not used by anything in Core - gv/ggv/gpdf: duplicate of functionality of evince/kpdf/etc - tuxracer/bzflag: games - octave/lapack: not Core functionality - XFCE: duplicate functionality with respect to GNOME, KDE, etc - exim: duplicate functionality with respect to postfix, sendmail; it has been in Core less than postfix, sendmail, and isn't as SELinux-able as postfix Honestly, if Extras was launched before FC2, I doubt that XFCE would have been in Core to begin with. These criteria have been used in past releases for various packages as well; see removals of devlabel, quanta, licq, chromium, printman, etc. in FC3, gtoaster, xtraceroute, mars-nwe, nmh, imap, etc. in FC2. We're currently investigating how trademarks relate to spins of ISOs from Extras, especially if ISOs aren't done on the FTP site. Once there's some clarification there, it would be *easy* to write short scripts, etc. to generate ISOs of Extras subsets, and I suspect that would be done. Bill From feliciano.matias at free.fr Fri Feb 25 20:07:25 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 25 Feb 2005 21:07:25 +0100 Subject: XFCE packages gone? In-Reply-To: <200502251944.j1PJiHoa020239@leto.astradyne.corp> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> Message-ID: <1109362045.19156.0.camel@one.myworld> Le vendredi 25 f?vrier 2005 ? 19:44 +0000, Tet a ?crit : > Who made the final decision about which packages were to > go? Bill Nottingham? Elliot? Someone else? http://fedora.redhat.com/about/leadership.html -------------- 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 eric at snowmoon.com Fri Feb 25 20:07:46 2005 From: eric at snowmoon.com (Eric Warnke) Date: Fri, 25 Feb 2005 15:07:46 -0500 (EST) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109355545.10989.41.camel@opus.phy.duke.edu> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> Message-ID: <20050225144841.S98262@malkav.snowmoon.com> On Fri, 25 Feb 2005, seth vidal wrote: >> I think everyone wants the same things, to make sure FC4 does not turn >> into an end user nightmare. Personally my vote would be for 5 cd's until >> a true fix can be applied rather than a last minute pulling of packages. >> But seeing as that may not be happening. > > That's been true forever if you EVER installed a former release and > either: > 1. had ANY package removed which you used (lprng anyone?) lprng was never part of core ( afaict ) > 2. ever installed something from fedora.us, freshrpms, dagrpms, atrpms, I don't install things from fedora.us, freshrpms, dag, ... if I need something outside core I rebuild it, test it and deploy it in a local repo. I don't think it's unreasonable to let the user know that they are breaking there system in anaconda. But that's not the point. FC1 was 3 discs, FC2 was 4 discs and there was a grand total of 21 packages removed ( list below ) and 128 additional packages. FC3 was 4 discs as well and there were 53 packages removed from the system ( list below ) and 78 additions. Of these packages removed MOST were because java was pulled and therefore the associated packages were also pulled. Looking at these lists it's clear that the vast majority of these packages were removed because or age, or neglect. In contrast, with this round of cuts you are asking for and removing packages that are not neglected or obsolete but packages at that are regularly used by members of this list. I don't think it's outragious of the community to ask why those packages have been removed with such haste? Why a 5 disc FC4 is such a problem? Why not better inform the user with anaconda? Might I remind RedHat that they floated the question to the community without any standards of what or why. No attempt has been made to clarify the exact ammount of space that need to be made up. No one has attempted to bzip2 packages that might save space. Between suggestions already made we could reduce the overage by half. Careful inspection of the packages could reveal more dead packages and then larger items could be examined for cutting. Cheers, Eric Packages removed from FC2 -Xbae -Xlt -ami -bonobo-conf -boost-jam -cipe -gnome-vfs2-extras -imap -indexhtml -kdoc -kpppload -libcapplet0 -libgtop -libmrproject -mars-nwe -mrproject -nmh -run -xawtv -xcpustate -xtraceroute Packages removed from FC3 -Gtk-Perl -Wnn6-SDK -ac-archive -ant -aspell-pt_BR -bcel -bluez-pan -bluez-sdp -chromium -commons-beanutils -commons-collections -commons-dbcp -commons-digester -commons-fileupload -commons-logging -commons-modeler -commons-pool -cup -dvdrtools -glade -gqview -gtkam -gtkglarea -hwcrypto -iiimf-le-inpinyin -iscsi -jaf -jakarta-regexp -javamail -junit -libole2 -librep -licq -linc -mx4j -mysql-jdbc -njamd -pidentd -pilot-link095-compat -python-optik -quanta -redhat-java-rpm-scripts -rep-gtk -sawfish -servletapi -shapecfg -struts -system-config-proc -tomcat -unarj -xalan-j -xerces-j From skvidal at phy.duke.edu Fri Feb 25 20:15:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 15:15:22 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> Message-ID: <1109362522.23111.24.camel@cutter> On Fri, 2005-02-25 at 16:57 -0300, Alexandre Oliva wrote: >On Feb 25, 2005, seth vidal wrote: > >> why do you think fedora-maintainers is closed to posts from >> non-maintainers? > >Because someone wasn't in their right mind when this idea came up? it was decided by a group of red hat and non red hat fedora contributors at the pre-fudcon meetings. Mostly to keep the signal/noise ratio down. As you can see by this weeks output on f-d-l it's hard to get very far with everyone posting even if they don't have much of a dog in the fight. -sv From fedora at wir-sind-cool.org Fri Feb 25 20:28:31 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 25 Feb 2005 21:28:31 +0100 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225144841.S98262@malkav.snowmoon.com> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> <20050225144841.S98262@malkav.snowmoon.com> Message-ID: <20050225212831.4dc99849.fedora@wir-sind-cool.org> On Fri, 25 Feb 2005 15:07:46 -0500 (EST), Eric Warnke wrote: > In contrast, with this round of cuts you are asking for and removing > packages that are not neglected or obsolete but packages at that are > regularly used by members of this list. That's _the_ opportunity for such members to step forward and maintain the packages in Fedora Extras, provided that the previous maintainer at Red Hat hasn't planned to do that. > No one has attempted to bzip2 packages that > might save space. I remember a long discussion about time/space tradeoffs. bzip2 uncompression is a lot slower than gzip. From feliciano.matias at free.fr Fri Feb 25 20:29:22 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 25 Feb 2005 21:29:22 +0100 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225144841.S98262@malkav.snowmoon.com> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> <20050225144841.S98262@malkav.snowmoon.com> Message-ID: <1109363362.19156.5.camel@one.myworld> Le vendredi 25 f?vrier 2005 ? 15:07 -0500, Eric Warnke a ?crit : > I don't think it's outragious of the community to ask why those packages > have been removed with such haste? Why a 5 disc FC4 is such a problem? > Why not better inform the user with anaconda? Might I remind RedHat that > they floated the question to the community without any standards of what > or why. No attempt has been made to clarify the exact ammount of space > that need to be made up. Already lengthily discussed here (fedora-devel). -------------- 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 fedora at wir-sind-cool.org Fri Feb 25 20:35:30 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 25 Feb 2005 21:35:30 +0100 Subject: XFCE packages gone? In-Reply-To: <20050225200240.GC25441@nostromo.devel.redhat.com> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <20050225200240.GC25441@nostromo.devel.redhat.com> Message-ID: <20050225213530.4503d8f0.fedora@wir-sind-cool.org> On Fri, 25 Feb 2005 15:02:40 -0500, Bill Nottingham wrote: > http://fedoraproject.org/wiki/Extras_2fCoreVsExtras As a side-note, there's something odd in the Wiki implementation which creates such less readable links. This one is better: http://fedoraproject.org/wiki/Extras/CoreVsExtras > Honestly, if Extras was launched before FC2, I doubt that XFCE would > have been in Core to begin with. Actually, work at including XFCE in fedora.us had started only a month before XFCE appeared in Rawhide all of a sudden. From sta282 at astradyne.co.uk Fri Feb 25 20:43:17 2005 From: sta282 at astradyne.co.uk (Tet) Date: Fri, 25 Feb 2005 20:43:17 +0000 Subject: XFCE packages gone? In-Reply-To: Your message of "Fri, 25 Feb 2005 14:55:34 EST." <1109361334.23111.14.camel@cutter> Message-ID: <200502252043.j1PKhHw2020470@leto.astradyne.corp> seth vidal writes: >I know you're unlikely to accept this but could we go with 'b/c these >guys have been doing this for a long time so trust them'. Actually, I can't think of a better reason for someone to be in a position to be making that sort of decision, and now that Bill's given some rationale for the removal of at least some of the packages, I'm relatively happy (or I will be when the removed packages show up in Extras). Tet From michael.favia at insitesinc.com Fri Feb 25 20:49:17 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 25 Feb 2005 14:49:17 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109362522.23111.24.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> Message-ID: <421F8F4D.1030600@insitesinc.com> seth vidal wrote: >Mostly to keep the signal/noise ratio down. > > Sounds awful elitist and Machiavellian for a community driven project. >As you can see by this weeks output on f-d-l it's hard to get very far >with everyone posting even if they don't have much of a dog in the >fight. > > I agree, but then you are just granting the illusion of a community controlled project arent you? Essentially the real discussion concerning dev will have been moved to f-m right? I understand that trying to keep the project moving without all of this "change is bad" and "me too" crap is important but i think that this "fix" fails to live up to the community aspect of the project doesnt it? Essentially your voice doesnt matter if you arent a maintainer anymore because the other lists will be read less and less by RH and maintainers over time. As a result you will lose the community driven nature i think because all of the opinions batted about will be those of maintainers alone. A moderated white list of users that conduct themselves in a prescribed manner makes most sense to me. -mf From michael.favia at insitesinc.com Fri Feb 25 20:53:41 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 25 Feb 2005 14:53:41 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F8F4D.1030600@insitesinc.com> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> Message-ID: <421F9055.6030401@insitesinc.com> Michael Favia wrote: > I agree, but then you are just granting the illusion of a community > controlled project arent you? Please replace "controlled" with "driven". i have no illusions of grandure for the community place nor do i think it is desirable. :). -mf From skvidal at phy.duke.edu Fri Feb 25 21:04:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:04:29 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F8F4D.1030600@insitesinc.com> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> Message-ID: <1109365469.23111.35.camel@cutter> On Fri, 2005-02-25 at 14:49 -0600, Michael Favia wrote: >seth vidal wrote: > >>Mostly to keep the signal/noise ratio down. >> >> >Sounds awful elitist and Machiavellian for a community driven project. It does? Who do I represent? I think I am a member of 'the community'? I think Jeremy and Bill and Elliot are too. I think they're members of the contributing community. It's not elitistism it's based on listening to the people who are doing the work. In large projects if you listen to everyone you can never get any work done. So you listen to the people are contributing. I don't think that's particularly crazy. Show me an open source project that is NOT like that. This is not a democracy - I hope it's a meritocracy - but in reality it's something more like 'those people who do the work get listened to'-ocracy. Do the work, see how many people listen. They may not agree - but they'll listen. >I agree, but then you are just granting the illusion of a community >controlled project arent you? Essentially the real discussion concerning >dev will have been moved to f-m right? I understand that trying to keep >the project moving without all of this "change is bad" and "me too" crap >is important but i think that this "fix" fails to live up to the >community aspect of the project doesnt it? Essentially your voice doesnt >matter if you arent a maintainer anymore because the other lists will be >read less and less by RH and maintainers over time. As a result you will >lose the community driven nature i think because all of the opinions >batted about will be those of maintainers alone. A moderated white list >of users that conduct themselves in a prescribed manner makes most sense >to me. Then tell me how else you do it? How to cull the signal from the noise? show me a better way and we'll get there lickety-damn-split. -sv From eric at snowmoon.com Fri Feb 25 21:00:28 2005 From: eric at snowmoon.com (Eric Warnke) Date: Fri, 25 Feb 2005 16:00:28 -0500 (EST) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F9055.6030401@insitesinc.com> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <421F9055.6030401@insitesinc.com> Message-ID: <20050225155313.O98262@malkav.snowmoon.com> On Fri, 25 Feb 2005, Michael Favia wrote: > Michael Favia wrote: > >> I agree, but then you are just granting the illusion of a community >> controlled project arent you? > > Please replace "controlled" with "driven". i have no illusions of grandure > for the community place nor do i think it is desirable. :). > -mf May I remind you of the Fedora "contract" http://fedora.redhat.com/about/objectives.html Specifically I think this discussion touches on points 1, 6, 7, and 12. Cheers, Eric Warnke Systems Administrator - Research Technology SUNY at Albany From skvidal at phy.duke.edu Fri Feb 25 21:08:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:08:34 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109365469.23111.35.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> Message-ID: <1109365714.23111.38.camel@cutter> >Then tell me how else you do it? How to cull the signal from the noise? > >show me a better way and we'll get there lickety-damn-split. one more addendum - just b/c discussion about decisions in the distro and extras should go to fedora-maintainers doesn't mean I'll stop reading fedora-devel. Hopefully it will mean fedora-devel will become more useful. -sv From czar at czarc.net Fri Feb 25 21:35:44 2005 From: czar at czarc.net (Gene C.) Date: Fri, 25 Feb 2005 16:35:44 -0500 Subject: XFCE packages gone? In-Reply-To: <1109361334.23111.14.camel@cutter> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <1109361334.23111.14.camel@cutter> Message-ID: <200502251635.44955.czar@czarc.net> On Friday 25 February 2005 14:55, seth vidal wrote: > The Fedora Core Technical Committee made the decisions. ?That's Cristian > Gafton, Jeremy Katz, Elliot Lee and Bill Nottingham. > > I know you're unlikely to accept this but could we go with 'b/c these > guys have been doing this for a long time so trust them'. Yes, I trust their descisions. At one time with Red Hat Linux there was a companion CD called "Powertools" which had some extra stuff useful to many but not part of the Red Hat Linux core. Then many (not all) Powertools packages were merged into the distribution and the rest were dropped to be handled by others. Maybe we need to segment Fedora Extras into two parts. There are lots and lots of packages in Fedora Extras and to expect all of those to be thoroughly tested with a new distribution is more that a bit optimistic. Maybe if there was a "Extras 1" which had the packages removed from core as well as some others from the current Extras and then the rest of the current Extras packages into "Extras 2", this could be made more managable. "Extras 1" could be the 5th CD (or even 5th and 6th CDs) and not increase the size of the Core distribution while providing a collection useful to many. "Extras 1" would have a real push to be tested with the Core and any problems resolved but "Extras 2" would continue with the current process. -- Gene From ph18 at cornell.edu Fri Feb 25 21:40:05 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Fri, 25 Feb 2005 16:40:05 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225212831.4dc99849.fedora@wir-sind-cool.org> References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> <20050225144841.S98262@malkav.snowmoon.com> <20050225212831.4dc99849.fedora@wir-sind-cool.org> Message-ID: On Fri, 25 Feb 2005 21:28:31 +0100, Michael Schwendt wrote: > > That's _the_ opportunity for such members to step forward and maintain > the > packages in Fedora Extras, provided that the previous maintainer at Red > Hat hasn't planned to do that. > Yeah, but if there is some software package I like, I'm more inclined to install it from source rather than to screw around with rpms... Be that finding a prebuilt one that's six months out of date or going through the extra bother to generate rpms. I've built rpms before, but the question I'd have then is what would be expected of me if I ~were~ to maintain a package myself. It's easy for me to test on AMD64 and (possibly) x86, but I'm not going to be able to support a package for the Itanic. >> No one has attempted to bzip2 packages that >> might save space. > > I remember a long discussion about time/space tradeoffs. bzip2 > uncompression is a lot slower than gzip. > On newer computers (>1 GhZ) I think that the installation time is more determined by the speed of the I/O system than the speed of the CPU. bzip might actually help. From skvidal at phy.duke.edu Fri Feb 25 21:50:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:50:06 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> <20050225144841.S98262@malkav.snowmoon.com> <20050225212831.4dc99849.fedora@wir-sind-cool.org> Message-ID: <1109368206.23111.56.camel@cutter> > Yeah, but if there is some software package I like, I'm more inclined >to install it from source rather than to screw around with rpms... Be >that finding a prebuilt one that's six months out of date or going through >the extra bother to generate rpms. > > I've built rpms before, but the question I'd have then is what would be >expected of me if I ~were~ to maintain a package myself. It's easy for me >to test on AMD64 and (possibly) x86, but I'm not going to be able to >support a package for the Itanic. That's not expected. Maintainers are expected to: - keep the package building on whatever they can and solicit help from people running on minority platforms for testing - monitor the software for updates and security issues - stay current with the expected and intended use for the package - keep abreast of licensing issues with the package. - keep the packaging guidelines applied and cleanly implemented in the package. -sv From richardl at redhat.com Fri Feb 25 21:46:37 2005 From: richardl at redhat.com (Richard Li) Date: Fri, 25 Feb 2005 16:46:37 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <20050224222530.GQ11644@nostromo.devel.redhat.com> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <20050225145325.GB1048932@hiwaay.net> <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> <20050225144841.S98262@malkav.snowmoon.com> <20050225212831.4dc99849.fedora@wir-sind-cool.org> Message-ID: <421F9CBD.60105@redhat.com> >>> No one has attempted to bzip2 packages that >>> might save space. >> >> I remember a long discussion about time/space tradeoffs. bzip2 >> uncompression is a lot slower than gzip. > > On newer computers (>1 GhZ) I think that the installation time is > more determined by the speed of the I/O system than the speed of the > CPU. bzip might actually help. I believe that switching would increase the minimum memory requirements for Anaconda. From jspaleta at gmail.com Fri Feb 25 21:49:58 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Feb 2005 16:49:58 -0500 Subject: XFCE packages gone? In-Reply-To: <200502251635.44955.czar@czarc.net> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <1109361334.23111.14.camel@cutter> <200502251635.44955.czar@czarc.net> Message-ID: <604aa7910502251349d42762f@mail.gmail.com> On Fri, 25 Feb 2005 16:35:44 -0500, Gene C. wrote: > "Extras 1" could be the 5th CD (or even 5th and 6th CDs) and not increase the > size of the Core distribution while providing a collection useful to many. > > "Extras 1" would have a real push to be tested with the Core and any problems > resolved but "Extras 2" would continue with the current process. or how about if quality is a significant issue with any extras package... we punt it right the hell out of extras completely. I see no benefit to drawing a line in the sand inside extras based on quality. Its either good enough or not good enough. My understanding is there will be a 'extras testing' branch similar to 'core updates-testing' for some packages that need extra love and testing to linger if need be. If packages in extras aren't rebuilding cleanly by the time fc4 gets released or have 'major' unresolved problems.. those packages don't hit the release tree for extras as targetted against fc4. And we do this case by case IF there is a problem. So as a tester of rawhide... i encourage you to eat extras development as soon as it spins up some binaries "any day now." -jef" if core development is rawhide is extras development rawmeat?"spaleta From skvidal at phy.duke.edu Fri Feb 25 21:56:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 16:56:47 -0500 Subject: XFCE packages gone? In-Reply-To: <200502251635.44955.czar@czarc.net> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <1109361334.23111.14.camel@cutter> <200502251635.44955.czar@czarc.net> Message-ID: <1109368607.23111.62.camel@cutter> >At one time with Red Hat Linux there was a companion CD called "Powertools" >which had some extra stuff useful to many but not part of the Red Hat Linux >core. Then many (not all) Powertools packages were merged into the >distribution and the rest were dropped to be handled by others. > >Maybe we need to segment Fedora Extras into two parts. There are lots and >lots of packages in Fedora Extras and to expect all of those to be thoroughly >tested with a new distribution is more that a bit optimistic. Maybe if there >was a "Extras 1" which had the packages removed from core as well as some >others from the current Extras and then the rest of the current Extras >packages into "Extras 2", this could be made more managable. > >"Extras 1" could be the 5th CD (or even 5th and 6th CDs) and not increase the >size of the Core distribution while providing a collection useful to many. > >"Extras 1" would have a real push to be tested with the Core and any problems >resolved but "Extras 2" would continue with the current process. it probably makes sense to keep them all together and try to make it work there. If things get screwed up then we can fall back to that position - but setting up like you've described sounds more like a proposition for failure. -sv From cra at WPI.EDU Fri Feb 25 22:20:33 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 25 Feb 2005 17:20:33 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050225144841.S98262@malkav.snowmoon.com> References: <1109344125.10989.0.camel@opus.phy.duke.edu> <1109346448.26364.177.camel@localhost.localdomain> <1109347191.621.2.camel@chip.laiskiainen.org> <1109347412.26364.185.camel@localhost.localdomain> <1109347888.10989.20.camel@opus.phy.duke.edu> <20050225161927.GC1048932@hiwaay.net> <604aa7910502250836415a5f6e@mail.gmail.com> <20050225114242.P98262@malkav.snowmoon.com> <1109355545.10989.41.camel@opus.phy.duke.edu> <20050225144841.S98262@malkav.snowmoon.com> Message-ID: <20050225222033.GY28055@angus.ind.WPI.EDU> On Fri, Feb 25, 2005 at 03:07:46PM -0500, Eric Warnke wrote: > lprng was never part of core ( afaict ) LPRng was in Red Hat Linux 9 and earlier. > I don't install things from fedora.us, freshrpms, dag, ... if I need > something outside core I rebuild it, test it and deploy it in a local > repo. I don't think it's unreasonable to let the user know that they are > breaking there system in anaconda. Anaconda won't upgrade your self-built packages, then. It won't remove them, either. Same as the packages removed from FC4. > or why. No attempt has been made to clarify the exact ammount of space > that need to be made up. No one has attempted to bzip2 packages that > might save space. Between suggestions already made we could reduce the > overage by half. Careful inspection of the packages could reveal more > dead packages and then larger items could be examined for cutting. You could do this. Anyone who cared enough could. From rjune at bravegnuworld.com Fri Feb 25 22:25:19 2005 From: rjune at bravegnuworld.com (Richard June) Date: Fri, 25 Feb 2005 17:25:19 -0500 Subject: Why is sendmail bad? In-Reply-To: <20050224204245.GA17728@yoda.jdub.homelinux.org> References: <200502241504.44676.rjune@bravegnuworld.com> <20050224204245.GA17728@yoda.jdub.homelinux.org> Message-ID: <200502251725.22843.rjune@bravegnuworld.com> On Thursday 24 February 2005 15:42, Josh Boyer wrote: > On Thu, Feb 24, 2005 at 03:04:40PM -0500, Richard June wrote: > > On Thursday 24 February 2005 14:53, Josh Boyer wrote: > > > On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote: > > > > There seems to be a lot of dissatisfaction with sendmail in the call > > > > to replace it with Exim or Postfix, but I didn't see any specifics > > > > about why people object to it. Anyone care to give details? > > > > > > Most of the discusion has been about what should be the default. For > > > "newbies" sendmail can be a pain to configure. It's documentation > > > leaves something to be desired, and the default sendmail.cf file isn't > > > all that helpful. > > > > > > That's not to say that sendmail isn't useful or does't work properly. > > > It does. But if a package is going to be the default for a > > > distribution, it should also be fairly simple for new users to > > > configure and adapt to. > > > > I take issue to that. sendmail has always been *TONS* easier for me to > > configure then postfix/exim. the sendmail.mc file is simple to understand > > and edit. > > I guess we'll have to agree to disagree. Anything that requires using m4 > after editing a config file isn't intuitive IMHO. edit the config file, run service sendmail restart. all done. you don't have to run m4 manually, the sendmail initscript does that for you. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mpeters at mac.com Sat Feb 26 00:49:31 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 26 Feb 2005 00:49:31 +0000 Subject: FC4 slimfast slimfest In-Reply-To: <1109191955.6581.78.camel@pensja.lam.pl> (from Lam@Lam.pl on Wed Feb 23 12:52:35 2005) References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <20050223211641.34262885.fedora@wir-sind-cool.org> <1109191955.6581.78.camel@pensja.lam.pl> Message-ID: <1109378971l.7697l.7l@devel.mpeters.us> On 02/23/2005 12:52:35 PM, Leszek Matok wrote: > Dnia 23-02-2005, ?ro o godzinie 21:16 +0100, Michael Schwendt napisa? > (a): > > Then do a better job at educating that person about extra packages > and > > how to get them easily. His choice of words ("stupid") is > inappropriate > > already. More friendlier of him would be to ask about how to add > mp3 > > support, in case you had not warned him earlier. > In fact I warn and give instruction how to install xmms-mp3, disable > librh_mp3.so, install mplayer etc., but only to few of my friends who > want to try out Linux and can count on my support. I don't sell > copies, > but I can imagine the hell any Fedora CD/DVD seller has to go through > :) I have gone through absolutely no hell. When a customer asks how to play mp3's - I simply tell them how to import gpg keys to Fedora Extras and rpm.livna.org - and how to add them to yum. Then - getting mp3 support is as easy as yum install xmms-mp3 gstreamer-plugins-mp3 That then pulls in everything they need. If they need it in sox - I provide a replacement rpm for them, if I ever get a "cease and stop" for that, I'll just provide the simple instructions (yum install mad-devel lame-devel; rpmbuild --rebuild sox- ***) > > The typical user who wants to try out Fedora is disappointed when > they > install for the first time. I for one don't want Linux to be 31337, I > want it to be seen as an alternative to Windows or MacOS even by > Windows/MacOS users, and that can happen only if such user doesn't > get > disgusted after even test installation. I don't care if the users go > back to their systems if only they get the impression that Linux > works. It does work. MS for eons did not ship an mp3 encoder, they still don't ship a DVD decoder. It's not hard to add the support, and certainly easier than Fedora going to a non free distribution method in order to pay for the patents. > The bad thing is only if they go back and say "I had Linux on my box > once, but it doesn't do this, this and this, and I had to find some > third-party packages which I didn't know how to install, so it > sucks". They have to get third party software, often $$$, to do stuff in Windows or OS X as well. Stuff that Fedora provides functionallity for OOB. -- Michael A. Peters http://mpeters.us/ From michael.favia at insitesinc.com Sat Feb 26 00:52:08 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 25 Feb 2005 18:52:08 -0600 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109365469.23111.35.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> Message-ID: <421FC838.7030304@insitesinc.com> seth vidal wrote: >It does? Who do I represent? I think I am a member of 'the community'? >I think Jeremy and Bill and Elliot are too. >I think they're members of the contributing community. > > Agreed. >It's not elitistism it's based on listening to the people who are doing >the work. In large projects if you listen to everyone you can never get >any work done. So you listen to the people are contributing. I don't >think that's particularly crazy. Show me an open source project that is >NOT like that. This is not a democracy - I hope it's a meritocracy - but >in reality it's something more like 'those people who do the work get >listened to'-ocracy. > > I feel this model assumes that maintainership is the only meritorious activity in fedora. I think that other meritorious activities such as useful analysis of plans and the occasional proposal of alternative solutions also is meritorious. Im not talking about backseat coding here but rather offering an alternative perspective to create a well-rounded view of the goal and the bumps in the path to get there as well as some suggestions to traverse the trail efficiently. If it is the position of redhat that this isnt the case i understand but i think it is a mistake to limit input to that one group. >Then tell me how else you do it? How to cull the signal from the noise? > >show me a better way and we'll get there lickety-damn-split. > > My best suggestion is to open the "new dev list" (aka maintainers) to people that serve other valuable roles or who routinely inject intelligent ideas into conversation on fedora-devel. Essentially i like the idea of a moderated list because i grow weary of a thread with 512 msgs (slimfast slimfest) because it takes half my morning to weed through it and very few users read it and end up asking the same questions elsewhere in the list. My only argument is that i think that people provide value in other ways than simply maintainership. Admit users to the list contingent on their behavior and ability to keep "noises off". If you find they are habitual flamers and dont contribute enough to justify the noise warn them, if it doesnt improve then thank them for the input and show them the door politely. If you start small with the whitelist and add users slowly it will be easy to manage and should maintain equilibrium without much influence. not to mention improve the level of decorum with which users treat each other on a smaller list with more accountability. I think we should be honest and mention that it is unlikely that the devel list will maintain the same level of importance with the introduction of a new "working list". I dont fault anyone for this but there are only so many hours in the day and the S:N ratio will be so much lower on devel when everyone bails to maintainer that it will increasingly become more like "fedora-list" and justifiably less worth reading. I read lists in order of importance (based on time constraints) and fedora devel will drop way lower with the advent of maintainers. -mf From fedora at wir-sind-cool.org Sat Feb 26 01:12:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 26 Feb 2005 02:12:45 +0100 Subject: FC4 slimfast slimfest In-Reply-To: <1109378971l.7697l.7l@devel.mpeters.us> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <20050223211641.34262885.fedora@wir-sind-cool.org> <1109191955.6581.78.camel@pensja.lam.pl> <1109378971l.7697l.7l@devel.mpeters.us> Message-ID: <20050226021245.3391dccb.fedora@wir-sind-cool.org> On Sat, 26 Feb 2005 00:49:31 +0000, Michael A. Peters wrote: > I have gone through absolutely no hell. > When a customer asks how to play mp3's - I simply tell them how to > import gpg keys to Fedora Extras and rpm.livna.org - and how to add > them to yum. > > Then - getting mp3 support is as easy as > > yum install xmms-mp3 gstreamer-plugins-mp3 > > That then pulls in everything they need. > If they need it in sox - I provide a replacement rpm for them, if I > ever get a "cease and stop" for that, I'll just provide the simple > instructions (yum install mad-devel lame-devel; rpmbuild --rebuild sox- > ***) yum install k3b-mp3 kdemultimedia-extras That adds even more mp3 plugins. From aoliva at redhat.com Sat Feb 26 03:15:12 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 00:15:12 -0300 Subject: XFCE packages gone? In-Reply-To: <20050225200240.GC25441@nostromo.devel.redhat.com> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <20050225200240.GC25441@nostromo.devel.redhat.com> Message-ID: On Feb 25, 2005, Bill Nottingham wrote: > - xemacs: duplicate of Emacs functionality It's actually the other way round. I happen to prefer GNU Emacs for several reasons, but I know from personal experience that XEmacs is far more feature-rich than GNU Emacs. xemacs-sumo offers a lot of applications that are not available within GNU Emacs. If we are to remove one of them, the one that is mostly duplicate functionality is GNU Emacs. w3-mode, mailcrypt, auctex are some of the apps that come to mind as built into XEmacs but missing from GNU Emacs. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From byte at aeon.com.my Sat Feb 26 03:54:12 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 26 Feb 2005 11:54:12 +0800 Subject: FC4 slimfast slimfest In-Reply-To: <1109194231.6581.98.camel@pensja.lam.pl> References: <200502212237.38864.ronny-vlug@vlugnet.org> <1109185501.6581.34.camel@pensja.lam.pl> <1109185822.5420.1.camel@hades.cambridge.redhat.com> <1109186127.6581.39.camel@pensja.lam.pl> <1109186655.5420.4.camel@hades.cambridge.redhat.com> <1109186939.6581.48.camel@pensja.lam.pl> <1109188148.5420.23.camel@hades.cambridge.redhat.com> <1109189233.6581.60.camel@pensja.lam.pl> <20050223220822.44d6e39d.fedora@wir-sind-cool.org> <1109194231.6581.98.camel@pensja.lam.pl> Message-ID: <1109390053.5676.142.camel@arena.soho.bytebot.net> On Wed, 2005-02-23 at 22:30 +0100, Leszek Matok wrote: > > Widely spread FAQs and HOWTOs will guide newbies > > appropriately, e.g. like http://fedorafaq.org does nowadays already. > Straight that up for me again: if fedorafaq.org tells about ways to > enable MP3 support and others, can Red Hat make link to it from the > Mozilla home page (file:///usr/share/doc/HTML/index.html in FC3) or > would it be contributory infringement? Apparently so; we can't link to fedorafaq.org or even point folk to livna In fact, Ask Shadowman answers this rather nicely: http://www.redhat.com/magazine/004feb05/departments/ask_shadowman/ (last question) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From byte at aeon.com.my Sat Feb 26 04:43:02 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 26 Feb 2005 12:43:02 +0800 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421F8F4D.1030600@insitesinc.com> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> Message-ID: <1109392983.5676.155.camel@arena.soho.bytebot.net> On Fri, 2005-02-25 at 14:49 -0600, Michael Favia wrote: > >Mostly to keep the signal/noise ratio down. > > > > > Sounds awful elitist and Machiavellian for a community driven project. All major open source projects have closed lists to keep the s/n ratio down for other development discussions. We're following the model GNOME used for gnome-hackers and gnome-hackers-readonly (though they then made the mistake of desktop-devel-list which became rather noisy, again) > I agree, but then you are just granting the illusion of a community > controlled project arent you? Essentially the real discussion concerning > dev will have been moved to f-m right? I understand that trying to keep No. If a community member not on fedora-maintainers reads something in fedora-maintainers-readonly, I'm sure the thread can be continued on in fedora-devel-list > the project moving without all of this "change is bad" and "me too" crap > is important but i think that this "fix" fails to live up to the > community aspect of the project doesnt it? Essentially your voice doesnt > matter if you arent a maintainer anymore because the other lists will be > read less and less by RH and maintainers over time. As a result you will > lose the community driven nature i think because all of the opinions > batted about will be those of maintainers alone. A moderated white list > of users that conduct themselves in a prescribed manner makes most sense > to me. No. Folk will still read fedora-devel, and don't feel left out by it Also, the other thing to keep in mind is that getting a package maintained isn't too hard, and the Extras process is now, open. My last cvs sync gave me about 572 packages in Extras; last time I checked with the "universe" of packages that another major distribution had, they fit an entire 2 DVDs iirc. So contribute more packages, I guess, and lets make Fedora rock (harder)! -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From byte at aeon.com.my Sat Feb 26 04:51:37 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 26 Feb 2005 12:51:37 +0800 Subject: reducing distribution CD count In-Reply-To: <1109285049.15658.38.camel@opus.phy.duke.edu> References: <200502240906.20729.czar@czarc.net> <1109280515.3817.123.camel@one.myworld> <421E47F1.1E43FD74@jwz.org> <1109285049.15658.38.camel@opus.phy.duke.edu> Message-ID: <1109393497.5676.162.camel@arena.soho.bytebot.net> On Thu, 2005-02-24 at 17:44 -0500, seth vidal wrote: > > > 3- The average joe (me) expect to find the documentation in the > same > > > place than the program. A program with its documentation is the > same > > > whole thing. > > > > Perhaps I'm not an "average joe" in this matter, but I never look > for > > documentation on the local disk. I *always* use Google first. > > +1 > > people use local docs? Think countries where the Internet is not so readily available. Or homes where there are no Internet connections. And don't even think 3rd world countries... Someone came up to me at LinuxWorld after the talk I gave, and said they'd like to upgrade from RH9 to FC3. I said, grab the DVD. He said he lacked a DVDROM drive. I said, use yum :) He said he lacked an Internet connection. He definitely needs local docs. And so do many others. And then there's devhelp as thomasvs mentions, which is mighty useful for programmers. We should set a precedent that whatever goes in, must at least have a good man page, with good docs. In fact, this is what FreeBSD/OpenBSD has set as precedent, iirc - package doesn't go in, till it has docs -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From aoliva at redhat.com Sat Feb 26 05:03:41 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 02:03:41 -0300 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109361494.23111.18.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> Message-ID: On Feb 25, 2005, seth vidal wrote: > I think extras is workable now. If it's not I wonder what I've been > building every night for the past N weeks. I'm sure you'd think it's workable. Let's see: - you operate one of the biggest mirrors of FC and presumably FE - even if you didn't have FE locally, you've got a *very* fat network pipe at your disposal - you're the author of the tool that gives most people easy-ish access to FE - you run the FE human build system That's hardly the case for the typical Fedora user. In fact, if I knew there was only one person on Earth (or in the universe!) that was happy about the usability of the current Fedora Extras, my first guess would be you, and the second would probably be Bill Gates :-) This is not meant as an insult or as criticism; I really appreciate your effort, and thank you for that. I just don't think your situation is anywhere close to that of most of our user base, and as much as you might try to make your views impartial and unaffected by this, it's very likely to still be very biased. Moving useful packages from Fedora Core to Fedora Extras, as it stands, is too hasty a step. We should extend the Fedora Core tools such that the Fedora distribution (by that I wish I could mean Core + Extras) can be installed and used as such, no matter how fat their network pipe is. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From greg at kroah.com Sat Feb 26 05:07:05 2005 From: greg at kroah.com (Greg KH) Date: Fri, 25 Feb 2005 21:07:05 -0800 Subject: ITE 8212 and pwc drivers absent in Rawhide In-Reply-To: <1109319950.5110.22.camel@localhost.localdomain> References: <1109319950.5110.22.camel@localhost.localdomain> Message-ID: <20050226050705.GA11218@kroah.com> On Fri, Feb 25, 2005 at 09:25:50AM +0100, Peter Backlund wrote: > Hello. > > I'd like to see the ITE 8212 IDE/RAID pci card driver > ( CONFIG_BLK_DEV_IT8212) and the pwc webcam driver back in the kernel. > Is there any reason why they were removed? The pwc driver author asked for it to be removed. It no longer has a maintainer nor anyone who wants to support it. Until then it will remain outside of the kernel tree (and _someone_ needs to actually submit it for inclusion...) thanks, greg k-h From eric at snowmoon.com Sat Feb 26 05:23:41 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 00:23:41 -0500 Subject: Package pruning for FC4 and beyond Message-ID: <422007DD.1020404@snowmoon.com> I said it and now I'm doing it. I have started making a once over of the packages looking for dead/obsolete/unecessary core packages in core-testing. I have gone through .src.rpm's a*-e* and I have a breakdown of packages. These packages appear to be things that can either move to extras or be dropped. I am willing to pledge support for some of these packages if there is a call for their continued existance in extras, but not all. I have a feeling that some will drop completly out from lack of support. Lines with a '+' mean that they are a dependancy that is a logical remove as well. I have a small reason for each removal from core listed next to each. 'D:0' = nothing depends on these packages. Highly likley candidates ElectricFence - Development only ( many similar ) D:0 SDL* - kdeaddons is the only thing that depends on this + kdeaddons - small add on packages for stock kde apps *VFlib2 - only if we can break the ghostscript requireedby + MagicPoint - Duplicated functionality already in other packages Xaw3d - required by emacs + emacs ( pick emacs or xemacs and move the other to extras ) a2ps - used by Xfprint ( XFce - already moved to extras ) awesfx - OLD Soundblaster awe 32 util ( 2000 ) D:0 bogl* - kernel 2.2 fb graphics lib D:0 cdecl - C/C++ to English conversion D:0 dasher - obscure alternate input method D:0 ! 10MB dovecot - IMAP server ( duplication of effort ) epic - duplicate effort lynx - duplicate effort ( elinks ) Possible candidates Canna - Superceeded by IIMF - nothing depends ! 10MB Guppi apel - extras for emacs + ddskk - extra input methods for emacs + film - message encoding emacs + wl - imap/pop/nntp reader for emacs arptables_jf - specialized filtering of arp D:0 ccs - cluster config? cdlabelgen - does anyone use? D:0 cscope - c code browser - duplicate effort D:0 doxygen - Sorce code documentation generator D:0 autorun - functionality in most desktops already d:0 Cheers, Eric -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Sat Feb 26 06:01:17 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 01:01:17 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <422007DD.1020404@snowmoon.com> References: <422007DD.1020404@snowmoon.com> Message-ID: <20050226060117.GA11986@jadzia.bu.edu> On Sat, Feb 26, 2005 at 12:23:41AM -0500, Eric Warnke wrote: > SDL* - kdeaddons is the only thing that depends on this But a great deal of third-party programs use it. It's nice to have libraries like this in core so there's a relatively normal functional base. > dovecot - IMAP server ( duplication of effort ) Duplication of which effort? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at phy.duke.edu Sat Feb 26 06:13:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 01:13:27 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <421FC838.7030304@insitesinc.com> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> <421FC838.7030304@insitesinc.com> Message-ID: <1109398407.27384.9.camel@cutter> >I feel this model assumes that maintainership is the only meritorious >activity in fedora. I think that other meritorious activities such as >useful analysis of plans and the occasional proposal of alternative >solutions also is meritorious. Im not talking about backseat coding here >but rather offering an alternative perspective to create a well-rounded >view of the goal and the bumps in the path to get there as well as some >suggestions to traverse the trail efficiently. If it is the position of >redhat that this isnt the case i understand but i think it is a mistake >to limit input to that one group. No, in fact, quite the contrary. We already raised this issue people can recommend/sponsor other non-packagers for inclusion on that list. I fully realize there are lots of non-packging meritous contributions to fedora. > >My best suggestion is to open the "new dev list" (aka maintainers) to >people that serve other valuable roles or who routinely inject >intelligent ideas into conversation on fedora-devel. Essentially i like >the idea of a moderated list because i grow weary of a thread with 512 >msgs (slimfast slimfest) because it takes half my morning to weed >through it and very few users read it and end up asking the same >questions elsewhere in the list. And I read every post on the thread. Sad huh? :) But if you want to help in that way then read through every message and work with Colin Charles on reviving the Fedora News Updates. And guess what- that also means you're contributing usefully. I really don't think it is inappropriate to try to get folks to contribute in order to be able to be more involved in the decision making process. -sv From barryn at pobox.com Sat Feb 26 06:26:42 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 25 Feb 2005 22:26:42 -0800 Subject: Package pruning for FC4 and beyond In-Reply-To: <422007DD.1020404@snowmoon.com> References: <422007DD.1020404@snowmoon.com> Message-ID: <20050226062642.GB30940@ip68-4-98-123.oc.oc.cox.net> On Sat, Feb 26, 2005 at 12:23:41AM -0500, Eric Warnke wrote: > Highly likley candidates > > ElectricFence - Development only ( many similar ) D:0 http://fedora.redhat.com/about/objectives.html ---begin quote--- Objectives of Fedora Core: 1. Create a complete general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community -- _those who not only consume, but also produce for the good of other community members_. [...] 4. Provide a robust development platform for building software, particularly open source software. ---end quote--- Given the above, I don't see how things like Electric Fence are "likely candidates" for removal. I'm not saying FC must keep Electric Fence, but "Development only" is not by itself a reason to remove it or any package. At least, that's how I see things. -Barry K. Nathan From mpeters at mac.com Sat Feb 26 06:27:52 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 26 Feb 2005 06:27:52 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <422007DD.1020404@snowmoon.com> (from eric@snowmoon.com on Fri Feb 25 21:23:41 2005) References: <422007DD.1020404@snowmoon.com> Message-ID: <1109399272l.7697l.9l@devel.mpeters.us> On 02/25/2005 09:23:41 PM, Eric Warnke wrote: > + emacs ( pick emacs or xemacs and move the other to extras ) keep emacs, move xemacs. > lynx - duplicate effort ( elinks ) keep lynx - a lot of existing scripts depend upon it, lynx really is almost as standard on *nix as vi - it is THE cli http client. -- Michael A. Peters http://mpeters.us/ From skvidal at phy.duke.edu Sat Feb 26 06:39:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 01:39:47 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> Message-ID: <1109399987.27384.33.camel@cutter> >I'm sure you'd think it's workable. Let's see: > >- you operate one of the biggest mirrors of FC and presumably FE > >- even if you didn't have FE locally, you've got a *very* fat > network pipe at your disposal > >- you're the author of the tool that gives most people easy-ish access > to FE > >- you run the FE human build system I also admin and provide the machine that is fedoraproject.org. I set up the wiki, I wrote the scripts to provide the rss feeds of the packages recently updated. Let's see, what else. Hmm, I host and provide the machine that is download.fedoralegacy.org. I do many of these things b/c of the opportunities my employer gives me by being a reasonably good-sized university. What do the things I try to contribute have to do with my belief that extras functions? You maintain libtool and a number of compiler-related functions. Does this mean you are not to be trusted about the state of the compilers? I believe extras functions b/c they are are over 901 packages in extras. There are a whole bunch of people packaging for it now. My role is just to rebuild these things while we work on the build system automation. >That's hardly the case for the typical Fedora user. In fact, if I >knew there was only one person on Earth (or in the universe!) that was >happy about the usability of the current Fedora Extras, my first guess >would be you, and the second would probably be Bill Gates :-) This is just bizarre. >This is not meant as an insult or as criticism; I really appreciate >your effort, and thank you for that. I just don't think your >situation is anywhere close to that of most of our user base, and as >much as you might try to make your views impartial and unaffected by >this, it's very likely to still be very biased. Moving useful >packages from Fedora Core to Fedora Extras, as it stands, is too hasty >a step. We should extend the Fedora Core tools such that the Fedora >distribution (by that I wish I could mean Core + Extras) can be >installed and used as such, no matter how fat their network pipe is. So here's the problem, you're missing. Let's give you the example of the user not having a fast network connection. cases: 1. the distro is 5 isos - they spend 8 yrs downloading 5 isos to install about 30% of the packages available on them - they've wasted a lot of time and probably made a number of coasters in the process. 2. the distro is 4 isos - they spend 6 yrs download 4 isos to install about 30% of the packages available on them. Then finding that their FAVORITE package is not there they spend 1 yr downloading only the packages they want from extras. So if we're worried about users with limited bandwidth then we would want the latter. Which means putting fewer packages in core. 3. the distro is 4 or 5 isos - the user is given the cds from a friend with a faster network connection. The user consumes no bandwidth at all, so far. a. it's 5 isos - their FAVORITE package is there so they're done (until they see something cool they want in extras, of course) b. it's 4 isos their FAVORITE package is not there - so they ask the friend to burn them a cd of a chunk of things from extras. Heck, if the friend is really nice s/he can get a list of what they need, run repoclosure on it across base + extras and then run createrepo on the cd before handing it over. Then s/he knows that the user has all they need. The user pops in the cd, runs and adds a repo to their yum.repos.d and they're cooking with gas. 4. the distro is 4 or 5 isos - the user is given the cds but not from a friend and has no other way than a 28.8K modem to download the rest. a. the distro is 4 isos - they don't have their FAVORITE package but then again they don't have the ability to play ascii art video files either. They don't have lots of things. I'm sorry, but hey, maybe someone wants to make isos of Extras like the user with the friend in the case above. b. the distro is 5 isos - they have their FAVORITE package, but they still can't play ascii art video files. So maybe someone volunteering to look at isos of extras is the right solution. hey, wait a second. You're a programmer aren't you? would you like to contribute to fedora extras? I bet you could come up with a way to make isos from Fedora Extras! That's fantastic, thanks for volunteering instead of just being another complaining voice w/o a solution. -sv From aoliva at redhat.com Sat Feb 26 06:37:59 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 03:37:59 -0300 Subject: Package pruning for FC4 and beyond In-Reply-To: <422007DD.1020404@snowmoon.com> References: <422007DD.1020404@snowmoon.com> Message-ID: On Feb 26, 2005, Eric Warnke wrote: > dovecot - IMAP server ( duplication of effort ) What's the other IMAP/POP server in Core that can export mailboxes in the standard mbox format as delivered by the default MTA, and can do preauth when started from the command line for fetchmail over ssh? > epic - duplicate effort Is there any other text-mode IRC client in Core? > lynx - duplicate effort ( elinks ) This debate has already happened several times. IIRC the end conclusion is always that each of the text-mode browsers has strengths and weaknesses that the others don't, to a point in which we really shouldn't drop any of them. > + film - message encoding emacs I suppose you mean flim -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From byte at aeon.com.my Sat Feb 26 06:53:57 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 26 Feb 2005 14:53:57 +0800 Subject: Package pruning for FC4 and beyond In-Reply-To: References: <422007DD.1020404@snowmoon.com> Message-ID: <1109400838.5676.167.camel@arena.soho.bytebot.net> On Sat, 2005-02-26 at 03:37 -0300, Alexandre Oliva wrote: > > epic - duplicate effort > > Is there any other text-mode IRC client in Core? I've proposed its replacement with irssi before. It was generally agreed upon on this list... pvrabec: mind moving epic to Extras, and irssi from Extras into Core? Thanks -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From mpeters at mac.com Sat Feb 26 07:10:27 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 26 Feb 2005 07:10:27 +0000 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: <20050225123954.A4334@xos037.xos.nl> (from jos@xos.nl on Fri Feb 25 03:39:54 2005) References: <200502242238.j1OMcsO02013@xos037.xos.nl> <1109300719.10447.4.camel@one.myworld> <20050225123954.A4334@xos037.xos.nl> Message-ID: <1109401827l.7697l.10l@devel.mpeters.us> On 02/25/2005 03:39:54 AM, Jos Vos wrote: > > > > I don't take a close look but it seems Fedora Extra also have its > > development branch : > > > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ > > > > Ooops, it's empty :-) > > Yes, it is :-(. These removed packages will, I hope, be in extras? AbiWord and Gnumeric are of course my biggest needs - I agree they shouldn't be in core if Core has OO.o, but they do need to be in Extras if not in core - is there a listing somewhere of what core dropped packages will be imported into extras for fc4? XFCE is also one I definitely want to see - I use it machines that don't need a full gnome desktop. -- Michael A. Peters http://mpeters.us/ From skvidal at phy.duke.edu Sat Feb 26 07:16:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 02:16:00 -0500 Subject: fedora-d-rh] Re: XFCE packages gone? In-Reply-To: <1109401827l.7697l.10l@devel.mpeters.us> References: <200502242238.j1OMcsO02013@xos037.xos.nl> <1109300719.10447.4.camel@one.myworld> <20050225123954.A4334@xos037.xos.nl> <1109401827l.7697l.10l@devel.mpeters.us> Message-ID: <1109402160.27384.36.camel@cutter> On Sat, 2005-02-26 at 07:10 +0000, Michael A. Peters wrote: >On 02/25/2005 03:39:54 AM, Jos Vos wrote: > >> > >> > I don't take a close look but it seems Fedora Extra also have its >> > development branch : >> > >> http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ >> > >> > Ooops, it's empty :-) >> >> Yes, it is :-(. > >These removed packages will, I hope, be in extras? >AbiWord and Gnumeric are of course my biggest needs - I agree they >shouldn't be in core if Core has OO.o, but they do need to be in Extras >if not in core - is there a listing somewhere of what core dropped >packages will be imported into extras for fc4? > >XFCE is also one I definitely want to see - I use it machines that >don't need a full gnome desktop. development was just branched this afternoon for extras. I expect to be getting LOTS of build requests in the next week. :) -sv From aoliva at redhat.com Sat Feb 26 07:22:18 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 04:22:18 -0300 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109399987.27384.33.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> Message-ID: On Feb 26, 2005, seth vidal wrote: > What do the things I try to contribute have to do with my belief that > extras functions? You maintain libtool and a number of compiler-related > functions. Does this mean you are not to be trusted about the state of > the compilers? No, it means that if people moved features out of say the kernel claiming they could be implemented by the compiler or glibc, I wouldn't feel as uncomfortable because I could implement them myself if I had the time and inclination to do so. I'm at an advantage position in this regard. Just like you're at an advantage position WRT Fedora Extras. > I believe extras functions b/c they are are over 901 packages in > extras. See, the problem is not in extras. It works perfectly well, and there's very little to improve other than the creation of ISOs at about the same time as the release. The problem is in Core, that's missing essential features to make Extras a seamless part of the distro. Such features are scheduled to FC5, but nevertheless we're pushing useful packages from Core to Extras as if this would have no impact on anyone. As if the seamless integration was already in place. This is the mistake I'm disputing. My solution is to just bring the packages that were removed out of the madness to shrink the Core to an arbitrary limit. It's not shrinking the distro (Core + Extras), just pushing bits around, making some of them less convenient to get to. Sure having CDs of Extras available for download would address part of the problem: people would still be able to ask friends with big pipes to download and burn CDs for them. But how convenient is the experience of installing packages from such CDs be? Anaconda won't be able to install packages from such CDs; will system-config-packages? How about yum, will it require messing with yum config files, or does it have magic to resolve deps and install packages from a collection of CDs that have dep closure as a whole, but not individually? (i.e., I want to install package foo that's in CD2, but that depends on bar that's in CD1) >> That's hardly the case for the typical Fedora user. In fact, if I >> knew there was only one person on Earth (or in the universe!) that was >> happy about the usability of the current Fedora Extras, my first guess >> would be you, and the second would probably be Bill Gates :-) > This is just bizarre. In case the point of the joke was not clear, I think this rush to move packages out of the Core before the Core is ready for Extras will make Fedora as a whole worse, and anything that makes a GNU/Linux distro probably makes Bill Gates a richer man. > 1. the distro is 5 isos - they spend 8 yrs downloading 5 isos to install > about 30% of the packages available on them > - they've wasted a lot of time and probably made a number of coasters > in the process. Just because I'm a pedant, make that 4.5 isos, which was the original space figure we had. You don't have to download the second half of the last CD, so what we're saving is not 2 years of download (heh :-), just half a year or so. > So if we're worried about users with limited bandwidth then we would > want the latter. Which means putting fewer packages in core. Sure. As soon as the Core is ready. Besides, there's always the option of downloading the individual packages, or perform an HTTP install using a local web proxy. If you don't have a lot of bandwidth but can wait for 5 years for the install to complete, that's probably the way to go. For such users, whether something is in Core or Extras makes little difference, except for updates possibly breaking working packages. > b. it's 4 isos their FAVORITE package is not there - so they ask the > friend to burn them a cd of a chunk of things from extras. Heck, if the > friend is really nice s/he can get a list of what they need, run > repoclosure on it across base + extras and then run createrepo on the cd > before handing it over. Then s/he knows that the user has all they need. > The user pops in the cd, runs and adds a repo to their yum.repos.d and > they're cooking with gas. If it fits in a single CD, or each CD is made repo-closed, yes. > either. They don't have lots of things. I'm sorry, but hey, maybe > someone wants to make isos of Extras like the user with the friend in > the case above. They can't. And nobody can, if I'm reading the Fedora trademark guidelines. Yeah, we should fix that. But fine, someone could burn select rpms into CDs for friends. But companies can't create Extras CDs fitting certain profiles and sell them, or distribute them with magazines, using the Fedora name. > b. the distro is 5 isos - they have their FAVORITE package, but they > still can't play ascii art video files. So maybe someone volunteering to > look at isos of extras is the right solution. It would help, but as I explained above, we still need better tools. > hey, wait a second. You're a programmer aren't you? Allegedly :-) > would you like to contribute to fedora extras? I bet you could come > up with a way to make isos from Fedora Extras! Hey, I know we have some Python scripts to create the Core CDs! Why couldn't we just tell it to take packages from the Extras pool as well, and roll a single set of CDs? Wouldn't that be cool? :-) > That's fantastic, thanks for volunteering instead of just being another > complaining voice w/o a solution. The solution that many of us have been proposing is to revert the not-well-thought-out rush to shrink Core before the tools are ready to make Extras a seamless part of the distro. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From russell at coker.com.au Sat Feb 26 07:32:13 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 26 Feb 2005 18:32:13 +1100 Subject: writing zero bytes in bash Message-ID: <200502261832.16337.russell@coker.com.au> This message is intentionally sent to the fedora-devel-list and the SE Linux list not the fedora-selinux-list. It is not related to Fedora specific SE Linux functionality, but it is related to bash (a core part of Fedora) and SE Linux kernel code. To unset the fscreate or exec context you have to write zero bytes to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. If you want to do this in a shell script you would do something like: echo -n "" > /proc/self/attr/fscreate However that shell command results in bash (both the version in rawhide and the version in RHEL4) performing the following system calls: open("/proc/self/attr/exec", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 fcntl64(1, F_GETFD) = 0 fcntl64(1, F_DUPFD, 10) = 10 fcntl64(1, F_GETFD) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 dup2(3, 1) = 1 close(3) = 0 dup2(10, 1) = 1 fcntl64(10, F_GETFD) = 0x1 (flags FD_CLOEXEC) close(10) = 0 It opens the file with O_CREAT (so if you were to do `echo -n "" > /tmp/flag` to create a flag file then it would work as expected), but never calls the write(2) system call. To unset the fscreate or exec context you have to call write(fd, X, 0) (the value of X doesn't seem to matter as the kernel code doesn't dereference it). It seems likely to me that there may be other bits of kernel code exporting an interface under /proc where a write of 0 bytes may have a different meaning to merely opening a file with write access and then closing it. So it seems reasonable to me to consider this to be a bug in bash where it's optimisation of shell code results in the action requested by the user not being performed correctly. It took a surprising amount of time for me to realise that bash wasn't doing what I expected of it and ran strace to prove it. I expect that most sys-admins would take even longer to work it out (if they ever did). I expect that the bash developers may disagree with this assessment so I would like some more input on the lists before I file a bug report. -- 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 Sat Feb 26 07:51:03 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 26 Feb 2005 18:51:03 +1100 Subject: kickstart NFS install freezing Message-ID: <200502261851.05029.russell@coker.com.au> I am doing some tests on a kickstart install of RHEL4 and discovered a problem with my NFS server, after a large amount of data being transferred it will lock up the ethernet interface and refuse to talk to the NFS client until the interface has been deconfigured with "ifconfig down" and then configured again. When this problem occurs it stops the install (as expected), but it also stops the mouse cursor from moving. This seems to be a bug to me, the X server should not be accessing files on the NFS server (as far as I am aware) and therefore there is no good cause for the mouse cursor to stop. Once the NFS server starts responding again the install proceeds and the mouse cursor responds. Is this considered to be working as designed or is it a bug? -- 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 peter.backlund at home.se Sat Feb 26 08:09:27 2005 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 26 Feb 2005 09:09:27 +0100 Subject: ITE 8212 and pwc drivers absent in Rawhide In-Reply-To: <20050226050705.GA11218@kroah.com> References: <1109319950.5110.22.camel@localhost.localdomain> <20050226050705.GA11218@kroah.com> Message-ID: <1109405368.1049.6.camel@localhost.localdomain> fre 2005-02-25 klockan 21:07 -0800 skrev Greg KH: >On Fri, Feb 25, 2005 at 09:25:50AM +0100, Peter Backlund wrote: >> Hello. >> >> I'd like to see the ITE 8212 IDE/RAID pci card driver >> ( CONFIG_BLK_DEV_IT8212) and the pwc webcam driver back in the kernel. >> Is there any reason why they were removed? > >The pwc driver author asked for it to be removed. It no longer has a >maintainer nor anyone who wants to support it. Until then it will >remain outside of the kernel tree (and _someone_ needs to actually >submit it for inclusion...) IIRC, Alan Cox stepped up as a maintainer of the driver, and it's included in the -ac patchset. /Peter From symbiont at berlios.de Sat Feb 26 08:12:53 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 26 Feb 2005 16:12:53 +0800 Subject: writing zero bytes in bash In-Reply-To: <200502261832.16337.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> Message-ID: <200502261612.54380.symbiont@berlios.de> On Saturday 26 February 2005 15:32, Russell Coker wrote: > To unset the fscreate or exec context you have to call write(fd, X, > 0) (the value of X doesn't seem to matter as the kernel code doesn't > dereference it). dd -- -jeff From mihai at xcyb.org Sat Feb 26 08:48:28 2005 From: mihai at xcyb.org (Mihai Maties) Date: Sat, 26 Feb 2005 10:48:28 +0200 Subject: writing zero bytes in bash In-Reply-To: <200502261832.16337.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> Message-ID: <200502261048.28448.mihai@xcyb.org> On Saturday 26 February 2005 09:32, Russell Coker wrote: > It opens the file with O_CREAT (so if you were to do `echo -n "" > > /tmp/flag` to create a flag file then it would work as expected), but never > calls the write(2) system call. > > To unset the fscreate or exec context you have to call write(fd, X, 0) (the > value of X doesn't seem to matter as the kernel code doesn't dereference > it). As a sidenote, dd behaves the same. dd if=/dev/null of=something does not call write(2) because it doesn't need to write anything. Since no records were read it assumes that no records must be written. Again, the output file would be created because of the open("something", O_CREAT) call. > It seems likely to me that there may be other bits of kernel code exporting > an interface under /proc where a write of 0 bytes may have a different > meaning to merely opening a file with write access and then closing it. Then this is the problem, not bash, dd or whatever. > So it seems reasonable to me to consider this to be a bug in bash where > it's optimisation of shell code results in the action requested by the user > not being performed correctly. It's quite logical since if you do not have something to write, to not try to write it. > It took a surprising amount of time for me to realise that bash wasn't > doing what I expected of it and ran strace to prove it. I expect that most > sys-admins would take even longer to work it out (if they ever did). This is indeed a problem, but the solution is not patching bash, dd, whatever. > I expect that the bash developers may disagree with this assessment so I > would like some more input on the lists before I file a bug report. If I were a bash developer I would disagree with you :) You would ask me to make a workaround in bash to solve an issue that has its roots somewhere else... Mihai From ville.skytta at iki.fi Sat Feb 26 10:26:16 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 26 Feb 2005 12:26:16 +0200 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109399272l.7697l.9l@devel.mpeters.us> References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> Message-ID: <1109413576.15854.140.camel@bobcat.mine.nu> On Sat, 2005-02-26 at 06:27 +0000, Michael A. Peters wrote: > On 02/25/2005 09:23:41 PM, Eric Warnke wrote: > > > + emacs ( pick emacs or xemacs and move the other to extras ) > > keep emacs, move xemacs. Already done. XEmacs and related stuff will be soon imported to Extras CVS for FC4+. From mitr at volny.cz Sat Feb 26 10:31:41 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 26 Feb 2005 11:31:41 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <422007DD.1020404@snowmoon.com> References: <422007DD.1020404@snowmoon.com> Message-ID: <20050226103137.GA28440@chrys.ms.mff.cuni.cz> On Sat, Feb 26, 2005 at 12:23:41AM -0500, Eric Warnke wrote: > I said it and now I'm doing it. Thanks! Most of the list looks very reasonable (to me personally, at least). > bogl* - kernel 2.2 fb graphics lib D:0 Used in the installer for CJK support in "text mode" > doxygen - Sorce code documentation generator D:0 A build dependency of several packages (e.g. kdelibs) Mirek From russell at coker.com.au Sat Feb 26 10:32:50 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 26 Feb 2005 21:32:50 +1100 Subject: writing zero bytes in bash In-Reply-To: <200502261612.54380.symbiont@berlios.de> References: <200502261832.16337.russell@coker.com.au> <200502261612.54380.symbiont@berlios.de> Message-ID: <200502262132.53440.russell@coker.com.au> On Saturday 26 February 2005 19:12, Jeff Pitman wrote: > On Saturday 26 February 2005 15:32, Russell Coker wrote: > > To unset the fscreate or exec context you have to call write(fd, X, > > 0) (the value of X doesn't seem to matter as the kernel code doesn't > > dereference it). > > dd I'm not sure what you are saying here. Are you suggesting to use dd to write zero bytes or that bash should work in a similar way to dd? dd does not seem capable of actually doing a write of 0. If you use bs=0 then it gives an error code, if you use count=0 then it does nothing (like bash). Maybe this should be considered a bug in dd as well, but let's concentrate on bash for the moment. This isn't the type of issue that can be addressed with a one-word reply. -- 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 dwmw2 at infradead.org Sat Feb 26 10:34:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 26 Feb 2005 10:34:57 +0000 Subject: XFCE packages gone? In-Reply-To: References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <20050225200240.GC25441@nostromo.devel.redhat.com> Message-ID: <1109414098.26364.253.camel@localhost.localdomain> On Sat, 2005-02-26 at 00:15 -0300, Alexandre Oliva wrote: >It's actually the other way round. I happen to prefer GNU Emacs for >several reasons, but I know from personal experience that XEmacs is >far more feature-rich than GNU Emacs. xemacs-sumo offers a lot of >applications that are not available within GNU Emacs. If we are to >remove one of them, the one that is mostly duplicate functionality is >GNU Emacs. w3-mode, mailcrypt, auctex are some of the apps that come >to mind as built into XEmacs but missing from GNU Emacs. > I already filed a bug for the absence of tramp, which was in xemacs but isn't in emacs. Despite years of using xemacs I'll certainly have a go at switching to emacs -- they're large packages and there's such a large overlap in their functionality that it makes sense to ship only one. For Exim/Postfix I don't hold out as much hope. I think the 'duplicate functionality' argument is even more backwards there, but I'm certainly willing to have a play with Postfix if I get time. It'd be useful if someone could suggest ways that a Postfix configuration can do the things which were possible with Exim in FC3 -- in particular: - Spam/virus scanning at SMTP time with tunable rejection thresholds, as in the default exim.conf - Virtual domains with aliases in TXT records in DNS, so that the owners of each domain can do maintenance with a Dynamic DNS client. (http://david.woodhou.se/eximconf/include/routers-dns-virtual) - Virtual domains with local users defined by the existence of a mbox file in a given directory, to which that user's mail is delivered. (http://david.woodhou.se/eximconf/include/routers-dir-virtual) - Automatic rewriting of outgoing reverse-paths using a timestamp and HMAC so that no mail is ever sent from a raw address like 'dwmw2 at infradead.org' hence no bounces need to be accepted. So users stop getting bounces to mail they didn't send, and other sites who do sender verification callouts stop accepting fake mail. (http://www.infradead.org/rpr.html, http://david.woodhou.se/eximconf/include/routers-ses) - Correct sender verification callouts using the NULL sender to simulate a bounce instead of a postmaster address. - Recipient verification callouts for domains for which we perform backup MX services, to avoid accepting mail to nonexistent users. - Rejection of HELO claiming to be a host in certain domains which are known to always have correct reverse DNS, when the host in question lacks it. (http://david.woodhou.se/eximconf/include/acl-helo) - Rejection of hosts failing the CSV (draft-ietf-marid-csv-csa-02.txt) record of the name with which they HELO ( http://david.woodhou.se/eximconf/include/acl-helo-csv) And indeed the rest of the spam checks in and functionality seen in http://david.woodhou.se/eximconf/ including but not limited to the filters in include/acl-content and include/acl-recipient These are things which are possible with Exim as Fedora Core 3 shipped it. Will they be possible with Fedora Core 4 as shipped? Is that 1721KiB package _really_ duplicating functionality which is available elsewhere? -- dwmw2 From mitr at volny.cz Sat Feb 26 10:39:16 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 26 Feb 2005 11:39:16 +0100 Subject: writing zero bytes in bash In-Reply-To: <200502261832.16337.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> Message-ID: <20050226103915.GB28440@chrys.ms.mff.cuni.cz> On Sat, Feb 26, 2005 at 06:32:13PM +1100, Russell Coker wrote: > To unset the fscreate or exec context you have to write zero bytes > to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. I personally think this is the problem - no interface should require writing 0 bytes. To quote the POSIX spec: | Before any action described below is taken, and if nbyte is zero and | the file is a regular file, the write() function may detect and return | errors as described below. In the absence of errors, or if error | detection is not performed, the write() function shall return zero and | have no other results. If nbyte is zero and the file is not a regular | file, the results are unspecified. Files in /proc _are_ regular files, as far as stat() is concerned, so I don't think you can require that portable programs give you the possibility to write 0 bytes to these files. Mirek From russell at coker.com.au Sat Feb 26 10:39:42 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 26 Feb 2005 21:39:42 +1100 Subject: writing zero bytes in bash In-Reply-To: <200502261048.28448.mihai@xcyb.org> References: <200502261832.16337.russell@coker.com.au> <200502261048.28448.mihai@xcyb.org> Message-ID: <200502262139.45861.russell@coker.com.au> On Saturday 26 February 2005 19:48, Mihai Maties wrote: > On Saturday 26 February 2005 09:32, Russell Coker wrote: > > It opens the file with O_CREAT (so if you were to do `echo -n "" > > > /tmp/flag` to create a flag file then it would work as expected), but > > never calls the write(2) system call. > > > > To unset the fscreate or exec context you have to call write(fd, X, 0) > > (the value of X doesn't seem to matter as the kernel code doesn't > > dereference it). > > As a sidenote, dd behaves the same. dd if=/dev/null of=something does not > call write(2) because it doesn't need to write anything. Since no records > were read it assumes that no records must be written. Again, the output > file would be created because of the open("something", O_CREAT) call. However dd bs=0 is an error, so dd refuses to operate in a situation where the operater specifically requests a zero write. > > So it seems reasonable to me to consider this to be a bug in bash where > > it's optimisation of shell code results in the action requested by the > > user not being performed correctly. > > It's quite logical since if you do not have something to write, to not try > to write it. That's one approach to the issue. The other is that if the administrator requests an operation then it should be completed. In the majority of situations where a user requests a strange operation Unix complies and does as requested. The expectation of a Unix system is that what you request will be done even if it is bad for you, so why not do what is requested just because it seems redundant? Someone who does "echo -n > foo" to create file foo could have just as easily done "touch foo". > > I expect that the bash developers may disagree with this assessment so I > > would like some more input on the lists before I file a bug report. > > If I were a bash developer I would disagree with you :) You would ask me to > make a workaround in bash to solve an issue that has its roots somewhere > else... Actually I am not asking for a feature to be added, but for a feature to be removed. There is special-case code in bash if(size >0) write() and I am merely suggesting that the if statement be removed. -- 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 Sat Feb 26 10:47:52 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 26 Feb 2005 21:47:52 +1100 Subject: writing zero bytes in bash In-Reply-To: <20050226103915.GB28440@chrys.ms.mff.cuni.cz> References: <200502261832.16337.russell@coker.com.au> <20050226103915.GB28440@chrys.ms.mff.cuni.cz> Message-ID: <200502262147.55747.russell@coker.com.au> Interesting comment. I'm replying with the SE Linux list CC'd so everyone who's involved can comment. Maybe a change to make "\n" equivalent to "" in the SE Linux kernel interfaces in question would be appropriate then? For the SE Linux interfaces in question a '\n' character is not valid in any part of the input and the input must contain three fields separated by colons, so a special case of "\n" being equivalent to "" can not cause any confusion. Also as a side note, in the normal use only libselinux.so has any code which does such zero byte writes. Doing it from bash is only needed for testing, debugging, and educational purposes. On Saturday 26 February 2005 21:39, Miloslav Trmac wrote: > On Sat, Feb 26, 2005 at 06:32:13PM +1100, Russell Coker wrote: > > To unset the fscreate or exec context you have to write zero bytes > > to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. > > I personally think this is the problem - no interface should require > writing 0 bytes. > > To quote the POSIX spec: > | Before any action described below is taken, and if nbyte is zero and > | the file is a regular file, the write() function may detect and return > | errors as described below. In the absence of errors, or if error > | detection is not performed, the write() function shall return zero and > | have no other results. If nbyte is zero and the file is not a regular > | file, the results are unspecified. > > Files in /proc _are_ regular files, as far as stat() is concerned, so > I don't think you can require that portable programs give you the > possibility to write 0 bytes to these files. > Mirek -- 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 mitr at volny.cz Sat Feb 26 10:49:16 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 26 Feb 2005 11:49:16 +0100 Subject: writing zero bytes in bash In-Reply-To: <200502262139.45861.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> <200502261048.28448.mihai@xcyb.org> <200502262139.45861.russell@coker.com.au> Message-ID: <20050226104916.GC28440@chrys.ms.mff.cuni.cz> On Sat, Feb 26, 2005 at 09:39:42PM +1100, Russell Coker wrote: > Actually I am not asking for a feature to be added, but for a feature to be > removed. There is special-case code in bash if(size >0) write() and I am > merely suggesting that the if statement be removed. Really? My guess is actually something like this: left = (len of data); p = (start of data); while (left != 0) { r = write (fd, p, left); if (r < 0) { if (errno != EINTR) error; r = 0; } p += r; left -= r; } which "looks" perfectly natural. Mirek From eric at snowmoon.com Sat Feb 26 13:38:51 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 08:38:51 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <422007DD.1020404@snowmoon.com> References: <422007DD.1020404@snowmoon.com> Message-ID: <42207BEB.7020000@snowmoon.com> Round two of the first set of possibilities. I have marked objections and removed a few from consiteration. Any with objections that I have kept, I have expanded on my reasoning. Once again these are suggestions to the community and I have no power to make the cuts myself, but once the discussion is complete I will forward the annotaded recommendationd up the food chain. In responding, please comment if you want it kept in core or in extras and why. Removed from consiteration Xaw3d - required by emacs and emacs is being kept bogl* - kernel 2.2 fb graphics lib d:0 ( should update dependancies here if it's required by the installer! ) epic/irssi? epic is there and it's the only text mode irc client unless we want to swap it out for irssi Ojections, but I still believe could be moved. dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut. ElectricFence - Development only nothing depends on it - 1 objection, but I still say it's usage does not justify it remaining in core - there is at least one competing package ( dmalloc, valgrind ) lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. doxygen - Sorce code documentation generator D:0 - 1 objecton - I don't think we necessarly need to keep every build dependancy in core. Likley without objections SDL* - kdeaddons is the only thing that depends on this + kdeaddons - small add on packages. not 100% necessary Canna - Superceeded by IIMF - nothing depends ! 10MB MAKEDEV - Superceeded by udev ? *VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility + MagicPoint - Duplicated functionality already in other packages a2ps - text to postscript tool required by xfprint awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 dasher - obscure alternate input method ! 10MB apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0 Possible without objections Guppi ccs - cluster config? cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 More to follow.... Cheers, Eric -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From dragoran at feuerpokemon.de Sat Feb 26 13:49:08 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 26 Feb 2005 14:49:08 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <42207BEB.7020000@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: <42207E54.9090902@feuerpokemon.de> "SDL* - kdeaddons is the only thing that depends on this" dropping sdl isn't a good idea because many third party apps require it. From seanlkml at sympatico.ca Sat Feb 26 14:08:15 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 26 Feb 2005 09:08:15 -0500 (EST) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109392983.5676.155.camel@arena.soho.bytebot.net> References: <1109287914.26364.69.camel@localhost.localdomain><421F36A6.8040401@olin.edu><1109342585.26364.163.camel@localhost.localdomain><1109346741.10989.13.camel@opus.phy.duke.edu><1109346973.26364.181.camel@localhost.localdomain><1109348125.10989.22.camel@opus.phy.duke.edu><20050225162219.GD1048932@hiwaay.net><1109348730.10989.33.camel@opus.phy.duke.edu><1109349041.26364.190.camel@localhost.localdomain><1109355427.10989.39.camel@opus.phy.duke.edu><20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter><1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109392983.5676.155.camel@arena.soho.bytebot.net> Message-ID: <1485.10.10.10.24.1109426895.squirrel@linux1> On Fri, February 25, 2005 11:43 pm, Colin Charles said: Hey colin, > All major open source projects have closed lists to keep the s/n ratio > down for other development discussions. We're following the model GNOME > used for gnome-hackers and gnome-hackers-readonly This is a little bit of an exaggeration; several prominent open source projects do not have a closed list. > (though they then made the mistake of desktop-devel-list which became > rather noisy, again) Noise may be a fair tradeoff if opening things up also leads to additional valuable input. > No. If a community member not on fedora-maintainers reads something in > fedora-maintainers-readonly, I'm sure the thread can be continued on in > fedora-devel-list Not if you want the readonly list membership to see it. And if they have to read the devel-list too, you haven't accomplished anything. > No. Folk will still read fedora-devel, and don't feel left out by it Who are you speaking for, and how do you know? Certainly people who don't often contribute may well have a valuable insight that will be harder to share. Such a person is bound to feel left out. > Also, the other thing to keep in mind is that getting a package > maintained isn't too hard, and the Extras process is now, open. My last > cvs sync gave me about 572 packages in Extras; last time I checked with > the "universe" of packages that another major distribution had, they fit > an entire 2 DVDs iirc. So contribute more packages, I guess, and lets > make Fedora rock (harder)! I don't see what this has to do with keeping the lists open to contributions from those who might not have contributed before. The people who believe Fedora is better served by avoiding closed lists want to improve Fedora just as much. Cheers, Sean From jakub at redhat.com Sat Feb 26 14:11:19 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 26 Feb 2005 09:11:19 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <42207BEB.7020000@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: <20050226141119.GV853@devserv.devel.redhat.com> On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote: > ElectricFence - Development only nothing depends on it - 1 objection, > but I still say it's usage does not justify it remaining in core - there > is at least one competing package ( dmalloc, valgrind ) valgrind is i386 only (therefore not a replacement for efence) and dmalloc is far worse then efence. If anything needs to be dumped to Extras, then it is dmalloc, not ElectricFence. > lynx/elinks - 1 objection about scripts using lynx... ether those > scripts are not part of core or they are not marked correctly. If you > can surf the web with either, you can download them from extras. If > either has a dependancy in core the .src.rpm needs to be corrected. If you install a server, you often don't run X at all and ability to browse web is very useful. Plus it is definitely something e.g. blind people can't miss in the distro. Therefore I strongly object to dropping at least elinks. elinks is really small package btw. > doxygen - Sorce code documentation generator D:0 - 1 objecton - I don't > think we necessarly need to keep every build dependancy in core. Core must be self-hosting. Jakub From eric at snowmoon.com Sat Feb 26 14:24:40 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 09:24:40 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <42207BEB.7020000@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: <422086A8.7020200@snowmoon.com> Round 3... all cage rule apply.. new items on the lists Removed from consiteration *electricfence - multiplatform .. see new additions* *doxygen - core must be self hosting* Xaw3d - required by emacs and emacs is being kept bogl* - kernel 2.2 fb graphics lib d:0 ( should update dependancies here if it's required by the installer! ) epic/irssi? epic is there and it's the only text mode irc client unless we want to swap it out for irssi Ojections, but I still believe could be moved. dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut. *lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras.* *SDL - kdeaddons is the only thing that depends on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras.* + kdeaddons - small add on packages. not 100% necessary. *New additions to the likley list* dmalloc, valgrind - electricence appears to be more compatible and better developed. freeglut - library with no dependancy in core fsh - obscure shell, features absorbed into OpenSSH giftrans - netpbm tools can do the same iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / pico / emacs / ed / vi ) lftp - useful ftp client ( ftp, ncftp ) D:0 Likley without objections Canna - Superceeded by IIMF - nothing depends ! 10MB MAKEDEV - Superceeded by udev ? *VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility + MagicPoint - Duplicated functionality already in other packages a2ps - text to postscript tool required by xfprint awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 dasher - obscure alternate input method ! 10MB apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0 Possible without objections Guppi ccs - cluster config? cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 freeradius - complex package d:0 ftpcopy - utility D:0. I have never used it, do we need in core g-wrap - Another wrapper for a development utility d:0 h2ps - another postscript generator D:0 Cheers, Eric -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From buildsys at redhat.com Sat Feb 26 14:47:46 2005 From: buildsys at redhat.com (Build System) Date: Sat, 26 Feb 2005 09:47:46 -0500 Subject: rawhide report: 20050226 changes Message-ID: <200502261447.j1QElk9K011807@porkchop.devel.redhat.com> Removed package ttfonts-ja Removed package jisksp14 Removed package knm_new Removed package ttfonts-ko Removed package kappa20 Removed package jisksp16-1990 Updated Packages: PyXML-0.8.4-2 ------------- * Fri Feb 25 2005 Miloslav Trmac - 0.8.4-2 - Rebuild, this should fix #149507 dhcp-10:3.0.2-2 --------------- * Thu Feb 24 2005 Jason Vas Dias 10:3.0.2-2 - Fix bug 143640: do not allow more than one dhclient to configure an interface * Mon Feb 21 2005 Jason Vas Dias 10:3.0.2-1 - Upgrade to ISC 3.0.2 Final Release (documentation change only). * Mon Feb 14 2005 Jason Vas Dias 8:3.0.2rc3-8 - Add better execshield security link options - fix dhcpd.init when no /etc/dhcpd.conf exists and -cf in DHCPDARGS emacs-21.3-24 ------------- * Thu Feb 24 2005 Jens Petersen - 21.3-24 - mark default.el (noreplace) config (Pawel Salek, 149310) - only set keyboard-coding-system in xterm's to fix problem with inputting Latin characters becoming prefixes and making emacs loop (Eddahbi Karim, 126007) - make emacs-el also own its lisp directories - run latex-mode-hook in latex-mode (Martin Biely, 144083) - add emacs-21.3-latex-mode-hook-144083.patch festival-1.95-1 --------------- * Fri Feb 25 2005 - 1.95-1 - patch from Matthew Miller to update to 1.95. Full changelog below * Mon Feb 07 2005 Matthew Miller 1.95-0.mattdm8 - put speech-tools binaries in /usr/libexec/speech-tools so as to not clutter /usr/bin. Another approach would be to make speech-tools a separate package and to make these utilities a subpackage of that. - macro-ize /usr/bin, /usr/lib, /usr/include * Sun Feb 06 2005 Matthew Miller 1.95-0.mattdm6 - worked on this some more - made actually work -- put back rest of fsstnd patch which I had broken - made kludge for lack of sonames in shared libraries -- I think I did the right thing - put back american as the default -- british dicts are non-free. firefox-0:1.0.1-1 ----------------- * Thu Feb 24 2005 Christopher Aillon 0:1.0.1-1 - Update to 1.0.1 fixing several security flaws. - Temporarily disable langpacks to workaround startup issues (#145806) - Request the correct system colors from gtk (#143423) gnome-pilot-2.0.12-5 -------------------- * Fri Feb 25 2005 Than Ngo 2.0.12-5 - fix broken desktop file ipsec-tools-0.5-1 ----------------- * Wed Feb 23 2005 Bill Nottingham 0.5-1 - update to 0.5 kernel-2.6.10-1.1154_FC4 ------------------------ * Fri Feb 25 2005 Dave Jones - Hopefully fix the zillion unresolved symbols. (#149758) krb5-1.4-1 ---------- * Thu Feb 24 2005 Nalin Dahyabhai 1.4-1 - update to 1.4 - v1.4 kadmin client requires a v1.4 kadmind on the server, or use the "-O" flag to specify that it should communicate with the server using the older protocol - new libkrb5support library - v5passwdd and kadmind4 are gone - versioned symbols - pick up $KRB5KDC_ARGS from /etc/sysconfig/krb5kdc, if it exists, and pass it on to krb5kdc - pick up $KADMIND_ARGS from /etc/sysconfig/kadmin, if it exists, and pass it on to kadmind - pick up $KRB524D_ARGS from /etc/sysconfig/krb524, if it exists, and pass it on to krb524d *instead of* "-m" - set "forwardable" in [libdefaults] in the default krb5.conf to match the default setting which we supply for pam_krb5 - set a default of 24h for "ticket_lifetime" in [libdefaults], reflecting the compiled-in default libsepol-1.3.6-3 ---------------- * Fri Feb 18 2005 Dan Walsh 1.3.6-3 - Make sure local_files file pointer is closed - Stop outputing error messages mailman-3:2.1.5-33.fc4 ---------------------- * Fri Feb 25 2005 John Dennis - 3:2.1.5-33.fc4 - fix bug #147833, CAN-2004-1177 pam_krb5-2.1.3-1 ---------------- * Fri Feb 25 2005 Nalin Dahyabhai - 2.1.3-1 - update to 2.1.3 policycoreutils-1.21.20-2 ------------------------- * Thu Feb 24 2005 Dan Walsh 1.21.20-2 - Fix genhomedircon to handle blank users * Thu Feb 24 2005 Dan Walsh 1.21.20-1 - Update to latest from NSA - Add call to libsepol pvm-3.4.5-2_FC4 --------------- * Fri Feb 25 2005 Jason Vas Dias 3.4.5-2_FC4 - Fix bug 147337 - invalid format string in pvmlog.c - make version compare > that of FC3 radvd-0.7.3-1_FC4 ----------------- * Fri Feb 25 2005 Jason Vas Dias 0.7.3-1_FC4 - make version compare > that of FC3 rpmdb-fedora-1:4-0.20050226 --------------------------- selinux-policy-strict-1.21.15-3 ------------------------------- * Fri Feb 25 2005 Dan Walsh 1.21.15-3 - Add transitions to dhcpc - Remove serviceusers - Fixes for mta in targeted * Thu Feb 24 2005 Dan Walsh 1.21.15-1 - Update from NSA selinux-policy-targeted-1.21.15-3 --------------------------------- * Fri Feb 25 2005 Dan Walsh 1.21.15-3 - Add transitions to dhcpc - Remove serviceusers - Fixes for mta in targeted * Thu Feb 24 2005 Dan Walsh 1.21.15-1 - Update from NSA * Mon Feb 21 2005 Dan Walsh 1.21.14-2 - Lots of fix patches from Ivan shadow-utils-2:4.0.3-59 ----------------------- * Fri Feb 25 2005 Peter Vrabec 2:4.0.3-59 - static limit on group count to dynamic (#125510, #148994, #147742) * Mon Feb 21 2005 Peter Vrabec 2:4.0.3-58 - add "-l" option #146214 sysreport-1.4.0-1 ----------------- * Fri Feb 25 2005 Than Ngo 1.4.0-1 - Fix typo in collection of iptables #142992 - Add fix to always call hardware.py #144999 - Add the collection of /etc/nsswitch.conf bug #136717 - Add chkconfig type information to sysreport bug #136699 - Add the collection of information about a samba server config #136575 - Add the collection of LDAP client and server configuration information #136719 - Add the collection of /proc/slabinfo #139558 - Add the collection of syslog configuration - Add the collection of ntp configuration - Add the collection of mdadm.conf #136722 - Add the collection of lsof output - Add the collection of postfix configuration files - Add the collection of squid configuration files - Add the collection of automount configuration files - Add the collection of NFS export file - Add the collection of yp configuration files - Add the collection of kerberos configuration files - Add the collection of CUPS configuration files - Add the collection of apache configuration files - Add the collection of /var/log/secure - Add the collection of modinfo for all loaded modules - Add the collection of satellite-debug and rhn-proxy-debug - Add the collection of /etc/modprobe.conf #149651 tcsh-6.13-12 ------------ * Fri Feb 25 2005 Miloslav Trmac - 6.13-12 - Don't ship the HTML documentation (generated from the man page, contains also a copy of the man page) util-linux-2.12p-2 ------------------ * Fri Feb 25 2005 Steve Dickson 2.12p-2 - Changed nfsmount to only use reserve ports when necessary (bz# 141773) vixie-cron-1:4.1-24_FC4 ----------------------- * Fri Feb 25 2005 Jason Vas Dias - 4.1-24_FC4 - Add an /etc/sysconfig/crond file for containing CRONDARGS and - settings like CRON_VALIDATE_MAILRCPTS . * Fri Feb 25 2005 Jason Vas Dias - 4.1-24_FC4 - Fix bug 147636 - disable silly mail recipient name checking - (do_command.c's safe_p()) by default . Can be enabled by - presence of CRON_VALIDATE_MAILRCPTS variable in crond's - environment - also '_'s in MAILTOs are allowed. xscreensaver-1:4.18-19 ---------------------- * Fri Feb 25 2005 Nalin Dahyabhai 1:4.18-19 - We don't patch configure.in, so we don't need to run 'autoconf'. - Add --without-kerberos to skip built-in Kerberos password verification, so that we'll always go through PAM (fixes 149731). From malists at epon.ro Sat Feb 26 14:56:47 2005 From: malists at epon.ro (Marius Andreiana) Date: Sat, 26 Feb 2005 16:56:47 +0200 Subject: writing zero bytes in bash In-Reply-To: <200502261832.16337.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> Message-ID: <1109429807.3469.7.camel@marte.biciclete.ro> On Sat, 2005-02-26 at 18:32 +1100, Russell Coker wrote: > To unset the fscreate or exec context you have to write zero bytes > to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. > > If you want to do this in a shell script you would do something like: > echo -n "" > /proc/self/attr/fscreate what about > /proc/self/attr/fscreate ? -- Marius Andreiana Epon Business Applications http://www.epon.ro From jspaleta at gmail.com Sat Feb 26 15:04:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 10:04:29 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <422086A8.7020200@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> Message-ID: <604aa79105022607043d109bf1@mail.gmail.com> On Sat, 26 Feb 2005 09:24:40 -0500, Eric Warnke wrote: > freeglut - library with no dependancy in core Cough in the developmnent tree....libtiff rpm -q --requires libtiff libglut.so.3 rpm -q --whatprovides libglut.so.3 freeglut-2.2.0-14 how are you checking for deps? the libtiff deps isnt somthing obscure.. its required by gtk2. I just want to make sure you aren't wasting your time using a depcheck method thats going to be highly unreliable. Are you looking at the deps in fc3 or in rawhide? I'm not sure looking at the dep chains in fc3 gives an accurate picture for the sake of this discussion. > dasher - obscure alternate input method ! 10MB uhm... thats almost an offensive comment... a11y elements are very important... just be glad you don't need them. > Possible without objections > Guppi used by gnucash.... how are you checking for deps? Even in fc3 this is a requirement. rawhide: libguppi.so.16 is needed by (installed) gnucash-1.8.11-1.i386 libguppitank.so.16 is needed by (installed) gnucash-1.8.11-1.i386 fc3: libguppi.so.16 is needed by (installed) gnucash-1.8.9-2.i386 libguppitank.so.16 is needed by (installed) gnucash-1.8.9-2.i386 > ccs - cluster config? if you don't understand the function perhaps its best not to list as being removable. > freeradius - complex package d:0 how is complexity a reason to drop it? apache is pretty complex as well. either make the duplication argument or make the argument that its unneeded in core. > h2ps - another postscript generator D:0 Are you saying that other cli postscript generators can convert Hangul and thus overlap in functionality? -jef From eric at snowmoon.com Sat Feb 26 15:17:12 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 10:17:12 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <604aa79105022607043d109bf1@mail.gmail.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> Message-ID: <422092F8.4050003@snowmoon.com> Jeff, This was meant to spark discussion... not to be the end all be all. Jeff Spaleta wrote: > how are you checking for deps? the libtiff deps isnt somthing > obscure.. its required by gtk2. > I just want to make sure you aren't wasting your time using a depcheck > method thats going to be highly unreliable. Are you looking at the > deps in fc3 or in rawhide? I'm not sure looking at the dep chains in > fc3 gives an accurate picture for the sake of this discussion. I could not find a rpmdb for rawhide. If you wish to send me one I would be more than happy to use it. I have been using rpm -w --whatrequires under the full fc3 rpmdb. >>dasher - obscure alternate input method ! 10MB > > uhm... thats almost an offensive comment... a11y elements are very > important... just be glad you don't need them. If it is used by kde or gnomes accessability feature and used by someone ( anyone ) I will remove it from consiteration. Your other objections are noted, but I stand by freeradius as a specialty package probably better served in extras. Cheers, Eric -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From ronny-vlug at vlugnet.org Sat Feb 26 15:23:09 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sat, 26 Feb 2005 16:23:09 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <422086A8.7020200@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> Message-ID: <200502261623.09369.ronny-vlug@vlugnet.org> On Saturday 26 February 2005 15:24, Eric Warnke wrote: > dovecot - IPAP server - 2 objections, but if you can server to the > internet, you can download it from extras. Ether this or cyrus should > be cut. I second removing cyrus from Core as it is really special purpose. -- http://LinuxWiki.org/RonnyBuchmann From jspaleta at gmail.com Sat Feb 26 15:29:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 10:29:53 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <422092F8.4050003@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> Message-ID: <604aa791050226072922a7d0cc@mail.gmail.com> On Sat, 26 Feb 2005 10:17:12 -0500, Eric Warnke wrote: > If it is used by kde or gnomes accessability feature and used by someone > ( anyone ) I will remove it from consiteration. I'm pretty sure the entire point of dasher is related to accessibility. man dasher ... Control mode Provides a control node at the bottom of the screen. This allows various tasks to be performed inside Dasher, such as editing the text written, speaking entered text and stopping or pausing Dasher. If compiled with and using a desktop supporting the ATK accessibility framework, compliant applications will have their menu trees exported to Dasher and these may be accessed via this node. As soon as you play with it.. and configure it to enable the control mode...you'll see control elements apear in the interface and not just alphabet. -jef From russell at coker.com.au Sat Feb 26 15:34:33 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 27 Feb 2005 02:34:33 +1100 Subject: writing zero bytes in bash In-Reply-To: <1109429807.3469.7.camel@marte.biciclete.ro> References: <200502261832.16337.russell@coker.com.au> <1109429807.3469.7.camel@marte.biciclete.ro> Message-ID: <200502270234.36513.russell@coker.com.au> On Sunday 27 February 2005 01:56, Marius Andreiana wrote: > On Sat, 2005-02-26 at 18:32 +1100, Russell Coker wrote: > > To unset the fscreate or exec context you have to write zero bytes > > to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. > > > > If you want to do this in a shell script you would do something like: > > echo -n "" > /proc/self/attr/fscreate > > what about > > > /proc/self/attr/fscreate > > ? What is it about this thread that is generating the one-word emails? Your message doesn't contain anything I can interpret, I'm not sure if you are trying to make a point or ask a question. If it's a SE Linux question you want to ask, you've removed from the CC list the one address that's best 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 shiva at sewingwitch.com Sat Feb 26 17:00:43 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 26 Feb 2005 09:00:43 -0800 Subject: Why is sendmail bad? In-Reply-To: <1109288482.17967.28.camel@jdub.homelinux.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> Message-ID: <79FAA82857A03335BDEE9331@[10.0.0.4]> --On Thursday, February 24, 2005 5:41 PM -0600 Josh Boyer wrote: > Eventually. I was in a situation where I switched ISPs and didn't have > an email address anymore. I hate hotmail, and didn't have access to > gmail yet. So, I got a mail server running as fast as I could. _Then_ > I learned more about it. Note that that's another argument for relegating *all* the MTA's to Extras and shipping a dirt-simple SMTP pass-through that does little more than proxy local mail requests to the ISP or company server. From shiva at sewingwitch.com Sat Feb 26 17:05:11 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 26 Feb 2005 09:05:11 -0800 Subject: Why is sendmail bad? In-Reply-To: <20050224213500.GJ28055@angus.ind.WPI.EDU> References: <20050224213500.GJ28055@angus.ind.WPI.EDU> Message-ID: --On Thursday, February 24, 2005 4:35 PM -0500 "Chuck R. Anderson" wrote: > In my environment, on 99% of all systems, I've never needed anything > but a simple queue-to-smarthost mail sending daemon, with no receive > functionality at all. Therefore, I don't care which mail daemon is > included, as long as it can do that and supports some type of > /etc/aliases file. I'd actually prefer to see a simple ssmtp-like > program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't > expand local aliases). I can understand queuing, in case the real server is down. That can be the simple-minded queuing implemented by most MUA's. But why aliases? Shouldn't those also be handled by the real server? I'd guess that we could take the SMTP back end off an MUA and call it "sendmail" for application compatibility and ship that. From jwboyer at jdub.homelinux.org Sat Feb 26 17:14:27 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 26 Feb 2005 11:14:27 -0600 Subject: Why is sendmail bad? In-Reply-To: <79FAA82857A03335BDEE9331@[10.0.0.4]> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> Message-ID: <1109438068.17967.31.camel@jdub.homelinux.org> On Sat, 2005-02-26 at 09:00 -0800, Kenneth Porter wrote: > --On Thursday, February 24, 2005 5:41 PM -0600 Josh Boyer > wrote: > > > Eventually. I was in a situation where I switched ISPs and didn't have > > an email address anymore. I hate hotmail, and didn't have access to > > gmail yet. So, I got a mail server running as fast as I could. _Then_ > > I learned more about it. > > Note that that's another argument for relegating *all* the MTA's to Extras > and shipping a dirt-simple SMTP pass-through that does little more than > proxy local mail requests to the ISP or company server. Not really. My ISP gives me a line and an IP address. That's it. I don't have access to any of their mail servers. So I needed an MTA that could both send and receive on it's own, and not proxy through anything. josh From cra at WPI.EDU Sat Feb 26 17:23:30 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 26 Feb 2005 12:23:30 -0500 Subject: Why is sendmail bad? In-Reply-To: References: <20050224213500.GJ28055@angus.ind.WPI.EDU> Message-ID: <20050226172330.GB21024@angus.ind.WPI.EDU> On Sat, Feb 26, 2005 at 09:05:11AM -0800, Kenneth Porter wrote: > I can understand queuing, in case the real server is down. That can be the > simple-minded queuing implemented by most MUA's. But why aliases? Shouldn't > those also be handled by the real server? System daemons and server applications often send mail to system accounts. These and root mail need to be aliased to a real person who is going to be reading the mail from them. The mappings are often server-specific, or at least department-specific, and cannot be stored on the central mail server. I'm not talking about huge mailing lists or hosting virtual mail accounts, just providing the basic functionality that the default /etc/aliases from sendmail demonstrates. From eric at snowmoon.com Sat Feb 26 17:24:18 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 12:24:18 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <422092F8.4050003@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> Message-ID: <4220B0C2.2060007@snowmoon.com> Please post feedback. All objections noted. Please tell me why any of these items should stay in core. Most should probably end up in extras with a few that can probably drop off all together at this point. This list was based on my own review of .src.rpm's in testing. I am not running testing, so ther may be small issues with some of the items, please contact me directly if I miscalculated. This is based on core being a small and stable platform with little diplication. Many pacakages would probably do better in extras too with the possibility of more maintainers. Once I have sufficient feedback I will forward this list on to the technical board for consiteration. Please positive feedback only. Removed from consiteration ccs - cluster config? Guppi electricfence - multiplatform .. see new additions doxygen - core must be self hosting Xaw3d - required by emacs and emacs is being kept bogl* - kernel 2.2 fb graphics lib d:0 ( should update dependancies here if it's required by the installer! ) epic/irssi? epic is there and it's the only text mode irc client unless we want to swap it out for irssi dasher - alternate input method h2ps - should let people that use multinational tools decide which one go and which ones stay Ojections, but I still believe could be moved. *freeglut - library with no dependancy in core. libtiff requirement can be corrected. I am working on a patch or updated spec file.* *dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot.* lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras. SDL - kdeaddons is the only thing that depends on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras. + kdeaddons - small add on packages. not 100% necessary. *New additions to the likley list* w3m/w3m-el - another text pager/web browser usermode/utempter - overlaps with sudo tora - packaged without oracle plugin and does appear to work out of the box with MySQL or postgress. tix - Tcl/Tk extansion routed - appears to be superceeded by quagga qmkbootdisk - graphical boot disk creation utiltiy - stale ots - was used as part of abiword, but abiword has been religated to extras nut - nice package, but is it really core materal? nss_db - partly broken. Most usefulness gone now that nscd is standard ( I will personally manage since I wrote the fix ) dosfttools - looks like mtools superceeds this package. mew - emailing in emacs strace - looks like ltrace provides same functionality dmalloc, valgrind - electricence appears to be more compatible and better developed. fsh - obscure shell, features absorbed into OpenSSH giftrans - netpbm tools can do the same iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / pico / emacs / ed / vi ) lftp - useful ftp client ( ftp, ncftp ) D:0 nedit - another x text editor Likley without objections Canna - Superceeded by IIMF - nothing depends ! 10MB MAKEDEV - Superceeded by udev ? *VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility + MagicPoint - Duplicated functionality already in other packages a2ps - text to postscript tool required by xfprint awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0 Possible without objections talk - protocol is getting old with IM star - tar with acl support. planner - anther project managment tool pinfo - another text info file browser - do we need two? cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 freeradius - complex package d:0 ftpcopy - utility D:0. I have never used it do we need in core g-wrap - Another wrapper for a development utility d:0 mc - Is this really a core util? would it be better served in extras? Cheers, Eric -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Sat Feb 26 17:25:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 12:25:09 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <42207BEB.7020000@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: <20050226172509.GA27412@jadzia.bu.edu> On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote: > dovecot - IPAP server - 2 objections, but if you can server to the > internet, you can download it from extras. Ether this or cyrus should > be cut. cyrus, then. Dovecot is more general-purpose. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwmw2 at infradead.org Sat Feb 26 17:30:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 26 Feb 2005 17:30:17 +0000 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <1109439019.26364.259.camel@localhost.localdomain> On Sat, 2005-02-26 at 12:24 -0500, Eric Warnke wrote: >fsh - obscure shell, features absorbed into OpenSSH Some scripts will use this but relatively few. This is one of the cases where the FC3 package doesn't actually work on FC4, though -- it'll break in an upgrade. I'd like to see it die in FC5 -- OpenSSH needs to completely provide the same functionality first though. OpenSSH doesn't yet have the capacity to automatically decide whether to be the 'master' and open the first connection, or whether to be the 'slave' and use an existing connection. Neither does it hold the connection open with a timeout. Not hard to fix -- but since fsh is only 161KiB, it hasn't been a huge priority. We don't gain much by dropping it, but I'd like to say in the release notes that it's deprecated, so that we can drop it from FC5. Although by FC5 we can just move it into Extras without too much upgrade pain anyway. -- dwmw2 From cra at WPI.EDU Sat Feb 26 17:31:43 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 26 Feb 2005 12:31:43 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109399272l.7697l.9l@devel.mpeters.us> References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> Message-ID: <20050226173143.GC21024@angus.ind.WPI.EDU> On Sat, Feb 26, 2005 at 06:27:52AM +0000, Michael A. Peters wrote: > >lynx - duplicate effort ( elinks ) > > keep lynx - a lot of existing scripts depend upon it, lynx really is > almost as standard on *nix as vi - it is THE cli http client. Is elinks command-line compatible to lynx? It it is, I would prefer to see elinks, as it renders pages much better (supports frames and tables, etc). From cra at WPI.EDU Sat Feb 26 17:35:41 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 26 Feb 2005 12:35:41 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <42207BEB.7020000@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: <20050226173541.GD21024@angus.ind.WPI.EDU> On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote: > doxygen - Sorce code documentation generator D:0 - 1 objecton - I don't > think we necessarly need to keep every build dependancy in core. Of course we do. Core needs to be able to build itself. From mattdm at mattdm.org Sat Feb 26 17:39:08 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 12:39:08 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <20050226173908.GB27412@jadzia.bu.edu> On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote: > usermode/utempter - overlaps with sudo Is there a GUI front-end for sudo? (And, ideally, a good API for editing its config file?) These are definitely both different approaches to the same problem, but currently, they both have various strengths and weaknesses. Significant work would have to go into one of them in order to drop one. Although, since sudo isn't configured by default or used by anything, it's possible *that's* a candidate. > strace - looks like ltrace provides same functionality nope! > pinfo - another text info file browser - do we need two? the other one really sucks. > mc - Is this really a core util? would it be better served in extras? It was the gnome desktop manager before nautilus. I assume that's why it's still around. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mitr at volny.cz Sat Feb 26 17:42:06 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 26 Feb 2005 18:42:06 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <20050226174202.GA2935@chrys.ms.mff.cuni.cz> On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote: > Please positive feedback only. What does this mean? > usermode/utempter - overlaps with sudo I thought utempter does something completely different... usermode-gtk provides the "type root password to run system-config-*" in X; while it does "overlap" with sudo, it can't be _replaced_ by sudo. > nut - nice package, but is it really core materal? It is one of the basic utilities needed on a "serious" server of any kind. > dosfttools - looks like mtools superceeds this package. The other way around - mounting is more useful than mcopy. But _both_ are required for mkbootdisk. > MAKEDEV - Superceeded by udev ? Required by udev, actually. > talk - protocol is getting old with IM UNIX kernel interface is "getting old" too. > planner - anther project managment tool "Another"? What is the alternative? > g-wrap - Another wrapper for a development utility d:0 Required by gnucash. (The simplest way to test dependencies of a package against a rpmdb is probably (rpm --dbpath ... -e --test $package). This takes into account all the provides: in a package.) Mirek From mattdm at mattdm.org Sat Feb 26 17:45:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 12:45:31 -0500 Subject: Why is sendmail bad? In-Reply-To: <79FAA82857A03335BDEE9331@[10.0.0.4]> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> Message-ID: <20050226174531.GC27412@jadzia.bu.edu> On Sat, Feb 26, 2005 at 09:00:43AM -0800, Kenneth Porter wrote: > Note that that's another argument for relegating *all* the MTA's to Extras > and shipping a dirt-simple SMTP pass-through that does little more than > proxy local mail requests to the ISP or company server. By this argument, should *all* servers be moved to Extras? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sat Feb 26 17:48:03 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 12:48:03 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <20050226173143.GC21024@angus.ind.WPI.EDU> References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> <20050226173143.GC21024@angus.ind.WPI.EDU> Message-ID: <20050226174803.GD27412@jadzia.bu.edu> On Sat, Feb 26, 2005 at 12:31:43PM -0500, Chuck R. Anderson wrote: > Is elinks command-line compatible to lynx? It it is, I would prefer > to see elinks, as it renders pages much better (supports frames and > tables, etc). Honestly, that's why I like to have lynx around: "what would this look like to someone who for accessability reasons needs to use a tool that can't handle frames?". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From eric at snowmoon.com Sat Feb 26 17:51:54 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 12:51:54 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <20050226174803.GD27412@jadzia.bu.edu> References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> <20050226173143.GC21024@angus.ind.WPI.EDU> <20050226174803.GD27412@jadzia.bu.edu> Message-ID: <4220B73A.3000201@snowmoon.com> It's best to use real screen readers as tests, since many of them handle quite a bit of markup these days. Many gecko tools also give you stlye-less views or degraded viewing of pages. I'm also just suggesting that these move to extras, not gone all together. Matthew Miller wrote: > Honestly, that's why I like to have lynx around: "what would this look like > to someone who for accessability reasons needs to use a tool that can't > handle frames?". > -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From dwmw2 at infradead.org Sat Feb 26 17:55:11 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 26 Feb 2005 17:55:11 +0000 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109399987.27384.33.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> Message-ID: <1109440511.25030.11.camel@localhost.localdomain> On Sat, 2005-02-26 at 01:39 -0500, seth vidal wrote: >hey, wait a second. You're a programmer aren't you? would you like to >contribute to fedora extras? I bet you could come up with a way to make >isos from Fedora Extras! Making ISOs from Extras isn't hard, and isn't the problem. Please do try to keep up with the conversation. The problem is not just that there are no ISOs of Extras yet -- the problem is that that anaconda won't handle external repositories until FC5, whether you can get them onto an ISO or not. >That's fantastic, thanks for volunteering instead of just being another >complaining voice w/o a solution. You're being deliberately misleading again. Alex offered his preferred solution on fedora-maintainers list, and isn't 'just complaining'. Look for Message-ID I fully support Fedora Extras. I've set up a build box for Extras on FC3/PPC and have made a yum repository available. I'm currently trying to work out where to find a spare build box (or enough disk space for a buildroot) for the FC4 version. I'll make ISOs for it when anaconda can handle them too. But that's not the stumbling block. Extras is good -- but it's not workable _yet_ as a mechanism for dumping packages from Core. Packages we dump now, we have to accept that they _are_ being dumped, just like the packages which were dumped for FC2. We can't excuse it on the basis that "Extras will pick them up". That doesn't work until FC5. -- dwmw2 From twaugh at redhat.com Sat Feb 26 17:54:26 2005 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 26 Feb 2005 17:54:26 +0000 Subject: writing zero bytes in bash In-Reply-To: <200502261832.16337.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> Message-ID: <20050226175426.GJ3626@redhat.com> On Sat, Feb 26, 2005 at 06:32:13PM +1100, Russell Coker wrote: > To unset the fscreate or exec context you have to write zero bytes > to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. Oh dear, really? How badly designed. The man page for write() says that writing no bytes causes write() to return 0 "without causing any other effect". Tim. */ -------------- 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 Sat Feb 26 18:01:36 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 26 Feb 2005 13:01:36 -0500 Subject: writing zero bytes in bash In-Reply-To: <200502270234.36513.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> <1109429807.3469.7.camel@marte.biciclete.ro> <200502270234.36513.russell@coker.com.au> Message-ID: <20050226180136.GF21024@angus.ind.WPI.EDU> On Sun, Feb 27, 2005 at 02:34:33AM +1100, Russell Coker wrote: > > what about > > > > > /proc/self/attr/fscreate > > > > ? > > What is it about this thread that is generating the one-word emails? > Your message doesn't contain anything I can interpret, I'm not sure if you are > trying to make a point or ask a question. I think he meant "> /proc/self/attr/fscreate", but this doesn't appear to write either: 4841 open("/proc/self/attr/fscreate", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 4841 fcntl64(1, F_GETFD) = 0 4841 fcntl64(1, F_DUPFD, 10) = 10 4841 fcntl64(1, F_GETFD) = 0 4841 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 4841 dup2(3, 1) = 1 4841 close(3) = 0 From cra at WPI.EDU Sat Feb 26 18:08:09 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 26 Feb 2005 13:08:09 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> Message-ID: <20050226180809.GG21024@angus.ind.WPI.EDU> On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote: > lftp - useful ftp client ( ftp, ncftp ) D:0 I think ncftp should be the one to be removed from Core. lftp has more functionality (http), and is installed by default, whereas ncftp is not installed by default. Also, while ncftp itself is OSS (Clarified Artistic License), other components from the same company are not (NcFTPd server, libNcFTP). > Possible without objections > talk - protocol is getting old with IM vi, ed, and ex are old too. Should we remove them? > star - tar with acl support. Do tar or pax provide equivalent functionality? From Nicolas.Mailhot at laPoste.net Sat Feb 26 18:15:09 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 26 Feb 2005 19:15:09 +0100 Subject: Why is sendmail bad? In-Reply-To: <79FAA82857A03335BDEE9331@[10.0.0.4]> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> Message-ID: <1109441709.5970.15.camel@rousalka.dyndns.org> Le samedi 26 f?vrier 2005 ? 09:00 -0800, Kenneth Porter a ?crit : >--On Thursday, February 24, 2005 5:41 PM -0600 Josh Boyer > wrote: > >> Eventually. I was in a situation where I switched ISPs and didn't have >> an email address anymore. I hate hotmail, and didn't have access to >> gmail yet. So, I got a mail server running as fast as I could. _Then_ >> I learned more about it. > >Note that that's another argument for relegating *all* the MTA's to Extras >and shipping a dirt-simple SMTP pass-through that does little more than >proxy local mail requests to the ISP or company server. You can do this with one well-documented declaration in postfix (relayhost), I suppose exim is as esay to setup. The nice thing about a full-featured MTA with real local queues is your mail will still pass through when your ISP decides to do a big advertising campaign without upgrading its network first. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Sat Feb 26 18:21:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 13:21:50 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109440511.25030.11.camel@localhost.localdomain> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> <1109440511.25030.11.camel@localhost.localdomain> Message-ID: <1109442111.27384.101.camel@cutter> >Making ISOs from Extras isn't hard, and isn't the problem. Please do try >to keep up with the conversation. okay david, have a nice day. -sv From jspaleta at gmail.com Sat Feb 26 18:19:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 13:19:29 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <604aa79105022610197382aa86@mail.gmail.com> On Sat, 26 Feb 2005 12:24:18 -0500, Eric Warnke wrote: > usermode/utempter - overlaps with sudo usermode is acutually used by every system-config tool utempter is needed by libgnome and xorg-x11 packages nothing uses sudo... though i imagine many users do. > tix - Tcl/Tk extansion required by tkinter.. as soon as tkinter is dropped this will go. without complaint i would imagine > nut - nice package, but is it really core materal? as much a piece of core as any server oriented package. Get apache booted out first and I'll agree. > nss_db - partly broken. Most usefulness gone now that nscd is standard ( > dosfttools - looks like mtools superceeds this package. needed by mkbootdisk mtools needed by syslinux get the syslinux and the mkbootdisk maintainers to agree on one or the other if possible before talking about removing one of them. Though honestly i don't see how the binaries in mtools superceed the binaries in dosfstools. /sbin/fsck.vfat seems rather important at first glance. > lftp - useful ftp client ( ftp, ncftp ) D:0 if yer gonna drop one drop ftp or ncftp instead.. lftp handles ftp and http, > MAKEDEV - Superceeded by udev ? required by udev > a2ps - text to postscript tool required by xfprint xfprint is no longer in the development tree.. > freeradius - complex package d:0 I objected.. i continue to object. This is a poor argument. Either point to a package this duplicates or make an argument that this functionality shouldnt be in core. No matter how complex the service is.. it provides functionality for server configurations. > mc - Is this really a core util? would it be better served in extras? there are many console oriented applications in Core... is there a reason why there should text console filemanager as well? We have console text editors and web browsers... why not a filemanager as well? -jef From Nicolas.Mailhot at laPoste.net Sat Feb 26 18:20:53 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 26 Feb 2005 19:20:53 +0100 Subject: Why is sendmail bad? In-Reply-To: References: <20050224213500.GJ28055@angus.ind.WPI.EDU> Message-ID: <1109442053.5970.21.camel@rousalka.dyndns.org> Le samedi 26 f?vrier 2005 ? 09:05 -0800, Kenneth Porter a ?crit : >--On Thursday, February 24, 2005 4:35 PM -0500 "Chuck R. Anderson" > wrote: > >> In my environment, on 99% of all systems, I've never needed anything >> but a simple queue-to-smarthost mail sending daemon, with no receive >> functionality at all. Therefore, I don't care which mail daemon is >> included, as long as it can do that and supports some type of >> /etc/aliases file. I'd actually prefer to see a simple ssmtp-like >> program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't >> expand local aliases). > >I can understand queuing, in case the real server is down. That can be the >simple-minded queuing implemented by most MUA's. But why aliases? Shouldn't >those also be handled by the real server? You can always get by with your provider if you pay more. Often you have to play tricks when you only have a basic residential access. In my case that means real queues + aliases + address rewriting + sasl auth + use of port 24 not 25. I'd be surprised if I where alone in this case. To fight spamming and worms ISP put in place all sorts of creative annoyances that mean you really need a smart MTA if you don't want to be reduced to webmail. 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 ronny-vlug at vlugnet.org Sat Feb 26 18:19:46 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sat, 26 Feb 2005 19:19:46 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226173908.GB27412@jadzia.bu.edu> References: <422007DD.1020404@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226173908.GB27412@jadzia.bu.edu> Message-ID: <200502261919.47152.ronny-vlug@vlugnet.org> On Saturday 26 February 2005 18:39, Matthew Miller wrote: > > mc - Is this really a core util? would it be better served in extras? > > It was the gnome desktop manager before nautilus. I assume that's why it's > still around. A lot of people use that kind of file manager (and it's AFAICT the only text mode file manager in Core) -- http://LinuxWiki.org/RonnyBuchmann From skvidal at phy.duke.edu Sat Feb 26 18:25:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 13:25:47 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <1109442347.27384.104.camel@cutter> >jed - another text mode editor - we already discussed moving this to extras >joe - yet another text editor ( nano / pico / emacs / ed / vi ) nano doesn't do utf8 afaict, pico isn't in the distribution (it's pine) emacs is almost it's own operating system ed doesn't count and you know it vi is not an editor I'm fine with moving joe to extras personally but it does fill a place nothing else fills. -sv From feliciano.matias at free.fr Sat Feb 26 18:21:41 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 26 Feb 2005 19:21:41 +0100 Subject: writing zero bytes in bash In-Reply-To: <200502262139.45861.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> <200502261048.28448.mihai@xcyb.org> <200502262139.45861.russell@coker.com.au> Message-ID: <1109442102.4312.9.camel@one.myworld> Le samedi 26 f?vrier 2005 ? 21:39 +1100, Russell Coker a ?crit : > Actually I am not asking for a feature to be added, but for a feature to be > removed. There is special-case code in bash if(size >0) write() and I am > merely suggesting that the if statement be removed. > Writing nothing is not writing ? Look at this : $ cat titi cat: titi: No such file or directory No file => no cat No data => no write -------------- 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 ronny-vlug at vlugnet.org Sat Feb 26 18:21:55 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sat, 26 Feb 2005 19:21:55 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226174202.GA2935@chrys.ms.mff.cuni.cz> References: <422007DD.1020404@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226174202.GA2935@chrys.ms.mff.cuni.cz> Message-ID: <200502261921.55723.ronny-vlug@vlugnet.org> On Saturday 26 February 2005 18:42, Miloslav Trmac wrote: > > dosfttools - looks like mtools superceeds this package. > > The other way around - mounting is more useful than mcopy. > But _both_ are required for mkbootdisk. I thought boot disks are not possibke anyway? Maybe we can remove all of this. -- http://LinuxWiki.org/RonnyBuchmann From cra at WPI.EDU Sat Feb 26 18:26:25 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sat, 26 Feb 2005 13:26:25 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <1109442347.27384.104.camel@cutter> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <1109442347.27384.104.camel@cutter> Message-ID: <20050226182625.GI21024@angus.ind.WPI.EDU> On Sat, Feb 26, 2005 at 01:25:47PM -0500, seth vidal wrote: > vi is not an editor What is it then? From Nicolas.Mailhot at laPoste.net Sat Feb 26 18:29:04 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 26 Feb 2005 19:29:04 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <422086A8.7020200@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> Message-ID: <1109442544.5970.26.camel@rousalka.dyndns.org> BTW in a related topic if the arts part could be spun out of gstreamer-plugins this system could run without qt installed. It'd be easier to drop out suff later if it's not deeply linked like this Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sat Feb 26 18:33:23 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 26 Feb 2005 19:33:23 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <1109442804.5970.31.camel@rousalka.dyndns.org> Le samedi 26 f?vrier 2005 ? 12:24 -0500, Eric Warnke a ?crit : >*dovecot/cryus - IMAP server cyrus does seem more like a specialty >package when compared to the simplcity and utility of dovecot.* Therefore dovecot and cyrus do not really overlap. Unlike all the console web browsers for example they target widely different publics. (cyrus could certainly be in extras but I believe it needs to be maintained for RHEL and it seems all the linux "exchage killers" rely on it one way or the other. Plus I may be wrong but cyrus auth libs are used by other packages) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sat Feb 26 18:35:04 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 26 Feb 2005 19:35:04 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226180809.GG21024@angus.ind.WPI.EDU> References: <20050226180809.GG21024@angus.ind.WPI.EDU> Message-ID: <1109442905.5970.33.camel@rousalka.dyndns.org> Le samedi 26 f?vrier 2005 ? 13:08 -0500, Chuck R. Anderson a ?crit : >On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote: >> lftp - useful ftp client ( ftp, ncftp ) D:0 > >I think ncftp should be the one to be removed from Core. lftp has >more functionality (http), and is installed by default, whereas ncftp >is not installed by default. Also, while ncftp itself is OSS >(Clarified Artistic License), other components from the same company >are not (NcFTPd server, libNcFTP). +1 for keeping lftp and moving ncftp out. This is way overdue. 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 jspaleta at gmail.com Sat Feb 26 18:38:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 13:38:02 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <1109442804.5970.31.camel@rousalka.dyndns.org> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <1109442804.5970.31.camel@rousalka.dyndns.org> Message-ID: <604aa79105022610384493a0c3@mail.gmail.com> On Sat, 26 Feb 2005 19:33:23 +0100, Nicolas Mailhot wrote: > (cyrus could certainly be in extras but I believe it needs to be > maintained for RHEL and it seems all the linux "exchage killers" rely on > it one way or the other. Plus I may be wrong but cyrus auth libs are > used by other packages) cyrus-sasl is a requirement for some important items like openldap and sendmail and even mutt. -jef From fedora at wir-sind-cool.org Sat Feb 26 18:49:11 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 26 Feb 2005 19:49:11 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <20050226194911.2364cf7f.fedora@wir-sind-cool.org> On Sat, 26 Feb 2005 12:24:18 -0500, Eric Warnke wrote: > Possible without objections > mc - Is this really a core util? would it be better served in extras? Considering that it was re-added to RHEL 4, yes. From eric at snowmoon.com Sat Feb 26 18:52:45 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 13:52:45 -0500 Subject: Package pruning for FC4 and beyond - question In-Reply-To: <20050226194911.2364cf7f.fedora@wir-sind-cool.org> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226194911.2364cf7f.fedora@wir-sind-cool.org> Message-ID: <4220C57D.3000603@snowmoon.com> Since this is the second time this has come up... Is being part of RHEL reason enough to keep things in core? If that is the case I will exclude from my list all packages that exist in RHEL. Personally I don't think that should be the goal here. If you want RHEL compatibility then get a RHEL knockoff. Cheers Eric Michael Schwendt wrote: > On Sat, 26 Feb 2005 12:24:18 -0500, Eric Warnke wrote: > > >>Possible without objections >>mc - Is this really a core util? would it be better served in extras? > > > Considering that it was re-added to RHEL 4, yes. > -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From feliciano.matias at free.fr Sat Feb 26 18:53:32 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 26 Feb 2005 19:53:32 +0100 Subject: writing zero bytes in bash In-Reply-To: <200502261832.16337.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> Message-ID: <1109444012.6005.13.camel@one.myworld> Le samedi 26 f?vrier 2005 ? 18:32 +1100, Russell Coker a ?crit : > open("/proc/self/attr/exec", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 Perhaps we can consider open("...", O_WRONLY|O_TRUNC, 0666) means : id=open(..., O_WRONLY, ...) ; ftruncate=(id,0) ; write(id,X,0); (?) In this case, there is something "wrong" at the kernel level. open("...", O_WRONLY|O_TRUNC, ...) is like writing/changing a file (except if the file is already empty). -------------- 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 mpeters at mac.com Sat Feb 26 19:10:24 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 26 Feb 2005 19:10:24 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <20050226174803.GD27412@jadzia.bu.edu> (from mattdm@mattdm.org on Sat Feb 26 09:48:03 2005) References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> <20050226173143.GC21024@angus.ind.WPI.EDU> <20050226174803.GD27412@jadzia.bu.edu> Message-ID: <1109445024l.7697l.14l@devel.mpeters.us> On 02/26/2005 09:48:03 AM, Matthew Miller wrote: > Honestly, that's why I like to have lynx around: "what would this > look > like > to someone who for accessability reasons needs to use a tool that > can't > handle frames?". lynx does handle frames. It also handles some CSS. It's a great browser to have on a headless box, and one that a lot of admins of headless boxes expect to be there. -- Michael A. Peters http://mpeters.us/ From eric at snowmoon.com Sat Feb 26 19:12:54 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 14:12:54 -0500 Subject: kickstart NFS install freezing In-Reply-To: <200502261851.05029.russell@coker.com.au> References: <200502261851.05029.russell@coker.com.au> Message-ID: <4220CA36.7010100@snowmoon.com> Russell Coker wrote: > I am doing some tests on a kickstart install of RHEL4 and discovered a problem > with my NFS server, after a large amount of data being transferred it will > lock up the ethernet interface and refuse to talk to the NFS client until the > interface has been deconfigured with "ifconfig down" and then configured > again. Have you investigated plain old hardware problems on the nfs client and server. You should never have to re-config the interface to get it to start working again. Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From aoliva at redhat.com Sat Feb 26 19:21:54 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 16:21:54 -0300 Subject: Package pruning for FC4 and beyond In-Reply-To: <200502261623.09369.ronny-vlug@vlugnet.org> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <200502261623.09369.ronny-vlug@vlugnet.org> Message-ID: On Feb 26, 2005, Ronny Buchmann wrote: > On Saturday 26 February 2005 15:24, Eric Warnke wrote: >> dovecot - IPAP server - 2 objections, but if you can server to the >> internet, you can download it from extras. Ether this or cyrus should >> be cut. > I second removing cyrus from Core as it is really special purpose. +1 dovecot works out of the box. cyrus is useless out of the box, and hardly compatible with anything else in the distro. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From pub at goldshmidt.org Sat Feb 26 21:25:04 2005 From: pub at goldshmidt.org (Oleg Goldshmidt) Date: 26 Feb 2005 21:25:04 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109413576.15854.140.camel@bobcat.mine.nu> References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> <1109413576.15854.140.camel@bobcat.mine.nu> Message-ID: Ville Skytt? writes: > On Sat, 2005-02-26 at 06:27 +0000, Michael A. Peters wrote: > > On 02/25/2005 09:23:41 PM, Eric Warnke wrote: > > > > > + emacs ( pick emacs or xemacs and move the other to extras ) > > > > keep emacs, move xemacs. > > Already done. XEmacs and related stuff will be soon imported to Extras > CVS for FC4+. Would you consider moving only xemacs-sumo (about 3/4 of the whole thing) and keep the core xemacs? FWIW, since someone has voiced a "keep emacs, move xemacs" preference I'd like to register the opposite suggestion ;-). -- Oleg Goldshmidt | pub at NOSPAM.goldshmidt.org | http://www.goldshmidt.org From pub at goldshmidt.org Sat Feb 26 21:17:32 2005 From: pub at goldshmidt.org (Oleg Goldshmidt) Date: 26 Feb 2005 21:17:32 +0000 Subject: FC4 slimfast slimfest In-Reply-To: References: Message-ID: Elliot Lee writes: > Here's a heads up that we need to get rid of about 300M of packages to > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce, > xemacs, cfengine, and all the games are leading candidates. > Nothing is set in stone, but if you want to write in favor of keeping > something, you'll have to suggest something else of equal or greater size > to axe instead. Hi, By all means axe games/eclipse/java/cfengine, but are you seriously considering removing xemacs?? I really don't want to suggest other packages for removal. I hope you'll find a solution that will keep the most essential tool *for me* ;-). If you *absolutely* cannot keep xemacs, how about a compromise: keep xemacs - 9681KB as reported by ftp://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/ - and remove only xemacs-sumo (33611KB)? I have not checked, actually, but it stands to reason that xemacs-sumo depends on xemacs but not the other way around. If you do this, then it would also be nice to put a notice regarding where to get xemacs-sumo in the documentation, and maybe in the default xemacs startup buffer. Regards, -- Oleg Goldshmidt | pub at NOSPAM.goldshmidt.org | http://www.goldshmidt.org From aoliva at redhat.com Sat Feb 26 19:28:41 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 16:28:41 -0300 Subject: writing zero bytes in bash In-Reply-To: <200502262139.45861.russell@coker.com.au> References: <200502261832.16337.russell@coker.com.au> <200502261048.28448.mihai@xcyb.org> <200502262139.45861.russell@coker.com.au> Message-ID: On Feb 26, 2005, Russell Coker wrote: > Actually I am not asking for a feature to be added, but for a feature to be > removed. There is special-case code in bash if(size >0) write() and I am > merely suggesting that the if statement be removed. Have you considered that it might just be writing to a FILE*, and that it's the stdio subsystem that's deciding it doesn't need to write anything at close() time because nothing was actually written? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Sat Feb 26 19:31:40 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Feb 2005 16:31:40 -0300 Subject: kickstart NFS install freezing In-Reply-To: <200502261851.05029.russell@coker.com.au> References: <200502261851.05029.russell@coker.com.au> Message-ID: On Feb 26, 2005, Russell Coker wrote: > When this problem occurs it stops the install (as expected), but it > also stops the mouse cursor from moving. This seems to be a bug to > me, the X server should not be accessing files on the NFS server (as > far as I am aware) and therefore there is no good cause for the > mouse cursor to stop. If the X server code is mounted from the NFS server and it needs swapping in, then the only place you can get it from is the NFS server. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mattdm at mattdm.org Sat Feb 26 19:41:37 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 14:41:37 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226180809.GG21024@angus.ind.WPI.EDU> References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> Message-ID: <20050226194137.GA31261@jadzia.bu.edu> On Sat, Feb 26, 2005 at 01:08:09PM -0500, Chuck R. Anderson wrote: > > Possible without objections > > talk - protocol is getting old with IM > vi, ed, and ex are old too. Should we remove them? Probably not. But removing telnetd wouldn't bother me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From eric at snowmoon.com Sat Feb 26 19:46:51 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 14:46:51 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226194137.GA31261@jadzia.bu.edu> References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> <20050226194137.GA31261@jadzia.bu.edu> Message-ID: <4220D22B.2050007@snowmoon.com> Matthew Miller wrote: > On Sat, Feb 26, 2005 at 01:08:09PM -0500, Chuck R. Anderson wrote: > >>>Possible without objections >>>talk - protocol is getting old with IM >> >>vi, ed, and ex are old too. Should we remove them? > > > Probably not. But removing telnetd wouldn't bother me. > > I have not seen talk activly used in a decade, as opposed to vi that I use daily. Unfortuantly it appears that telnet and telnet-server packages are built from the same rpm making the split impossible. Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From jos at xos.nl Sat Feb 26 20:05:18 2005 From: jos at xos.nl (Jos Vos) Date: Sat, 26 Feb 2005 21:05:18 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220D22B.2050007@snowmoon.com>; from eric@snowmoon.com on Sat, Feb 26, 2005 at 02:46:51PM -0500 References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> <20050226194137.GA31261@jadzia.bu.edu> <4220D22B.2050007@snowmoon.com> Message-ID: <20050226210518.A10477@xos037.xos.nl> On Sat, Feb 26, 2005 at 02:46:51PM -0500, Eric Warnke wrote: > I have not seen talk activly used in a decade, as opposed to vi that I > use daily. > > Unfortuantly it appears that telnet and telnet-server packages are built > from the same rpm making the split impossible. I'm using talk daily. Much better than all the modern (graphical) tools built on (mostly) crap IM protocols. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jwz at jwz.org Sat Feb 26 20:19:35 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 26 Feb 2005 12:19:35 -0800 Subject: Package pruning for FC4 and beyond - COMPLETE LIST References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226174202.GA2935@chrys.ms.mff.cuni.cz> Message-ID: <4220D9D7.6C84C527@jwz.org> Miloslav Trmac wrote: > > > talk - protocol is getting old with IM > UNIX kernel interface is "getting old" too. This proves that there is *no* package you can suggest removing that someone won't object to. It's like we're seeing "Godwin's Law of Shell Scripts" or something. I think the time for democracy has passed. Someone needs to just unilaterally make a decision and then deal with problems later. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From jwz at jwz.org Sat Feb 26 20:22:25 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 26 Feb 2005 12:22:25 -0800 Subject: Package pruning for FC4 and beyond - COMPLETE LIST References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> <20050226194137.GA31261@jadzia.bu.edu> <4220D22B.2050007@snowmoon.com> Message-ID: <4220DA81.454448F2@jwz.org> Eric Warnke wrote: > > Unfortuantly it appears that telnet and telnet-server packages are > built from the same rpm making the split impossible. I've seen this objection several times, and it hardly seems insurmountable to me. Why can't you modify the build system to have an explicit list of RPMs to delete just before burning the "Core" CD? Since the number of packages that have this kind of problem does not seem to be large, the list would not be very long. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From cmadams at hiwaay.net Sat Feb 26 20:24:09 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 26 Feb 2005 14:24:09 -0600 Subject: Package pruning for FC4 and beyond - question In-Reply-To: <4220C57D.3000603@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226194911.2364cf7f.fedora@wir-sind-cool.org> <4220C57D.3000603@snowmoon.com> Message-ID: <20050226202409.GA1105875@hiwaay.net> Once upon a time, Eric Warnke said: > Is being part of RHEL reason enough to keep things in core? If that is > the case I will exclude from my list all packages that exist in RHEL. > Personally I don't think that should be the goal here. In the Objectives of Fedora Core: 13. Form the basis of Red Hat's commercially supported operating system products. http://fedora.redhat.com/about/objectives.html -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From eric at snowmoon.com Sat Feb 26 20:25:02 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 15:25:02 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220DA81.454448F2@jwz.org> References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> <20050226194137.GA31261@jadzia.bu.edu> <4220D22B.2050007@snowmoon.com> <4220DA81.454448F2@jwz.org> Message-ID: <4220DB1E.6060605@snowmoon.com> Jamie Zawinski wrote: > I've seen this objection several times, and it hardly seems > insurmountable to me. Why can't you modify the build system to > have an explicit list of RPMs to delete just before burning the > "Core" CD? I think the objection is to splitting an upstream package between two repositories and maintainers. Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From cmadams at hiwaay.net Sat Feb 26 20:25:16 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 26 Feb 2005 14:25:16 -0600 Subject: Why is sendmail bad? In-Reply-To: <79FAA82857A03335BDEE9331@[10.0.0.4]> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> Message-ID: <20050226202516.GB1105875@hiwaay.net> Once upon a time, Kenneth Porter said: > Note that that's another argument for relegating *all* the MTA's to Extras > and shipping a dirt-simple SMTP pass-through that does little more than > proxy local mail requests to the ISP or company server. That's fine if you are building a workstation-only system, but are you also going to drop Apache, OpenLDAP, vsftpd, ...? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jspaleta at gmail.com Sat Feb 26 20:30:10 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 15:30:10 -0500 Subject: Package pruning for FC4 and beyond - question In-Reply-To: <4220C57D.3000603@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226194911.2364cf7f.fedora@wir-sind-cool.org> <4220C57D.3000603@snowmoon.com> Message-ID: <604aa791050226123031f36fca@mail.gmail.com> On Sat, 26 Feb 2005 13:52:45 -0500, Eric Warnke wrote: > Since this is the second time this has come up... > > Is being part of RHEL reason enough to keep things in core? If that is > the case I will exclude from my list all packages that exist in RHEL. > Personally I don't think that should be the goal here. There is no clear answer to this yet. The issue is complicated however by the fact that Extras buildsystem is seperate from the Red Hat internal buildsystem Core and RHEL both currently use. I'm sure the buildsystem constraints factor into how Red Hat decides where to keep RHEL relevant components under their control. -jef From ivazquez at ivazquez.net Sat Feb 26 20:35:53 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 26 Feb 2005 15:35:53 -0500 Subject: Sponsor request for Fedora Extras Message-ID: <1109450153.7308.42.camel@localhost.localdomain> I'd like to get a sponsor for Fedora Extras CVS for the packages listed on this page: http://fedora.ivazquez.net/content/view/27/30/ They're various packages that some may find useful to have, and the packages _should_ conform to the FE packaging policies. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A 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 mattdm at mattdm.org Sat Feb 26 20:35:45 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 15:35:45 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220D22B.2050007@snowmoon.com> References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> <20050226194137.GA31261@jadzia.bu.edu> <4220D22B.2050007@snowmoon.com> Message-ID: <20050226203545.GA32345@jadzia.bu.edu> On Sat, Feb 26, 2005 at 02:46:51PM -0500, Eric Warnke wrote: > Unfortuantly it appears that telnet and telnet-server packages are built > from the same rpm making the split impossible. Not impossible; just more of a pain. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sat Feb 26 20:40:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 26 Feb 2005 15:40:31 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220DB1E.6060605@snowmoon.com> References: <4220B0C2.2060007@snowmoon.com> <20050226180809.GG21024@angus.ind.WPI.EDU> <20050226194137.GA31261@jadzia.bu.edu> <4220D22B.2050007@snowmoon.com> <4220DA81.454448F2@jwz.org> <4220DB1E.6060605@snowmoon.com> Message-ID: <20050226204031.GB32345@jadzia.bu.edu> On Sat, Feb 26, 2005 at 03:25:02PM -0500, Eric Warnke wrote: > I think the objection is to splitting an upstream package between two > repositories and maintainers. In this case, though the upstream was just ripped from BSD, and isn't particularly maintained (no changes to netkit-telnet at the Source URL in five years....) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From eric at snowmoon.com Sat Feb 26 20:40:30 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sat, 26 Feb 2005 15:40:30 -0500 Subject: Package pruning for FC4 and beyond - question In-Reply-To: <604aa791050226123031f36fca@mail.gmail.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226194911.2364cf7f.fedora@wir-sind-cool.org> <4220C57D.3000603@snowmoon.com> <604aa791050226123031f36fca@mail.gmail.com> Message-ID: <4220DEBE.7030803@snowmoon.com> Is it that difficult for RH to maintain contol, but be copied to extras for building in Fedora Extras? If this is not already a thread internal to RH it should be. What is the real and expected deliniation between FC, FE, RHEL, and RH as a company and the maintainers and community at large? I understand there are real business issues that forced the creation of FE, but now the continued push for more community involvment necessatated by package maintanince and thereby extending FE into FC's old territory... what's the deal? I don't expect anyone can answer the question right now, but I think we at least deserve an answer at some point in the near future. Cheers, Eric Jeff Spaleta wrote: > On Sat, 26 Feb 2005 13:52:45 -0500, Eric Warnke wrote: > >>Since this is the second time this has come up... >> >>Is being part of RHEL reason enough to keep things in core? If that is >>the case I will exclude from my list all packages that exist in RHEL. >>Personally I don't think that should be the goal here. > > > There is no clear answer to this yet. The issue is complicated however > by the fact that Extras buildsystem is seperate from the Red Hat > internal buildsystem Core and RHEL both currently use. I'm sure the > buildsystem constraints factor into how Red Hat decides where to keep > RHEL relevant components under their control. > > -jef > -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From cmadams at hiwaay.net Sat Feb 26 20:44:48 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 26 Feb 2005 14:44:48 -0600 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <20050226204448.GC1105875@hiwaay.net> Once upon a time, Eric Warnke said: > lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether > those scripts are not part of core or they are not marked correctly. If > you can surf the web with either, you can download them from extras. If > either has a dependancy in core the .src.rpm needs to be corrected. > Personally I think lynx should go to extras. At one time, lynx was the only one of those that could do SSL, basic authentication, etc. (I don't know the current state of all of them because I use lynx). I think it may still be the only one that verifies SSL certificates. An example of a script that uses lynx is the Apache apachectl script. IIRC the perl CPAN module can also use it when libwww-perl is not available. Since lynx was (and may still be) the widest-spread text mode browser, many third party and home-grown scripts use it. I haven't seen scripts that come out-of-the box that use any of the others; that would be a reason to keep lynx over the others. > usermode/utempter - overlaps with sudo No it doesn't. > nut - nice package, but is it really core materal? It should be. Every UPS at Best Buy and even Wal-Mart has shutdown software for Windows, and nut is the tool to use for Linux. It is useful for both workstations and servers. > dosfttools - looks like mtools superceeds this package. Actually mtools predates dosfstools (I used mtools on Suns at least 12-14 years ago IIRC). However, they don't overlap entirely. Mtools is designed mainly to operate on floppies and wants to do things in terms of drive letters (that have to be configured). Dosfstools has VFAT mkfs and fsck utils that work just like other Unix filesystem mkfs/fsck (and can handle more mkfs options). I don't think mtools includes an fsck equivalent. > strace - looks like ltrace provides same functionality Not at all. Strace looks at system calls and ltrace looks library calls (hence the "s" vs. the "l"). > iptstate - package getting stale In what way? Is there duplicated functionality, or is it in way out of date? It performs its function (quite well), is up to date with respect to the interfaces required, and is the only tool for the job I believe. There are numerous packages that don't get regular updates because they just work and the requirements don't change. I built some walls today, but I didn't go buy a new hammer just because mine is old (although I did look at some new ones at the hardware store!). > lftp - useful ftp client ( ftp, ncftp ) D:0 Lftp is much more useful than ncftp (and lftp is in the default install where ncftp is not). Drop ncftp instead. > a2ps - text to postscript tool required by xfprint No idea how easy a2ps may be to remove, but GNU enscript is another flexible text to Postscript tool that is also included (don't know if the functionality is the same though). > star - tar with acl support. Yes, and AFAIK there is no included alternative to backing up ACLs. > pinfo - another text info file browser - do we need two? The info interface may be great if you are an emacs user, but it is not for the rest of us. Pinfo is far superior for normal people. > freeradius - complex package d:0 So are OpenOffice.org, xorg-x11, kernel, etc. That is no reason to remove something. It is also a useful package for servers. > mc - Is this really a core util? would it be better served in extras? There is no other text-mode file manager (except for a basic bit in lynx IIRC). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From feliciano.matias at free.fr Sat Feb 26 20:54:59 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 26 Feb 2005 21:54:59 +0100 Subject: Sponsor request for Fedora Extras In-Reply-To: <1109450153.7308.42.camel@localhost.localdomain> References: <1109450153.7308.42.camel@localhost.localdomain> Message-ID: <1109451299.6005.17.camel@one.myworld> Le samedi 26 f?vrier 2005 ? 15:35 -0500, Ignacio Vazquez-Abrams a ?crit : > I'd like to get a sponsor for Fedora Extras CVS for the packages listed > on this page: > > http://fedora.ivazquez.net/content/view/27/30/ > Wrong list ? https://www.redhat.com/mailman/listinfo/fedora-extras-list https://www.redhat.com/mailman/listinfo/fedora-packaging http://www.fedoraproject.org/wiki/Extras http://cvs.fedora.redhat.com/extras.shtml -------------- 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 ivazquez at ivazquez.net Sat Feb 26 21:07:47 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 26 Feb 2005 16:07:47 -0500 Subject: Sponsor request for Fedora Extras In-Reply-To: <1109451299.6005.17.camel@one.myworld> References: <1109450153.7308.42.camel@localhost.localdomain> <1109451299.6005.17.camel@one.myworld> Message-ID: <1109452067.7308.43.camel@localhost.localdomain> On Sat, 2005-02-26 at 21:54 +0100, F?liciano Matias wrote: > Le samedi 26 f?vrier 2005 ? 15:35 -0500, Ignacio Vazquez-Abrams a > ?crit : > > I'd like to get a sponsor for Fedora Extras CVS for the packages listed > > on this page: > > Wrong list ? I was told to ask on f-d-l, so that's what I did. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A 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 greenrd at presidium.org Sat Feb 26 21:16:24 2005 From: greenrd at presidium.org (Robin Green) Date: Sat, 26 Feb 2005 16:16:24 -0500 (EST) Subject: Xen: Installing guest VMs Message-ID: I read the FUDcon slides on the plans for Xen virtualisation in Fedora. On slide 8 it says, under "FC4 goals": - Installation of guest VMs So, is the plan to modify the Xeno-kernel so that it makes virtual block devices into fake IDE or SCSI devices, or is the plan to modify anaconda to install on Xen without kludges, or some combination? (Let's ignore driver domains for the minute!) I am currently working on the latter approach. I chose that because (a) I'd rather hack on Anaconda in python, than the kernel in C. (Actually, anaconda relies on a lot of C, but still, it's better.) (b) I see it as an excellent opportunity to move away from the blasted DOS partition system. There really is _no_ need to support partition tables on guest installs (dom0 can pass selected partitions or virtual partitions to domU), so let's not bother! My initial hacky kludge will be directed at getting Disk Druid to work with a fixed set of "partitions" (virtual block devices) - so you'll just be able to assign mount points and filesystem types, but not create or delete partitions. I've already got as far as bringing up the network in stage 1 and starting a stage 2 install over HTTP (yay!) An intriguing possibility is having a pre-install stage of Anaconda for guest installs, which runs on the host as a normal program, e.g. for things like hooking up LVM volumes to the new VM. You could even rewrite to run the ENTIRE install process on the host, without even booting the guest kernel, although my suspicion is that that route would involve an unnecessary amount of effort. So, any details on what route RH is planning to take to get guest installs working? -- Robin From jspaleta at gmail.com Sat Feb 26 21:28:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Feb 2005 16:28:30 -0500 Subject: Sponsor request for Fedora Extras In-Reply-To: <1109451299.6005.17.camel@one.myworld> References: <1109450153.7308.42.camel@localhost.localdomain> <1109451299.6005.17.camel@one.myworld> Message-ID: <604aa79105022613285a58386f@mail.gmail.com> On Sat, 26 Feb 2005 21:54:59 +0100, F?liciano Matias wrote: > Wrong list ? Let's be clear... i told him to try this list... because his orginal post to fedora-extras-list 2 weeks ago didn't garner much attention. I do not want a lack of comment to be a roadblock to getting a contributor access. I don't think its inapproraite to ping the more general -devel discussion list after 2 weeks of waiting for a response on the -extras-list. The sponcership concept is a 'new' process and its critical that initial contributors get into the system.. to build an ecosystem of packagers. -jef From feliciano.matias at free.fr Sat Feb 26 21:38:11 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 26 Feb 2005 22:38:11 +0100 Subject: Sponsor request for Fedora Extras In-Reply-To: <604aa79105022613285a58386f@mail.gmail.com> References: <1109450153.7308.42.camel@localhost.localdomain> <1109451299.6005.17.camel@one.myworld> <604aa79105022613285a58386f@mail.gmail.com> Message-ID: <1109453891.6005.20.camel@one.myworld> Le samedi 26 f?vrier 2005 ? 16:28 -0500, Jeff Spaleta a ?crit : > On Sat, 26 Feb 2005 21:54:59 +0100, F?liciano Matias > wrote: > > Wrong list ? > > Let's be clear... No problemo. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From russell at coker.com.au Sat Feb 26 21:39:47 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 27 Feb 2005 08:39:47 +1100 Subject: kickstart NFS install freezing In-Reply-To: <4220CA36.7010100@snowmoon.com> References: <200502261851.05029.russell@coker.com.au> <4220CA36.7010100@snowmoon.com> Message-ID: <200502270839.50631.russell@coker.com.au> On Sunday 27 February 2005 06:12, Eric Warnke wrote: > Russell Coker wrote: > > I am doing some tests on a kickstart install of RHEL4 and discovered a > > problem with my NFS server, after a large amount of data being > > transferred it will lock up the ethernet interface and refuse to talk to > > the NFS client until the interface has been deconfigured with "ifconfig > > down" and then configured again. > > Have you investigated plain old hardware problems on the nfs client and > server. You should never have to re-config the interface to get it to > start working again. True, there are obviously some issues with the server, and I will be investigating them ASAP. But in the mean time the client doesn't seem to be operating in the way I expect. Alexandre has posted a message that might explain the problem, although I'm surprised that a machine with 256M of RAM would want to discard executable pages from the X binary on an install. -- 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 Sat Feb 26 21:48:57 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 27 Feb 2005 08:48:57 +1100 Subject: writing zero bytes in bash In-Reply-To: References: <200502261832.16337.russell@coker.com.au> <200502262139.45861.russell@coker.com.au> Message-ID: <200502270849.01464.russell@coker.com.au> On Sunday 27 February 2005 06:28, Alexandre Oliva wrote: > On Feb 26, 2005, Russell Coker wrote: > > Actually I am not asking for a feature to be added, but for a feature to > > be removed. There is special-case code in bash if(size >0) write() and I > > am merely suggesting that the if statement be removed. > > Have you considered that it might just be writing to a FILE*, and that > it's the stdio subsystem that's deciding it doesn't need to write > anything at close() time because nothing was actually written? Good point. A quick test program shows that fwrite() doesn't support writing zero bytes. In that case we have a choice between having a change in the interface (such as supporting the writing of "\n" for an empty setting), or just leaving such operations as being impossible in shell scripts. -- 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 Sat Feb 26 21:50:21 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 27 Feb 2005 08:50:21 +1100 Subject: writing zero bytes in bash In-Reply-To: <1109442102.4312.9.camel@one.myworld> References: <200502261832.16337.russell@coker.com.au> <200502262139.45861.russell@coker.com.au> <1109442102.4312.9.camel@one.myworld> Message-ID: <200502270850.24851.russell@coker.com.au> On Sunday 27 February 2005 05:21, F?liciano Matias wrote: > Le samedi 26 f?vrier 2005 ? 21:39 +1100, Russell Coker a ?crit : > > Actually I am not asking for a feature to be added, but for a feature to > > be removed. There is special-case code in bash if(size >0) write() and I > > am merely suggesting that the if statement be removed. > > Writing nothing is not writing ? If that was the case then surely the VFS would catch it before it got as far as the proc file system. -- 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 Sat Feb 26 22:01:35 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 27 Feb 2005 09:01:35 +1100 Subject: writing zero bytes in bash In-Reply-To: <20050226175426.GJ3626@redhat.com> References: <200502261832.16337.russell@coker.com.au> <20050226175426.GJ3626@redhat.com> Message-ID: <200502270901.39429.russell@coker.com.au> On Sunday 27 February 2005 04:54, Tim Waugh wrote: > On Sat, Feb 26, 2005 at 06:32:13PM +1100, Russell Coker wrote: > > To unset the fscreate or exec context you have to write zero bytes > > to /proc/self/attr/fscreate or /proc/self/attr/exec respectively. > > Oh dear, really? How badly designed. The man page for write() says > that writing no bytes causes write() to return 0 "without causing any > other effect". Is an entry under /proc a "regular file" or a "special file"? Sym-links under /proc/*/fd are not regular sym-links, which seems to imply that files under /proc are not "regular files". That seems to indicate that the section "the results are not portable" applies. Alexandre has a good point though, so it seems that changing the interface would be a good idea. -- 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 Axel.Thimm at ATrpms.net Sat Feb 26 22:30:31 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 26 Feb 2005 23:30:31 +0100 Subject: exim removed :( (was: rawhide report: 20050224 changes) In-Reply-To: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> Message-ID: <20050226223031.GJ3077@neu.nirvana> On Thu, Feb 24, 2005 at 01:52:30PM -0500, Build System wrote: > Removed package exim That's sad, as exim is the most promising MTA out there already outperforming its competitors. It also doesn't take any space to speak of (10MB). Please consider getting it back for FC4. Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Sat Feb 26 22:39:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 17:39:22 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226182625.GI21024@angus.ind.WPI.EDU> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <1109442347.27384.104.camel@cutter> <20050226182625.GI21024@angus.ind.WPI.EDU> Message-ID: <1109457562.27384.106.camel@cutter> On Sat, 2005-02-26 at 13:26 -0500, Chuck R. Anderson wrote: >On Sat, Feb 26, 2005 at 01:25:47PM -0500, seth vidal wrote: >> vi is not an editor > >What is it then? I think it makes music. All I seem to get from it is beeps. -sv From dwmw2 at infradead.org Sat Feb 26 23:13:49 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 26 Feb 2005 23:13:49 +0000 Subject: exim removed :( (was: rawhide report: 20050224 changes) In-Reply-To: <20050226223031.GJ3077@neu.nirvana> References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> <20050226223031.GJ3077@neu.nirvana> Message-ID: <1109459629.27107.8.camel@localhost.localdomain> On Sat, 2005-02-26 at 23:30 +0100, Axel Thimm wrote: >That's sad, as exim is the most promising MTA out there already >outperforming its competitors. It also doesn't take any space to speak >of (10MB). It's far less than that -- it's 1721KiB. We gain almost no space by dropping it. I'm somewhat ignorant of Postfix so I could be wrong, but I don't believe it duplicates the functionality available from Exim. I've already posted a few examples of things which Exim in FC3 could handle, to see if someone most Postfix-aware than I can show how to do the same in Postfix. Nobody's taken that challenge yet. -- dwmw2 From czar at czarc.net Sat Feb 26 23:34:37 2005 From: czar at czarc.net (Gene C.) Date: Sat, 26 Feb 2005 18:34:37 -0500 Subject: Package pruning for FC4 and beyond - question In-Reply-To: <4220DEBE.7030803@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <604aa791050226123031f36fca@mail.gmail.com> <4220DEBE.7030803@snowmoon.com> Message-ID: <200502261834.37404.czar@czarc.net> On Saturday 26 February 2005 15:40, Eric Warnke wrote: > Is it that difficult for RH to maintain contol, but be copied to extras > for building in Fedora Extras? ?If this is not already a thread internal > to RH it should be. ?What is the real and expected deliniation between > FC, FE, RHEL, and RH as a company and the maintainers and community at > large? ?I understand there are real business issues that forced the > creation of FE, but now the continued push for more community involvment > necessatated by package maintanince and thereby extending FE into FC's > old territory... what's the deal? When Red Hat stopped doing Red Hat Linux and started up Fedora Core, my interpretation of the objectives was that Fedora Core would be testbed for RHEL and that packages which are part of RHEL would (in almost all cases) would also be in Fedora Core. However, there will likely be packages in Fedora Core which are not in RHEL. Now when there is some kind of transition with packages providing function (e.g., LPNG and cups), a package may be dropped from a current Fedora Core while still in the current RHEL ... this would be a "test" to see if the package could be dropped. A current example might be keeping emacs while moving xemacs to Fedora Extras. I assume that this is a test to see if the same can be done with RHEL (remove xemacs from the basic RHEL). One question that occurs to me is whether there will be something like a RHEL Extras to add not-so-widely-used packages to the commercial RHEL distribution. -- Gene From feliciano.matias at free.fr Sat Feb 26 23:58:19 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sun, 27 Feb 2005 00:58:19 +0100 Subject: exim removed :( (was: rawhide report: 20050224 changes) In-Reply-To: <1109459629.27107.8.camel@localhost.localdomain> References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> <20050226223031.GJ3077@neu.nirvana> <1109459629.27107.8.camel@localhost.localdomain> Message-ID: <1109462299.7542.8.camel@one.myworld> Le samedi 26 f?vrier 2005 ? 23:13 +0000, David Woodhouse a ?crit : > On Sat, 2005-02-26 at 23:30 +0100, Axel Thimm wrote: > >That's sad, as exim is the most promising MTA out there already > >outperforming its competitors. It also doesn't take any space to speak > >of (10MB). > > It's far less than that -- it's 1721KiB. We gain almost no space by > dropping it. > > I'm somewhat ignorant of Postfix so I could be wrong, but I don't > believe it duplicates the functionality available from Exim. > > I've already posted a few examples of things which Exim in FC3 could > handle, to see if someone most Postfix-aware than I can show how to do > the same in Postfix. Nobody's taken that challenge yet. > Which distribution use exim by default ? Debian ? Other ? Does the license matter ? exim : GPL postfix : IBM Public License http://www.gnu.org/licenses/license-list.html IBM Public License, Version 1.0 This is a free software license but it is incompatible with the GPL. The IBM Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL. For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.) Just curious. -------------- 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 greenrd at greenrd.org Sat Feb 26 21:36:57 2005 From: greenrd at greenrd.org (Robin Green) Date: Sat, 26 Feb 2005 21:36:57 +0000 Subject: Xen: Installing guest VMs References: Message-ID: On Sat, 26 Feb 2005 16:16:24 -0500, I wrote: > You could even rewrite > to run the ENTIRE install process on the host, without even booting the > guest kernel, although my suspicion is that that route would involve an > unnecessary amount of effort. Also, it would be just creating an unnecessary amount of work. You'd eventually have to ensure that the host-based installer worked on all possible Xen hosts (which will some day include Windows, I suspect); from a QA point of view I would think it would be wiser to stick with the "run the installer on the guest VM" model. Python is (I hear) fairly portable, but you'd have to ship separate installers containing separate builds of python and gtk for each supported host platform, and test them all - easier just to run anaconda in the guest. -- Robin From eric at snowmoon.com Sun Feb 27 05:09:44 2005 From: eric at snowmoon.com (Eric Warnke) Date: Sun, 27 Feb 2005 00:09:44 -0500 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <42215618.9000905@snowmoon.com> At this point I think I have weeded out all of the packages that should not be moved and solicited enough feedback to give put forward a reasonable set of packages to be moved from core to extras. This is the last posting to this list. Please forward additional comments off-list and I will pass the whole parcel along in a day or two. I do believe in a slimed down core so that we all can have a stronger and more efficient base of software to work from. To divert energy into packages that duplicate effort seems waistful and counter productive. To that end I submit to the community the list of packages that I think should migrate to extras and be picked up by the community or be dropped. I am also willing to pick up some of these packages in extras based if they are used in my environment and current maintainers want to give them up. *Recomendation for depreciation* fsh - fast shell, features being absorbed into OpenSSH ( Depreciate in anticipation of OpenSSH functionality ) *Ojections, let technical team make final call.* mc - Is this really a core util? would it be better served in extras? several objections as the only text mode file manager. I'm on the fence on this one. freeglut - libtiff dependancy - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149784 dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot. OTOH cyrus is maintained for RHEL and other packages depends on cyrus-sasl. The community definatly appears to favor keeping dovecot and letting cyrus be religated to extras. lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx and w3m should go to extras. SDL - Few things depend on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras. + kdeaddons - small add on packages. not 100% necessary. + gstreamer-plugins + theora-tools ! *gnomemeeting* - It is possible to compile without SDL support, I will test that change ans see what aspects of the program it affects. nut - nice package, but is it really core materal? 1 objection used on server. Is server use enough to keep it in core? talk - protocol is getting old with IM - 3 objections... do people still use this. Last time I saw this in active use was a decade ago. Unlike other mature tools nothing really depends on talk. I think this is in the same category as telnetd, it's just not in wide enough use to justify keeping it in core. *Recommend eviction from core* ncftp - duplicate funcationality ( ftp, lftp ) nobody appeard to have any love lost if this moves to extras w3m/w3m-el - another text pager/web browser tora - packaged without oracle plugin and does not appear to work out of the box with MySQL or postgress. tix - Tcl/Tk extansion ( only id tkinter can go as well ) routed - appears to be superceeded by quagga qmkbootdisk - graphical boot disk creation utiltiy - stale ots - was used as part of abiword, but abiword has been religated to extras. This one is a no brainer nss_db - partly broken. Most usefulness gone now that nscd is standard ( I will personally manage since I wrote the fix ) mew - emailing in emacs dmalloc, valgrind - electricfence appears to be more compatible and better developed. giftrans - netpbm tools can do the same iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / emacs / vi ) nedit - another x text editor Canna - Superceeded by IIMF - nothing depends ! 10MB MagicPoint - Duplicated functionality already in other packages OO.o a2ps - text to postscript tool required by xfprint ( xfprint already in extras ) no brainer awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0 cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 ftpcopy - utility D:0. I have never used it do we need in core g-wrap - Another wrapper for a development utility d:0 Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From mpeters at mac.com Sun Feb 27 06:25:52 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 27 Feb 2005 06:25:52 +0000 Subject: Why is sendmail bad? In-Reply-To: (from shiva@sewingwitch.com on Thu Feb 24 11:45:15 2005) References: Message-ID: <1109485552l.6220l.1l@devel.mpeters.us> On 02/24/2005 11:45:15 AM, Kenneth Porter wrote: > There seems to be a lot of dissatisfaction with sendmail in the call > to replace it with Exim or Postfix, but I didn't see any specifics > about why people object to it. Anyone care to give details? It's not that sendmail is bad, it's just that postfix (and reportedly exim) are a lot easier to configure without an O'Reilly book at your side. Also - postfix can be run in a chroot jail without too much effort, last I heard - that was just not possible with sendmail. -- Michael A. Peters http://mpeters.us/ From byte at aeon.com.my Sun Feb 27 06:35:00 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 27 Feb 2005 14:35:00 +0800 Subject: exim removed :( (was: rawhide report: 20050224 changes) In-Reply-To: <1109462299.7542.8.camel@one.myworld> References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> <20050226223031.GJ3077@neu.nirvana> <1109459629.27107.8.camel@localhost.localdomain> <1109462299.7542.8.camel@one.myworld> Message-ID: <1109486100.5676.281.camel@arena.soho.bytebot.net> On Sun, 2005-02-27 at 00:58 +0100, F?liciano Matias wrote: > Does the license matter ? > exim : GPL > postfix : IBM Public License Its one of the approved licenses[1]: Approved License means any of the following licenses: GNU General Public License v2.0; IBM Public License v1.0; Common Public License v0.5; Q Public License v1.0; Open Software License v1.1; and any open source license granted by Red Hat. [1] - http://www.redhat.com/legal/patent_policy.html -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From rc040203 at freenet.de Sun Feb 27 06:39:04 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 27 Feb 2005 07:39:04 +0100 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109365714.23111.38.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter> Message-ID: <1109486344.15959.491.camel@mccallum.corsepiu.local> On Fri, 2005-02-25 at 16:08 -0500, seth vidal wrote: > >Then tell me how else you do it? How to cull the signal from the noise? > > > >show me a better way and we'll get there lickety-damn-split. > > one more addendum - just b/c discussion about decisions in the distro > and extras should go to fedora-maintainers doesn't mean I'll stop > reading fedora-devel. Hopefully it will mean fedora-devel will become > more useful. Moving packages between Core and Extras is Fedora development. Moving discussions to a closed list, means nothing but you are not willing to listen to other opinions and prefer to decide and proceed at your own will - A severe fault, IMNSHO. Ralf From herrold at owlriver.com Sun Feb 27 06:48:05 2005 From: herrold at owlriver.com (R P Herrold) Date: Sun, 27 Feb 2005 01:48:05 -0500 (EST) Subject: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109362522.23111.24.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> Message-ID: On Fri, 25 Feb 2005, seth vidal wrote: >>> why do you think fedora-maintainers is closed to posts from >>> non-maintainers? > > it was decided by a group of red hat and non red hat fedora contributors > at the pre-fudcon meetings. > Mostly to keep the signal/noise ratio down. Yeah, backroom deals keep the riff-raff out and the surprise in a relationship, all right. And the trains all run on time. It is just has little to do a democratic process. George Orwell had this one called: The only Community in Fedora is for those pigs who are more equal than others. It is rank hypocrisy to proclaim oneself a community, when power and privilege of insider status are reserved to a small elite. -- Russ Herrold From skvidal at phy.duke.edu Sun Feb 27 07:09:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 02:09:44 -0500 Subject: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> Message-ID: <1109488184.27384.164.camel@cutter> On Sun, 2005-02-27 at 01:48 -0500, R P Herrold wrote: >On Fri, 25 Feb 2005, seth vidal wrote: > >>>> why do you think fedora-maintainers is closed to posts from >>>> non-maintainers? >> >> it was decided by a group of red hat and non red hat fedora contributors >> at the pre-fudcon meetings. >> Mostly to keep the signal/noise ratio down. > >Yeah, backroom deals keep the riff-raff out and the surprise >in a relationship, all right. And the trains all run on time. >It is just has little to do a democratic process. > >George Orwell had this one called: The only Community in >Fedora is for those pigs who are more equal than others. It >is rank hypocrisy to proclaim oneself a community, when power >and privilege of insider status are reserved to a small elite. *yawn* Russ you of all people should know that there's no benefit to asking everyone for their opinion. It just gives you a lot of opinions, someone still has to make the decisions. Why is there a private caos-steering-committee, russ? Are you hiding something? Is it hyprocrisy!?!! no, it's not, it's just so we(I'm on it, remember?:) can talk about things w/o worrying too much. How did people get on the steering committee? Greg Asked us. No elections, it was based on people who had done the work and helped out. No democracy there. There's no democracy in the people who lead ubuntu either. nor in suse/novell nor in slackware gnome has board elections - but the people who are in control over gnome is not the board the people in control of gnome work for novell and red hat. postfix is controlled completely by Wietse Venema sendmail by sendmail co and eric allman apache by the apache foundation whose membership is based on what? Their contributions to the project, not on elections. bind - entirely isc. The kernel summit is invite only. Open source is not about democracy. It's never been about democracy. It is about social mobility w/i any organization. The ability to move up (or down) in the social stratum. You move up in terms of control and responsibility by doing the work. By contributing. If you do not contribute, you don't get any decision-making authority. I will say this once again and for all, if anyone wants to find themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS TO DO THE WORK. DO NOT WAIT. Do the work. If you need help knowing what needs to be worked on. ASK. -sv From jwz at jwz.org Sun Feb 27 07:11:41 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 26 Feb 2005 23:11:41 -0800 Subject: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> Message-ID: <422172AD.6358EE78@jwz.org> > George Orwell had this one called: The only Community in And with the Godwinization, the cycle of life is complete. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From skvidal at phy.duke.edu Sun Feb 27 09:25:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 04:25:56 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109486344.15959.491.camel@mccallum.corsepiu.local> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter> <1109486344.15959.491.camel@mccallum.corsepiu.local> Message-ID: <1109496356.27384.189.camel@cutter> >Moving packages between Core and Extras is Fedora development. > >Moving discussions to a closed list, means nothing but you are not >willing to listen to other opinions and prefer to decide and proceed at >your own will - A severe fault, IMNSHO. No, it just means I don't have time to listen to the opinions of folks who aren't putting in some effort to contribute. I'll take the time to listen if you're contributing and trying to be constructive. -sv From Lam at Lam.pl Sun Feb 27 09:38:35 2005 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 27 Feb 2005 10:38:35 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <422086A8.7020200@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> Message-ID: <1109497115.5869.15.camel@pensja.lam.pl> Dnia 26-02-2005, sob o godzinie 09:24 -0500, Eric Warnke napisa?(a): > jed - another text mode editor > joe - yet another text editor ( nano / pico / emacs / ed / vi ) > lftp - useful ftp client ( ftp, ncftp ) D:0 Just like desktop environments, it's really hard to say one editor can substitute another. Unlike DE-s, text editors are rather small (I use joe - 200 KiB RPM file, even nano having 1% of joe features is bigger) and removing them doesn't give this much benefit (meaning saved space) as removing f.e. KDE (since GNOME is the default, why haven't you list KDE? :)). I say let's move vi to Extras - an editor which can't be left with ^C deserves this! :) Is pico part of Rawhide now? I thought its licence is the same as pine's and can't be included, besides, you're using FC3 rpmdb and pico can't be found there. Can ed be thought of as a replacement for any full-screen text editor? :) Of course I won't go mad if joe is going to be moved to Extras, downloading 200 KiB will take only 20 seconds on my link, so go ahead, make my life harder and not gain anything for the Core :) Lam From Nicolas.Mailhot at laPoste.net Sun Feb 27 10:07:49 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 27 Feb 2005 11:07:49 +0100 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <42215618.9000905@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> Message-ID: <1109498870.25736.10.camel@rousalka.dyndns.org> Le dimanche 27 f?vrier 2005 ? 00:09 -0500, Eric Warnke a ?crit : >nut - nice package, but is it really core materal? 1 objection used on >server. Is server use enough to keep it in core? You know UPSes are not only unsed for servers. They are for example quite common in HomeCinema setups where you absolutely do not want a power failure to shorten dramatically the life of your equipment by shutting down your projector before it has the chance to cool down its lamp by running its fans at max settings for a few minutes (the lamp is the single most expensive and delicate component of a video projector) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sun Feb 27 10:09:53 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 27 Feb 2005 11:09:53 +0100 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <42215618.9000905@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> Message-ID: <1109498993.25736.11.camel@rousalka.dyndns.org> BTW pan was moved to extras but I don't remember what the official replacement was supposed to be. Objections were raised by Alan Cox among others. 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 flyingpenguin61 at gmail.com Sun Feb 27 10:11:16 2005 From: flyingpenguin61 at gmail.com (Jocelyn Delalande) Date: Sun, 27 Feb 2005 11:11:16 +0100 Subject: Self-Introduction: Jocelyn Delalande Message-ID: <42219CC4.3050902@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings and hello to all people of this list ! So, let's introduce myself... 1. My real name is Jocelyn Delalande 2. I live in France/Basse Normandie/Orne 3. I'm student in a high school 4. I don't want to reveal the name of my school to keep a kind of anonymity... and it's not very usefull... 5. So, my goals ~ * I would like to package (or see published) some little packages of utilities, programs, games... that I use and that I love. For example, I have almost finished a package of numlockx, an utility that enable the numlock at X startup. Other softs (projects) mytoy, gmailfs, scite... * I think I'll not write QA because of my english level... But I can make french translations of them, of course. *Anything else special? Yes, please, be lenient with my english please ;-) but not hesitate to correct me if you see errors in packages, bugzilla... *Anything else special?(bis) I hope I will help a little the fedora project with my contributions and do a good work with fedora-devel-list members ! :-) 6. * Almost nothing... just help on forums/ IRC on http://fedora-france.org * as the precedent... almost nothing ... just the bash (not fully) and the basics of rpm conception. *Why should we trust you? and why not ;-) ? ~ 7.and to finish, my gpg : (registred on pgp.mit.edu) pub 1024D/E19277EE 2005-02-26 ~ Empreinte de la cl? = 0A74 3785 C9A5 9179 4338 F6D2 6178 56BA E192 77EE uid Jocelyn Delalande sub 2048g/12660C61 2005-02-26 see you - -- +++++++++++++++++++++++++++++++ + Jocelyn Delalande + + flyingpenguin61 at hotmail.com + + MSN:supergamerj at hotmail.com + +++++++++++++++++++++++++++++++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCIZzEYXhWuuGSd+4RAqa3AJoDXlHIQItPhXT9siNCgRTwgufPggCeL6wj lf86UbGSUWsAIuPKdBbDsLc= =MU1h -----END PGP SIGNATURE----- From Lam at Lam.pl Sun Feb 27 10:38:32 2005 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 27 Feb 2005 11:38:32 +0100 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <1109498993.25736.11.camel@rousalka.dyndns.org> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> <1109498993.25736.11.camel@rousalka.dyndns.org> Message-ID: <1109500712.5869.17.camel@pensja.lam.pl> Dnia 27-02-2005, nie o godzinie 11:09 +0100, Nicolas Mailhot napisa?(a): > BTW pan was moved to extras but I don't remember what the official > replacement was supposed to be. I'd say Evo, but I don't know what's the official one really is. Lam From rc040203 at freenet.de Sun Feb 27 11:23:57 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 27 Feb 2005 12:23:57 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <1109503437.15959.520.camel@mccallum.corsepiu.local> On Sat, 2005-02-26 at 12:24 -0500, Eric Warnke wrote: > Please post feedback. All objections noted. > Xaw3d - required by emacs and emacs is being kept libXaw should not be removed. It is one fundamental libs in X11, many (older, however still useful) applications are based on. > Ojections, but I still believe could be moved. > > *freeglut - library with no dependancy in core. libtiff requirement can > be corrected. I am working on a patch or updated spec file.* Basis for many GL applications. Should be shipped in parallel to libGL/Mesa/X11 and should be regarded integral part of X11. > joe - yet another text editor ( nano / pico / emacs / ed / vi ) Not just "yet another text editor". It's the only Wordstar compatible ASCI-editor in Fedora (WordStar has dominated the editor market in the late 1980/90's, generations of users have grown up with it.) Removing it from FC means a severe loss of functionally to this generation of users. Ralf From mpeters at mac.com Sun Feb 27 11:49:29 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 27 Feb 2005 11:49:29 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <422086A8.7020200@snowmoon.com> (from eric@snowmoon.com on Sat Feb 26 06:24:40 2005) References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> Message-ID: <1109504969l.7040l.0l@devel.mpeters.us> On 02/26/2005 06:24:40 AM, Eric Warnke wrote: > lftp - useful ftp client ( ftp, ncftp ) D:0 Absolutely the best cli ftp client I have ever used. Any *other* ftp clients are redundant :p Yes, there's curl and wget etc. which can download, yes - there's the standard ftp command, yes - lftp could be fetched from extras, but I think it should stay - it's not very big, and I bet it is heavily used. I think the idea behind moving stuff to Extras should not be to move every duplicate package - if masses of people are just going to yum install it, and it is small, it might as well be on the install CD. AbiWord/Gnumeric being large packages that aren't used by a lot of people are good examples. lftp (under 1 MB) and lynx (under 2MB) are small packages that are used by a fair number of people - they should thus not be moved. -- Michael A. Peters http://mpeters.us/ From jakub at redhat.com Sun Feb 27 11:56:23 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Sun, 27 Feb 2005 06:56:23 -0500 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <42215618.9000905@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> Message-ID: <20050227115623.GW853@devserv.devel.redhat.com> On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote: > dmalloc, valgrind - electricfence appears to be more compatible and > better developed. Please don't mention valgrind in the list of packages you want to remove. Valgrind is a real necessity in finding memory allocation bugs, but so is ElectricFence, malloc checking in glibc and mudflap. dmalloc I have no objection to, but valgrind is really going to stay. Jakub From seanlkml at sympatico.ca Sun Feb 27 12:31:16 2005 From: seanlkml at sympatico.ca (Sean) Date: Sun, 27 Feb 2005 07:31:16 -0500 (EST) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109496356.27384.189.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain><421F36A6.8040401@olin.edu><1109342585.26364.163.camel@localhost.localdomain><1109346741.10989.13.camel@opus.phy.duke.edu><1109346973.26364.181.camel@localhost.localdomain><1109348125.10989.22.camel@opus.phy.duke.edu><20050225162219.GD1048932@hiwaay.net><1109348730.10989.33.camel@opus.phy.duke.edu><1109349041.26364.190.camel@localhost.localdomain><1109355427.10989.39.camel@opus.phy.duke.edu><20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter><1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com><1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter><1109486344.15959.491.camel@mccallum.corsepiu.local> <1109496356.27384.189.camel@cutter> Message-ID: <1912.10.10.10.24.1109507476.squirrel@linux1> On Sun, February 27, 2005 4:25 am, seth vidal said: > No, it just means I don't have time to listen to the opinions of folks > who aren't putting in some effort to contribute. I'll take the time to > listen if you're contributing and trying to be constructive. Hey Seth, Not every issue is a matter of opinion, and keeping the list open to the widest number of contributors should be a net win. Even the annoying package removal thread wasn't that hard to skim through. Seems like a small price to pay to keep from cutting yourself off from useful posts (ie. constructive contributions). Sean From Nigel.Metheringham at dev.intechnology.co.uk Sun Feb 27 14:49:32 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Sun, 27 Feb 2005 14:49:32 +0000 Subject: reducing distribution CD count In-Reply-To: <20050224175035.22391185@python2> References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> Message-ID: <1109515772.5676.29.camel@angua.localnet> On Thu, 2005-02-24 at 17:50 +0100, Matthias Saou wrote: > - Exim was removed... it's tiny, and was in FC3, so that's > probably a bad idea. I would suggest that removing a package that has significant security implications (any MTA or significant functionality network program would fall into this category) is not good. People depending on FC for security updates must be made aware that suddenly they must get security updates from elsewhere or change to an alternative package. [I've not commented on this up until now because I do have an axe to grind, but I feel this aspect has been overlooked] Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From feliciano.matias at free.fr Sun Feb 27 14:51:08 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sun, 27 Feb 2005 15:51:08 +0100 Subject: exim removed :( (was: rawhide report: 20050224 changes) In-Reply-To: <1109486100.5676.281.camel@arena.soho.bytebot.net> References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> <20050226223031.GJ3077@neu.nirvana> <1109459629.27107.8.camel@localhost.localdomain> <1109462299.7542.8.camel@one.myworld> <1109486100.5676.281.camel@arena.soho.bytebot.net> Message-ID: <1109515868.17920.2.camel@one.myworld> Le dimanche 27 f?vrier 2005 ? 14:35 +0800, Colin Charles a ?crit : > On Sun, 2005-02-27 at 00:58 +0100, F?liciano Matias wrote: > > Does the license matter ? > > exim : GPL > > postfix : IBM Public License > > Its one of the approved licenses[1]: > I know, but I prefer a GPL-compatible license. Not you ? Not Fedora ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nigel.Metheringham at dev.intechnology.co.uk Sun Feb 27 15:11:14 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Sun, 27 Feb 2005 15:11:14 +0000 Subject: Why is sendmail bad? In-Reply-To: <200502241504.44676.rjune@bravegnuworld.com> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <200502241504.44676.rjune@bravegnuworld.com> Message-ID: <1109517074.5676.33.camel@angua.localnet> On Thu, 2005-02-24 at 15:04 -0500, Richard June wrote: > I take issue to that. sendmail has always been *TONS* easier for me to > configure then postfix/exim. the sendmail.mc file is simple to understand and > edit. You lot really are wimps. You should configure sendmail the proper way - edit the raw config (ideally with TECO since the command sets are so similar). [And yes, I have done this, although with sendmail 5.x - in the days when you had to reverse domain names within the UK. Now I generally use exim, although have run postfix in living memory] Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From lists at sapience.com Sun Feb 27 15:33:41 2005 From: lists at sapience.com (Mail Lists) Date: Sun, 27 Feb 2005 10:33:41 -0500 Subject: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109488184.27384.164.camel@cutter> References: <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <1109488184.27384.164.camel@cutter> Message-ID: <20050227153341.GA6532@sapience.com> On Sun, Feb 27, 2005 at 02:09:44AM -0500, seth vidal wrote: > I will say this once again and for all, if anyone wants to find > themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS > TO DO THE WORK. Very valid points. However - things are not black and white - read LKML - Linus listens - even to non kernel hackers - it is one of his many remarkable strengths. g/ From skvidal at phy.duke.edu Sun Feb 27 16:42:48 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 11:42:48 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1912.10.10.10.24.1109507476.squirrel@linux1> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter> <1109486344.15959.491.camel@mccallum.corsepiu.local> <1109496356.27384.189.camel@cutter> <1912.10.10.10.24.1109507476.squirrel@linux1> Message-ID: <1109522569.27384.213.camel@cutter> On Sun, 2005-02-27 at 07:31 -0500, Sean wrote: > >Not every issue is a matter of opinion, and keeping the list open to the >widest number of contributors should be a net win. Even the annoying >package removal thread wasn't that hard to skim through. Seems like a >small price to pay to keep from cutting yourself off from useful posts >(ie. constructive contributions). why do you think I'd be cut off from the contributions? I'm not stopping reading fedora-devel, but for some issues I wouldn't post there. Seriously, though it doesn't cut me off from most contributions and b/c of the structure of maintainers list it lends itself nicely to people who are willing to do more than just give their opinion actually discussing items. Over the years of working on misc open source projects I realized I get a more tired, more quickly of hearing complaints and opinions from people if they're not willing to help either solve them or implement their solutions. that's just me though. -sv From skvidal at phy.duke.edu Sun Feb 27 16:43:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 11:43:57 -0500 Subject: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <20050227153341.GA6532@sapience.com> References: <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <1109488184.27384.164.camel@cutter> <20050227153341.GA6532@sapience.com> Message-ID: <1109522637.27384.216.camel@cutter> On Sun, 2005-02-27 at 10:33 -0500, Mail Lists wrote: >On Sun, Feb 27, 2005 at 02:09:44AM -0500, seth vidal wrote: >> I will say this once again and for all, if anyone wants to find >> themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS >> TO DO THE WORK. > > Very valid points. However - things are not black and white - > read LKML - Linus listens - even to non kernel hackers - it > is one of his many remarkable strengths. and where have we implied that users won't be listened to? But as it is if you want to listen to users on fedora-list and everyone else on fedora-devel-list it is a full time job JUST to read the email. -sv From walters at redhat.com Sun Feb 27 16:42:53 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 27 Feb 2005 11:42:53 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109442544.5970.26.camel@rousalka.dyndns.org> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <1109442544.5970.26.camel@rousalka.dyndns.org> Message-ID: <1109522573.4515.5.camel@nexus.verbum.private> On Sat, 2005-02-26 at 19:29 +0100, Nicolas Mailhot wrote: >BTW in a related topic if the arts part could be spun out of >gstreamer-plugins this system could run without qt installed. My hope is that we can go with ALSA sound mixing on by default and simply drop the arts gstreamer plugin, since AFAIK it's only used by people using arts for sound mixing and who want gstreamer apps to output to arts. From seanlkml at sympatico.ca Sun Feb 27 16:49:56 2005 From: seanlkml at sympatico.ca (Sean) Date: Sun, 27 Feb 2005 11:49:56 -0500 (EST) Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109522569.27384.213.camel@cutter> References: <1109287914.26364.69.camel@localhost.localdomain><421F36A6.8040401@olin.edu><1109342585.26364.163.camel@localhost.localdomain><1109346741.10989.13.camel@opus.phy.duke.edu><1109346973.26364.181.camel@localhost.localdomain><1109348125.10989.22.camel@opus.phy.duke.edu><20050225162219.GD1048932@hiwaay.net><1109348730.10989.33.camel@opus.phy.duke.edu><1109349041.26364.190.camel@localhost.localdomain><1109355427.10989.39.camel@opus.phy.duke.edu><20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter><1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com><1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter><1109486344.15959.491.camel@mccallum.corsepiu.local><1109496356.27384.189.camel@cutter><1912.10.10.10.24.1109507476.squirrel@linux1> <1109522569.27384.213.camel@cutter> Message-ID: <2900.10.10.10.24.1109522996.squirrel@linux1> On Sun, February 27, 2005 11:42 am, seth vidal said: > Over the years of working on misc open source projects I realized I get > a more tired, more quickly of hearing complaints and opinions from > people if they're not willing to help either solve them or implement > their solutions. > > that's just me though. Naw it's not just you; who wants to listen to complainers? Guess the only point was that not _everyone_ who is a first time poster is just a complainer, and may actually have a valuable contribution. It's these people you'll cut yourself off from because of the other noise makers. The argument comes down to how much noise you're willing to endure in order to leave the door open for valuable posts from people who are too new to have made acknowledged contributions. A moderated list might be a better compromise. Sean From skvidal at phy.duke.edu Sun Feb 27 17:04:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Feb 2005 12:04:32 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <2900.10.10.10.24.1109522996.squirrel@linux1> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com> <1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter> <1109486344.15959.491.camel@mccallum.corsepiu.local> <1109496356.27384.189.camel@cutter> <1912.10.10.10.24.1109507476.squirrel@linux1> <1109522569.27384.213.camel@cutter> <2900.10.10.10.24.1109522996.squirrel@linux1> Message-ID: <1109523872.27384.221.camel@cutter> >Naw it's not just you; who wants to listen to complainers? Guess the only >point was that not _everyone_ who is a first time poster is just a >complainer, and may actually have a valuable contribution. It's these >people you'll cut yourself off from because of the other noise makers. > >The argument comes down to how much noise you're willing to endure in >order to leave the door open for valuable posts from people who are too >new to have made acknowledged contributions. A moderated list might be a >better compromise. a moderated list requires a moderator. And a list with the type of traffic fedora-devel has would need a moderator with no life. -sv From cra at WPI.EDU Sun Feb 27 17:07:27 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sun, 27 Feb 2005 12:07:27 -0500 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <42215618.9000905@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> Message-ID: <20050227170727.GJ21024@angus.ind.WPI.EDU> On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote: > dovecot/cryus - IMAP server cyrus does seem more like a specialty > package when compared to the simplcity and utility of dovecot. OTOH > cyrus is maintained for RHEL and other packages depends on cyrus-sasl. > The community definatly appears to favor keeping dovecot and letting > cyrus be religated to extras. If cyrus-sasl can't be separated easily from cyrus IMAP, then it needs to stay. sasl is an authentication library that is needed by many components of LDAP/Kerberos authentication strategies. > lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether > those scripts are not part of core or they are not marked correctly. If > you can surf the web with either, you can download them from extras. If > either has a dependancy in core the .src.rpm needs to be corrected. > Personally I think lynx and w3m should go to extras. lynx should stay if it is the only one that does Basic Auth and SSL well. In fact, I change my stance here and say that lynx should stay based on the argument that scripts, libraries, and applications use it. It existed for so long before the other text browsers, that it has become the defacto standard way to "bootstrap" things from the net. > SDL - Few things depend on this. 1 objection. Would be nice to have in > core, but is really not a core function since nothing in core depends on > it. Anything that is going to require it can pull it down from extras. > + kdeaddons - small add on packages. not 100% necessary. > + gstreamer-plugins > + theora-tools theora-tools should stay. We need to have an unencumbered suite of multimedia tools in Core, if for no other reason than to encourage widespread adoption of open formats over closed ones. > nut - nice package, but is it really core materal? 1 objection used on > server. Is server use enough to keep it in core? Yes. Core is not just a desktop distribution. nut should stay. > talk - protocol is getting old with IM - 3 objections... do people still > use this. Last time I saw this in active use was a decade ago. Unlike > other mature tools nothing really depends on talk. I think this is in > the same category as telnetd, it's just not in wide enough use to > justify keeping it in core. We're talking (no pun intended) about 22k installed (50k source) here... With 3 objections to it, why worry about it so much? Just keep it... > *Recommend eviction from core* > routed - appears to be superceeded by quagga routed is a very simple RIP protocol daemon sometimes used by non-routers in listen-only mode (-q) to learn the available routes on the network (default route, other routes). It is this aspect of routed that maybe should keep it in Core. Source 43 KB. Installed 40 KB. I say keep it. quagga is really a much larger package that supports many more routing protocols than just RIP, and is intended for large routers, route servers, etc. not network clients, nor your simple home router. It is much more complex, and as such doesn't really fill the need that routed fills. Source 2 MB. Installed 4+ MB. If either package goes, this one should. This seems like a perfect candidate for Extras, given its small target audience. > dmalloc, valgrind - electricfence appears to be more compatible and > better developed. I thought valgrind was supposedly so much better than the others? I remember at one time it had been encumbered by patents or something, and as such it couldn't be included at the time. Now that it is in there, should we really remove it again? I have no strong opinion on this one, just asking... Extras could certainly take this one if desired. > iptstate - package getting stale Stale? It was initially packaged in Jan 2004, and recently updated in Feb 2005. Again, this is only 17 KB source, 39 KB installed. I say keep it. It sounds very useful. > a2ps - text to postscript tool required by xfprint ( xfprint already in > extras ) no brainer Agreed. As long as we keep enscript. From cra at WPI.EDU Sun Feb 27 17:17:20 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sun, 27 Feb 2005 12:17:20 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109497115.5869.15.camel@pensja.lam.pl> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <1109497115.5869.15.camel@pensja.lam.pl> Message-ID: <20050227171720.GK21024@angus.ind.WPI.EDU> On Sun, Feb 27, 2005 at 10:38:35AM +0100, Leszek Matok wrote: > I say let's move vi to Extras - an editor which can't be left with ^C > deserves this! :) I don't think we should remove vi--it is the basic, traditional *nix editor. Note that I'm not a vi zealot--I actually use all three of vi, emacs, and nano for various different tasks... > Is pico part of Rawhide now? I thought its licence is the same as pine's > and can't be included, besides, you're using FC3 rpmdb and pico can't be > found there. No, nano replaced pico. cone (in Extras) is intended to replace pine. I don't think nano should be removed from Core. In fact, when cone is ready, I think it should be brought into Core. From dwmw2 at infradead.org Sun Feb 27 17:21:41 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 27 Feb 2005 17:21:41 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <20050227171720.GK21024@angus.ind.WPI.EDU> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <1109497115.5869.15.camel@pensja.lam.pl> <20050227171720.GK21024@angus.ind.WPI.EDU> Message-ID: <1109524901.27107.38.camel@localhost.localdomain> On Sun, 2005-02-27 at 12:17 -0500, Chuck R. Anderson wrote: >No, nano replaced pico. cone (in Extras) is intended to replace pine. >I don't think nano should be removed from Core. In fact, when cone is >ready, I think it should be brought into Core. Nano could really do with UTF-8 support. I'm very tempted to ship a CVS snapshot for that reason, although that's generally not a good thing to do. Cone still lacks the capability to get at IMAP servers by rsh/ssh, doesn't it? -- dwmw2 From cra at WPI.EDU Sun Feb 27 17:27:51 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sun, 27 Feb 2005 12:27:51 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109524901.27107.38.camel@localhost.localdomain> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <1109497115.5869.15.camel@pensja.lam.pl> <20050227171720.GK21024@angus.ind.WPI.EDU> <1109524901.27107.38.camel@localhost.localdomain> Message-ID: <20050227172751.GL21024@angus.ind.WPI.EDU> On Sun, Feb 27, 2005 at 05:21:41PM +0000, David Woodhouse wrote: > Nano could really do with UTF-8 support. I'm very tempted to ship a CVS > snapshot for that reason, although that's generally not a good thing to > do. Go for it. We should put the CVS snapshot into Rawhide/FC4t1 and see how it goes. It can be downgraded later if it doesn't go so well. From flyingpenguin61 at gmail.com Sun Feb 27 17:47:16 2005 From: flyingpenguin61 at gmail.com (Jocelyn Delalande) Date: Sun, 27 Feb 2005 18:47:16 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <20050227170006.0680B739F0@hormel.redhat.com> References: <20050227170006.0680B739F0@hormel.redhat.com> Message-ID: > On Sat, 2005-02-26 at 19:29 +0100, Nicolas Mailhot wrote: > My hope is that we can go with ALSA sound mixing on by default and > simply drop the arts gstreamer plugin, since AFAIK it's only used by > people using arts for sound mixing and who want gstreamer apps to output > to arts. I agree with you, moreover arts/gstreamer are not real solutions for mixing (in a standard use I mean) many programs have troubles with it... Enabling alsa mixing by default will make the ditribution more user-friendly... This is just my opinion From Nicolas.Mailhot at laPoste.net Sun Feb 27 18:18:33 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 27 Feb 2005 19:18:33 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: References: <20050227170006.0680B739F0@hormel.redhat.com> Message-ID: <1109528316.2748.2.camel@rousalka.dyndns.org> Le dimanche 27 f?vrier 2005 ? 18:47 +0100, Jocelyn Delalande a ?crit : >> On Sat, 2005-02-26 at 19:29 +0100, Nicolas Mailhot wrote: >> My hope is that we can go with ALSA sound mixing on by default and >> simply drop the arts gstreamer plugin, since AFAIK it's only used by >> people using arts for sound mixing and who want gstreamer apps to output >> to arts. > >I agree with you, moreover arts/gstreamer are not real solutions for >mixing (in a standard use I mean) many programs have troubles with >it... Enabling alsa mixing by default will make the ditribution more >user-friendly... In the meanwhile could the arts gstreamer part be separated (or moved to extras) ? Unless FC4 is already scheduled to be 100% ALSAified ? 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 terraformers at gmx.net Sun Feb 27 18:40:12 2005 From: terraformers at gmx.net (Lars) Date: Sun, 27 Feb 2005 19:40:12 +0100 Subject: kde-3.4 (3.3.92) in fc4 References: <421B3A3B.1070100@math.unl.edu> <421B44B8.4070603@redhat.com> <421CE072.30004@redhat.com> Message-ID: Than Ngo wrote: > Rex Dieter wrote: > >> Than Ngo wrote: >> >>> Rex Dieter wrote: >>> >>>> I know it's getting close, but I think it's important to try to get >>>> kde-3.4 (3.3.92beta2 at the moment) into fc4. If not, fedora users >>>> will have to wait for fc5 before seeing this (please correct me if >>>> I'm wrong). >>> >> >>> i'm still waiting for KDE-3.4 RC1, which will be released on Feb 22. >> >> >> Don't you mean Feb 26? That is what is posted on >> http://developer.kde.org/development-versions/kde-3.4-release-plan.html >> >> -- Rex >> > yes, i mean Feb 26., sorry for typo ! > > Than > *bump* ;) L From buildsys at redhat.com Sun Feb 27 18:50:51 2005 From: buildsys at redhat.com (Build System) Date: Sun, 27 Feb 2005 13:50:51 -0500 Subject: rawhide report: 20050227 changes Message-ID: <200502271850.j1RIopiN015364@porkchop.devel.redhat.com> Updated Packages: evince-0.1.5-1 -------------- * Sat Feb 26 2005 Marco Pesenti Gritti - 0.1.5-1 - Update to 0.1.5 kernel-2.6.10-1.1155_FC4 ------------------------ * Sat Feb 26 2005 Dave Jones - 2.6.11-rc5-bk1 rpmdb-fedora-1:4-0.20050227 --------------------------- From terraformers at gmx.net Sun Feb 27 18:57:28 2005 From: terraformers at gmx.net (Lars) Date: Sun, 27 Feb 2005 19:57:28 +0100 Subject: rawhide report: 20050227 changes References: <200502271850.j1RIopiN015364@porkchop.devel.redhat.com> Message-ID: Build System wrote: > > > > Updated Packages: > > evince-0.1.5-1 > -------------- > * Sat Feb 26 2005 Marco Pesenti Gritti - 0.1.5-1 > - Update to 0.1.5 > > kernel-2.6.10-1.1155_FC4 > ------------------------ > * Sat Feb 26 2005 Dave Jones > - 2.6.11-rc5-bk1 > > rpmdb-fedora-1:4-0.20050227 > --------------------------- > ...still waiting for kde3.4rc1 L From jspaleta at gmail.com Sun Feb 27 19:15:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 27 Feb 2005 14:15:42 -0500 Subject: reducing distribution CD count In-Reply-To: <1109515772.5676.29.camel@angua.localnet> References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> <1109515772.5676.29.camel@angua.localnet> Message-ID: <604aa791050227111510d45277@mail.gmail.com> On Sun, 27 Feb 2005 14:49:32 +0000, Nigel Metheringham > I would suggest that removing a package that has significant security > implications (any MTA or significant functionality network program would > fall into this category) is not good. People depending on FC for > security updates must be made aware that suddenly they must get security > updates from elsewhere or change to an alternative package. you touch on a larger issue about how a package vendor can effectively 'expire' any package to make sure users are aware its no longer being maintained by the original vendor. Currently such notifications for Core are made in the release-notes and its up to users installing the next release of Core to review the release notes. For extras I know of no discussion on how to address issues of notification of removals when they happen in the future. I think we can all agree that relying on the userbase to read the release-notes is probably a less effective method than some tool based approach that users/admins can interact with when doing normal update tasks. The closest thing we have right now in Core are yum and up2date's ability to list orphaned packages installed on the system that do not exist as part of a repository. But even this is a reactive step that users/admins must take to police theire own system. What we need is a way to have vendors 'push' a notice of expiration in a way that the tools notice and inform the admin about as a normal course of events. I know of no on-going experiments to implement anything like this. -jef From mlists at juma.me.uk Sun Feb 27 19:19:50 2005 From: mlists at juma.me.uk (Ismael Juma) Date: Sun, 27 Feb 2005 19:19:50 +0000 Subject: rawhide report: 20050227 changes In-Reply-To: References: <200502271850.j1RIopiN015364@porkchop.devel.redhat.com> Message-ID: <42221D56.6040807@juma.me.uk> Lars wrote: > [snip] > ...still waiting for kde3.4rc1 > [snip] Hi, For what is worth the following packages have already been updated to 3.4rc1 in cvs (http://cvs.fedora.redhat.com/viewcvs/devel/): - kdeaddons - kdeadmin - kdebase - kdegames - kdegraphics - kdelibs - kdenetwork Taking that into account, I think you won't have to wait for much longer (but I could be wrong). :) Regards, Ismael From terraformers at gmx.net Sun Feb 27 19:26:49 2005 From: terraformers at gmx.net (Lars) Date: Sun, 27 Feb 2005 20:26:49 +0100 Subject: rawhide report: 20050227 changes References: <200502271850.j1RIopiN015364@porkchop.devel.redhat.com> <42221D56.6040807@juma.me.uk> Message-ID: Ismael Juma wrote: > Lars wrote: >> [snip] >> ...still waiting for kde3.4rc1 >> [snip] > > Hi, > > For what is worth the following packages have already been updated to > 3.4rc1 in cvs (http://cvs.fedora.redhat.com/viewcvs/devel/): > - kdeaddons > - kdeadmin > - kdebase > - kdegames > - kdegraphics > - kdelibs > - kdenetwork > > Taking that into account, I think you won't have to wait for much longer > (but I could be wrong). :) > > Regards, > Ismael > yay! cheers L From mpeters at mac.com Sun Feb 27 20:25:36 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 27 Feb 2005 20:25:36 +0000 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226173908.GB27412@jadzia.bu.edu> (from mattdm@mattdm.org on Sat Feb 26 09:39:08 2005) References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226173908.GB27412@jadzia.bu.edu> Message-ID: <1109535936l.7040l.4l@devel.mpeters.us> On 02/26/2005 09:39:08 AM, Matthew Miller wrote: > > Although, since sudo isn't configured by default or used by anything, > it's > possible *that's* a candidate. I wouldn't cry if sudo disapeared. What I use it for could be done with the other solutions as well, and may even be better done with the other solutions. -- Michael A. Peters http://mpeters.us/ From mpeters at mac.com Sun Feb 27 20:28:55 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 27 Feb 2005 20:28:55 +0000 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <1109457562.27384.106.camel@cutter> (from skvidal@phy.duke.edu on Sat Feb 26 14:39:22 2005) References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <1109442347.27384.104.camel@cutter> <20050226182625.GI21024@angus.ind.WPI.EDU> <1109457562.27384.106.camel@cutter> Message-ID: <1109536135l.7040l.5l@devel.mpeters.us> On 02/26/2005 02:39:22 PM, seth vidal wrote: > > > I think it makes music. All I seem to get from it is beeps. LOL! :p -- Michael A. Peters http://mpeters.us/ From katzj at redhat.com Sun Feb 27 20:31:59 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 27 Feb 2005 15:31:59 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> Message-ID: <1109536319.22789.21.camel@bree.local.net> On Sat, 2005-02-26 at 04:22 -0300, Alexandre Oliva wrote: >On Feb 26, 2005, seth vidal wrote: >> I believe extras functions b/c they are are over 901 packages in >> extras. [snip] >Sure having CDs of Extras available for download would address part of >the problem: people would still be able to ask friends with big pipes >to download and burn CDs for them. But how convenient is the >experience of installing packages from such CDs be? Anaconda won't be >able to install packages from such CDs; will system-config-packages? Yes. And firstboot even asks for such CDs. And has since before Fedora existed :) Jeremy From mricon at gmail.com Sun Feb 27 21:55:37 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 27 Feb 2005 16:55:37 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <1109503437.15959.520.camel@mccallum.corsepiu.local> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <1109503437.15959.520.camel@mccallum.corsepiu.local> Message-ID: On Sun, 27 Feb 2005 12:23:57 +0100, Ralf Corsepius wrote: > > joe - yet another text editor ( nano / pico / emacs / ed / vi ) > Not just "yet another text editor". It's the only Wordstar compatible > ASCI-editor in Fedora (WordStar has dominated the editor market in the > late 1980/90's, generations of users have grown up with it.) Removing it > from FC means a severe loss of functionally to this generation of users. I agree wholeheartedly. It just wouldn't be the same without both of these guys. :) Cheers, -- Konstantin Ryabitsev Zlotniks, INC From grmoc at yahoo.com Sun Feb 27 22:06:22 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Sun, 27 Feb 2005 14:06:22 -0800 (PST) Subject: kde-3.4 (3.3.92) in fc4 In-Reply-To: Message-ID: <20050227220622.89456.qmail@web41523.mail.yahoo.com> By which, I believe, Lars means that it is out... .. and I mean that it is compiling on my box. (Well, at least the konstruct is. I havn't even looked for packages) -R --- Lars wrote: > Than Ngo wrote: > > > Rex Dieter wrote: > > > >> Than Ngo wrote: > >> > >>> Rex Dieter wrote: > >>> > >>>> I know it's getting close, but I think it's important to try to get > >>>> kde-3.4 (3.3.92beta2 at the moment) into fc4. If not, fedora users > >>>> will have to wait for fc5 before seeing this (please correct me if > >>>> I'm wrong). > >>> > >> > >>> i'm still waiting for KDE-3.4 RC1, which will be released on Feb 22. > >> > >> > >> Don't you mean Feb 26? That is what is posted on > >> http://developer.kde.org/development-versions/kde-3.4-release-plan.html > >> > >> -- Rex > >> > > yes, i mean Feb 26., sorry for typo ! > > > > Than > > > > *bump* ;) > > L > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From mbneto at gmail.com Sun Feb 27 22:07:32 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 27 Feb 2005 18:07:32 -0400 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <20050227170727.GJ21024@angus.ind.WPI.EDU> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> <20050227170727.GJ21024@angus.ind.WPI.EDU> Message-ID: <5cf776b8050227140752e50e2f@mail.gmail.com> please do not axe dovecot. it's the first imap server that runs out of the box without major trouble. On Sun, 27 Feb 2005 12:07:27 -0500, Chuck R. Anderson wrote: > On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote: > > dovecot/cryus - IMAP server cyrus does seem more like a specialty > > package when compared to the simplcity and utility of dovecot. OTOH > > cyrus is maintained for RHEL and other packages depends on cyrus-sasl. > > The community definatly appears to favor keeping dovecot and letting > > cyrus be religated to extras. > > If cyrus-sasl can't be separated easily from cyrus IMAP, then it needs > to stay. sasl is an authentication library that is needed by many > components of LDAP/Kerberos authentication strategies. From mpeters at mac.com Sun Feb 27 22:34:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 27 Feb 2005 22:34:49 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109522573.4515.5.camel@nexus.verbum.private> (from walters@redhat.com on Sun Feb 27 08:42:53 2005) References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <1109442544.5970.26.camel@rousalka.dyndns.org> <1109522573.4515.5.camel@nexus.verbum.private> Message-ID: <1109543689l.7040l.6l@devel.mpeters.us> On 02/27/2005 08:42:53 AM, Colin Walters wrote: > On Sat, 2005-02-26 at 19:29 +0100, Nicolas Mailhot wrote: > >BTW in a related topic if the arts part could be spun out of > >gstreamer-plugins this system could run without qt installed. > > My hope is that we can go with ALSA sound mixing on by default and > simply drop the arts gstreamer plugin, since AFAIK it's only used by > people using arts for sound mixing and who want gstreamer apps to > output > to arts. No objections from me - gstreamer-plugins is the only reasin qt is on my system. -- Michael A. Peters http://mpeters.us/ From ottohaliburton at comcast.net Sun Feb 27 22:37:31 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Sun, 27 Feb 2005 16:37:31 -0600 Subject: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducingdistribution CD count) In-Reply-To: <1109522637.27384.216.camel@cutter> Message-ID: <008d01c51d1c$ed26f410$4601a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of seth vidal > Sent: Sunday, February 27, 2005 10:44 AM > To: Development discussions related to Fedora Core > Subject: Re: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: > reducingdistribution CD count) > > On Sun, 2005-02-27 at 10:33 -0500, Mail Lists wrote: > >On Sun, Feb 27, 2005 at 02:09:44AM -0500, seth vidal wrote: > >> I will say this once again and for all, if anyone wants to find > >> themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS > >> TO DO THE WORK. > > > > Very valid points. However - things are not black and white - > > read LKML - Linus listens - even to non kernel hackers - it > > is one of his many remarkable strengths. > > and where have we implied that users won't be listened to? But as it is > if you want to listen to users on fedora-list and everyone else on > fedora-devel-list it is a full time job JUST to read the email. > > -sv I agree, but you have to listen to all of the complainers as well as contributors b/c quite often the new ideas come from the complainers rather than the contributors, cause generally developers are very happy with the status quo. No complaints means everything is okay and no need to develop or create new things. My problem is that everything is argued, some things should be allowed to die in the wind, they just aren't worth the effort to respond to. i.e. insulting someone for their ignorance of a topic or trivial suggestion, these things should just be allowed to die and push the good complaints or the good ideas and treat everything else as a quirk of nature. That would probably make these threads a hell of a lot shorter. From pozsy at uhulinux.hu Sun Feb 27 23:12:53 2005 From: pozsy at uhulinux.hu (=?iso-8859-1?Q?Pozs=E1r_Bal=E1zs?=) Date: Mon, 28 Feb 2005 00:12:53 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <1109442905.5970.33.camel@rousalka.dyndns.org> References: <20050226180809.GG21024@angus.ind.WPI.EDU> <1109442905.5970.33.camel@rousalka.dyndns.org> Message-ID: <20050227231253.GF11027@ojjektum.uhulinux.hu> On Sat, Feb 26, 2005 at 07:35:04PM +0100, Nicolas Mailhot wrote: > Le samedi 26 f?vrier 2005 ?? 13:08 -0500, Chuck R. Anderson a ?crit : > >On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote: > >> lftp - useful ftp client ( ftp, ncftp ) D:0 > > > >I think ncftp should be the one to be removed from Core. lftp has > >more functionality (http), and is installed by default, whereas ncftp > >is not installed by default. Also, while ncftp itself is OSS > >(Clarified Artistic License), other components from the same company > >are not (NcFTPd server, libNcFTP). > > +1 for keeping lftp and moving ncftp out. This is way overdue. ncftp can do recursive get/put. Apart from that, lftp is clearly better imho. -- pozsy From cra at WPI.EDU Sun Feb 27 23:15:02 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sun, 27 Feb 2005 18:15:02 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050227231253.GF11027@ojjektum.uhulinux.hu> References: <20050226180809.GG21024@angus.ind.WPI.EDU> <1109442905.5970.33.camel@rousalka.dyndns.org> <20050227231253.GF11027@ojjektum.uhulinux.hu> Message-ID: <20050227231502.GN21024@angus.ind.WPI.EDU> On Mon, Feb 28, 2005 at 12:12:53AM +0100, Pozs?r Bal?zs wrote: > ncftp can do recursive get/put. Apart from that, lftp is clearly better > imho. lftp can do recursive get, not sure about put. From msevior at physics.unimelb.edu.au Mon Feb 28 01:46:51 2005 From: msevior at physics.unimelb.edu.au (Martin Sevior) Date: Mon, 28 Feb 2005 12:46:51 +1100 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <20050225095531.EA00873351@hormel.redhat.com> References: <20050225095531.EA00873351@hormel.redhat.com> Message-ID: <1109555212.14742.2443.camel@localhost.localdomain> On Thu, 24 Feb 2005, Peter Robinson wrote: > So with these removed from Core I assume they are going to be in Extras. > Correct? In Extras will they continue to be maintained as before or will > they need someone to step up and maintain them? The reason I ask is it > would be a pity to see abiword and gnumeric disappear as I find them > considerably faster than OOo and in the case of Abiword it supports a > number of word files that don't work to well with OOo.I also use grip. > While I'm happy for them to be in extras rather than core I would still > like them to be around. > The plan is to add these packages to Extras as demand requires. Volunteers > are always wanted to help maintain packages. Are you interested? Please > see http://fedoraproject.org/wiki/Extras_2fCvsAccess How sad. We constantly push the envolope, fix bugs, provide upgrades and provide rpm's for stable and development version of our program for FC3, FC2, FC1 and redhat 9 on our website. Maybe we should just stick with source and Debian. I've been seriously thinking of moving to Ubuntu anyway. Well I guess that's just about it for FC as a community distro. Martin Sevior Core AbiWord Developer. Hint type "word Processor" into google and see what you get. It isn't either MS Word or OOo From mpeters at mac.com Mon Feb 28 03:04:12 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 28 Feb 2005 03:04:12 +0000 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109528316.2748.2.camel@rousalka.dyndns.org> (from Nicolas.Mailhot@laPoste.net on Sun Feb 27 10:18:33 2005) References: <20050227170006.0680B739F0@hormel.redhat.com> <1109528316.2748.2.camel@rousalka.dyndns.org> Message-ID: <1109559852l.8695l.0l@devel.mpeters.us> On 02/27/2005 10:18:33 AM, Nicolas Mailhot wrote: > > In the meanwhile could the arts gstreamer part be separated (or moved > to > extras) ? Unless FC4 is already scheduled to be 100% ALSAified ? If core is not going to be 100% alsafied then the plugin should stay in core, so that you don't have to maintain two src.rpm's for the same source tarball. Qt is going to be in core, so removing the arts plugin isn't going to save space, and should not be done if there are cases where it is needed for a functional sound system out of the box. -- Michael A. Peters http://mpeters.us/ From ndbecker2 at verizon.net Mon Feb 28 03:07:10 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Sun, 27 Feb 2005 22:07:10 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226174202.GA2935@chrys.ms.mff.cuni.cz> <4220D9D7.6C84C527@jwz.org> Message-ID: Jamie Zawinski wrote: > Miloslav Trmac wrote: >> >> > talk - protocol is getting old with IM >> UNIX kernel interface is "getting old" too. > > This proves that there is *no* package you can suggest removing that > someone won't object to. It's like we're seeing "Godwin's Law of > Shell Scripts" or something. > > I think the time for democracy has passed. Someone needs to just > unilaterally make a decision and then deal with problems later. > You know, there is another alternative that is neither concensus nor dictatorship. We could vote. From ndbecker2 at verizon.net Mon Feb 28 03:12:15 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Sun, 27 Feb 2005 22:12:15 -0500 Subject: Package pruning for FC4 and beyond References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> Message-ID: Michael A. Peters wrote: > > On 02/25/2005 09:23:41 PM, Eric Warnke wrote: > >> + emacs ( pick emacs or xemacs and move the other to extras ) > > keep emacs, move xemacs. > Jamie? How's that sound? :) From ndbecker2 at verizon.net Mon Feb 28 03:11:01 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Sun, 27 Feb 2005 22:11:01 -0500 Subject: Package pruning for FC4 and beyond References: <422007DD.1020404@snowmoon.com> Message-ID: Alexandre Oliva wrote: > On Feb 26, 2005, Eric Warnke wrote: > >> dovecot - IMAP server ( duplication of effort ) > > What's the other IMAP/POP server in Core that can export mailboxes in > the standard mbox format as delivered by the default MTA, and can do > preauth when started from the command line for fetchmail over ssh? > I use dovecot to export mail delivered in maildir format. Don't know about mbox - but you're not suggesting that cyrus exports standard format, are you? cyrus runs its own database - one reason I don't use it. From ndbecker2 at verizon.net Mon Feb 28 03:08:48 2005 From: ndbecker2 at verizon.net (Neal Becker) Date: Sun, 27 Feb 2005 22:08:48 -0500 Subject: Package pruning for FC4 and beyond References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <20050226141119.GV853@devserv.devel.redhat.com> Message-ID: Jakub Jelinek wrote: > On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote: >> ElectricFence - Development only nothing depends on it - 1 objection, >> but I still say it's usage does not justify it remaining in core - there >> is at least one competing package ( dmalloc, valgrind ) > > valgrind is i386 only (therefore not a replacement for efence) and > dmalloc is far worse then efence. If anything needs to be dumped to > Extras, then it is dmalloc, not ElectricFence. Yes yes yes and yes. From mpeters at mac.com Mon Feb 28 03:25:37 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 28 Feb 2005 03:25:37 +0000 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <1109555212.14742.2443.camel@localhost.localdomain> (from msevior@physics.unimelb.edu.au on Sun Feb 27 17:46:51 2005) References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> Message-ID: <1109561137l.8695l.1l@devel.mpeters.us> On 02/27/2005 05:46:51 PM, Martin Sevior wrote: > > > How sad. We constantly push the envolope, fix bugs, provide upgrades > and > provide rpm's for stable and development version of our program for > FC3, FC2, FC1 and redhat 9 on our website. > > Maybe we should just stick with source and Debian. > > I've been seriously thinking of moving to Ubuntu anyway. > > Well I guess that's just about it for FC as a community distro. > > Martin Sevior > > Core AbiWord Developer. As someone is an absolutely huge fan of AbiWord, and as a member of the Fedora "community" as a user and not a @hat address, I would like to comment on this. The problem as I see it is that Fedora Core is getting too big with too much duplicated functionallity. The Fedora Extas infrastructure now exists as a place where alternative packages can still be maintained and developed that integrate tightly with Fedora Core, and with quality control - by the very community that uses them. I see that as a good thing, it is a lot easier to get Fedora to the public if it is smaller to download, cheaper to burn (less CD's), etc. A lot of the popularity of Ubuntu is that it is a small distro - not a lot of CD's. If I had my way, OO.o and Evolution would go to extras and AbiWord/ Gnumeric/Balsa/Pan would be in Core - but the user community uses OO.o and Evolution, those apps are more popular. That doesn't mean AbiWord/Gnumeric/Balsa etc. shouldn't be available, but it does mean that currently they are downloaded for every CD/DVD install and usually never installed by the users. By moving them into Extras, they are still there for people who do want to use them, but Core is a smaller download for the majority who do not. Abiword, Gnumeric, and GStreamer are my personal favorite OSS projects. It is sad imho to see the first two going out of core, but I think it needs to done, at least until people figure out that OO.o is too slow and bloated with too high maintenance to be worth it. OO.o had excellent marketing - that's what gave it momentum, it will (I think) die down (especially now that Windows AbiWord and OS X AbiWord are starting to take shape) This may actually be a good thing for AbiWord - since it is going to be in Extras, and you guys already build rpm's for FC, perhaps someone from AbiWord could become the Extras maintainer for it, ensuring the quality of the product available through yum for Fedora Core users. I'm not on AbiWord devel list, but maybe someone there wants to do that. -- Michael A. Peters http://mpeters.us/ From mattdm at mattdm.org Mon Feb 28 03:36:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 27 Feb 2005 22:36:19 -0500 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <1109555212.14742.2443.camel@localhost.localdomain> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> Message-ID: <20050228033618.GA32178@jadzia.bu.edu> On Mon, Feb 28, 2005 at 12:46:51PM +1100, Martin Sevior wrote: > How sad. We constantly push the envolope, fix bugs, provide upgrades and > provide rpm's for stable and development version of our program for > FC3, FC2, FC1 and redhat 9 on our website. On the contrary -- you're already maintaining RPMs, so why not maintain them as part of Extras? This could be a significant improvement. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From smooge at gmail.com Mon Feb 28 03:41:28 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sun, 27 Feb 2005 20:41:28 -0700 Subject: XFCE packages gone? In-Reply-To: <1109414098.26364.253.camel@localhost.localdomain> References: <200502251944.j1PJiHoa020239@leto.astradyne.corp> <20050225200240.GC25441@nostromo.devel.redhat.com> <1109414098.26364.253.camel@localhost.localdomain> Message-ID: <80d7e40905022719412f434d6f@mail.gmail.com> On Sat, 26 Feb 2005 10:34:57 +0000, David Woodhouse wrote: > For Exim/Postfix I don't hold out as much hope. I think the 'duplicate > functionality' argument is even more backwards there, but I'm certainly > willing to have a play with Postfix if I get time. It'd be useful if > someone could suggest ways that a Postfix configuration can do the > things which were possible with Exim in FC3 -- in particular: > Do all of the SMTP handlers have enough documentation to hit various CC levels? We are using sendmail mostly for the fact that the various documentation we are required was there for it a while ago and not for Postfix and Exim. Yes somehow needing a masters degree to configure a tool seems to make it a better choice for some large industries... -- Stephen J Smoogen. CSIRT/Linux System Administrator From riel at redhat.com Mon Feb 28 04:25:57 2005 From: riel at redhat.com (Rik van Riel) Date: Sun, 27 Feb 2005 23:25:57 -0500 (EST) Subject: Xen: Installing guest VMs In-Reply-To: References: Message-ID: On Sat, 26 Feb 2005, Robin Green wrote: > An intriguing possibility is having a pre-install stage of Anaconda for > guest installs, which runs on the host as a normal program, e.g. for > things like hooking up LVM volumes to the new VM. This sounds like a nice idea. > You could even rewrite to run the ENTIRE install process on the host, > without even booting the guest kernel, although my suspicion is that > that route would involve an unnecessary amount of effort. This doesn't ;) I would imagine that eg. FC6 might have special features that are not in FC4, meaning that the anaconda running on the host would need to be enhanced to deal with the configuration of future versions of the distribution. Much easier to run the installer that matches the distro that's being installed, so it knows how to configure things right. Using a pre-install program to call the installer might be a nice touch, thoug. -- "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 msevior at physics.unimelb.edu.au Mon Feb 28 06:36:00 2005 From: msevior at physics.unimelb.edu.au (Martin Sevior) Date: Mon, 28 Feb 2005 17:36:00 +1100 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <20050228033618.GA32178@jadzia.bu.edu> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> Message-ID: <1109572560.14742.2502.camel@localhost.localdomain> On Sun, 2005-02-27 at 22:36 -0500, Matthew Miller wrote: > On Mon, Feb 28, 2005 at 12:46:51PM +1100, Martin Sevior wrote: > > How sad. We constantly push the envolope, fix bugs, provide upgrades and > > provide rpm's for stable and development version of our program for > > FC3, FC2, FC1 and redhat 9 on our website. > > On the contrary -- you're already maintaining RPMs, so why not maintain them > as part of Extras? This could be a significant improvement. > Look as Mike Peters has pointed out we're already being beaten up by SUN marketing. Putting us into Extras makes it an order of magnitude harder for people to find us, so spare me the double-think. My personal experience of Fedora-Extras has been very negative so far. It took months for FC3 extras to appear after FC-core. It appears pretty disingenuous though for the largest Linux company with around $1,000,000,000 in the bank and profits growing by 50% per year to reduce their level of support for us. I don't feel much loyality to FC or RedHat anymore. That said, we want to make our software as widely available as possible. If someone from the FC community wants to maintain AbiWord for FC-Extras we'd love to hear from them. Martin From m.f.h at web.de Mon Feb 28 06:07:47 2005 From: m.f.h at web.de (Marcus Hartig) Date: Mon, 28 Feb 2005 07:07:47 +0100 Subject: (FC4) x86_64 GCC and building 32bit apps Message-ID: <4222B533.2060901@web.de> Hello, after reading the article "GNU Compiler Collection: Performance under Linux" in the actual c't magazine http://www.heise.de/ct/ I decided to recompile my 32bit Fedora firefox 1.0.1 with better CFLAGS like in the big GCC test read. And -Os was very slow there... They have better performance results with FC3 GCC 3.4.3 and e.g LAME with the SSE extensions on 32bit. About 3 min. faster LAME encoding 17 wavs with SSE activated.... So I have installed all needed i386 pkgs (i think) from X11, glibc to required gnome things on my up2date x86_64 FC4 rawhide. But I get always errors compiling firefox or building the rpm about the ld complaining an uncompatible 64bit obj or not finding the X11 extensions. Why is the GCC 3.4.3-20 not using the 32bit libs, I see he use the 64bit gnome ones while compiling, when I give him -m32 in mozconfig and or tried in the firefox spec file: [...] ac_add_options --enable-optimize="-O2 -m32 -msse2 -mtune=athlon64 -march=athlon-xp" ... ac_add_options --x-libraries=/usr/X11R6/lib ac_add_options --libdir=/usr/lib ac_add_options --x-includes=/usr/X11R6/include What is here wrong? Or which switch is needed for GCC building and searching 32bit libs/apps? Why is it searching in ../lib64? Greetings, Marcus From skvidal at phy.duke.edu Mon Feb 28 07:55:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 28 Feb 2005 02:55:46 -0500 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <1109572560.14742.2502.camel@localhost.localdomain> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> Message-ID: <1109577346.27384.231.camel@cutter> >Look as Mike Peters has pointed out we're already being beaten up by SUN >marketing. Putting us into Extras makes it an order of magnitude harder >for people to find us, so spare me the double-think. just one point. When fc3 was released extras was not available. When fc4 is released extras will be available. It will also be included an enabled in the default yum.repos.d files. so then a user running: yum install abiword will just get it. No searching, no groping about, it's just there. -sv -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Feb 28 09:10:56 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Feb 2005 10:10:56 +0100 (CET) Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050227231253.GF11027@ojjektum.uhulinux.hu> References: <20050226180809.GG21024@angus.ind.WPI.EDU> <1109442905.5970.33.camel@rousalka.dyndns.org> <20050227231253.GF11027@ojjektum.uhulinux.hu> Message-ID: <7658.192.54.193.137.1109581856.squirrel@rousalka.dyndns.org> On Lun 28 f?vrier 2005 0:12, Pozs?r Bal?zs a ?crit : > On Sat, Feb 26, 2005 at 07:35:04PM +0100, Nicolas Mailhot wrote: >> Le samedi 26 f?vrier 2005 ?? 13:08 -0500, Chuck R. Anderson a ?crit : >> >On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote: >> >> lftp - useful ftp client ( ftp, ncftp ) D:0 >> > >> >I think ncftp should be the one to be removed from Core. lftp has >> >more functionality (http), and is installed by default, whereas ncftp >> >is not installed by default. Also, while ncftp itself is OSS >> >(Clarified Artistic License), other components from the same company >> >are not (NcFTPd server, libNcFTP). >> >> +1 for keeping lftp and moving ncftp out. This is way overdue. > > ncftp can do recursive get/put. Apart from that, lftp is clearly better > imho. So does lftp, unless I've missed something -- Nicolas Mailhot From tmraz at redhat.com Mon Feb 28 09:13:34 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 28 Feb 2005 10:13:34 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <42207E54.9090902@feuerpokemon.de> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <42207E54.9090902@feuerpokemon.de> Message-ID: <1109582014.5885.7.camel@perun.redhat.usu> On Sat, 2005-02-26 at 14:49 +0100, dragoran wrote: > "SDL* - kdeaddons is the only thing that depends on this" > dropping sdl isn't a good idea because many third party apps require it. +1 I agree that removing most games (except the basic as gnome-games) from FC is desirable however removing SDL would mean that even for installing almost any games this dependency would have to be installed by user. I don't think it's a good idea. -- Tomas Mraz From kzak at redhat.com Mon Feb 28 10:39:16 2005 From: kzak at redhat.com (Karel Zak) Date: Mon, 28 Feb 2005 11:39:16 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <20050226173143.GC21024@angus.ind.WPI.EDU> References: <422007DD.1020404@snowmoon.com> <1109399272l.7697l.9l@devel.mpeters.us> <20050226173143.GC21024@angus.ind.WPI.EDU> Message-ID: <1109587156.10657.1.camel@petra> On Sat, 2005-02-26 at 12:31 -0500, Chuck R. Anderson wrote: > On Sat, Feb 26, 2005 at 06:27:52AM +0000, Michael A. Peters wrote: > > >lynx - duplicate effort ( elinks ) > > > > keep lynx - a lot of existing scripts depend upon it, lynx really is > > almost as standard on *nix as vi - it is THE cli http client. > > Is elinks command-line compatible to lynx? It it is, I would prefer > to see elinks, as it renders pages much better (supports frames and > tables, etc). Agree, elinks features: * Lots of protocols (local files, finger, http, https, ftp, smb, ipv4, ipv6) * Authentication (HTTP authentication, Proxy authentication) * Persistent cookies * Cute menus and dialogs * Tabbed browsing * Support for browser scripting (Perl, Lua, Guile) * Tables and frames rendering * Colors * Background (non-blocking) downloads ... and really active upstream developers. Karel -- Karel Zak From tagoh at redhat.com Mon Feb 28 11:36:57 2005 From: tagoh at redhat.com (Akira TAGOH) Date: Mon, 28 Feb 2005 20:36:57 +0900 (JST) Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <4220B0C2.2060007@snowmoon.com> References: <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> Message-ID: <20050228.203657.4204231372799843702.tagoh@redhat.com> >>>>> On Sat, 26 Feb 2005 12:24:18 -0500, >>>>> "EW" == Eric Warnke wrote: EW> h2ps - should let people that use multinational tools decide which one EW> go and which ones stay Right now is there any good candidate tool to replace it? otherwise it's required to do print the Korean text out. EW> lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether EW> those scripts are not part of core or they are not marked correctly. If EW> you can surf the web with either, you can download them from extras. If EW> either has a dependancy in core the .src.rpm needs to be corrected. EW> Personally I think lynx should go to extras. lynx/elinks has a problem to look at each native encodings which almost website uses since we are using UTF-8 locale. w3m only can takes care of it. for m17n, we should keep w3m in FC for the usability. EW> *New additions to the likley list* EW> w3m/w3m-el - another text pager/web browser w3m-el might be moved into FE, but not w3m as the above reason. EW> Canna - Superceeded by IIMF - nothing depends ! 10MB Don't move. IIIMF is just a framework, and Canna is used as the backend of Japanese. EW> *VFlib2 - Required by MajicPoint and ghostscript - only if we can break EW> the ghostscript compatibility VFlib2 is required for the correct vertical writing printing on ghostscript. don't break it without any fixes. Regards, -- Akira TAGOH From tagoh at redhat.com Mon Feb 28 11:26:01 2005 From: tagoh at redhat.com (Akira TAGOH) Date: Mon, 28 Feb 2005 20:26:01 +0900 (JST) Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050226204448.GC1105875@hiwaay.net> References: <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226204448.GC1105875@hiwaay.net> Message-ID: <20050228.202601.3611407741281863970.tagoh@redhat.com> >>>>> On Sat, 26 Feb 2005 14:44:48 -0600, >>>>> "CA" == Chris Adams wrote: CA> Once upon a time, Eric Warnke said: >> lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether >> those scripts are not part of core or they are not marked correctly. If >> you can surf the web with either, you can download them from extras. If >> either has a dependancy in core the .src.rpm needs to be corrected. >> Personally I think lynx should go to extras. CA> At one time, lynx was the only one of those that could do SSL, basic CA> authentication, etc. (I don't know the current state of all of them CA> because I use lynx). I think it may still be the only one that verifies CA> SSL certificates. w3m can do it as well, though. -- Akira TAGOH From dcbw at redhat.com Mon Feb 28 13:08:15 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 28 Feb 2005 08:08:15 -0500 (EST) Subject: Binaries spinning in relocate_doit() Message-ID: Is there any particular reason that in the past day or two, most of my gnome apps (gedit, gnome-panel, nautilus) get hung in at least one thread in relocate_doit() and take 100% cpu? Other threads still continue to run, but whatever thread does get blocked usually looks like this (from gnome-panel): Loaded symbols for /usr/lib/bonobo/monikers/libmoniker_std_2.so 0x007227e2 in ?? () at rtld.c:586 from /lib/ld-linux.so.2 586 relocate_doit (void *a) (gdb) t a a bt Thread 2 (Thread -1211847760 (LWP 10965)): #0 0x007227e2 in ?? () at rtld.c:586 from /lib/ld-linux.so.2 #1 0x007fc0d4 in *__GI___poll (fds=0x861ff4, nfds=23, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:86 #2 0x00a12999 in g_main_context_iterate (context=0x8aaa238, block=1, dispatch=1, self=0x89df428) at gmain.c:2880 #3 0x00a12d2f in IA__g_main_loop_run (loop=0x8aa9f60) at gmain.c:2782 #4 0x003e4b3f in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #5 0x00a6a17c in ?? () from /usr/lib/libglib-2.0.so.0 #6 0xb7c4a448 in ?? () #7 0x00a2b66b in g_thread_create_proxy (data=0x89df428) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) Thread 1 (Thread -1208997408 (LWP 10958)): #0 0x007227e2 in ?? () at rtld.c:586 from /lib/ld-linux.so.2 #1 0x007fdd79 in ?? () from /lib/tls/libc.so.6 #2 0x0097d59c in ?? () from /usr/X11R6/lib/libX11.so.6 #3 0x0090b876 in XUnlockDisplay () from /usr/X11R6/lib/libX11.so.6 #4 0x0090bb67 in _X11TransBytesReadable () from /usr/X11R6/lib/libX11.so.6 #5 0x008f1b43 in _XEventsQueued () from /usr/X11R6/lib/libX11.so.6 #6 0x008e2039 in XPending () from /usr/X11R6/lib/libX11.so.6 #7 0x003219fd in gdk_check_xpending (display=0x0) at gdkevents-x11.c:147 #8 0x00324215 in gdk_event_prepare (source=0x0, timeout=0x0) at gdkevents-x11.c:2177 #9 0x00a11e9e in IA__g_main_context_prepare (context=0x89d4c00, priority=0xbfef7778) at gmain.c:2265 #10 0x00a127ac in g_main_context_iterate (context=0x89d4c00, block=1, dispatch=1, self=0x89b5348) at gmain.c:2558 #11 0x00a12d2f in IA__g_main_loop_run (loop=0x8a9a4d8) at gmain.c:2782 #12 0x06f3a2ae in IA__gtk_main () at gtkmain.c:963 #13 0x08063c73 in main (argc=-1074827748, argv=0xbfef7914) at main.c:90 (gdb) Dan From pvrabec at redhat.com Mon Feb 28 13:20:10 2005 From: pvrabec at redhat.com (Peter Vrabec) Date: Mon, 28 Feb 2005 14:20:10 +0100 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109400838.5676.167.camel@arena.soho.bytebot.net> References: <422007DD.1020404@snowmoon.com> <1109400838.5676.167.camel@arena.soho.bytebot.net> Message-ID: <42231A8A.1080702@redhat.com> I don't mind. Some people in Brno office will invite this replacement. Colin Charles wrote: > On Sat, 2005-02-26 at 03:37 -0300, Alexandre Oliva wrote: > >>>epic - duplicate effort >> >>Is there any other text-mode IRC client in Core? > > > I've proposed its replacement with irssi before. It was generally agreed > upon on this list... > > pvrabec: mind moving epic to Extras, and irssi from Extras into Core? > > Thanks From mattdm at mattdm.org Mon Feb 28 14:01:26 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 28 Feb 2005 09:01:26 -0500 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <1109572560.14742.2502.camel@localhost.localdomain> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> Message-ID: <20050228140126.GA15793@jadzia.bu.edu> On Mon, Feb 28, 2005 at 05:36:00PM +1100, Martin Sevior wrote: > Look as Mike Peters has pointed out we're already being beaten up by SUN > marketing. Putting us into Extras makes it an order of magnitude harder > for people to find us, so spare me the double-think. This won't be the case soon. It may take until FC5, though, so have some patience > My personal experience of Fedora-Extras has been very negative so far. > It took months for FC3 extras to appear after FC-core. Extras is just getting started, so it's not fair to make your judgement based on experience so far. FC4 extras will be available with the release, and yum-enabled. FC5 extras will, hopefully, be pickable right in the installer. > That said, we want to make our software as widely available as possible. > If someone from the FC community wants to maintain AbiWord for FC-Extras > we'd love to hear from them. I thought you said you were already maintaining FC rpms. What am I missing here? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ph18 at cornell.edu Mon Feb 28 14:01:31 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Mon, 28 Feb 2005 09:01:31 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <1109535936l.7040l.4l@devel.mpeters.us> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226173908.GB27412@jadzia.bu.edu> <1109535936l.7040l.4l@devel.mpeters.us> Message-ID: On Sun, 27 Feb 2005 20:25:36 +0000, Michael A. Peters wrote: > On 02/26/2005 09:39:08 AM, Matthew Miller wrote: > >> Although, since sudo isn't configured by default or used by anything, >> it's >> possible *that's* a candidate. > > I wouldn't cry if sudo disapeared. > What I use it for could be done with the other solutions as well, and > may even be better done with the other solutions. > We use sudo extensively on every unix system we have. If you've got more than one person doing sysadmining on a machine, it's essential. If I wanted to spend time tracking down and installing all the basic things I need to make a system where I can be productive, I'd install Solaris, not Linux. From mattdm at mattdm.org Mon Feb 28 14:02:50 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 28 Feb 2005 09:02:50 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226173908.GB27412@jadzia.bu.edu> <1109535936l.7040l.4l@devel.mpeters.us> Message-ID: <20050228140250.GB15793@jadzia.bu.edu> On Mon, Feb 28, 2005 at 09:01:31AM -0500, Paul A. Houle wrote: > If I wanted to spend time tracking down and installing all the basic > things I need to make a system where I can be productive, I'd install > Solaris, not Linux. Moving it to extras shouldn't require any "tracking down". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dnjinc at wowway.com Mon Feb 28 14:09:02 2005 From: dnjinc at wowway.com (Demond James) Date: Mon, 28 Feb 2005 09:09:02 -0500 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <1109577346.27384.231.camel@cutter> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> <1109577346.27384.231.camel@cutter> Message-ID: <422325FE.9090709@wowway.com> seth vidal wrote: > >>Look as Mike Peters has pointed out we're already being beaten up by SUN >>marketing. Putting us into Extras makes it an order of magnitude harder >>for people to find us, so spare me the double-think. >> >> > > just one point. When fc3 was released extras was not available. When > fc4 is released extras will be available. > It will also be included an enabled in the default yum.repos.d files. > > so then a user running: > yum install abiword > > will just get it. No searching, no groping about, it's just there. > > -sv > To add one more point, starting with FC5 the user will be able to install AbiWord when through anaconda if it's maintained in FE. The way I'm thinking is that the FE packages will show up in the package selection list, hopefully that's how it will be implemented. It would definitely be great if the FC rpm maintainer at AbiWord could submit that same package to Fedora Extras and maintain it there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Mon Feb 28 14:28:54 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Feb 2005 09:28:54 -0500 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <1109572560.14742.2502.camel@localhost.localdomain> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> Message-ID: <604aa79105022806284d720448@mail.gmail.com> On Mon, 28 Feb 2005 17:36:00 +1100, Martin Sevior wrote: >I don't feel much loyality to FC > or RedHat anymore. That's unfortunate, especially since we are now seeing public facing progress in Extras and the newly established contributor process in place. If there is nothing that can be said to encourage you to take a constructive role in the evolving contributor process during its critical initial stages, then please, check back from time to time as the process matures and Core evolves accordingly. The situation we are in now.. with the inclusion of java is a rather extradinary event, and I dare say would have lead to similar packaging decisions by Red Hat if it happened in the rhl timeframe. We can either agree with the decision and the constraints or we disagree.. but please lets not imply malice in the decision-making. I hope you check back into the process in the fc5 timeframe when the discussion to make Core drastically smaller takes on much more weight if the anaconda development plan holds true to expected timeframe for repo support. If it wasn't clear before... I'll repeat it. I'm pretty sure everyone with a stake in the race hoped to get Extras up on its feet quicker. And for whomever I'm allowed to speak for, I apologize for it taking this long. But now that its here, everyone has a choice to make to be involved or not. Core is going to get smaller, Extras is going to take on more weight through the next few releases... in an evolutionary way. The end result will not look exactly like ubuntu, but things are going to move somewhat into that direction which means a non-trivial number of packages is going to move out of Core into Extras over time.. and Extras will take on more importance as a result. We can't snap our fingers and make that happen overnight. And its far more constructive to focus on thinking and working about how Extras needs to operate in an fc6 timescale than to continue to morn decisions Red Hat has already made. -jef"No one in the sum total of human history has ever felt a deeper rage than what I felt when oneko was ripped out of rhl. I fell into a darkness, deep and bottomless. I wandered the earth, lost and forlorn searching for meaning. I swore an oath to seek my revenge on those who have hurt me so. I have fought a daily struggle to break open the Red gates so that I have can get oneko back into distribution. And now that Fedora Extras is finally here and my goal is at hand, its not so compelling anymore cuz xdesktopwaves is sooo much cooler."spaleta From msevior at physics.unimelb.edu.au Mon Feb 28 15:15:17 2005 From: msevior at physics.unimelb.edu.au (msevior at physics.unimelb.edu.au) Date: Tue, 1 Mar 2005 02:15:17 +1100 (EST) Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <20050228140126.GA15793@jadzia.bu.edu> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> <20050228140126.GA15793@jadzia.bu.edu> Message-ID: <31925.211.28.207.95.1109603717.squirrel@kiosk.ph.unimelb.edu.au> > On Mon, Feb 28, 2005 at 05:36:00PM +1100, Martin Sevior wrote: >> Look as Mike Peters has pointed out we're already being beaten up by SUN >> marketing. Putting us into Extras makes it an order of magnitude harder >> for people to find us, so spare me the double-think. > > This won't be the case soon. It may take until FC5, though, so have some > patience > >> My personal experience of Fedora-Extras has been very negative so far. >> It took months for FC3 extras to appear after FC-core. > > Extras is just getting started, so it's not fair to make your judgement > based on experience so far. FC4 extras will be available with the release, > and yum-enabled. FC5 extras will, hopefully, be pickable right in the > installer. > Well if it's so great why isn't all the java and server stuff placed in Extras? Developers and sys-admins know how to find stuff. Ordinary users (abiword's target market) are less inclined. I know RH big enterprise users pay the bills but I'd rather naively bought into the idea that FC was about building community with grass roots projects. Now it appears you have to have a substantial group of people on a payroll to get into FC core. >> That said, we want to make our software as widely available as possible. >> If someone from the FC community wants to maintain AbiWord for FC-Extras >> we'd love to hear from them. > > I thought you said you were already maintaining FC rpms. What am I missing > here? > Well it appears my good friend and fellow developer Marc Maurer has stepped up to the job of maintaining AbiWord in Extras so FCE will get great AbiWord packages right after releases. What do we have to do to get back into core? Martin From mattdm at mattdm.org Mon Feb 28 15:54:27 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 28 Feb 2005 10:54:27 -0500 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <31925.211.28.207.95.1109603717.squirrel@kiosk.ph.unimelb.edu.au> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> <20050228140126.GA15793@jadzia.bu.edu> <31925.211.28.207.95.1109603717.squirrel@kiosk.ph.unimelb.edu.au> Message-ID: <20050228155427.GB19309@jadzia.bu.edu> On Tue, Mar 01, 2005 at 02:15:17AM +1100, msevior at physics.unimelb.edu.au wrote: > Well if it's so great why isn't all the java and server stuff placed in > Extras? Developers and sys-admins know how to find stuff. Ordinary users Some of it will be. > (abiword's target market) are less inclined. I know RH big enterprise > users pay the bills but I'd rather naively bought into the idea that FC > was about building community with grass roots projects. Now it appears you > have to have a substantial group of people on a payroll to get into FC > core. I don't think any office apps should be in Core. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mike at flyn.org Mon Feb 28 15:53:42 2005 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 28 Feb 2005 09:53:42 -0600 Subject: Package pruning for FC4 and beyond In-Reply-To: <1109543689l.7040l.6l@devel.mpeters.us> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <1109442544.5970.26.camel@rousalka.dyndns.org> <1109522573.4515.5.camel@nexus.verbum.private> <1109543689l.7040l.6l@devel.mpeters.us> Message-ID: <20050228155342.GA14739@imp.flyn.org> >>> BTW in a related topic if the arts part could be spun out of >>> gstreamer-plugins this system could run without qt installed. >> My hope is that we can go with ALSA sound mixing on by default and >> simply drop the arts gstreamer plugin, since AFAIK it's only used by >> people using arts for sound mixing and who want gstreamer apps to >> output >> to arts. > No objections from me - gstreamer-plugins is the only reasin qt is on > my system. See also https://bugzilla.redhat.com/beta/show_bug.cgi?id=108463. -- Mike :wq From mattdm at mattdm.org Mon Feb 28 16:05:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 28 Feb 2005 11:05:15 -0500 Subject: to the rescue [was Re: fedora-devel-list Digest, Vol 12, Issue 86] In-Reply-To: <604aa79105022806284d720448@mail.gmail.com> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> <604aa79105022806284d720448@mail.gmail.com> Message-ID: <20050228160515.GA19961@jadzia.bu.edu> On Mon, Feb 28, 2005 at 09:28:54AM -0500, Jeff Spaleta wrote: > -jef"No one in the sum total of human history has ever felt a deeper > rage than what I felt when oneko was ripped out of rhl. I fell into a > darkness, deep and bottomless. I wandered the earth, lost and forlorn > searching for meaning. I swore an oath to seek my revenge on those who > have hurt me so. I have fought a daily struggle to break open the Red > gates so that I have can get oneko back into distribution. And now > that Fedora Extras is finally here and my goal is at hand, its not so > compelling anymore cuz xdesktopwaves is sooo much cooler."spaleta I have an oneko RPM we could add to extras if you want. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rahulsundaram at gmail.com Mon Feb 28 16:06:32 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 28 Feb 2005 21:36:32 +0530 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: <31925.211.28.207.95.1109603717.squirrel@kiosk.ph.unimelb.edu.au> References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> <20050228140126.GA15793@jadzia.bu.edu> <31925.211.28.207.95.1109603717.squirrel@kiosk.ph.unimelb.edu.au> Message-ID: Hi > > > > Well if it's so great why isn't all the java and server stuff placed in > Extras? Developers and sys-admins know how to find stuff. I believe the reason for this was already discussed in this list. basically this is the first time Free java has become good enough to be shipped with a distro and since fedora developers did the major work in bringing it up to this point they want to push it better. Ordinary users > (abiword's target market) are less inclined. I know RH big enterprise > users pay the bills but I'd rather naively bought into the idea that FC > was about building community with grass roots projects. Now it appears you > have to have a substantial group of people on a payroll to get into FC > core. not true. extras is made up of other people. I am pushing for fc core to just be a single cd or two. that can only happen with anaconda getting support for other repos. meanwhile yum install abiword will install it since fc4 will have extras repo enabled by default. so its not hard to do. > > >> That said, we want to make our software as widely available as possible. > >> If someone from the FC community wants to maintain AbiWord for FC-Extras > >> we'd love to hear from them. > > > > I thought you said you were already maintaining FC rpms. What am I missing > > here? > > > > Well it appears my good friend and fellow developer Marc Maurer has > stepped up to the job of maintaining AbiWord in Extras so FCE will get > great AbiWord packages right after releases. > > What do we have to do to get back into core? > > Martin propose it in the fedora extras list. -- Regards, Rahul Sundaram From katzj at redhat.com Mon Feb 28 16:16:20 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Feb 2005 11:16:20 -0500 Subject: Xen: Installing guest VMs In-Reply-To: References: Message-ID: <1109607381.22789.69.camel@bree.local.net> On Sat, 2005-02-26 at 16:16 -0500, Robin Green wrote: >So, is the plan to modify the Xeno-kernel so that it makes virtual block >devices into fake IDE or SCSI devices, or is the plan to modify anaconda >to install on Xen without kludges, or some combination? (Let's ignore >driver domains for the minute!) Personally, I don't want them to be fake IDE or SCSI devices, but fake _disk_ devices, yes. Faking IDE or SCSI is hard (and only done poorly at present). But there's also some other stuff needed so that device probing can be sane (see some of my posts to xen-devel from a few weeks ago and Rusty's mail from over the weekend) >I am currently working on the latter approach. I chose that because This isn't the approach I really want :-) Mostly because it ends up making things drastically different from a user experience point of view. Adding partitions makes little to no sense, you're adding a _device_. And then you use it however makes sense. Which could be using the whole device, but most of our toolset assumes the existence of some partition table on the device. >An intriguing possibility is having a pre-install stage of Anaconda for >guest installs, which runs on the host as a normal program, e.g. for >things like hooking up LVM volumes to the new VM. There's likely to be a need for a "guest setup" utility that does a lot of the device set up and then starts the installer and kicks things off from there. My initial thinking is that it basically asks all the information needed for device setup and where you want to do an install from and then kicks things off with all of the information needed to get through the first stage passed in. > You could even rewrite >to run the ENTIRE install process on the host, without even booting the >guest kernel, although my suspicion is that that route would involve an >unnecessary amount of effort. Having the entire install run in the host is less desirable from a security point of view. It also means that the host has to have support for any filesystem of any guest you want to install, etc. Not to mention the difficulty it adds of doing things like an FC5 guest install on an FC4 host. Jeremy From ph18 at cornell.edu Mon Feb 28 16:17:00 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Mon, 28 Feb 2005 11:17:00 -0500 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050228140446.10950.qmail@web8505.mail.in.yahoo.com> References: <20050228140446.10950.qmail@web8505.mail.in.yahoo.com> Message-ID: On Mon, 28 Feb 2005 06:04:46 -0800 (PST), Rahul Sundaram wrote: > > I dont support removing sudo either but yum install > sudo isnt a hard thing to do. if you are going to jump > operating systems just because of this then thats > overreacting IMO > Actually, it's not hard to download the packages and install from source. (./configure ; make ; make install isn't much harder than "yum install" and it's more likely to work.) However, the whole reason I prefer Linux over Solaris is that Linux comes with a good userspace, not because the Linux kernel is all that good. (The big thing Linux has going for it is driver support.) As the things that I expect to be "just there" start to disappear, the advantages of sticking with Linux go away. From fedora-devel at camperquake.de Mon Feb 28 16:24:20 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 28 Feb 2005 17:24:20 +0100 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: References: <20050228140446.10950.qmail@web8505.mail.in.yahoo.com> Message-ID: <20050228172420.5d7234d7@nausicaa.camperquake.de> Hi. "Paul A. Houle" wrote: > source. (./configure ; make ; make install isn't much harder than "yum > install" and it's more likely to work.) And it's one of the fastest ways to turn a package managed system into an absolute mess unless you know quite well what you're doing. -- Percussive Maintenance: The fine art of whacking the c**p out of an electronic device to get it to work again. From shiva at sewingwitch.com Mon Feb 28 16:45:37 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 28 Feb 2005 08:45:37 -0800 Subject: Why is sendmail bad? In-Reply-To: <20050226202516.GB1105875@hiwaay.net> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> <20050226202516.GB1105875@hiwaay.net> Message-ID: --On Saturday, February 26, 2005 2:25 PM -0600 Chris Adams wrote: > That's fine if you are building a workstation-only system, but are you > also going to drop Apache, OpenLDAP, vsftpd, ...? I guess that depends on what Fedora is being targeted for, and how aggressive one wants to be about slimming down the distro to fit on less media. But note that I didn't say "drop", just move to Extras. Presumably Fedora *Core* could switch to a bare-bones workstation install with capability equivalent to XP Home (which lacks an MTA), and everything else moved to Extras for advanced users who want server capability. And unlike XP Pro and Windows 2003, you still get to add all that functionality for *free*. Basic users can get a working installation from a magazine CD, and the rest can download additional content for the fancy stuff. From fedora-devel at camperquake.de Mon Feb 28 16:48:32 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 28 Feb 2005 17:48:32 +0100 Subject: Why is sendmail bad? In-Reply-To: References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> <20050226202516.GB1105875@hiwaay.net> Message-ID: <20050228174832.7fcf473e@nausicaa.camperquake.de> Hi. Kenneth Porter wrote: > Fedora *Core* could switch to a bare-bones workstation install with > capability equivalent to XP Home (which lacks an MTA), Except that you cannot reasonably run a *NIX system without an MTA. -- God is my co-pilot, but the Devil is my bombardier. From sopwith at redhat.com Mon Feb 28 16:51:06 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 28 Feb 2005 11:51:06 -0500 (EST) Subject: Package pruning for FC4 and beyond In-Reply-To: <42207BEB.7020000@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: Eric, thanks for taking on this task! Just a couple of comments On Sat, 26 Feb 2005, Eric Warnke wrote: > dovecot - IPAP server - 2 objections, but if you can server to the > internet, you can download it from extras. Ether this or cyrus should > be cut. cyrus is not as widely useful, so it probably would be moved to Extras if anything. > lynx/elinks - 1 objection about scripts using lynx... ether those > scripts are not part of core or they are not marked correctly. If you > can surf the web with either, you can download them from extras. If > either has a dependancy in core the .src.rpm needs to be corrected. A while back I tried to work out the whole "text mode browser" confusion. There is also w3m in the mix. Each of them has unique attributes for particular users (blind users, CJK users, etc.) Someone such as yourself needs to find out all the details, pick the best one or two for the overall Fedora audience, and move the other(s) to Extras. Best, -- Elliot From ad+lists at uni-x.org Mon Feb 28 16:51:43 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Mon, 28 Feb 2005 17:51:43 +0100 Subject: ITE 8212 and pwc drivers absent in Rawhide In-Reply-To: <20050226050705.GA11218@kroah.com> References: <1109319950.5110.22.camel@localhost.localdomain> <20050226050705.GA11218@kroah.com> Message-ID: <1109609503.9846.43.camel@serendipity.dogma.lan> Am Sa, den 26.02.2005 schrieb Greg KH um 6:07: > The pwc driver author asked for it to be removed. It no longer has a > maintainer nor anyone who wants to support it. Until then it will > remain outside of the kernel tree (and _someone_ needs to actually > submit it for inclusion...) > greg k-h History AFAIK. Meanwhile the code is actively maintained again by http://www.saillard.org/linux/pwc/ My current FC2 kernel has that driver and it is working with my Philips cam as it should. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp Serendipity 17:49:44 up 7 days, 4:58, load average: 0.11, 0.17, 0.20 -------------- 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 shiva at sewingwitch.com Mon Feb 28 16:55:37 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 28 Feb 2005 08:55:37 -0800 Subject: Why is sendmail bad? In-Reply-To: <1109441709.5970.15.camel@rousalka.dyndns.org> References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> <1109441709.5970.15.camel@rousalka.dyndns.org> Message-ID: --On Saturday, February 26, 2005 7:15 PM +0100 Nicolas Mailhot wrote: > The nice thing about a full-featured MTA with real local queues is your > mail will still pass through when your ISP decides to do a big > advertising campaign without upgrading its network first. I don't question the value of a full-featured MTA for an advanced user. I just don't see it as being a required feature for a new user. Presumably the people installing Fedora who can't configure sendmail are either home users (who have a full-featured ISP to operate a real MTA) or business users operating behind a company MTA. AFAIK, Fedora isn't being pushed as an "MTA training platform", so there's no need to keep one in the Core product when it's tight for space. And if it's not tight for space, one could still use a very simple outbound-only queuing MTA for the default and make Postfix/Exim/Sendmail choices for advanced users. From sopwith at redhat.com Mon Feb 28 17:03:07 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 28 Feb 2005 12:03:07 -0500 (EST) Subject: Package pruning for FC4 and beyond - question In-Reply-To: <20050226202409.GA1105875@hiwaay.net> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <20050226194911.2364cf7f.fedora@wir-sind-cool.org> <4220C57D.3000603@snowmoon.com> <20050226202409.GA1105875@hiwaay.net> Message-ID: On Sat, 26 Feb 2005, Chris Adams wrote: > Once upon a time, Eric Warnke said: > > Is being part of RHEL reason enough to keep things in core? If that is > > the case I will exclude from my list all packages that exist in RHEL. > > Personally I don't think that should be the goal here. > > In the Objectives of Fedora Core: > > 13. Form the basis of Red Hat's commercially supported operating system > products. > > http://fedora.redhat.com/about/objectives.html Don't worry about whether the packages are in RHEL - we'll sort out that mess when we come to it. ;-) -- Elliot From eric at snowmoon.com Mon Feb 28 17:09:47 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 28 Feb 2005 12:09:47 -0500 Subject: Intel Pro Wireless cards Message-ID: <4223505B.20402@snowmoon.com> After reviewing the archives of the various lists I have found no discussion on the topic of wireless driver inclusion in FC. I have checked with LICENSE and FAQ for the intel driver and firmware and was wondering if it could be included in core. Without those driver it makes most centrino based laptops useless without special handling. Specifically since I know people will ask, the problem must lie in the firmware since the driver is GPL. The firmware is under a commercial licence that allows redistribution as long as a small number of conditions are met. Distributed by rpm and installed the only condition that needs to be met is that the LICENCE file needs to be installed with the firmware. http://ipw2100.sourceforge.net/firmware.php?fid=1 "*Your rights to redistribute the Software shall be contingent upon your installation of this Agreement in its entirety in the same directory as the Software.*" So, is this a non-starter, or can this be accomodated by FC? I know this would be a bog help to the laptop users out there. At least if we can get the driver support in core so that each kernel release does not break laptop support I would be most grateful. Cheers, Eric From jspaleta at gmail.com Mon Feb 28 17:10:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Feb 2005 12:10:44 -0500 Subject: Package pruning for FC4 and beyond In-Reply-To: References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> Message-ID: <604aa79105022809106bd60c13@mail.gmail.com> On Mon, 28 Feb 2005 11:51:06 -0500 (EST), Elliot Lee wrote: > A while back I tried to work out the whole "text mode browser" confusion. > There is also w3m in the mix. Each of them has unique attributes for > particular users (blind users, CJK users, etc.) Someone such as yourself > needs to find out all the details, pick the best one or two for the > overall Fedora audience, and move the other(s) to Extras. is there a reasonable good checklist of 'details' people are suppose to be looking for? Its very easy to forget about CJK users or the like if you personally never have to deal with the tech issues that raises. Last time i checked the closest thing we had was from the desktop group. http://fedora.redhat.com/projects/desktop/defaults.html Is that enough of a guide for devilish details? accessibility and internationalization are mentioned.. but they have buzzword qualities that might not sink in. Does this need to be re-formulated or at the very least re-packaged and presented somewhere more prominent? It would be nice to have a somewhat standardized set of checkbox items so as each package came up we could weight the pros and cons of competing details that need to be considered. -jef"valkyrie needs food... badly"spaleta From sopwith at redhat.com Mon Feb 28 17:23:33 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 28 Feb 2005 12:23:33 -0500 (EST) Subject: Package pruning for FC4 and beyond In-Reply-To: <604aa79105022809106bd60c13@mail.gmail.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <604aa79105022809106bd60c13@mail.gmail.com> Message-ID: On Mon, 28 Feb 2005, Jeff Spaleta wrote: > On Mon, 28 Feb 2005 11:51:06 -0500 (EST), Elliot Lee wrote: > > A while back I tried to work out the whole "text mode browser" confusion. > > There is also w3m in the mix. Each of them has unique attributes for > > particular users (blind users, CJK users, etc.) Someone such as yourself > > needs to find out all the details, pick the best one or two for the > > overall Fedora audience, and move the other(s) to Extras. > > is there a reasonable good checklist of 'details' people are suppose > to be looking for? Its very easy to forget about CJK users or the like > if you personally never have to deal with the tech issues that raises. Akira is the RH package owner of w3m, and he's well qualified to fill us in on the details because he did that last time I brought the issue up ;-) -- Elliot From dcbw at redhat.com Mon Feb 28 17:33:27 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 28 Feb 2005 12:33:27 -0500 Subject: Intel Pro Wireless cards In-Reply-To: <4223505B.20402@snowmoon.com> References: <4223505B.20402@snowmoon.com> Message-ID: <1109612007.14468.7.camel@dcbw.boston.redhat.com> On Mon, 2005-02-28 at 12:09 -0500, Eric Warnke wrote: > After reviewing the archives of the various lists I have found no > discussion on the topic of wireless driver inclusion in FC. > > I have checked with LICENSE and FAQ for the intel driver and firmware > and was wondering if it could be included in core. Without those driver > it makes most centrino based laptops useless without special handling. The actual _driver_ has been included in Core kernels for some time already. > Specifically since I know people will ask, the problem must lie in the > firmware since the driver is GPL. The firmware is under a commercial > licence that allows redistribution as long as a small number of > conditions are met. Distributed by rpm and installed the only condition > that needs to be met is that the LICENCE file needs to be installed with > the firmware. > > http://ipw2100.sourceforge.net/firmware.php?fid=1 > > "*Your rights to redistribute the Software shall be contingent upon your > installation of this Agreement in its entirety in the same directory as > the Software.*" This is a non-starter. If the package is not under a FOSS license, which this is not, then it cannot be included in Core. The Intel firmware is not under such a license. Dan From ee21rh at surrey.ac.uk Mon Feb 28 17:41:47 2005 From: ee21rh at surrey.ac.uk (Richard Hughes) Date: Mon, 28 Feb 2005 17:41:47 +0000 Subject: Intel Pro Wireless cards References: <4223505B.20402@snowmoon.com> Message-ID: On Mon, 28 Feb 2005 12:09:47 -0500, Eric Warnke wrote: > After reviewing the archives of the various lists I have found no > discussion on the topic of wireless driver inclusion in FC. Same with Atmel at76c50x wireless chips. See http://thekelleys.org.uk/atmel/ Debian : non-free [http://packages.debian.org/unstable/net/atmel-firmware], SuSE : GPL, Other License(s), packaged. [http://www.novell.com/products/linuxpackages/professional/atmel-firmware.html] Ubuntu : In main distribution. [http://higgs.djpig.de/ubuntu/www/hoary/net/atmel-firmware] Copyright File here: /******************************************************************************/ /* Copyright (c) 2004-07-05 Atmel Corporation. All Rights Reserved. */ /* */ /* Redistribution and use of the microcode software ("Firmware") is */ /* permitted provided that the following conditions are met: */ /* Firmware is redistributed in object code only, specifically, only */ /* in two file formats: (a) .h header file; or (b) .rom binary image file; */ /* */ /* Any reproduction of Firmware must contain the above copyright notice, */ /* this list of conditions and the below disclaimer in the documentation */ /* and/or other materials provided with the distribution; and */ /* The name of Atmel Corporation may not be used to endorse or promote */ /* products derived from this Firmware without specific prior written consent.*/ /******************************************************************************/ /******************************************************************************/ /* DISCLAIMER: ATMEL PROVIDES THIS FIRMWARE "AS IS" WITH NO WARRANTIES */ /* OR INDEMNITIES WHATSOEVER. ATMEL EXPRESSLY DISCLAIMS ANY EXPRESS, */ /* STATUTORY OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, */ /* THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR */ /* PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR */ /* ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL */ /* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS */ /* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) */ /* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, */ /* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING */ /* IN ANY WAY OUT OF THE USE OF THIS FIRMWARE, EVEN IF ADVISED OF THE */ /* POSSIBILITY OF SUCH DAMAGE. */ /* */ /* USER ACKNOWLEDGES AND AGREES THAT THE PURCHASE OR USE OF THE FIRMWARE */ /* WILL NOT CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, */ /* OR OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS */ /* (PATENT, COPYRIGHT, TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) */ /* EMBODIED IN ANY OTHER ATMEL HARDWARE OR FIRMWARE EITHER SOLELY */ /* OR IN COMBINATION WITH THE FIRMWARE. */ /******************************************************************************/ Is this a package for livna, core or extras? Richard. -- http://www.hughsie.com/PUBLIC-KEY From dcbw at redhat.com Mon Feb 28 17:51:25 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 28 Feb 2005 12:51:25 -0500 Subject: Intel Pro Wireless cards In-Reply-To: References: <4223505B.20402@snowmoon.com> Message-ID: <1109613085.14468.9.camel@dcbw.boston.redhat.com> On Mon, 2005-02-28 at 17:41 +0000, Richard Hughes wrote: > On Mon, 28 Feb 2005 12:09:47 -0500, Eric Warnke wrote: > > After reviewing the archives of the various lists I have found no > > discussion on the topic of wireless driver inclusion in FC. > > Same with Atmel at76c50x wireless chips. > Is this a package for livna, core or extras? Livna. Dan From jwboyer at jdub.homelinux.org Mon Feb 28 17:52:53 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 28 Feb 2005 11:52:53 -0600 Subject: Why is sendmail bad? In-Reply-To: References: <20050224195343.GA17633@yoda.jdub.homelinux.org> <1109275608.7775.239.camel@serendipity.dogma.lan> <20050224205611.GB17728@yoda.jdub.homelinux.org> <1109279833.7775.251.camel@serendipity.dogma.lan> <1109288482.17967.28.camel@jdub.homelinux.org> <79FAA82857A03335BDEE9331@[10.0.0.4]> <1109441709.5970.15.camel@rousalka.dyndns.org> Message-ID: <20050228175253.GA17448@yoda.jdub.homelinux.org> On Mon, Feb 28, 2005 at 08:55:37AM -0800, Kenneth Porter wrote: > --On Saturday, February 26, 2005 7:15 PM +0100 Nicolas Mailhot > wrote: > > Presumably the people installing Fedora who can't configure sendmail are > either home users (who have a full-featured ISP to operate a real MTA) or > business users operating behind a company MTA. AFAIK, Fedora isn't being > pushed as an "MTA training platform", so there's no need to keep one in the > Core product when it's tight for space. And if it's not tight for space, > one could still use a very simple outbound-only queuing MTA for the default > and make Postfix/Exim/Sendmail choices for advanced users. That makes some sense. But then you have the broken upgrade path issue if you drop _all_ fully featured MTAs from Core. Potentially that is. I think it's more plausible once the installer supports installing from other repos. Which is FC5 I hear. So for FC4 I think one of the current MTAs should be present. I'm not going to dare suggest which one, but one of them should remain :). Then for FC5 we can do what you suggested. josh From jspaleta at gmail.com Mon Feb 28 17:53:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Feb 2005 12:53:14 -0500 Subject: Intel Pro Wireless cards In-Reply-To: References: <4223505B.20402@snowmoon.com> Message-ID: <604aa79105022809535577c11c@mail.gmail.com> On Mon, 28 Feb 2005 17:41:47 +0000, Richard Hughes wrote: > Is this a package for livna, core or extras? If its not foss its livna. Fedora Core and Extras are chartered to be solely foss material. -jef From cmadams at hiwaay.net Mon Feb 28 18:36:08 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 28 Feb 2005 12:36:08 -0600 Subject: Package pruning for FC4 and beyond In-Reply-To: <604aa79105022809106bd60c13@mail.gmail.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <604aa79105022809106bd60c13@mail.gmail.com> Message-ID: <20050228183608.GD897460@hiwaay.net> Once upon a time, Jeff Spaleta said: > -jef"valkyrie needs food... badly"spaleta Mmm... nethack. I had a good nethack package a while back; sounds like a good excuse to clean it up and learn about maintaining a package in Extras. -- 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 28 18:39:34 2005 From: buildsys at redhat.com (Build System) Date: Mon, 28 Feb 2005 13:39:34 -0500 Subject: rawhide report: 20050228 changes Message-ID: <200502281839.j1SIdYjL016115@porkchop.devel.redhat.com> New package fonts-chinese Chinese TrueType Font -- Simplified and Traditional Chinese Ming and Kai Face. Updated Packages: byacc-1.9-29 ------------ * Sun Feb 27 2005 Florian La Roche - Copyright: -> License: cdecl-2.5-32 ------------ * Sun Feb 27 2005 Florian La Roche - Copyright: -> License cpufreq-utils-1:0.2-1.1.11 -------------------------- emacs-21.3-25 ------------- * Mon Feb 28 2005 Jens Petersen - 21.3-25 - add tramp-2.1.3 to site-lisp (David Woodhouse, 149703) - move removal of info dir to after its installation - add tramp-init.el to put tramp into load-path firefox-0:1.0.1-2 ----------------- * Sun Feb 27 2005 Christopher Aillon 0:1.0.1-2 - Add upstream fix to reduce round trips to xserver during remote control - Add upstream fix to call g_set_application_name genromfs-0.5.1-2 ---------------- * Sun Feb 27 2005 Florian La Roche - Copyright: -> License jed-0.99.16-7 ------------- * Sun Feb 27 2005 Florian La Roche - Copyright: -> License m4-1.4.2-2 ---------- * Sun Feb 27 2005 Florian La Roche - rebuild memtest86+-1.51-1 ----------------- * Sat Feb 19 2005 Warren Togami - 1.51-1 - 1.51 rpmdb-fedora-1:4-0.20050228 --------------------------- sox-12.17.6-2 ------------- * Sun Feb 27 2005 Florian La Roche - Copyright: -> License: tftp-0.40-3 ----------- * Sun Feb 27 2005 Florian La Roche - Copyright: -> License From mpeters at mac.com Mon Feb 28 18:58:54 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 28 Feb 2005 18:58:54 +0000 Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: <20050228172420.5d7234d7@nausicaa.camperquake.de> (from fedora-devel@camperquake.de on Mon Feb 28 08:24:20 2005) References: <20050228140446.10950.qmail@web8505.mail.in.yahoo.com> <20050228172420.5d7234d7@nausicaa.camperquake.de> Message-ID: <1109617134l.7066l.0l@devel.mpeters.us> On 02/28/2005 08:24:20 AM, Ralf Ertzinger wrote: > Hi. > > "Paul A. Houle" wrote: > > > source. (./configure ; make ; make install isn't much harder than > "yum > > install" and it's more likely to work.) > > And it's one of the fastest ways to turn a package managed system > into > an > absolute mess unless you know quite well what you're doing. Absolutely 100% correct. If there isn't an rpm for what I want, I make one myself for that very reason - RPM is one of the biggest strengths of Red Hat (and Fedora) - why mess up a good thing? I've been down that road before - once you start building from source, you have to keep doing it because rpm doesn't know about what is installed by source, or use --nodeps - the system just becomes difficult to maintain, especially if the box later becomes someone elses job to maintain. and no, ./configure && make && su --command="make install" is not more likely to work than "yum install packagename" That is only the case if you mix repo's not designed to work together. Even then, though, software like smart can often sort things out enough to do it. -- Michael A. Peters http://mpeters.us/ From czar at czarc.net Mon Feb 28 19:01:20 2005 From: czar at czarc.net (Gene C.) Date: Mon, 28 Feb 2005 14:01:20 -0500 Subject: FC5 anaconda Message-ID: <200502281401.20237.czar@czarc.net> There have been a number of characteristics/functionality for anaconda in FC5 mentioned on this list. Is there some place where the plan is described/discussed? I currently subscribe to the anaconda-devel-list but only started in late January so if there was discussion earlier, I missed it. -- Gene From mattdm at mattdm.org Mon Feb 28 19:05:52 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 28 Feb 2005 14:05:52 -0500 Subject: FC5 anaconda In-Reply-To: <200502281401.20237.czar@czarc.net> References: <200502281401.20237.czar@czarc.net> Message-ID: <20050228190552.GA3456@jadzia.bu.edu> On Mon, Feb 28, 2005 at 02:01:20PM -0500, Gene C. wrote: > There have been a number of characteristics/functionality for anaconda in FC5 > mentioned on this list. Is there some place where the plan is > described/discussed? Jeremy Katz gave a talk about it at FUDCon -- the slides are online at (click on the link in the schedule at the bottom). It was also recorded; not sure what the status of the video is, but it's supposed to get put up eventually. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From richardl at redhat.com Mon Feb 28 19:18:13 2005 From: richardl at redhat.com (Richard Li) Date: Mon, 28 Feb 2005 14:18:13 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <2900.10.10.10.24.1109522996.squirrel@linux1> References: <1109287914.26364.69.camel@localhost.localdomain><421F36A6.8040401@olin.edu><1109342585.26364.163.camel@localhost.localdomain><1109346741.10989.13.camel@opus.phy.duke.edu><1109346973.26364.181.camel@localhost.localdomain><1109348125.10989.22.camel@opus.phy.duke.edu><20050225162219.GD1048932@hiwaay.net><1109348730.10989.33.camel@opus.phy.duke.edu><1109349041.26364.190.camel@localhost.localdomain><1109355427.10989.39.camel@opus.phy.duke.edu><20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter><1109362522.23111.24.camel@cutter> <421F8F4D.1030600@insitesinc.com><1109365469.23111.35.camel@cutter> <1109365714.23111.38.camel@cutter><1109486344.15959.491.camel@mccallum.corsepiu.local><1109496356.27384.189.camel@cutter><1912.10.10.10.24.1109507476.squirrel@linux1> <1109522569.27384.213.camel@cutter> <2900.10.10.10.24.1109522996.squirrel@linux1> Message-ID: <42236E75.8090702@redhat.com> >The argument comes down to how much noise you're willing to endure in >order to leave the door open for valuable posts from people who are too >new to have made acknowledged contributions. A moderated list might be a >better compromise. > > Why don't we see how this new system all works out? The original approach with fedora-devel-list has been around for awhile, and there have been problems with S/N. So let's give this new system some time and see what the risk/reward is to this approach. After all, even though Fedora as an OS might have a long lineage, Fedora as a community is still really new. This makes everything both easy and hard because there's a lot of users to begin with, and everyone wants almost-the-same-thing-but-not-quite. So, figuring out how to build a community on the fly that works for everyone is a hard problem. Having some data or experience with which to support a particular point of view will help. If there are significant downsides to the new structure, or things become unworkable, I'm sure that the Fedora folks will be open to revisiting the issue. Richard PS I am not on fedora-maintainers. From czar at czarc.net Mon Feb 28 19:49:23 2005 From: czar at czarc.net (Gene C.) Date: Mon, 28 Feb 2005 14:49:23 -0500 Subject: FC5 anaconda In-Reply-To: <20050228190552.GA3456@jadzia.bu.edu> References: <200502281401.20237.czar@czarc.net> <20050228190552.GA3456@jadzia.bu.edu> Message-ID: <200502281449.23163.czar@czarc.net> On Monday 28 February 2005 14:05, Matthew Miller wrote: > On Mon, Feb 28, 2005 at 02:01:20PM -0500, Gene C. wrote: > > There have been a number of characteristics/functionality for anaconda in > > FC5 mentioned on this list. ?Is there some place where the plan is > > described/discussed? > > Jeremy Katz gave a talk about it at FUDCon -- the slides are online at > (click on the link in the schedule at > the bottom). It was also recorded; not sure what the status of the video > is, but it's supposed to get put up eventually. Thanks, that provides some info but I suspect that a lot of words were spoken which added a lot more info. I believe I understand how this will (could) all work for an Internet connected system where, basically, you do a network install for a lot of that packages (especially those in Fedora Extras). However, how about the unconnected system? What is the thinking on how it will handle installing everything from CD or DVD images? Will there be CD and/or DVD iso images for Extras or will we need to roll our own? Even for Internet connected systems, if you have a number of systems to do installs on, you do not want to have to download the packages for each system ... you (or at least I) want to download the packages once and then do installs on all of the systems. I suspect I may be a bit early with these questions and some of the stuff has not been thought through just yet ... some general goals established but not "how" to do it. -- Gene From eric at snowmoon.com Mon Feb 28 19:50:27 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 28 Feb 2005 14:50:27 -0500 Subject: Intel Pro Wireless cards In-Reply-To: <604aa79105022809535577c11c@mail.gmail.com> References: <4223505B.20402@snowmoon.com> <604aa79105022809535577c11c@mail.gmail.com> Message-ID: <42237603.6040000@snowmoon.com> Then I assume it'a an oversight that other closed source firmware ships with Fedora? The bluez-bluefw module ships with a GLP license even though the firmware that is included appears ( as in I'm email broadcom right now ) to be free as in beer not free as in speech. Without the source code it's only Free and not FOSS. If they can ship free-redistibutution firmware for the broadcom why not intel's free-redistribution license? Cheers, Eric Jeff Spaleta wrote: > On Mon, 28 Feb 2005 17:41:47 +0000, Richard Hughes wrote: > >>Is this a package for livna, core or extras? > > > If its not foss its livna. > Fedora Core and Extras are chartered to be solely foss material. > > -jef > -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From rhally at mindspring.com Mon Feb 28 19:57:10 2005 From: rhally at mindspring.com (Richard Hally) Date: Mon, 28 Feb 2005 14:57:10 -0500 Subject: rawhide report: 20050228 changes In-Reply-To: <200502281839.j1SIdYjL016115@porkchop.devel.redhat.com> References: <200502281839.j1SIdYjL016115@porkchop.devel.redhat.com> Message-ID: <42237796.8070908@mindspring.com> Build System wrote: > >rpmdb-fedora-1:4-0.20050228 >--------------------------- > > > > > What is going on with rpmdb-fedora? It shows up in the build system "rawhide report" but it is not actually in the /development download directory to be downloaded?? Richard Hally From dcbw at redhat.com Mon Feb 28 19:58:23 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 28 Feb 2005 14:58:23 -0500 Subject: Intel Pro Wireless cards In-Reply-To: <42237603.6040000@snowmoon.com> References: <4223505B.20402@snowmoon.com> <604aa79105022809535577c11c@mail.gmail.com> <42237603.6040000@snowmoon.com> Message-ID: <1109620703.571.1.camel@dcbw.boston.redhat.com> On Mon, 2005-02-28 at 14:50 -0500, Eric Warnke wrote: > Then I assume it'a an oversight that other closed source firmware ships > with Fedora? > > The bluez-bluefw module ships with a GLP license even though the > firmware that is included appears ( as in I'm email broadcom right now ) > to be free as in beer not free as in speech. Without the source code > it's only Free and not FOSS. > > If they can ship free-redistibutution firmware for the broadcom why not > intel's free-redistribution license? That would appear to be an oversight. File a bug against the package. Dan From daryll.strauss at gmail.com Mon Feb 28 20:04:25 2005 From: daryll.strauss at gmail.com (Daryll Strauss) Date: Mon, 28 Feb 2005 12:04:25 -0800 Subject: I want more CDs in the distribution Message-ID: <55668b8c050228120473a73b01@mail.gmail.com> Here's a counter idea for people to chew on. I'd like to see more CDs in the distribution, I'd just like them all to be less full. One of the problems we seem to be bumping up against is that although a personal desktop, a workstation, and a server share a lot of packages, there's also a lot of packages that are specific to one type of use or another. Server's typically don't install OpenOffice, and desktops don't install NetNews servers in most cases. What if we break the distribution in to more CD's each with fewer packages more tightly organized around usage. For a made up example: CD1 & CD2 - Base OS (practically everyone uses) CD3 - Core Server packages CD4 - Core Dekstop packages CD5 - Additional Server packages CD6 - Additional Desktop packages CD7 - Really bizarre packages (anything else we include for some reason) ADVANTAGES: If I'm installing a basic desktop or basic server I'm downloading fewer packages. The installer already seems to handle multiple discs and notifying the user which ones are needed. If you're downloading everything the total size really isn't substantially bigger (just a smidge for ISO overhead) If you install a minimal version and want to add packages later you can do that via the Internet anyway. (We should encourage people to do this if they have broadband) DISADVANTAGES: More files to download - I don't think this is an issue More CDs required for the full distribution - Media costs are small and you can put it all on one DVD if you really care. This probaby is an issue for publishers. More disk swapping to install everything - That's a real drawback, but since you have to swap disks anyway I'm not sure it's a big deal. More work categorizing end user usage and arguing over which packages are in which category. - yes :) Users need to figure out which disks to download. >From my point of view that last one is the only one that a big usability issue. The installer already tells me which disks are required early on in the process but that's not when you want to find out. It's just a failsafe. Documentation would help, but we know people often don't read it. A web script that let a user pick what packages they want to install and it tells them what discs to get would be helpful and fairly easy. In reality we want the installer to get stuff from repositories after the fact, but that's a more major change. What do you think? From dstewart at atl.lmco.com Mon Feb 28 20:09:32 2005 From: dstewart at atl.lmco.com (Doug Stewart) Date: Mon, 28 Feb 2005 15:09:32 -0500 Subject: I want more CDs in the distribution In-Reply-To: <55668b8c050228120473a73b01@mail.gmail.com> References: <55668b8c050228120473a73b01@mail.gmail.com> Message-ID: <42237A7C.1000309@atl.lmco.com> > > What do you think? > I like the sound of it. Of course, then the "What's a server package?" vs. "What's a desktop package?" flamewars would commence... *grin* -- ---------- Doug Stewart Systems Administrator/Web Applications Developer Lockheed Martin Advanced Technology Labs dstewart at atl.lmco.com From eric at snowmoon.com Mon Feb 28 20:12:08 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 28 Feb 2005 15:12:08 -0500 Subject: I want more CDs in the distribution In-Reply-To: <55668b8c050228120473a73b01@mail.gmail.com> References: <55668b8c050228120473a73b01@mail.gmail.com> Message-ID: <42237B18.3000803@snowmoon.com> Daryll Strauss wrote: > > What do you think? > I think with FC5 and Yum based anaconda, you can have a field day and tell us how it turns out. Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From adriano.galano at gmail.com Mon Feb 28 20:19:22 2005 From: adriano.galano at gmail.com (Adriano Galano) Date: Mon, 28 Feb 2005 21:19:22 +0100 Subject: I want more CDs in the distribution In-Reply-To: <42237A7C.1000309@atl.lmco.com> References: <55668b8c050228120473a73b01@mail.gmail.com> <42237A7C.1000309@atl.lmco.com> Message-ID: <754f42e7050228121916f277ba@mail.gmail.com> On Mon, 28 Feb 2005 15:09:32 -0500, Doug Stewart wrote: > > > > What do you think? > > > Why not to use DVD like the media? Maybe that could be solve the question abourt what is on the CD 1 or in the CD n ;-) Second, why not to organize the system in "meta-packages" or components, for example, "apache", "gnome", "office", "games" or "webapps core" ;-) not at he instalation level maybe at the package level. > I like the sound of it. Of course, then the "What's a server package?" > vs. "What's a desktop package?" flamewars would commence... > Third, and the real crazy idea :-), why not to stablish one rating or categorization scheme for packages with one (or several) index that show the expected audience of the package...something like the Sourceforge.net's Trove categorization but per CD or DVD creation. > *grin* > > -- > ---------- > Doug Stewart > Systems Administrator/Web Applications Developer > Lockheed Martin Advanced Technology Labs > dstewart at atl.lmco.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > Regards, -Adriano -- Adriano M. (bryam) Galano D?ez In LiNUX and FLOSS since 1992 (R) http://bryam.blogspot.com From jwz at jwz.org Mon Feb 28 20:40:28 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Mon, 28 Feb 2005 12:40:28 -0800 Subject: I want more CDs in the distribution References: <55668b8c050228120473a73b01@mail.gmail.com> <42238167.15A63A7B@dnalounge.com> Message-ID: <422381BC.607772FB@jwz.org> [ oops, sent from wrong email addr last time ] Daryll Strauss wrote: > > What if we break the distribution in to more CD's each with fewer > packages more tightly organized around usage. For a made up example: > CD1 & CD2 - Base OS (practically everyone uses) > CD3 - Core Server packages > CD4 - Core Dekstop packages > CD5 - Additional Server packages > CD6 - Additional Desktop packages > CD7 - Really bizarre packages (anything else we include for some reason) Eh, I think that means I'd always have to download at least 6 CDs, because chances are gnome, httpd, and xemacs will be on different discs, so it seems (selfishly) like no gain. What I generally do is install the absolutely minimal fedora I can, and then install the rest after the machine has booted. This is good because it gets me past the part I might actually have to fuck around with (partitioning, debugging boot loader problems) right away, and then most importantly, *gets me a network* while things are installing, so I'm not sitting there bored out of my mind while it grinds away: Anaconda doesn't let me ssh out to check my mail. Also it means I don't end up installing 80% of the packages twice (the version on the CD, and then the upgrade from yum.) I know that the installer currently does that two-stage thing where firstboot (or whatever) asks you to install additional packages after the machine is on the net with a desktop. I'd like to see stage 1 get a lot smaller, and almost everything go into stage 2. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From daryll.strauss at gmail.com Mon Feb 28 21:03:17 2005 From: daryll.strauss at gmail.com (Daryll Strauss) Date: Mon, 28 Feb 2005 13:03:17 -0800 Subject: I want more CDs in the distribution In-Reply-To: <422381BC.607772FB@jwz.org> References: <55668b8c050228120473a73b01@mail.gmail.com> <42238167.15A63A7B@dnalounge.com> <422381BC.607772FB@jwz.org> Message-ID: <55668b8c050228130344c07ee3@mail.gmail.com> I threw this out to get people thinking about alternatives and this idea seems to require minimal recoding. Real repositories and categories will help those of us with broadband, but I don't think it deals with the media install issues at all. One person suggested moving to DVDs. The doesn't work because a LOT of people don't have DVD burners yet. Heck one old codger I know doesn't have a DVD reader. I like minimizing the install and doing as much as possible after the fact, but again that same old codger doesn't have broadband, so he really needs CDs. How many disks you need to install depends on how well the groups are categorized. If you want the minimal install and do the rest over the net, then you're surely going to be downloading fewer discs. Hopefully the "minimal" install corresponds to the base OS case listed above, so it's the fewest number of discs. Even if you do download all 6+ partially full disks, who cares? It's the same amount of data as 4 packed ones. You just need to burn a bit more media or do a local network/disk install. Getting the CD boundaries right is the tricky part. No setup is going to work for everyone, and it is going to suck if you need one package from that extra disk, but there's no way to avoid that problem, and with a reasonable breakdown it seems to help many users. - |Daryll From notting at redhat.com Mon Feb 28 21:05:46 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Feb 2005 16:05:46 -0500 Subject: rawhide report: 20050228 changes In-Reply-To: <42237796.8070908@mindspring.com> References: <200502281839.j1SIdYjL016115@porkchop.devel.redhat.com> <42237796.8070908@mindspring.com> Message-ID: <20050228210546.GG10778@nostromo.devel.redhat.com> > >rpmdb-fedora-1:4-0.20050228 > > What is going on with rpmdb-fedora? It shows up in the build system > "rawhide report" but it is not actually in the /development download > directory to be downloaded?? The source RPM builds. The binary RPMs do not, because of a spec file bug. Bill From webmaster at margo.bijoux.nom.br Mon Feb 28 21:07:00 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Mon, 28 Feb 2005 18:07:00 -0300 Subject: Package pruning for FC4 and beyond In-Reply-To: References: <422007DD.1020404@snowmoon.com> Message-ID: <422387F4.1030901@margo.bijoux.nom.br> Neal Becker wrote: >I use dovecot to export mail delivered in maildir format. Don't know about >mbox - but you're not suggesting that cyrus exports standard format, are >you? cyrus runs its own database - one reason I don't use it. > > Mbox is completely supported . I use it to export my mbox files from thunderbird (windows version) to evolution (I know it's weird , but I have plans of doing this to use webmail later while I dont get a server). -- Pedro Macedo From jwz at jwz.org Mon Feb 28 21:12:32 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Mon, 28 Feb 2005 13:12:32 -0800 Subject: I want more CDs in the distribution References: <55668b8c050228120473a73b01@mail.gmail.com> <42238167.15A63A7B@dnalounge.com> <422381BC.607772FB@jwz.org> <55668b8c050228130344c07ee3@mail.gmail.com> Message-ID: <42238940.B437E7@jwz.org> Daryll Strauss wrote: > > I like minimizing the install and doing as much as possible after the > fact, but again that same old codger doesn't have broadband, so he > really needs CDs. Even if I were installing from CDs, I'd still prefer to be doing a lot more post-boot than happens now. The pseudo-ads in Anaconda are pretty, but I'd rather be looking at porn^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H checking my mail... -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From aoliva at redhat.com Mon Feb 28 21:43:29 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Feb 2005 18:43:29 -0300 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <1109536319.22789.21.camel@bree.local.net> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> <1109536319.22789.21.camel@bree.local.net> Message-ID: On Feb 27, 2005, Jeremy Katz wrote: > On Sat, 2005-02-26 at 04:22 -0300, Alexandre Oliva wrote: >> On Feb 26, 2005, seth vidal wrote: >>> I believe extras functions b/c they are are over 901 packages in >>> extras. > [snip] >> Sure having CDs of Extras available for download would address part of >> the problem: people would still be able to ask friends with big pipes >> to download and burn CDs for them. But how convenient is the >> experience of installing packages from such CDs be? Anaconda won't be >> able to install packages from such CDs; will system-config-packages? > Yes. And firstboot even asks for such CDs. And has since before Fedora > existed :) Yeah, I know. But firstboot doesn't run for kickstart installs, for one, and kickstart can't use Extras CDs, so you're stuck with doing the post-install stage by hand. Yuck. Also, see the other points about making the CDs available in a form that won't get users in dependency hell. What if I want to install a package from an Extras CD that depends on a Core package that I didn't install? Will it let me know which Core CD contains it? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dag at wieers.com Mon Feb 28 21:49:19 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 28 Feb 2005 22:49:19 +0100 (CET) Subject: I want more CDs in the distribution In-Reply-To: <42237B18.3000803@snowmoon.com> References: <55668b8c050228120473a73b01@mail.gmail.com> <42237B18.3000803@snowmoon.com> Message-ID: On Mon, 28 Feb 2005, Eric Warnke wrote: > Daryll Strauss wrote: > > > What do you think? > > I think with FC5 and Yum based anaconda, you can have a field day and tell us > how it turns out. Yet another alternative: Postpone FC4 until both Anaconda repo support and Fedora Extras are ready, and let FC3 evolve more controlled over the stretched period. Preparing FC4 will result in spending less resources in Anaconda and Fedora Extras. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From aoliva at redhat.com Mon Feb 28 21:50:16 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Feb 2005 18:50:16 -0300 Subject: Package pruning for FC4 and beyond In-Reply-To: References: <422007DD.1020404@snowmoon.com> Message-ID: On Feb 28, 2005, Neal Becker wrote: > Alexandre Oliva wrote: >> On Feb 26, 2005, Eric Warnke wrote: >> >>> dovecot - IMAP server ( duplication of effort ) >> >> What's the other IMAP/POP server in Core that can export mailboxes in >> the standard mbox format as delivered by the default MTA, and can do >> preauth when started from the command line for fetchmail over ssh? > I use dovecot to export mail delivered in maildir format. Don't know about > mbox - but you're not suggesting that cyrus exports standard format, are > you? Nope. I'm suggesting it doesn't, and therefore dovecot is not duplicate effort, it stands on its own. > cyrus runs its own database - one reason I don't use it. Yup, same here. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From eric at snowmoon.com Mon Feb 28 21:51:53 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 28 Feb 2005 16:51:53 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> <1109536319.22789.21.camel@bree.local.net> Message-ID: <42239279.90505@snowmoon.com> Alexandre Oliva wrote: > Yeah, I know. But firstboot doesn't run for kickstart installs, for > one, and kickstart can't use Extras CDs, so you're stuck with doing > the post-install stage by hand. Yuck. 1) You can configure firstboot to run after kickstarting "firstboot --enable" in your kickstart file. 2) Do what I do. Kickstart %post section that installs a rpm with updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename". This way when the computer reboots you have an up-to-date system. I use this process to add my own custom repo and I have a rpm for "desktop" systems whose dependancies are the software I want installed. Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Mon Feb 28 21:58:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 28 Feb 2005 16:58:18 -0500 Subject: FC3 -> FC4 Upgrade? (was Re: reducing distribution CD count) In-Reply-To: <42239279.90505@snowmoon.com> References: <1109287914.26364.69.camel@localhost.localdomain> <421F36A6.8040401@olin.edu> <1109342585.26364.163.camel@localhost.localdomain> <1109346741.10989.13.camel@opus.phy.duke.edu> <1109346973.26364.181.camel@localhost.localdomain> <1109348125.10989.22.camel@opus.phy.duke.edu> <20050225162219.GD1048932@hiwaay.net> <1109348730.10989.33.camel@opus.phy.duke.edu> <1109349041.26364.190.camel@localhost.localdomain> <1109355427.10989.39.camel@opus.phy.duke.edu> <20050225190829.GG1048932@hiwaay.net> <1109358912.23111.1.camel@cutter> <1109360807.26364.217.camel@localhost.localdomain> <1109361494.23111.18.camel@cutter> <1109399987.27384.33.camel@cutter> <1109536319.22789.21.camel@bree.local.net> <42239279.90505@snowmoon.com> Message-ID: <1109627898.21503.39.camel@cutter> On Mon, 2005-02-28 at 16:51 -0500, Eric Warnke wrote: > >Alexandre Oliva wrote: >> Yeah, I know. But firstboot doesn't run for kickstart installs, for >> one, and kickstart can't use Extras CDs, so you're stuck with doing >> the post-install stage by hand. Yuck. > >1) You can configure firstboot to run after kickstarting "firstboot >--enable" in your kickstart file. > >2) Do what I do. Kickstart %post section that installs a rpm with >updates fot yum repos as well as new ones. I import all the necessary >keys and do a "yum -y update" and then "yum -y install packagename". >This way when the computer reboots you have an up-to-date system. I use >this process to add my own custom repo and I have a rpm for "desktop" >systems whose dependancies are the software I want installed. yum in fc4 should allow: yum -y shell /path/to/some/file file would contain: install foo remove bar update baz groupinstall foo run it works in yum 2.3.0 now, iirc, but it's not as refined as i'd like. -sv From webmaster at margo.bijoux.nom.br Mon Feb 28 22:02:36 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Mon, 28 Feb 2005 19:02:36 -0300 Subject: I want more CDs in the distribution In-Reply-To: <754f42e7050228121916f277ba@mail.gmail.com> References: <55668b8c050228120473a73b01@mail.gmail.com> <42237A7C.1000309@atl.lmco.com> <754f42e7050228121916f277ba@mail.gmail.com> Message-ID: <422394FC.8040002@margo.bijoux.nom.br> Adriano Galano wrote: >Why not to use DVD like the media? Maybe that could be solve the >question abourt what is on the CD 1 or in the CD n ;-) > > One example to answer the question: I'm a computer science student in the biggest university in my city (the 3rd biggest capital of brazil). And guess what? Until recently (at least 1 year ago), I was the only one with a DVD burner (the Digital Image Processing Lab bought a dvd burner 4 months after me and my best friend just bought one). 3 burners in an universe of 1500+ people gives an idea on how hard would it be to burn that media .... And there's also the fact that not every computer has a dvd drive.... -- Pedro Macedo From aoliva at redhat.com Mon Feb 28 22:04:08 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Feb 2005 19:04:08 -0300 Subject: reducing distribution CD count In-Reply-To: <604aa791050227111510d45277@mail.gmail.com> References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> <1109515772.5676.29.camel@angua.localnet> <604aa791050227111510d45277@mail.gmail.com> Message-ID: On Feb 27, 2005, Jeff Spaleta wrote: > you touch on a larger issue about how a package vendor can effectively > 'expire' any package to make sure users are aware its no longer being > maintained by the original vendor. fedora-release could Obsolete: package <= V-R as of the time of the new release or something like that. It's not perfect, since if there's an update for the package after the initial release, one would have to spin a new fedora-release package to cover that. Yeah, right :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Mon Feb 28 22:12:29 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Feb 2005 19:12:29 -0300 Subject: fedora-devel-list Digest, Vol 12, Issue 86 In-Reply-To: References: <20050225095531.EA00873351@hormel.redhat.com> <1109555212.14742.2443.camel@localhost.localdomain> <20050228033618.GA32178@jadzia.bu.edu> <1109572560.14742.2502.camel@localhost.localdomain> <20050228140126.GA15793@jadzia.bu.edu> <31925.211.28.207.95.1109603717.squirrel@kiosk.ph.unimelb.edu.au> Message-ID: On Feb 28, 2005, Rahul Sundaram wrote: >> was about building community with grass roots projects. Now it appears you >> have to have a substantial group of people on a payroll to get into FC >> core. > not true. extras is made up of other people. I am pushing for fc core Since it just happened twice in a row, I thought I'd point out that fc core is a misnomer. Fedora is the name of the distro, and it now has two existing components: Core and Extras. Core is what Red Hat maintains; Extras is what the community maintains. Unfortunately, the Core installer still can't get packages from Extras installed, and most likely won't before FC5. >> What do we have to do to get back into core? > propose it in the fedora extras list. This wouldn't get it into Core. It would get it into Extras, which, by FC5's time-frame, would be nearly equivalent. For FC4, it means you won't be able to get it at install time, and a post-install step would be required to bring it in. Not a big deal if you're privileged enough to have a fat net pipe on your Fedora-running box. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mricon at gmail.com Mon Feb 28 22:19:22 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 28 Feb 2005 17:19:22 -0500 Subject: I want more CDs in the distribution In-Reply-To: <42238940.B437E7@jwz.org> References: <55668b8c050228120473a73b01@mail.gmail.com> <42238167.15A63A7B@dnalounge.com> <422381BC.607772FB@jwz.org> <55668b8c050228130344c07ee3@mail.gmail.com> <42238940.B437E7@jwz.org> Message-ID: On Mon, 28 Feb 2005 13:12:32 -0800, Jamie Zawinski wrote: > Even if I were installing from CDs, I'd still prefer to be doing a lot > more post-boot than happens now. The pseudo-ads in Anaconda are pretty, > but I'd rather be looking at porn^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H checking > my mail... Don't know if you've heard about emacs, but I believe it lets you delete whole words with Meta-Backspace. -- Konstantin ("Seth-dared-me-to-say-this-:)") Ryabitsev Zlotniks, INC From jspaleta at gmail.com Mon Feb 28 22:36:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Feb 2005 17:36:22 -0500 Subject: reducing distribution CD count In-Reply-To: References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> <1109515772.5676.29.camel@angua.localnet> <604aa791050227111510d45277@mail.gmail.com> Message-ID: <604aa79105022814364bafe9ea@mail.gmail.com> On 28 Feb 2005 19:04:08 -0300, Alexandre Oliva wrote: > fedora-release could Obsolete: package <= V-R as of the time of the > new release or something like that. It's not perfect, since if > there's an update for the package after the initial release, one would > have to spin a new fedora-release package to cover that. Yeah, right > :-) obsoleting does more than notify.. it will have an affect on the install package set. Thats not what is need at all. people need to be informed of expiration so they can make informed choices... not have removals of expired packages removed by obsoleting magic. You only make matters worse by expanding the use of obsoleting to include this sort of situation... people will just learn to disable obsoleting to avoid applications evaporating from the system. -jef From aoliva at redhat.com Mon Feb 28 22:52:51 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Feb 2005 19:52:51 -0300 Subject: I want more CDs in the distribution In-Reply-To: <422381BC.607772FB@jwz.org> References: <55668b8c050228120473a73b01@mail.gmail.com> <42238167.15A63A7B@dnalounge.com> <422381BC.607772FB@jwz.org> Message-ID: On Feb 28, 2005, Jamie Zawinski wrote: > What I generally do is install the absolutely minimal fedora I can, and > then install the rest after the machine has booted. This is good > because it gets me past the part I might actually have to fuck around > with (partitioning, debugging boot loader problems) right away, and then > most importantly, *gets me a network* while things are installing, so > I'm not sitting there bored out of my mind while it grinds away: > Anaconda doesn't let me ssh out to check my mail. Erhm... Ctrl-Alt-F2 > Also it means I don't end up installing 80% of the packages twice (the > version on the CD, and then the upgrade from yum.) This is actually a very good point. We could argue towards shipping updated CDs as well, and get the installer to use them. Like rolling releases. I suggested that before, and Seth says it might not even be too hard to get yum to peek into the ISOs to get the rpms, but it would take some eeky work. As for post-install installation, I've been thinking of rpm's new (?) feature Requires(missingok): (did it actually make to the latest rpm release?): it could be used to represent package groups, such that, instead of having package collections the way they are now, mostly static, we could instead have meta-packages that determined the standard composition of a package group, but still in such a way that you could remove some of the components afterwards without leaving your system with artificially-broken deps. > I know that the installer currently does that two-stage thing where > firstboot (or whatever) asks you to install additional packages after > the machine is on the net with a desktop. I'd like to see stage 1 get a > lot smaller, and almost everything go into stage 2. If you could do all that with kickstart as well, I'm sold. Rolling the same set of packages onto dozens of boxes isn't exactly pleasant otherwise. It sure would be a plus if the first-stage install didn't actually take longer, but rather it just passed info on to firstboot (which currently doesn't run in kickstart installs) such that it can complete the install without interaction, while the box might already be (somewhat) usable. Whether the installation of additional packages should be done in background or not, with or without a round of package updates and reboot afterwards, would be configured in kickstart. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From shiva at sewingwitch.com Mon Feb 28 23:01:56 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 28 Feb 2005 15:01:56 -0800 Subject: I want more CDs in the distribution In-Reply-To: <422394FC.8040002@margo.bijoux.nom.br> References: <55668b8c050228120473a73b01@mail.gmail.com> <42237A7C.1000309@atl.lmco.com> <754f42e7050228121916f277ba@mail.gmail.com> <422394FC.8040002@margo.bijoux.nom.br> Message-ID: <7E8BD023E1D0BED2FFF63B5C@[10.169.6.246]> --On Monday, February 28, 2005 7:02 PM -0300 Pedro Fernandes Macedo wrote: > One example to answer the question: I'm a computer science student in the > biggest university in my city (the 3rd > biggest capital of brazil). And guess what? Until recently (at least 1 > year ago), I was the only one with a DVD burner (the Digital Image > Processing > Lab bought a dvd burner 4 months after me and my best friend just bought > one). 3 burners in an universe of 1500+ people gives an idea on > how hard would it be to burn that media .... The prices dropped fast recently, at least in the US. I bought an external USB2 burner maybe two years ago, for $400, and now an internal drive can be had for about $70, and a USB2 enclosure for maybe another $50. Has Brazil seen any of that drop? From eric at snowmoon.com Mon Feb 28 23:06:51 2005 From: eric at snowmoon.com (Eric Warnke) Date: Mon, 28 Feb 2005 18:06:51 -0500 Subject: reducing distribution CD count In-Reply-To: <604aa79105022814364bafe9ea@mail.gmail.com> References: <200502240906.20729.czar@czarc.net> <20050224175035.22391185@python2> <1109515772.5676.29.camel@angua.localnet> <604aa791050227111510d45277@mail.gmail.com> <604aa79105022814364bafe9ea@mail.gmail.com> Message-ID: <4223A40B.3010301@snowmoon.com> Jeff Spaleta wrote: > obsoleting does more than notify.. it will have an affect on the > install package set. Thats not what is need at all. people need to be > informed of expiration so they can make informed choices... not have > removals of expired packages removed by obsoleting magic. You only > make matters worse by expanding the use of obsoleting to include this > sort of situation... people will just learn to disable obsoleting to > avoid applications evaporating from the system. What about adding metadata to the repos that describe packages that have been abandond. Then you could do a yum list abandond ( or the like ) to see what packages have become old/stale/abandond. Though I just wonder how that would work if say core abandond a package, but freshrpms picked it up. Hmmm..... Something to think about. Cheers, -- Eric Warnke Computer Programmer / Systems Analyst eric at snowmoon.com 518-727-1523 GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259 'There is always an easy solution to every human problem -- neat, plausible, and wrong.' - H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From ghenriks at rogers.com Mon Feb 28 23:48:57 2005 From: ghenriks at rogers.com (Gerald Henriksen) Date: Mon, 28 Feb 2005 18:48:57 -0500 Subject: I want more CDs in the distribution In-Reply-To: References: <55668b8c050228120473a73b01@mail.gmail.com> <42237B18.3000803@snowmoon.com> Message-ID: On Mon, 28 Feb 2005 22:49:19 +0100 (CET), you wrote: >Yet another alternative: > >Postpone FC4 until both Anaconda repo support and Fedora Extras are ready, >and let FC3 evolve more controlled over the stretched period. Preparing >FC4 will result in spending less resources in Anaconda and Fedora Extras. I am beginning to think this is the best idea. Delay Fedora Core 4 for 6 months. This hopefully gives time to get Anaconda and all the other relevant bits set up to allow for a distribution that is made up of 2 parts (Core and Extras). Prehaps even rename them to better reflect that they are of equal value. It also gives more time to allow the things people are aiming to try and include (gcc 4, java, openoffice.org 2) to get ready as well as get people and mirrors used to Extras. Spend some of the time trying to get those sofware projects that do package their stuff for Fedora to put their packages into Extras, thus helping to give legitimacy to Extras in the eyes of those who currently feel that stuff in Extras are second class citizens. So in the fall release Fedora 4 with everything working so that there are no negative feelings/reviews/stories about broken upgrades because Extras isn't supported yet. From rahulsundaram at yahoo.co.in Mon Feb 28 14:04:46 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Mon, 28 Feb 2005 06:04:46 -0800 (PST) Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: Message-ID: <20050228140446.10950.qmail@web8505.mail.in.yahoo.com> Hi > > > > We use sudo extensively on every unix system we > have. If you've got more > than one person doing sysadmining on a machine, > it's essential. > > If I wanted to spend time tracking down and > installing all the basic > things I need to make a system where I can be > productive, I'd install > Solaris, not Linux. I dont support removing sudo either but yum install sudo isnt a hard thing to do. if you are going to jump operating systems just because of this then thats overreacting IMO ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From rahulsundaram at yahoo.co.in Mon Feb 28 16:24:26 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Mon, 28 Feb 2005 08:24:26 -0800 (PST) Subject: Package pruning for FC4 and beyond - COMPLETE LIST In-Reply-To: Message-ID: <20050228162426.28497.qmail@web8502.mail.in.yahoo.com> Hi > > > > Actually, it's not hard to download the packages > and install from > source. (./configure ; make ; make install isn't > much harder than "yum > install" and it's more likely to work.) you are completely wrong about that. yum has auto depedency resolver and several other advantages over installing from source. with pup in fc4 it would be even more friendlier > > However, the whole reason I prefer Linux over > Solaris is that Linux > comes with a good userspace, not because the Linux > kernel is all that > good. (The big thing Linux has going for it is > driver support.) As the > things that I expect to be "just there" start to > disappear, the > advantages of sticking with Linux go away. > let me get this straight. if its called fedora core and is in ISO images, its there and if its in fedora extras as rpm packages, it goes away? ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From cs at zip.com.au Mon Feb 28 22:29:07 2005 From: cs at zip.com.au (Cameron Simpson) Date: Tue, 1 Mar 2005 09:29:07 +1100 Subject: Package pruning for FC4 and beyond - DRAFT FINAL In-Reply-To: <42215618.9000905@snowmoon.com> References: <422007DD.1020404@snowmoon.com> <42207BEB.7020000@snowmoon.com> <422086A8.7020200@snowmoon.com> <604aa79105022607043d109bf1@mail.gmail.com> <422092F8.4050003@snowmoon.com> <4220B0C2.2060007@snowmoon.com> <42215618.9000905@snowmoon.com> Message-ID: <20050228222907.GA21427@cskk.homeip.net> On 00:09 27 Feb 2005, Eric Warnke wrote: | w3m/w3m-el - another text pager/web browser Part of the standard recipe for rendering HTML in mutt (and probably other text mode mail readers). Given that you advocate punting lynx too, how do you suggest text mode users render HTML for humans? | nss_db - partly broken. Most usefulness gone now that nscd is standard ( It would be good for nscd to have a useful manual page. Its OPTIONS section says: --help will give you a list with all options and what they do. | a2ps - text to postscript tool required by xfprint ( xfprint already in | extras ) no brainer Got another text->ps in core please? Some tools are used on their own! -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ DON'T DRINK SOAP! DILUTE DILUTE! OK! - on the label of Dr. Bronner's Castile Soap From terraformers at gmx.net Fri Feb 25 13:12:04 2005 From: terraformers at gmx.net (Lars) Date: Fri, 25 Feb 2005 14:12:04 +0100 Subject: rawhide report: 20050224 changes References: <200502241852.j1OIqU0T017593@porkchop.devel.redhat.com> Message-ID: > Removed package kdetoys why is the kdetoys package removed? i enjoy the kweatherservice/applet all the time, its *really* nice. please, bring it back to core, or import it to extras. thanks lars From arjan at infradead.org Tue Feb 22 22:17:57 2005 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 22 Feb 2005 23:17:57 +0100 Subject: Exim as default MTA. In-Reply-To: <20050222220021.GB23838@devserv.devel.redhat.com> References: <421A4A7C.3000002@bluga.net> <1109020788.24391.3.camel@one.myworld> <20050221221314.GF11759@devserv.devel.redhat.com> <20050222141541.GA4987@dudweiler.stuttgart.redhat.com> <1109109046.30247.5.camel@localhost.localdomain> <20050222220021.GB23838@devserv.devel.redhat.com> Message-ID: <1109110678.6024.113.camel@laptopd505.fenrus.org> On Tue, 2005-02-22 at 17:00 -0500, Alan Cox wrote: > On Tue, Feb 22, 2005 at 09:50:46PM +0000, David Woodhouse wrote: > > Exim would be a far better default, because it's far easier to configure > > and far better documented. In FC4 it ships with TLS enabled by default, > > and SMTP AUTH support present but commented out in the specfile. It also > > I must disagree. If the user has to know what the mail system is you've > already failed the main usability test for "the general user". If they know > what they are doing then they probably have an opinion already and a preferred > app, and can also work yum/up2date. there also is the angle of security history. Ok no mail system is perfect there. I still rather install ssmtp or similar on all boxes by default unless the admin explicitly asked for a mail *server* not just a mail sender ... Esp since a simple mail sender ought to be easy to configure "Enter the email server as your ISP told you to use below" and vroom smarthost done... from a security pov that ought to be a lot nicer.