From jpo at lsd.di.uminho.pt Thu Jun 1 18:51:09 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 01 Jun 2006 19:51:09 +0100 Subject: FYI: the texinfo package has been splitted in two In-Reply-To: <447B21C1.3090707@lsd.di.uminho.pt> References: <447B21C1.3090707@lsd.di.uminho.pt> Message-ID: <447F371D.4070909@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The FC-4 and FC-5 texinfo packages have been updated today: the texinfo package also started providing texinfo-tex. - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEfzcdl0metZG9hRsRAmUEAJ9AnlIfKZFTcIi839APC4vKKGQ/gACfZXK/ oyLPiF8Gz5OGplyVI233HgQ= =1E6g -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From michael at knox.net.nz Fri Jun 2 18:46:27 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 03 Jun 2006 06:46:27 +1200 Subject: FYI lua split Message-ID: <44808783.6080609@knox.net.nz> Hey all, In the next day or so, I will be rebuilding lua to produce a devel package. Just a heads up if you maintain a package that builds against lua, you're going to need a rebuild. So keep an eye on the cvs commits. Thanks! Michael From skvidal at linux.duke.edu Sun Jun 4 20:32:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 04 Jun 2006 16:32:26 -0400 Subject: extras buildsys/plague downtime Message-ID: <1149453146.21779.12.camel@cutter> Hi folks, We've got to swap out a disk in the buildmaster (buildsys.fedoraproject.org) in order to increase available space. Therefore, we'll be taking plague down while they're swapped. This will happen Monday June 5th at 13:00 GMT-4. Ideally it will only take 20 minutes to do everything but give me until at least 14:00 before sending out the hatemail. :) thanks, -sv From jspaleta at gmail.com Mon Jun 5 01:33:03 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 4 Jun 2006 21:33:03 -0400 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <4471E231.1070409@thecodergeek.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <4471E231.1070409@thecodergeek.com> Message-ID: <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> On 5/22/06, Peter Gordon wrote: > Jeff Spaleta wrote: > > glabels in fedora extras is currently tracking the stable glabels > > branch, and its pretty straight forward. Just get on the low traffic > > upstream glabels mailinglist and watch for any "stable" release > > announcements or upstream bugs. > > I've been using gLabels a lot as of recent. If no one has any > outstanding complaints thereof, I'd be happy to take it off your hands > for a while. Okay, sorry I've been really busy in the best 2 weeks.... Sooooo if you want to take co-ownership all i think you need to do is update the owners list file in cvs to add your email next to glabels. -jef From skvidal at linux.duke.edu Mon Jun 5 18:30:33 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 05 Jun 2006 14:30:33 -0400 Subject: extras buildsys/plague downtime In-Reply-To: <1149453146.21779.12.camel@cutter> References: <1149453146.21779.12.camel@cutter> Message-ID: <1149532234.18582.0.camel@cutter> On Sun, 2006-06-04 at 16:32 -0400, seth vidal wrote: > Hi folks, > We've got to swap out a disk in the buildmaster > (buildsys.fedoraproject.org) in order to increase available space. > Therefore, we'll be taking plague down while they're swapped. > > This will happen Monday June 5th at 13:00 GMT-4. > > Ideally it will only take 20 minutes to do everything but give me until > at least 14:00 before sending out the hatemail. :) > And we're all back up. Let me know if anything seems hosed. -sv From jkeating at redhat.com Mon Jun 5 21:23:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 05 Jun 2006 17:23:07 -0400 Subject: Broken Build Requires Message-ID: <1149542587.3171.31.camel@dhcp83-49.boston.redhat.com> As some of you know, we switched to a new build system at Red Hat, that makes use of Mock. Before Test1 of FC6 (before the freeze), I'd like to rebuild all compilable packages using this new build system. However, I can't do this until the broken BuildRequires are fixed. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=191529&hide_resolved=1 That lists the current unresolved issues. There is still 135 packages that need to be addressed before they'll build in the new build system. PLEASE do take a look if your package is one of those a bug has been filed against. Devel freeze is next Wed. That's not a lot of time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Mon Jun 5 21:35:02 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 5 Jun 2006 16:35:02 -0500 Subject: Broken Build Requires In-Reply-To: <1149542587.3171.31.camel@dhcp83-49.boston.redhat.com> References: <1149542587.3171.31.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060605213502.GB25454@lists.us.dell.com> On Mon, Jun 05, 2006 at 05:23:07PM -0400, Jesse Keating wrote: > PLEASE do take a look if your package is one of those a bug has been > filed against. Devel freeze is next Wed. That's not a lot of time. Extras has an owners.list file that I've been thinking of using to bcc: the maintainers of the files that don't compile. If there's something like that for Core (there must be, as bugzilla knows...), we could do the same. Just to make sure people see/know their package list for cleanups like this. Just a thought. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From michael at knox.net.nz Mon Jun 5 21:37:25 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 06 Jun 2006 09:37:25 +1200 Subject: Broken Build Requires In-Reply-To: <20060605213502.GB25454@lists.us.dell.com> References: <1149542587.3171.31.camel@dhcp83-49.boston.redhat.com> <20060605213502.GB25454@lists.us.dell.com> Message-ID: <4484A415.5020003@knox.net.nz> Matt Domsch wrote: > On Mon, Jun 05, 2006 at 05:23:07PM -0400, Jesse Keating wrote: > >>PLEASE do take a look if your package is one of those a bug has been >>filed against. Devel freeze is next Wed. That's not a lot of time. > > > Extras has an owners.list file that I've been thinking of using to > bcc: the maintainers of the files that don't compile. If there's > something like that for Core (there must be, as bugzilla knows...), we > could do the same. Just to make sure people see/know their package > list for cleanups like this. > > Just a thought. And its a good one. I have nearly finished filing the remaining bugs for i386 Core, not even begun to look at extras (tho I did notive two of my packages have failed). If there is a way to bcc the owner of a package, I think that would speed the process up greatly. Michael From jkeating at redhat.com Mon Jun 5 21:43:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 05 Jun 2006 17:43:33 -0400 Subject: Broken Build Requires In-Reply-To: <20060605213502.GB25454@lists.us.dell.com> References: <1149542587.3171.31.camel@dhcp83-49.boston.redhat.com> <20060605213502.GB25454@lists.us.dell.com> Message-ID: <1149543813.3171.33.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-06-05 at 16:35 -0500, Matt Domsch wrote: > Extras has an owners.list file that I've been thinking of using to > bcc: the maintainers of the files that don't compile. If there's > something like that for Core (there must be, as bugzilla knows...), we > could do the same. Just to make sure people see/know their package > list for cleanups like this. There is already a bug open. Next Monday I'll just do a 'Ping, you need to fix this' comment to every open bug. The 'Change Several Bugs at Once' tool is nice for things like this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Tue Jun 6 02:37:44 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 06 Jun 2006 14:37:44 +1200 Subject: FYI lua split In-Reply-To: <44808783.6080609@knox.net.nz> References: <44808783.6080609@knox.net.nz> Message-ID: <4484EA78.8080904@knox.net.nz> Michael J Knox wrote: > Hey all, > > In the next day or so, I will be rebuilding lua to produce a devel > package. Just a heads up if you maintain a package that builds against > lua, you're going to need a rebuild. So keep an eye on the cvs commits. This has been built now and should released into the wild in the next push Michael From ville.skytta at iki.fi Tue Jun 6 06:24:24 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 06 Jun 2006 09:24:24 +0300 Subject: Broken Build Requires In-Reply-To: <20060605213502.GB25454@lists.us.dell.com> References: <1149542587.3171.31.camel@dhcp83-49.boston.redhat.com> <20060605213502.GB25454@lists.us.dell.com> Message-ID: <1149575064.2810.5.camel@localhost.localdomain> On Mon, 2006-06-05 at 16:35 -0500, Matt Domsch wrote: > Extras has an owners.list file that I've been thinking of using to > bcc: the maintainers of the files that don't compile. Could you additionally add the maintainer's email address to the actual reports next to the package name? The list is pretty long now and for people who maintain lots of packages, searching it by package names isn't too much fun. From peter at thecodergeek.com Tue Jun 6 16:49:19 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 06 Jun 2006 09:49:19 -0700 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <4471E231.1070409@thecodergeek.com> <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> Message-ID: <4485B20F.3020103@thecodergeek.com> Jeff Spaleta wrote: > On 5/22/06, Peter Gordon wrote: >> I've been using gLabels a lot as of recent. If no one has any >> outstanding complaints thereof, I'd be happy to take it off your hands >> for a while. > > Okay, sorry I've been really busy in the best 2 weeks.... Sooooo if > you want to take co-ownership all i think you need to do is update the > owners list file in cvs to add your email next to glabels. Done. Good luck with the move, Jeff! :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From packages at amiga-hardware.com Fri Jun 9 22:05:56 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Fri, 09 Jun 2006 23:05:56 +0100 Subject: x86_64 devel building Message-ID: <4489F0C4.6080805@amiga-hardware.com> Hi, There appears to be a problem with x86_64 build system for the devel branch. A lot of builds are failing with: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-x86_64-core-f01c4d3fe2e112337ebecef75d32a28643ef6760/root groupinstall build file:///pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: '/pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml' Trying other mirror. Cannot open/read repomd.xml file for repository: core failure: repodata/repomd.xml from core: [Errno 256] No more mirrors to try. Cleaning up... Done. -- Ian Chapman. From bressers at redhat.com Mon Jun 12 18:17:14 2006 From: bressers at redhat.com (Josh Bressers) Date: Mon, 12 Jun 2006 14:17:14 -0400 Subject: FWD: Re: New Mozilla vulnerabilities?? Message-ID: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> The Firefox maintainer, Chris Aillon asked me to forward this along to this list. He's swamped right now trying to get the fixes for the various Mozilla security issues backported. He's looking for anyone willing to help roll new Firefox packages for FC5 and rawhide. Thanks. -- JB ------- Forwarded Message Date: Mon, 12 Jun 2006 13:07:43 -0400 From: Christopher Aillon To: Matthew Miller cc: Josh Bressers , fedora-security-list at redhat.com Subject: Re: [Fwd: Re: New Mozilla vulnerabilities??] Matthew Miller wrote: > On Mon, Jun 12, 2006 at 06:43:22AM -0400, Josh Bressers wrote: > >> The plan is to move everything to seamonkey, but there is much testing that >> needs to be done. We're not ready yet, which is why we are backporting the >> critical patches first. >> > > But in the meantime, what about firefox in FC5, which is already 1.5.0.x? > Does the (presumably) easier fix for the current release have to wait on the > harder work for the older releases? As far as I can tell, there wasn't even > a bug entry for this, and I had to file it myself. (And it's gotten no > response at all.) > > > > C'mon, it may not be a remote root compromise, but it is highly visible and > _could_ allow remote code execution. Fedora can do better than this! > > If someone wants to simply rev the spec, commit, and build, that's fine (and very welcome) as long as the Release is set to 2 for rawhide, and 1.1.fc5 for fc5 (to keep up with my numbering scheme). I find its best to not jump out of doing something you'd rather not jump back into, which is why I'm focusing on the backport. ------- End of Forwarded Message From dennis at ausil.us Mon Jun 12 18:54:12 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 12 Jun 2006 13:54:12 -0500 (CDT) Subject: FWD: Re: New Mozilla vulnerabilities?? In-Reply-To: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> References: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> Message-ID: <44297.68.254.239.133.1150138452.squirrel@webmail.ausil.us> > > The Firefox maintainer, Chris Aillon asked me to forward this along to > this > list. He's swamped right now trying to get the fixes for the various > Mozilla security issues backported. He's looking for anyone willing to > help roll new Firefox packages for FC5 and rawhide. > > Thanks. > Work is underway I have test builds compiling now Dennis From kengert at redhat.com Mon Jun 12 19:42:36 2006 From: kengert at redhat.com (Kai Engert) Date: Mon, 12 Jun 2006 21:42:36 +0200 Subject: FWD: Re: New Mozilla vulnerabilities?? In-Reply-To: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> References: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> Message-ID: <448DC3AC.9030906@redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3248 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Mon Jun 12 21:48:12 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 17:48:12 -0400 Subject: some minor Core pruning Message-ID: <20060612214812.GA16446@nostromo.devel.redhat.com> Running some dependency analysis on Core yielded a few packages in the following groups. This isn't exhaustive, by any means; there are still quite a few leaf nodes that are potential Extras candidates. Library packages required only by Extras packages (could be moved to extras): libgconf-java libxml (and only required by the rather old Gtk-Perl) Library + binary packages required only by Extras packages (could be moved to extras): mikmod tog-pegasus inn Library packages required by *nothing* (could be killed): libpng10 liboldX libvolume_id Library + binary packages required by nothing (could be killed, or moved): linux-atm lksctp-tools mysqlclient10 mysqlclient14 netatalk openhpi tn5250 xdelta Opinions? Bill From tgl at redhat.com Mon Jun 12 22:07:14 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 12 Jun 2006 18:07:14 -0400 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <13087.1150150034@sss.pgh.pa.us> Bill Nottingham writes: > Library + binary packages required by nothing (could be killed, or moved): > mysqlclient10 > mysqlclient14 Those are compatibility packages to provide ABI compatibility for programs built against old versions of libmysqlclient.so. They were always intended to have a limited lifespan --- I don't see a reason to carry them forward into FC6, unless we want to offer them in RHEL5. Do we promise ABI compatibility across RHEL releases? regards, tom lane From michael at knox.net.nz Mon Jun 12 22:10:15 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 10:10:15 +1200 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <448DE647.5050006@knox.net.nz> Bill Nottingham wrote: > Running some dependency analysis on Core yielded a few packages > in the following groups. This isn't exhaustive, by any means; there > are still quite a few leaf nodes that are potential Extras candidates. > > Library packages required only by Extras packages (could be moved to > extras): > libgconf-java > libxml (and only required by the rather old Gtk-Perl) > > > Library + binary packages required only by Extras packages (could be > moved to extras): > mikmod > tog-pegasus > inn > > Library packages required by *nothing* (could be killed): > libpng10 > liboldX > libvolume_id > > Library + binary packages required by nothing (could be killed, or moved): > linux-atm > lksctp-tools > mysqlclient10 > mysqlclient14 > netatalk > openhpi > tn5250 > xdelta > > Opinions? > Put them up for adoption on fedora-extras and drop the packages that can be dropped... Slimming down FC is always a good thing ;-) Michael From Matt_Domsch at dell.com Mon Jun 12 22:18:16 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 12 Jun 2006 17:18:16 -0500 Subject: some minor Core pruning In-Reply-To: <13087.1150150034@sss.pgh.pa.us> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <13087.1150150034@sss.pgh.pa.us> Message-ID: <20060612221816.GA1437@lists.us.dell.com> On Mon, Jun 12, 2006 at 06:07:14PM -0400, Tom Lane wrote: > Bill Nottingham writes: > > Library + binary packages required by nothing (could be killed, or moved): > > mysqlclient10 > > mysqlclient14 > > Those are compatibility packages to provide ABI compatibility for > programs built against old versions of libmysqlclient.so. They were > always intended to have a limited lifespan --- I don't see a reason to > carry them forward into FC6, unless we want to offer them in RHEL5. > Do we promise ABI compatibility across RHEL releases? Note: I don't speak for Red Hat's marketing department. So here's my take: RHEL promises N-2 ABI compatibility. That is, apps built on RHEL3 will continue to be supported, unmodified, on RHEL5. Fedora need not make the same promises, but obviously the longer the distro is backwards-compatible, the longer a given build of an application (think from some ISV) will continue to work without significant additional time investment by the ISV. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From karsten at redhat.de Mon Jun 12 21:18:16 2006 From: karsten at redhat.de (Karsten Hopp) Date: Mon, 12 Jun 2006 23:18:16 +0200 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <20060612211816.GA28504@redhat.de> On Mon, Jun 12, 2006 at 05:48:12PM -0400, Bill Nottingham wrote: > lksctp-tools Requested by two huge partners for RHEL, dunno if anyone else uses it. > tn5250 I've never used it and actually have no idea what it is used for. I just check if there are any upstream updates and fix bugs when someone reports them (none so far). We've already moved more important packages to Extras such as x3270 which is absolutely required if you need to install a mainframe. -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From misa at redhat.com Mon Jun 12 22:31:01 2006 From: misa at redhat.com (Mihai Ibanescu) Date: Mon, 12 Jun 2006 18:31:01 -0400 Subject: Updating python to 2.4.3 in FC4? Message-ID: <20060612223101.GB3908@abulafia.devel.redhat.com> Hello, Since there are several python bugs that have to be fixed both in FC5 and FC4, is anybody strongly opposing pushing python 2.4.3 to FC4? (it still has 2.4.1 and a few things have been fixed between .1 and .3 [1]) It'd still go into Testing first, of course. [1] http://www.python.org/download/releases/2.4.3/NEWS.txt Cheers, Misa From sgrubb at redhat.com Mon Jun 12 22:31:28 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 12 Jun 2006 18:31:28 -0400 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <200606121831.28989.sgrubb@redhat.com> On Monday 12 June 2006 17:48, Bill Nottingham wrote: > This isn't exhaustive, by any means; there are still quite a few leaf nodes > that are potential Extras candidates. I was wondering why we have autoconf213, automake14, and automake15 still in the repo? I was able to eliminate them from my build tree 2 years ago. Also, is there any reason to keep byacc? I was able to substitute bison for everything that wanted byacc and eliminated it from my buildtree too. Just curious... -Steve From denis at poolshark.org Mon Jun 12 23:45:34 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 13 Jun 2006 01:45:34 +0200 Subject: some minor Core pruning In-Reply-To: <13087.1150150034@sss.pgh.pa.us> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <13087.1150150034@sss.pgh.pa.us> Message-ID: <448DFC9E.8070009@poolshark.org> Tom Lane wrote: > Bill Nottingham writes: > >>Library + binary packages required by nothing (could be killed, or moved): >>mysqlclient10 >>mysqlclient14 > > > Those are compatibility packages to provide ABI compatibility for > programs built against old versions of libmysqlclient.so. They were > always intended to have a limited lifespan --- I don't see a reason to > carry them forward into FC6, unless we want to offer them in RHEL5. > Do we promise ABI compatibility across RHEL releases? mysqlclient10 mysqlclient14 If they're put up for adoption in Extras, I will probably pick them up (at least mysqlclient10) as I'll need them to package Glom and its compat-libgda. -denis From notting at redhat.com Tue Jun 13 01:04:19 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 21:04:19 -0400 Subject: some minor Core pruning In-Reply-To: <200606121831.28989.sgrubb@redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> Message-ID: <20060613010419.GA20190@nostromo.devel.redhat.com> Steve Grubb (sgrubb at redhat.com) said: > On Monday 12 June 2006 17:48, Bill Nottingham wrote: > > This isn't exhaustive, by any means; there are still quite a few leaf nodes > > that are potential Extras candidates. > > I was wondering why we have autoconf213, automake14, and automake15 still in > the repo? I was able to eliminate them from my build tree 2 years ago. Also, > is there any reason to keep byacc? I was able to substitute bison for > everything that wanted byacc and eliminated it from my buildtree too. # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source mozilla-37:1.7.13-1.1.fc5.src gtk+-1:1.2.10-50.src star-0:1.5a74-2.src tetex-0:3.0-24.src pam_smb-0:1.1.7-7.2.src emacs-0:21.4-14.1.src libIDL-0:0.8.6-5.src metacity-0:2.15.5-5.src gnome-mag-0:0.12.5-1.src gtk+-1:1.2.10-50.src gdm-1:2.15.3-7.src gnome-session-0:2.15.1-4.src librsvg2-0:2.15.0-1.src libwmf-0:0.2.8.4-8.src nss_db-0:2.2-35.src Bill From jwboyer at jdub.homelinux.org Tue Jun 13 00:16:13 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 12 Jun 2006 19:16:13 -0500 Subject: some minor Core pruning In-Reply-To: <13087.1150150034@sss.pgh.pa.us> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <13087.1150150034@sss.pgh.pa.us> Message-ID: <1150157773.5618.1.camel@vader.jdub.homelinux.org> On Mon, 2006-06-12 at 18:07 -0400, Tom Lane wrote: > Bill Nottingham writes: > > Library + binary packages required by nothing (could be killed, or moved): > > mysqlclient10 > > mysqlclient14 > > Those are compatibility packages to provide ABI compatibility for > programs built against old versions of libmysqlclient.so. They were > always intended to have a limited lifespan --- I don't see a reason to > carry them forward into FC6, unless we want to offer them in RHEL5. > Do we promise ABI compatibility across RHEL releases? Why do RHEL ABI practices have an impact whether or not a package stays in Fedora Core or gets moved to Fedora Extras? josh From notting at redhat.com Tue Jun 13 01:19:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 21:19:31 -0400 Subject: some minor Core pruning In-Reply-To: <13087.1150150034@sss.pgh.pa.us> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <13087.1150150034@sss.pgh.pa.us> Message-ID: <20060613011931.GA2576@nostromo.devel.redhat.com> Tom Lane (tgl at redhat.com) said: > Bill Nottingham writes: > > Library + binary packages required by nothing (could be killed, or moved): > > mysqlclient10 > > mysqlclient14 > > Those are compatibility packages to provide ABI compatibility for > programs built against old versions of libmysqlclient.so. They were > always intended to have a limited lifespan --- I don't see a reason to > carry them forward into FC6, unless we want to offer them in RHEL5. > Do we promise ABI compatibility across RHEL releases? Yes, but RHEL != Fedora. There's no reason they *couldn't* be in Extras. I thought (wrongly?) that mysqlclient10 was still around because of the MySQL LGPL -> GPL license change. Bill From michael at knox.net.nz Tue Jun 13 01:23:34 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 13:23:34 +1200 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <448E1396.9080105@knox.net.nz> Bill Nottingham wrote: > Steve Grubb (sgrubb at redhat.com) said: > >>On Monday 12 June 2006 17:48, Bill Nottingham wrote: >> >>>This isn't exhaustive, by any means; there are still quite a few leaf nodes >>>that are potential Extras candidates. >> >>I was wondering why we have autoconf213, automake14, and automake15 still in >>the repo? I was able to eliminate them from my build tree 2 years ago. Also, >>is there any reason to keep byacc? I was able to substitute bison for >>everything that wanted byacc and eliminated it from my buildtree too. > > > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source > mozilla-37:1.7.13-1.1.fc5.src > gtk+-1:1.2.10-50.src > star-0:1.5a74-2.src > tetex-0:3.0-24.src > pam_smb-0:1.1.7-7.2.src > emacs-0:21.4-14.1.src > libIDL-0:0.8.6-5.src > metacity-0:2.15.5-5.src > gnome-mag-0:0.12.5-1.src > gtk+-1:1.2.10-50.src > gdm-1:2.15.3-7.src > gnome-session-0:2.15.1-4.src > librsvg2-0:2.15.0-1.src > libwmf-0:0.2.8.4-8.src > nss_db-0:2.2-35.src > Would it be much work to move these way from those requirements? Michael From notting at redhat.com Tue Jun 13 01:32:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 21:32:20 -0400 Subject: some minor Core pruning In-Reply-To: <448E1396.9080105@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E1396.9080105@knox.net.nz> Message-ID: <20060613013220.GB2576@nostromo.devel.redhat.com> Michael J. Knox (michael at knox.net.nz) said: > Would it be much work to move these way from those requirements? Not sure. Probably worth some investigation. Bill From michael at knox.net.nz Tue Jun 13 01:38:12 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 13:38:12 +1200 Subject: some minor Core pruning In-Reply-To: <20060613013220.GB2576@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E1396.9080105@knox.net.nz> <20060613013220.GB2576@nostromo.devel.redhat.com> Message-ID: <448E1704.6010608@knox.net.nz> Bill Nottingham wrote: > Michael J. Knox (michael at knox.net.nz) said: > >>Would it be much work to move these way from those requirements? > > > Not sure. Probably worth some investigation. > I have a rawhide tree here, I will see what I can break. Michael From tgl at redhat.com Tue Jun 13 01:57:27 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 12 Jun 2006 21:57:27 -0400 Subject: some minor Core pruning In-Reply-To: <20060613011931.GA2576@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <13087.1150150034@sss.pgh.pa.us> <20060613011931.GA2576@nostromo.devel.redhat.com> Message-ID: <14865.1150163847@sss.pgh.pa.us> Bill Nottingham writes: > I thought (wrongly?) that mysqlclient10 was still around because of > the MySQL LGPL -> GPL license change. Hm, that's a good point I had forgotten about. Red Hat Legal eventually determined that we (RH) had no cases where we couldn't link apps to the newer mysql libraries, in view of the GPL exceptions that MySQL AB published. But there very likely are customers out there with different requirements. But as already mentioned, these are issues for RHEL not Fedora. If you don't mind pulling RHEL5 bits from Extras, there's no reason not to push these two packages to Extras. regards, tom lane From katzj at redhat.com Tue Jun 13 02:15:01 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 Jun 2006 22:15:01 -0400 Subject: some minor Core pruning In-Reply-To: <20060612211816.GA28504@redhat.de> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <20060612211816.GA28504@redhat.de> Message-ID: <1150164901.14948.9.camel@aglarond.local> On Mon, 2006-06-12 at 23:18 +0200, Karsten Hopp wrote: > On Mon, Jun 12, 2006 at 05:48:12PM -0400, Bill Nottingham wrote: > > lksctp-tools > Requested by two huge partners for RHEL, dunno if anyone else uses it. Doesn't really strike me as a compelling reason for it to stay in Core. Can be maintained in Extras for that. > > tn5250 > I've never used it and actually have no idea what it is used for. I just > check if there are any upstream updates and fix bugs when someone reports > them (none so far). We've already moved more important packages to Extras such > as x3270 which is absolutely required if you need to install a mainframe. tn5250 is for iSeries consoles, although x3270 has grown support for 5250s too. So nuking from orbit may well be sufficient. Jeremy From michael at knox.net.nz Tue Jun 13 02:18:28 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 14:18:28 +1200 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <448E2074.6030102@knox.net.nz> Bill Nottingham wrote: > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source [snip] > pam_smb-0:1.1.7-7.2.src Fixed version of the srpm can be grabbed from: http://www.knox.net.nz/~michael/pam_smb-1.1.7-7.3.src.rpm Michael From michael at knox.net.nz Tue Jun 13 02:35:16 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 14:35:16 +1200 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <448E2464.30108@knox.net.nz> Bill Nottingham wrote: > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source > librsvg2-0:2.15.0-1.src Has a BuildRequires: automake14, but its not used. Michael From notting at redhat.com Tue Jun 13 02:37:10 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 22:37:10 -0400 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <20060613023710.GA13259@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > libIDL-0:0.8.6-5.src > gnome-mag-0:0.12.5-1.src > gdm-1:2.15.3-7.src > gnome-session-0:2.15.1-4.src > librsvg2-0:2.15.0-1.src All being fixed. Bill From deisenst at gtw.net Tue Jun 13 02:55:23 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 12 Jun 2006 21:55:23 -0500 Subject: FWD: Re: New Mozilla vulnerabilities?? In-Reply-To: <44297.68.254.239.133.1150138452.squirrel@webmail.ausil.us> References: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> <44297.68.254.239.133.1150138452.squirrel@webmail.ausil.us> Message-ID: <448E291B.4090108@gtw.net> Dennis Gilmore wrote: >>The Firefox maintainer, Chris Aillon asked me to forward this along to >>this >>list. He's swamped right now trying to get the fixes for the various >>Mozilla security issues backported. He's looking for anyone willing to >>help roll new Firefox packages for FC5 and rawhide. >> >>Thanks. >> > > Work is underway I have test builds compiling now > > Dennis Hey Dennis, if you have firefox (binaries &/or source) packages built that are ready to be looked at out there somewhere, you might want to sign them with your GPG key and post a notice of their availablility for testing/looking at in bug: Regards, David From michael at knox.net.nz Tue Jun 13 03:10:10 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 15:10:10 +1200 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <448E2C92.6090206@knox.net.nz> Bill Nottingham wrote: > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source > metacity-0:2.15.5-5.src Fixed. Replaced BR on automake14 with automake, also added gettext to BR to building min mock enviro. http://www.knox.net.nz/~michael/metacity-2.15.5-6.src.rpm Michael From michael at knox.net.nz Tue Jun 13 03:23:10 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 15:23:10 +1200 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <448E2F9E.9020209@knox.net.nz> Bill Nottingham wrote: > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source > nss_db-0:2.2-35.src Switched automake15 for automake. http://www.knox.net.nz/~michael/nss_db-2.2-36.src.rpm Michael From notting at redhat.com Tue Jun 13 03:54:33 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 23:54:33 -0400 Subject: more Core dependency data Message-ID: <20060613035433.GA32114@nostromo.devel.redhat.com> The following packages: - have no dependencies in Core - are not in comps - are not subpackages of something in comps Hence, the question is - should they stay in core? Should they get added to comps? Should they move to Extras? (Note that only two of these actually have deps in Extras, as well...) adjtimex amtu awesfx bluez-hcidump busybox gecko-sharp2 genromfs hesinfo hexedit hwbrowser iddev ipv6calc isicom jgroups m2crypto magma-plugins mpage mt-st perl-File-MMagic perl-TermReadKey perl-XML-Dumper procinfo pychecker pydict python-docs rhnlib rwall scim-bridge selinux-doc sg3_utils tanukiwrapper ttcp usbutils xorg-x11-drv-tek4957 xorg-x11-drv-vmmouse xorg-x11-xdm xorg-x11-xfwp Bill From rc040203 at freenet.de Tue Jun 13 04:08:12 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 06:08:12 +0200 Subject: some minor Core pruning In-Reply-To: <448E2C92.6090206@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E2C92.6090206@knox.net.nz> Message-ID: <1150171693.30155.85.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 15:10 +1200, Michael J. Knox wrote: > Bill Nottingham wrote: > > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source > > metacity-0:2.15.5-5.src > > Fixed. Replaced BR on automake14 with automake, also added gettext to BR > to building min mock enviro. The big-bang approach - If you think this is the right way to handle this issue, I could not disagree more. Metacity uses automake-1.7, uses AM_MAINTAINER_MODE, the only patch affecting the autotools is a one liner, so providing a patch would be trivial and painless. BTW: The gettext-thing probably is a missing dep in intltool. [This had been reported elsewhere before] > http://www.knox.net.nz/~michael/metacity-2.15.5-6.src.rpm Ralf From rc040203 at freenet.de Tue Jun 13 04:11:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 06:11:19 +0200 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <1150171879.30155.90.camel@mccallum.corsepiu.local> On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > The following packages: > > - have no dependencies in Core > - are not in comps > - are not subpackages of something in comps > > Hence, the question is - should they stay in core? ??? Many of them are utilities ... Ralf From michael at knox.net.nz Tue Jun 13 04:11:35 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 16:11:35 +1200 Subject: some minor Core pruning In-Reply-To: <1150171693.30155.85.camel@mccallum.corsepiu.local> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E2C92.6090206@knox.net.nz> <1150171693.30155.85.camel@mccallum.corsepiu.local> Message-ID: <448E3AF7.6010007@knox.net.nz> Ralf Corsepius wrote: > On Tue, 2006-06-13 at 15:10 +1200, Michael J. Knox wrote: > >>Bill Nottingham wrote: >> >>># repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source >>>metacity-0:2.15.5-5.src >> >>Fixed. Replaced BR on automake14 with automake, also added gettext to BR >>to building min mock enviro. > > The big-bang approach - If you think this is the right way to handle > this issue, I could not disagree more. > > Metacity uses automake-1.7, uses AM_MAINTAINER_MODE, the only patch > affecting the autotools is a one liner, so providing a patch would be > trivial and painless. well, I am sure the metacity maintainer would appreicate the pathc ;-) I am at work for another 20mins or so, so if I get a chance I can make it. > BTW: The gettext-thing probably is a missing dep in intltool. > [This had been reported elsewhere before] > Ok, I must have not read that thread somewhere :-( Michael From michael at knox.net.nz Tue Jun 13 04:17:03 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 16:17:03 +1200 Subject: some minor Core pruning In-Reply-To: <1150171693.30155.85.camel@mccallum.corsepiu.local> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E2C92.6090206@knox.net.nz> <1150171693.30155.85.camel@mccallum.corsepiu.local> Message-ID: <448E3C3F.6010808@knox.net.nz> Ralf Corsepius wrote: > On Tue, 2006-06-13 at 15:10 +1200, Michael J. Knox wrote: > >>Bill Nottingham wrote: >> >>># repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source >>>metacity-0:2.15.5-5.src >> >>Fixed. Replaced BR on automake14 with automake, also added gettext to BR >>to building min mock enviro. [snip] > Metacity uses automake-1.7, uses AM_MAINTAINER_MODE, the only patch > affecting the autotools is a one liner, so providing a patch would be > trivial and painless. Hang about.. you said automake 1.7 are you sure? It was depending on 1.4 previously. Also, whats the downside of just using 1.9 ? (wanting to understand the issue :) ) Michael From michael at knox.net.nz Tue Jun 13 04:21:07 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 13 Jun 2006 16:21:07 +1200 Subject: more Core dependency data In-Reply-To: <1150171879.30155.90.camel@mccallum.corsepiu.local> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150171879.30155.90.camel@mccallum.corsepiu.local> Message-ID: <448E3D33.3020202@knox.net.nz> Ralf Corsepius wrote: > On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > >>The following packages: >> >>- have no dependencies in Core >>- are not in comps >>- are not subpackages of something in comps >> >>Hence, the question is - should they stay in core? > > ??? Many of them are utilities ... > Might be the case, however, if they are not in the comps file or a subpackage of something in comps, they wont be installed, Correct? So moving them to extras seems like a good idea. Michael From notting at redhat.com Tue Jun 13 04:21:44 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Jun 2006 00:21:44 -0400 Subject: more Core dependency data In-Reply-To: <1150171879.30155.90.camel@mccallum.corsepiu.local> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150171879.30155.90.camel@mccallum.corsepiu.local> Message-ID: <20060613042144.GA32766@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > > The following packages: > > > > - have no dependencies in Core > > - are not in comps > > - are not subpackages of something in comps > > > > Hence, the question is - should they stay in core? > ??? Many of them are utilities ... If they're important enough to be part of Core, they (theoretically) should be important enough to be in comps *somewhere*. Bill From jgarzik at redhat.com Tue Jun 13 04:24:48 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 13 Jun 2006 00:24:48 -0400 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <20060613042448.GB3008@devserv.devel.redhat.com> On Mon, Jun 12, 2006 at 11:54:33PM -0400, Bill Nottingham wrote: > mpage This has always been pretty darn useful, and a standard util... > mt-st ditto > sg3_utils helpful scsi utils, like hdparm or blktool Jeff From rc040203 at freenet.de Tue Jun 13 04:32:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 06:32:15 +0200 Subject: some minor Core pruning In-Reply-To: <448E3C3F.6010808@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E2C92.6090206@knox.net.nz> <1150171693.30155.85.camel@mccallum.corsepiu.local> <448E3C3F.6010808@knox.net.nz> Message-ID: <1150173136.30155.104.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 16:17 +1200, Michael J. Knox wrote: > Ralf Corsepius wrote: > > On Tue, 2006-06-13 at 15:10 +1200, Michael J. Knox wrote: > > > >>Bill Nottingham wrote: > >> > >>># repoquery --whatrequires --alldeps autoconf213 automake14 automake15 --archlist i686,i386,noarch,src --repoid development --repoid development-source > >>>metacity-0:2.15.5-5.src > >> > >>Fixed. Replaced BR on automake14 with automake, also added gettext to BR > >>to building min mock enviro. > > [snip] > > > Metacity uses automake-1.7, uses AM_MAINTAINER_MODE, the only patch > > affecting the autotools is a one liner, so providing a patch would be > > trivial and painless. > > Hang about.. you said automake 1.7 are you sure? With the sources from your src.rpm: # tar xzf metacity-2.15.5-jun6-2006.tar.gz .. # head -1 metacity-2.15.5-jun6-2006/Makefile.in # Makefile.in generated by automake 1.7.9 from Makefile.am. > It was depending on 1.4 > previously. > > Also, whats the downside of just using 1.9 ? (wanting to understand the > issue :) ) Many subtile behavioral changes potentially affecting a package. Checking whether a package is affected by them is not an easy task. However, in most cases, using automake-1.9 on packages having been designed for 1.7 is harmless. Using automake > 1.4 on packages having been written for 1.4 almost never works. Ralf From rc040203 at freenet.de Tue Jun 13 04:48:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 06:48:19 +0200 Subject: more Core dependency data In-Reply-To: <20060613042144.GA32766@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150171879.30155.90.camel@mccallum.corsepiu.local> <20060613042144.GA32766@nostromo.devel.redhat.com> Message-ID: <1150174100.30155.108.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 00:21 -0400, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > > > The following packages: > > > > > > - have no dependencies in Core > > > - are not in comps > > > - are not subpackages of something in comps > > > > > > Hence, the question is - should they stay in core? > > ??? Many of them are utilities ... I should have said "optional utilities", being important/helpful in individual setups. > If they're important enough to be part of Core, they (theoretically) > should be important enough to be in comps *somewhere*. The fact they have not been, indicates users using them must have installed them otherwise (esp. w/o anaconda) ;) Ralf From mattdm at mattdm.org Tue Jun 13 04:50:55 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Jun 2006 00:50:55 -0400 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <20060613045055.GA11346@jadzia.bu.edu> On Mon, Jun 12, 2006 at 11:54:33PM -0400, Bill Nottingham wrote: > busybox Anaconda still uses this, yeah? > hesinfo Does anyone at all in the world use this? Does MIT, still? Is there any point in keeping *any* of the Hesiod stuff? > rhnlib Yeah, this can be taken out and shot. :) A lot of the rest could go into extras. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From peter at thecodergeek.com Tue Jun 13 04:55:34 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 12 Jun 2006 21:55:34 -0700 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <448E4546.1010900@thecodergeek.com> Bill Nottingham wrote: > python-docs Python is part of Core. I think it'd make sens for the documentation to also be in Core too. > rhnlib This is the RHN stuff...now that we have Pup/Pirut (with YumApplet in development), we don't need this right? Seems to be like it can be easily punted from Core. > selinux-doc I think it should stay, for similar reasoning as python-docs, above. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Tue Jun 13 05:07:20 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Jun 2006 01:07:20 -0400 Subject: more Core dependency data In-Reply-To: <448E4546.1010900@thecodergeek.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <448E4546.1010900@thecodergeek.com> Message-ID: <20060613050720.GA12376@jadzia.bu.edu> On Mon, Jun 12, 2006 at 09:55:34PM -0700, Peter Gordon wrote: > > python-docs > Python is part of Core. I think it'd make sens for the documentation to > also be in Core too. Maybe. How often to people look at it rather than just going to the web? This is 13M that could be freed up on the CDs.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jnovy at redhat.com Tue Jun 13 06:32:13 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 13 Jun 2006 08:32:13 +0200 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <1150180333.3662.12.camel@localhost.localdomain> On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > Should they move to Extras? (Note that only two of these > actually have deps in Extras, as well...) > > hexedit Mostly duplicates functionality we have in mc already. The only advantage it has is that it's able to edit/view raw devices and contains helpers to edit sectors, etc. The new upstream version also uses color highlighting of the numbers based on their value (they call it "fruit salad" view mode), which is also missing in mc so far. > usbutils lsusb is definitely cool utility I can't imagine my life without ;) I vote for not removing it from Core. Jindrich From jakub at redhat.com Tue Jun 13 06:41:19 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 13 Jun 2006 02:41:19 -0400 Subject: more Core dependency data In-Reply-To: <20060613045055.GA11346@jadzia.bu.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <20060613045055.GA11346@jadzia.bu.edu> Message-ID: <20060613064119.GK3115@devserv.devel.redhat.com> On Tue, Jun 13, 2006 at 12:50:55AM -0400, Matthew Miller wrote: > > hesinfo > > Does anyone at all in the world use this? Does MIT, still? Is there any > point in keeping *any* of the Hesiod stuff? A few universities apparently, e.g. Iowa state, use Hesiod heavily. Jakub From lsmid at redhat.com Tue Jun 13 08:08:49 2006 From: lsmid at redhat.com (Ludek Smid) Date: Tue, 13 Jun 2006 10:08:49 +0200 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <448E7291.70005@redhat.com> Bill Nottingham wrote: > Library + binary packages required by nothing (could be killed, or moved): > xdelta I have nothing against removing xdelta from core, but as far as I know, it's only package providing binary diff feature. The source code of xdelta is no longer maintained by upstream. Maybe we can replace it by another utility. Suggestions? Ludek From jnovy at redhat.com Tue Jun 13 08:17:10 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 13 Jun 2006 10:17:10 +0200 Subject: some minor Core pruning In-Reply-To: <448E7291.70005@redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <448E7291.70005@redhat.com> Message-ID: <1150186630.2255.6.camel@localhost.localdomain> On Tue, 2006-06-13 at 10:08 +0200, Ludek Smid wrote: > Bill Nottingham wrote: > > Library + binary packages required by nothing (could be killed, or moved): > > xdelta > > I have nothing against removing xdelta from core, but as far as I know, > it's only package providing binary diff feature. > > The source code of xdelta is no longer maintained by upstream. Maybe we > can replace it by another utility. Suggestions? bsdiff which is now in Extras could be a good replacement candidate IMO. The question is whether the bindiff functionality is needed in Core at all since no Core app explicitly requires binary diffing (for now). Jindrich From pertusus at free.fr Tue Jun 13 09:56:57 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 13 Jun 2006 11:56:57 +0200 Subject: some minor Core pruning In-Reply-To: <448E7291.70005@redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <448E7291.70005@redhat.com> Message-ID: <20060613095657.GC2515@free.fr> > I have nothing against removing xdelta from core, but as far as I know, > it's only package providing binary diff feature. > > The source code of xdelta is no longer maintained by upstream. Maybe we > can replace it by another utility. Suggestions? It isn't the same than what is at http://sourceforge.net/projects/xdelta/ ? There was a release of that soft on 2006-05-13. -- Pat From rc040203 at freenet.de Tue Jun 13 10:16:40 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 12:16:40 +0200 Subject: some minor Core pruning In-Reply-To: <1150186630.2255.6.camel@localhost.localdomain> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <448E7291.70005@redhat.com> <1150186630.2255.6.camel@localhost.localdomain> Message-ID: <1150193800.30155.120.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 10:17 +0200, Jindrich Novy wrote: > On Tue, 2006-06-13 at 10:08 +0200, Ludek Smid wrote: > > Bill Nottingham wrote: > > > Library + binary packages required by nothing (could be killed, or moved): > > > xdelta > > > > I have nothing against removing xdelta from core, but as far as I know, > > it's only package providing binary diff feature. > > > > The source code of xdelta is no longer maintained by upstream. Maybe we > > can replace it by another utility. Suggestions? > > bsdiff which is now in Extras could be a good replacement candidate IMO. > The question is whether the bindiff functionality is needed in Core at > all since no Core app explicitly requires binary diffing (for now). It could be useful for rpmbuild (Imagine patching binary images) or ... ... (pronouncing the unspeakable) to support xdelta rpms ;) Ralf From lsmid at redhat.com Tue Jun 13 10:58:21 2006 From: lsmid at redhat.com (Ludek Smid) Date: Tue, 13 Jun 2006 12:58:21 +0200 Subject: some minor Core pruning In-Reply-To: <20060613095657.GC2515@free.fr> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <448E7291.70005@redhat.com> <20060613095657.GC2515@free.fr> Message-ID: <448E9A4D.4060309@redhat.com> Patrice Dumas wrote: > It isn't the same than what is at http://sourceforge.net/projects/xdelta/ ? > > There was a release of that soft on 2006-05-13. It is, but it is version 3.0 not backward compatible with 1.1.3 that is currently shipped in FC5. That means, at this point you can freely select between xdelta 3.0 and it's alternatives. Ludek From jkeating at j2solutions.net Tue Jun 13 11:58:31 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 13 Jun 2006 07:58:31 -0400 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <1150199911.2417.12.camel@ender> On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > bluez-hcidump This should probably be in comps somewhere or a dep of something. I do believe this is necessary for some bluetooth work. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roozbeh at farsiweb.info Tue Jun 13 11:57:45 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 13 Jun 2006 15:27:45 +0330 Subject: more Core dependency data In-Reply-To: <20060613050720.GA12376@jadzia.bu.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <448E4546.1010900@thecodergeek.com> <20060613050720.GA12376@jadzia.bu.edu> Message-ID: <1150199865.3373.2.camel@tameshk.farsiweb.info> ??? ???????? 2006-06-13 ???? 01:07 -0400? Matthew Miller ????: > On Mon, Jun 12, 2006 at 09:55:34PM -0700, Peter Gordon wrote: > > > python-docs > > Python is part of Core. I think it'd make sens for the documentation to > > also be in Core too. > > Maybe. How often to people look at it rather than just going to the web? A lot, if they are in low connectivity parts of the world or not have a good connection. Or if they want the documentation for the exact version of something that they are running, that is not necessarily available online. roozbeh From jkeating at redhat.com Tue Jun 13 12:06:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Jun 2006 08:06:16 -0400 Subject: More packages on the chopping block Message-ID: <1150200376.2417.16.camel@ender> These probably can't go to Extras, but one would question their existence in Core: New package openCryptoki Implementation of Cryptoki v2.11 for IBM Crypto Hardware New package s390utils Linux/390 specific utilities. These packages only come back when s390(x) is enabled in the nightly runs. Given we don't actually ship s390(x) do these really belong in Core? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pknirsch at redhat.com Tue Jun 13 12:08:28 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Tue, 13 Jun 2006 14:08:28 +0200 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <448EAABC.2010601@redhat.com> Bill Nottingham wrote: > rwall My dad's dad used to use (r)wall. But honestly, could be easily moved to extras. :) > sg3_utils Quite usefull SCSI tools. Not sure if they could be put into comps somewhere useful, but i suspect hardware dependant comps stuff is kinda out of the question. ;) 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 mattdm at mattdm.org Tue Jun 13 12:11:26 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Jun 2006 08:11:26 -0400 Subject: more Core dependency data In-Reply-To: <1150180333.3662.12.camel@localhost.localdomain> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150180333.3662.12.camel@localhost.localdomain> Message-ID: <20060613121126.GA24394@jadzia.bu.edu> On Tue, Jun 13, 2006 at 08:32:13AM +0200, Jindrich Novy wrote: > Mostly duplicates functionality we have in mc already. The only > advantage it has is that it's able to edit/view raw devices and contains > helpers to edit sectors, etc. The new upstream version also uses color > highlighting of the numbers based on their value (they call it "fruit > salad" view mode), which is also missing in mc so far. Also, mc sucks. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rvokal at redhat.com Tue Jun 13 12:12:46 2006 From: rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Tue, 13 Jun 2006 14:12:46 +0200 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <1150200766.11904.2.camel@garfield.redhat.usu> On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > ipv6calc No objection moving it to extras -- Radek Vok?l From blizzard at redhat.com Tue Jun 13 12:16:31 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 13 Jun 2006 08:16:31 -0400 Subject: more Core dependency data In-Reply-To: <20060613050720.GA12376@jadzia.bu.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <448E4546.1010900@thecodergeek.com> <20060613050720.GA12376@jadzia.bu.edu> Message-ID: <448EAC9F.3030800@redhat.com> Matthew Miller wrote: > On Mon, Jun 12, 2006 at 09:55:34PM -0700, Peter Gordon wrote: >>> python-docs >> Python is part of Core. I think it'd make sens for the documentation to >> also be in Core too. > > Maybe. How often to people look at it rather than just going to the web? > This is 13M that could be freed up on the CDs.... > > I just downloaded this off the python site yesterday, because I didn't think that we would include it in Core. You know, as a counter-example. :) --Chris From misa at redhat.com Tue Jun 13 12:38:31 2006 From: misa at redhat.com (Mihai Ibanescu) Date: Tue, 13 Jun 2006 08:38:31 -0400 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <20060613123831.GC14148@abulafia.devel.redhat.com> On Mon, Jun 12, 2006 at 11:54:33PM -0400, Bill Nottingham wrote: > The following packages: > > - have no dependencies in Core > - are not in comps > - are not subpackages of something in comps > > Hence, the question is - should they stay in core? Should they get > added to comps? Should they move to Extras? (Note that only two of these > actually have deps in Extras, as well...) > > m2crypto we include both pyOpenSSL (used by rhnlib) and m2crypto. If rhnlib goes away, is there anything else requiring pyOpenSSL? IMO pyOpenSSL is still useful for doing SSL certificate validation, but how many people care enough for it, I don't know. > pychecker Useful developer tool, I'd include it in Development. > python-docs > rhnlib These have been discussed already - python-docs should stay, it used to be a subpackage of the main python package, but I split it out to get rid of the annoying BuildRequires of tetex. Misa From jkeating at j2solutions.net Tue Jun 13 12:39:19 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 13 Jun 2006 08:39:19 -0400 Subject: more Core dependency data In-Reply-To: <448EAABC.2010601@redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <448EAABC.2010601@redhat.com> Message-ID: <1150202359.2417.18.camel@ender> On Tue, 2006-06-13 at 14:08 +0200, Phil Knirsch wrote: > > > sg3_utils > > Quite usefull SCSI tools. Not sure if they could be put into comps > somewhere useful, but i suspect hardware dependant comps stuff is > kinda > out of the question. ;) Do note, that useful things can live in Extras. Especially if they aren't listed in comps and thus aren't available at install time. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Tue Jun 13 12:43:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 13 Jun 2006 08:43:49 -0400 Subject: more Core dependency data In-Reply-To: <20060613045055.GA11346@jadzia.bu.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <20060613045055.GA11346@jadzia.bu.edu> Message-ID: <1150202629.14948.15.camel@aglarond.local> On Tue, 2006-06-13 at 00:50 -0400, Matthew Miller wrote: > On Mon, Jun 12, 2006 at 11:54:33PM -0400, Bill Nottingham wrote: > > busybox > > Anaconda still uses this, yeah? Yep, for minstg2.img > > hesinfo > > Does anyone at all in the world use this? Does MIT, still? Is there any > point in keeping *any* of the Hesiod stuff? There are places that use hesiod, but the extra little utilities like this could probably be just as well maintained in Extras. Jeremy From sgrubb at redhat.com Tue Jun 13 13:21:23 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 13 Jun 2006 09:21:23 -0400 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <200606130921.23796.sgrubb@redhat.com> On Monday 12 June 2006 23:54, Bill Nottingham wrote: > Hence, the question is - should they stay in core? > > amtu This one is in the LSPP Security Target. It also seems that there are customers that do their own setup and take it through accreditation. For RHEL5, I think it should be in comps. For FC, I don't think it matters one way or another. -Steve From sgrubb at redhat.com Tue Jun 13 13:37:20 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 13 Jun 2006 09:37:20 -0400 Subject: some minor Core pruning In-Reply-To: <448E1704.6010608@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <20060613013220.GB2576@nostromo.devel.redhat.com> <448E1704.6010608@knox.net.nz> Message-ID: <200606130937.20342.sgrubb@redhat.com> On Monday 12 June 2006 21:38, Michael J. Knox wrote: > > Not sure. Probably worth some investigation. > > I have a rawhide tree here, I will see what I can break. Thanks for looking at this guys. In most cases, you can just change the automake BR to automake or automake16. I did find the occasional package that needed its .am files patched, but I think I submitted patches for the worst ones 2 years ago. I was also wondering about byacc. Is it needed for anything that bison can't cover? In many cases, the configure script will look for both and chose which ever it finds. In a couple places, Makefiles had to be patched to use bison -y but otherwise the substitution works fine. -Steve From coldwell at redhat.com Tue Jun 13 13:48:29 2006 From: coldwell at redhat.com (Chip Coldwell) Date: Tue, 13 Jun 2006 09:48:29 -0400 (EDT) Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: On Mon, 12 Jun 2006, Bill Nottingham wrote: > The following packages: > > - have no dependencies in Core > - are not in comps > - are not subpackages of something in comps > > Hence, the question is - should they stay in core? Should they get > added to comps? Should they move to Extras? (Note that only two of these > actually have deps in Extras, as well...) > > adjtimex This is needed by NTP, no? > mt-st How can you rewind and eject a tape without mt? > sg3_utils Very useful for discovering what a particular scsi generic device is sg_inq /dev/sgN etc. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc From rdieter at math.unl.edu Tue Jun 13 14:04:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jun 2006 09:04:08 -0500 Subject: some minor Core pruning Message-ID: <448EC5D8.10907@math.unl.edu> Michael J. Knox wrote: > Bill Nottingham wrote: >> # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 >> # --archlist i686,i386,noarch,src --repoid development --repoid >> # development-source >> gtk+-1:1.2.10-50.src > Would it be much work to move these way from those requirements? I'm 90% certain gtk+ absolutely needs autoconf213,automake14 -- Rex From rc040203 at freenet.de Tue Jun 13 14:12:44 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 16:12:44 +0200 Subject: some minor Core pruning In-Reply-To: <448EC5D8.10907@math.unl.edu> References: <448EC5D8.10907@math.unl.edu> Message-ID: <1150207965.30155.142.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 09:04 -0500, Rex Dieter wrote: > Michael J. Knox wrote: > > Bill Nottingham wrote: > > >> # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 > >> # --archlist i686,i386,noarch,src --repoid development --repoid > >> # development-source > >> gtk+-1:1.2.10-50.src > > > Would it be much work to move these way from those requirements? > > I'm 90% certain gtk+ absolutely needs autoconf213,automake14 Not, if not running the autotools as part of building and not if gtk+ is not part of Core. Ralf From jwboyer at jdub.homelinux.org Tue Jun 13 14:24:24 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 13 Jun 2006 09:24:24 -0500 Subject: more Core dependency data In-Reply-To: References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <1150208664.29294.10.camel@weaponx.rchland.ibm.com> On Tue, 2006-06-13 at 09:48 -0400, Chip Coldwell wrote: > > > sg3_utils > > Very useful for discovering what a particular scsi generic device is And it can be just as useful in Extras as it was/is in Core. Usefulness is not a good metric to determine if something needs to be in Core. josh From mlichvar at redhat.com Tue Jun 13 14:01:37 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 13 Jun 2006 16:01:37 +0200 Subject: more Core dependency data In-Reply-To: References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <20060613140137.GB19431@bordell.redhat.usu> On Tue, Jun 13, 2006 at 09:48:29AM -0400, Chip Coldwell wrote: > >adjtimex > > This is needed by NTP, no? No. It is just a utility that can show/set kernel time variables. This can be useful when you want more accurate system time without using ntpd. Could go to Extras. -- Miroslav Lichvar From rdieter at math.unl.edu Tue Jun 13 15:05:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jun 2006 10:05:35 -0500 Subject: some minor Core pruning In-Reply-To: <448EC5D8.10907@math.unl.edu> References: <448EC5D8.10907@math.unl.edu> Message-ID: <448ED43F.70205@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2006-06-13 at 09:04 -0500, Rex Dieter wrote: >> Michael J. Knox wrote: >> > Bill Nottingham wrote: >> >> # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 >> >> # --archlist i686,i386,noarch,src --repoid development --repoid >> >> # development-source >> >> gtk+-1:1.2.10-50.src >> > Would it be much work to move these way from those requirements? >> I'm 90% certain gtk+ absolutely needs autoconf213,automake14 > Not, if not running the autotools as part of building and not if gtk+ is > not part of Core. I thought we were only speaking in terms of BuildRequires here. Good point though, gtk+ is already (supposedly, soon-to-be) out of Core. -- Rex From notting at redhat.com Tue Jun 13 15:55:39 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Jun 2006 11:55:39 -0400 Subject: more Core dependency data In-Reply-To: <1150202629.14948.15.camel@aglarond.local> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <20060613045055.GA11346@jadzia.bu.edu> <1150202629.14948.15.camel@aglarond.local> Message-ID: <20060613155539.GA2535@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > Anaconda still uses this, yeah? > > Yep, for minstg2.img Then require it. :P Bill From notting at redhat.com Tue Jun 13 15:57:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Jun 2006 11:57:08 -0400 Subject: more Core dependency data In-Reply-To: <1150208664.29294.10.camel@weaponx.rchland.ibm.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150208664.29294.10.camel@weaponx.rchland.ibm.com> Message-ID: <20060613155708.GB2535@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > And it can be just as useful in Extras as it was/is in Core. > > Usefulness is not a good metric to determine if something needs to be in > Core. Well, it is to some extent. For example, a web browser is considered useful enough to be in Core. It's a matter of degrees. Bill From smooge at gmail.com Tue Jun 13 16:08:44 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 13 Jun 2006 10:08:44 -0600 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> On 6/12/06, Bill Nottingham wrote: adjtimex Extras amtu Core system-tools awesfx Extras bluez-hcidump Core system-tools busybox Core core gecko-sharp2 Extras genromfs Extras hesinfo Extras hexedit Core system-tools hwbrowser Extras [If not needed by LVM code] iddev Extras [If not needed by LVM code] ipv6calc Core system-tools isicom Extras jgroups Extras m2crypto Extras magma Core clustering magma-plugins Core clustering mpage Core printing mt-st Core perl-File-MMagic Extras perl-TermReadKey Extras perl-XML-Dumper Extras procinfo Extras pychecker Core development-tools pydict Core development-tools python-docs Core documentation rhnlib Extras rwall Core legacy-network-server scim-bridge Core chinese-support selinux-doc Core documentation sg3_utils Extras tanukiwrapper Extras ttcp Extras usbutils Core base xorg-x11-drv-tek4957 Extras? xorg-x11-drv-vmmouse Extras? xorg-x11-xdm Extras? xorg-x11-xfwp Extras? -- Stephen J Smoogen. CSIRT/Linux System Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjones at redhat.com Tue Jun 13 18:49:12 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 13 Jun 2006 14:49:12 -0400 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <1150224552.30933.24.camel@localhost.localdomain> On Mon, 2006-06-12 at 17:48 -0400, Bill Nottingham wrote: > libvolume_id Er, we _might_ wind up using this in nash. Not 100% sure yet. Go ahead and kill it for now, if I need it I can bring it back. -- Peter From pvrabec at redhat.com Tue Jun 13 19:13:00 2006 From: pvrabec at redhat.com (Peter Vrabec) Date: Tue, 13 Jun 2006 21:13:00 +0200 Subject: some minor Core pruning In-Reply-To: <20060613010419.GA20190@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <200606121831.28989.sgrubb@redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> Message-ID: <20060613211300.3c520450@a05-0705a.kn.vutbr.cz> star doesn't need autoconf213 since star-1.5a74-3 On Mon, 12 Jun 2006 21:04:19 -0400 Bill Nottingham wrote: > Steve Grubb (sgrubb at redhat.com) said: > > On Monday 12 June 2006 17:48, Bill Nottingham wrote: > > > This isn't exhaustive, by any means; there are still quite a few > > > leaf nodes that are potential Extras candidates. > > > > I was wondering why we have autoconf213, automake14, and automake15 > > still in the repo? I was able to eliminate them from my build tree > > 2 years ago. Also, is there any reason to keep byacc? I was able to > > substitute bison for everything that wanted byacc and eliminated it > > from my buildtree too. > > # repoquery --whatrequires --alldeps autoconf213 automake14 > automake15 --archlist i686,i386,noarch,src --repoid development > --repoid development-source mozilla-37:1.7.13-1.1.fc5.src > gtk+-1:1.2.10-50.src star-0:1.5a74-2.src > tetex-0:3.0-24.src > pam_smb-0:1.1.7-7.2.src > emacs-0:21.4-14.1.src > libIDL-0:0.8.6-5.src > metacity-0:2.15.5-5.src > gnome-mag-0:0.12.5-1.src > gtk+-1:1.2.10-50.src > gdm-1:2.15.3-7.src > gnome-session-0:2.15.1-4.src > librsvg2-0:2.15.0-1.src > libwmf-0:0.2.8.4-8.src > nss_db-0:2.2-35.src > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From michael at knox.net.nz Tue Jun 13 19:43:31 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 14 Jun 2006 07:43:31 +1200 (NZST) Subject: some minor Core pruning In-Reply-To: <1150207965.30155.142.camel@mccallum.corsepiu.local> References: <448EC5D8.10907@math.unl.edu> <1150207965.30155.142.camel@mccallum.corsepiu.local> Message-ID: <1158.219.89.41.91.1150227811.squirrel@www.knox.net.nz> Ralf Corsepius wrote: > On Tue, 2006-06-13 at 09:04 -0500, Rex Dieter wrote: >> Michael J. Knox wrote: >> > Bill Nottingham wrote: >> >> >> # repoquery --whatrequires --alldeps autoconf213 automake14 >> automake15 >> >> # --archlist i686,i386,noarch,src --repoid development --repoid >> >> # development-source >> >> gtk+-1:1.2.10-50.src >> >> > Would it be much work to move these way from those requirements? >> >> I'm 90% certain gtk+ absolutely needs autoconf213,automake14 > Not, if not running the autotools as part of building and not if gtk+ is > not part of Core. > auto tools are run during the build. I looked at this briefly, but didn't have time to do much else. Michael From jkeating at redhat.com Tue Jun 13 20:22:15 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Jun 2006 16:22:15 -0400 Subject: gtk-engines whacked from dist-fc6 Message-ID: <1150230135.11731.38.camel@dhcp83-49.boston.redhat.com> It doesn't look like anything uses this or uses this to build, so we removed it from FC6. If somebody wants to pick it up for extras, I pitty thee. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue Jun 13 20:23:17 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Jun 2006 16:23:17 -0400 Subject: some minor Core pruning In-Reply-To: <1150224552.30933.24.camel@localhost.localdomain> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1150224552.30933.24.camel@localhost.localdomain> Message-ID: <20060613202317.GB5556@nostromo.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > On Mon, 2006-06-12 at 17:48 -0400, Bill Nottingham wrote: > > > libvolume_id > > Er, we _might_ wind up using this in nash. Not 100% sure yet. Go ahead > and kill it for now, if I need it I can bring it back. This is actually a subpackage of udev. We could stop packaging it, but it's not removing a package. Bill From ajackson at redhat.com Tue Jun 13 19:45:49 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 13 Jun 2006 15:45:49 -0400 Subject: Core package removal: liboldX, libxkbui Message-ID: <448F15ED.7000402@redhat.com> Neither of these libs is used at all in either core or extras, AFAICT. liboldX is ABI compatibility for X10 applications, which would be shocking to find since X10 never built on Linux to begin with. libxkbui is used from the xorgcfg utility, but that's not built in Core; I don't know of any other application that uses it. Both will be dropped from Core in tomorrow's rawhide. If someone really wants to revive libxkbui for some reason, it'd be a fine candidate for Extras. - ajax From pjones at redhat.com Tue Jun 13 22:55:14 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 13 Jun 2006 18:55:14 -0400 Subject: more Core dependency data In-Reply-To: <1150199911.2417.12.camel@ender> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150199911.2417.12.camel@ender> Message-ID: <1150239314.16845.5.camel@localhost.localdomain> On Tue, 2006-06-13 at 07:58 -0400, Jesse Keating wrote: > On Mon, 2006-06-12 at 23:54 -0400, Bill Nottingham wrote: > > bluez-hcidump > > This should probably be in comps somewhere or a dep of something. I do > believe this is necessary for some bluetooth work. It's only required for debugging, not to make it work. -- Peter From pmachata at redhat.com Wed Jun 14 08:07:34 2006 From: pmachata at redhat.com (Petr Machata) Date: Wed, 14 Jun 2006 10:07:34 +0200 Subject: more Core dependency data In-Reply-To: <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> Message-ID: <1150272454.2905.14.camel@hridell.redhat.usu> On Tue, 2006-06-13 at 10:08 -0600, Stephen John Smoogen wrote: > On 6/12/06, Bill Nottingham wrote: > > genromfs Extras This is (?) used for creating initrd images. Doesn't kernel need to use it during build? PM From katzj at redhat.com Wed Jun 14 11:58:28 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 14 Jun 2006 07:58:28 -0400 Subject: more Core dependency data In-Reply-To: <1150272454.2905.14.camel@hridell.redhat.usu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> <1150272454.2905.14.camel@hridell.redhat.usu> Message-ID: <1150286308.30656.0.camel@gondor> On Wed, 2006-06-14 at 10:07 +0200, Petr Machata wrote: > On Tue, 2006-06-13 at 10:08 -0600, Stephen John Smoogen wrote: > > On 6/12/06, Bill Nottingham wrote: > > > > genromfs Extras > > This is (?) used for creating initrd images. Doesn't kernel need to use > it during build? No, we don't really use romfs for anything Jeremy From deisenst at gtw.net Wed Jun 14 16:18:52 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 14 Jun 2006 11:18:52 -0500 Subject: FYI- Re: FWD: Re: New Mozilla vulnerabilities?? In-Reply-To: <448E291B.4090108@gtw.net> References: <200606121817.k5CIHEfw032727@devserv.devel.redhat.com> <44297.68.254.239.133.1150138452.squirrel@webmail.ausil.us> <448E291B.4090108@gtw.net> Message-ID: <449036EC.1090509@gtw.net> David Eisenstein wrote: > Dennis Gilmore wrote: > >>>The Firefox maintainer, Chris Aillon asked me to forward this along to >>>this >>>list. He's swamped right now trying to get the fixes for the various >>>Mozilla security issues backported. He's looking for anyone willing to >>>help roll new Firefox packages for FC5 and rawhide. >>> >>>Thanks. >>> >> >>Work is underway I have test builds compiling now >> >>Dennis Since Bugzilla barfed yesterday, this bug has been re-entered as Bug #195241: . -David From tmraz at redhat.com Wed Jun 14 23:08:20 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 15 Jun 2006 01:08:20 +0200 Subject: gnutls upgrade Message-ID: <1150326501.3559.26.camel@perun.kabelta.loc> So I have upgraded gnutls in FC development to 1.4.0 version. This means that there is a soname bump and rebuild of dependent packages are required. This is a notice to maintainers of such dependent packages in extras so that they know about the required rebuild. I also apologize that I upgraded the gnutls package just before FC6 Test1 freeze and caused so many necessary rebuilds of Fedora Core packages. I'm sorry that I didn't realize that there are so many new dependencies in devel compared to FC4 and FC5. -- Tomas Mraz From pvrabec at redhat.com Thu Jun 15 14:49:26 2006 From: pvrabec at redhat.com (Peter Vrabec) Date: Thu, 15 Jun 2006 16:49:26 +0200 Subject: IPv6 project Message-ID: <20060615164926.064f5e94@wrabco.redhat.usu> Hi folks, could you look at IPv6Project http://intranet.corp.redhat.com/ic/intranet/wiki?wikicat=Engineering%3aIPv6Project and file IPv6 status of packages. thx. From dennis at ausil.us Thu Jun 15 15:12:10 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Jun 2006 10:12:10 -0500 (CDT) Subject: IPv6 project In-Reply-To: <20060615164926.064f5e94@wrabco.redhat.usu> References: <20060615164926.064f5e94@wrabco.redhat.usu> Message-ID: <34382.68.254.239.133.1150384330.squirrel@webmail.ausil.us> I could if it was accessable > Hi folks, > > could you look at IPv6Project > http://intranet.corp.redhat.com/ic/intranet/wiki?wikicat=Engineering%3aIPv6Project > > and file IPv6 status of packages. > > thx. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From notting at redhat.com Thu Jun 15 15:41:14 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Jun 2006 11:41:14 -0400 Subject: more Core dependency data In-Reply-To: <1150286308.30656.0.camel@gondor> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> <1150272454.2905.14.camel@hridell.redhat.usu> <1150286308.30656.0.camel@gondor> Message-ID: <20060615154114.GD29888@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > On Wed, 2006-06-14 at 10:07 +0200, Petr Machata wrote: > > On Tue, 2006-06-13 at 10:08 -0600, Stephen John Smoogen wrote: > > > On 6/12/06, Bill Nottingham wrote: > > > > > > genromfs Extras > > > > This is (?) used for creating initrd images. Doesn't kernel need to use > > it during build? > > No, we don't really use romfs for anything So, this was added to the distro back in 1998. For making boot *floppies*. On *SPARC*. I think it can die. :) Bill From jpo at lsd.di.uminho.pt Thu Jun 15 17:11:05 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Thu, 15 Jun 2006 18:11:05 +0100 Subject: more Core dependency data (genromfs) In-Reply-To: <20060615154114.GD29888@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> <1150272454.2905.14.camel@hridell.redhat.usu> <1150286308.30656.0.camel@gondor> <20060615154114.GD29888@nostromo.devel.redhat.com> Message-ID: <449194A9.503@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Nottingham wrote: > Jeremy Katz (katzj at redhat.com) said: >> On Wed, 2006-06-14 at 10:07 +0200, Petr Machata wrote: >>> On Tue, 2006-06-13 at 10:08 -0600, Stephen John Smoogen wrote: >>>> On 6/12/06, Bill Nottingham wrote: >>>> >>>> genromfs Extras >>> This is (?) used for creating initrd images. Doesn't kernel need to use >>> it during build? >> No, we don't really use romfs for anything > > So, this was added to the distro back in 1998. For making boot *floppies*. On > *SPARC*. > > I think it can die. :) Please submit it to Extras (genromfs is used by embedded systems developers). jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEkZSpl0metZG9hRsRAoynAJ0cd/m99d7rydRjsb6LIDqFoVksxACfUHm3 CM3I4cmR/BUMTnFdQ6gzPd8= =6Ynd -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Thu Jun 15 17:23:56 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Jun 2006 13:23:56 -0400 Subject: more Core dependency data (genromfs) In-Reply-To: <449194A9.503@lsd.di.uminho.pt> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <80d7e4090606130908v235ad6bdje57afc5dd73949da@mail.gmail.com> <1150272454.2905.14.camel@hridell.redhat.usu> <1150286308.30656.0.camel@gondor> <20060615154114.GD29888@nostromo.devel.redhat.com> <449194A9.503@lsd.di.uminho.pt> Message-ID: <20060615172356.GC30694@nostromo.devel.redhat.com> Jose Pedro Oliveira (jpo at lsd.di.uminho.pt) said: > > So, this was added to the distro back in 1998. For making boot *floppies*. On > > *SPARC*. > > > > I think it can die. :) > > Please submit it to Extras (genromfs is used by embedded systems > developers). What makes romfs better than cramfs or squashfs? Bill From dwmw2 at infradead.org Thu Jun 15 18:37:57 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 15 Jun 2006 19:37:57 +0100 Subject: IPv6 project In-Reply-To: <34382.68.254.239.133.1150384330.squirrel@webmail.ausil.us> References: <20060615164926.064f5e94@wrabco.redhat.usu> <34382.68.254.239.133.1150384330.squirrel@webmail.ausil.us> Message-ID: <1150396678.11159.204.camel@shinybook.infradead.org> On Thu, 2006-06-15 at 10:12 -0500, Dennis Gilmore wrote: > I could if it was accessable I don't think there's much call for a Wiki. Bugzilla ought to be a perfectly sufficient way of tracking bugs. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=195271 -- dwmw2 From rc040203 at freenet.de Fri Jun 16 06:35:13 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 08:35:13 +0200 Subject: [Bug 192912] Review Request: paps In-Reply-To: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> Message-ID: <1150439713.12910.65.camel@mccallum.corsepiu.local> > ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > NEEDSWORK > - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. Why? I thought, RH was going to use the *same* conventions as Fedora? Apparently not ... Ralf From jkeating at redhat.com Fri Jun 16 12:22:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Jun 2006 08:22:25 -0400 Subject: [Bug 192912] Review Request: paps In-Reply-To: <1150439713.12910.65.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> Message-ID: <1150460545.32654.20.camel@ender> On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: > > - Brew doesn't support %{?dist} tag anymore, so this will not > evaluate when built. > Why? I thought, RH was going to use the *same* conventions as Fedora? > > Apparently not ... We haven't yet added the support for %{?dist} yet. With the change to the new build system having to come online under very time crunched conditions, adding yet another wrinkle to the deployment was considered not worth it. I'll be looking to add that support in post Test1. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Fri Jun 16 12:44:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Jun 2006 07:44:24 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150439713.12910.65.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> Message-ID: <1150461864.22820.21.camel@localhost.localdomain> On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: > > ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > > ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > > NEEDSWORK > > - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. > Why? I thought, RH was going to use the *same* conventions as Fedora? > > Apparently not ... Brew never supported %{?dist} tag, and the guidelines say that Core packages can't expect that tag to be there. HOWEVER: Just because they can't use the actual dist tag, if they want to add any sort of suffix, they have to use the dist tag syntax. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From sgrubb at redhat.com Fri Jun 16 12:45:23 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 16 Jun 2006 08:45:23 -0400 Subject: some minor Core pruning In-Reply-To: <448E1396.9080105@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <20060613010419.GA20190@nostromo.devel.redhat.com> <448E1396.9080105@knox.net.nz> Message-ID: <200606160845.23237.sgrubb@redhat.com> On Monday 12 June 2006 21:23, Michael J. Knox wrote: > > # repoquery --whatrequires --alldeps autoconf213 automake14 automake15 > > --archlist i686,i386,noarch,src --repoid development --repoid > > development-source mozilla-37:1.7.13-1.1.fc5.src > > gtk+-1:1.2.10-50.src > > star-0:1.5a74-2.src > > tetex-0:3.0-24.src > > pam_smb-0:1.1.7-7.2.src > > emacs-0:21.4-14.1.src > > libIDL-0:0.8.6-5.src > > metacity-0:2.15.5-5.src > > gnome-mag-0:0.12.5-1.src > > gtk+-1:1.2.10-50.src > > gdm-1:2.15.3-7.src > > gnome-session-0:2.15.1-4.src > > librsvg2-0:2.15.0-1.src > > libwmf-0:0.2.8.4-8.src > > nss_db-0:2.2-35.src > > Would it be much work to move these way from those requirements? So, where do we stand with all this work? What's left? Thanks, -Steve From rc040203 at freenet.de Fri Jun 16 13:09:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 15:09:15 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150461864.22820.21.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> Message-ID: <1150463355.12910.116.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 07:44 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: > > > ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > > > ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > > > NEEDSWORK > > > - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. > > Why? I thought, RH was going to use the *same* conventions as Fedora? > > > > Apparently not ... > > Brew never supported %{?dist} tag, ... never say "never" ... ;) > and the guidelines say that Core > packages can't expect that tag to be there. Well, exactly this is one of the points I consider to be a "must-be discussed soon". At least I consider consistent and clear conventions on "NEVR"'s, which %dist is part of, to be a minimum requirement for closer and better Core<->Extra (+external repos) interaction. To me, the current situation leaves much to be desired. Ralf From bugs.michael at gmx.net Fri Jun 16 14:44:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 16 Jun 2006 16:44:18 +0200 Subject: IMPORTANT: FE - ExcludeArch for noarch packages Message-ID: <20060616164418.59b3c698.bugs.michael@gmx.net> Concerning Fedora Extras As of today, the Fedora Extras "push script", which GPG signs and publishes packages found in the "needsign" repository, respects ExcludeArch also in .noarch (!) packages. It has not done this before and has published noarch packages for all platforms. I've done the last couple of pushs with this feature enabled to see whether any package would trigger the new feature. Today, I got this warning: EXCLUDEARCH: Not releasing mhonarc-2.6.16-1.fc6.noarch.rpm for x86_64. Conclusively, it seems we have published packages like this in the repository unknowingly. You may need to submit removal requests in the Wiki for any old noarch packages, which have been published before for an architecture that should have been excluded. (Note, I've removed mhonarc for x86_64 already.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sat Jun 17 10:04:24 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 17 Jun 2006 12:04:24 +0200 Subject: Request BUILDS: Job failed on arch i386 In-Reply-To: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> References: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> Message-ID: <13dbfe4f0606170304w5b549ebaj2b1347608c9de6ee@mail.gmail.com> Hello, I am requesting Builds on cd devel/ make build for knetstats https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929 Afterwards I received the following mail. What is wrong with my make build ? Job failed on arch i386 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/11137-knetstats-1.5-7.fc6/ ------------------------------------------------- Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/selinux Executing /usr/sbin/mock-helper mount -t none -o bind /selinux /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/selinux ensuring dir /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts -o gid=5,mode=620 pts /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/pts ensuring dir /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/shm Executing /usr/sbin/mock-helper mount -t tmpfs shm /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/shm Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/null -m 666 c 1 3 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/urandom -m 644 c 1 9 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/random -m 644 c 1 9 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/full -m 666 c 1 7 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/ptmx -m 666 c 5 2 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/tty -m 666 c 5 0 Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/zero -m 666 c 1 5 Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root groupinstall build Failed to add groups file for repository: core file:///pub/fedora/linux/core/development/i386/os/Fedora/RPMS/initscripts-8.35-1.i386.rpm: [Errno -1] Header is not complete. Trying other mirror. Error: failure: Fedora/RPMS/initscripts-8.35-1.i386.rpm from core: [Errno 256] No more mirrors to try. unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category unhandled node in : category Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/selinux Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/shm Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-3db029e82ce39f23ee3bb50d7f5a003ebc4f1a57/root/dev/pts Done. -- http://clunixchit.blogspot.com -- http://clunixchit.blogspot.com From packages at amiga-hardware.com Sat Jun 17 21:45:44 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 17 Jun 2006 22:45:44 +0100 Subject: Request BUILDS: Job failed on arch i386 In-Reply-To: <13dbfe4f0606170304w5b549ebaj2b1347608c9de6ee@mail.gmail.com> References: <13dbfe4f0606170301s1984795ay9c1e5046885d29a5@mail.gmail.com> <13dbfe4f0606170304w5b549ebaj2b1347608c9de6ee@mail.gmail.com> Message-ID: <44947808.9090509@amiga-hardware.com> Chitlesh GOORAH wrote: > Afterwards I received the following mail. What is wrong with my make > build ? It appears the build system is unable to contact its repo at the moment. I'd just wait wait a day and try and requeue the job. -- Ian Chapman. From fedora at leemhuis.info Sun Jun 18 19:04:07 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Jun 2006 21:04:07 +0200 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday Message-ID: <1150657448.2210.26.camel@localhost.localdomain> Hi! I'm proud to announce that the Fedora Extras Steering Committee (created on the first FUDCon back in February 2005) plans an election to let all Extras packagers vote the new members for the next FESCo working period. 17 people nominated themselves for the job: 1. Andreas Bierfert (awjb) 2. Tom "spot" Callaway (spot) 3. Rex Dieter (rdieter) 4. Kevin Fenzi (nirik) 5. Dennis Gilmore (ausil) irc (dgilmore) 6. Christian Iseli (c4chris) 7. Jeremy Katz (jeremy) 8. Michael J. Knox (mjk) 9. Toshio Kuratomi (abadger1999) 10. Thorsten Leemhuis (thl) 11. Jose-Pedro Oliviera (jpo) 12. Brian Pepple (bpepple) 13. Michael Schwendt (mschwendt) 14. Ville Skytt? (scop) 15. Jason Tibbitts (tibbs) 16. Warren Togami (wtogami) 17. Seth Vidal (skvidal) For details and some future plans of these fine people see: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations You are a Fedora Extras Packager and want to be in the next FESCo? Well, then hurry up and nominate yourself until Tuesday, 20 June 23:59 UTC by adding yourself to above wiki page. For some details on the nominations and the background of the decision to actually make it one see: https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00026.html The actual election will start on Thursday, 22 June 0:01 UTC and will last until Sunday, 02 July 23:59 UTC. The results will be posted to this list. The first meeting of the "new" FESCo will be on Thursday, June 06 2006 on #fedora-extras at 17:00 UTC. A new chair will be elected there by the new members. The actual voting will happen in the accounts system. Toshio Kuratomi was so helpful and created a framework for it, see https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00676.html for details. Thanks for your great work Toshio! I hope I didn't miss any important information. If I did: Just ask. CU thl P.S.: Sorry for cross-posting, but I think that okay for this kind of mail. Follow-up-to fedora-extras-list at redhat.com only please. tia! -- Thorsten Leemhuis From rc040203 at freenet.de Mon Jun 19 04:10:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Jun 2006 06:10:43 +0200 Subject: [Bug 195645] Review Request: rasqal - RDF query library In-Reply-To: <200606182022.k5IKMioE027629@bugzilla.redhat.com> References: <200606182022.k5IKMioE027629@bugzilla.redhat.com> Message-ID: <1150690243.16123.107.camel@mccallum.corsepiu.local> On Sun, 2006-06-18 at 16:22 -0400, bugzilla at redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: Review Request: rasqal - RDF query library > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195645 > > > > > > ------- Additional Comments From thomas at apestaart.org 2006-06-18 16:14 EST ------- > It's not that I do not want to use %makeinstall - it's that the packaging > guidelines that mention you shouldn't use it do not say *anything* useful about > it, why it's bad, and they're not even correct. If I need to make this change, > I need to know because I have a bunch of other packages using %makeinstall. > > Let's take those rules step by step: > > %makeinstall overrides a set of environment variables during "make > install". I.e. it performs make prefix="..." includedir="..." ... > > This is wrong - it overrides make variables, not environment variables. Unless make isn't broken and unless the makefiles aren't playing dirty games with make flags the effect is the same. > In addition, this is all the rule says - it does not say that it is wrong or why > it is wrong. So it's a) factually wrong and b) irrelevant. > > > It is error prone, and can have unexpected effects when run against less > than perfect Makefiles. > > How is it error prone ? - More sources of errors: A dozen vars vs. one single var. - %makeinstall causes the makefiles to see a different set of variables between "make install" and other (previous/subsequent) invocations of make. > How does make DESTDIR=... not fail when run against a > less than perfect Makefile - for example, one that doesn't even *have* DESTDIR ? > > It can trigger unnecessary rebuilds when executing "make install" > > Don't know about this one, it may be true or may not be true, but in all the > packages I've built I've never known this to be a problem that actually bothered me. It's the second point above. %makeinstall causes the makefiles to see different variables during "make install", than those which had been used in %configure or during "make all". This triggers broken rebuilds, if a makefile contains dependencies on the make variables being changed during %makeinstall. A similar problem occurs with makefile which edit/generate files during "make install" ("install-hooks"), e.g. to propagate final installation dirs to scripts/config-files. > If a package contains libtool archives, it can cause broken *.la files to > be installed. > > I haven't seen broken .la files, This issue for example affects(~ed?) GCC. Ralf From michael at knox.net.nz Mon Jun 19 05:18:22 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 19 Jun 2006 17:18:22 +1200 Subject: [Bug 195645] Review Request: rasqal - RDF query library In-Reply-To: <1150690243.16123.107.camel@mccallum.corsepiu.local> References: <200606182022.k5IKMioE027629@bugzilla.redhat.com> <1150690243.16123.107.camel@mccallum.corsepiu.local> Message-ID: <4496339E.7030808@knox.net.nz> Hi, sorry for the top post.... Personally, %makeinstall should be left to the developers discretion. As you had already previously stated: "Why the %makeinstall? makeinstall is an anachronism and should only be used if make DESTDIR=... install is nonfunctional." So, that would imply, that there could be a case for it. I don't know if rasqal falls into this, but if it works with make DEST... install then it should that. Re: broken .la files... who cares? its a pointless concern since Fedora policy is not to ship .la files. Hey.. look at that... I didn't disagree with you Ralf :) Michael Ralf Corsepius wrote: >> ------- Additional Comments From thomas at apestaart.org 2006-06-18 16:14 EST ------- >> It's not that I do not want to use %makeinstall - it's that the packaging >> guidelines that mention you shouldn't use it do not say *anything* useful about >> it, why it's bad, and they're not even correct. If I need to make this change, >> I need to know because I have a bunch of other packages using %makeinstall. >> >> Let's take those rules step by step: >> >> %makeinstall overrides a set of environment variables during "make >> install". I.e. it performs make prefix="..." includedir="..." ... >> >> This is wrong - it overrides make variables, not environment variables. > Unless make isn't broken and unless the makefiles aren't playing dirty > games with make flags the effect is the same. > >> In addition, this is all the rule says - it does not say that it is wrong or why >> it is wrong. So it's a) factually wrong and b) irrelevant. >> >> >> It is error prone, and can have unexpected effects when run against less >> than perfect Makefiles. >> >> How is it error prone ? > > - More sources of errors: A dozen vars vs. one single var. > > - %makeinstall causes the makefiles to see a different set of variables > between "make install" and other (previous/subsequent) invocations of > make. > >> How does make DESTDIR=... not fail when run against a >> less than perfect Makefile - for example, one that doesn't even *have* DESTDIR ? >> >> It can trigger unnecessary rebuilds when executing "make install" >> >> Don't know about this one, it may be true or may not be true, but in all the >> packages I've built I've never known this to be a problem that actually bothered me. > It's the second point above. > > %makeinstall causes the makefiles to see different variables during > "make install", than those which had been used in %configure or during > "make all". > > This triggers broken rebuilds, if a makefile contains dependencies on > the make variables being changed during %makeinstall. > > A similar problem occurs with makefile which edit/generate files during > "make install" ("install-hooks"), e.g. to propagate final installation > dirs to scripts/config-files. > >> If a package contains libtool archives, it can cause broken *.la files to >> be installed. >> >> I haven't seen broken .la files, > This issue for example affects(~ed?) GCC. > > Ralf > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From rc040203 at freenet.de Mon Jun 19 05:56:30 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Jun 2006 07:56:30 +0200 Subject: [Bug 195645] Review Request: rasqal - RDF query library In-Reply-To: <4496339E.7030808@knox.net.nz> References: <200606182022.k5IKMioE027629@bugzilla.redhat.com> <1150690243.16123.107.camel@mccallum.corsepiu.local> <4496339E.7030808@knox.net.nz> Message-ID: <1150696591.16123.121.camel@mccallum.corsepiu.local> On Mon, 2006-06-19 at 17:18 +1200, Michael J. Knox wrote: > Hi, > > sorry for the top post.... > > Personally, %makeinstall should be left to the developers discretion. I didn't say anything else. It's each packager's freedom to avoid making his live easy. > As > you had already previously stated: > > "Why the %makeinstall? makeinstall is an anachronism and should only be > used if make DESTDIR=... install is nonfunctional." Exactly. There is no point in making "make DESTDIR=... install" mandatory, but if a configuration supports it, there less reason not to use it. > So, that would imply, that there could be a case for it. I don't know if > rasqal falls into this, but if it works with make DEST... install then > it should that. > > Re: broken .la files... who cares? Libtool is just an example of a tool of which some versions are using "install-hooks". There exist many more. > its a pointless concern since Fedora > policy is not to ship .la files. Well, a lot of the FUD people spread on libtool stems from people facing side-effects of %makeinstall ;) Whether Fedora not shipping *.la's is a good decision or not is another topic (IMO, this decision is a fault). Ralf From michael at knox.net.nz Mon Jun 19 20:57:06 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 20 Jun 2006 08:57:06 +1200 Subject: gnome-libs Message-ID: <44970FA2.9000503@knox.net.nz> Has this package gone west on a indefinite vacation or is it to return in extras? Sorry if I missed the email detailing this already. Michael From rdieter at math.unl.edu Tue Jun 20 12:37:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jun 2006 07:37:24 -0500 Subject: gnome-libs In-Reply-To: <44970FA2.9000503@knox.net.nz> References: <44970FA2.9000503@knox.net.nz> Message-ID: <4497EC04.7050208@math.unl.edu> Michael J. Knox wrote: > Has this package gone west on a indefinite vacation or is it to return > in extras? AFAIK, yes, gnome-libs has been removed from Core, and a quick bugzilla search makes it appear that as of yet, no one has submitted it for Fedora Extras review. -- Rex From jwboyer at jdub.homelinux.org Tue Jun 20 14:35:44 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Jun 2006 09:35:44 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657448.2210.26.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> Message-ID: <1150814145.26810.1.camel@weaponx.rchland.ibm.com> On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > > You are a Fedora Extras Packager and want to be in the next FESCo? Well, > then hurry up and nominate yourself until Tuesday, 20 June 23:59 UTC by > adding yourself to above wiki page. For some details on the nominations > and the background of the decision to actually make it one see: > https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00026.html I got back from vacation and finally added an entry for myself. Sorry for the last minute addition. I look forward to having a great election! josh From jwboyer at jdub.homelinux.org Thu Jun 22 12:52:28 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Jun 2006 07:52:28 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657448.2210.26.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> Message-ID: <1150980748.26810.4.camel@weaponx.rchland.ibm.com> On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > The actual election will start on Thursday, 22 June 0:01 UTC and will > last until Sunday, 02 July 23:59 UTC. The results will be posted to this The election has started. Get out there and vote for your next FESCo! josh From jwboyer at jdub.homelinux.org Thu Jun 22 12:59:03 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Jun 2006 07:59:03 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150980748.26810.4.camel@weaponx.rchland.ibm.com> References: <1150657448.2210.26.camel@localhost.localdomain> <1150980748.26810.4.camel@weaponx.rchland.ibm.com> Message-ID: <1150981143.26810.6.camel@weaponx.rchland.ibm.com> On Thu, 2006-06-22 at 07:52 -0500, Josh Boyer wrote: > On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > > > The actual election will start on Thursday, 22 June 0:01 UTC and will > > last until Sunday, 02 July 23:59 UTC. The results will be posted to this > > The election has started. Get out there and vote for your next FESCo! With "there" being: https://admin.fedoraproject.org/voting/vote.cgi josh From jwboyer at jdub.homelinux.org Thu Jun 22 12:52:28 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Jun 2006 07:52:28 -0500 Subject: Fedora Extras Steering Committee (FESCo) Elections beginning on Thursday In-Reply-To: <1150657448.2210.26.camel@localhost.localdomain> References: <1150657448.2210.26.camel@localhost.localdomain> Message-ID: <1150980748.26810.4.camel@weaponx.rchland.ibm.com> On Sun, 2006-06-18 at 21:04 +0200, Thorsten Leemhuis wrote: > The actual election will start on Thursday, 22 June 0:01 UTC and will > last until Sunday, 02 July 23:59 UTC. The results will be posted to this The election has started. Get out there and vote for your next FESCo! josh -- fedora-extras-list mailing list fedora-extras-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-extras-list From mharris at mharris.ca Fri Jun 23 07:01:03 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 23 Jun 2006 03:01:03 -0400 Subject: more Core dependency data In-Reply-To: <20060613035433.GA32114@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> Message-ID: <449B91AF.3070604@mharris.ca> Bill Nottingham wrote: > The following packages: > > - have no dependencies in Core > - are not in comps > - are not subpackages of something in comps > > Hence, the question is - should they stay in core? Should they get > added to comps? Should they move to Extras? (Note that only two of these > actually have deps in Extras, as well...) > [SNIP] > isicom At one point Red Hat had a contract with the company that produced this hardware, to include the software for a certain number of OS releases, or something like that. I don't remember the details as it was like 5 years ago. I do believe though that we've more than met our obligations years ago, and I'm pretty sure there is no longer any obligation to continue shipping this software. I'm not even sure if it even still works under current kernels, etc. I think we should probably just drop it completely, and if someone complains, we can always reconsider whether to add it back to Core, or to give them the opportunity to maintain it in Extras. > xorg-x11-drv-tek4957 There are people out there who use this still believe it or not. We previously had removed it, and I either got a bug report or email beating us to a pulp for removing it. We also removed tek support from xterm at the same time and had to restore it to make some people happy. Since this type of thing just more or less "works" it doesn't require any upstream maintenance, and we'll probably not ever have to perform any maintenance on it, so it is very low impact staying in core. It is actually trivial to update it in core if it is ever updated upstream, so I believe it is best to leave it in Core. > xorg-x11-drv-vmmouse This driver was just added recently for VMware, and should remain in Core and in future RHEL releases as well, in order to be able to optimally install the OS inside VMware, and to run X inside VMware post-install out of the box. > xorg-x11-xdm xdm can move to Extras or stay in Core, doesn't matter much to me, and I don't think it matters much to anyone else on the X devel team per se. either. Having said that, I'd be surprised if there isn't anyone out there with a lab of machines or similar who for whatever ungodly reason chooses/prefers to use xdm and needs it to be available out of the box on Fedora installations. In the days of monolithic X, security holes were frequently found in xdm, as were various other nasty issues, and we had to update it quite frequently, which was more work than it should be due to the monolithicity of X as a whole. Nowadays however, xdm has matured quite a bit and security vulnerabilities are fewer and further between. Also, it is rather simple to patch up the modular package to fix issues, and to generally perform any maintenance that is necessary over time. A more important reason to keep it in Core however, is that it contains various config files and scripts which are also shared with gdm and kdm. We could split those files into yet another package, but then we have to manually resync them with upstream xdm any time upstream changes them - which creates more work for no real big gains. So, I'd vote to just leave xdm in Core, at least for the time being, as it's more effort to remove it from Core and clean up the mess IMHO. > xorg-x11-xfwp To be honest, I'd be surprised if anyone even uses this at all, or if anyone ever has for that matter. I'd be perfectly comfortable seeing this dropped from Core and made available to an enthusiastic Fedora Extras volunteer. We dropped a number of apps that are provided by the X11 distribution in FC5 and for the most part, nobody has even noticed - indicating a lot of them (most of which used to be part of X11R6-contrib ages ago) are not really critical to the Core OS, and thus might make more sense in Fedora Extras if suitable volunteership is interested in taking it to task. Sorry for not responding to this previously, but I haven't read the list for a while and just went through some old mails. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Jun 23 07:07:05 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 23 Jun 2006 03:07:05 -0400 Subject: more Core dependency data In-Reply-To: <20060613121126.GA24394@jadzia.bu.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150180333.3662.12.camel@localhost.localdomain> <20060613121126.GA24394@jadzia.bu.edu> Message-ID: <449B9319.5060108@mharris.ca> Matthew Miller wrote: > On Tue, Jun 13, 2006 at 08:32:13AM +0200, Jindrich Novy wrote: >> Mostly duplicates functionality we have in mc already. The only >> advantage it has is that it's able to edit/view raw devices and contains >> helpers to edit sectors, etc. The new upstream version also uses color >> highlighting of the numbers based on their value (they call it "fruit >> salad" view mode), which is also missing in mc so far. > > Also, mc sucks. :) When I see a better file manager that is at least as stable and functional - at a bare minimum, and doesn't crash every time you move the mouse cursor too fast or sneeze, I might try it. Until then I'll continue to use mc. I certainly would prefer it to stay in Fedora Core rather than Extras both for personal reasons as well as knowing others will feel the same. When you log into a remote machine and want to perform file management activities, and the host of other features that mc has, you do not necessarily have the bandwidth available to run a GUI filemanager, and there's no guarantee that X libraries are even installed on a remote box, let alone nautilus or something. Please keep mc in Core for sysadmins and developer types. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From alan at redhat.com Fri Jun 23 07:55:20 2006 From: alan at redhat.com (Alan Cox) Date: Fri, 23 Jun 2006 03:55:20 -0400 Subject: more Core dependency data In-Reply-To: <449B91AF.3070604@mharris.ca> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> Message-ID: <20060623075520.GG32475@devserv.devel.redhat.com> On Fri, Jun 23, 2006 at 03:01:03AM -0400, Mike A. Harris wrote: > I'm not even sure if it even still works under current kernels, > etc. Yeah it works, although almost nobody has the cards any more From jnovy at redhat.com Fri Jun 23 10:49:47 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 23 Jun 2006 12:49:47 +0200 Subject: more Core dependency data In-Reply-To: <449B9319.5060108@mharris.ca> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150180333.3662.12.camel@localhost.localdomain> <20060613121126.GA24394@jadzia.bu.edu> <449B9319.5060108@mharris.ca> Message-ID: <1151059787.2309.16.camel@localhost.localdomain> On Fri, 2006-06-23 at 03:07 -0400, Mike A. Harris wrote: > Matthew Miller wrote: > > On Tue, Jun 13, 2006 at 08:32:13AM +0200, Jindrich Novy wrote: > >> Mostly duplicates functionality we have in mc already. The only > >> advantage it has is that it's able to edit/view raw devices and contains > >> helpers to edit sectors, etc. The new upstream version also uses color > >> highlighting of the numbers based on their value (they call it "fruit > >> salad" view mode), which is also missing in mc so far. > > > > Also, mc sucks. :) > > Please keep mc in Core for sysadmins and developer types. The question was whether to move hexedit to Extras. I'm absolutely sure mc belongs to Core and I would defend it pretty hardly to let it stay there ;) Jindrich From rdieter at math.unl.edu Fri Jun 23 11:59:18 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Jun 2006 06:59:18 -0500 Subject: more Core dependency data In-Reply-To: <449B91AF.3070604@mharris.ca> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> Message-ID: <449BD796.6050201@math.unl.edu> Mike A. Harris wrote: > Bill Nottingham wrote: >> The following packages: >> >> - have no dependencies in Core >> - are not in comps >> - are not subpackages of something in comps >> >> Hence, the question is - should they stay in core? Should they get >> added to comps? Should they move to Extras? (Note that only two of these >> actually have deps in Extras, as well...) >> > [SNIP] >> xorg-x11-xdm > > xdm can move to Extras or stay in Core, doesn't matter much to me, FYI, xdm's structure and config files (/etc/X11/xdm/*) are used by kdebase/kdm, so these two are tied together. -- Rex From rdieter at math.unl.edu Fri Jun 23 12:04:55 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Jun 2006 07:04:55 -0500 Subject: more Core dependency data In-Reply-To: <449BD796.6050201@math.unl.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <449BD796.6050201@math.unl.edu> Message-ID: <449BD8E7.2050400@math.unl.edu> Rex Dieter wrote: > Mike A. Harris wrote: >> Bill Nottingham wrote: >>> The following packages: >>> >>> - have no dependencies in Core >>> - are not in comps >>> - are not subpackages of something in comps >>> xorg-x11-xdm >> >> xdm can move to Extras or stay in Core, doesn't matter much to me, > > FYI, xdm's structure and config files (/etc/X11/xdm/*) are used by > kdebase/kdm, so these two are tied together. The reason for their not showing up as dependencies is because kdebase atm uses *file* dependences not rpm/pkg ones: Requires: /etc/X11/xdm/Xaccess Requires: /etc/X11/xdm/Xservers Requires: /etc/X11/xdm/Xwilling Requires: /etc/X11/xinit/Xsession Requires: /etc/X11/xdm/Xsetup_0 -- Rex From jkeating at redhat.com Fri Jun 23 12:27:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Jun 2006 08:27:49 -0400 Subject: more Core dependency data In-Reply-To: <449B91AF.3070604@mharris.ca> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> Message-ID: <1151065669.26960.15.camel@ender> On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote: > > xorg-x11-drv-vmmouse > > This driver was just added recently for VMware, and should remain > in Core and in future RHEL releases as well, in order to be able > to optimally install the OS inside VMware, and to run X inside > VMware post-install out of the box. Why does it matter if it is in Core or Extras? How is it getting installed to the users system? Is it in Comps somewhere, as a default or required package? Or is it someting that users have to yum install foo after the install if they want it. If that's the case, why can't it live in Extras? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-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 Fri Jun 23 12:37:29 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 23 Jun 2006 07:37:29 -0500 Subject: more Core dependency data In-Reply-To: <1151065669.26960.15.camel@ender> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> Message-ID: <1151066249.26810.13.camel@weaponx.rchland.ibm.com> On Fri, 2006-06-23 at 08:27 -0400, Jesse Keating wrote: > On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote: > > > xorg-x11-drv-vmmouse > > > > This driver was just added recently for VMware, and should remain > > in Core and in future RHEL releases as well, in order to be able > > to optimally install the OS inside VMware, and to run X inside > > VMware post-install out of the box. > > Why does it matter if it is in Core or Extras? How is it getting > installed to the users system? Is it in Comps somewhere, as a default > or required package? Or is it someting that users have to yum install > foo after the install if they want it. If that's the case, why can't it > live in Extras? Slight tangent below: Remember that moving packages from Core to Extras isn't necessarily a 5 minute task. It needs a maintainer, and that maintainer has to have gotten sponsored according to the Extras process. And since Red Hat engineers are not automatically sponsored, it requires extra effort from them to move it if they wish to continue to maintain it. That may also be a reason for some resistance. Do I think this is a reason to not move packages? Certainly not. It's just an observation. We now return you to your regularly scheduled email. josh From jkeating at redhat.com Fri Jun 23 12:43:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Jun 2006 08:43:53 -0400 Subject: more Core dependency data In-Reply-To: <1151066249.26810.13.camel@weaponx.rchland.ibm.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> <1151066249.26810.13.camel@weaponx.rchland.ibm.com> Message-ID: <1151066633.26960.22.camel@ender> On Fri, 2006-06-23 at 07:37 -0500, Josh Boyer wrote: > > Remember that moving packages from Core to Extras isn't necessarily a > 5 > minute task. It needs a maintainer, and that maintainer has to have > gotten sponsored according to the Extras process. And since Red Hat > engineers are not automatically sponsored, it requires extra effort > from > them to move it if they wish to continue to maintain it. That may > also > be a reason for some resistance. > > Do I think this is a reason to not move packages? Certainly not. > It's > just an observation. Sure, for the first package there is some extra work involved. I try to help out when a RH engineer is trying to break into Extras. And yeah, different build system means more to learn, but for myself I keep two source dirs, one for rh internal, one for extras. the structure is the same, make tag, make build works the same, I get emails when my builds finish, its all pretty much the same. I'm curious if its the first hurdle that's causing the resistance. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Fri Jun 23 12:47:42 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 23 Jun 2006 08:47:42 -0400 Subject: more Core dependency data In-Reply-To: <1151065669.26960.15.camel@ender> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> Message-ID: <1151066862.9341.16.camel@aglarond.local> On Fri, 2006-06-23 at 08:27 -0400, Jesse Keating wrote: > On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote: > > > xorg-x11-drv-vmmouse > > > > This driver was just added recently for VMware, and should remain > > in Core and in future RHEL releases as well, in order to be able > > to optimally install the OS inside VMware, and to run X inside > > VMware post-install out of the box. > > Why does it matter if it is in Core or Extras? How is it getting > installed to the users system? Is it in Comps somewhere, as a default > or required package? It's depended on by xorg-x11-drivers now[1] (which gets installed by default). So there's good logic here :) Jeremy [1] Added a day or three ago when mharris went through and updated the dep list of the package for all of the new drivers in xorg 7.1 -- thanks Mike! From mharris at mharris.ca Mon Jun 26 10:29:04 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 26 Jun 2006 06:29:04 -0400 Subject: more Core dependency data In-Reply-To: <449BD796.6050201@math.unl.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <449BD796.6050201@math.unl.edu> Message-ID: <449FB6F0.1020004@mharris.ca> Rex Dieter wrote: > Mike A. Harris wrote: >> Bill Nottingham wrote: >>> The following packages: >>> >>> - have no dependencies in Core >>> - are not in comps >>> - are not subpackages of something in comps >>> >>> Hence, the question is - should they stay in core? Should they get >>> added to comps? Should they move to Extras? (Note that only two of these >>> actually have deps in Extras, as well...) >>> >> [SNIP] >>> xorg-x11-xdm >> >> xdm can move to Extras or stay in Core, doesn't matter much to me, > > FYI, xdm's structure and config files (/etc/X11/xdm/*) are used by > kdebase/kdm, so these two are tied together. Which, if you read the rest of my post you'd have seen that I already indicated. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon Jun 26 10:34:40 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 26 Jun 2006 06:34:40 -0400 Subject: more Core dependency data In-Reply-To: <1151065669.26960.15.camel@ender> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> Message-ID: <449FB840.6040007@mharris.ca> Jesse Keating wrote: > On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote: >>> xorg-x11-drv-vmmouse >> This driver was just added recently for VMware, and should remain >> in Core and in future RHEL releases as well, in order to be able >> to optimally install the OS inside VMware, and to run X inside >> VMware post-install out of the box. > > Why does it matter if it is in Core or Extras? How is it getting > installed to the users system? Is it in Comps somewhere, as a default > or required package? Or is it someting that users have to yum install > foo after the install if they want it. If that's the case, why can't it > live in Extras? It is easy for the X Development team to maintain all of the drivers that ship with X as a set, which can be updated all at the same time, using a single consistent policy, procedure, set of guidelines, repository, and buildsystem. Moving things like this to Extras does not buy anything that terribly useful, and it makes them unavailable during OS installation. For example, do you wish to force VMware users to install the OS via text mode, and then later yum install the drivers from Extras and have to rerun the config utility? That is quite foolish IMHO. The benefits of keeping these in the distribution far outweigh any advantages of tossing them into Extras, both to end users, to the X Devel team, to the Fedora Community, to Red Hat, and to VMWare Inc. who was kind enough to provide the drivers to X.Org so that things can work out of the box during OS installation, and post install without additional effort being expended by users. When we produce media that merges Core and Extras and anaconda can install from both, without requiring network access, and the Core and Extras repositories are merged somehow or using identical back end infrastructure, all of the points I have just made will be nullified. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon Jun 26 23:59:46 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 26 Jun 2006 19:59:46 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150461864.22820.21.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> Message-ID: <44A074F2.5010009@mharris.ca> Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: >>> ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- >>> ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- >>> NEEDSWORK >>> - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. >> Why? I thought, RH was going to use the *same* conventions as Fedora? >> >> Apparently not ... > > Brew never supported %{?dist} tag, and the guidelines say that Core > packages can't expect that tag to be there. HOWEVER: Just because they > can't use the actual dist tag, if they want to add any sort of suffix, > they have to use the dist tag syntax. This seems to be a quite sane policy to have IMHO. What can we do to enforce this at the brew level? -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From jkeating at redhat.com Tue Jun 27 01:35:59 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Jun 2006 21:35:59 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <44A074F2.5010009@mharris.ca> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> Message-ID: <1151372159.23849.18.camel@ender> On Mon, 2006-06-26 at 19:59 -0400, Mike A. Harris wrote: > This seems to be a quite sane policy to have IMHO. What can we do to > enforce this at the brew level? There are a few ways, I can draft up some post build tests that look for "FC[456]" or the like. However what I'm going to do instead is add support for %{?dist} within brew, use ls and grep to find offending packages, and file bugs with the packager to convert it to using %{?dist} to signify things. It'll just be fun to figure out upgrade paths and the such. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Tue Jun 27 12:00:59 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 27 Jun 2006 07:00:59 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <44A074F2.5010009@mharris.ca> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> Message-ID: <1151409659.28942.11.camel@localhost.localdomain> On Mon, 2006-06-26 at 19:59 -0400, Mike A. Harris wrote: > Tom 'spot' Callaway wrote: > > On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: > >>> ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > >>> ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > >>> NEEDSWORK > >>> - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. > >> Why? I thought, RH was going to use the *same* conventions as Fedora? > >> > >> Apparently not ... > > > > Brew never supported %{?dist} tag, and the guidelines say that Core > > packages can't expect that tag to be there. HOWEVER: Just because they > > can't use the actual dist tag, if they want to add any sort of suffix, > > they have to use the dist tag syntax. > > This seems to be a quite sane policy to have IMHO. What can we do to > enforce this at the brew level? I think the long term plan is to implement support for the %{?dist} macro set in brew. Jesse? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From laroche at redhat.com Tue Jun 27 12:08:00 2006 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Jun 2006 14:08:00 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1151409659.28942.11.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> Message-ID: <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> > I think the long term plan is to implement support for the %{?dist} > macro set in brew. Jesse? This would make a lot of sense to avoid changes to spec files if you want to build across several releases. Shouldn't we change Fedora Core and mass-apply this change to all packages? regards, Florian La Roche From chitlesh at fedoraproject.org Tue Jun 27 12:10:48 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 27 Jun 2006 14:10:48 +0200 Subject: devel package problem Message-ID: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> Hello there, I have the package katapult https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196262 rpmlint asks me to put the static libraries in -devel, which I did. Now I have katapult and katapult-devel during installation, I fell on root(i386)[0]$rpm -ivh katapult-* error: Failed dependencies: libkatapult.so.0 is needed by katapult-0.3.1.3-1.i386 libkatapultcatalog.so.0 is needed by katapult-0.3.1.3-1.i386 libkatapultdisplay.so.0 is needed by katapult-0.3.1.3-1.i386 the katapult package needs %{_libdir}/lib%{name}.so %{_libdir}/lib%{name}catalog.so %{_libdir}/lib%{name}display.so to install how can I ask katapult to pull katapult-devel as dependency ? Chitlesh -- http://clunixchit.blogspot.com From jkeating at redhat.com Tue Jun 27 12:30:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Jun 2006 08:30:33 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> Message-ID: <1151411433.23849.37.camel@ender> On Tue, 2006-06-27 at 14:08 +0200, Florian La Roche wrote: > Shouldn't we change Fedora Core and mass-apply this change to all > packages? See my other email. I'll be adding support for %{?dist}, but ensuring upgrade path will be fun. Is not FC5 considered newer than fc5 ? So we'll have to do some fiddling with the packages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-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 city-fan.org Tue Jun 27 12:45:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 27 Jun 2006 13:45:53 +0100 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1151411433.23849.37.camel@ender> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> <1151411433.23849.37.camel@ender> Message-ID: <44A12881.9010901@city-fan.org> Jesse Keating wrote: > On Tue, 2006-06-27 at 14:08 +0200, Florian La Roche wrote: >> Shouldn't we change Fedora Core and mass-apply this change to all >> packages? > > See my other email. I'll be adding support for %{?dist}, but ensuring > upgrade path will be fun. Is not FC5 considered newer than fc5 ? So > we'll have to do some fiddling with the packages. It's the other way around. fc5 is newer than FC5. So in most cases (since .FCn is common in Core) this will be painless. Paul. From rdieter at math.unl.edu Tue Jun 27 12:46:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Jun 2006 07:46:12 -0500 Subject: devel package problem In-Reply-To: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> References: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> Message-ID: <44A12894.2080000@math.unl.edu> Chitlesh GOORAH wrote: > Hello there, > > I have the package katapult > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196262 > > rpmlint asks me to put the static libraries in -devel, which I did. > Now I have katapult and katapult-devel > > during installation, I fell on > > root(i386)[0]$rpm -ivh katapult-* > error: Failed dependencies: > libkatapult.so.0 is needed by katapult-0.3.1.3-1.i386 > libkatapultcatalog.so.0 is needed by katapult-0.3.1.3-1.i386 > libkatapultdisplay.so.0 is needed by katapult-0.3.1.3-1.i386 > > the katapult package needs > %{_libdir}/lib%{name}.so > %{_libdir}/lib%{name}catalog.so > %{_libdir}/lib%{name}display.so > to install FYI, I think you're thinking these are static libs? They're not, but they're not -devel-type symlinks to shared libs either. In short, put them in the main pkg. > how can I ask katapult to pull katapult-devel as dependency ? You don't. -- Rex From bugs.michael at gmx.net Tue Jun 27 12:54:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 27 Jun 2006 14:54:24 +0200 Subject: devel package problem In-Reply-To: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> References: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> Message-ID: <20060627145424.9e36a06d.bugs.michael@gmx.net> On Tue, 27 Jun 2006 14:10:48 +0200, Chitlesh GOORAH wrote: > Hello there, > > I have the package katapult > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196262 The download location is inaccessible, so I cannot comment on the package (Resolving beta.glwb.info... failed: Temporary failure in name resolution.), but read on. > rpmlint asks me to put the static libraries in -devel, which I did. > Now I have katapult and katapult-devel > > during installation, I fell on > > root(i386)[0]$rpm -ivh katapult-* > error: Failed dependencies: > libkatapult.so.0 is needed by katapult-0.3.1.3-1.i386 > libkatapultcatalog.so.0 is needed by katapult-0.3.1.3-1.i386 > libkatapultdisplay.so.0 is needed by katapult-0.3.1.3-1.i386 > > the katapult package needs > %{_libdir}/lib%{name}.so > %{_libdir}/lib%{name}catalog.so > %{_libdir}/lib%{name}display.so > to install This doesn't match above failed dependencies. Look closer. The katapult package requires the *.so.0 sonames, not the *.so > > how can I ask katapult to pull katapult-devel as dependency ? Don't. It sounds wrong. There is a packaging error or library naming mistake here somewhere. Can you make available the src.rpm in a working location? Or post the output of "rpm -qlvp" for both binary builds. From sct at redhat.com Tue Jun 27 13:08:51 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Tue, 27 Jun 2006 14:08:51 +0100 Subject: more Core dependency data In-Reply-To: <1151065669.26960.15.camel@ender> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> Message-ID: <1151413731.5230.13.camel@sisko.sctweedie.blueyonder.co.uk> Hi, On Fri, 2006-06-23 at 08:27 -0400, Jesse Keating wrote: > On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote: > > > xorg-x11-drv-vmmouse > Why does it matter if it is in Core or Extras? Well, is it something that would help Xen too? If so, it would definitely be good to have it as part of core. It's only 14k, after all. I know that vmware has support for USB pointers with absolute coordinates, and that has recently been added to Xen too; does this driver do anything for such devices? --Stephen From rdieter at math.unl.edu Tue Jun 27 13:12:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Jun 2006 08:12:28 -0500 Subject: devel package problem In-Reply-To: <44A12894.2080000@math.unl.edu> References: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> <44A12894.2080000@math.unl.edu> Message-ID: <44A12EBC.4030907@math.unl.edu> Rex Dieter wrote: > Chitlesh GOORAH wrote: >> I have the package katapult >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196262 >> >> rpmlint asks me to put the static libraries in -devel, which I did. >> Now I have katapult and katapult-devel >> >> during installation, I fell on >> >> root(i386)[0]$rpm -ivh katapult-* >> error: Failed dependencies: >> libkatapult.so.0 is needed by katapult-0.3.1.3-1.i386 >> libkatapultcatalog.so.0 is needed by katapult-0.3.1.3-1.i386 >> libkatapultdisplay.so.0 is needed by katapult-0.3.1.3-1.i386 >> >> the katapult package needs >> %{_libdir}/lib%{name}.so >> %{_libdir}/lib%{name}catalog.so >> %{_libdir}/lib%{name}display.so >> to install > > FYI, I think you're thinking these are static libs? They're not, but > they're not -devel-type symlinks to shared libs either. In short, put > them in the main pkg. Ignore me here. (too early, not enough coffee). Mike's comment was much closer to the mark. I commented in the bugzilla submission. -- Rex From tgl at redhat.com Tue Jun 27 13:41:34 2006 From: tgl at redhat.com (Tom Lane) Date: Tue, 27 Jun 2006 09:41:34 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> Message-ID: <12601.1151415694@sss.pgh.pa.us> Florian La Roche writes: >> I think the long term plan is to implement support for the %{?dist} >> macro set in brew. Jesse? > This would make a lot of sense to avoid changes to spec files if you > want to build across several releases. > Shouldn't we change Fedora Core and mass-apply this change to all packages? I'm having a hard time getting excited about this, and an even harder time believing that it's something that should be mass-applied. Even when an SRPM is code-wise identical across multiple branches (and at least for my packages that's the exception not the norm), the corresponding spec files are *never* identical; they have at least different changelog histories. So I have basically zero use for a dist macro. regards, tom lane From mharris at redhat.com Tue Jun 27 13:41:49 2006 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 27 Jun 2006 09:41:49 -0400 Subject: more Core dependency data In-Reply-To: <1151413731.5230.13.camel@sisko.sctweedie.blueyonder.co.uk> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> <1151413731.5230.13.camel@sisko.sctweedie.blueyonder.co.uk> Message-ID: <44A1359D.3060902@redhat.com> Stephen C. Tweedie wrote: > Hi, > > On Fri, 2006-06-23 at 08:27 -0400, Jesse Keating wrote: >> On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote: >>>> xorg-x11-drv-vmmouse > >> Why does it matter if it is in Core or Extras? > > Well, is it something that would help Xen too? If so, it would > definitely be good to have it as part of core. It's only 14k, after > all. I know that vmware has support for USB pointers with absolute > coordinates, and that has recently been added to Xen too; does this > driver do anything for such devices? I don't recall the specific improvments the driver provides to vmware, but I do remember that they claim it greatly improves mouse support when used under vmware over the "mouse" driver. Both the 'vmware' video driver and 'vmmouse' have also been available for quite some time from VMware Inc. in their vmtools package aparently. They contributed the code to X.Org ages ago, as they wanted their platforms to have out of the box OS support on par with any other non-virtual setup. If we can reuse this stuff under Xen or other technologies, that would be great. The driver sources are fairly small so you might want to pull them from CVS and see if it might also be useful for Xen too. HTH -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From chitlesh at fedoraproject.org Tue Jun 27 13:48:57 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 27 Jun 2006 15:48:57 +0200 Subject: devel package problem In-Reply-To: <20060627145424.9e36a06d.bugs.michael@gmx.net> References: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> <20060627145424.9e36a06d.bugs.michael@gmx.net> Message-ID: <13dbfe4f0606270648t45898259q86ef6f5719bb3087@mail.gmail.com> On 6/27/06, Michael Schwendt wrote: > Don't. It sounds wrong. There is a packaging error or library > naming mistake here somewhere. Can you make available the src.rpm > in a working location? Or post the output of "rpm -qlvp" for both > binary builds. > Sorry, here is a working location: http://chitlesh.ch.funpic.de/katapult/ Chitlesh(i386)[0]$su -c "rpm -Uvh katapult-0.3.1.3-3.i386.rpm " Password: error: Failed dependencies: libkatapult.so.0 is needed by katapult-0.3.1.3-3.i386 libkatapultcatalog.so.0 is needed by katapult-0.3.1.3-3.i386 libkatapultdisplay.so.0 is needed by katapult-0.3.1.3-3.i386 chitlesh(i386)[0]$rpm -qlvp katapult-0.3.1.3-3.i386.rpm -rwxr-xr-x 1 root root 101612 Jun 27 15:44 /usr/bin/katapult -rwxr-xr-x 1 root root 1262 Jun 27 15:43 /usr/lib/kde3/katapult_amarokcatalog.la -rwxr-xr-x 1 root root 60936 Jun 27 15:44 /usr/lib/kde3/katapult_amarokcatalog.so -rwxr-xr-x 1 root root 1274 Jun 27 15:42 /usr/lib/kde3/katapult_bookmarkcatalog.la -rwxr-xr-x 1 root root 61240 Jun 27 15:44 /usr/lib/kde3/katapult_bookmarkcatalog.so -rwxr-xr-x 1 root root 1286 Jun 27 15:43 /usr/lib/kde3/katapult_calculatorcatalog.la -rwxr-xr-x 1 root root 70268 Jun 27 15:44 /usr/lib/kde3/katapult_calculatorcatalog.so -rwxr-xr-x 1 root root 1274 Jun 27 15:42 /usr/lib/kde3/katapult_documentcatalog.la -rwxr-xr-x 1 root root 61232 Jun 27 15:44 /usr/lib/kde3/katapult_documentcatalog.so -rwxr-xr-x 1 root root 1168 Jun 27 15:43 /usr/lib/kde3/katapult_glassdisplay.la -rwxr-xr-x 1 root root 476112 Jun 27 15:44 /usr/lib/kde3/katapult_glassdisplay.so -rwxr-xr-x 1 root root 1268 Jun 27 15:42 /usr/lib/kde3/katapult_programcatalog.la -rwxr-xr-x 1 root root 48500 Jun 27 15:44 /usr/lib/kde3/katapult_programcatalog.so -rwxr-xr-x 1 root root 1162 Jun 27 15:43 /usr/lib/kde3/katapult_puredisplay.la -rwxr-xr-x 1 root root 576304 Jun 27 15:44 /usr/lib/kde3/katapult_puredisplay.so lrwxrwxrwx 1 root root 20 Jun 27 15:43 /usr/lib/libkatapult.so.1 -> libkatapult.so.1.0.0 -rwxr-xr-x 1 root root 15164 Jun 27 15:44 /usr/lib/libkatapult.so.1.0.0 lrwxrwxrwx 1 root root 27 Jun 27 15:43 /usr/lib/libkatapultcatalog.so.1 -> libkatapultcatalog.so.1.0.0 -rwxr-xr-x 1 root root 24076 Jun 27 15:44 /usr/lib/libkatapultcatalog.so.1.0.0 lrwxrwxrwx 1 root root 27 Jun 27 15:43 /usr/lib/libkatapultdisplay.so.1 -> libkatapultdisplay.so.1.0.0 -rwxr-xr-x 1 root root 57520 Jun 27 15:44 /usr/lib/libkatapultdisplay.so.1.0.0 -rw-r--r-- 1 root root 469 Jun 27 15:43 /usr/share/applications/fedora-katapult.desktop drwxr-xr-x 2 root root 0 Jun 27 15:44 /usr/share/doc/katapult-0.3.1.3 -rw-r--r-- 1 root root 286 Mar 23 11:52 /usr/share/doc/katapult-0.3.1.3/AUTHORS -rw-r--r-- 1 root root 18009 Mar 23 11:52 /usr/share/doc/katapult-0.3.1.3/COPYING -rw-r--r-- 1 root root 20202 Mar 23 11:52 /usr/share/doc/katapult-0.3.1.3/ChangeLog -rw-r--r-- 1 root root 1120 Mar 23 11:53 /usr/share/doc/katapult-0.3.1.3/INDEX -rw-r--r-- 1 root root 1 Mar 23 11:52 /usr/share/doc/katapult-0.3.1.3/README -rw-r--r-- 1 root root 202 Mar 23 11:52 /usr/share/doc/katapult-0.3.1.3/TODO -rw-r--r-- 1 root root 25 Mar 23 11:53 /usr/share/doc/katapult-0.3.1.3/VERSION -rw-r--r-- 1 root root 11421 Mar 23 11:52 /usr/share/icons/hicolor/128x128/actions/checkmark.png -rw-r--r-- 1 root root 11269 Mar 23 11:52 /usr/share/icons/hicolor/128x128/actions/no.png -rw-r--r-- 1 root root 10763 Mar 23 11:52 /usr/share/icons/hicolor/128x128/apps/katapult.png -rw-r--r-- 1 root root 10584 Mar 23 11:52 /usr/share/icons/hicolor/128x128/apps/xcalc.png -rw-r--r-- 1 root root 711 Mar 23 11:52 /usr/share/icons/hicolor/16x16/apps/katapult.png -rw-r--r-- 1 root root 1056 Mar 23 11:52 /usr/share/icons/hicolor/22x22/apps/katapult.png -rw-r--r-- 1 root root 1774 Mar 23 11:52 /usr/share/icons/hicolor/32x32/apps/katapult.png -rw-r--r-- 1 root root 2971 Mar 23 11:52 /usr/share/icons/hicolor/48x48/apps/katapult.png -rw-r--r-- 1 root root 4363 Mar 23 11:52 /usr/share/icons/hicolor/64x64/apps/katapult.png -rw-r--r-- 1 root root 7275 Mar 23 11:52 /usr/share/icons/hicolor/scalable/apps/katapult.svgz -rw-r--r-- 1 root root 4749 Mar 23 12:04 /usr/share/locale/bg/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 2039 Mar 23 12:04 /usr/share/locale/br/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 7637 Mar 23 12:04 /usr/share/locale/da/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 1470 Mar 23 12:04 /usr/share/locale/el/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 3924 Mar 23 12:04 /usr/share/locale/es/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 3892 Mar 23 12:04 /usr/share/locale/fr/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 2397 Mar 23 12:04 /usr/share/locale/ga/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 7990 Mar 23 12:04 /usr/share/locale/it/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 7897 Mar 23 12:04 /usr/share/locale/nl/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 3993 Mar 23 12:04 /usr/share/locale/pl/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 8136 Mar 23 12:04 /usr/share/locale/pt/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 7738 Mar 23 12:04 /usr/share/locale/sv/LC_MESSAGES/katapult.mo -rw-r--r-- 1 root root 952 Mar 23 11:52 /usr/share/services/katapult_amarokcatalog.desktop -rw-r--r-- 1 root root 964 Mar 23 11:52 /usr/share/services/katapult_bookmarkcatalog.desktop -rw-r--r-- 1 root root 1032 Mar 23 11:52 /usr/share/services/katapult_calculatorcatalog.desktop -rw-r--r-- 1 root root 953 Mar 23 11:52 /usr/share/services/katapult_documentcatalog.desktop -rw-r--r-- 1 root root 678 Mar 23 11:52 /usr/share/services/katapult_glassdisplay.desktop -rw-r--r-- 1 root root 936 Mar 23 11:52 /usr/share/services/katapult_programcatalog.desktop -rw-r--r-- 1 root root 655 Mar 23 11:52 /usr/share/services/katapult_puredisplay.desktop -rw-r--r-- 1 root root 399 Mar 23 11:52 /usr/share/servicetypes/katapultcatalog.desktop -rw-r--r-- 1 root root 401 Mar 23 11:52 /usr/share/servicetypes/katapultdisplay.desktop chitlesh(i386)[0]$rpm -qlvp katapult-devel-0.3.1.3-3.i386.rpm lrwxrwxrwx 1 root root 20 Jun 27 15:43 /usr/lib/libkatapult.so -> libkatapult.so.1.0.0 lrwxrwxrwx 1 root root 27 Jun 27 15:43 /usr/lib/libkatapultcatalog.so -> libkatapultcatalog.so.1.0.0 lrwxrwxrwx 1 root root 27 Jun 27 15:43 /usr/lib/libkatapultdisplay.so -> libkatapultdisplay.so.1.0.0 drwxr-xr-x 2 root root 0 Jun 27 15:44 /usr/share/doc/katapult-devel-0.3.1.3 -rw-r--r-- 1 root root 1 Mar 23 11:52 /usr/share/doc/katapult-devel-0.3.1.3/README Chitlesh -- http://clunixchit.blogspot.com From jkeating at j2solutions.net Tue Jun 27 14:26:41 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 27 Jun 2006 10:26:41 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <12601.1151415694@sss.pgh.pa.us> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> <12601.1151415694@sss.pgh.pa.us> Message-ID: <1151418401.28630.2.camel@ender> On Tue, 2006-06-27 at 09:41 -0400, Tom Lane wrote: > > I'm having a hard time getting excited about this, and an even harder > time believing that it's something that should be mass-applied. Even > when an SRPM is code-wise identical across multiple branches (and at > least for my packages that's the exception not the norm), the > corresponding spec files are *never* identical; they have at least > different changelog histories. So I have basically zero use for a > dist macro. > Wrong. There are many times when the changelog is EXACTLY the same across the releases. Case in point mock. I just spun a few new mock releases for FC-4, FC-5, and devel. There were packaging bugs that applied to each and every branch. Using %{?dist} I was able to fix it in devel, use %{?dist} in the changelog lines, and then copy the spec file and patch to FC-4 branch and FC-5 branch. The spec files are line for line identical. They only appear as different after being built and the %{?dist} tag is translated. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Tue Jun 27 15:01:12 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 27 Jun 2006 17:01:12 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1151411433.23849.37.camel@ender> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> <1151411433.23849.37.camel@ender> Message-ID: <20060627170112.2875e97d.bugs.michael@gmx.net> On Tue, 27 Jun 2006 08:30:33 -0400, Jesse Keating wrote: > On Tue, 2006-06-27 at 14:08 +0200, Florian La Roche wrote: > > Shouldn't we change Fedora Core and mass-apply this change to all > > packages? > > See my other email. I'll be adding support for %{?dist}, but ensuring > upgrade path will be fun. Is not FC5 considered newer than fc5 ? So > we'll have to do some fiddling with the packages. It's the opposite. Small 'f' is higher than big 'F'. fc4 is newer than FC5. And all numbers 0-9 are higher than a-z and A-Z. From sct at redhat.com Tue Jun 27 17:35:59 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Tue, 27 Jun 2006 18:35:59 +0100 Subject: more Core dependency data In-Reply-To: <44A1359D.3060902@redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <1151065669.26960.15.camel@ender> <1151413731.5230.13.camel@sisko.sctweedie.blueyonder.co.uk> <44A1359D.3060902@redhat.com> Message-ID: <1151429759.5230.23.camel@sisko.sctweedie.blueyonder.co.uk> Hi, On Tue, 2006-06-27 at 09:41 -0400, Mike A. Harris wrote: > I don't recall the specific improvments the driver provides to > vmware, but I do remember that they claim it greatly improves mouse > support when used under vmware over the "mouse" driver. Both > the 'vmware' video driver and 'vmmouse' have also been available > for quite some time from VMware Inc. in their vmtools package > aparently. They contributed the code to X.Org ages ago, as they > wanted their platforms to have out of the box OS support on par > with any other non-virtual setup. If we can reuse this stuff under > Xen or other technologies, that would be great. Doesn't look like it's immediately useful to Xen --- it provides a client, but no server, and the protocol it uses isn't a standard one that's provided by the Xen device model. --Stephen From dwmw2 at infradead.org Tue Jun 27 22:47:12 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 27 Jun 2006 23:47:12 +0100 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <1151448432.6394.300.camel@pmac.infradead.org> On Mon, 2006-06-12 at 17:48 -0400, Bill Nottingham wrote: > Running some dependency analysis on Core yielded a few packages > in the following groups. This isn't exhaustive, by any means; there > are still quite a few leaf nodes that are potential Extras candidates. There's no excuse for Postfix being in core, is there? It duplicates basic functionality which is provided by sendmail. -- dwmw2 From nicolas.mailhot at laposte.net Tue Jun 27 23:04:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Jun 2006 01:04:06 +0200 Subject: some minor Core pruning In-Reply-To: <1151448432.6394.300.camel@pmac.infradead.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> Message-ID: <1151449446.28409.1.camel@rousalka.dyndns.org> Le mardi 27 juin 2006 ? 23:47 +0100, David Woodhouse a ?crit : > On Mon, 2006-06-12 at 17:48 -0400, Bill Nottingham wrote: > > Running some dependency analysis on Core yielded a few packages > > in the following groups. This isn't exhaustive, by any means; there > > are still quite a few leaf nodes that are potential Extras candidates. > > There's no excuse for Postfix being in core, is there? It duplicates > basic functionality which is provided by sendmail. I didn't know you were doing bidi in english now. The usual sentence order would read "There's no excuse for Sendmail being in core, is there? It duplicates basic functionality which is provided by Postfix." Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwmw2 at infradead.org Tue Jun 27 23:24:54 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 28 Jun 2006 00:24:54 +0100 Subject: some minor Core pruning In-Reply-To: <1151449446.28409.1.camel@rousalka.dyndns.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> Message-ID: <1151450694.6394.310.camel@pmac.infradead.org> On Wed, 2006-06-28 at 01:04 +0200, Nicolas Mailhot wrote: > I didn't know you were doing bidi in english now. > The usual sentence order would read > > "There's no excuse for Sendmail being in core, is there? It duplicates > basic functionality which is provided by Postfix." No, because sendmail is the default -- although perhaps it _shouldn't_ be. The default MTA should be included in Core, and the others should be in Extras unless they provide functionality which isn't available from the default MTA. Actually, the default probably ought to be Exim -- Debian and Ubuntu have got this right. And even if Exim isn't the default, it should be in Core -- it provides a lot of functionality that neither postfix nor sendmail can manage. But that's a separate question -- let's start by at least being consistent. -- dwmw2 From michael at knox.net.nz Tue Jun 27 23:46:36 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 28 Jun 2006 11:46:36 +1200 Subject: some minor Core pruning In-Reply-To: <1151450694.6394.310.camel@pmac.infradead.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> Message-ID: <44A1C35C.20404@knox.net.nz> David Woodhouse wrote: [snip] > The default MTA should be included in Core, and the others should be in > Extras unless they provide functionality which isn't available from the > default MTA. [snip] +1 on that reasoning. However, the road to a concluse agreement on which app to provide the said functionality in core, I doubt, will be easy :) But then again... does it really matter? The goal is to have the lines between FE and FC to be pretty much transparent for the end user, so when I build a server and install postfix if it comes from FE instead of FC I couldn't care Michael From jwboyer at jdub.homelinux.org Wed Jun 28 00:29:27 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Jun 2006 19:29:27 -0500 Subject: some minor Core pruning In-Reply-To: <44A1C35C.20404@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> Message-ID: <1151454567.12474.4.camel@vader.jdub.homelinux.org> On Wed, 2006-06-28 at 11:46 +1200, Michael J. Knox wrote: > David Woodhouse wrote: > [snip] > > > The default MTA should be included in Core, and the others should be in > > Extras unless they provide functionality which isn't available from the > > default MTA. > > [snip] > > +1 on that reasoning. However, the road to a concluse agreement on which > app to provide the said functionality in core, I doubt, will be easy :) > > But then again... does it really matter? The goal is to have the lines > between FE and FC to be pretty much transparent for the end user, so > when I build a server and install postfix if it comes from FE instead of > FC I couldn't care Until Extras has .isos at release time lots of people will care. Arguably, that would also be part of the FC<->FE merge but I won't dare make a statement about that. Btw, I personally could care less about .isos. But my views probably don't represent the majority of users. josh From alan at redhat.com Wed Jun 28 01:17:19 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jun 2006 21:17:19 -0400 Subject: some minor Core pruning In-Reply-To: <1151449446.28409.1.camel@rousalka.dyndns.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> Message-ID: <20060628011719.GA3240@devserv.devel.redhat.com> On Wed, Jun 28, 2006 at 01:04:06AM +0200, Nicolas Mailhot wrote: > "There's no excuse for Sendmail being in core, is there? It duplicates > basic functionality which is provided by Postfix." Not in the real world. Sendmail is the expected norm. Its like buying a car and finding it comes with wheels. Tracks may offer more functionality, hovercraft may offer more excitement, but the default expectation is wheels. Ditto sendmail as mail server. We have a lot of "best of breed" stuff in Extras precisely because its not the expected norm. Thus joe is in extras and vi is in core. Alan From tgl at redhat.com Wed Jun 28 04:00:20 2006 From: tgl at redhat.com (Tom Lane) Date: Wed, 28 Jun 2006 00:00:20 -0400 Subject: some minor Core pruning In-Reply-To: <1151449446.28409.1.camel@rousalka.dyndns.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> Message-ID: <11262.1151467220@sss.pgh.pa.us> Nicolas Mailhot writes: >> There's no excuse for Postfix being in core, is there? It duplicates >> basic functionality which is provided by sendmail. > I didn't know you were doing bidi in english now. > The usual sentence order would read > "There's no excuse for Sendmail being in core, is there? It duplicates > basic functionality which is provided by Postfix." And then there's emacs vs vi (resp. your-emacs-clone vs my-vi-clone) postgres vs mysql your-web-browser vs my-web-browser yadda yadda yadda. You have to leave some room for personal preference. If any one of these projects were clearly superior to their competitors by every measure, the competitors would be dead. They aren't, and they aren't. I think Fedora Core can afford to prefer "best of breed" projects for inclusion, but that is not the same as saying "there can be only one". That way leads to pissing off a lot of people you shouldn't have pissed off ... regards, tom lane From deisenst at gtw.net Wed Jun 28 05:43:07 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 28 Jun 2006 00:43:07 -0500 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <44A1C35C.20404@knox.net.nz> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> Message-ID: <44A216EB.2020400@gtw.net> Michael J. Knox wrote: > David Woodhouse wrote: > [snip] > >> The default MTA should be included in Core, and the others should be in >> Extras unless they provide functionality which isn't available from the >> default MTA. > > > [snip] > > +1 on that reasoning. However, the road to a concluse agreement on which > app to provide the said functionality in core, I doubt, will be easy :) > > But then again... does it really matter? The goal is to have the lines > between FE and FC to be pretty much transparent for the end user, so > when I build a server and install postfix if it comes from FE instead of > FC I couldn't care I have a problem with this so-called "goal" to have the lines between Fedora Extras and Fedora Core become pretty much transparent for the end user. If this is a goal, I am not seeing us going about it in a compre- hensive way. What end-user(s) are we talking about here? Some folks do not have broadband Internet connections. They have dialup internet of 40 kbps download speed at best. Some users may not even have *any* network connection. How, then, is Fedora Extras useful to them, unless it, too, is packaged somehow on physical media alongside Core? Does Fedora have that as a goal? Further -- I see much glibness about saying, "Throw this over to extras. Throw that over to extras. Extras can take care of it." I understand there appears to be some community-wide consensus that it is a "Good Thing"?? to reduce the size of Fedora Core. (I am afraid I don't know Mr. Extras - can he handle all these new packages?) But I thought that The Fedora Project was about creating value (and perhaps attractiveness) to the end-users. What kind of end-user polling or testing is being consulted here to come up with these decisions as to what the end-users want and need and don't want in Core? I am seeing lots of programmers weighing in on the decision-making processes (of what goes and what stays, for example), but I am not seeing the evidence of any kind of end-user polling, Usability Testing or other metrics being sought nor applied. In the back of my mind, I'm beginning to call Fedora a "Programmer- friendly" distribution. Who needs users? Regards, David Eisenstein From blizzard at redhat.com Wed Jun 28 08:52:40 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Jun 2006 04:52:40 -0400 Subject: some minor Core pruning In-Reply-To: <1151448432.6394.300.camel@pmac.infradead.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> Message-ID: <44A24358.5000008@redhat.com> David Woodhouse wrote: > On Mon, 2006-06-12 at 17:48 -0400, Bill Nottingham wrote: >> Running some dependency analysis on Core yielded a few packages >> in the following groups. This isn't exhaustive, by any means; there >> are still quite a few leaf nodes that are potential Extras candidates. > > There's no excuse for Postfix being in core, is there? It duplicates > basic functionality which is provided by sendmail. > I can't believe you guys took David's bait! :) --Chris From bugs.michael at gmx.net Wed Jun 28 11:29:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Jun 2006 13:29:42 +0200 Subject: devel package problem In-Reply-To: <13dbfe4f0606270648t45898259q86ef6f5719bb3087@mail.gmail.com> References: <13dbfe4f0606270510s25ffcfcajf4d74e2e073a2dd7@mail.gmail.com> <20060627145424.9e36a06d.bugs.michael@gmx.net> <13dbfe4f0606270648t45898259q86ef6f5719bb3087@mail.gmail.com> Message-ID: <20060628132942.51eb9653.bugs.michael@gmx.net> On Tue, 27 Jun 2006 15:48:57 +0200, Chitlesh GOORAH wrote: > On 6/27/06, Michael Schwendt wrote: > > Don't. It sounds wrong. There is a packaging error or library > > naming mistake here somewhere. Can you make available the src.rpm > > in a working location? Or post the output of "rpm -qlvp" for both > > binary builds. > > > > Sorry, here is a working location: > http://chitlesh.ch.funpic.de/katapult/ Okay, thanks. First of all, the package didn't build because it's missing to source /etc/profile.d/qt.sh and hence failed to find Qt: %build unset QTDIR || : ; . /etc/profile.d/qt.sh export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include ... The package needs more work, since the katapult-devel package is not needed. It includes files which are not needed. > Chitlesh(i386)[0]$su -c "rpm -Uvh katapult-0.3.1.3-3.i386.rpm " > Password: > error: Failed dependencies: > libkatapult.so.0 is needed by katapult-0.3.1.3-3.i386 > libkatapultcatalog.so.0 is needed by katapult-0.3.1.3-3.i386 > libkatapultdisplay.so.0 is needed by katapult-0.3.1.3-3.i386 Cannot confirm (FC5). $ rpm -qpR /home/misc5/tmp/rpm/RPMS/katapult-0.3.1.3-3.i386.rpm | grep kata.*so libkatapult.so.1 libkatapultcatalog.so.1 libkatapultdisplay.so.1 When building your package, did you have old katapult libraries installed, which were linked against instead of the included ones? I see a bad -L/usr/lib in the build log. From fedora at camperquake.de Wed Jun 28 11:55:07 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 28 Jun 2006 13:55:07 +0200 Subject: some minor Core pruning In-Reply-To: <20060628011719.GA3240@devserv.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> Message-ID: <20060628135507.044e0ba1@voip.int.addix.net> Hi. On Tue, 27 Jun 2006 21:17:19 -0400, Alan Cox wrote: > Not in the real world. > > Sendmail is the expected norm. Norm for what? /usr/sbin/sendmail is there for all major mail servers, and it behaves just the same in all cases normal userspace programs care about. Hell, the usual "desktop user" case does not need a mailserver at all on the local machine, since noone reads mail sent to root at localhost.localdomain, anyways. From jkeating at redhat.com Wed Jun 28 11:59:06 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Jun 2006 07:59:06 -0400 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <44A216EB.2020400@gtw.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <44A1C35C.20404@knox.net.nz> <44A216EB.2020400@gtw.net> Message-ID: <200606280759.10068.jkeating@redhat.com> On Wednesday 28 June 2006 01:43, David Eisenstein wrote: > Some folks do not have broadband Internet connections. ?They have dialup > internet of 40 kbps download speed at best. ?Some users may not even have > *any* network connection. ?How, then, is Fedora Extras useful to them, > unless it, too, is packaged somehow on physical media alongside Core? ?Does > Fedora have that as a goal? Yes we have such a goal. Even without moving everything from Core to Extras, one of the big goals we have is to create tools so that anybody can take a collection of packages (could be from core, could be from extras) and easily produce an iso set out of them, and have the legal right to call it Fedora. This allows users to create a Fedora Gnome Edition or a Fedora KDE edition, or a Fedora Server Edition or any number of different ways of putting packages together. Red Hat will most likely choose one collection to put out there, anybody else can make other collections. They all would use the universe of packages for updates source, they would all use anaconda, etc, etc.. We deeply care about folks with low bandwidth or no bandwidth, and any major plan to shake up how we do things will have these folks in mind so that we can continue delivering a quality distribution to them. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed Jun 28 12:10:53 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Jun 2006 07:10:53 -0500 Subject: some minor Core pruning In-Reply-To: <20060628135507.044e0ba1@voip.int.addix.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> Message-ID: <1151496653.22623.12.camel@weaponx.rchland.ibm.com> On Wed, 2006-06-28 at 13:55 +0200, Ralf Ertzinger wrote: > Hi. > > On Tue, 27 Jun 2006 21:17:19 -0400, Alan Cox wrote: > > > Not in the real world. > > > > Sendmail is the expected norm. > > Norm for what? /usr/sbin/sendmail is there for all major mail servers, > and it behaves just the same in all cases normal userspace > programs care about. Hell, the usual "desktop user" case does not > need a mailserver at all on the local machine, since noone reads > mail sent to root at localhost.localdomain, anyways. I do. Be careful with assumptions and abstractions. :) josh From alan at redhat.com Wed Jun 28 14:07:22 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jun 2006 10:07:22 -0400 Subject: some minor Core pruning In-Reply-To: <20060628135507.044e0ba1@voip.int.addix.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> Message-ID: <20060628140722.GA22290@devserv.devel.redhat.com> On Wed, Jun 28, 2006 at 01:55:07PM +0200, Ralf Ertzinger wrote: > > Sendmail is the expected norm. > > Norm for what? /usr/sbin/sendmail is there for all major mail servers, Normfor a unix like OS install. Its the one the books cover by default, its the one other vendors ship by default From skvidal at linux.duke.edu Wed Jun 28 14:14:10 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 28 Jun 2006 10:14:10 -0400 Subject: some minor Core pruning In-Reply-To: <20060628140722.GA22290@devserv.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <20060628140722.GA22290@devserv.devel.redhat.com> Message-ID: <1151504051.29430.16.camel@cutter> On Wed, 2006-06-28 at 10:07 -0400, Alan Cox wrote: > On Wed, Jun 28, 2006 at 01:55:07PM +0200, Ralf Ertzinger wrote: > > > Sendmail is the expected norm. > > > > Norm for what? /usr/sbin/sendmail is there for all major mail servers, > > Normfor a unix like OS install. Its the one the books cover by default, its > the one other vendors ship by default > But we're supposed to be better than the other vendors, right? Seriously, can we stop this discussion - it won't change much and we'd be better off spending time sorting out how to make the isos for everyone from anywhere. :) then you can put what YOU want on YOUR isos of fedora. -sv From dwmw2 at infradead.org Wed Jun 28 14:10:35 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 28 Jun 2006 15:10:35 +0100 Subject: some minor Core pruning In-Reply-To: <1151496653.22623.12.camel@weaponx.rchland.ibm.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <1151496653.22623.12.camel@weaponx.rchland.ibm.com> Message-ID: <1151503835.17134.30.camel@pmac.infradead.org> On Wed, 2006-06-28 at 07:10 -0500, Josh Boyer wrote: > > Norm for what? /usr/sbin/sendmail is there for all major mail servers, > > and it behaves just the same in all cases normal userspace > > programs care about. Hell, the usual "desktop user" case does not > > need a mailserver at all on the local machine, since noone reads > > mail sent to root at localhost.localdomain, anyways. > > I do. Be careful with assumptions and abstractions. :) We're talking about _defaults_ though, so it's not entirely unreasonable to make such generalisations. According to your Received: headers, Fedora's defaults have already failed you -- you've already installed Exim from Extras, and presumably removed sendmail. Would it really matter to you if it were been some simple outgoing-only relay tool that you'd had to remove, instead of sendmail? My point is that if we're going to pretend to be rational and consistent, there should be _one_ package providing /usr/lib/sendmail in Core, and those other than the default should be in Extras. Currently the default is sendmail, which means postfix should be moved to Extras. Whether the default _should_ be sendmail is a separate question. There are arguments for it being sendmail purely because that's 'expected', which sound to me much like the arguments that computers should come with Windows because that's 'expected'. There are arguments for it being a simple relay which can only handle outgoing mail and no local delivery -- even mail to root@ can be set up to forward to a real email address elsewhere. You're right that that wouldn't serve everyone -- but the GNOME folks have made far _worse_ generalisations on Fedora's behalf, and at least this is one decision that we can override for ourselves just installing a proper MTA. There are arguments for it being Exim, which is capable of acting as simple outgoing relay and is _also_ capable of much more; spam checking, antivirus, greylisting, etc. -- all without third-party software (other than SA and ClamAV themselves). I think that's probably the best choice -- it's easy to configure, well documented, more functional than any of the alternatives, and has a good security record. It also has complete and _mature_ support for IPv6, unlike postfix which was recently observed to be bouncing mail for domains with IPv6-only primary MX. I'm sure someone can contrive some kind of spurious argument for it being postfix, too -- despite that fact that postfix doesn't match Exim in functionality and doesn't match either Sendmail or Exim in ubiquity?. -- dwmw2 ? http://www.securityspace.com/s_survey/data/man.200605/mxsurvey.html From dwmw2 at infradead.org Wed Jun 28 14:14:46 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 28 Jun 2006 15:14:46 +0100 Subject: some minor Core pruning In-Reply-To: <20060628140722.GA22290@devserv.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <20060628140722.GA22290@devserv.devel.redhat.com> Message-ID: <1151504086.17134.34.camel@pmac.infradead.org> On Wed, 2006-06-28 at 10:07 -0400, Alan Cox wrote: > Normfor a unix like OS install. Its the one the books cover by default, its > the one other vendors ship by default Debian and Ubuntu don't -- they ship Exim, which is a far better choice. But _questioning_ the default wasn't really the point of starting this discussion. The point was to point out that Postfix has no business being in Core since it _isn't_ the default, and it should be moved to Extras. -- dwmw2 From tmraz at redhat.com Wed Jun 28 14:26:22 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 28 Jun 2006 16:26:22 +0200 Subject: more Core dependency data In-Reply-To: <1151059787.2309.16.camel@localhost.localdomain> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <1150180333.3662.12.camel@localhost.localdomain> <20060613121126.GA24394@jadzia.bu.edu> <449B9319.5060108@mharris.ca> <1151059787.2309.16.camel@localhost.localdomain> Message-ID: <1151504782.3601.25.camel@perun.kabelta.loc> On Fri, 2006-06-23 at 12:49 +0200, Jindrich Novy wrote: > On Fri, 2006-06-23 at 03:07 -0400, Mike A. Harris wrote: > > > > Please keep mc in Core for sysadmins and developer types. > > The question was whether to move hexedit to Extras. I'm absolutely sure > mc belongs to Core and I would defend it pretty hardly to let it stay > there ;) +1 -- Tomas Mraz From sundaram at fedoraproject.org Wed Jun 28 15:34:54 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Jun 2006 21:04:54 +0530 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <44A216EB.2020400@gtw.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> <44A216EB.2020400@gtw.net> Message-ID: <44A2A19E.9000004@fedoraproject.org> David Eisenstein wrote: >Michael J. Knox wrote: > > >>David Woodhouse wrote: >>[snip] >> >> >> >>>The default MTA should be included in Core, and the others should be in >>>Extras unless they provide functionality which isn't available from the >>>default MTA. >>> >>> >>[snip] >> >>+1 on that reasoning. However, the road to a concluse agreement on which >>app to provide the said functionality in core, I doubt, will be easy :) >> >>But then again... does it really matter? The goal is to have the lines >>between FE and FC to be pretty much transparent for the end user, so >>when I build a server and install postfix if it comes from FE instead of >>FC I couldn't care >> >> > >I have a problem with this so-called "goal" to have the lines between >Fedora Extras and Fedora Core become pretty much transparent for the end >user. If this is a goal, I am not seeing us going about it in a compre- >hensive way. > >What end-user(s) are we talking about here? > >Some folks do not have broadband Internet connections. They have dialup >internet of 40 kbps download speed at best. Some users may not even have >*any* network connection. How, then, is Fedora Extras useful to them, >unless it, too, is packaged somehow on physical media alongside Core? Does >Fedora have that as a goal? > > Did you see the already existing threads on this? Yes - Fedora Extras on media is a goal. >Further -- I see much glibness about saying, "Throw this over to extras. >Throw that over to extras. Extras can take care of it." I understand >there appears to be some community-wide consensus that it is a "Good >Thing"?? to reduce the size of Fedora Core. (I am afraid I don't know >Mr. Extras - can he handle all these new packages?) > > Thats because its not Mr.Extras. Its a team of people who have already committed themselves to maintaining these packages. If noone else is interested enough to maintain it, that package wouldnt be in the repository. >But I thought that The Fedora Project was about creating value (and perhaps >attractiveness) to the end-users. What kind of end-user polling or testing >is being consulted here to come up with these decisions as to what the >end-users want and need and don't want in Core? I am seeing lots of >programmers weighing in on the decision-making processes (of what goes and >what stays, for example), but I am not seeing the evidence of any kind of >end-user polling, Usability Testing or other metrics being sought nor applied. > >In the back of my mind, I'm beginning to call Fedora a "Programmer- >friendly" distribution. > >Who needs users? > We dont need to do usability testing to decide such simple things and users have already expressed clearly what they want. The different variables are already well known. An example is outlined in http://fedoraproject.org/wiki/UnleashKDE -- Rahul From steve at kspei.com Wed Jun 28 15:00:57 2006 From: steve at kspei.com (Steven Pritchard) Date: Wed, 28 Jun 2006 10:00:57 -0500 Subject: some minor Core pruning In-Reply-To: <1151504086.17134.34.camel@pmac.infradead.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <20060628140722.GA22290@devserv.devel.redhat.com> <1151504086.17134.34.camel@pmac.infradead.org> Message-ID: <20060628150057.GA16938@osiris.silug.org> On Wed, Jun 28, 2006 at 03:14:46PM +0100, David Woodhouse wrote: > The point was to point out that Postfix has no business being in Core > since it _isn't_ the default, and it should be moved to Extras. As a Postfix user, I'm completely fine with that. All of my servers running Postfix already need amavisd-new and clamav from Extras anyway... 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 dennis at ausil.us Wed Jun 28 15:47:23 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Jun 2006 10:47:23 -0500 (CDT) Subject: some minor Core pruning In-Reply-To: <1151503835.17134.30.camel@pmac.infradead.org> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <1151496653.22623.12.camel@weaponx.rchland.ibm.com> <1151503835.17134.30.camel@pmac.infradead.org> Message-ID: <34731.68.254.239.133.1151509643.squirrel@webmail.ausil.us> > On Wed, 2006-06-28 at 07:10 -0500, Josh Boyer wrote: > There are arguments for it being Exim, which is capable of acting as > simple outgoing relay and is _also_ capable of much more; spam checking, > antivirus, greylisting, etc. -- all without third-party software (other > than SA and ClamAV themselves). I think that's probably the best choice > -- it's easy to configure, well documented, more functional than any of > the alternatives, and has a good security record. It also has complete > and _mature_ support for IPv6, unlike postfix which was recently > observed to be bouncing mail for domains with IPv6-only primary MX. postfix 2.2 added a config option for /etc/postfix/main.cf inet_protocols with the default being ipv4 only so i would have a guess that postfix was not configured correctly https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197105 filled a bug requesting change in default config Dennis From dwmw2 at infradead.org Wed Jun 28 16:04:36 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 28 Jun 2006 17:04:36 +0100 Subject: some minor Core pruning In-Reply-To: <34731.68.254.239.133.1151509643.squirrel@webmail.ausil.us> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <1151496653.22623.12.camel@weaponx.rchland.ibm.com> <1151503835.17134.30.camel@pmac.infradead.org> <34731.68.254.239.133.1151509643.squirrel@webmail.ausil.us> Message-ID: <1151510676.18130.24.camel@pmac.infradead.org> On Wed, 2006-06-28 at 10:47 -0500, Dennis Gilmore wrote: > postfix 2.2 added a config option for /etc/postfix/main.cf > > inet_protocols > > with the default being ipv4 only so i would have a guess that postfix was > not configured correctly No, it was a bug -- the system in question didn't actually have IPv6 addresses configured and it was failing to deliver mail to infradead.org, claiming (IIRC) that the highest priority MX host was the local host. I believe the diagnosis was that it interpreted the IPv6-only primary MX host 'phoenix.ipv6.infradead.org' as if it were the Legacy IP address 0.0.0.0 -- then claimed that it was a local address, and hence the mail was undeliverable since infradead.org was obviously not configured as a local domain on that machine. -- dwmw2 From nicolas.mailhot at laposte.net Wed Jun 28 17:30:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Jun 2006 19:30:34 +0200 Subject: some minor Core pruning In-Reply-To: <20060628140722.GA22290@devserv.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <20060628011719.GA3240@devserv.devel.redhat.com> <20060628135507.044e0ba1@voip.int.addix.net> <20060628140722.GA22290@devserv.devel.redhat.com> Message-ID: <1151515834.17910.8.camel@rousalka.dyndns.org> Le mercredi 28 juin 2006 ? 10:07 -0400, Alan Cox a ?crit : > On Wed, Jun 28, 2006 at 01:55:07PM +0200, Ralf Ertzinger wrote: > > > Sendmail is the expected norm. > > > > Norm for what? /usr/sbin/sendmail is there for all major mail servers, > > Normfor a unix like OS install. Its the one the books cover by default, its > the one other vendors ship by default Actually, when the sendmail people announced they were rewriting sendmail from scratch, it woke up even PHBs. Even when they don't know tech they realise a full rewrite means deep trouble in the codebase. So today you have : - small non-critical MTAs : will use whatever is bundled with the OS - bigger/more critical projects -> these days it's not sendmail but one of its alternatives (which one comes first vary) - very uncommon deployments which need sendmail high-end features -> will use sendmail (but I doubt they run Fedora anyway) I work in a big corp which is very conservative and is usually lagging a few years behind the IT market, and even it dumped sendmail several years ago for its corporate-level MTA infrastructure. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Wed Jun 28 20:18:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Jun 2006 16:18:01 -0400 Subject: Red Hat's build system now supports %{?dist} Message-ID: <1151525881.29387.30.camel@dhcp83-49.boston.redhat.com> As of about 20 minutes ago, the Red Hat build system now supports %{?dist} tags. This should make it easier for packages to come from Extras into Core and should help Core get much more consistent with package release naming. Now would be a good time, Core Maintainers, to look through your packages and if you're using something like 'FC5' or 'Fc5' or any other such thing to convert your package to use the %{?dist} tag as explained here: http://fedoraproject.org/wiki/DistTag and here http://fedoraproject.org/wiki/Packaging/NamingGuidelines Fairly soon, we should start filing bugs for packages that do not follow the guideline for release naming. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Jun 28 21:23:46 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 28 Jun 2006 16:23:46 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <12601.1151415694@sss.pgh.pa.us> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <44A074F2.5010009@mharris.ca> <1151409659.28942.11.camel@localhost.localdomain> <20060627120800.GA6482@dudweiler.stuttgart.redhat.com> <12601.1151415694@sss.pgh.pa.us> Message-ID: <1151529827.17972.41.camel@localhost.localdomain> On Tue, 2006-06-27 at 09:41 -0400, Tom Lane wrote: > Florian La Roche writes: > >> I think the long term plan is to implement support for the %{?dist} > >> macro set in brew. Jesse? > > > This would make a lot of sense to avoid changes to spec files if you > > want to build across several releases. > > Shouldn't we change Fedora Core and mass-apply this change to all packages? > > I'm having a hard time getting excited about this, and an even harder > time believing that it's something that should be mass-applied. Even > when an SRPM is code-wise identical across multiple branches (and at > least for my packages that's the exception not the norm), the > corresponding spec files are *never* identical; they have at least > different changelog histories. So I have basically zero use for a > dist macro. This is one of the reasons why using the dist macro(s) is not currently mandatory. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From notting at redhat.com Wed Jun 28 23:14:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jun 2006 19:14:16 -0400 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <44A216EB.2020400@gtw.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> <44A216EB.2020400@gtw.net> Message-ID: <20060628231416.GC2612@nostromo.devel.redhat.com> David Eisenstein (deisenst at gtw.net) said: > Further -- I see much glibness about saying, "Throw this over to extras. > Throw that over to extras. Extras can take care of it." I understand > there appears to be some community-wide consensus that it is a "Good > Thing"?? to reduce the size of Fedora Core. (I am afraid I don't know > Mr. Extras - can he handle all these new packages?) Look over the list of packages provided. It's all packages with no dependencies, either runtime or buildtime. Most of said packages are libraries. I see no motiviation for Core to provide libraries that aren't actually *used*; there is really no way that that benefits users. Bill From notting at redhat.com Wed Jun 28 23:16:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jun 2006 19:16:37 -0400 Subject: more Core dependency data In-Reply-To: <449B91AF.3070604@mharris.ca> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> Message-ID: <20060628231637.GD2612@nostromo.devel.redhat.com> Mike A. Harris (mharris at mharris.ca) said: > >xorg-x11-xdm ... > A more important reason to keep it in Core however, is that it > contains various config files and scripts which are also shared > with gdm and kdm. We could split those files into yet another > package, but then we have to manually resync them with upstream > xdm any time upstream changes them - which creates more work for > no real big gains. If there are scripts here, it would perhaps beehove KDM or GDM to require XDM. :) Bill From notting at redhat.com Wed Jun 28 23:17:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jun 2006 19:17:15 -0400 Subject: more Core dependency data In-Reply-To: <449BD8E7.2050400@math.unl.edu> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <449BD796.6050201@math.unl.edu> <449BD8E7.2050400@math.unl.edu> Message-ID: <20060628231715.GE2612@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > The reason for their not showing up as dependencies is because kdebase > atm uses *file* dependences not rpm/pkg ones: > Requires: /etc/X11/xdm/Xaccess > Requires: /etc/X11/xdm/Xservers > Requires: /etc/X11/xdm/Xwilling > Requires: /etc/X11/xinit/Xsession > Requires: /etc/X11/xdm/Xsetup_0 Aha. repoquery does not appear to show these deps correctly. Bill From deisenst at gtw.net Wed Jun 28 23:44:05 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 28 Jun 2006 18:44:05 -0500 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <20060628231416.GC2612@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> <44A216EB.2020400@gtw.net> <20060628231416.GC2612@nostromo.devel.redhat.com> Message-ID: <44A31445.40808@gtw.net> Bill Nottingham wrote: > David Eisenstein (deisenst at gtw.net) said: > >>Further -- I see much glibness about saying, "Throw this over to extras. >>Throw that over to extras. Extras can take care of it." I understand >>there appears to be some community-wide consensus that it is a "Good >>Thing"?? to reduce the size of Fedora Core. (I am afraid I don't know >>Mr. Extras - can he handle all these new packages?) > > > Look over the list of packages provided. It's all packages with no > dependencies, either runtime or buildtime. Most of said packages are > libraries. I see no motiviation for Core to provide libraries that > aren't actually *used*; there is really no way that that benefits > users. > > Bill I apologize, Bill, and to all of you, for my rather harsh words. The glibness is mine, not yours. Sorry. Dumb question: Where exactly do I find the list of packages provided? One thing that does concern me some is: What of people who, say, have been using Fedora Core since the olden days, and who have custom or proprietary applications on their computers that may require some of these older deprecated libraries that upgrading to a newer Core will no longer provide? Even though *current* applications in Core (or Extras?) no longer use such libraries, it can still affect these users who may wish to upgrade to newer releases of Core. For some, altering their sources to work with a newer supported library may not be an option. Please bear in mind that these thoughts come from a Legacy standpoint, as Fedora Legacy has been my main contribution to the Fedora Project: So keeping older things running has been my focus so far, not running the latest and greatest. (What was that SELinux thing again? ;-) ) The plan then is to let Fedora Extras contributors take over these library packages to continue maintaining them for new Core releases, right? If no one steps forward then to maintain these packages, do they then become orphaned/unmaintained or even unavailable? Thanks for your patience with me. Warm regards, David Eisenstein From kwade at redhat.com Wed Jun 28 23:44:18 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 28 Jun 2006 16:44:18 -0700 Subject: relnotes content for test2 freeze 03 July Message-ID: <1151538259.2489.687.camel@erato.phig.org> http://fedoraproject.org/wiki/Docs/Beats We're taking a snapshot for translation on 03 July. Test1 had a placeholder, empty set of notes. Ugly. Let's rectify this, please. For how-to information: http://fedoraproject.org/wiki/Docs/Beats/HowTo http://fedoraproject.org/wiki/DocsProject/WritingUsingTheWiki Please forward this to your own project lists. There are too many of you all for me to keep track of anymore. :) Thanks - Karsten (cross-posted to f-devel-l and f-maintainers, separately posted to internal devel list) -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Jun 29 00:00:09 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jun 2006 20:00:09 -0400 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <44A31445.40808@gtw.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> <44A216EB.2020400@gtw.net> <20060628231416.GC2612@nostromo.devel.redhat.com> <44A31445.40808@gtw.net> Message-ID: <20060629000009.GI2612@nostromo.devel.redhat.com> David Eisenstein (deisenst at gtw.net) said: > I apologize, Bill, and to all of you, for my rather harsh words. The > glibness is mine, not yours. Sorry. > > Dumb question: Where exactly do I find the list of packages provided? I assume you were talking about the list of proposed packaged for pruning that was in the original mail of this thread. If not, my apologies. > One thing that does concern me some is: What of people who, say, have been > using Fedora Core since the olden days, and who have custom or proprietary > applications on their computers that may require some of these older > deprecated libraries that upgrading to a newer Core will no longer provide? The old version sticks around on upgrade... > The plan then is to let Fedora Extras contributors take over these library > packages to continue maintaining them for new Core releases, right? If no > one steps forward then to maintain these packages, do they then become > orphaned/unmaintained or even unavailable? I would suspect so, much like any other Fedora Extras package that is given up by the maintainer. Bill From pmatilai at laiskiainen.org Thu Jun 29 09:57:41 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 29 Jun 2006 12:57:41 +0300 Subject: more Core dependency data In-Reply-To: <20060628231715.GE2612@nostromo.devel.redhat.com> References: <20060613035433.GA32114@nostromo.devel.redhat.com> <449B91AF.3070604@mharris.ca> <449BD796.6050201@math.unl.edu> <449BD8E7.2050400@math.unl.edu> <20060628231715.GE2612@nostromo.devel.redhat.com> Message-ID: <1151575061.2760.42.camel@weasel.turre.laiskiainen.org> On Wed, 2006-06-28 at 19:17 -0400, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > The reason for their not showing up as dependencies is because kdebase > > atm uses *file* dependences not rpm/pkg ones: > > Requires: /etc/X11/xdm/Xaccess > > Requires: /etc/X11/xdm/Xservers > > Requires: /etc/X11/xdm/Xwilling > > Requires: /etc/X11/xinit/Xsession > > Requires: /etc/X11/xdm/Xsetup_0 > > Aha. repoquery does not appear to show these deps correctly. Ah, indeed. Fixed in CVS head and patch attached (against yum-utils 0.6 repoquery but applies to cvs head as well) - Panu - -------------- next part -------------- A non-text attachment was scrubbed... Name: repoquery-filedeps.patch Type: text/x-patch Size: 1736 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Jun 29 13:59:32 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Jun 2006 19:29:32 +0530 Subject: The Fedora Core Pruning project, Re: some minor Core pruning In-Reply-To: <44A31445.40808@gtw.net> References: <20060612214812.GA16446@nostromo.devel.redhat.com> <1151448432.6394.300.camel@pmac.infradead.org> <1151449446.28409.1.camel@rousalka.dyndns.org> <1151450694.6394.310.camel@pmac.infradead.org> <44A1C35C.20404@knox.net.nz> <44A216EB.2020400@gtw.net> <20060628231416.GC2612@nostromo.devel.redhat.com> <44A31445.40808@gtw.net> Message-ID: <44A3DCC4.3090904@fedoraproject.org> David Eisenstein wrote: >Bill Nottingham wrote: > > >>David Eisenstein (deisenst at gtw.net) said: >> >> >> >>>Further -- I see much glibness about saying, "Throw this over to extras. >>>Throw that over to extras. Extras can take care of it." I understand >>>there appears to be some community-wide consensus that it is a "Good >>>Thing"?? to reduce the size of Fedora Core. (I am afraid I don't know >>>Mr. Extras - can he handle all these new packages?) >>> >>> >>Look over the list of packages provided. It's all packages with no >>dependencies, either runtime or buildtime. Most of said packages are >>libraries. I see no motiviation for Core to provide libraries that >>aren't actually *used*; there is really no way that that benefits >>users. >> >>Bill >> >> > >I apologize, Bill, and to all of you, for my rather harsh words. The >glibness is mine, not yours. Sorry. > >Dumb question: Where exactly do I find the list of packages provided? > > List of packages planned to be removed? It was posted earlier in this list. >One thing that does concern me some is: What of people who, say, have been >using Fedora Core since the olden days, and who have custom or proprietary >applications on their computers that may require some of these older >deprecated libraries that upgrading to a newer Core will no longer provide? > Even though *current* applications in Core (or Extras?) no longer use such >libraries, it can still affect these users who may wish to upgrade to newer >releases of Core. For some, altering their sources to work with a newer >supported library may not be an option. > >Please bear in mind that these thoughts come from a Legacy standpoint, as >Fedora Legacy has been my main contribution to the Fedora Project: So >keeping older things running has been my focus so far, not running the >latest and greatest. (What was that SELinux thing again? ;-) ) > >The plan then is to let Fedora Extras contributors take over these library >packages to continue maintaining them for new Core releases, right? If no >one steps forward then to maintain these packages, do they then become >orphaned/unmaintained or even unavailable? > >Thanks for your patience with me. > > > Yes. -- Rahul From tibbs at math.uh.edu Thu Jun 29 18:28:17 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Jun 2006 13:28:17 -0500 Subject: PHP packaging guidelines not yet accepted Message-ID: The packaging committee met for the first time today, in part to take up the issue of the PHP guidelines. The result was that the current draft was not accepted. So, reviewers take note: as before, submissions of PHP extensions and modules (including PEAR and PECL modules) should not be approved until finalized guidelines are ready. Applications which happen to be written in PHP are OK as always. I know that it's annoying to have packages accumulating for which reviews cannot be completed due to the lack of these guidelines; we will be working on this and hope to have something out soon. The current draft is at: http://fedoraproject.org/wiki/Packaging/PHP You may of course join us in discussing this on the fedora packaging list, fedora-packaging at redhat.com. The packaging committee currently meets on Thursdays at 16:00UTC in #fedora-packaging on irc.freenode.net. - J< From ajackson at redhat.com Thu Jun 29 17:54:22 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 29 Jun 2006 13:54:22 -0400 Subject: Base X11 libraries cleanup Message-ID: <44A413CE.1070509@redhat.com> Ideally, all libraries should report zero unused direct dependencies when inspected with ldd -r -u. Although in some sense unused libraries are harmless, they do put needless pressure on the kernel's VM since all processes linked with the affected libraries have to map many more files, and in principle you can get unexpected behaviour when symbols don't resolve the way you expect due to namespace collisions. Several of the core X libraries fail this, for not particularly good reasons. I've fixed most of them by now, but there's one or two stragglers still. The side effect of this is that the culled libraries will not be included in the linker search scope for any libraries or applications above them in the stack. For example, libXaw no longer links against libSM, so if your application linked against libXaw and not libSM, but used symbols from libSM, it may now fail at runtime claiming that some symbols could not be resolved. If this happens, the affected package needs to be fixed to link against all appropriate libraries directly. I doubt anyone will actually run into that, but I wanted to give a heads up in case it does happen. (Ideally we should be able to do this for the entire OS. Baby steps.) - ajax From jkeating at redhat.com Thu Jun 29 20:31:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 29 Jun 2006 16:31:05 -0400 Subject: PHP packaging guidelines not yet accepted In-Reply-To: References: Message-ID: <200606291631.06087.jkeating@redhat.com> On Thursday 29 June 2006 14:28, Jason L Tibbitts III wrote: > The packaging committee met for the first time today, in part to take > up the issue of the PHP guidelines. ?The result was that the current > draft was not accepted. Its worth noting that we like the guideline, its just that there are some unresolved questions. Until those are resolved, we cannot accept the guideline. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Jun 29 20:51:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Jun 2006 15:51:45 -0500 Subject: qt4: make FHS-friendly (bug #196901) Message-ID: <44A43D61.30604@math.unl.edu> Per http://bugzilla.redhat.com/bugzilla/196901 I'm planning on moving bits out of the traditional %_libdir/qt4. For packagers, the biggest difference(s) will be: libdir: %_libdir/qt4/%_lib/* -> %_libdir/* headerdir: %_libdir/qt4/include/* -> %_includedir/* as well as: datadir: %_libdir/qt4 -> %_datadir/qt4 docdir: %_docdir/qt4-doc-%version -> %_docdir/qt4 translationdir: %_libdir/qt4/translations -> %_datadir/qt4/translations These changes will affect mostly qt4 addon packages(e.g. qt4-qsa), and should have zero impact on end users. I'll push devel branch build tomorrow (Fri) am, and wait ~1 week (~Thu, Jun 06) (without any show-stopping bugs appearing) before pushing FC-4/FC-5 updates. -- Rex From michael at knox.net.nz Fri Jun 30 01:47:28 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 30 Jun 2006 13:47:28 +1200 Subject: imlib .so questions. Message-ID: <44A482B0.4080404@knox.net.nz> Hi All, This pertains to this bug report (review actually): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 rpmlint outputs the following errors: E: imlib invalid-soname /usr/lib/libimlib-xpm.so libimlib-xpm.so E: imlib invalid-soname /usr/lib/libimlib-jpeg.so libimlib-jpeg.so E: imlib invalid-soname /usr/lib/libimlib-tiff.so libimlib-tiff.so E: imlib invalid-soname /usr/lib/libimlib-ppm.so libimlib-ppm.so E: imlib invalid-soname /usr/lib/libimlib-bmp.so libimlib-bmp.so E: imlib invalid-soname /usr/lib/libimlib-ps.so libimlib-ps.so E: imlib invalid-soname /usr/lib/libimlib-gif.so libimlib-gif.so E: imlib invalid-soname /usr/lib/libimlib-png.so libimlib-png.so I am not sure how to fix this. Its a legacy library, so is it worth fixing? Does anyone have some suggestions? All ears.. Thanks Michael From deisenst at gtw.net Fri Jun 30 03:13:30 2006 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 29 Jun 2006 22:13:30 -0500 Subject: Fw: fedora legacy broken upgrade paths (was: Broken upgrade paths inFC+FE 2006-06-28) Message-ID: <00c701c69bf3$31437320$6401a8c0@vdavide> Hi Chris, Thought you might wish to be aware of the following for current Fedora Core releases... it looks like we in Legacy botched up the upgrade path for the current Mozilla product, Mozilla-1.7.13-xxxx. Might we be able to figure out a way to overcome this? Also-- as we in Legacy work on other formerly-core packages, do you, Chris, or you, Josh, or any of you on this mailing list have any suggestions on what we need to do to coordinate our package naming so we don't botch up any future upgrade paths? Incidentally, Chris or Josh: Is there any news about the Mozilla-1.7.13 backports I have been given to understand you are working with to fix the most critical of the Mozilla vulnerability issues? Once there are Mozilla-1.7.13 packages released for RHEL, are there plans to subsequently release similar packages for FC5, FC6, rawhide? Thanks a bunch in advance! Warm Regards, David Eisenstein ----- Original Message ----- From: "Axel Thimm" To: Cc: "Discussion related to Fedora Extras" Sent: Thursday, June 29, 2006 12:48 AM Subject: fedora legacy broken upgrade paths (was: Broken upgrade paths inFC+FE 2006-06-28) > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00109.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00111.dat Type: application/octet-stream Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Jun 30 07:23:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 30 Jun 2006 09:23:20 +0200 Subject: Base X11 libraries cleanup In-Reply-To: <44A413CE.1070509@redhat.com> References: <44A413CE.1070509@redhat.com> Message-ID: <44A4D168.7060502@hhs.nl> Adam Jackson wrote: > Ideally, all libraries should report zero unused direct dependencies > when inspected with ldd -r -u. Although in some sense unused libraries > are harmless, they do put needless pressure on the kernel's VM since all > processes linked with the affected libraries have to map many more > files, and in principle you can get unexpected behaviour when symbols > don't resolve the way you expect due to namespace collisions. > > Several of the core X libraries fail this, for not particularly good > reasons. I've fixed most of them by now, but there's one or two > stragglers still. > > The side effect of this is that the culled libraries will not be > included in the linker search scope for any libraries or applications > above them in the stack. For example, libXaw no longer links against > libSM, so if your application linked against libXaw and not libSM, but > used symbols from libSM, it may now fail at runtime claiming that some > symbols could not be resolved. If this happens, the affected package > needs to be fixed to link against all appropriate libraries directly. > > I doubt anyone will actually run into that, but I wanted to give a heads > up in case it does happen. > > (Ideally we should be able to do this for the entire OS. Baby steps.) > > - ajax > How about using ld --as-needed, AFAIK that has come up before and would be a great improvement! Whats holding us back from linking with --as-needed by default? Regards, Hans From fedora at camperquake.de Fri Jun 30 07:30:48 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 30 Jun 2006 09:30:48 +0200 Subject: Base X11 libraries cleanup In-Reply-To: <44A4D168.7060502@hhs.nl> References: <44A413CE.1070509@redhat.com> <44A4D168.7060502@hhs.nl> Message-ID: <20060630093048.341fbdeb@voip.int.addix.net> Hi. On Fri, 30 Jun 2006 09:23:20 +0200, Hans de Goede wrote: > How about using ld --as-needed, AFAIK that has come up before and > would be a great improvement! In the few cases that I've tried it it simply did not work as adveritsed (or maybe I misunderstood it's purpose). To wit: > cat > test.c < int main(int argc, char** argv) { fprintf(stdout, "This is a test\n"); return 0; } EOF > gcc -o test.o -c test.c > gcc -o test -lxml2 -Wl,--as-needed test.o > ldd -r -u ./test Unused direct dependencies: /usr/lib/libxml2.so.2 From paul at city-fan.org Fri Jun 30 07:37:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 30 Jun 2006 08:37:06 +0100 Subject: Base X11 libraries cleanup In-Reply-To: <20060630093048.341fbdeb@voip.int.addix.net> References: <44A413CE.1070509@redhat.com> <44A4D168.7060502@hhs.nl> <20060630093048.341fbdeb@voip.int.addix.net> Message-ID: <1151653026.7470.254.camel@laurel.intra.city-fan.org> On Fri, 2006-06-30 at 09:30 +0200, Ralf Ertzinger wrote: > Hi. > > On Fri, 30 Jun 2006 09:23:20 +0200, Hans de Goede wrote: > > > How about using ld --as-needed, AFAIK that has come up before and > > would be a great improvement! > > In the few cases that I've tried it it simply did not work as adveritsed > (or maybe I misunderstood it's purpose). > > To wit: > > > cat > test.c < #include > > int main(int argc, char** argv) { > > fprintf(stdout, "This is a test\n"); > > return 0; > } > EOF > > > gcc -o test.o -c test.c > > gcc -o test -lxml2 -Wl,--as-needed test.o > > ldd -r -u ./test > Unused direct dependencies: > > /usr/lib/libxml2.so.2 However: $ cat > test.c < int main(int argc, char** argv) { fprintf(stdout, "This is a test\n"); return 0; } EOF $ gcc -o test.o -c test.c $ gcc -o test -lxml2 -Wl,--as-needed test.o $ ldd -r -u ./test Unused direct dependencies: /usr/lib/libxml2.so.2 $ gcc -o test -Wl,--as-needed -lxml2 test.o $ ldd -r -u ./test (no output) Paul. From fedora at camperquake.de Fri Jun 30 08:00:15 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 30 Jun 2006 10:00:15 +0200 Subject: Base X11 libraries cleanup In-Reply-To: <1151653026.7470.254.camel@laurel.intra.city-fan.org> References: <44A413CE.1070509@redhat.com> <44A4D168.7060502@hhs.nl> <20060630093048.341fbdeb@voip.int.addix.net> <1151653026.7470.254.camel@laurel.intra.city-fan.org> Message-ID: <20060630100015.22966eae@voip.int.addix.net> Hi. On Fri, 30 Jun 2006 08:37:06 +0100, Paul Howarth wrote: > $ gcc -o test -Wl,--as-needed -lxml2 test.o > $ ldd -r -u ./test Ah, right, there was that. I had a more complex case somewhere where I _think_ I tried putting --as-needed almost anywhere without visible effect. However, using --as-needed did not hurt there, either, so using it is fine with me. From bugs.michael at gmx.net Fri Jun 30 08:07:07 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 30 Jun 2006 10:07:07 +0200 Subject: qt4: make FHS-friendly (bug #196901) In-Reply-To: <44A43D61.30604@math.unl.edu> References: <44A43D61.30604@math.unl.edu> Message-ID: <20060630100707.f0104748.bugs.michael@gmx.net> On Thu, 29 Jun 2006 15:51:45 -0500, Rex Dieter wrote: > Per > http://bugzilla.redhat.com/bugzilla/196901 > > I'm planning on moving bits out of the traditional %_libdir/qt4. For > packagers, the biggest difference(s) will be: > libdir: %_libdir/qt4/%_lib/* -> %_libdir/* > headerdir: %_libdir/qt4/include/* -> %_includedir/* > > as well as: > datadir: %_libdir/qt4 -> %_datadir/qt4 > docdir: %_docdir/qt4-doc-%version -> %_docdir/qt4 > translationdir: %_libdir/qt4/translations -> %_datadir/qt4/translations What will be moved? The 'qt4' hierarchy? Individual files? What happens to the concept of co-existing Qt installations? Will these changes survive package movement into Core (i.e. when Qt 4.x will appear in Core)? From bugs.michael at gmx.net Fri Jun 30 08:08:58 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 30 Jun 2006 10:08:58 +0200 Subject: imlib .so questions. In-Reply-To: <44A482B0.4080404@knox.net.nz> References: <44A482B0.4080404@knox.net.nz> Message-ID: <20060630100858.48227a5f.bugs.michael@gmx.net> On Fri, 30 Jun 2006 13:47:28 +1200, Michael J. Knox wrote: > Hi All, > > This pertains to this bug report (review actually): > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194355 > > rpmlint outputs the following errors: > > E: imlib invalid-soname /usr/lib/libimlib-xpm.so libimlib-xpm.so > E: imlib invalid-soname /usr/lib/libimlib-jpeg.so libimlib-jpeg.so > E: imlib invalid-soname /usr/lib/libimlib-tiff.so libimlib-tiff.so > E: imlib invalid-soname /usr/lib/libimlib-ppm.so libimlib-ppm.so > E: imlib invalid-soname /usr/lib/libimlib-bmp.so libimlib-bmp.so > E: imlib invalid-soname /usr/lib/libimlib-ps.so libimlib-ps.so > E: imlib invalid-soname /usr/lib/libimlib-gif.so libimlib-gif.so > E: imlib invalid-soname /usr/lib/libimlib-png.so libimlib-png.so > > I am not sure how to fix this. By adding a proper version to the SONAME or moving these plugins into a sub-directory like imlib2 does. However, it then needs RPATH or absolute paths to load them. > Its a legacy library, so is it worth fixing? No. From fedora at camperquake.de Fri Jun 30 08:31:28 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 30 Jun 2006 10:31:28 +0200 Subject: Base X11 libraries cleanup In-Reply-To: <20060630100015.22966eae@voip.int.addix.net> References: <44A413CE.1070509@redhat.com> <44A4D168.7060502@hhs.nl> <20060630093048.341fbdeb@voip.int.addix.net> <1151653026.7470.254.camel@laurel.intra.city-fan.org> <20060630100015.22966eae@voip.int.addix.net> Message-ID: <20060630103128.3141c3ac@voip.int.addix.net> Hi. On Fri, 30 Jun 2006 10:00:15 +0200, Ralf Ertzinger wrote: > However, using --as-needed did not hurt there, either, so using > it is fine with me. OK, I found it, and it did hurt, after all. Instructions: a) download http://www.skytale.net/files/bmp-flac2/bmp-flac2-009.tar.gz b) untar c) install bmp-devel and flac-devel d) do a ./configure; make e) look at the ldd output of libflac.so (huge) f) do a "make distclean" g) change "$(CC) $(LDFLAGS)" into "$(CC) -Wl,--as-needed $(LDFLAGS)" in Makefile.in (line 25) h) repeat step d) i) look at the ldd output again (very small and lots of unresolved symbols) From rdieter at math.unl.edu Fri Jun 30 11:36:22 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Jun 2006 06:36:22 -0500 Subject: qt4: make FHS-friendly (bug #196901) In-Reply-To: <20060630100707.f0104748.bugs.michael@gmx.net> References: <44A43D61.30604@math.unl.edu> <20060630100707.f0104748.bugs.michael@gmx.net> Message-ID: <44A50CB6.9060709@math.unl.edu> Michael Schwendt wrote: > On Thu, 29 Jun 2006 15:51:45 -0500, Rex Dieter wrote: > >> Per >> http://bugzilla.redhat.com/bugzilla/196901 >> >> I'm planning on moving bits out of the traditional %_libdir/qt4. For >> packagers, the biggest difference(s) will be: >> libdir: %_libdir/qt4/%_lib/* -> %_libdir/* >> headerdir: %_libdir/qt4/include/* -> %_includedir/* >> >> as well as: >> datadir: %_libdir/qt4 -> %_datadir/qt4 >> docdir: %_docdir/qt4-doc-%version -> %_docdir/qt4 >> translationdir: %_libdir/qt4/translations -> %_datadir/qt4/translations > > What will be moved? The 'qt4' hierarchy? Individual files? What happens to > the concept of co-existing Qt installations? %_libdir/qt4 (aka the qt4 heirarchy) will still exist, The main changes are: * shared libs will now be in %_libdir * header files will now be in %_includedir * noarch content will (largely) now live in %_datadir/qt4 instead. But the qt4 heirarchy (%_libdir/qt) will still exist, containing other arch-specific bits (binaries, plugins, etc...) This arrangement doesn't preclude having another parallel-installable qt4 somewhere else, but that's not ever much of a concern/priority, imo. > Will these changes survive package movement into Core (i.e. when Qt 4.x > will appear in Core)? I'd assume so, but that would depend on who (continues) to maintain it post-move-to-Core. -- Rex From bugs.michael at gmx.net Fri Jun 30 12:12:50 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 30 Jun 2006 14:12:50 +0200 Subject: qt4: make FHS-friendly (bug #196901) In-Reply-To: <44A50CB6.9060709@math.unl.edu> References: <44A43D61.30604@math.unl.edu> <20060630100707.f0104748.bugs.michael@gmx.net> <44A50CB6.9060709@math.unl.edu> Message-ID: <20060630141250.70471f30.bugs.michael@gmx.net> On Fri, 30 Jun 2006 06:36:22 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > On Thu, 29 Jun 2006 15:51:45 -0500, Rex Dieter wrote: > > > >> Per > >> http://bugzilla.redhat.com/bugzilla/196901 > >> > >> I'm planning on moving bits out of the traditional %_libdir/qt4. For > >> packagers, the biggest difference(s) will be: > >> libdir: %_libdir/qt4/%_lib/* -> %_libdir/* > >> headerdir: %_libdir/qt4/include/* -> %_includedir/* > >> > >> as well as: > >> datadir: %_libdir/qt4 -> %_datadir/qt4 > >> docdir: %_docdir/qt4-doc-%version -> %_docdir/qt4 > >> translationdir: %_libdir/qt4/translations -> %_datadir/qt4/translations > > > > What will be moved? The 'qt4' hierarchy? Individual files? What happens to > > the concept of co-existing Qt installations? > > %_libdir/qt4 (aka the qt4 heirarchy) will still exist, The main changes are: > * shared libs will now be in %_libdir > * header files will now be in %_includedir > * noarch content will (largely) now live in %_datadir/qt4 instead. What will $QTDIR, $QTLIB and $QTINC look like? Will your layout break anything which uses $QTDIR/lib, $QTDIR/include and $QTDIR/bin? Or do you try to fix that with symlinks? > But the qt4 heirarchy (%_libdir/qt) will still exist, containing other > arch-specific bits (binaries, plugins, etc...) > > This arrangement doesn't preclude having another parallel-installable > qt4 somewhere else, but that's not ever much of a concern/priority, imo. How about another parallel installable _other_ version of Qt? e.g. Qt 3.x, Qt 2.x. What about namespace clashes? > > Will these changes survive package movement into Core (i.e. when Qt 4.x > > will appear in Core)? > > I'd assume so, but that would depend on who (continues) to maintain it > post-move-to-Core. From rdieter at math.unl.edu Fri Jun 30 12:18:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Jun 2006 07:18:28 -0500 Subject: qt4: make FHS-friendly (bug #196901) In-Reply-To: <20060630141250.70471f30.bugs.michael@gmx.net> References: <44A43D61.30604@math.unl.edu> <20060630100707.f0104748.bugs.michael@gmx.net> <44A50CB6.9060709@math.unl.edu> <20060630141250.70471f30.bugs.michael@gmx.net> Message-ID: <44A51694.3080109@math.unl.edu> Michael Schwendt wrote: > What will $QTDIR, $QTLIB and $QTINC look like? Will your layout break > anything which uses $QTDIR/lib, $QTDIR/include and $QTDIR/bin? QTDIR,QTLIB,QTINC are qt3 constructs, not used in qt4 at all. qt4 apps (mostly) use pkg-config to query this type of thing. >> But the qt4 heirarchy (%_libdir/qt) will still exist, containing other >> arch-specific bits (binaries, plugins, etc...) >> >> This arrangement doesn't preclude having another parallel-installable >> qt4 somewhere else, but that's not ever much of a concern/priority, imo. > > How about another parallel installable _other_ version of Qt? e.g. > Qt 3.x, Qt 2.x. What about namespace clashes? It's certainly still installable along-side qt(3). I wouldn't have tried this if it weren't. -- Rex From jpo at lsd.di.uminho.pt Fri Jun 30 13:43:08 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 30 Jun 2006 14:43:08 +0100 Subject: FE-5 perl packages status (2006-06-30) Message-ID: <44A52A6C.3080200@lsd.di.uminho.pt> -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fe5-perl-packages-report-20060630.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From tcallawa at redhat.com Fri Jun 30 14:34:37 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 30 Jun 2006 09:34:37 -0500 Subject: Fedora Packaging Committee Meeting (2006-06-29) Message-ID: <1151678077.7108.27.camel@localhost.localdomain> The Fedora Packaging Committee met yesterday (June 29, 2006). Full minutes of this meeting and the full IRC log of the meeting can be found here: http://fedoraproject.org/wiki/Packaging/Minutes Here are the minutes from this meeting: * All members in attendance, except Michael Schwendt, who has not yet accepted (or declined) the invitation to join. * It was agreed that all decisions by the Fedora Packaging Committee would be decided by a majority vote of 6. Thus, a 6 member quorum is required. If the committee adds/removes members, the quorum amount will be revisited. * The moderator (TomCallaway) started going through the list of open issues found here: Packaging/GuidelinesTodo * On the first issue, libexecdir, the Committee voted to add text to the Guidelines permitting the use of %{_libexecdir} in Fedora packages even though it is not currently part of the FHS. The issue passed with 6 yes votes, 0 no votes, 4 members abstaining. * The Committee also voted to recommend that subdirs be used in % _libexecdir where upstream shows no clear preference. Ultimately, the use of subdirs in %{_libexecdir} is at the packager's discretion. The issue passed with 7 yes votes, 0 no votes, 3 members abstaining. * AxelThimm agreed to take the issue of including libexecdir to the FHS on behalf of the Fedora Packaging Committee. * TomCallaway agreed to write up the libexecdir changes. * On the issue of mono guidelines, the Committee discussed the confusing (and frightening) nature of mono packages at length, and ultimately voted to standardize mono packages as architecture specific packages that put their files under %{_libdir}/%{name}. The issue passed with 8 yes votes, 0 no votes, 2 members abstaining. * On the issue of ruby guidelines, the Committee discussed the draft guidelines, and voted to approve them as formal guidelines and lift the hold on ruby packages. The issue passed with 6 yes votes, 0 no votes, 4 members abstaining. * On the issue of php guidelines, the Committee discussed the draft guidelines. It was noted that there are still several key open issues around the PHP guidelines. A vote was taken to approve the existing guidelines, and this vote failed, with 5 yes votes, 0 no votes, and 5 members abstaining. This issue was tabled, and put on the agenda for next week. JasonTibbs and TomCallaway were tasked with resolving the open issues with the PHP guidelines. * As a result of the PHP guidelines not being approved, a moratorium was placed on all php packages. JasonTibbs announced this on the fedora-extras and fedora-maintainers lists. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ajackson at redhat.com Fri Jun 30 13:58:02 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 30 Jun 2006 09:58:02 -0400 Subject: Base X11 libraries cleanup In-Reply-To: <44A4D168.7060502@hhs.nl> References: <44A413CE.1070509@redhat.com> <44A4D168.7060502@hhs.nl> Message-ID: <44A52DEA.3010508@redhat.com> Hans de Goede wrote: > How about using ld --as-needed, AFAIK that has come up before and would > be a great improvement! > > Whats holding us back from linking with --as-needed by default? Well, one, libtool will actively defeat your attempts to use it, since it doesn't think linker arguments are positional, so it sorts -Wl,--as-needed (and -Wl,* in general) to the end, _after_ all the libraries you could possibly want to have specified as optional. Which means the libtool developers are either clueless or malicious. No, I'm not interested in fixing libtool, other than by replacement. In general though, since --as-needed is positional, it's not as simple as "just turn it on by default", because you have to do it between all the convenience libraries you ar'd up during the build, and all the installed system libraries you might possibly want to link against. Even if you do that, there's no guarantee the app isn't doing something weird like using the result of dlopen(NULL) to dlsym with, in which case the altered search scope can affect runtime behaviour. It's fine to add it if you're willing to fix what breaks _and_ you're not using libtool. - ajax From caillon at redhat.com Fri Jun 30 16:10:03 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 30 Jun 2006 12:10:03 -0400 Subject: Fw: fedora legacy broken upgrade paths (was: Broken upgrade paths inFC+FE 2006-06-28) In-Reply-To: <00c701c69bf3$31437320$6401a8c0@vdavide> References: <00c701c69bf3$31437320$6401a8c0@vdavide> Message-ID: <44A54CDB.50207@redhat.com> David Eisenstein wrote: > Hi Chris, > > Thought you might wish to be aware of the following for current Fedora Core releases... it looks like we in Legacy botched up the upgrade path for the current Mozilla product, Mozilla-1.7.13-xxxx. > > Might we be able to figure out a way to overcome this? Also-- as we in Legacy work on other formerly-core packages, do you, Chris, or you, Josh, or any of you on this mailing list have any suggestions on what we need to do to coordinate our package naming so we don't botch up any future upgrade paths? > I suggest pulling the current package so that nobody else gets it and replacing it with a package that will not cause these ill effects. Reducing the effect should be a first step. We'll have to deal with it somehow, anyway, but I think the current plan of having SeaMonkey obsolete the mozilla package will work, once that gets done. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From jkeating at redhat.com Fri Jun 30 19:47:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Jun 2006 15:47:19 -0400 Subject: Mass rebuild of core packages coming soon Message-ID: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> I've been requested to rebuild every Core package for a few reasons. 1) rpm signing w/ sha256sum 2) New toolset feature to speed up dynamic lib linking by 50%~ 3) get all packages built through new build system (brew) We're waiting for some stuff to finalize upstream, but would like to start on the building next week. Please give me a list of packages you'd prefer I didn't build and I'll blacklist them from my massbuild scripts. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cweyl at alumni.drew.edu Fri Jun 30 20:33:44 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 30 Jun 2006 13:33:44 -0700 Subject: Mass rebuild of core packages coming soon In-Reply-To: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> Message-ID: <7dd7ab490606301333j4b226795x5d9b1485512f1b42@mail.gmail.com> On 6/30/06, Jesse Keating wrote: > I've been requested to rebuild every Core package for a few reasons. Out of curiosity, is this just to rebuild them for devel/fc6, or for fc5 (4?) as well? -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Fri Jun 30 23:38:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Jun 2006 19:38:27 -0400 Subject: Mass rebuild of core packages coming soon In-Reply-To: <7dd7ab490606301333j4b226795x5d9b1485512f1b42@mail.gmail.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <7dd7ab490606301333j4b226795x5d9b1485512f1b42@mail.gmail.com> Message-ID: <200606301938.27297.jkeating@redhat.com> On Friday 30 June 2006 16:33, Chris Weyl wrote: > Out of curiosity, is this just to rebuild them for devel/fc6, or for > fc5 (4?) as well? Just for devel/fc6. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: