From Axel.Thimm at ATrpms.net Thu Mar 1 12:53:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 13:53:00 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070227203050.096d8b69@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> Message-ID: <20070301125300.GA10127@neu.nirvana> On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > FP! :-) > > Joke aside, I'd like to see which views we have on the release and > update procedure to apply to EPEL. > > - Do we want a moving (and potentially breaking) set of packages which > is constantly being updated? The CentOS way > - De we want a fixed set of packages when a RHEL release is made and > focus on major bugfixes and security updates from there on? More RHEL like You'll find that people in favour of one will come from the respective camp. *RHEL* customers are usually really fixated in using RHEL 5.3 and not something between 5.3 and 5.4. Same for Scientific Linux. CentOS OTOH more on running the latests. So, it's up to the target audience you want to please. I think RHEL's fastrack may be a good model. You prepare packages for RHEL 5.(N+1) and make it already available there. Users can then decide to stick with minor release + security updates or slide on a rolling like release from RHEL 5.N to RHEL 5.(N+1). Maybe we even have to do that that way, if we want to claim full RHEL support. Otherwise we may be enforcing different update models to RHEL users than they have with RHEL pure. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 1 12:59:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 13:59:38 +0100 Subject: Backporting (was: Release and update procedure for EPEL) In-Reply-To: <20070227194604.GC3330@nostromo.devel.redhat.com> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070227194604.GC3330@nostromo.devel.redhat.com> Message-ID: <20070301125938.GB10127@neu.nirvana> On Tue, Feb 27, 2007 at 02:46:04PM -0500, Bill Nottingham wrote: > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > - Do we want a moving (and potentially breaking) set of packages which > > is constantly being updated? > > - De we want a fixed set of packages when a RHEL release is made and > > focus on major bugfixes and security updates from there on? > > > > Or maybe something in between, or even both at the same time in > > separate repositories... all is possible, as long as we have enough man > > power to make it happen. > > I'd lean somewhat towards the latter. If we actually intend to maintain > stuff for 7 years, we're not going to be wanting to do that many upgrades. > > Are packagers really signing up for backporting? A good question, backporting is the name of evil in software engineering and packaging. FL died on the amount of efforts this requires. Simply upgrading is the fast way out, but maybe not the RHEL API/ABI stable way. Backporting would be really great, but we need tons of slaves or masochists to commit to this. Maybe it depends on how many paid jobs from RH and external will be involved, since volunteers are less likely to do backporting. I would say, if we think that manpower will be low, we need to follow a rolling release model w/o backporting. If we know that there is enough momentum and interest (in the sense of doing it, not just wanting it) then we should consider backporting, it would raise quality/stability standards to two of the "E"s in RHEL/EPEL ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu Mar 1 14:49:02 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 01 Mar 2007 08:49:02 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <20070301125300.GA10127@neu.nirvana> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> Message-ID: <1172760542.3803.10.camel@localhost.localdomain> On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: > On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > > FP! :-) > > > > Joke aside, I'd like to see which views we have on the release and > > update procedure to apply to EPEL. > > > > - Do we want a moving (and potentially breaking) set of packages which > > is constantly being updated? > > The CentOS way > > > - De we want a fixed set of packages when a RHEL release is made and > > focus on major bugfixes and security updates from there on? > > More RHEL like FWIW, the CentOS people I spoke to at FOSDEM were very much interested in the "fixed set, with bugfixes and security updates only" model. ~spot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 1 15:44:14 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Mar 2007 16:44:14 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <1172760542.3803.10.camel@localhost.localdomain> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> <1172760542.3803.10.camel@localhost.localdomain> Message-ID: <20070301164414.2f73bcc3@python3.es.egwn.lan> Tom 'spot' Callaway wrote : > On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: > > On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > > > FP! :-) > > > > > > Joke aside, I'd like to see which views we have on the release and > > > update procedure to apply to EPEL. > > > > > > - Do we want a moving (and potentially breaking) set of packages which > > > is constantly being updated? > > > > The CentOS way > > > > > - De we want a fixed set of packages when a RHEL release is made and > > > focus on major bugfixes and security updates from there on? > > > > More RHEL like > > FWIW, the CentOS people I spoke to at FOSDEM were very much interested > in the "fixed set, with bugfixes and security updates only" model. ...but also in providing a lot of recent stuff. They already have php 5 and mysql 5 in a separate location for people to use on CentOS 4. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.04 0.10 0.15 From Axel.Thimm at ATrpms.net Thu Mar 1 16:18:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 17:18:24 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <1172760542.3803.10.camel@localhost.localdomain> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> <1172760542.3803.10.camel@localhost.localdomain> Message-ID: <20070301161824.GA16337@neu.nirvana> On Thu, Mar 01, 2007 at 08:49:02AM -0600, Tom 'spot' Callaway wrote: > On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: > > On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > > > FP! :-) > > > > > > Joke aside, I'd like to see which views we have on the release and > > > update procedure to apply to EPEL. > > > > > > - Do we want a moving (and potentially breaking) set of packages which > > > is constantly being updated? > > > > The CentOS way > > > > > - De we want a fixed set of packages when a RHEL release is made and > > > focus on major bugfixes and security updates from there on? > > > > More RHEL like > > FWIW, the CentOS people I spoke to at FOSDEM were very much interested > in the "fixed set, with bugfixes and security updates only" model. Well, in the world of clones you usually pick Scientific Linux for point in time releases and CentOS for rolling ones, that's the typical distinction between the last standing major clones. But some recent development will raise a higher incentive to support the RHEL model better within CentOS soon. But that makes our lives more miserable, because it pushes towards backporting. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Thu Mar 1 16:25:29 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 1 Mar 2007 10:25:29 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <20070301161824.GA16337@neu.nirvana> References: <20070227203050.096d8b69@python3.es.egwn.lan> <1172760542.3803.10.camel@localhost.localdomain> <20070301161824.GA16337@neu.nirvana> Message-ID: <200703011025.30152.dennis@ausil.us> On Thursday 01 March 2007 10:18:24 am Axel Thimm wrote: > On Thu, Mar 01, 2007 at 08:49:02AM -0600, Tom 'spot' Callaway wrote: > > On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: > > > On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > > > > FP! :-) > > > > > > > > Joke aside, I'd like to see which views we have on the release and > > > > update procedure to apply to EPEL. > > > > > > > > - Do we want a moving (and potentially breaking) set of packages > > > > which is constantly being updated? > > > > > > The CentOS way > > > > > > > - De we want a fixed set of packages when a RHEL release is made and > > > > focus on major bugfixes and security updates from there on? > > > > > > More RHEL like > > > > FWIW, the CentOS people I spoke to at FOSDEM were very much interested > > in the "fixed set, with bugfixes and security updates only" model. > > Well, in the world of clones you usually pick Scientific Linux for > point in time releases and CentOS for rolling ones, that's the typical > distinction between the last standing major clones. But some recent > development will raise a higher incentive to support the RHEL model > better within CentOS soon. > > But that makes our lives more miserable, because it pushes towards > backporting. Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling releases you are talking about. or are you talking about CentOS plus or some such -- Dennis Gilmore, RHCE From fedora at leemhuis.info Thu Mar 1 17:14:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Mar 2007 18:14:30 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070301164414.2f73bcc3@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> <1172760542.3803.10.camel@localhost.localdomain> <20070301164414.2f73bcc3@python3.es.egwn.lan> Message-ID: <45E709F6.5030904@leemhuis.info> Matthias Saou schrieb: > Tom 'spot' Callaway wrote : >> On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: >>> On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: >>>> FP! :-) >>>> Joke aside, I'd like to see which views we have on the release and >>>> update procedure to apply to EPEL. >>>> - Do we want a moving (and potentially breaking) set of packages which >>>> is constantly being updated? >>> The CentOS way >>> >>>> - De we want a fixed set of packages when a RHEL release is made and >>>> focus on major bugfixes and security updates from there on? >>> More RHEL like >> FWIW, the CentOS people I spoke to at FOSDEM were very much interested >> in the "fixed set, with bugfixes and security updates only" model. I agree with the "fixed set, with bugfixes and security updates only", too. But also with this: > ...but also in providing a lot of recent stuff. They already have php 5 > and mysql 5 in a separate location for people to use on CentOS 4. But I'd say we should leave this out for now until EPEL lift of, and find a a solution for this later. CU thl From mastahnke at gmail.com Thu Mar 1 17:31:11 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 1 Mar 2007 11:31:11 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <45E709F6.5030904@leemhuis.info> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> <1172760542.3803.10.camel@localhost.localdomain> <20070301164414.2f73bcc3@python3.es.egwn.lan> <45E709F6.5030904@leemhuis.info> Message-ID: <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> Wasn't Red Hat introducing something along the lines of a LAMP stack that rolls on top of RHEL? LIke it would actually have PHP5/MySQL 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I thought, but a valid idea. The latest software for what is needed, and stable known-good software for the rest. I thought something like that was talked about at the RH summit last year. I do think that a rolling release on top of a no API/ABI breakage release would be very difficult to do, and tend to agree that targetting minor releases for updates probably makes the most sense for users and developers. On 3/1/07, Thorsten Leemhuis wrote: > Matthias Saou schrieb: > > Tom 'spot' Callaway wrote : > >> On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: > >>> On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > >>>> FP! :-) > >>>> Joke aside, I'd like to see which views we have on the release and > >>>> update procedure to apply to EPEL. > >>>> - Do we want a moving (and potentially breaking) set of packages which > >>>> is constantly being updated? > >>> The CentOS way > >>> > >>>> - De we want a fixed set of packages when a RHEL release is made and > >>>> focus on major bugfixes and security updates from there on? > >>> More RHEL like > >> FWIW, the CentOS people I spoke to at FOSDEM were very much interested > >> in the "fixed set, with bugfixes and security updates only" model. > > I agree with the "fixed set, with bugfixes and security updates only", too. > > But also with this: > > > ...but also in providing a lot of recent stuff. They already have php 5 > > and mysql 5 in a separate location for people to use on CentOS 4. > > But I'd say we should leave this out for now until EPEL lift of, and > find a a solution for this later. > > CU > thl > > _______________________________________________ > Epel-devel-list mailing list > Epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From Axel.Thimm at ATrpms.net Thu Mar 1 22:26:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Mar 2007 23:26:35 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <200703011025.30152.dennis@ausil.us> References: <20070227203050.096d8b69@python3.es.egwn.lan> <1172760542.3803.10.camel@localhost.localdomain> <20070301161824.GA16337@neu.nirvana> <200703011025.30152.dennis@ausil.us> Message-ID: <20070301222635.GB31912@neu.nirvana> On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote: > On Thursday 01 March 2007 10:18:24 am Axel Thimm wrote: > > On Thu, Mar 01, 2007 at 08:49:02AM -0600, Tom 'spot' Callaway wrote: > > > On Thu, 2007-03-01 at 13:53 +0100, Axel Thimm wrote: > > > > On Tue, Feb 27, 2007 at 08:30:50PM +0100, Matthias Saou wrote: > > > > > FP! :-) > > > > > > > > > > Joke aside, I'd like to see which views we have on the release and > > > > > update procedure to apply to EPEL. > > > > > > > > > > - Do we want a moving (and potentially breaking) set of packages > > > > > which is constantly being updated? > > > > > > > > The CentOS way > > > > > > > > > - De we want a fixed set of packages when a RHEL release is made and > > > > > focus on major bugfixes and security updates from there on? > > > > > > > > More RHEL like > > > > > > FWIW, the CentOS people I spoke to at FOSDEM were very much interested > > > in the "fixed set, with bugfixes and security updates only" model. > > > > Well, in the world of clones you usually pick Scientific Linux for > > point in time releases and CentOS for rolling ones, that's the typical > > distinction between the last standing major clones. But some recent > > development will raise a higher incentive to support the RHEL model > > better within CentOS soon. > > > > But that makes our lives more miserable, because it pushes towards > > backporting. > > Umm CentOS releases updates shortly after RHEL does. Im not sure what rolling > releases you are talking about. Roling in the sense of the minor release integer. > or are you talking about CentOS plus or some such No, that's something different, that's an add-on repo which goes beyond cloning. Compare http://isoredirect.centos.org/centos/4/isos/i386/ to https://www.scientificlinux.org/download/ E.g. the range of 4.x versions. SL follows RH in maintaining each point release, while CentOS kind of EOLs the previous point releases. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Fri Mar 2 05:20:31 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 01 Mar 2007 21:20:31 -0800 Subject: Release and update procedure for EPEL In-Reply-To: <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> <1172760542.3803.10.camel@localhost.localdomain> <20070301164414.2f73bcc3@python3.es.egwn.lan> <45E709F6.5030904@leemhuis.info> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> Message-ID: <1172812831.4651.497.camel@erato.phig.org> On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote: > Wasn't Red Hat introducing something along the lines of a LAMP stack > that rolls on top of RHEL? LIke it would actually have PHP5/MySQL > 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I > thought, but a valid idea. The latest software for what is needed, > and stable known-good software for the rest. Yep, launched last September. From the right-side column here: https://rhstack.108.redhat.com ... is this list of apps and versions: HTTPD Apache 2.0.59 JBoss AS 4.0.5 MySQL 5.0.30 PHP 5.1.6 Perl 5.8.8 PostgreSQL 8.1.8 Red Hat Enterprise Linux 4 Update 4 I suppose that makes those applications and versions not eligible to be packages in EPEL? Is eligibility decided by applications or specific versions or both? Or some other combination? - Karsten -- 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 dennis at ausil.us Fri Mar 2 12:36:32 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 2 Mar 2007 06:36:32 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <1172812831.4651.497.camel@erato.phig.org> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> Message-ID: <200703020636.45768.dennis@ausil.us> Once upon a time Thursday 01 March 2007, Karsten Wade wrote: > On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote: > > Wasn't Red Hat introducing something along the lines of a LAMP stack > > that rolls on top of RHEL? LIke it would actually have PHP5/MySQL > > 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I > > thought, but a valid idea. The latest software for what is needed, > > and stable known-good software for the rest. > > Yep, launched last September. From the right-side column here: > > https://rhstack.108.redhat.com > > ... is this list of apps and versions: > > HTTPD Apache 2.0.59 > JBoss AS 4.0.5 > MySQL 5.0.30 > PHP 5.1.6 > Perl 5.8.8 > PostgreSQL 8.1.8 > Red Hat Enterprise Linux 4 Update 4 > > I suppose that makes those applications and versions not eligible to be > packages in EPEL? Is eligibility decided by applications or specific > versions or both? Or some other combination? EPEL packages are not to replace packages in RHEL so of those we could maybe include JBoss. though things get murky when it comes to Red Hat add on's Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 2 12:50:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Mar 2007 13:50:32 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <200703020636.45768.dennis@ausil.us> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> Message-ID: <45E81D98.6090407@leemhuis.info> On 02.03.2007 13:36, Dennis Gilmore wrote: > Once upon a time Thursday 01 March 2007, Karsten Wade wrote: >> On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote: >>> Wasn't Red Hat introducing something along the lines of a LAMP stack >>> that rolls on top of RHEL? LIke it would actually have PHP5/MySQL >>> 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I >>> thought, but a valid idea. The latest software for what is needed, >>> and stable known-good software for the rest. >> Yep, launched last September. From the right-side column here: >> https://rhstack.108.redhat.com >> ... is this list of apps and versions: >> HTTPD Apache 2.0.59 >> JBoss AS 4.0.5 >> MySQL 5.0.30 >> PHP 5.1.6 >> Perl 5.8.8 >> PostgreSQL 8.1.8 >> Red Hat Enterprise Linux 4 Update 4 >> I suppose that makes those applications and versions not eligible to be >> packages in EPEL? Is eligibility decided by applications or specific >> versions or both? Or some other combination? > EPEL packages are not to replace packages in RHEL so of those we could maybe > include JBoss. +1 (including the maybe) > though things get murky when it comes to Red Hat add on's Exactly... Not sure, maybe the compromise needs to be something like this: --- EPEL Packages must not replace or conflict(?) with Packages from it's base (e.g. RHEL) or directly related Add-On-Packages for it, that got released in the same timeframe as the RHEL-Release. --- CU thl (?) -- conflict in the real life meaning of conflict, not the "Conflict:" usage in RPM (that's another discussion for later) From mastahnke at gmail.com Fri Mar 2 14:33:19 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 2 Mar 2007 08:33:19 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <45E81D98.6090407@leemhuis.info> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> Message-ID: <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> On 3/2/07, Thorsten Leemhuis wrote: > On 02.03.2007 13:36, Dennis Gilmore wrote: > > Once upon a time Thursday 01 March 2007, Karsten Wade wrote: > >> On Thu, 2007-03-01 at 11:31 -0600, Michael Stahnke wrote: > >>> Wasn't Red Hat introducing something along the lines of a LAMP stack > >>> that rolls on top of RHEL? LIke it would actually have PHP5/MySQL > >>> 5(or maybe 4.1) on top of RHEL 4. It was a separate subscription I > >>> thought, but a valid idea. The latest software for what is needed, > >>> and stable known-good software for the rest. > >> Yep, launched last September. From the right-side column here: > >> https://rhstack.108.redhat.com > >> ... is this list of apps and versions: > >> HTTPD Apache 2.0.59 > >> JBoss AS 4.0.5 > >> MySQL 5.0.30 > >> PHP 5.1.6 > >> Perl 5.8.8 > >> PostgreSQL 8.1.8 > >> Red Hat Enterprise Linux 4 Update 4 > >> I suppose that makes those applications and versions not eligible to be > >> packages in EPEL? Is eligibility decided by applications or specific > >> versions or both? Or some other combination? > > EPEL packages are not to replace packages in RHEL so of those we could maybe > > include JBoss. > > +1 (including the maybe) > > > though things get murky when it comes to Red Hat add on's > I guess I assumed we were not aiming to replace RHEL base packages. As for the other channels of software, we probably need to visit each one. Does CentOS or Scientific currently repackage the other channels that RH normally charges subscription for? Excuse my ignorance, we are strictly a RHEL shop. For example, Directory Server, Application Server, Developer Suite Channel, etc are all add-on channels that have a lot of great packages but are not part of the core RHEL base. Maybe it's a good topic for this weekend's meeting? > Exactly... > > Not sure, maybe the compromise needs to be something like this: > --- > EPEL Packages must not replace or conflict(?) with Packages from it's > base (e.g. RHEL) or directly related Add-On-Packages for it, that got > released in the same timeframe as the RHEL-Release. > --- > > CU > thl > > (?) -- conflict in the real life meaning of conflict, not the > "Conflict:" usage in RPM (that's another discussion for later) > > _______________________________________________ > Epel-devel-list mailing list > Epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From dennis at ausil.us Fri Mar 2 15:00:16 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 2 Mar 2007 09:00:16 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> References: <20070227203050.096d8b69@python3.es.egwn.lan> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> Message-ID: <200703020900.16682.dennis@ausil.us> On Friday 02 March 2007 08:33:19 am Michael Stahnke wrote: > I guess I assumed we were not aiming to replace RHEL base packages. > As for the other channels of software, we probably need to visit each > one. Does CentOS or Scientific currently repackage the other channels > that RH normally charges subscription for? Excuse my ignorance, we > are strictly a RHEL shop. > > For example, Directory Server, Application Server, Developer Suite > Channel, etc are all add-on channels that have a lot of great packages > but are not part of the core RHEL base. Maybe it's a good topic for > this weekend's meeting? > AFAIK they don't. but i have never really looked. Directory server is a special case. There is Red Hat Directory Server which is paid for and comes with support etc. Then there is Fedora Directory Server which is Free and comes with community support. I already have buy in from the Directory Server guys to get Fedora Directory Server into EPEL. Both use the same code base. -- Dennis Gilmore, RHCE From notting at redhat.com Fri Mar 2 16:54:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Mar 2007 11:54:10 -0500 Subject: Release and update procedure for EPEL In-Reply-To: <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> Message-ID: <20070302165410.GA9050@nostromo.devel.redhat.com> Michael Stahnke (mastahnke at gmail.com) said: > I guess I assumed we were not aiming to replace RHEL base packages. What happens when a package targeted for EPEL requires a bug fix in a RHEL package? (This is not theoretical, I have one of these.) Bill From fedora at leemhuis.info Fri Mar 2 17:31:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Mar 2007 18:31:35 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070302165410.GA9050@nostromo.devel.redhat.com> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> Message-ID: <45E85F77.7000700@leemhuis.info> Bill Nottingham schrieb: > Michael Stahnke (mastahnke at gmail.com) said: >> I guess I assumed we were not aiming to replace RHEL base packages. > What happens when a package targeted for EPEL requires a bug fix > in a RHEL package? (This is not theoretical, I have one of these.) AFIACS the same as in Extras in the past: File a bug, poke Red Hat maintainers (?) and pray that it gets fixed. Especially the last part is important. Sorry, sound like a joke, and in parts is one, but well, on the other hands that's how it roughly worked for community contributors in Extras(?). CU thl (?) maybe with the help of a friendly red hat employee like notting or jeremy that can poke in real life, too (?) praying is optional and you can use the god of your choice From notting at redhat.com Fri Mar 2 17:32:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Mar 2007 12:32:01 -0500 Subject: Release and update procedure for EPEL In-Reply-To: <45E85F77.7000700@leemhuis.info> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> Message-ID: <20070302173201.GA10008@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > AFIACS the same as in Extras in the past: File a bug, poke Red Hat > maintainers (?) and pray that it gets fixed. > > Especially the last part is important. > > Sorry, sound like a joke, and in parts is one, but well, on the other > hands that's how it roughly worked for community contributors in Extras(?). Sure, but it's actually a lot easier to get things fixed in Fedora, especially if it's just 'grab a newer version'. I'm not sure I can convincingly come up with a business case for rebasing guile for RHEL 4. :) Bill From fedora at leemhuis.info Fri Mar 2 17:44:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Mar 2007 18:44:50 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070302173201.GA10008@nostromo.devel.redhat.com> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> Message-ID: <45E86292.3070709@leemhuis.info> Bill Nottingham schrieb: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> AFIACS the same as in Extras in the past: File a bug, poke Red Hat >> maintainers (?) and pray that it gets fixed. >> Especially the last part is important. >> Sorry, sound like a joke, and in parts is one, but well, on the other >> hands that's how it roughly worked for community contributors in Extras(?). > Sure, but it's actually a lot easier to get things fixed in Fedora, >From my point of view it seems quite hard sometimes... But that's a different story... > especially if it's just 'grab a newer version'. I'm not sure I can > convincingly come up with a business case for rebasing guile for > RHEL 4. :) :-) Anyway, do you have any proposed solution for the problem at hand that not involves replacing or disturbing pacakges from RHEL? Then I'm all ears... CU thl From buildsys at fedoraproject.org Fri Mar 2 23:46:39 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 2 Mar 2007 18:46:39 -0500 (EST) Subject: Fedora EPEL Package Build Report 2007-03-02 Message-ID: <20070302234639.7E40515212E@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 30 NEW aiccu-2007.01.07-2.el5 NEW bitlbee-1.0.3-5.el5 NEW clamav-0.88.6-1.el5 NEW denyhosts-2.6-2.el5 NEW dircproxy-1.2.0-0.5.beta2.el5 NEW dnsmasq-2.38-1.el5 NEW duplicity-0.4.2-6.el5 NEW eggdrop-1.6.18-4.el5 NEW fedora-usermgmt-0.8.91-1.el5 NEW ganglia-3.0.4-1.el5 NEW konversation-1.0.1-2.el5 NEW libconfuse-2.5-3.el5 NEW libopm-0.1-3.20050731cvs.el5 NEW librsync-0.9.7-9.el5 NEW mock-0.6.8-4.el5 NEW nagios-2.7-2.el5 NEW p7zip-4.44-2.el5 NEW perl-Net-LibIDN-0.09-1.el5 NEW perl-Readonly-1.03-6.el5 NEW perl-Readonly-XS-1.04-7.el5 NEW php-idn-1.2-1.el5 NEW php-magickwand-0.1.8-3.el5 NEW powerman-1.0.25-2.el5 NEW rbldnsd-0.996a-2.el5 NEW rpmdevtools-5.3-1.el5 NEW rpmlint-0.78-2.el5 NEW rrdtool-1.2.18-1.el5 NEW tcllib-1.9-1.el5 NEW tcpick-0.2.1-11.el5 NEW zabbix-1.1.6-1.el5 Packages built and released for Fedora EPEL 4: 82 NEW Macaulay2-0.9.95-3.el4 NEW OpenEXR-1.4.0a-4.el4 NEW aiccu-2007.01.15-1.el4 NEW asciidoc-7.0.2-3.el4 NEW bitlbee-1.0.3-5.el4 NEW cabextract-1.1-2.el4 NEW clamav-0.88.6-1.el4 NEW cmucl-19d-3.el4 NEW crack-5.0a-1.el4 NEW denyhosts-2.6-2.el4 NEW dircproxy-1.2.0-0.5.beta2.el4 (!) dnsmasq-2.32-1.el4 : INVALID build results, not published! NEW duplicity-0.4.2-6.el4 NEW eggdrop-1.6.18-4.el4 NEW exiv2-0.12-1.el4 NEW facter-1.3.6-1.el4 NEW factory-2.0.5-11.el4 NEW fedora-usermgmt-0.8-1.el4 NEW fltk-1.1.7-5.el4 NEW fwrestart-1.04-1.el4 NEW gc-6.8-3.el4 NEW gconfmm26-2.8.1-1.el4 NEW ghex-2.8.2-4.el4 NEW glibmm24-2.4.8-1.el4 NEW gmime-2.2.1-2.el4 NEW gnome-vfsmm26-2.8.0-1.el4 NEW gtkmm24-2.4.11-2.el4 NEW hmmer-2.3.2-3.el4 NEW icu-3.6-4.el4 NEW jasper-1.900.0-3.el4 NEW libfac-2.0.5-8.el4 NEW libglademm24-2.4.2-1.el4 NEW libgnomecanvasmm26-2.8.0-1.el4 NEW libgnomemm26-2.8.0-1.el4 NEW libgnomeuimm26-2.8.0-1.el4 NEW libmpcdec-1.2.2-4.el4.1 NEW libopm-0.1-3.20050731cvs.el4 NEW librsync-0.9.7-9.el4 NEW libsigc++20-2.0.17-1.el4 NEW mail-notification-1.1-2.el4 NEW mathml-fonts-1.0-21.el4 NEW maxima-5.11.0-7.el4 (!) mercurial-0.9.1-2.el4 : INVALID build results, not published! (!) mock-0.6.8-4.el4 : INVALID build results, not published! NEW moin-1.5.7-1.el4 NEW mussh-0.7-1.el4 NEW nagios-2.7-2.el4 NEW nas-1.8-10.el4 NEW nfswatch-4.99.7-1.el4 NEW nrpe-2.7-3.el4 NEW ntl-5.4-5.el4 NEW otrs-2.1.5-1.el4 NEW p7zip-4.44-2.el4 NEW perl-Crypt-PasswdMD5-1.3-2.el4 NEW perl-Net-LibIDN-0.09-1.el4 NEW perl-Readonly-1.03-4.el4 NEW perl-Readonly-XS-1.04-3.el4 NEW perl-SOAP-Lite-0.68-3.el4 NEW powerman-1.0.25-2.el4 NEW puppet-0.22.1-2.el4 NEW python-crypto-2.0.1-1.el4 NEW python-docutils-0.4-4.el4 NEW python-imaging-1.1.6-3.el4 NEW qt4-4.2.2-5.el4 NEW rbldnsd-0.996a-2.el4 NEW revelation-0.4.7-5.el4 NEW rpmdevtools-5.3-1.el4 NEW rpmlint-0.70-1.el4 NEW rrdtool-1.2.18-1.el4 NEW rxvt-unicode-8.1-1.el4 NEW sbcl-1.0.3-1.el4 NEW sparse-0.2-1.el4 NEW tcllib-1.9-1.el4 NEW tcpick-0.2.1-11.el4 NEW tiobench-0.3.3-2.el4 NEW ttywatch-0.14-4.el4 NEW uw-imap-2006e-2.el4 NEW vnc-ltsp-config-4.0-3.el4 NEW xdg-utils-1.0.1-1.el4 NEW xforms-1.0.90-8.el4 (!) ytalk-3.3.0-6.el4 : INVALID build results, not published! NEW zabbix-1.1.6-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dennis at ausil.us Fri Mar 2 23:49:56 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 2 Mar 2007 17:49:56 -0600 Subject: Fedora EPEL Package Build Report 2007-03-02 In-Reply-To: <20070302234639.7E40515212E@buildsys.fedoraproject.org> References: <20070302234639.7E40515212E@buildsys.fedoraproject.org> Message-ID: <200703021749.56639.dennis@ausil.us> On Friday 02 March 2007 05:46:39 pm buildsys at fedoraproject.org wrote: > Packages built and released for Fedora EPEL 5: 30 > Packages built and released for Fedora EPEL 4: 82 Testing out the push scripts and the sync process from duke to Red Hat -- Dennis Gilmore, RHCE From Axel.Thimm at ATrpms.net Sat Mar 3 00:04:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 3 Mar 2007 01:04:52 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <45E86292.3070709@leemhuis.info> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> Message-ID: <20070303000452.GB23292@neu.nirvana> On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote: > Bill Nottingham schrieb: > > Thorsten Leemhuis (fedora at leemhuis.info) said: > >> AFIACS the same as in Extras in the past: File a bug, poke Red Hat > >> maintainers (?) and pray that it gets fixed. > >> Especially the last part is important. > >> Sorry, sound like a joke, and in parts is one, but well, on the other > >> hands that's how it roughly worked for community contributors in Extras(?). > > Sure, but it's actually a lot easier to get things fixed in Fedora, > > >From my point of view it seems quite hard sometimes... But that's a > different story... > > > especially if it's just 'grab a newer version'. I'm not sure I can > > convincingly come up with a business case for rebasing guile for > > RHEL 4. :) > > :-) > > Anyway, do you have any proposed solution for the problem at hand that > not involves replacing or disturbing pacakges from RHEL? Then I'm all > ears... I don't know, maybe it shows that the all-frightened "don't replace" sign paved everywhere isn't the holy grail afterall. When even one section in Red Hat replaces packages from RHEL for LAMP ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Mar 3 06:01:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 03 Mar 2007 07:01:31 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070303000452.GB23292@neu.nirvana> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> <20070303000452.GB23292@neu.nirvana> Message-ID: <45E90F3B.7050609@leemhuis.info> Axel Thimm schrieb: > On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote: >> Bill Nottingham schrieb: >>> Thorsten Leemhuis (fedora at leemhuis.info) said: >>>> AFIACS the same as in Extras in the past: File a bug, poke Red Hat >>>> maintainers (?) and pray that it gets fixed. >>>> Especially the last part is important. >>>> Sorry, sound like a joke, and in parts is one, but well, on the other >>>> hands that's how it roughly worked for community contributors in Extras(?). >>> Sure, but it's actually a lot easier to get things fixed in Fedora, >> >From my point of view it seems quite hard sometimes... But that's a >> different story... >>> especially if it's just 'grab a newer version'. I'm not sure I can >>> convincingly come up with a business case for rebasing guile for >>> RHEL 4. :) >> :-) >> Anyway, do you have any proposed solution for the problem at hand that >> not involves replacing or disturbing pacakges from RHEL? Then I'm all >> ears... > I don't know, maybe it shows that the all-frightened "don't replace" > sign paved everywhere isn't the holy grail afterall. I think it is still important for us to not replace stuff in the main repo. But we could have a (or even a lot more) repo that replaces stuff (or puts it in parallel into /opt or something) in parallel to the holy-grail-do-not-replace-EPEL-repo if we really want to. But I'd would like to get the do-not-replace-EPEL-repo started first before we start thinking about things like that. > When even one > section in Red Hat replaces packages from RHEL for LAMP ... Well, there is afaics a great difference in these two scenarios: 1: - customer buys RHEL - customer buys RHEL add-on foo - customer has a problem with RHEL package bar from RHEL due to one of the package from foo - calls RH support and problem get solved, as both products are from RH so there is no chance for them to ignore the problem 2: - customer buys RHEL - customer get package foo from EPEL that ships with a new bar which replaces bar shipped by RHEL - customer has a problem with bar or another package depending on bar - calls RH support and problem get ignored: "not our package, we can't help" CU thl From smooge at gmail.com Fri Mar 2 18:55:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 2 Mar 2007 11:55:44 -0700 Subject: Release and update procedure for EPEL In-Reply-To: <45E86292.3070709@leemhuis.info> References: <20070227203050.096d8b69@python3.es.egwn.lan> <7874d9dd0703010931w613c6371w79d9e9c83a7178df@mail.gmail.com> <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> Message-ID: <80d7e4090703021055x224c34fes19ae4028afc47ecb@mail.gmail.com> On 3/2/07, Thorsten Leemhuis wrote: > Bill Nottingham schrieb: > > Thorsten Leemhuis (fedora at leemhuis.info) said: > >> AFIACS the same as in Extras in the past: File a bug, poke Red Hat > >> maintainers (?) and pray that it gets fixed. > >> Especially the last part is important. > >> Sorry, sound like a joke, and in parts is one, but well, on the other > >> hands that's how it roughly worked for community contributors in Extras(?). > > Sure, but it's actually a lot easier to get things fixed in Fedora, > > >From my point of view it seems quite hard sometimes... But that's a > different story... > > > especially if it's just 'grab a newer version'. I'm not sure I can > > convincingly come up with a business case for rebasing guile for > > RHEL 4. :) > > :-) > > Anyway, do you have any proposed solution for the problem at hand that > not involves replacing or disturbing pacakges from RHEL? Then I'm all > ears... > That would be the APEL list... with a nice APEL with a worm in it. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Sat Mar 3 09:26:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 Mar 2007 10:26:01 +0100 Subject: package stability Message-ID: <20070303092601.GA2881@free.fr> Hello, Do we want to keep API/ABI stable over the corresponding RHEL release? I think yes, but then we should really make sure that some libs don't go to EPEL (for an example of a lib I maintain there is libdap which changes API every 6 months or so). Is there something similar for apps, for example that searching paths command-line options, config files, file formats, are backward compatible? If we impose such constraints, maybe there could be a discussion before a package enters EPEL. Not a formal review because there should be no packaging/usability issues, but a verification that the package is stable enough and there are enough people/firms interested such that if the maintainer stops maintaining a package that needs work it won't be really unmaintained. -- Pat From Axel.Thimm at ATrpms.net Sat Mar 3 10:48:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 3 Mar 2007 11:48:40 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <45E90F3B.7050609@leemhuis.info> References: <1172812831.4651.497.camel@erato.phig.org> <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> <20070303000452.GB23292@neu.nirvana> <45E90F3B.7050609@leemhuis.info> Message-ID: <20070303104840.GB27400@neu.nirvana> On Sat, Mar 03, 2007 at 07:01:31AM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Fri, Mar 02, 2007 at 06:44:50PM +0100, Thorsten Leemhuis wrote: > >> Bill Nottingham schrieb: > >>> especially if it's just 'grab a newer version'. I'm not sure I can > >>> convincingly come up with a business case for rebasing guile for > >>> RHEL 4. :) > >> :-) > >> Anyway, do you have any proposed solution for the problem at hand that > >> not involves replacing or disturbing pacakges from RHEL? Then I'm all > >> ears... > > I don't know, maybe it shows that the all-frightened "don't replace" > > sign paved everywhere isn't the holy grail afterall. > > I think it is still important for us to not replace stuff in the main repo. I'm not suggesting the main repo (well, I'm not suggesting anything at this point in time, I'll let Bill suggest "epelplus" and take the blame ;) > > When even one section in Red Hat replaces packages from RHEL for > > LAMP ... > > Well, there is afaics a great difference in these two scenarios: > > 1: > - customer buys RHEL > - customer buys RHEL add-on foo > - customer has a problem with RHEL package bar from RHEL due to one of > the package from foo > - calls RH support and problem get solved, as both products are from RH > so there is no chance for them to ignore the problem > > 2: > - customer buys RHEL > - customer get package foo from EPEL that ships with a new bar which > replaces bar shipped by RHEL > - customer has a problem with bar or another package depending on bar > - calls RH support and problem get ignored: "not our package, we can't > help" Oh, we have much worse that that already in place: 3: - customer buys RHEL - customer get package foo from EPEL that ships with a bar which does not exist in RHEL, so everybody thinks it's fine - bar fubars customer's system (bar is a plugin, daemon, kernel module, or something similar) - customer report to RH that system does not work (doesn't boot, firefox crashes, kernel oops) - RH speds support time on customer only to find out that the bug is not directly in firefox/kernel/etc. but in a pure add-on package In fact in all these years of "replacements" 3) has happened far more often than 2) - the metrics would be 3)/#add-ons compared to 2)/#replacment, but 2) is very close to zero. So, if we are not in a worse position that we already are, why not benefit and have Bill update/fix guille in the "epelplus" repo? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 3 10:51:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 3 Mar 2007 11:51:14 +0100 Subject: package stability In-Reply-To: <20070303092601.GA2881@free.fr> References: <20070303092601.GA2881@free.fr> Message-ID: <20070303105114.GC27400@neu.nirvana> On Sat, Mar 03, 2007 at 10:26:01AM +0100, Patrice Dumas wrote: > Do we want to keep API/ABI stable over the corresponding RHEL release? It would be interesting to have a document that described RH's specs in this area. E.g. which API/ABI are more important that others. RHEL has certainly kept some parts more flexible than others, for example wireless API/ABI on almost each kernel update. It's probably a weighing of pros and cons per case. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sat Mar 3 15:54:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 03 Mar 2007 09:54:51 -0600 Subject: package stability In-Reply-To: <20070303092601.GA2881@free.fr> References: <20070303092601.GA2881@free.fr> Message-ID: <45E99A4B.4000905@math.unl.edu> Patrice Dumas wrote: > Do we want to keep API/ABI stable over the corresponding RHEL release? > I think yes, but then we should really make sure that some libs don't > go to EPEL (for an example of a lib I maintain there is libdap which > changes API every 6 months or so). As long a reasonable exceptions can be made, I'm ok with it. -- Rex From fedora at leemhuis.info Sat Mar 3 17:04:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 03 Mar 2007 18:04:42 +0100 Subject: Meeting log from last week Message-ID: <45E9AAAA.5010303@leemhuis.info> Hi, just FYI, I uploaded the meeting log from last week to the wiki: http://www.fedoraproject.org/wiki/EPEL/Meetings/20070225 I wanted to write a summary, but stopped soon -- it was more a general chat about different things without much order in it, and that was to hard to summarize. Next meeting is tomorrow, at 16:00 UTC in #fedora-meeting on freenode; I hope to update the schedule with some details beforehand. Hope to see you guys there tomorrow. BTW, we probably should revisit the meeting time again soon, to make sure that most of the people EPEL that are interested in EPEL can participate. Cu thl From sundaram at fedoraproject.org Sun Mar 4 21:59:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 05 Mar 2007 03:29:19 +0530 Subject: rename fedora-usermgmt? Message-ID: <45EB4137.7040608@fedoraproject.org> Hi I see fedora-usermgmt has been made available for EPEL. That is probably going to cause some confusion. Maybe rename it into system-usermgmt or something more distribution neutral. The other packages except for fedora-ds-base are all indeed specific to Fedora. Rahul From mmcgrath at redhat.com Sun Mar 4 22:07:15 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 04 Mar 2007 16:07:15 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <45EB4137.7040608@fedoraproject.org> References: <45EB4137.7040608@fedoraproject.org> Message-ID: <45EB4313.4060907@redhat.com> Rahul Sundaram wrote: > Hi > > I see fedora-usermgmt has been made available for EPEL. That is > probably going to cause some confusion. Maybe rename it into > system-usermgmt or something more distribution neutral. The other > packages except for fedora-ds-base are all indeed specific to Fedora. > > Rahul Why don't we just remove it? -Mike From dennis at ausil.us Sun Mar 4 22:41:08 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 4 Mar 2007 16:41:08 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <45EB4313.4060907@redhat.com> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> Message-ID: <200703041641.18529.dennis@ausil.us> Once upon a time Sunday 04 March 2007, Mike McGrath wrote: > Rahul Sundaram wrote: > > Hi > > > > I see fedora-usermgmt has been made available for EPEL. That is > > probably going to cause some confusion. Maybe rename it into > > system-usermgmt or something more distribution neutral. The other > > packages except for fedora-ds-base are all indeed specific to Fedora. > > > > Rahul > > Why don't we just remove it? Mike, i know you hate it :) but alot of packages use it. Rahul, that is what its named upstream. if you want it renamed file a bug. this is not the appropriate place for discussion on this. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sun Mar 4 23:43:41 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 04 Mar 2007 17:43:41 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <200703041641.18529.dennis@ausil.us> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> Message-ID: <45EB59AD.3060509@redhat.com> Dennis Gilmore wrote: > Once upon a time Sunday 04 March 2007, Mike McGrath wrote: > >> Rahul Sundaram wrote: >> >>> Hi >>> >>> I see fedora-usermgmt has been made available for EPEL. That is >>> probably going to cause some confusion. Maybe rename it into >>> system-usermgmt or something more distribution neutral. The other >>> packages except for fedora-ds-base are all indeed specific to Fedora. >>> >>> Rahul >>> >> Why don't we just remove it? >> > Mike, i know you hate it :) but alot of packages use it. > More packages don't use it and no packages in RHEL use it. I'll stop now, I don't want to be "that guy" :-D -Mike From smooge at gmail.com Mon Mar 5 01:47:41 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 4 Mar 2007 18:47:41 -0700 Subject: rename fedora-usermgmt? In-Reply-To: <45EB59AD.3060509@redhat.com> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> Message-ID: <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> On 3/4/07, Mike McGrath wrote: > Dennis Gilmore wrote: > > Once upon a time Sunday 04 March 2007, Mike McGrath wrote: > > > >> Rahul Sundaram wrote: > >> > >>> Hi > >>> > >>> I see fedora-usermgmt has been made available for EPEL. That is > >>> probably going to cause some confusion. Maybe rename it into > >>> system-usermgmt or something more distribution neutral. The other > >>> packages except for fedora-ds-base are all indeed specific to Fedora. > >>> > >>> Rahul > >>> > >> Why don't we just remove it? > >> > > Mike, i know you hate it :) but alot of packages use it. > > > > More packages don't use it and no packages in RHEL use it. I'll stop > now, I don't want to be "that guy" :-D > Can I be that guy. Personally I think F-U-M has caused me more problems moving apps over into an enterprise environment. Trying to get packages installed before LDAP is up etc and having to deal with oh look clamav is now the same as Johnny the Hacker. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Axel.Thimm at ATrpms.net Mon Mar 5 11:32:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 12:32:08 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> Message-ID: <20070305113208.GK29562@neu.nirvana> On Sun, Mar 04, 2007 at 06:47:41PM -0700, Stephen John Smoogen wrote: > On 3/4/07, Mike McGrath wrote: > >Dennis Gilmore wrote: > >> Once upon a time Sunday 04 March 2007, Mike McGrath wrote: > >> > >>> Rahul Sundaram wrote: > >>> > >>>> Hi > >>>> > >>>> I see fedora-usermgmt has been made available for EPEL. That is > >>>> probably going to cause some confusion. Maybe rename it into > >>>> system-usermgmt or something more distribution neutral. The other > >>>> packages except for fedora-ds-base are all indeed specific to Fedora. > >>>> > >>>> Rahul > >>>> > >>> Why don't we just remove it? > >>> > >> Mike, i know you hate it :) but alot of packages use it. > >> > > > >More packages don't use it and no packages in RHEL use it. I'll stop > >now, I don't want to be "that guy" :-D > > > > Can I be that guy. Personally I think F-U-M has caused me more > problems moving apps over into an enterprise environment. Trying to > get packages installed before LDAP is up etc and having to deal with > oh look clamav is now the same as Johnny the Hacker. FWIW I hate it, too, anyone here around with other feelings for that? Maybe we're all "that guy" ;) Anyway please kill and *ban* it, we should endorse using that mechanism. If an application really needs a fixed uid/gid let's provide it one and let's fix the uid/gid 100-499 space being eaten from low to high (high to low would be 1000x better) which is dangling for years. If non-fixed system account had been assigned 499 lowwards then we'd have now space to extend to say uid/gid 200 ... I think I somewhere have an old bugzilla against it, lemme see ... here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190523 A perfect example of reporter and assignee not being able to communicate. Feel free to add your comments there to make something happen. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 5 12:07:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Mar 2007 13:07:42 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <20070305113208.GK29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> Message-ID: <45EC080E.1080302@leemhuis.info> On 05.03.2007 12:32, Axel Thimm wrote: > On Sun, Mar 04, 2007 at 06:47:41PM -0700, Stephen John Smoogen wrote: >> On 3/4/07, Mike McGrath wrote: >>> Dennis Gilmore wrote: >>>> Once upon a time Sunday 04 March 2007, Mike McGrath wrote: >>>>> Rahul Sundaram wrote: >>>>>> I see fedora-usermgmt has been made available for EPEL. That is >>>>>> probably going to cause some confusion. Maybe rename it into >>>>>> system-usermgmt or something more distribution neutral. The other >>>>>> packages except for fedora-ds-base are all indeed specific to Fedora. >>>>> Why don't we just remove it? >>>> Mike, i know you hate it :) but alot of packages use it. >>> More packages don't use it and no packages in RHEL use it. I'll stop >>> now, I don't want to be "that guy" :-D >> Can I be that guy. Personally I think F-U-M has caused me more >> problems moving apps over into an enterprise environment. Trying to >> get packages installed before LDAP is up etc and having to deal with >> oh look clamav is now the same as Johnny the Hacker. > > FWIW I hate it, too, anyone here around with other feelings for that? > Maybe we're all "that guy" ;) > > Anyway please kill and *ban* it, we should endorse using that mechanism. > > If an application really needs a fixed uid/gid let's provide it one > and let's fix the uid/gid 100-499 space being eaten from low to high > (high to low would be 1000x better) which is dangling for years. If > non-fixed system account had been assigned 499 lowwards then we'd have > now space to extend to say uid/gid 200 ... Just my 2 cent: Yes, we need to find a solution, whatever that might look like. Writing and enforcing a fedora-usermgmt successor could be one, extending the UID/GID space another one. Someone just needs to drive the whole issue forward and get it approved by the Fedora community, FPC and FESCo. But the current mix of using fedora-usermgmt in some packages and not using it in others just sucks. CU thl From Axel.Thimm at ATrpms.net Mon Mar 5 12:18:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 13:18:05 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC080E.1080302@leemhuis.info> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <45EC080E.1080302@leemhuis.info> Message-ID: <20070305121805.GO29562@neu.nirvana> On Mon, Mar 05, 2007 at 01:07:42PM +0100, Thorsten Leemhuis wrote: > On 05.03.2007 12:32, Axel Thimm wrote: > >On Sun, Mar 04, 2007 at 06:47:41PM -0700, Stephen John Smoogen wrote: > >>On 3/4/07, Mike McGrath wrote: > >>>Dennis Gilmore wrote: > >>>>Once upon a time Sunday 04 March 2007, Mike McGrath wrote: > >>>>>Rahul Sundaram wrote: > >>>>>>I see fedora-usermgmt has been made available for EPEL. That is > >>>>>>probably going to cause some confusion. Maybe rename it into > >>>>>>system-usermgmt or something more distribution neutral. The other > >>>>>>packages except for fedora-ds-base are all indeed specific to Fedora. > >>>>>Why don't we just remove it? > >>>>Mike, i know you hate it :) but alot of packages use it. > >>>More packages don't use it and no packages in RHEL use it. I'll stop > >>>now, I don't want to be "that guy" :-D > >>Can I be that guy. Personally I think F-U-M has caused me more > >>problems moving apps over into an enterprise environment. Trying to > >>get packages installed before LDAP is up etc and having to deal with > >>oh look clamav is now the same as Johnny the Hacker. > > > >FWIW I hate it, too, anyone here around with other feelings for that? > >Maybe we're all "that guy" ;) > > > >Anyway please kill and *ban* it, we should endorse using that mechanism. > > > >If an application really needs a fixed uid/gid let's provide it one > >and let's fix the uid/gid 100-499 space being eaten from low to high > >(high to low would be 1000x better) which is dangling for years. If > >non-fixed system account had been assigned 499 lowwards then we'd have > >now space to extend to say uid/gid 200 ... > > Just my 2 cent: Yes, we need to find a solution, whatever that might > look like. Writing and enforcing a fedora-usermgmt successor could be > one, not really, it moves the problem from a global one to a site-specific one. We need to deal with it on a global scale. > extending the UID/GID space another one. Someone just needs to drive > the whole issue forward and get it approved by the Fedora community, > FPC and FESCo. I'd vote for thl, go thl, go! :) > But the current mix of using fedora-usermgmt in some packages and > not using it in others just sucks. That's why we should allow it to infest the RHEL world, too. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Mar 5 12:19:57 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Mar 2007 13:19:57 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <20070305113208.GK29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> Message-ID: <20070305131957.56a4a43a@python3.es.egwn.lan> Axel Thimm wrote : > FWIW I hate it, too, anyone here around with other feelings for that? > Maybe we're all "that guy" ;) Seems so. A nice clean list of all fixes uids and gids used in Fedora is what I've always wished for. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.11 0.08 0.12 From Axel.Thimm at ATrpms.net Mon Mar 5 12:30:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 13:30:14 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <20070305131957.56a4a43a@python3.es.egwn.lan> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305131957.56a4a43a@python3.es.egwn.lan> Message-ID: <20070305123014.GP29562@neu.nirvana> On Mon, Mar 05, 2007 at 01:19:57PM +0100, Matthias Saou wrote: > Axel Thimm wrote : > > > FWIW I hate it, too, anyone here around with other feelings for that? > > Maybe we're all "that guy" ;) > > Seems so. A nice clean list of all fixes uids and gids used in Fedora > is what I've always wished for. /usr/share/doc/setup-*/uidgid is supposed to be just that, or not? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 5 12:47:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Mar 2007 13:47:27 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <20070305121805.GO29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <45EC080E.1080302@leemhuis.info> <20070305121805.GO29562@neu.nirvana> Message-ID: <45EC115F.30809@leemhuis.info> On 05.03.2007 13:18, Axel Thimm wrote: > On Mon, Mar 05, 2007 at 01:07:42PM +0100, Thorsten Leemhuis wrote: >> Just my 2 cent: Yes, we need to find a solution, whatever that might >> look like. Writing and enforcing a fedora-usermgmt successor could be >> one, > not really, it moves the problem from a global one to a site-specific > one. We need to deal with it on a global scale. Maybe. I never looked to much into this shit, but seems to me all solutions so far are painful or hard to achieve, so we have to find the worst evil, whatever that might look like... >> extending the UID/GID space another one. Someone just needs to drive >> the whole issue forward and get it approved by the Fedora community, >> FPC and FESCo. > I'd vote for thl, go thl, go! :) -1 (enough on my plate already) >> But the current mix of using fedora-usermgmt in some packages and >> not using it in others just sucks. > That's why we should allow it to infest the RHEL world, too. Shouldn't? Cu thl From Axel.Thimm at ATrpms.net Mon Mar 5 12:54:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 13:54:32 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC115F.30809@leemhuis.info> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <45EC080E.1080302@leemhuis.info> <20070305121805.GO29562@neu.nirvana> <45EC115F.30809@leemhuis.info> Message-ID: <20070305125432.GS29562@neu.nirvana> On Mon, Mar 05, 2007 at 01:47:27PM +0100, Thorsten Leemhuis wrote: > On 05.03.2007 13:18, Axel Thimm wrote: > >On Mon, Mar 05, 2007 at 01:07:42PM +0100, Thorsten Leemhuis wrote: > >>Just my 2 cent: Yes, we need to find a solution, whatever that might > >>look like. Writing and enforcing a fedora-usermgmt successor could be > >>one, > >not really, it moves the problem from a global one to a site-specific > >one. We need to deal with it on a global scale. > > Maybe. I never looked to much into this shit, but seems to me all > solutions so far are painful or hard to achieve, so we have to find the > worst evil, whatever that might look like... The worst? ;) > >>extending the UID/GID space another one. Someone just needs to drive > >>the whole issue forward and get it approved by the Fedora community, > >>FPC and FESCo. > >I'd vote for thl, go thl, go! :) > > -1 (enough on my plate already) Could you perhaps try to find a volunteer in the fesco group? > >>But the current mix of using fedora-usermgmt in some packages and > >>not using it in others just sucks. > >That's why we should allow it to infest the RHEL world, too. > > Shouldn't? Yes, looks like we both like to argue against ourselves ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 5 13:05:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Mar 2007 14:05:17 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <20070305125432.GS29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <45EC080E.1080302@leemhuis.info> <20070305121805.GO29562@neu.nirvana> <45EC115F.30809@leemhuis.info> <20070305125432.GS29562@neu.nirvana> Message-ID: <45EC158D.5050501@leemhuis.info> On 05.03.2007 13:54, Axel Thimm wrote: > On Mon, Mar 05, 2007 at 01:47:27PM +0100, Thorsten Leemhuis wrote: >> On 05.03.2007 13:18, Axel Thimm wrote: >>>> extending the UID/GID space another one. Someone just needs to drive >>>> the whole issue forward and get it approved by the Fedora community, >>>> FPC and FESCo. >>> I'd vote for thl, go thl, go! :) >> -1 (enough on my plate already) > Could you perhaps try to find a volunteer in the fesco group? I'm not in FESCo anymore and I doubt I would find one. So no. I further think this effort might be better driven by the Packaging Committee (but I'm not sure on that). Cu thl From Axel.Thimm at ATrpms.net Mon Mar 5 13:08:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 14:08:59 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC158D.5050501@leemhuis.info> References: <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <45EC080E.1080302@leemhuis.info> <20070305121805.GO29562@neu.nirvana> <45EC115F.30809@leemhuis.info> <20070305125432.GS29562@neu.nirvana> <45EC158D.5050501@leemhuis.info> Message-ID: <20070305130859.GT29562@neu.nirvana> On Mon, Mar 05, 2007 at 02:05:17PM +0100, Thorsten Leemhuis wrote: > On 05.03.2007 13:54, Axel Thimm wrote: > >On Mon, Mar 05, 2007 at 01:47:27PM +0100, Thorsten Leemhuis wrote: > >>On 05.03.2007 13:18, Axel Thimm wrote: > >>>>extending the UID/GID space another one. Someone just needs to drive > >>>>the whole issue forward and get it approved by the Fedora community, > >>>>FPC and FESCo. > >>>I'd vote for thl, go thl, go! :) > >>-1 (enough on my plate already) > >Could you perhaps try to find a volunteer in the fesco group? > > I'm not in FESCo anymore and I doubt I would find one. So no. > > I further think this effort might be better driven by the Packaging > Committee (but I'm not sure on that). could make sense, but that's beyond the current mandate of the FPC, so fesco would have to extend it to cover this, before the FPC is considered authoritative on uid/gid. Anyway maybe it's off-topic on EPEL, we should perhaps just agree on banning fedora-usermgmt from EPEL and fix packages that make use of it as they come into play. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Mon Mar 5 14:22:10 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 05 Mar 2007 09:22:10 -0500 Subject: rename fedora-usermgmt? In-Reply-To: <20070305123014.GP29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305131957.56a4a43a@python3.es.egwn.lan> <20070305123014.GP29562@neu.nirvana> Message-ID: <45EC2792.4010605@redhat.com> Axel Thimm wrote: > On Mon, Mar 05, 2007 at 01:19:57PM +0100, Matthias Saou wrote: >> Axel Thimm wrote : >> >>> FWIW I hate it, too, anyone here around with other feelings for that? >>> Maybe we're all "that guy" ;) >> Seems so. A nice clean list of all fixes uids and gids used in Fedora >> is what I've always wished for. > > /usr/share/doc/setup-*/uidgid is supposed to be just that, or not? Yes, but only up to uid 100. I remember having a discussion about this with Jeremy several months ago, and istr him liking the idea of us creeping into at least the 101-499 space for the hard-coded uidgid list, but that someone needed to actively push this. One thing that needs clarification is the (iirc) LSB, with respect to what 101-499 can be used for. We'd like to maintain LSB compliance, but the guidelines were a bit hazy in this area, so perhaps pushing the LSB to clarify how that uid space should be used is the first step to deep-sixing the atrocity that is fedora-usermgmt (hey, I'm that guy too). -- Jarod Wilson jwilson at redhat.com -------------- 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 Mon Mar 5 14:25:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Mar 2007 09:25:24 -0500 Subject: rename fedora-usermgmt? In-Reply-To: <20070305113208.GK29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> Message-ID: <20070305142524.GA2657@jadzia.bu.edu> On Mon, Mar 05, 2007 at 12:32:08PM +0100, Axel Thimm wrote: > FWIW I hate it, too, anyone here around with other feelings for that? > Maybe we're all "that guy" ;) Yes, I am *also* that guy. Can't we just have a Fedora project registry of assigned numbers and stick to it? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Mon Mar 5 14:36:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 08:36:01 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <20070305142524.GA2657@jadzia.bu.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> Message-ID: <45EC2AD1.2000203@math.unl.edu> Matthew Miller wrote: > On Mon, Mar 05, 2007 at 12:32:08PM +0100, Axel Thimm wrote: >> FWIW I hate it, too, anyone here around with other feelings for that? >> Maybe we're all "that guy" ;) > > Yes, I am *also* that guy. > > Can't we just have a Fedora project registry of assigned numbers and stick > to it? Fact is: fedora-usermgmt solves a (nitch) problem, regardless of whether folks agree with it's implementation. Imo, maintainers of epel packages, should be free to use it, if they wish. It would be inappropriate, imo, to implement a blanket "no fedora-usermngt" policy in epel, unless, of course, no maintainer for it can be found for epel. -- Rex From Axel.Thimm at ATrpms.net Mon Mar 5 14:37:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 15:37:38 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC2792.4010605@redhat.com> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305131957.56a4a43a@python3.es.egwn.lan> <20070305123014.GP29562@neu.nirvana> <45EC2792.4010605@redhat.com> Message-ID: <20070305143738.GW29562@neu.nirvana> On Mon, Mar 05, 2007 at 09:22:10AM -0500, Jarod Wilson wrote: > Axel Thimm wrote: > > On Mon, Mar 05, 2007 at 01:19:57PM +0100, Matthias Saou wrote: > >> Axel Thimm wrote : > >> > >>> FWIW I hate it, too, anyone here around with other feelings for that? > >>> Maybe we're all "that guy" ;) > >> Seems so. A nice clean list of all fixes uids and gids used in Fedora > >> is what I've always wished for. > > > > /usr/share/doc/setup-*/uidgid is supposed to be just that, or not? > > Yes, but only up to uid 100. I remember having a discussion about this > with Jeremy several months ago, and istr him liking the idea of us > creeping into at least the 101-499 space for the hard-coded uidgid list, > but that someone needed to actively push this. One thing that needs > clarification is the (iirc) LSB, with respect to what 101-499 can be > used for. We'd like to maintain LSB compliance, but the guidelines were > a bit hazy in this area, so perhaps pushing the LSB to clarify how that > uid space should be used is the first step to deep-sixing the atrocity > that is fedora-usermgmt (hey, I'm that guy too). Not all space is available for fixed uid/gid. Currently we have 0-99 (or 100? anyway): fixed system uid/gid 100-499: non-fixed system accounts 500-...: user accounts We will still need non-fixed system accounts for the less integrated and less critical uid/gid that packages will want to use. The problem is that the space 100-499 is used by a a few dozen packages which is quite a waste. And the next problem is that when they ask useradd for some random system uid/gid they get it handed from 100 upwards, so the space gets fragmented. Therefore useradd -r should start handing out from 499 downwards so at some point in time we will have the liberty to move the bar between fixed/non-fixed uid/gids higher to say 200 for example. But as long as useradd allocated bottom-to-top we will have more trouble to lift that bar. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 5 14:38:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 15:38:13 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <20070305142524.GA2657@jadzia.bu.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> Message-ID: <20070305143813.GX29562@neu.nirvana> On Mon, Mar 05, 2007 at 09:25:24AM -0500, Matthew Miller wrote: > On Mon, Mar 05, 2007 at 12:32:08PM +0100, Axel Thimm wrote: > > FWIW I hate it, too, anyone here around with other feelings for that? > > Maybe we're all "that guy" ;) > > Yes, I am *also* that guy. > > Can't we just have a Fedora project registry of assigned numbers and stick > to it? We already have that and I think it's called Bill Nottingham for now ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 5 14:40:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 15:40:47 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC2AD1.2000203@math.unl.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> Message-ID: <20070305144047.GY29562@neu.nirvana> On Mon, Mar 05, 2007 at 08:36:01AM -0600, Rex Dieter wrote: > Matthew Miller wrote: > >On Mon, Mar 05, 2007 at 12:32:08PM +0100, Axel Thimm wrote: > >>FWIW I hate it, too, anyone here around with other feelings for that? > >>Maybe we're all "that guy" ;) > > > >Yes, I am *also* that guy. > > > >Can't we just have a Fedora project registry of assigned numbers and stick > >to it? > > Fact is: fedora-usermgmt solves a (nitch) problem, regardless of > whether folks agree with it's implementation. > > Imo, maintainers of epel packages, should be free to use it, if they > wish. It would be inappropriate, imo, to implement a blanket "no > fedora-usermngt" policy in epel, unless, of course, no maintainer for it > can be found for epel. Please no, it requires the admin's attention to setup some random space in his user uid/gid space, and if he misses it (who really cares about yet another package pulled in by yum install foo) or forgets this setup he runs into possible uid/gid conflcits between packages and users. We don't want that for Fedora and even less for RHEL. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Mon Mar 5 14:43:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Mar 2007 09:43:54 -0500 Subject: rename fedora-usermgmt? In-Reply-To: <45EC2AD1.2000203@math.unl.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> Message-ID: <20070305144354.GA4035@jadzia.bu.edu> On Mon, Mar 05, 2007 at 08:36:01AM -0600, Rex Dieter wrote: > Fact is: fedora-usermgmt solves a (nitch) problem, regardless of > whether folks agree with it's implementation. But the problem it solves is "lack of an official list of reserved system userids". When Fedora was a third-party repository, it could really do much about the official list, but now that we are fedora, we can. And particularly since the fedora-usermgmt approach is most problematic in enterprise environments, now's a good time to fix the problem rather than patch around it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Mon Mar 5 14:45:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 08:45:05 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <20070305144047.GY29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> Message-ID: <45EC2CF1.3070308@math.unl.edu> Axel Thimm wrote: > On Mon, Mar 05, 2007 at 08:36:01AM -0600, Rex Dieter wrote: >> Matthew Miller wrote: >>> On Mon, Mar 05, 2007 at 12:32:08PM +0100, Axel Thimm wrote: >>>> FWIW I hate it, too, anyone here around with other feelings for that? >>>> Maybe we're all "that guy" ;) >>> Yes, I am *also* that guy. >>> >>> Can't we just have a Fedora project registry of assigned numbers and stick >>> to it? >> Fact is: fedora-usermgmt solves a (nitch) problem, regardless of >> whether folks agree with it's implementation. >> >> Imo, maintainers of epel packages, should be free to use it, if they >> wish. It would be inappropriate, imo, to implement a blanket "no >> fedora-usermngt" policy in epel, unless, of course, no maintainer for it >> can be found for epel. > > Please no, it requires the admin's attention to setup some random > space in his user uid/gid space That's news to me. My recollection of the last "usermgmt" debate was that if left unconfigured, fedora-usermgmt (essentially) is exactly the same as the usual useradd/userdel. It only changes behavior when modified/custmized by admin. -- Rex From mmcgrath at redhat.com Mon Mar 5 14:47:59 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 05 Mar 2007 08:47:59 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <20070305144354.GA4035@jadzia.bu.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144354.GA4035@jadzia.bu.edu> Message-ID: <45EC2D9F.4040307@redhat.com> Matthew Miller wrote: > On Mon, Mar 05, 2007 at 08:36:01AM -0600, Rex Dieter wrote: > >> Fact is: fedora-usermgmt solves a (nitch) problem, regardless of >> whether folks agree with it's implementation. >> > > But the problem it solves is "lack of an official list of reserved system > userids". When Fedora was a third-party repository, it could really do much > about the official list, but now that we are fedora, we can. > > And particularly since the fedora-usermgmt approach is most problematic in > enterprise environments, now's a good time to fix the problem rather than > patch around it. > I might be alone here but... I've never once had a problem. Anything that is going to be considered needs to completely replace useradd. Any system that involves using both is faulty. -Mike From rdieter at math.unl.edu Mon Mar 5 14:52:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 08:52:29 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <20070305144354.GA4035@jadzia.bu.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144354.GA4035@jadzia.bu.edu> Message-ID: <45EC2EAD.7070306@math.unl.edu> Matthew Miller wrote: > On Mon, Mar 05, 2007 at 08:36:01AM -0600, Rex Dieter wrote: >> Fact is: fedora-usermgmt solves a (nitch) problem, regardless of >> whether folks agree with it's implementation. > > But the problem it solves is "lack of an official list of reserved system > userids". When Fedora was a third-party repository, it could really do much > about the official list, but now that we are fedora, we can. The other problem addressed by fedora-usermngt is that we'll also eventually run out of fixed 100-499 id's as well. > And particularly since the fedora-usermgmt approach is most problematic in > enterprise environments Again, news to me. How is it problematic? My perception of this discussion is that it's mostly FUD, in not understanding the *real* fundamental issues fedora-usermngt addresses, and inventing theoretical problems that it may cause. Regardless, imo, this is a *fedora* issue, and should be addressed globally, not here in epel-only space. -- Rex From rdieter at math.unl.edu Mon Mar 5 14:54:19 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 08:54:19 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <45EC2D9F.4040307@redhat.com> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144354.GA4035@jadzia.bu.edu> <45EC2D9F.4040307@redhat.com> Message-ID: <45EC2F1B.3000200@math.unl.edu> Mike McGrath wrote: > I might be alone here but... I've never once had a problem. Anything > that is going to be considered needs to completely replace useradd. Any > system that involves using both is faulty. Such an attempt was made in the not too distant past, but the long and short of it was that most folks didn't accept the premise that a problem existed that required fixing. -- Rex From Axel.Thimm at ATrpms.net Mon Mar 5 14:58:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 15:58:29 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC2CF1.3070308@math.unl.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> Message-ID: <20070305145829.GZ29562@neu.nirvana> On Mon, Mar 05, 2007 at 08:45:05AM -0600, Rex Dieter wrote: > Axel Thimm wrote: > >On Mon, Mar 05, 2007 at 08:36:01AM -0600, Rex Dieter wrote: > >>Matthew Miller wrote: > >>>On Mon, Mar 05, 2007 at 12:32:08PM +0100, Axel Thimm wrote: > >>>>FWIW I hate it, too, anyone here around with other feelings for that? > >>>>Maybe we're all "that guy" ;) > >>>Yes, I am *also* that guy. > >>> > >>>Can't we just have a Fedora project registry of assigned numbers and > >>>stick > >>>to it? > >>Fact is: fedora-usermgmt solves a (nitch) problem, regardless of > >>whether folks agree with it's implementation. > >> > >>Imo, maintainers of epel packages, should be free to use it, if they > >>wish. It would be inappropriate, imo, to implement a blanket "no > >>fedora-usermngt" policy in epel, unless, of course, no maintainer for it > >>can be found for epel. > > > >Please no, it requires the admin's attention to setup some random > >space in his user uid/gid space > > That's news to me. My recollection of the last "usermgmt" debate was > that if left unconfigured, fedora-usermgmt (essentially) is exactly the > same as the usual useradd/userdel. It only changes behavior when > modified/custmized by admin. That's news to me, too, but this more or less would just mean that the bomb is delivered unarmed and just waits for an innocent admin to press on the red knob. ;) But more seriously, what exactly would fedora-usermgmt do, if asked to allocate the "relative" uid 42? Ignore the request? The packager that decided to use fedora-usermgmt over plain useradd -r must have had his reasons to not let this be a random selection and still he finally gets a random id. The original intent of fedora-usermgmt was to deal with packages requiring *fixed* uid/gid, so the fallback to useradd -r will be breaking that package, or that package didn't need a fixed uid/gid in the first place. In a nutshell: Optional usage of fedora-usermgmt with a fallback to useradd -r contradicts to the pupose of fedora-usermgmt. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 5 15:09:34 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 09:09:34 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <20070305145829.GZ29562@neu.nirvana> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> Message-ID: <45EC32AE.1070006@math.unl.edu> Axel Thimm wrote: > The original intent of fedora-usermgmt was to deal with packages > requiring *fixed* uid/gid, so the fallback to useradd -r will be > breaking that package, or that package didn't need a fixed uid/gid in > the first place. The intent is to implement (quasi?) fixed uid/gid assignment within the 100-499 space, provided admin's configured it, so they'd have consistent uid/gid assignment across their enterprise. Have I mentioned this is the wrong forum for this discussion? -- Rex From mmcgrath at redhat.com Mon Mar 5 15:13:22 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 05 Mar 2007 09:13:22 -0600 Subject: rename fedora-usermgmt? In-Reply-To: <45EC32AE.1070006@math.unl.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> Message-ID: <45EC3392.9050201@redhat.com> Rex Dieter wrote: > Have I mentioned this is the wrong forum for this discussion? We might come up with a different solution for epel then for extras though that wouldn't be optimal. I say we let the voting app decide. -Mike From fedora at leemhuis.info Mon Mar 5 16:15:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Mar 2007 17:15:29 +0100 Subject: rename fedora-usermgmt? In-Reply-To: <45EC2EAD.7070306@math.unl.edu> References: <45EB4137.7040608@fedoraproject.org> <45EB4313.4060907@redhat.com> <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144354.GA4035@jadzia.bu.edu> <45EC2EAD.7070306@math.unl.edu> Message-ID: <45EC4221.1040504@leemhuis.info> Rex Dieter schrieb: > [...] > Regardless, imo, this is a *fedora* issue, and should be addressed > globally, not here in epel-only space. +1 Please let's move this discussion for fedora-packaging -- that's where it belongs. CU thl From mschwendt.tmp0701.nospam at arcor.de Mon Mar 5 16:43:22 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 5 Mar 2007 17:43:22 +0100 Subject: Meeting log from last week In-Reply-To: <45E9AAAA.5010303@leemhuis.info> References: <45E9AAAA.5010303@leemhuis.info> Message-ID: <20070305174322.04fa845a.mschwendt.tmp0701.nospam@arcor.de> On Sat, 03 Mar 2007 18:04:42 +0100, Thorsten Leemhuis wrote: > Hi, > > just FYI, I uploaded the meeting log from last week to the wiki: > > http://www.fedoraproject.org/wiki/EPEL/Meetings/20070225 Two corrections here: > 00:20 < thl> | the current push scripts also don't handle testing nicely They don't handle it at all. More important, it's not implemented in the buildsys, so there's no support for it to start with. Consider that everything that enters "needsign" is available to subsequent build-jobs immediately. No separate build targets like "epel4" and "testing/epel4" are available. Writing a simple build-results mover should not be difficult, even without a package database that would keep track of where a build-job's packages have been pushed to. Similar to how RepoPrune does it, one can find a set of source+binary rpms for a given pkg %{name} based on the "Source RPM" header and then move/copy everything to a different target repo. The more recent push scripts can release single build-jobs, ignore the rest of the needsign queue, and at least provide a rough way to include the needsign queue in the repoclosure check (*with* mail reports to the pkg owners). Missing is the integration of the form "only push all pkgs that passed the test and none that were built after/during the test". With a crowded needsign queue, one doesn't want to cut'n'paste many package names, although that is possible. And, of course, when something is reported as broken, somebody would need to investigate, exclude packages and rerun time-consuming tests while packagers submit even more build jobs. With available code and no optimisations, one can easily see that running this automatically and frequently would occupy a dedicated server: $ time pushscript/RCNeedsign.py Extras development Copying build results to temporary working directory: gkrellm-moon-0.6-2.fc7 gkrellm-sun-1.0.0-2.fc7 gquilt-0.20-1.fc7 qps-1.9.19-0.1.a.fc7 qt4-4.2.2-7.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2962.fc7 Installing into temporary repository: gkrellm-moon-0.6-2.fc7 gkrellm-sun-1.0.0-2.fc7 gquilt-0.20-1.fc7 qps-1.9.19-0.1.a.fc7 qt4-4.2.2-7.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2962.fc7 Creating repository /tmp/tmp-repo-Lbc9uW/development/ppc Creating repository /tmp/tmp-repo-Lbc9uW/development/x86_64 Creating repository /tmp/tmp-repo-Lbc9uW/development/i386 Running /srv/extras-push/work/extras-repoclosure/rc-run.py --mail=owners --needsign=file:///tmp/tmp-repo-Lbc9uW/%s/%s/ development Trying to acquire lock file, waiting for any active job to terminate: OK development (ppc) development (x86_64) development (i386) real 12m55.152s user 7m20.028s sys 0m47.181s > 00:22 < dgilmore> | pretty much only one person pushes extras > 00:22 < nirik> | I could possibly also do sign/pushes on a schedule. ie, every morning at some time, etc. > 00:22 < thl> | having three or four signers that can push sounds enough to me > 00:23 < nirik> | yeah, mschwent? > 00:23 < thl> | nirik, I think so Ville and me push regularly. Warren probably only if we don't push often enough :) or if the availability of important updates matches his time-zone. From fedora at leemhuis.info Mon Mar 5 18:37:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Mar 2007 19:37:14 +0100 Subject: Meeting Summary for yesterdays meeting Message-ID: <45EC635A.2010002@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Meetings/20070304 = Meeting 20070304 = [[TableOfContents]] == Attending == * dgilmore * Jeff_S * mmcgrath * nirik * quaid * stahnma * thl == Summary == * thl created a status page in the wiki to track which Fedora contributors are interested in EPEL; see http://www.fedoraproject.org/wiki/EPEL/ContributorStatus got a bit enhanced by him after some feedback he received during the meeting; he will announce this to fedora-maintainers during the wiki after he added some more questions and answers to the FAQ that especially Fedora Contributors might have * one thing should be agreed on soon: rolling release, latest and greatest or a more carefull update approach? Answering that question is quite important before the mass of Fedora contributors starts to build packages for EPEL. The plan is to actually work out a solution during the next week (thl will try to write something up) on the list and ratify it in the next meeting on 20070311. Some highlights from the meeting log regarding this topic are between 00:16 and round about 00:32 * who is allowed to participate in EPEL -> the plan is to allow all Fedora contributors for EPEL. If you dislike that speak up now. * dgilmore created a gpg key for signing RPMS * dgilmore created the upload location and uploaded the first bunch of packages http://download.fedora.redhat.com/pub/epel/ * branching: EPEL5 currenly branches from devel, but and will soon be branched from FC-6 as devel might be to new for EL5. EPEL4 gets branched from FC-3. If one or both of those is not existent then the EPEL branch will get created from the Fedora devel branch == Full log == {{{ 00:00 < stahnma> | hello 00:00 --- | thl has changed the topic to: EPEL meeting! 00:00 < thl> | hy stahnma 00:00 < thl> | hi een 00:00 < thl> | even 00:00 --> | jwb_gone (Josh Boyer) has joined #fedora-meeting 00:00 --> | jwb_gone (Josh Boyer) has joined #fedora-meeting 00:00 --> | quaid (Karsten Wade) has joined #fedora-meeting 00:00 --> | quaid (Karsten Wade) has joined #fedora-meeting 00:00 < thl> | sorry, the "v" on my keyboard has some problems and works only half of the time :-/ 00:01 < stahnma> | thl needs a new keyboard 00:01 < thl> | stahnma, a new notebook 00:01 < thl> | laptop 00:01 < stahnma> | ah 00:01 < nirik> | sorry I'm late... here now. ;) 00:01 * | nirik just switched over to using his new d820 last night... so far so good. 00:02 < thl> | nirik, welcome, you din#t miss anything yet :) 00:02 --> | jmbuser (John Babich) has joined #fedora-meeting 00:03 < thl> | I#d say that was enough time to wait for people to show up 00:03 * | quaid finally got the regular alert programmed into his cellphone, so made it this time 00:03 < thl> | so let's get slowly started 00:03 < thl> | I just created a new page in the wiki 00:03 < thl> | see http://www.fedoraproject.org/wiki/EPEL/ContributorStatus 00:04 < thl> | the stuff in the head explains the background for that page 00:04 < nirik> | is that everyone from the fedora owners.list? 00:04 < thl> | if people like the idea I'd like to send out a mail to arious fedora lists asking people to update their status 00:04 < thl> | nirik, all from cvsextras in the Accounts system 00:05 < thl> | the number of packages is from owners.list 00:05 < thl> | but it's not exact, as some people use different e-mail adresses 00:05 * | thl waits for people to read the page 00:05 < nirik> | humm... what does "interested" mean here... that they want to maintain packages? or that they will someday? or that they don't mind if others do? 00:06 < thl> | good question 00:06 < quaid> | thl: recommend the /!\ be swapped to be at the top, and set it up so people can just read that and go on (some people don't read :) 00:06 < thl> | should probably be "interested in maintain packages..." 00:07 < thl> | quaid, okay, will do 00:07 < nirik> | I guess we could use 'yes' (ready to branch and maintain), 'no' don't want to branch and maintain, or 'perhaps' willing to help, but not now, or how no packages that should go into epel? 00:07 < stahnma> | if it is a 'no' are we going to add a co-maintainer? 00:08 < thl> | stahnma, no, only if there is a co-maintainer that actually wants to do the job 00:09 < stahnma> | I suppose that is dependant on the packages that person has or doe snot have 00:09 < nirik> | yeah... 00:09 < quaid> | this page is contributor focused ... 00:09 < quaid> | could it be package focused? 00:09 < quaid> | or isthat too hard ? 00:09 < quaid> | that is, hard to do on a Wiki 00:09 < thl> | quaid, much to hard 00:10 < thl> | we have oer 2500 packages 00:10 < thl> | some people have more then hundret packages 00:10 < thl> | your don#t want to flip yes/no for all of them 00:10 < thl> | this way people see that the status of the contributor is 00:10 < thl> | and can ask him, if a particular page is missing 00:10 < thl> | that should be good enough 00:11 < thl> | sure, a package based approach with a DB might have some adantages, but would be hard to set up 00:11 < nirik> | yeah, I think this is usefull in that someone might have been asked before... we don't want to keep bugging someone if they don't want to deal with it. 00:11 < thl> | this should do it afaics 00:11 < thl> | nirik, +1 00:12 --> | aa33d (entr0py) has joined #fedora-meeting 00:12 < thl> | nirik, btw, regarding "I guess we could use 'yes' (ready to branch and maintain)," -- I'll put a more detailed section in the document that decribes what the different values mean 00:12 < nirik> | ok, sounds good. 00:13 < thl> | is it okay for you guys if I bug the mailig lists with it later? 00:13 < quaid> | +1 00:14 < Jeff_S> | sounds good to me 00:14 < nirik> | +1 from me 00:14 < stahnma> | +1 00:15 < thl> | k, thx guys 00:15 < thl> | I further plan to add a "EPEL for Fedora contributors" section to the FAQ 00:15 < thl> | so people know how eerything is currently expected to work 00:15 < thl> | but one thing should be agreed on soon: 00:16 < thl> | rolling release, latest and greatest, more carefull update approach? 00:16 < thl> | people might be wondering what they should build for RHEL4 00:16 < thl> | (for RHEL5 is obvious: build what's currently in the FC-6 branch) 00:17 < nirik> | I think it should be: release stable things, if there is a version update it only pushes out on minor release updates, ie, 4.4 to 4.5... 00:17 < stahnma> | from a maintainer view, if the the current FC6 stuff will build against RHEL4, I would think they want to do that 00:17 < stahnma> | perl modules for example 00:17 < thl> | stahnma, well, there is a problem: a lot of current stuff won't build for RHEL4 as GTK2 for example is quite old 00:18 < stahnma> | right 00:18 < nirik> | in some cases it will... GUI still will not be as easy 00:18 < thl> | and having a repo where some stuff is quite new, and others old, makes not that much sense 00:18 <-- | entr0py has quit (Read error: 110 (Connection timed out)) 00:18 < stahnma> | well, I agree with that 00:18 < thl> | for perl-modules having "latest" might be okay and possinble most of the time 00:18 < stahnma> | will we be asking quite a lot of our maintainers though? 00:18 < nirik> | well, part of the problem is that "stable" depends on the upstream project. 00:19 --- | BobJensen-Away is now known as BobJensen 00:19 < stahnma> | have any people asked to do EPEL in RHEL 5 only and nor 4? 00:19 < stahnma> | s/nor/not 00:19 < nirik> | Perhaps instead of saying that people must backport everything, or always upgrade we should just have a "Goal: stable software. Backport if you can/need to, update if the new version is very stable" 00:19 < thl> | stahnma, scop (Ville) indicated he's more interested in RHEL5 than RHEL4 00:19 < thl> | s/RH// 00:20 < thl> | nirik, +1 00:20 < thl> | nirik, I'll try to put that into the faq before sending the mail out 00:20 < stahnma> | defining "very stable" will be rough 00:20 < stahnma> | unless we have some type of test suite 00:20 < Jeff_S> | I think that's something best left to the contributor(s) to decide for each package 00:21 < nirik> | yeah. There is upstream stable, and what the maintainer thinks is stable, and what the end user thinks is stable. 00:21 < stahnma> | probably 00:21 < thl> | Jeff_S, well, we should have a mostly common look and feel 00:21 --> | trondd (Trond Danielsen) has joined #fedora-meeting 00:21 < Jeff_S> | I think most people will not be willing to backport patches for very long, since it becomes quite a chore once you drop too far behind the current upstream release 00:21 < thl> | a repo that in parts has quite old software while other parts are quite new is a bit confusing IMHO 00:21 < quaid> | what if people want to update the dependencies by e.g. updating GTK2 for EL4? etc. 00:22 < thl> | Jeff_S, well, the thing IMHO is: update only if there is a good reason 00:22 < quaid> | pretty soon we're going to be looking at a stable and unstable branch 00:22 < stahnma> | I think the rolling release when minor updates are released make the most sense to e 00:22 < thl> | quaid, well, that would be replacing, and we don#t want that afaics 00:23 < stahnma> | seems like if you want to start replacing EL components or core, you should run Fedora 00:23 < thl> | quaid, one could come up with a GTK2 pacakge that lives in /opt and is used by rpaths -- but I doubt we really want that 00:23 < thl> | stahnma, +1 to "I think the rolling release when minor updates are released make the most sense to me" 00:23 * | nirik shudders. No. 00:23 < nirik> | replacing rhel stuff sounds like a bad idea to me. ;) 00:24 < nirik> | I do like doing non security/bug updates only on minor version upgrades tho. 00:24 < thl> | +1 for "I do like doing non security/bug updates only on minor version upgrades" 00:24 < stahnma> | so should we commit a statement of direction then? 00:24 * | thl wonders where nirik got the impression we want to replace stuff from rhel 00:25 < stahnma> | this will help each contributor decide if they are interested in EPEL 00:25 < thl> | stahnma, that's why I brought the topic up 00:25 < nirik> | well, there was talk about it on the list... not sure people were serious tho, or just didn't understand what it was... 00:25 < quaid> | thl: it was my comment and your reply 00:25 < mmcgrath> | Sorry guys, 00:25 < quaid> | oh, ok 00:25 * | mmcgrath is here now. 00:25 < stahnma> | thl, yeah, I mean, like, are we agreed on this? 00:25 * | mmcgrath reads up 00:25 < nirik> | thl: yeah, I think we should get some consensus on the list before we push it out to the world tho. 00:26 < thl> | nirik, I in parts agree, but that might take weeks :-(( 00:26 < quaid> | +1 to work it out on list, make a decision here in 7 days 00:26 < thl> | +1 for quaid 00:26 < stahnma> | +1 quaid 00:26 < nirik> | one still unknown is if we push updates on minor release upgrades, is there any criteria for those updates? anything goes? or try and maintain stability, but new features/upgrades are ok? 00:26 < nirik> | +1 quaid 00:27 < thl> | nirik, +1 for "try and maintain stability, but new features/upgrades are ok" (maybe with the add-on "if there is a good reasons for them)" 00:27 < stahnma> | nirik I think we try to move with upstream. This is easiest for the maintainer and the admin running EPEL can look into the release before moving. All the shops I know don't just go from update 4 to update 5 wtihout research and testing 00:28 < nirik> | yeah, agreed. 00:28 < thl> | stahnma, well, but the base we build for doesn#t move -- so why should we without a reasons? 00:28 < stahnma> | thl trumps me with his logic 00:28 < thl> | people use RHEL because it nearly doesn't move; I think EPEL should be similar 00:29 < stahnma> | well, if look at EL each update normally *does* include movement from upstream, they just don't change hte version number 00:29 < nirik> | so when rhel goes from X.N to X.N+1, would we want to start building and testing then? or would we want to have a testing repo ready with the updates? 00:29 < stahnma> | for example, 3.6p1 of OpenSSH on RHEL3 has many features of 4.0 and greather 00:29 < thl> | stahnma, some movement yes, but not much afaics 00:30 * | mmcgrath agrees with thl. 00:30 < thl> | nirik, I'd say we should have a testing repo in parallel, that becomes stable in parallel with the update 00:30 < thl> | & of RHEL 00:31 < nirik> | yeah, although if the new rhel minor bumps some things, it could break things that previously compiled in testing... 00:31 < mmcgrath> | RHEL's just a rolling release with snapshots in time. 00:31 < stahnma> | in theory a new RHEL minor shouldn't break anything (100% api/abi compat) :) 00:31 < mmcgrath> | There's minor exceptions. 00:31 < thl> | nirik, should be seldom afaics (and isnn't this a bug in RHEL then?) 00:32 < quaid> | the way things are now, are EPEL maintainers going to be able to get access to the EL bits early enough? 00:32 < thl> | quaid, no, I don't think so 00:32 < nirik> | ok, just wanted to bring that up... ;) WOuld be fine if it didn't break anything. 00:32 < quaid> | i.e., do we need to arrange some kind of beta channel for EPEL maintainers 00:32 < thl> | they will get it when CentOS shipps them, and that some days/weeks after HEL 00:32 < stahnma> | quaid: that would be ideal 00:32 < thl> | quaid, I don't think that is needed 00:33 < thl> | quaid, and we can do that later if we really need it 00:33 < quaid> | ok 00:33 < mmcgrath> | hmm 00:33 < stahnma> | probably not a priority 00:33 <-- | aa33d has quit (Read error: 110 (Connection timed out)) 00:33 < thl> | quaid, would RHEL be willing to have such a channel for EPEL maintainers? 00:33 < quaid> | it's likely we can do something, but it may require (just guessing) an NDA or something; OTOH, maybe the CLA is good enough there, we'd have to Seek Legal Advice 00:33 < thl> | quaid, remember, some EPEL maintainers might not have RHEL at all 00:33 < mmcgrath> | thl: What will be more likely is a xen instance people can 'reserve' 00:34 < quaid> | thl: well, it's done for customers; can't see why it wouldn't work, but ... 00:34 < thl> | mmcgrath, ohh, hmm, yes, that could work; I like the idea 00:34 < stahnma> | mmcgrath: that would probably ok 00:34 < quaid> | mmcgrath +1 00:34 < thl> | mmcgrath, but nevertheless: probably not a priority 00:34 < mmcgrath> | That just seams like less red tape. 00:35 <-- | kital has quit (Remote closed the connection) 00:35 < thl> | so, who brings the discussion about the "packge upgrade guidelines" to the list? 00:36 * | thl probably has to do it 00:37 < thl> | I'm not sure if I find time for it in the next two or three days, but I'll try 00:38 * | thl brought up the topics he wanted to see discuessed today 00:38 < nirik> | yeah, I could try, but I need to try and catch up with core reviews soon. ;) 00:38 < stahnma> | quaid: any progress on the Communication plans? 00:38 < thl> | nirik, it's okay, I'll do it 00:38 * | thl simply ignores the merge reviews most of the time 00:39 * | stahnma tries to do one merge review a night 00:39 * | thl doesn't even read the fedora lists in that detail as in the past 00:39 < nirik> | I was trying to do that, but got swamped at work and now new laptop fun. ;) 00:39 < thl> | the benefits of not being in FESCO anymore 00:39 < quaid> | stahnma: not yet; some of it is wanting to have our details make sense first 00:39 < nirik> | anyhow, back to epel... anything else we want to discuss? 00:40 * | thl hasn't anything 00:40 < mmcgrath> | I have one, branching. 00:40 < stahnma> | quaid: agreed. 00:40 < mmcgrath> | I swear this was discussed but I can't find it, who's allowed to request branches right now? 00:40 < quaid> | stahnma: but I'll start to stub out a page today, and we can throw our pieces into it to stitch together later 00:40 < nirik> | last I heard it was: sponsors and anyone with more than 5 packages... 00:40 < stahnma> | dgilmore told me it wsa something about 5 packages 00:40 < mmcgrath> | nirik: Is that written down somewhere? 00:41 < thl> | mmcgrath, I think everyone is now 00:41 < dgilmore> | sorry guys i slept in 00:41 < thl> | we'll set up the release team soon to make sure that everything is properly maintained, even if the maintainers vanishes -- we afaics have to do this anyhow 00:41 < thl> | hi dgilmore ! 00:42 < dgilmore> | hey thl 00:42 < thl> | dgilmore, gpg-key? new rhel5 buildroot? did pushing work? 00:42 < nirik> | mmcgrath: not that I know of. Perhaps we want to revisit it now? 00:42 < dgilmore> | thl: gpg key is done 00:42 < dgilmore> | what was built is pushed 00:42 < thl> | dgilmore, great :) 00:42 < dgilmore> | I havent been able to get the build root updated yet 00:43 < thl> | mmcgrath, "Is that written down somewhere?" -> should be in a FESCo meeting log somewhere 00:43 < thl> | mmcgrath, but I'd say we should allow everyone now 00:44 < thl> | dgilmore, thx for your work 00:44 < quaid> | +1 we don't want it to be too difficult to get in new EPEL maintainers 00:44 < nirik> | +1 for allowing any maintainer to branch. 00:44 < stahnma> | +1 00:44 * | thl takes that as accepted, and will add it to the wiki somewhere 00:44 < dgilmore> | im ok with that 00:44 < quaid> | esp. as we're advocating for customer-types to do it, standard Fedora process seems fine 00:44 < nirik> | hopefully we won't get too many new folks who want to push a new game or something. 00:45 * | thl will at least write about it once to the list, before he adds it to the wiki 00:45 < stahnma> | well initially not having dependencies will probably hinder game packages and several other larger packages 00:45 < dgilmore> | thl: EL-5 is being branched from devel not FC-6 00:45 < thl> | dgilmore, shoudn#t that be FC-6 now? 00:45 < nirik> | stahnma: true. 00:45 < dgilmore> | thl: i dont think so 00:46 < dgilmore> | maybe it should be 00:46 < nirik> | I haven't built any of my branched packages for el5... I have no way of test building or testing them yet. 00:46 < thl> | devel might have quite new stuff (see bittorent) 00:46 < dgilmore> | EL-4 is FC-3 if it exists if not devel 00:46 * | thl votes to create EL-5 branches for FC-6 00:46 < thl> | dgilmore, that's fine afaics 00:47 < thl> | s/for/from/ 00:47 < dgilmore> | i can make it so EL-5 does FC-6 if it exists devel if not 00:47 < thl> | dgilmore, +1 00:47 < thl> | other opinions? 00:48 < nirik> | sounds fine to me. 00:48 < nirik> | I don't think it much matters... maintainer can adjust as needed. 00:48 < thl> | nirik, but FC-6 is better as safe default IMHO 00:49 < nirik> | sure. 00:50 < thl> | anything else to discuss? 00:50 * | thl takes that as "no" 00:50 < mmcgrath> | nope :-) 00:51 < thl> | shaltt we close the meeting ? 00:51 < thl> | shall 00:51 < nirik> | dgilmore: with the push, do we have mirrored repos yet? 00:51 < dgilmore> | nirik: im not sure 00:51 < nirik> | ie, is there yum.repos.d files that we can install and test with now? 00:51 < nirik> | yeah, I don't have anything else, so closing down is fine with me. 00:51 < dgilmore> | nirik: i need to create a epel-release package that can be installed and set everything up 00:52 < nirik> | yeah. ok. 00:52 < dgilmore> | along with mirrorlist stuff 00:52 < thl> | dgilmore, +1 (but dgilmore has enough to do already afaics -- maybe somebody wants to leant a helping hand to dgilmore?) 00:53 * | thl does even more stupid typos today than he does usually already :-/ 00:54 < thl> | shall we close the meeting for today? 00:54 < stahnma> | ok, thanks everyone 00:54 < thl> | yeah, thx everyone! 00:54 < nirik> | thanks thl 00:55 --- | thl has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting 00:55 < thl> | nirik, I'm just doing this a bit like I did the meetings when I was FESCo chair 00:55 < thl> | is that okay for everybody? 00:55 < quaid> | +1 from me, works great 00:56 < nirik> | yep. Works fine for me... we might want to ping the listg again and make sure this is a ok time... but seems to work for several of us at least. 00:56 < jwb_gone> | there's a meeting going on? 00:56 < nirik> | there was... 00:56 < jwb_gone> | for? 00:57 < thl> | epel 00:57 < nirik> | EPEL... 00:57 < jwb_gone> | oh, sorry. wasn't paying attention 00:57 < jwb_gone> | :) 00:57 < nirik> | http://www.fedoraproject.org/wiki/EPEL/ 00:58 < dgilmore> | http://download.fedora.redhat.com/pub/epel/ 00:58 < dgilmore> | everything is there 01:01 < nirik> | cool! 01:01 < quaid> | dgilmore++ 01:01 * | quaid says, "In your face, nay-sayers!" 01:01 < Jeff_S> | dgilmore: cool :) }}} From kwade at redhat.com Mon Mar 5 20:30:01 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 05 Mar 2007 12:30:01 -0800 Subject: package stability In-Reply-To: <20070303105114.GC27400@neu.nirvana> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> Message-ID: <1173126601.2865.262.camel@erato.phig.org> On Sat, 2007-03-03 at 11:51 +0100, Axel Thimm wrote: > On Sat, Mar 03, 2007 at 10:26:01AM +0100, Patrice Dumas wrote: > > Do we want to keep API/ABI stable over the corresponding RHEL release? > > It would be interesting to have a document that described RH's specs > in this area. E.g. which API/ABI are more important that others. RHEL > has certainly kept some parts more flexible than others, for example > wireless API/ABI on almost each kernel update. > > It's probably a weighing of pros and cons per case. I've asked about this. There aren't any papers/documents written (yet), but there are supposed to be some tools in the works. I'll work on finding/getting the people involved to discuss the topic on this list. I've volunteered to help write a paper on the topic, so it's now a matter of gathering the technical leadership and confirming the various positions/answers. - Karsten -- 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 Axel.Thimm at ATrpms.net Mon Mar 5 20:37:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 21:37:27 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45EC32AE.1070006@math.unl.edu> References: <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> Message-ID: <20070305203727.GA29562@neu.nirvana> On Mon, Mar 05, 2007 at 09:09:34AM -0600, Rex Dieter wrote: > Axel Thimm wrote: > > >The original intent of fedora-usermgmt was to deal with packages > >requiring *fixed* uid/gid, so the fallback to useradd -r will be > >breaking that package, or that package didn't need a fixed uid/gid in > >the first place. > > The intent is to implement (quasi?) fixed uid/gid assignment within the > 100-499 space, provided admin's configured it, so they'd have consistent ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > uid/gid assignment across their enterprise. and add: "provided the admins configured it _the same_ across their enterprise." > Have I mentioned this is the wrong forum for this discussion? Trying to solve this on the Fedora side may take ages as no one really seems to be interested (or are you volunteering to take the lead). See for example the ancient bug report that could had been the start to solve this, furthermore this discussion has happened in Fedora space often enough w/o anyone really interested. Just let's not inherit everything. This for example seems like a good candidate to not let pass our filters. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 5 20:41:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 14:41:00 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070305203727.GA29562@neu.nirvana> References: <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> Message-ID: <45EC805C.5020106@math.unl.edu> Axel Thimm wrote: > On Mon, Mar 05, 2007 at 09:09:34AM -0600, Rex Dieter wrote: >> Axel Thimm wrote: >> >>> The original intent of fedora-usermgmt was to deal with packages >>> requiring *fixed* uid/gid, so the fallback to useradd -r will be >>> breaking that package, or that package didn't need a fixed uid/gid in >>> the first place. >> The intent is to implement (quasi?) fixed uid/gid assignment within the >> 100-499 space, provided admin's configured it, so they'd have consistent > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> uid/gid assignment across their enterprise. > > and add: "provided the admins configured it _the same_ across their > enterprise." If an admin misconfigures their site, all bets are off, regardless. -- Rex From rdieter at math.unl.edu Mon Mar 5 20:44:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 14:44:32 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070305203727.GA29562@neu.nirvana> References: <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> Message-ID: <45EC8130.9090809@math.unl.edu> Axel Thimm wrote: > On Mon, Mar 05, 2007 at 09:09:34AM -0600, Rex Dieter wrote: >> Have I mentioned this is the wrong forum for this discussion? > > Trying to solve this on the Fedora side may take ages as no one really > seems to be interested (or are you volunteering to take the lead). No volunteer quota left, I'm afraid. (: -- Rex From Axel.Thimm at ATrpms.net Mon Mar 5 20:47:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 21:47:11 +0100 Subject: package stability In-Reply-To: <1173126601.2865.262.camel@erato.phig.org> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <1173126601.2865.262.camel@erato.phig.org> Message-ID: <20070305204711.GC29562@neu.nirvana> On Mon, Mar 05, 2007 at 12:30:01PM -0800, Karsten Wade wrote: > On Sat, 2007-03-03 at 11:51 +0100, Axel Thimm wrote: > > On Sat, Mar 03, 2007 at 10:26:01AM +0100, Patrice Dumas wrote: > > > Do we want to keep API/ABI stable over the corresponding RHEL release? > > > > It would be interesting to have a document that described RH's specs > > in this area. E.g. which API/ABI are more important that others. RHEL > > has certainly kept some parts more flexible than others, for example > > wireless API/ABI on almost each kernel update. > > > > It's probably a weighing of pros and cons per case. > > I've asked about this. There aren't any papers/documents written (yet), > but there are supposed to be some tools in the works. I'll work on > finding/getting the people involved to discuss the topic on this list. > I've volunteered to help write a paper on the topic, so it's now a > matter of gathering the technical leadership and confirming the various > positions/answers. We need a RHEL representative/contact whom we will be able to officially ask stuff like the above, to sketch some inside specs and so on, and I think this sounds a lot like it should be you :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 5 20:48:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 5 Mar 2007 21:48:44 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45EC805C.5020106@math.unl.edu> References: <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> Message-ID: <20070305204844.GD29562@neu.nirvana> On Mon, Mar 05, 2007 at 02:41:00PM -0600, Rex Dieter wrote: > Axel Thimm wrote: > >On Mon, Mar 05, 2007 at 09:09:34AM -0600, Rex Dieter wrote: > >>Axel Thimm wrote: > >> > >>>The original intent of fedora-usermgmt was to deal with packages > >>>requiring *fixed* uid/gid, so the fallback to useradd -r will be > >>>breaking that package, or that package didn't need a fixed uid/gid in > >>>the first place. > >>The intent is to implement (quasi?) fixed uid/gid assignment within the > >>100-499 space, provided admin's configured it, so they'd have consistent > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>uid/gid assignment across their enterprise. > > > >and add: "provided the admins configured it _the same_ across their > >enterprise." > > If an admin misconfigures their site, all bets are off, regardless. But the above forces him to configure the app. BTW I tried to find how fedora-usermgmt is supposed to fallback to simple useradd -r operation and didn't find anything. Are you sure it does that? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 5 20:58:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 14:58:01 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070305204844.GD29562@neu.nirvana> References: <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> Message-ID: <45EC8459.4010205@math.unl.edu> Axel Thimm wrote: > On Mon, Mar 05, 2007 at 02:41:00PM -0600, Rex Dieter wrote: >> If an admin misconfigures their site, all bets are off, regardless. > > But the above forces him to configure the app. configuration is *optional*. >BTW I tried to find how > fedora-usermgmt is supposed to fallback to simple useradd -r operation > and didn't find anything. Are you sure it does that? I've only taken the maintainers' (Enrico Scholz) word for it. I trust he knows what he's talking about. -- Rex From kwade at redhat.com Mon Mar 5 23:18:23 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 05 Mar 2007 15:18:23 -0800 Subject: package stability In-Reply-To: <20070305204711.GC29562@neu.nirvana> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <1173126601.2865.262.camel@erato.phig.org> <20070305204711.GC29562@neu.nirvana> Message-ID: <1173136703.2865.278.camel@erato.phig.org> On Mon, 2007-03-05 at 21:47 +0100, Axel Thimm wrote: > We need a RHEL representative/contact whom we will be able to > officially ask stuff like the above, to sketch some inside specs and > so on, and I think this sounds a lot like it should be you :) Yes, I can fill this role, at least temporarily. I'm not technically the best (by far) or the best connected, but I am i) good enough to start us off, and ii) not totally blinded by working on the RHEL 5 release. :) As more @redhat.com-based Fedora developers understand what EPEL is, I'm hoping a better "thought leader" emerges. - Karsten -- 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 fedora at leemhuis.info Tue Mar 6 06:05:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Mar 2007 07:05:31 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070305203727.GA29562@neu.nirvana> References: <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> Message-ID: <45ED04AB.1070803@leemhuis.info> On 05.03.2007 21:37, Axel Thimm wrote: > On Mon, Mar 05, 2007 at 09:09:34AM -0600, Rex Dieter wrote: >> Axel Thimm wrote: >> Have I mentioned this is the wrong forum for this discussion? > Trying to solve this on the Fedora side may take ages k, then it might take ages. But I'm strictly against finding special EPEL solutions for problems, if the same problem exists in Fedora-land and should be fixed there, too (and this is the case here). > as no one really > seems to be interested (or are you volunteering to take the lead). Then I'd say the problem can't be that big. CU thl From Christian.Iseli at licr.org Tue Mar 6 06:56:16 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 6 Mar 2007 07:56:16 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45ED04AB.1070803@leemhuis.info> References: <200703041641.18529.dennis@ausil.us> <45EB59AD.3060509@redhat.com> <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> Message-ID: <20070306075616.3d2b471a@ludwig-alpha.unil.ch> On Tue, 06 Mar 2007 07:05:31 +0100, Thorsten Leemhuis wrote: > k, then it might take ages. But I'm strictly against finding special > EPEL solutions for problems, if the same problem exists in Fedora-land > and should be fixed there, too (and this is the case here). k, I'll hop in and state (again) MHO on this topic: root: rpm -qf `which useradd ` shadow-utils-4.0.17-12.fc6 so, my humble opinion is: whatever policy we'd like implemented for how useradd behaves must be implemented within the shadow-utils package. Even more so now that we no longer have a distinction between Core and Extras. C From Axel.Thimm at ATrpms.net Tue Mar 6 10:48:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 11:48:34 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45ED04AB.1070803@leemhuis.info> References: <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> Message-ID: <20070306104834.GB11141@neu.nirvana> On Tue, Mar 06, 2007 at 07:05:31AM +0100, Thorsten Leemhuis wrote: > On 05.03.2007 21:37, Axel Thimm wrote: > >On Mon, Mar 05, 2007 at 09:09:34AM -0600, Rex Dieter wrote: > >>Axel Thimm wrote: > >>Have I mentioned this is the wrong forum for this discussion? > >Trying to solve this on the Fedora side may take ages > > k, then it might take ages. But I'm strictly against finding special > EPEL solutions for problems, if the same problem exists in Fedora-land > and should be fixed there, too (and this is the case here). Then let's not find special solutions. I'm just against having this kind of special "solution" in EPEL, and I think the majority here has the same opinion. In fact I'm really for using the non-special solution, just plain useradd -r. If the fallback is supposed to had been useradd -r anyway then there was no win to use that special "solution" in the first place. No special solutions, please, I agree - ban fedora-usermgmt from EPEL. > >as no one really seems to be interested (or are you volunteering to > >take the lead). > > Then I'd say the problem can't be that big. That's a joke, right? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Mar 6 11:06:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Mar 2007 12:06:51 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070306104834.GB11141@neu.nirvana> References: <80d7e4090703041747v3131549erdec455233b8bd1cf@mail.gmail.com> <20070305113208.GK29562@neu.nirvana> <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> <20070306104834.GB11141@neu.nirvana> Message-ID: <45ED4B4B.7060208@leemhuis.info> On 06.03.2007 11:48, Axel Thimm wrote: > [...] > No special solutions, please, I agree - ban fedora-usermgmt from EPEL. "ban fedora-usermgmt from EPEL" for me is a special EPEL solution, as it differs from the Fedora solution. That way lie dragons! I'd like to avoid them -- every single rule around packaging that is different between Fedora and EPEL will make life harder for users and packagers that are active in both camps, as they have to keep different rule sets in mind. I'd like to avoid that as much as possible. >>> as no one really seems to be interested (or are you volunteering to >>> take the lead). >> Then I'd say the problem can't be that big. > That's a joke, right? Unsure. Yes, in parts, no in other parts -- as Rex iirc said: there seems to be a lot FUD about "fedora-usermgmt" around. If the problem if so big that you want to get is solved then please go and solve it in Fedora (hey, you are in the Packaging Committee!), and it will be solved for EPEL that way, too. Taking a EPEL-shortcut would IMHO be plain wrong. CU thl From Axel.Thimm at ATrpms.net Tue Mar 6 12:24:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 13:24:06 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45ED4B4B.7060208@leemhuis.info> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> <20070306104834.GB11141@neu.nirvana> <45ED4B4B.7060208@leemhuis.info> Message-ID: <20070306122406.GC30939@neu.nirvana> On Tue, Mar 06, 2007 at 12:06:51PM +0100, Thorsten Leemhuis wrote: > On 06.03.2007 11:48, Axel Thimm wrote: > >[...] > >No special solutions, please, I agree - ban fedora-usermgmt from EPEL. > > "ban fedora-usermgmt from EPEL" for me is a special EPEL solution, as it > differs from the Fedora solution. > > That way lie dragons! > > I'd like to avoid them -- every single rule around packaging that is > different between Fedora and EPEL will make life harder for users and > packagers that are active in both camps, as they have to keep different > rule sets in mind. I'd like to avoid that as much as possible. > > >>>as no one really seems to be interested (or are you volunteering to > >>>take the lead). > >>Then I'd say the problem can't be that big. > >That's a joke, right? > > Unsure. Yes, in parts, no in other parts -- as Rex iirc said: there > seems to be a lot FUD about "fedora-usermgmt" around. > > If the problem if so big that you want to get is solved then please go > and solve it in Fedora (hey, you are in the Packaging Committee!), and > it will be solved for EPEL that way, too. > > Taking a EPEL-shortcut would IMHO be plain wrong. Ok, how about we simply vote on that and let it R.I.P.? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Mar 6 14:29:37 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 08:29:37 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070306122406.GC30939@neu.nirvana> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> <20070306104834.GB11141@neu.nirvana> <45ED4B4B.7060208@leemhuis.info> <20070306122406.GC30939@neu.nirvana> Message-ID: <45ED7AD1.1040000@redhat.com> Axel Thimm wrote: > On Tue, Mar 06, 2007 at 12:06:51PM +0100, Thorsten Leemhuis wrote: > >> On 06.03.2007 11:48, Axel Thimm wrote: >> >>> [...] >>> No special solutions, please, I agree - ban fedora-usermgmt from EPEL. >>> >> "ban fedora-usermgmt from EPEL" for me is a special EPEL solution, as it >> differs from the Fedora solution. >> >> That way lie dragons! >> >> I'd like to avoid them -- every single rule around packaging that is >> different between Fedora and EPEL will make life harder for users and >> packagers that are active in both camps, as they have to keep different >> rule sets in mind. I'd like to avoid that as much as possible. >> >> >>>>> as no one really seems to be interested (or are you volunteering to >>>>> take the lead). >>>>> >>>> Then I'd say the problem can't be that big. >>>> >>> That's a joke, right? >>> >> Unsure. Yes, in parts, no in other parts -- as Rex iirc said: there >> seems to be a lot FUD about "fedora-usermgmt" around. >> >> If the problem if so big that you want to get is solved then please go >> and solve it in Fedora (hey, you are in the Packaging Committee!), and >> it will be solved for EPEL that way, too. >> >> Taking a EPEL-shortcut would IMHO be plain wrong. >> > > Ok, how about we simply vote on that and let it R.I.P.? > Vote proposed. I predict a very vocal minority. -Mike From mmcgrath at redhat.com Tue Mar 6 14:52:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 08:52:49 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <45ED7AD1.1040000@redhat.com> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> <20070306104834.GB11141@neu.nirvana> <45ED4B4B.7060208@leemhuis.info> <20070306122406.GC30939@neu.nirvana> <45ED7AD1.1040000@redhat.com> Message-ID: <45ED8041.9080801@redhat.com> FYI: https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00126.html This makes me very unhappy. -Mike From ra+redhat at strg-alt-entf.org Tue Mar 6 15:50:13 2007 From: ra+redhat at strg-alt-entf.org (Ralph Angenendt) Date: Tue, 6 Mar 2007 16:50:13 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070301222635.GB31912@neu.nirvana> References: <20070227203050.096d8b69@python3.es.egwn.lan> <1172760542.3803.10.camel@localhost.localdomain> <20070301161824.GA16337@neu.nirvana> <200703011025.30152.dennis@ausil.us> <20070301222635.GB31912@neu.nirvana> Message-ID: <20070306155013.GA28839@br-online.de> Axel Thimm wrote: > On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote: > > Umm CentOS releases updates shortly after RHEL does. Im not sure > > what rolling releases you are talking about. > > Roling in the sense of the minor release integer. > > Compare > > http://isoredirect.centos.org/centos/4/isos/i386/ > > to > > https://www.scientificlinux.org/download/ > > E.g. the range of 4.x versions. SL follows RH in maintaining each > point release, while CentOS kind of EOLs the previous point releases. Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we don't either. All updates are going against the latest (misnomed) 'quarterly' update. And I don't think that SL does it any different, although I might be wrong there. Because every quarterly update is a big update set against the previous one (including updates). So I'm not too sure about what you are talking about. Cheers, Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Mar 6 16:03:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 10:03:39 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <20070306155013.GA28839@br-online.de> References: <20070227203050.096d8b69@python3.es.egwn.lan> <1172760542.3803.10.camel@localhost.localdomain> <20070301161824.GA16337@neu.nirvana> <200703011025.30152.dennis@ausil.us> <20070301222635.GB31912@neu.nirvana> <20070306155013.GA28839@br-online.de> Message-ID: <45ED90DB.6050100@redhat.com> Ralph Angenendt wrote: > Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we > don't either. All updates are going against the latest (misnomed) > 'quarterly' update. And I don't think that SL does it any different, > although I might be wrong there. Because every quarterly update is a big > update set against the previous one (including updates). > > So I'm not too sure about what you are talking about. > > Cheers, > This is something we can change later. Lets keep it simple for now and if an issue comes up we can discuss it as a real example instead of guessing what problems will come up. The releases are just a snapshot of the rolling updates at some point in time. Its pretty arbitrary AFAIK. -Mike From Axel.Thimm at ATrpms.net Tue Mar 6 18:56:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Mar 2007 19:56:48 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070306155013.GA28839@br-online.de> References: <20070227203050.096d8b69@python3.es.egwn.lan> <1172760542.3803.10.camel@localhost.localdomain> <20070301161824.GA16337@neu.nirvana> <200703011025.30152.dennis@ausil.us> <20070301222635.GB31912@neu.nirvana> <20070306155013.GA28839@br-online.de> Message-ID: <20070306185648.GG7703@neu.nirvana> On Tue, Mar 06, 2007 at 04:50:13PM +0100, Ralph Angenendt wrote: > Axel Thimm wrote: > > On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote: > > > Umm CentOS releases updates shortly after RHEL does. Im not sure > > > what rolling releases you are talking about. > > > > Roling in the sense of the minor release integer. > > > > Compare > > > > http://isoredirect.centos.org/centos/4/isos/i386/ > > > > to > > > > https://www.scientificlinux.org/download/ > > > > E.g. the range of 4.x versions. SL follows RH in maintaining each > > point release, while CentOS kind of EOLs the previous point releases. > > Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we > don't either. I'll better let someone with a Red Hat on answer this in detail, but I know that this doesn't hold true (anymore). Maybe only for selected releases (and I hope not only for selected clients). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Tue Mar 6 20:13:12 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 6 Mar 2007 13:13:12 -0700 Subject: remove fedora-usermgmt? In-Reply-To: <45ED8041.9080801@redhat.com> References: <20070305142524.GA2657@jadzia.bu.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> <20070306104834.GB11141@neu.nirvana> <45ED4B4B.7060208@leemhuis.info> <20070306122406.GC30939@neu.nirvana> <45ED7AD1.1040000@redhat.com> <45ED8041.9080801@redhat.com> Message-ID: <80d7e4090703061213y4afd3fe6tba2e6c2bb6dccefb@mail.gmail.com> On 3/6/07, Mike McGrath wrote: > FYI: > > https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00126.html > > This makes me very unhappy. > It is not unexpected though. One issue that will come up over and over again is that Fedora items are built for the current head. The design and goal of various packages are tied to that head and when trying to 'back-port' things to FC3 (for RHEL-4) and RHL7.2 (for RHEL-3) will not work because they used something that didnt appear until FC5 or FC6. This is the major reason that some packages going into any sort of EPEL will not be simple ports of stuff from FC to EPEL. They will instead have to be stuff that is built from the ground-up to support say RHEL-3 and also 4,5 etc. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Tue Mar 6 20:16:31 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 6 Mar 2007 13:16:31 -0700 Subject: Release and update procedure for EPEL In-Reply-To: <20070306155013.GA28839@br-online.de> References: <20070227203050.096d8b69@python3.es.egwn.lan> <1172760542.3803.10.camel@localhost.localdomain> <20070301161824.GA16337@neu.nirvana> <200703011025.30152.dennis@ausil.us> <20070301222635.GB31912@neu.nirvana> <20070306155013.GA28839@br-online.de> Message-ID: <80d7e4090703061216y2b13f942s546610e5afdf4e20@mail.gmail.com> On 3/6/07, Ralph Angenendt wrote: > Axel Thimm wrote: > > On Thu, Mar 01, 2007 at 10:25:29AM -0600, Dennis Gilmore wrote: > > > Umm CentOS releases updates shortly after RHEL does. Im not sure > > > what rolling releases you are talking about. > > > > Roling in the sense of the minor release integer. > > > > Compare > > > > http://isoredirect.centos.org/centos/4/isos/i386/ > > > > to > > > > https://www.scientificlinux.org/download/ > > > > E.g. the range of 4.x versions. SL follows RH in maintaining each > > point release, while CentOS kind of EOLs the previous point releases. > > Ummm. No. I don't think RH still maintains 4. Or 4U1. Or 4U2. So we > don't either. All updates are going against the latest (misnomed) > 'quarterly' update. And I don't think that SL does it any different, > although I might be wrong there. Because every quarterly update is a big > update set against the previous one (including updates). > Yes Red Hat ONLY supports the latest version of its product until 4.5.0 is released. At that point they will be moving to a newer support paradigm similar to the Scientific Linux. Basically if I am understanding things correctly.. 4.5.1 will be security updates only to 4.5.0 and not enhancement additions. 5.0.1 will be the same. They will also not be back-supporting 4U1->4U4. Only 4.5.0,4.6.0, and maybe if they have a 4.7.0 is going to be generally maintained as this. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Tue Mar 6 21:48:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 22:48:34 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <80d7e4090703061213y4afd3fe6tba2e6c2bb6dccefb@mail.gmail.com> References: <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45ED04AB.1070803@leemhuis.info> <20070306104834.GB11141@neu.nirvana> <45ED4B4B.7060208@leemhuis.info> <20070306122406.GC30939@neu.nirvana> <45ED7AD1.1040000@redhat.com> <45ED8041.9080801@redhat.com> <80d7e4090703061213y4afd3fe6tba2e6c2bb6dccefb@mail.gmail.com> Message-ID: <20070306214834.GA2879@free.fr> On Tue, Mar 06, 2007 at 01:13:12PM -0700, Stephen John Smoogen wrote: > > This is the major reason that some packages going into any sort of > EPEL will not be simple ports of stuff from FC to EPEL. They will > instead have to be stuff that is built from the ground-up to support > say RHEL-3 and also 4,5 etc. This is true in part, but a lot of QA is also independent of the fedora version. When the reviews are long, in my experience, it corresponds with issues that are solved with upstream, or non obvious packaging issues. -- Pat From greg at runlevel7.ca Wed Mar 7 06:03:51 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Tue, 06 Mar 2007 22:03:51 -0800 Subject: rpms that just need a rebuild... Message-ID: <45EE55C7.5090705@runlevel7.ca> I admit I haven't been following all the EPEL discussion that closely, so sorry if this has been brought up before... Originally I thought EPEL was going to function more like how centos.karan.org did, by just rebuilding Extras rpms on a ELx box, and people would volunteer to fix any packages that wouldn't build correctly. But it seems to be more focused on taking stable versions and only applying security patches...which is good, especially if there are lots of volunteers. But I was wondering if there is room in the plans for a "EPEL-unstable" repository (or something like that), which is just an automatic rebuild of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms for EL5 that I just rebuilt from the Fedora Extras 6 sources - no modifications to the spec files needed. By the way, I am not an Extras contributor, so I don't think I'd be allowed to be a maintainer just for EPEL, would I? Thanks, Greg From fedora at leemhuis.info Wed Mar 7 06:46:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 07 Mar 2007 07:46:13 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <45EE55C7.5090705@runlevel7.ca> References: <45EE55C7.5090705@runlevel7.ca> Message-ID: <45EE5FB5.7040905@leemhuis.info> On 07.03.2007 07:03, Greg Swallow wrote: > [...] > But I was wondering if there is room in the plans for a "EPEL-unstable" > repository (or something like that), which is just an automatic rebuild > of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms > for EL5 that I just rebuilt from the Fedora Extras 6 sources - no > modifications to the spec files needed. My 2 cent: It would IMHO make a lot more sense to have a second repo that replaces stuff from the base or installs newer versions of gtk2 in parallel to the one from the base; that would allow to ship newer version of other programs that depend on newer system library, too. But I'd say EPEL should focus on bringing up the main repo that doesn't replace stuff now before thinking about thinks like that. And the Fedora project is probably not the best place for this effort, too -- but I'm optimistic that there will soon be another project where this will be fitting in (more news to come, just be a bit patient for some weeks). > By the way, I am not an Extras contributor, so I don't think I'd be > allowed to be a maintainer just for EPEL, would I? You can become a Extras contributor via the normal sponsorship way and thus become a EPEL contributor, too. There are also talks to get new contributors in as co-maintainers, that have no access to the buildsys in the beginning. But we probably need some technical infrastructure for that, that is not yet in place. CU thl From greg at runlevel7.ca Wed Mar 7 06:52:55 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Tue, 06 Mar 2007 22:52:55 -0800 Subject: rpms that just need a rebuild... In-Reply-To: <45EE5FB5.7040905@leemhuis.info> References: <45EE55C7.5090705@runlevel7.ca> <45EE5FB5.7040905@leemhuis.info> Message-ID: <45EE6147.3020000@runlevel7.ca> Thorsten Leemhuis wrote: > On 07.03.2007 07:03, Greg Swallow wrote: > > [...] >> But I was wondering if there is room in the plans for a >> "EPEL-unstable" repository (or something like that), which is just an >> automatic rebuild of Fedora Extras 6 packages. For instance I need >> ~15 php-pear-??? rpms for EL5 that I just rebuilt from the Fedora >> Extras 6 sources - no modifications to the spec files needed. > > My 2 cent: It would IMHO make a lot more sense to have a second repo > that replaces stuff from the base or installs newer versions of gtk2 > in parallel to the one from the base; that would allow to ship newer > version of other programs that depend on newer system library, too. > > But I'd say EPEL should focus on bringing up the main repo that > doesn't replace stuff now before thinking about thinks like that. And > the Fedora project is probably not the best place for this effort, too > -- but I'm optimistic that there will soon be another project where > this will be fitting in (more news to come, just be a bit patient for > some weeks). I wasn't suggesting replacing stuff in the base at all, I just thought having more packages from Extras (all that will just rebuild without changes) available right away for EL5 would be nice, whether it is sponsored by Fedora or a 3rd party. Greg From Fedora at FamilleCollet.com Wed Mar 7 07:03:24 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 07 Mar 2007 08:03:24 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <45EE55C7.5090705@runlevel7.ca> References: <45EE55C7.5090705@runlevel7.ca> Message-ID: <45EE63BC.7070600@FamilleCollet.com> Greg Swallow a ?crit : > of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms > for EL5 that I just rebuilt from the Fedora Extras 6 sources - no > modifications to the spec files needed. I'm probably the maintener of some of them and i will like to push them on EPEL soon... (i need some time to prepare my build machine for my tests). Some of them are really useful (i think) because they were provided by old php version (bundle with), so EL4 -> EL5 mays requires then. Christopher Stone (maintener for most of the others) haven't put his status on http://www.fedoraproject.org/wiki/EPEL/ContributorStatus. Actually i'm waiting for a "green light" to begin the push... Regards From greg at runlevel7.ca Wed Mar 7 07:06:17 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Tue, 06 Mar 2007 23:06:17 -0800 Subject: rpms that just need a rebuild... In-Reply-To: <45EE63BC.7070600@FamilleCollet.com> References: <45EE55C7.5090705@runlevel7.ca> <45EE63BC.7070600@FamilleCollet.com> Message-ID: <45EE6469.5090500@runlevel7.ca> Remi Collet wrote: > Greg Swallow a ?crit : > >> of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms >> for EL5 that I just rebuilt from the Fedora Extras 6 sources - no >> modifications to the spec files needed. >> > > I'm probably the maintener of some of them and i will like to push them > on EPEL soon... (i need some time to prepare my build machine for my tests). > > Some of them are really useful (i think) because they were provided by > old php version (bundle with), so EL4 -> EL5 mays requires then. > Yes, I actually reported that as a bug in RHEL5 but was told to read the release notes - list of the missing ones in this bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218220 > Christopher Stone (maintener for most of the others) haven't put his > status on http://www.fedoraproject.org/wiki/EPEL/ContributorStatus. > > Actually i'm waiting for a "green light" to begin the push... > Sounds good. So just curious, what will be your philosophy in updating the EL5 rpms vs say the FC6 rpms? Do you think you will just rebuild the same versions at the same time? Or maybe update the FC6 rpm a week/month before the EL5 rpm (assuming the update is new features, not security)? Greg From fedora at leemhuis.info Wed Mar 7 07:20:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 07 Mar 2007 08:20:45 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <45EE6147.3020000@runlevel7.ca> References: <45EE55C7.5090705@runlevel7.ca> <45EE5FB5.7040905@leemhuis.info> <45EE6147.3020000@runlevel7.ca> Message-ID: <45EE67CD.4080507@leemhuis.info> On 07.03.2007 07:52, Greg Swallow wrote: > Thorsten Leemhuis wrote: >> On 07.03.2007 07:03, Greg Swallow wrote: >>> [...] >>> But I was wondering if there is room in the plans for a >>> "EPEL-unstable" repository (or something like that), which is just an >>> automatic rebuild of Fedora Extras 6 packages. For instance I need >>> ~15 php-pear-??? rpms for EL5 that I just rebuilt from the Fedora >>> Extras 6 sources - no modifications to the spec files needed. >> My 2 cent: It would IMHO make a lot more sense to have a second repo >> that replaces stuff from the base or installs newer versions of gtk2 >> in parallel to the one from the base; that would allow to ship newer >> version of other programs that depend on newer system library, too. >> But I'd say EPEL should focus on bringing up the main repo that >> doesn't replace stuff now before thinking about thinks like that. And >> the Fedora project is probably not the best place for this effort, too >> -- but I'm optimistic that there will soon be another project where >> this will be fitting in (more news to come, just be a bit patient for >> some weeks). > I wasn't suggesting replacing stuff in the base at all, I know. > I just thought > having more packages from Extras (all that will just rebuild without > changes) available right away for EL5 would be nice, whether it is > sponsored by Fedora or a 3rd party. Ohh, okay, then I got your wrong (I thought you wanted to constantly and automatically rebuild FE6 for EPEL5). My idea is to have most of Fedora Extras 6 packages available for EPEL5 soon. But it's not a automatic rebuild -- remember, someone has to maintain the stuff for quite some time, so we'll only build packages that have EPEL-maintainers. But I'm optimistic that with this way and a bit of co-maintainership we should be able to have most of FE6 available in EPEL5 soon. CU thl From fedora at leemhuis.info Wed Mar 7 07:25:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 07 Mar 2007 08:25:03 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <45EE63BC.7070600@FamilleCollet.com> References: <45EE55C7.5090705@runlevel7.ca> <45EE63BC.7070600@FamilleCollet.com> Message-ID: <45EE68CF.6050204@leemhuis.info> On 07.03.2007 08:03, Remi Collet wrote: > Greg Swallow a ?crit : >> of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms >> for EL5 that I just rebuilt from the Fedora Extras 6 sources - no >> modifications to the spec files needed. > > I'm probably the maintener of some of them and i will like to push them > on EPEL soon... (i need some time to prepare my build machine for my tests). > > Some of them are really useful (i think) because they were provided by > old php version (bundle with), so EL4 -> EL5 mays requires then. > > Christopher Stone (maintener for most of the others) haven't put his > status on http://www.fedoraproject.org/wiki/EPEL/ContributorStatus. > > Actually i'm waiting for a "green light" to begin the push... I'll work on a package maintainer policy today/tomorrow that lays down what kind of version-update policy we actually want for EPEL to avoid that we end up with a EPEL4 that has some brand new packages while others are quite old. I hope to discuss this policy then on this list and make something effective after next Sundays EPEL-SIG meeting. For EPEL5 it's probably not that pressuring, but needed quite soon, too. I'd say what's now in FE6 is suitable for EPEL5. There will probably a public CentOS 5 beta soon that we can use for testing. CU thl From greg at runlevel7.ca Wed Mar 7 07:32:16 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Tue, 06 Mar 2007 23:32:16 -0800 Subject: Release and update procedure for EPEL Message-ID: <45EE6A80.2060506@runlevel7.ca> Axel Thimm wrote: > Compare > > http://isoredirect.centos.org/centos/4/isos/i386/ > > to > > https://www.scientificlinux.org/download/ > > E.g. the range of 4.x versions. SL follows RH in maintaining each > point release, while CentOS kind of EOLs the previous point releases. (Sorry if this doesn't follow up to the previous messages properly, I wasn't subscribed to the list when this was posted) I think you missed that CentOS EOL's the previous point releases to http://vault.centos.org - 4.0, 4.1, 4.2, etc are all there if you want to stick to 4.3 for whatever reason. I think they just want to make mirroring their main repository less of a storage burden - And I think it works for them - there are a lot more CentOS mirrors that Scientific Linux mirrors. Greg From Fedora at FamilleCollet.com Wed Mar 7 07:47:36 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 07 Mar 2007 08:47:36 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <45EE6469.5090500@runlevel7.ca> References: <45EE55C7.5090705@runlevel7.ca> <45EE63BC.7070600@FamilleCollet.com> <45EE6469.5090500@runlevel7.ca> Message-ID: <45EE6E18.5050603@FamilleCollet.com> Greg Swallow a ?crit : >I actually reported that as a bug in RHEL5 but was told to read the release notes - list of the missing ones in this bug report: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218220 Thank's for the link. It's the first reason why i became a contributor : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190066 > Sounds good. So just curious, what will be your philosophy in updating > the EL5 rpms vs say the FC6 rpms? Do you think you will just rebuild > the same versions at the same time? Or maybe update the FC6 rpm a > week/month before the EL5 rpm (assuming the update is new features, not > security)? In the near future, FC6 could be the testing branch for EPEL, but when it become EOL (F8), i'll have to think to another way... php-pear are noarch but could have requires on php or pear version. I don't know which pear version will be on RHEL5. Hopes for 1.5.0, because 1.4.x has some problems with packaging https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197940 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222557 Of course analysing each Changelog is the first thing i always do. For example, php-pecl-zip would have been stick on 1.5.0 when 1.6.0 have change the class name (it's just an example, i don't know if zip is bundled with php on RHEL5). My biggest chalenge will be to create patch to an old version when a new version isn't compatible (API changes) but bugs are filed. Of course, i'm waiting for (and will try to follow) the official policy about version update on EPEL. Remi. P.S. hope my english is readable... From pertusus at free.fr Wed Mar 7 09:09:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 7 Mar 2007 10:09:57 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <45EE67CD.4080507@leemhuis.info> References: <45EE55C7.5090705@runlevel7.ca> <45EE5FB5.7040905@leemhuis.info> <45EE6147.3020000@runlevel7.ca> <45EE67CD.4080507@leemhuis.info> Message-ID: <20070307090957.GA3016@free.fr> On Wed, Mar 07, 2007 at 08:20:45AM +0100, Thorsten Leemhuis wrote: > > Ohh, okay, then I got your wrong (I thought you wanted to constantly and > automatically rebuild FE6 for EPEL5). > > My idea is to have most of Fedora Extras 6 packages available for EPEL5 > soon. But it's not a automatic rebuild -- remember, someone has to > maintain the stuff for quite some time, so we'll only build packages > that have EPEL-maintainers. But I'm optimistic that with this way and a > bit of co-maintainership we should be able to have most of FE6 available > in EPEL5 soon. I think that it would be nice to have automatic rebuild of F6 for the packages that are not in EPEL nor RHEL (in another repo, of course). That way the packages that change too often to be in EPEL and that don't have a maintainer close enough to upstream to know about what backport should be done could still be available. For a personnal example (always the same ;-) there is libdap. It works well with http://centos.karan.org/. There should then be a long term solution to extend this when F6 is dropped, but it would be in years, so we'll be able to see if such a repo is really necessary. -- Pat From pertusus at free.fr Wed Mar 7 09:26:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 7 Mar 2007 10:26:38 +0100 Subject: noticing the list for new packages? Message-ID: <20070307092638.GB3016@free.fr> Hello, I think that it would be nice if people doing branches in EPEL noticed the list such that it can be seen, and maybe discussed. This is not relevant for all packages, for example it is not interesting for an old stable utility package or a deprecated lib nobody uses anymore anyway, or some graphical apps that cannot have issues of compatibility or perl and python modules that haven't been changed in years. But for most libs, some modules and apps that are to be used by other apps for example compilers, doc apps translators, etc. I think it would be interesting that people wanting to maintain them post a short notice describing: * how stable is the software upstream * what kind of updating is intended (use latest versions, backport with explanation on what will be backported and even how...) * whether comaintainers are wanted * other? That way there could be a discussion, I am a bit scared that packages enter EPEL without discussion. I don't want this kind of stuff to become bureaucratic either. -- Pat From notting at redhat.com Wed Mar 7 21:07:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 16:07:21 -0500 Subject: Release and update procedure for EPEL In-Reply-To: <20070303104840.GB27400@neu.nirvana> References: <200703020636.45768.dennis@ausil.us> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> <20070303000452.GB23292@neu.nirvana> <45E90F3B.7050609@leemhuis.info> <20070303104840.GB27400@neu.nirvana> Message-ID: <20070307210721.GA25018@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > So, if we are not in a worse position that we already are, why not > benefit and have Bill update/fix guille in the "epelplus" repo? Because I don't really care about guile, I just want my app to work. :) Bill From notting at redhat.com Wed Mar 7 22:02:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:02:47 -0500 Subject: package stability In-Reply-To: <20070303105114.GC27400@neu.nirvana> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> Message-ID: <20070307220247.GC25018@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > On Sat, Mar 03, 2007 at 10:26:01AM +0100, Patrice Dumas wrote: > > Do we want to keep API/ABI stable over the corresponding RHEL release? > > It would be interesting to have a document that described RH's specs > in this area. E.g. which API/ABI are more important that others. RHEL > has certainly kept some parts more flexible than others, for example > wireless API/ABI on almost each kernel update. It depends on the release, but generally, symbols used by external modules must be kept fixed. However, various subsystems (libata, wireless) may change. With the exception of very specific things (the wireless-tools things mentioned, which caused its own headaches), the userspace library ABI is considered pretty much sacrosanct. Bill From mmcgrath at redhat.com Wed Mar 7 22:19:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 07 Mar 2007 16:19:50 -0600 Subject: package stability In-Reply-To: <20070307220247.GC25018@nostromo.devel.redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> Message-ID: <45EF3A86.5080403@redhat.com> Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > >> On Sat, Mar 03, 2007 at 10:26:01AM +0100, Patrice Dumas wrote: >> >>> Do we want to keep API/ABI stable over the corresponding RHEL release? >>> >> It would be interesting to have a document that described RH's specs >> in this area. E.g. which API/ABI are more important that others. RHEL >> has certainly kept some parts more flexible than others, for example >> wireless API/ABI on almost each kernel update. >> > > It depends on the release, but generally, symbols used by external > modules must be kept fixed. However, various subsystems (libata, wireless) > may change. > > With the exception of very specific things (the wireless-tools things > mentioned, which caused its own headaches), the userspace library ABI > is considered pretty much sacrosanct. > > Bill > Unlike in 'official' RHEL, I'd think the emphasis here is just on best effort for stability. As long as we're cautious I think it will be fine. -Mike From smooge at gmail.com Wed Mar 7 22:42:47 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 7 Mar 2007 15:42:47 -0700 Subject: package stability In-Reply-To: <20070303092601.GA2881@free.fr> References: <20070303092601.GA2881@free.fr> Message-ID: <80d7e4090703071442p2887a7a4mc39d7260e3c84419@mail.gmail.com> On 3/3/07, Patrice Dumas wrote: > Hello, > > Do we want to keep API/ABI stable over the corresponding RHEL release? > I think yes, but then we should really make sure that some libs don't > go to EPEL (for an example of a lib I maintain there is libdap which > changes API every 6 months or so). > > Is there something similar for apps, for example that searching paths > command-line options, config files, file formats, are backward > compatible? > > If we impose such constraints, maybe there could be a discussion before > a package enters EPEL. Not a formal review because there should be no > packaging/usability issues, but a verification that the package is > stable enough and there are enough people/firms interested such that > if the maintainer stops maintaining a package that needs work it won't > be really unmaintained. > After some thinking, this is my proposal: A package is 'frozen' at the time of a EL beta. This gives the EPEL people time to put together a 'DVD' or some such thing that can be used for large rollouts. When the EL goes gold, a finished set is published and kept to only security/feature fix updates til the next EL beta cycle. Security updates are done with the following preferences: If a backport patch is out, use that. If a patch is available via a minor update (say 4.5 to 4.7 versus 4.5 to 5.1). Else go to the latest supported upstream version. When the next beta release is done, packages are updated by maintainer preference. If there are requests for people to stay with rootmymachine-5.0 and the maintainer wants to go with 6.0 then a compat-rootmymachine5.0 or other approved naming scheme could be used by someone who wishes to maintain the old tree. For nearly maintenance only releases: (2.1/3.8), the maintainers would only be expected to do 'security updates.' For items like clamav, this might require a complete 'rebasing' push (0.88 to 0.90 as an example). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From notting at redhat.com Wed Mar 7 22:48:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:48:06 -0500 Subject: package stability In-Reply-To: <45EF3A86.5080403@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> Message-ID: <20070307224806.GA22202@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > Unlike in 'official' RHEL, I'd think the emphasis here is just on best > effort for stability. As long as we're cautious I think it will be fine. Anything we do should be very well documented, along the lines of: "API and ABI stability for packages in EPEL is NOT guaranteed. If you are an ISV, you should not base your software on these packages, or, if you do, be prepared to ship your own version." Bill From mmcgrath at redhat.com Wed Mar 7 22:54:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 07 Mar 2007 16:54:14 -0600 Subject: package stability In-Reply-To: <20070307224806.GA22202@nostromo.devel.redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070307224806.GA22202@nostromo.devel.redhat.com> Message-ID: <45EF4296.1030302@redhat.com> Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > >> Unlike in 'official' RHEL, I'd think the emphasis here is just on best >> effort for stability. As long as we're cautious I think it will be fine. >> > > Anything we do should be very well documented, along the lines of: > > "API and ABI stability for packages in EPEL is NOT guaranteed. If you are > an ISV, you should not base your software on these packages, or, if you do, > be prepared to ship your own version." > > Bill At the same time though it would be nice to get ISV's actually maintaining / co-maintaining packages. -Mike From Axel.Thimm at ATrpms.net Wed Mar 7 23:21:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 00:21:39 +0100 Subject: package stability In-Reply-To: <45EF3A86.5080403@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> Message-ID: <20070307232139.GC3217@neu.nirvana> On Wed, Mar 07, 2007 at 04:19:50PM -0600, Mike McGrath wrote: > Bill Nottingham wrote: > >Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > >>On Sat, Mar 03, 2007 at 10:26:01AM +0100, Patrice Dumas wrote: > >> > >>>Do we want to keep API/ABI stable over the corresponding RHEL release? > >>> > >>It would be interesting to have a document that described RH's specs > >>in this area. E.g. which API/ABI are more important that others. RHEL > >>has certainly kept some parts more flexible than others, for example > >>wireless API/ABI on almost each kernel update. > >> > > > >It depends on the release, but generally, symbols used by external > >modules must be kept fixed. However, various subsystems (libata, wireless) > >may change. > > > >With the exception of very specific things (the wireless-tools things > >mentioned, which caused its own headaches), the userspace library ABI > >is considered pretty much sacrosanct. > > > >Bill > > > Unlike in 'official' RHEL, I'd think the emphasis here is just on best > effort for stability. As long as we're cautious I think it will be fine. Well, "stability" is quite overloaded, so we may need to disambiguate it and decide on each flavour: a) stability as in doesn't break in itself b) stability as in doesn't break other external apps E.g. b) includes keeping API/ABIs stable and suggests backports. RHEL targets both. Do we, too? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Mar 7 23:26:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 00:26:13 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070307210721.GA25018@nostromo.devel.redhat.com> References: <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> <20070303000452.GB23292@neu.nirvana> <45E90F3B.7050609@leemhuis.info> <20070303104840.GB27400@neu.nirvana> <20070307210721.GA25018@nostromo.devel.redhat.com> Message-ID: <20070307232613.GD3217@neu.nirvana> On Wed, Mar 07, 2007 at 04:07:21PM -0500, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > why not benefit and have Bill update/fix guille > > Because I don't really care about guile, I just want my > app to work. :) But didn't you mention that you need to update/fix guille for your app's sake? That's all I wanted to say, I didn't suggest to place guille on your plate ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rtlm10 at gmail.com Thu Mar 8 00:59:27 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Wed, 7 Mar 2007 19:59:27 -0500 Subject: Release and update procedure for EPEL In-Reply-To: <20070303104840.GB27400@neu.nirvana> References: <1172812831.4651.497.camel@erato.phig.org> <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> <20070303000452.GB23292@neu.nirvana> <45E90F3B.7050609@leemhuis.info> <20070303104840.GB27400@neu.nirvana> Message-ID: <1ed4a0130703071659t622a2582x5473494e3faa3149@mail.gmail.com> On 3/3/07, Axel Thimm wrote: > > > Oh, we have much worse that that already in place: > > 3: > - customer buys RHEL > - customer get package foo from EPEL that ships with a bar which > does not exist in RHEL, so everybody thinks it's fine > - bar fubars customer's system (bar is a plugin, daemon, kernel > module, or something similar) > - customer report to RH that system does not work (doesn't boot, > firefox crashes, kernel oops) > - RH speds support time on customer only to find out that the bug is > not directly in firefox/kernel/etc. but in a pure add-on package > > In fact in all these years of "replacements" 3) has happened far more > often than 2) - the metrics would be 3)/#add-ons compared to > 2)/#replacment, but 2) is very close to zero. > > So, if we are not in a worse position that we already are, why not > benefit and have Bill update/fix guille in the "epelplus" repo? > This problem already exist for RH with third party packages / kernel modules / script installs. Third party stuff must account for a good 90% of the kernel dump cases we open with Red Hat. Their answer is simple, remove the third party stuff and reproduce the problem. Of course we can't but we do know who needs to do the fixing at this point. >From a customer standpoint the only difference I see between this and a EPEL package is that (if my experience with FE holds true) I might actually get a fix with out needing to arrange twelve conference calls, and eventually refusing to pay another cent to the ISV. Y'all do a much better job than any ISV I've ever dealt with. Keep up the good work! Now the case where a package has upgraded some thing Red Hat provides is another ball of wax. Red Hat still has the right to refuse to support someone else's package, but now its not as easy to get rid of. Sure I can downgrade but I'm sure some developer of mine will have found the only feature not implemented in the version Red Hat ships with. I'm constantly finding boxes where they've upgraded python and have broken all of the system utils, and more importantly yum. The part that really worries me is the case where say Red Hat does decide to upgrade a package to a similar or higher version than the one provided by EPEL. Now I'm in some odd situation where either package may upgrade the other depending on how close they are to each other. At least if there is a plus, bleeding, danger, whatever repo, I can use either the protectbase, or priorities plugin to yum to provide some degree of security. The brave souls willing to negate their support (or those running CentOS, ect. where support isn't the issue) can test the watters and report back to the more timid. ;-) Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From Axel.Thimm at ATrpms.net Thu Mar 8 02:05:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 03:05:25 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <1ed4a0130703071659t622a2582x5473494e3faa3149@mail.gmail.com> References: <45E81D98.6090407@leemhuis.info> <7874d9dd0703020633x789abab7u3a7c27a5c6149ab8@mail.gmail.com> <20070302165410.GA9050@nostromo.devel.redhat.com> <45E85F77.7000700@leemhuis.info> <20070302173201.GA10008@nostromo.devel.redhat.com> <45E86292.3070709@leemhuis.info> <20070303000452.GB23292@neu.nirvana> <45E90F3B.7050609@leemhuis.info> <20070303104840.GB27400@neu.nirvana> <1ed4a0130703071659t622a2582x5473494e3faa3149@mail.gmail.com> Message-ID: <20070308020525.GA13355@neu.nirvana> On Wed, Mar 07, 2007 at 07:59:27PM -0500, Russell Harrison wrote: > At least if there is a plus, bleeding, danger, whatever repo, I can use > either the protectbase, or priorities plugin to yum to provide some degree > of security. You only need these plugins if the repo were not split into pure-add-on and plus/bleeding/etc. In the latter case you either enable or not the "plus" repo - if you would additionally use any plugin not allowing RHEL upgrades you would not enable a single package in this repo. Or phrased differently: These plugins effectively try to split such a repo on the fly into pure-add-ons and replacing packages with the latter being turned off. But it is much better to do the splitting at the server-side as you have better control of what needs to go where. We would first have to decide if we want to allow such replacing packages (it's been a big no-go in Fedora-land), and if we would answer this positively we would have to think whether in one or two repos. Personally I'm for allowing replacements when needed and placing them (as well as any package depending on that replacement) into the "plus"/whatever repo. But it depends much on deciding whether we want to have stable API/ABI in EPEL like plain RHEL has. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Mar 8 05:50:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Mar 2007 06:50:05 +0100 Subject: package stability In-Reply-To: <80d7e4090703071442p2887a7a4mc39d7260e3c84419@mail.gmail.com> References: <20070303092601.GA2881@free.fr> <80d7e4090703071442p2887a7a4mc39d7260e3c84419@mail.gmail.com> Message-ID: <45EFA40D.4080903@leemhuis.info> On 07.03.2007 23:42, Stephen John Smoogen wrote: > > After some thinking, this is my proposal: > [...] I'm working on a policy currently. I'll take your ideas into account. I hope to finish the policy today. CU thl From pertusus at free.fr Thu Mar 8 09:44:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 10:44:03 +0100 Subject: package stability In-Reply-To: <45EF3A86.5080403@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> Message-ID: <20070308094403.GA2891@free.fr> On Wed, Mar 07, 2007 at 04:19:50PM -0600, Mike McGrath wrote: > > > Unlike in 'official' RHEL, I'd think the emphasis here is just on best > effort for stability. As long as we're cautious I think it will be fine. I personnally think that it is a bad idea. In my opinion there should be no difference between EPEL and RHEL packages. Also all we do in EPEL is best effort, not only for stability, we are volunteers. For packages that cannot achieve the same quality than RHEL packages sure they could be somewhere under the EPEL umbrella, say in EPEL plus or in a F6 rebuild, but I don't think it would be good to have package of less quality in the main EPEL repo. -- Pat From rdieter at math.unl.edu Thu Mar 8 12:42:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Mar 2007 06:42:55 -0600 Subject: package stability In-Reply-To: <20070308094403.GA2891@free.fr> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> Message-ID: <45F004CF.6080509@math.unl.edu> Patrice Dumas wrote: > On Wed, Mar 07, 2007 at 04:19:50PM -0600, Mike McGrath wrote: >>> >> Unlike in 'official' RHEL, I'd think the emphasis here is just on best >> effort for stability. As long as we're cautious I think it will be fine. > > I personnally think that it is a bad idea. In my opinion there should be > no difference between EPEL and RHEL packages. I'm with Mike here, that EPEL simply make a best effort, to be more in line with what (Fedora) Extras does. -- Rex From pertusus at free.fr Thu Mar 8 13:27:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 14:27:40 +0100 Subject: package stability In-Reply-To: <45F004CF.6080509@math.unl.edu> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> Message-ID: <20070308132740.GC2880@free.fr> On Thu, Mar 08, 2007 at 06:42:55AM -0600, Rex Dieter wrote: > > I'm with Mike here, that EPEL simply make a best effort, to be more in > line with what (Fedora) Extras does. As a user I enjoy centos for its stability, including ABI stability, and I guess other also do. If adding the main EPEL repo breaks that I think it will be of much less use. In Fedora Extras there is a best effort to be latest and greatest. It is the exact opposite, we cannot be in line with what is done for fedora. Having packages packagers cannot reasonably commmit to keep ABI stability in a separate repo under the EPEL umbrella would seem right to me, however. -- Pat From Axel.Thimm at ATrpms.net Thu Mar 8 14:00:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 15:00:41 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45EC8459.4010205@math.unl.edu> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> Message-ID: <20070308140041.GB30136@neu.nirvana> On Mon, Mar 05, 2007 at 02:58:01PM -0600, Rex Dieter wrote: > Axel Thimm wrote: > >On Mon, Mar 05, 2007 at 02:41:00PM -0600, Rex Dieter wrote: > > >>If an admin misconfigures their site, all bets are off, regardless. > > > >But the above forces him to configure the app. > > configuration is *optional*. > > >BTW I tried to find how > >fedora-usermgmt is supposed to fallback to simple useradd -r operation > >and didn't find anything. Are you sure it does that? > > I've only taken the maintainers' (Enrico Scholz) word for it. I trust > he knows what he's talking about. OK, I installed it on FC6/x86_64. I picked the README that suggests: > | fedora-useradd 42 -d /home/joe joe > > will create the user 'joe' having '/home/joe' as homedirectory. The > number '42' specifies an UID which is added to a configured, > system-wide base. By default, this base is '300' so that 'joe' will > have the uid 342. My "joe" landed on uid slot "5214". That would actually break when I turn on LDAP on this system, as there is a user on this slot. Furthermore the package describes itself as: > This package provides wrappers around useradd, userdel, groupadd and > groupdel to allow predictable but configurable uids/gids. The fallback, e.g. the default operation, be it either useradd -r or something I don't understand yet, certainly is not predictable. I guess that less than 1 permille of Fedora users even know that there is such a system to configure, and even less do configure it, so we can really assume that all packages using this method don't really need predictable uid/gids ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 14:34:35 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 15:34:35 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308140041.GB30136@neu.nirvana> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC2AD1.2000203@math.unl.edu> <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> Message-ID: <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 15:00:41 +0100, Axel Thimm wrote: > OK, I installed it on FC6/x86_64. I picked the README that suggests: > > > | fedora-useradd 42 -d /home/joe joe > > > > will create the user 'joe' having '/home/joe' as homedirectory. The > > number '42' specifies an UID which is added to a configured, > > system-wide base. By default, this base is '300' so that 'joe' will > > have the uid 342. > > My "joe" landed on uid slot "5214". In comparison, what do you get for plain "useradd joe"? For the different behaviour you would first need to enable fedora-usermgmt via the alternatives system. From dennis at ausil.us Thu Mar 8 14:37:52 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 8 Mar 2007 08:37:52 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070308140041.GB30136@neu.nirvana> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> Message-ID: <200703080837.52681.dennis@ausil.us> On Thursday 08 March 2007 08:00:41 am Axel Thimm wrote: > On Mon, Mar 05, 2007 at 02:58:01PM -0600, Rex Dieter wrote: > > Axel Thimm wrote: > OK, I installed it on FC6/x86_64. I picked the README that suggests: > > | fedora-useradd 42 -d /home/joe joe > > > > will create the user 'joe' having '/home/joe' as homedirectory. The > > number '42' specifies an UID which is added to a configured, > > system-wide base. By default, this base is '300' so that 'joe' will > > have the uid 342. > > My "joe" landed on uid slot "5214". That would actually break when I > turn on LDAP on this system, as there is a user on this slot. As a test i ran the exact same command on my desktop and my joe ended up at 10003 i double checked i had not configured /etc/fedora/usermgmt/baseuid and it says 300 which is the default offset. my user should have been 342 based on how its supposed to work as a further test i ran fedora-useradd 40 -d /home/bloggs bloggs that user got 10004 something is really wrong with it -- Dennis Gilmore, RHCE From dennis at ausil.us Thu Mar 8 14:40:47 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 8 Mar 2007 08:40:47 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> References: <20070305142524.GA2657@jadzia.bu.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200703080840.47668.dennis@ausil.us> On Thursday 08 March 2007 08:34:35 am Michael Schwendt wrote: > On Thu, 8 Mar 2007 15:00:41 +0100, Axel Thimm wrote: > > OK, I installed it on FC6/x86_64. I picked the README that suggests: > > > | fedora-useradd 42 -d /home/joe joe > > > > > > will create the user 'joe' having '/home/joe' as homedirectory. The > > > number '42' specifies an UID which is added to a configured, > > > system-wide base. By default, this base is '300' so that 'joe' will > > > have the uid 342. > > > > My "joe" landed on uid slot "5214". > > In comparison, what do you get for plain "useradd joe"? > > For the different behaviour you would first need to enable fedora-usermgmt > via the alternatives system. > i added a user smith who got 10005 which was the next uid after what i got earlier -- Dennis Gilmore, RHCE From mmcgrath at redhat.com Thu Mar 8 14:46:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 08:46:16 -0600 Subject: package stability In-Reply-To: <20070308132740.GC2880@free.fr> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> Message-ID: <45F021B8.3020708@redhat.com> Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 06:42:55AM -0600, Rex Dieter wrote: > >> I'm with Mike here, that EPEL simply make a best effort, to be more in >> line with what (Fedora) Extras does. >> > > As a user I enjoy centos for its stability, including ABI stability, and I > guess other also do. If adding the main EPEL repo breaks that I think it > will be of much less use. > I'll make a deal with you, if you can pay our volunteers what RH pays its engineers to do the type of backporting required to make the ABI's stay the same and we'll see to it that the EPEL packages are just like the RHEL ones. Otherwise this is a lesson in learning that you can't _make_ volunteers do anything and this, we're left with best effort. In this case its the spirit of the rule more so then the actual rule. > In Fedora Extras there is a best effort to be latest and greatest. It is > the exact opposite, we cannot be in line with what is done for fedora. > Yep, we want best effort for stability, not latest and greatest. > Having packages packagers cannot reasonably commmit to keep ABI > stability in a separate repo under the EPEL umbrella would seem right > to me, however See above. -Mike From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 15:01:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 16:01:26 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <200703080837.52681.dennis@ausil.us> References: <20070305142524.GA2657@jadzia.bu.edu> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <200703080837.52681.dennis@ausil.us> Message-ID: <20070308160126.cec35e54.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 08:37:52 -0600, Dennis Gilmore wrote: > On Thursday 08 March 2007 08:00:41 am Axel Thimm wrote: > > On Mon, Mar 05, 2007 at 02:58:01PM -0600, Rex Dieter wrote: > > > Axel Thimm wrote: > > > OK, I installed it on FC6/x86_64. I picked the README that suggests: > > > | fedora-useradd 42 -d /home/joe joe > > > > > > will create the user 'joe' having '/home/joe' as homedirectory. The > > > number '42' specifies an UID which is added to a configured, > > > system-wide base. By default, this base is '300' so that 'joe' will > > > have the uid 342. > > > > My "joe" landed on uid slot "5214". That would actually break when I > > turn on LDAP on this system, as there is a user on this slot. > As a test i ran the exact same command on my desktop and my joe ended up at > 10003 i double checked i had not configured /etc/fedora/usermgmt/baseuid > and it says 300 which is the default offset. my user should have been 342 > based on how its supposed to work > > as a further test i ran > fedora-useradd 40 -d /home/bloggs bloggs > > that user got 10004 something is really wrong with it No. fedora-usermgmt is _off_ by default. The numerical arg to fedora-useradd is void. The results is equal to "useradd foo". See e.g. rpm -qi fedora-usermgmt-shadow-utils Turn it on to get predictable uids/gids, that are relative to 300. From Axel.Thimm at ATrpms.net Thu Mar 8 15:49:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 16:49:16 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> References: <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308154916.GB31094@neu.nirvana> > On Thu, 8 Mar 2007 15:00:41 +0100, Axel Thimm wrote: > > This package provides wrappers around useradd, userdel, groupadd and > > groupdel to allow predictable but configurable uids/gids. > > The fallback, e.g. the default operation, be it either useradd -r or > something I don't understand yet, certainly is not predictable. I > guess that less than 1 permille of Fedora users even know that there > is such a system to configure, and even less do configure it, so we > can really assume that all packages using this method don't really > need predictable uid/gids ... On Thu, Mar 08, 2007 at 03:34:35PM +0100, Michael Schwendt wrote: > For the different behaviour you would first need to enable fedora-usermgmt > via the alternatives system. Which rather proves that it is useless. You either have the default unpredictable behaviour, or you need to configure global resources *per host* or *per site*. The default behaviour which accounts for 99.99% of all users is that people don't even know there is something to configure. And I probably made a very conservative guess. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 16:36:29 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 17:36:29 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308154916.GB31094@neu.nirvana> References: <20070305144047.GY29562@neu.nirvana> <45EC2CF1.3070308@math.unl.edu> <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> Message-ID: <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 16:49:16 +0100, Axel Thimm wrote: > > For the different behaviour you would first need to enable fedora-usermgmt > > via the alternatives system. > > Which rather proves that it is useless. You either have the default > unpredictable behaviour, or you need to configure global resources *per > host* or *per site*. Which is possible due to fedora-usermgmt packaging features. I haven't said that it is pretty or as easy as a one-line kickstart option. > The default behaviour which accounts for 99.99% of all users is that > people don't even know there is something to configure. The same percentage of users doesn't configure UID_*/GID_* either. From Philip.R.Schaffner at nasa.gov Thu Mar 8 16:39:33 2007 From: Philip.R.Schaffner at nasa.gov (Phil Schaffner) Date: Thu, 08 Mar 2007 11:39:33 -0500 Subject: RFP: octave and octave-forge for EL5 Message-ID: <1173371973.3844.20.camel@hazard2.larc.nasa.gov> Apparently Octave has been orphaned for EL5 , although it is still in Fedora Extras. Seems like octave and octave-forge are excellent candidates for EPEL. They do successfully build from FC6/7 src.rpm packages under the CentOS5 beta that is currently undergoing QA testing, albeit with a few additional requirements... octave SRPMS: fftw-3.1.2-3.fc6.src.rpm glpk-4.13-1.fc6.src.rpm hdf5-1.6.5-7.fc7.src.rpm octave-2.9.9-1.fc6.src.rpm rpmdevtools-5.3-1.fc6.src.rpm ufsparse-2.1.1-1.fc6.src.rpm octave RPMS: fftw-3.1.2-3.el5.i386.rpm fftw-debuginfo-3.1.2-3.el5.i386.rpm fftw-devel-3.1.2-3.el5.i386.rpm glpk-debuginfo-4.13-1.el5.i386.rpm glpk-devel-4.13-1.el5.i386.rpm glpk-utils-4.13-1.el5.i386.rpm hdf5-1.6.5-7.el5.i386.rpm hdf5-debuginfo-1.6.5-7.el5.i386.rpm hdf5-devel-1.6.5-7.el5.i386.rpm octave-2.9.9-1.el5.i386.rpm octave-debuginfo-2.9.9-1.el5.i386.rpm octave-devel-2.9.9-1.el5.i386.rpm rpmdevtools-5.3-1.el5.noarch.rpm ufsparse-2.1.1-1.el5.i386.rpm ufsparse-debuginfo-2.1.1-1.el5.i386.rpm ufsparse-devel-2.1.1-1.el5.i386.rpm For octave-forge: octave-forge SRPMS: cln-1.1.13-2.fc6.src.rpm ginac-1.3.6-1.fc7.src.rpm gsl-1.8-2.fc7.src.rpm libdap-3.7.2-3.fc7.src.rpm libnc-dap-3.6.2-5.fc7.src.rpm octave-forge-2006.07.09-7.fc6.src.rpm qhull-2003.1-6.fc6.src.rpm octave-forge RPMS: cln-1.1.13-2.el5.i386.rpm cln-debuginfo-1.1.13-2.el5.i386.rpm cln-devel-1.1.13-2.el5.i386.rpm ginac-1.3.6-1.el5.i386.rpm ginac-debuginfo-1.3.6-1.el5.i386.rpm ginac-devel-1.3.6-1.el5.i386.rpm ginac-utils-1.3.6-1.el5.i386.rpm libdap-3.7.2-3.el5.i386.rpm libdap-debuginfo-3.7.2-3.el5.i386.rpm libdap-devel-3.7.2-3.el5.i386.rpm libnc-dap-3.6.2-5.el5.i386.rpm libnc-dap-debuginfo-3.6.2-5.el5.i386.rpm libnc-dap-devel-3.6.2-5.el5.i386.rpm octave-forge-2006.07.09-7.el5.i386.rpm octave-forge-debuginfo-2006.07.09-7.el5.i386.rpm qhull-2003.1-6.el5.i386.rpm qhull-debuginfo-2003.1-6.el5.i386.rpm qhull-devel-2003.1-6.el5.i386.rpm This is not necessarily the exact set of packages that might be selected to address the goals of enterprise-level stability that have been discussed in recent posts, just what worked for me in a test-of-concept build. (e.g. not my "best effort" :-) Phil P.S. Could someone please fix the spelling in the Reply-to string? EPEL development disccusion From smooge at gmail.com Thu Mar 8 16:40:41 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 8 Mar 2007 09:40:41 -0700 Subject: package stability In-Reply-To: <45F021B8.3020708@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> Message-ID: <80d7e4090703080840ua76c325jc271d9f0ece80609@mail.gmail.com> On 3/8/07, Mike McGrath wrote: > Patrice Dumas wrote: > > On Thu, Mar 08, 2007 at 06:42:55AM -0600, Rex Dieter wrote: > > > >> I'm with Mike here, that EPEL simply make a best effort, to be more in > >> line with what (Fedora) Extras does. > >> > > > > As a user I enjoy centos for its stability, including ABI stability, and I > > guess other also do. If adding the main EPEL repo breaks that I think it > > will be of much less use. > > > I'll make a deal with you, if you can pay our volunteers what RH pays > its engineers to do the type of backporting required to make the ABI's > stay the same and we'll see to it that the EPEL packages are just like > the RHEL ones. Otherwise this is a lesson in learning that you can't > _make_ volunteers do anything and this, we're left with best effort. In > this case its the spirit of the rule more so then the actual rule. In my opinion this is a lesson that should be learned from Fedora Legacy. It takes a LOT of work to backport stuff.. and having un-paid volunteers do it is not something that will happen. I think (and I emphasize "think") that the average backport bug-fix in code known by the developer takes 12 hours of development time, and 10 hours of QA time to show that it fixes something, doesnt break otehr things, etc etc. If we were to use a salary of US$ 30.00/hour (which is low for maintenance coders..), that is a cost of US$ 660.00 per bug fixed. In cases where you are having to patch code you are not familiar with, the time factors are multiplied 2-3x. The average coder volunteer has about 2-4 hours per day that they can spend on focusing on their volunteer activity. This is leisure time that they are using and is usually considered a higher cost and may not be solid time. I do not know what the average bugs per package are that require a release. That would be a useful cost analysis to get an idea of how much a package support time and how many people are needed to support it. > > In Fedora Extras there is a best effort to be latest and greatest. It is > > the exact opposite, we cannot be in line with what is done for fedora. > > > Yep, we want best effort for stability, not latest and greatest. > > Having packages packagers cannot reasonably commmit to keep ABI > > stability in a separate repo under the EPEL umbrella would seem right > > to me, however > See above. > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Axel.Thimm at ATrpms.net Thu Mar 8 17:10:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 18:10:00 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> References: <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308171000.GA5543@neu.nirvana> On Thu, Mar 08, 2007 at 05:36:29PM +0100, Michael Schwendt wrote: > On Thu, 8 Mar 2007 16:49:16 +0100, Axel Thimm wrote: > > > > For the different behaviour you would first need to enable fedora-usermgmt > > > via the alternatives system. > > > > Which rather proves that it is useless. You either have the default > > unpredictable behaviour, or you need to configure global resources *per > > host* or *per site*. > > Which is possible due to fedora-usermgmt packaging features. I haven't > said that it is pretty or as easy as a one-line kickstart option. It's not about a beauty contest, it's about whether this is something we want to see being tuned like that at all. I wonder how many of the packagers making use of fedora-usermgmt are really aware that they are not really creating predictable uids/gids? And how many of them do rely on this feature and are falsely deceived? If your package works with plain useradd -r, that's OK, the use that. If not, then fedora-usermgmt does *not* save your day. Even worse: It may look localy as if it does and when deployed to users your package will boom. > > The default behaviour which accounts for 99.99% of all users is that > > people don't even know there is something to configure. > > The same percentage of users doesn't configure UID_*/GID_* either. Indeed, that's why we don't ship a tool that changes these values, and so why should we do so for useradd/fedora-usermgmt? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 17:47:41 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 18:47:41 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308171000.GA5543@neu.nirvana> References: <20070305145829.GZ29562@neu.nirvana> <45EC32AE.1070006@math.unl.edu> <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> Message-ID: <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 18:10:00 +0100, Axel Thimm wrote: > It's not about a beauty contest, it's about whether this is something > we want to see being tuned like that at all. So far there is no alternative. Perhaps we could use the core+extras merge to start a global fedora uid/gid registry finally? > I wonder how many of the > packagers making use of fedora-usermgmt are really aware that they are > not really creating predictable uids/gids? If not 100%, then the review process has failed. The packagers have registered their uid/gid (from 1 to 34 so far, imagine that!) at http://fedoraproject.org/wiki/PackageUserRegistry and apparently have never examined/verified their packages. > And how many of them do > rely on this feature and are falsely deceived? Without running into any symptoms? As in requesting uid 25, but getting 325 and not noticing it? ;) > If your package works with plain useradd -r, that's OK, the use > that. If not, then fedora-usermgmt does *not* save your day. Even > worse: It may look localy as if it does and when deployed to users > your package will boom. I agree with the first part, although it does not even try to achieve what fedora-usermgmt attempts at. But default fedora-useradd is just like plain useradd, so no "boom". From Axel.Thimm at ATrpms.net Thu Mar 8 18:00:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 19:00:54 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> References: <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308180054.GE5543@neu.nirvana> On Thu, Mar 08, 2007 at 06:47:41PM +0100, Michael Schwendt wrote: > On Thu, 8 Mar 2007 18:10:00 +0100, Axel Thimm wrote: > > > It's not about a beauty contest, it's about whether this is something > > we want to see being tuned like that at all. > > So far there is no alternative. Perhaps we could use the core+extras > merge to start a global fedora uid/gid registry finally? > > > I wonder how many of the > > packagers making use of fedora-usermgmt are really aware that they are > > not really creating predictable uids/gids? > > If not 100%, then the review process has failed. The packagers have > registered their uid/gid (from 1 to 34 so far, imagine that!) at > http://fedoraproject.org/wiki/PackageUserRegistry and apparently have > never examined/verified their packages. > > > And how many of them do > > rely on this feature and are falsely deceived? > > Without running into any symptoms? As in requesting uid 25, but > getting 325 and not noticing it? ;) > > > If your package works with plain useradd -r, that's OK, the use > > that. If not, then fedora-usermgmt does *not* save your day. Even > > worse: It may look localy as if it does and when deployed to users > > your package will boom. > > I agree with the first part, although it does not even try to achieve > what fedora-usermgmt attempts at. But default fedora-useradd is > just like plain useradd, so no "boom". Read closer: The above was splitting the use cases into such that would work with plain useradd -r and such that really require something more. You agree with the first set of packages, so let's focus on the latter: The packager has setup his fedora-usermgmt and indeed the uid/gid he requests in his local setup is predictable and works fine for him. But not on 99.99% of the users' system. There it goes "boom". And if there is no such package requiring more than useradd -r, then that's for the best, we can simply rip it off all 34 packages that use fedora-usermgmt ... And the next worse illusion with thsi concept: The fixed uid approach makes mostly sense for uids that are spawning packages like say uid/gid apache. So if we assume we have need for such a uid/gid and one package gets installed before configuring and the other after then you get de-synced uid/gids on the *same* system. The more I think about this solution the more of a can of worms it is. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 18:11:19 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 19:11:19 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308180054.GE5543@neu.nirvana> References: <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> Message-ID: <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 19:00:54 +0100, Axel Thimm wrote: > Read closer: The above was splitting the use cases into such that > would work with plain useradd -r and such that really require > something more. You agree with the first set of packages, so let's > focus on the latter: > > The packager has setup his fedora-usermgmt and indeed the uid/gid he > requests in his local setup is predictable and works fine for him. But > not on 99.99% of the users' system. There it goes "boom". Explain further: why does it go "boom"? Because the packager does not understand that the %uid in the spec file is a _relative_ value, which is still predictable for the package _user_. > And if there is no such package requiring more than useradd -r, then > that's for the best, we can simply rip it off all 34 packages that use > fedora-usermgmt ... If those that would benefit from a fixed uid can get one. > And the next worse illusion with thsi concept: The fixed uid approach > makes mostly sense for uids that are spawning packages like say > uid/gid apache. So if we assume we have need for such a uid/gid and > one package gets installed before configuring and the other after then > you get de-synced uid/gids on the *same* system. That is not how fedora-usermgmt works. It is inserted at the package/repository level, not at run-time when it would be too late. From pertusus at free.fr Thu Mar 8 18:15:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 19:15:35 +0100 Subject: RFP: octave and octave-forge for EL5 In-Reply-To: <1173371973.3844.20.camel@hazard2.larc.nasa.gov> References: <1173371973.3844.20.camel@hazard2.larc.nasa.gov> Message-ID: <20070308181535.GC2954@free.fr> On Thu, Mar 08, 2007 at 11:39:33AM -0500, Phil Schaffner wrote: > > libdap-3.7.2-3.fc7.src.rpm > libnc-dap-3.6.2-5.fc7.src.rpm libnc-dap API/ABI is stable, but libdap is very unstable, and I am not convinced that it is a right candidate for EPEL. I will discuss that with upstream, however. -- Pat From Axel.Thimm at ATrpms.net Thu Mar 8 18:48:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 19:48:24 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> References: <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308184824.GB10906@neu.nirvana> On Thu, Mar 08, 2007 at 07:11:19PM +0100, Michael Schwendt wrote: > On Thu, 8 Mar 2007 19:00:54 +0100, Axel Thimm wrote: > > > Read closer: The above was splitting the use cases into such that > > would work with plain useradd -r and such that really require > > something more. You agree with the first set of packages, so let's > > focus on the latter: > > > > The packager has setup his fedora-usermgmt and indeed the uid/gid he > > requests in his local setup is predictable and works fine for him. But > > not on 99.99% of the users' system. There it goes "boom". > > Explain further: why does it go "boom"? > > Because the packager does not understand that the %uid in the spec file is > a _relative_ value, which is still predictable for the package _user_. For example. The bug is in different non-determinsitic behaviour this package exhibits dependening on whether and how it is being configured. > > And if there is no such package requiring more than useradd -r, then > > that's for the best, we can simply rip it off all 34 packages that use > > fedora-usermgmt ... > > If those that would benefit from a fixed uid can get one. Obviously none needs one otherwise the 99.99% of users would had noticed. Alternatively if a package does need one, then obviously none of the 99.99% of users uses this package. So anyway you turn it you will find that this machinery is unused overkill "fixing" something that isn't broken. > > And the next worse illusion with thsi concept: The fixed uid approach > > makes mostly sense for uids that are spawning packages like say > > uid/gid apache. So if we assume we have need for such a uid/gid and > > one package gets installed before configuring and the other after then > > you get de-synced uid/gids on the *same* system. > > That is not how fedora-usermgmt works. It is inserted at the > package/repository level, not at run-time when it would be too late. What? It does run at package installation time, right? That's far from being repository level. To put the above example in very simple words: Install package A with "usermgmt"-uid 42, then configure usermgmt, then install package B which will have a completely different view of "usermgmt"-uid 42. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 8 18:58:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 19:58:10 +0100 Subject: EPEL vs Fedora main Message-ID: <20070308185810.GC10906@neu.nirvana> The current discussion about fedora-usermgr is an example of most probably a bad choice in Fedora which stalls EPEL. What will the general consensus be in this and further conflicting situations? Bringing this upstream, e.g. to Fedora main, is a noble thing, but waiting for such things to resolve in Fedora-land takes a long time, and in Fedora many people are more willing to compromise on stuff they consider sub-optimal than in RHEL. So will we be able to decide on anything deviating from Fedora or will everything that comes up in RHEL land need to go through the Fedora machinery? Of course, the highest commandment remains to be compatible to Fedora, but only as much as is really possible, and not blindly inherit everything that's being semi-tolerated in Fedora. If we can stand on our own feet, then we should start by voting on whether we want fedora-usermgmt to be part of RHEL or not. We can then move on to other important things as EPEL sig, and hope that the issue will be ironed out on Fedora someday. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 19:50:48 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 20:50:48 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308184824.GB10906@neu.nirvana> References: <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> Message-ID: <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 19:48:24 +0100, Axel Thimm wrote: > On Thu, Mar 08, 2007 at 07:11:19PM +0100, Michael Schwendt wrote: > > On Thu, 8 Mar 2007 19:00:54 +0100, Axel Thimm wrote: > > > > > Read closer: The above was splitting the use cases into such that > > > would work with plain useradd -r and such that really require > > > something more. You agree with the first set of packages, so let's > > > focus on the latter: > > > > > > The packager has setup his fedora-usermgmt and indeed the uid/gid he > > > requests in his local setup is predictable and works fine for him. But > > > not on 99.99% of the users' system. There it goes "boom". > > > > Explain further: why does it go "boom"? > > > > Because the packager does not understand that the %uid in the spec file is > > a _relative_ value, which is still predictable for the package _user_. > > For example. The bug is in different non-determinsitic behaviour this > package exhibits dependening on whether and how it is being > configured. So, in your scenario any package that does "useradd foo" goes "boom"? [In an earlier mail you complained about fedora-useradd picking a uid that useradd would have picked by default, too.] > > > And if there is no such package requiring more than useradd -r, then > > > that's for the best, we can simply rip it off all 34 packages that use > > > fedora-usermgmt ... > > > > If those that would benefit from a fixed uid can get one. > > Obviously none needs one otherwise the 99.99% of users would had > noticed. Users, who want the uids fixed *per site* would notice. Users, who want fixed uids per life-time of [backup] data and under consideration of complete reinstalls, would notice. > Alternatively if a package does need one, then obviously none > of the 99.99% of users uses this package. That might be true. Nobody has said that the package's target group is big. It is no silver-bullet. It has negative sides, too. Don't focus on fighting everyone who doesn't fight fedora-usermgmt. > So anyway you turn it you > will find that this machinery is unused overkill "fixing" something > that isn't broken. Depends on the definition of "broken". Restrictions and missing features can be seen as one form of breakage, too. > > > And the next worse illusion with thsi concept: The fixed uid approach > > > makes mostly sense for uids that are spawning packages like say > > > uid/gid apache. So if we assume we have need for such a uid/gid and > > > one package gets installed before configuring and the other after then > > > you get de-synced uid/gids on the *same* system. > > > > That is not how fedora-usermgmt works. It is inserted at the > > package/repository level, not at run-time when it would be too late. > > What? It does run at package installation time, right? That's far from > being repository level. To put the above example in very simple words: > Install package A with "usermgmt"-uid 42, then configure usermgmt, > then install package B which will have a completely different view of > "usermgmt"-uid 42. It provides means to avoid that *if* you want that. From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 20:04:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 21:04:30 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308185810.GC10906@neu.nirvana> References: <20070308185810.GC10906@neu.nirvana> Message-ID: <20070308210430.18aec52a.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 19:58:10 +0100, Axel Thimm wrote: > The current discussion about fedora-usermgr is an example of most > probably a bad choice in Fedora which stalls EPEL. In Fedora land, fedora-usermgmt is an optional packaging technique. No committee has decided on it before, IIRC. Guidelines with regard to useradd/userdel don't exist either, do they? From pertusus at free.fr Thu Mar 8 20:31:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 21:31:52 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308185810.GC10906@neu.nirvana> References: <20070308185810.GC10906@neu.nirvana> Message-ID: <20070308203152.GA2958@free.fr> On Thu, Mar 08, 2007 at 07:58:10PM +0100, Axel Thimm wrote: > The current discussion about fedora-usermgr is an example of most > probably a bad choice in Fedora which stalls EPEL. The fact that it is a bad choice is your opinion. And I can't see why it stalls EPEL. It could also be considered that it is the opposition to fedora-usermgr that stalls EPEL. (To be clear I haven't any opinion on fedora-usermgr myself, except that I know that 'skilled and known to have made right technical choices in the past' contributors are against while other are for). -- Pat From pertusus at free.fr Thu Mar 8 20:34:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 21:34:59 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308203152.GA2958@free.fr> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> Message-ID: <20070308203459.GB2958@free.fr> On Thu, Mar 08, 2007 at 09:31:52PM +0100, Patrice Dumas wrote: > > (To be clear I haven't any opinion on fedora-usermgr myself, except that > I know that 'skilled and known to have made right technical choices in > the past' contributors are against while other are for). After reading my comment it seems to be rather unintelligible. To rephrase it: there are skilled contributors both among those who oppose to fedora-usermgr and those who are for fedora-usermgr. -- Pat From Axel.Thimm at ATrpms.net Thu Mar 8 21:14:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 22:14:06 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308203152.GA2958@free.fr> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> Message-ID: <20070308211406.GF10906@neu.nirvana> On Thu, Mar 08, 2007 at 09:31:52PM +0100, Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 07:58:10PM +0100, Axel Thimm wrote: > > The current discussion about fedora-usermgr is an example of most > > probably a bad choice in Fedora which stalls EPEL. > > The fact that it is a bad choice is your opinion. There is a "probably" in my sentence above to show that there are a few people on this list that seem to not hate fedora-usermgr. Note that the issue started with a collective "I have fedora-usermgr, too" thread here. If it were a pure personal view my wording would had been much more stronger ;) > And I can't see why it stalls EPEL. It could also be considered that > it is the opposition to fedora-usermgr that stalls EPEL. Check the thread. After identifying that fedora-usermgr is not liked by "probably" the majority around here it the issue was "escalated" to be handled "upstream" in Fedora. If we had a quick voting here, we'd be past this issue by now, while now we're waiting on something to happen in Fedora-land. That's what I mean by being stalled. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 8 21:34:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 22:34:54 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> References: <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308213454.GG10906@neu.nirvana> On Thu, Mar 08, 2007 at 08:50:48PM +0100, Michael Schwendt wrote: > On Thu, 8 Mar 2007 19:48:24 +0100, Axel Thimm wrote: > > > On Thu, Mar 08, 2007 at 07:11:19PM +0100, Michael Schwendt wrote: > > > On Thu, 8 Mar 2007 19:00:54 +0100, Axel Thimm wrote: > > > > > > > Read closer: The above was splitting the use cases into such that > > > > would work with plain useradd -r and such that really require > > > > something more. You agree with the first set of packages, so let's > > > > focus on the latter: > > > > > > > > The packager has setup his fedora-usermgmt and indeed the uid/gid he > > > > requests in his local setup is predictable and works fine for him. But > > > > not on 99.99% of the users' system. There it goes "boom". > > > > > > Explain further: why does it go "boom"? > > > > > > Because the packager does not understand that the %uid in the spec file is > > > a _relative_ value, which is still predictable for the package _user_. > > > > For example. The bug is in different non-determinsitic behaviour this > > package exhibits dependening on whether and how it is being > > configured. > > So, in your scenario any package that does "useradd foo" goes "boom"? No, not my scenario, but any scenario. There are two kind of packages: a) packages not requiring fixed uid/gids: useradd -r is more than enough b) packages requiring fixed uid/gids: fedora-usermgmt's default of going useradd -r breaks the promise of fixed or semi-fixed uids/gids In neither case does fedora-usermgmt provide any benefit. So, that's not only about seeking a scenario where it goes boom, it's about seeking one where it makes sense in the first place. And yes, iff a package requires a *fixed* uid/gid and used useradd -r w/o the uid/gid breaks and goes boom just the same. > [In an earlier mail you complained about fedora-useradd picking a uid > that useradd would have picked by default, too.] Yes, so? Do you see a contradiction anywhere? I complain about a tool that is supposedly used for the *need* of predicting uid/gid that in reality just calls useradd -r. > > > > And if there is no such package requiring more than useradd -r, then > > > > that's for the best, we can simply rip it off all 34 packages that use > > > > fedora-usermgmt ... > > > > > > If those that would benefit from a fixed uid can get one. > > > > Obviously none needs one otherwise the 99.99% of users would had > > noticed. > > Users, who want the uids fixed *per site* would notice. Users, who want > fixed uids per life-time of [backup] data and under consideration of > complete reinstalls, would notice. Would, but obviously didn't. Which means that there isn't really any significant number of users. > > Alternatively if a package does need one, then obviously none > > of the 99.99% of users uses this package. > > That might be true. Nobody has said that the package's target group is > big. It is no silver-bullet. It has negative sides, too. Don't focus > on fighting everyone who doesn't fight fedora-usermgmt. No, my focus is on building something that is rock-solid for 99.99% (and more) of the userbase out there. Not about a dozen users ... > > So anyway you turn it you will find that this machinery is unused > > overkill "fixing" something that isn't broken. > > Depends on the definition of "broken". Restrictions and missing > features can be seen as one form of breakage, too. The current situation with fixed/non-fixed uid/gid isn't ideal, I agree 100%, but this kind of fix/workaround just makes things worse by pretending to fix something that it doesn't fix. > > > > And the next worse illusion with thsi concept: The fixed uid > > > > approach makes mostly sense for uids that are spawning > > > > packages like say uid/gid apache. So if we assume we have need > > > > for such a uid/gid and one package gets installed before > > > > configuring and the other after then you get de-synced > > > > uid/gids on the *same* system. > > > > > > That is not how fedora-usermgmt works. It is inserted at the > > > package/repository level, not at run-time when it would be too > > > late. > > > > What? It does run at package installation time, right? That's far > > from being repository level. To put the above example in very > > simple words: Install package A with "usermgmt"-uid 42, then > > configure usermgmt, then install package B which will have a > > completely different view of "usermgmt"-uid 42. > > It provides means to avoid that *if* you want that. OK, I bite. Which means does it provide? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Mar 8 21:32:14 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 22:32:14 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308211406.GF10906@neu.nirvana> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> Message-ID: <20070308213214.GD2958@free.fr> On Thu, Mar 08, 2007 at 10:14:06PM +0100, Axel Thimm wrote: > > Check the thread. After identifying that fedora-usermgr is not liked > by "probably" the majority around here it the issue was "escalated" to > be handled "upstream" in Fedora. If we had a quick voting here, we'd > be past this issue by now, while now we're waiting on something to > happen in Fedora-land. That's what I mean by being stalled. A quick voting here wouldn't mean anything, as I said in another place in the thread. There are other contributors that will certainly contribute to EPEL that are not there, among them major Fedora contributors that have relevant technical expertise on that subject. EPEL is barely existing, lets not pretend there is allready a community in place. The Fedora community is really existing. And also the majority isn't necessarily relevant. I have seen people being wrong against a consensus because their use case was different and they had have more experience on a subject. -- Pat From Axel.Thimm at ATrpms.net Thu Mar 8 21:44:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 22:44:10 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308213214.GD2958@free.fr> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> Message-ID: <20070308214410.GH10906@neu.nirvana> On Thu, Mar 08, 2007 at 10:32:14PM +0100, Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 10:14:06PM +0100, Axel Thimm wrote: > > > > Check the thread. After identifying that fedora-usermgr is not liked > > by "probably" the majority around here it the issue was "escalated" to > > be handled "upstream" in Fedora. If we had a quick voting here, we'd > > be past this issue by now, while now we're waiting on something to > > happen in Fedora-land. That's what I mean by being stalled. > > A quick voting here wouldn't mean anything, as I said in another place > in the thread. There are other contributors that will certainly > contribute to EPEL that are not there, among them major Fedora > contributors that have relevant technical expertise on that subject. > EPEL is barely existing, lets not pretend there is allready a community > in place. OK, so if we don't exist, what exactly is then our mandate here? Why is there any traffic on this list? This *is* the part of the Fedora community that *cares* about RHEL and EPEL. And there were invitations sent to various Fedora lists where contributors were invited to join up. > The Fedora community is really existing. And also the majority isn't > necessarily relevant. I have seen people being wrong against a > consensus because their use case was different and they had have > more experience on a subject. If you don't trust the majority how will you get to some decision at all? It's either a majority's call or a benevolent dictator's. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Mar 8 21:56:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 22:56:32 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308214410.GH10906@neu.nirvana> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> Message-ID: <20070308215632.GE2958@free.fr> On Thu, Mar 08, 2007 at 10:44:10PM +0100, Axel Thimm wrote: > > OK, so if we don't exist, what exactly is then our mandate here? Why > is there any traffic on this list? I am not saying that EPEL don't exist, I am saying that it is very new. And that we should ask more mature Fedora main for issues when there are people in fedora with expertise on that subject. > This *is* the part of the Fedora community that *cares* about RHEL and > EPEL. And there were invitations sent to various Fedora lists where > contributors were invited to join up. The first mail on the list date from Tue, 27 Feb 2007! 11 days ago! It would be wise to rely on Fedora support for some time. > > The Fedora community is really existing. And also the majority isn't > > necessarily relevant. I have seen people being wrong against a > > consensus because their use case was different and they had have > > more experience on a subject. > > If you don't trust the majority how will you get to some decision at > all? It's either a majority's call or a benevolent dictator's. Consensus through discussion may also be an option. Currently the guidelines are not finished, the relationship between Fedora, EPEL and RHEL are not completly clear, let's not hurry on a touchy subject like fedora-usermgt. There are many more important things to discuss about that may be less controversial. -- Pat From notting at redhat.com Thu Mar 8 21:59:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 16:59:26 -0500 Subject: package stability In-Reply-To: <45EF4296.1030302@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070307224806.GA22202@nostromo.devel.redhat.com> <45EF4296.1030302@redhat.com> Message-ID: <20070308215926.GC5337@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > > "API and ABI stability for packages in EPEL is NOT guaranteed. If you are > > an ISV, you should not base your software on these packages, or, if you > > do, > > be prepared to ship your own version." > > At the same time though it would be nice to get ISV's actually > maintaining / co-maintaining packages. Sure. But I'm not sure I want an ISV saying "To run our app, please install XYZ from EPEL." Bill From notting at redhat.com Thu Mar 8 22:03:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 17:03:04 -0500 Subject: remove fedora-usermgmt? In-Reply-To: <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> References: <20070305203727.GA29562@neu.nirvana> <45EC805C.5020106@math.unl.edu> <20070305204844.GD29562@neu.nirvana> <45EC8459.4010205@math.unl.edu> <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308220304.GD5337@nostromo.devel.redhat.com> Michael Schwendt (mschwendt.tmp0701.nospam at arcor.de) said: > So far there is no alternative. Perhaps we could use the core+extras > merge to start a global fedora uid/gid registry finally? Absolutely. It means taking over the 100-499 space, but IMO, it *needs* to be done. Bill, way behind on e-mail From pertusus at free.fr Thu Mar 8 22:03:47 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 23:03:47 +0100 Subject: package stability In-Reply-To: <80d7e4090703080840ua76c325jc271d9f0ece80609@mail.gmail.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <80d7e4090703080840ua76c325jc271d9f0ece80609@mail.gmail.com> Message-ID: <20070308220347.GF2958@free.fr> On Thu, Mar 08, 2007 at 09:40:41AM -0700, Stephen John Smoogen wrote: > > In my opinion this is a lesson that should be learned from Fedora > Legacy. It takes a LOT of work to backport stuff.. and having un-paid > volunteers do it is not something that will happen. Why? If this also benefit to them, sure they'll do the backport. One prominent reason, in my opinion why Fedora Legacy died is that RHEL/Centos were better substitutes. There is no substitute for EPEL, we can expect more volunteers. Debian is run by volunteers and they more or less achieve that, I can't see why we couldn't. > I do not know what the average bugs per package are that require a > release. That would be a useful cost analysis to get an idea of how > much a package support time and how many people are needed to support > it. For those packages that don't pass the benefit cost analysis, a repo where ABI/API isn't important could be used (like EPEL testing, or EPEL plus or whatever). -- Pat From mmcgrath at redhat.com Thu Mar 8 22:13:25 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 16:13:25 -0600 Subject: EPEL vs Fedora main In-Reply-To: <20070308215632.GE2958@free.fr> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> <20070308215632.GE2958@free.fr> Message-ID: <45F08A85.1000204@redhat.com> Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 10:44:10PM +0100, Axel Thimm wrote: > >> OK, so if we don't exist, what exactly is then our mandate here? Why >> is there any traffic on this list? >> > > I am not saying that EPEL don't exist, I am saying that it is very > new. And that we should ask more mature Fedora main for issues when > there are people in fedora with expertise on that subject. > > Actually I'd argue that the average EPEL contributor is far more dedicated / knowledgeable then the average Fedora Extras contributor. This is nothing against Extras, its just that EPEL has attracted a special kind of extras contributor. >> This *is* the part of the Fedora community that *cares* about RHEL and >> EPEL. And there were invitations sent to various Fedora lists where >> contributors were invited to join up. >> > > The first mail on the list date from Tue, 27 Feb 2007! 11 days ago! > It would be wise to rely on Fedora support for some time. > Actually EPEL has existed for close to 7 months now. Some conversations about it took place even before that. We're not new, additionally the core SIG is extremely experienced in the Fedora workings. http://fedoraproject.org/wiki/EPEL/SIG >>> The Fedora community is really existing. And also the majority isn't >>> necessarily relevant. I have seen people being wrong against a >>> consensus because their use case was different and they had have >>> more experience on a subject. >>> >> If you don't trust the majority how will you get to some decision at >> all? It's either a majority's call or a benevolent dictator's. >> > > Consensus through discussion may also be an option. > > Currently the guidelines are not finished, the relationship between > Fedora, EPEL and RHEL are not completly clear, let's not hurry on a > touchy subject like fedora-usermgt. There are many more important > things to discuss about that may be less controversial. > The relationship between red hat and fedora is not completely clear. Heck, even the merge of core and extras isn't 100% clear. From what I gather fedora-usermgmt won't work in RHEL4 (from the authors words). So, IMHO, its done. There's nothing to discuss. If upstream changes it so its compatible then we can examine it at that time. But right now, we have no choice but to remove it. -Mike From pertusus at free.fr Thu Mar 8 22:08:21 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 23:08:21 +0100 Subject: package stability In-Reply-To: <45F021B8.3020708@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> Message-ID: <20070308220821.GG2958@free.fr> On Thu, Mar 08, 2007 at 08:46:16AM -0600, Mike McGrath wrote: > > > I'll make a deal with you, if you can pay our volunteers what RH pays > its engineers to do the type of backporting required to make the ABI's > stay the same and we'll see to it that the EPEL packages are just like > the RHEL ones. Otherwise this is a lesson in learning that you can't I don't get it. Fedora extras is run by volunteers that are not paid by RH, still is is ver successfull. Why do you want somebody to pay? Why not rely on volunteers? It is all EPEL is about? > _make_ volunteers do anything and this, we're left with best effort. In That is always true. It is always best effort. But it is pointless to say, hey, let's put this package in EPEL, although we know we won't be able to keep the API/ABI stability. What I am saying is that it seems better to have a goal of API/ABI compatibility and do our best to achieve it, and don't start with saying API/ABI compatibility is not a goal. -- Pat From mmcgrath at redhat.com Thu Mar 8 22:15:03 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 16:15:03 -0600 Subject: package stability In-Reply-To: <20070308215926.GC5337@nostromo.devel.redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070307224806.GA22202@nostromo.devel.redhat.com> <45EF4296.1030302@redhat.com> <20070308215926.GC5337@nostromo.devel.redhat.com> Message-ID: <45F08AE7.3050700@redhat.com> Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > >>> "API and ABI stability for packages in EPEL is NOT guaranteed. If you are >>> an ISV, you should not base your software on these packages, or, if you >>> do, >>> be prepared to ship your own version." >>> >> At the same time though it would be nice to get ISV's actually >> maintaining / co-maintaining packages. >> > > Sure. But I'm not sure I want an ISV saying "To run our app, please > install XYZ from EPEL." > > Why not? I think it'd be a great vehicle to get these companies involved. -Mike From notting at redhat.com Thu Mar 8 22:12:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 17:12:34 -0500 Subject: package stability In-Reply-To: <45F08AE7.3050700@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070307224806.GA22202@nostromo.devel.redhat.com> <45EF4296.1030302@redhat.com> <20070308215926.GC5337@nostromo.devel.redhat.com> <45F08AE7.3050700@redhat.com> Message-ID: <20070308221233.GG5337@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > >Sure. But I'm not sure I want an ISV saying "To run our app, please > >install XYZ from EPEL." > > Why not? I think it'd be a great vehicle to get these companies involved. If XYZ is something *not* maintained by that ISV, and Joe Packager goes AWOL? Bill From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 22:18:39 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 23:18:39 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308213454.GG10906@neu.nirvana> References: <20070308140041.GB30136@neu.nirvana> <20070308153435.c901ac87.mschwendt.tmp0701.nospam@arcor.de> <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> Message-ID: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 22:34:54 +0100, Axel Thimm wrote: > > So, in your scenario any package that does "useradd foo" goes "boom"? > > No, not my scenario, but any scenario. There are two kind of packages: > > a) packages not requiring fixed uid/gids: useradd -r is more than > enough For single hosts. Maybe. The next time you reinstall from scratch, you cannot predict whether you end up with the same uids/gids, though. Just to be sure, don't get me wrong. It's not a feature with a huge target group. > b) packages requiring fixed uid/gids: fedora-usermgmt's default of > going useradd -r breaks the promise of fixed or semi-fixed uids/gids For _fixed_ (!) uids/gids, you don't use fedora-usermgmt, but useradd -u. useradd -r does not yield fixed, static or predictable results. And fedora-usermgmt (when enabled) gives predictable and static uids/gids, albeit not fixed ones. You don't need it when you need fixed uids/gids. Fixed => fixed world-wide => because a uid/gid may be compiled into the software (!) and must be the same for every installation of Fedora. This is not something fedora-usermgmt is used for. > I complain about a tool > that is supposedly used for the *need* of predicting uid/gid that in > reality just calls useradd -r. Well, that's because the default uid range is not allocated in any official way. > The current situation with fixed/non-fixed uid/gid isn't ideal, I > agree 100%, but this kind of fix/workaround just makes things worse by > pretending to fix something that it doesn't fix. I don't think it pretends that. See above. > > > What? It does run at package installation time, right? That's far > > > from being repository level. To put the above example in very > > > simple words: Install package A with "usermgmt"-uid 42, then > > > configure usermgmt, then install package B which will have a > > > completely different view of "usermgmt"-uid 42. > > > > It provides means to avoid that *if* you want that. > > OK, I bite. Which means does it provide? less fedora-usermgmt.spec ; echo "And I've never said it would be pretty..." From mmcgrath at redhat.com Thu Mar 8 22:20:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 16:20:32 -0600 Subject: package stability In-Reply-To: <20070308220821.GG2958@free.fr> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> Message-ID: <45F08C30.6090109@redhat.com> Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 08:46:16AM -0600, Mike McGrath wrote: > >>> >>> >> I'll make a deal with you, if you can pay our volunteers what RH pays >> its engineers to do the type of backporting required to make the ABI's >> stay the same and we'll see to it that the EPEL packages are just like >> the RHEL ones. Otherwise this is a lesson in learning that you can't >> > > I don't get it. Fedora extras is run by volunteers that are not paid > by RH, still is is ver successfull. Why do you want somebody to pay? > Why not rely on volunteers? It is all EPEL is about? Fedora extras supports a lifecycle that is less than two years. Typically about 1 year. EPEL is different, requiring many years. If I release nagios 2.7 right now in EPEL (which I have), I'll still be maintaining it in 2010[1]. At which point in time nagios might not even exist anymore, or it could be at version 5.3. The fact is there is NO way you're going to get me to do backports of it if a vulnerability is found. Its just not going to happen, mostly because I'm a terribly crappy programmer. Packagers != programmers. Backporting requires skilled labor which not everyone (including myself) will be able to do for antient packages (which nagios 2.7 will be by 2010). -Mike [1] 2010 when RHEL4 is EOLing From mmcgrath at redhat.com Thu Mar 8 22:21:52 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 16:21:52 -0600 Subject: package stability In-Reply-To: <20070308221233.GG5337@nostromo.devel.redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070307224806.GA22202@nostromo.devel.redhat.com> <45EF4296.1030302@redhat.com> <20070308215926.GC5337@nostromo.devel.redhat.com> <45F08AE7.3050700@redhat.com> <20070308221233.GG5337@nostromo.devel.redhat.com> Message-ID: <45F08C80.1030100@redhat.com> Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > >>> Sure. But I'm not sure I want an ISV saying "To run our app, please >>> install XYZ from EPEL." >>> >> Why not? I think it'd be a great vehicle to get these companies involved. >> > > If XYZ is something *not* maintained by that ISV, and Joe Packager goes > AWOL? > > Bill > Hopefully the ISV will have signed up to be a co-maintainer of that package. It won't work every time but corporate sponsorship of these packages could be a very good thing. I think its worth a shot anyway. -Mike From notting at redhat.com Thu Mar 8 22:21:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 17:21:53 -0500 Subject: package stability In-Reply-To: <45F08C30.6090109@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> Message-ID: <20070308222153.GI5337@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > Fedora extras supports a lifecycle that is less than two years. > Typically about 1 year. EPEL is different, requiring many years. If I > release nagios 2.7 right now in EPEL (which I have), I'll still be > maintaining it in 2010[1]. At which point in time nagios might not even > exist anymore, or it could be at version 5.3. The fact is there is NO > way you're going to get me to do backports of it if a vulnerability is > found. Its just not going to happen, mostly because I'm a terribly > crappy programmer. Packagers != programmers. Backporting requires > skilled labor which not everyone (including myself) will be able to do > for antient packages (which nagios 2.7 will be by 2010). An interesting side point is what some ISVs actually do. When RHEL 3 was released, Adboe made a version of Acrobat Reader that ran on RHEL 3, and supported it with various updates for security. However, as time has passed, they have officially EOLed the version that ran on RHEL 3, as their only current version (with security fixes, etc.) requires an entirely new GTK/Pango/etc stack. I suspect there will be plenty of stuff in EPEL that will eventually be frozen to the point where it may only get a backported security fix or two, simply because newer things just *will not build or run* on that version of RHEL/CentOS. Bill From pertusus at free.fr Thu Mar 8 22:21:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 23:21:16 +0100 Subject: EPEL vs Fedora main In-Reply-To: <45F08A85.1000204@redhat.com> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> <20070308215632.GE2958@free.fr> <45F08A85.1000204@redhat.com> Message-ID: <20070308222116.GH2958@free.fr> On Thu, Mar 08, 2007 at 04:13:25PM -0600, Mike McGrath wrote: > > > > > Actually I'd argue that the average EPEL contributor is far more > dedicated / knowledgeable then the average Fedora Extras contributor. That's just nonsense. The average Fedora Extras contributor doesn't count. In Fedora Extras there is a very limited number of very dedicated / knowledgeable contribuors who weight far more than the mass of fedora extras contributors who do almost nothing. The EPEL contributors are a subset of the active Fedora contributors. > This is nothing against Extras, its just that EPEL has attracted a > special kind of extras contributor. True, but there are very experienced, dedicated and knowledgeable Fedora Extras contributors that haven't allready raised their voice in EPEL. > >The first mail on the list date from Tue, 27 Feb 2007! 11 days ago! > >It would be wise to rely on Fedora support for some time. > > > Actually EPEL has existed for close to 7 months now. Some conversations > about it took place even before that. It was not really opened before a few weeks. There wasn't even a place to discuss about guidelines. Fortunaltly there was this core of people who didn't wait for the commitement of the community to begin things, but it is only the beginning of the building of the EPEL community. > We're not new, additionally the > core SIG is extremely experienced in the Fedora workings. > http://fedoraproject.org/wiki/EPEL/SIG I won't argue against that. I know who is who in fedora too. And major contributors aren't there already. > The relationship between red hat and fedora is not completely clear. > Heck, even the merge of core and extras isn't 100% clear. From what I > gather fedora-usermgmt won't work in RHEL4 (from the authors words). > So, IMHO, its done. There's nothing to discuss. If upstream changes it > so its compatible then we can examine it at that time. But right now, > we have no choice but to remove it. It is available in RHEL5. We have choice. -- Pat From mmcgrath at redhat.com Thu Mar 8 22:33:40 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 16:33:40 -0600 Subject: EPEL vs Fedora main In-Reply-To: <20070308222116.GH2958@free.fr> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> <20070308215632.GE2958@free.fr> <45F08A85.1000204@redhat.com> <20070308222116.GH2958@free.fr> Message-ID: <45F08F44.3050102@redhat.com> Patrice Dumas wrote: > It was not really opened before a few weeks. There wasn't even a place > to discuss about guidelines. Fortunaltly there was this core of people > who didn't wait for the commitement of the community to begin things, > but it is only the beginning of the building of the EPEL community. > > You've got to trust me on this, we've been around for more then a few weeks and in public. https://extras.108.redhat.com/ I just don't want you to think we're throwing stuff together here. A great deal of thought, planning and work has been done to even get the first package signed and rolled out to the public mirror. -Mike From pertusus at free.fr Thu Mar 8 22:36:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 23:36:00 +0100 Subject: package stability In-Reply-To: <45F08C30.6090109@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> Message-ID: <20070308223559.GI2958@free.fr> On Thu, Mar 08, 2007 at 04:20:32PM -0600, Mike McGrath wrote: > Fedora extras supports a lifecycle that is less than two years. > Typically about 1 year. EPEL is different, requiring many years. If I > release nagios 2.7 right now in EPEL (which I have), I'll still be > maintaining it in 2010[1]. At which point in time nagios might not even > exist anymore, or it could be at version 5.3. The fact is there is NO > way you're going to get me to do backports of it if a vulnerability is > found. Its just not going to happen, mostly because I'm a terribly > crappy programmer. Packagers != programmers. Backporting requires > skilled labor which not everyone (including myself) will be able to do > for antient packages (which nagios 2.7 will be by 2010). Then maybe nagios isn't right for EPEL main, but better suited for EPEL 'plus'? Anyway it is not necessarilly you who will do the backport. Maybe you know that there are debian people who fix the security bugs, maybe there are people interested in the package, but not in fedora/RHEL who are willing to keep old versions. (by the way nagios is an app, isn't it?). -- Pat From pertusus at free.fr Thu Mar 8 22:43:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Mar 2007 23:43:34 +0100 Subject: EPEL vs Fedora main In-Reply-To: <45F08F44.3050102@redhat.com> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> <20070308215632.GE2958@free.fr> <45F08A85.1000204@redhat.com> <20070308222116.GH2958@free.fr> <45F08F44.3050102@redhat.com> Message-ID: <20070308224334.GJ2958@free.fr> On Thu, Mar 08, 2007 at 04:33:40PM -0600, Mike McGrath wrote: > You've got to trust me on this, we've been around for more then a few > weeks and in public. > > https://extras.108.redhat.com/ > > I just don't want you to think we're throwing stuff together here. A > great deal of thought, planning and work has been done to even get the > first package signed and rolled out to the public mirror. Maybe I wasn't clear enough. I never said that there was some secret or the like, not that EPEL hadn't already came a long way. I have followed all from the beginning reading everything related in FESCo logs, and things like that. But before the announcement and the opening of this list the community wasn't really involved and it seemed to somebody external but interested like me that things weren't really ready but still in the testing phase. There had been only one important thread on that subject in the fedora lists before (or I missed it). It is not a criticism at all, I think things are going well, but, once again, regarding Fedora (extra) community participation as a whole, only beginning. -- Pat From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 22:57:40 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 23:57:40 +0100 Subject: EPEL vs Fedora main In-Reply-To: <45F08A85.1000204@redhat.com> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> <20070308215632.GE2958@free.fr> <45F08A85.1000204@redhat.com> Message-ID: <20070308235740.ad734429.mschwendt.tmp0701.nospam@arcor.de> On Thu, 08 Mar 2007 16:13:25 -0600, Mike McGrath wrote: > From what I > gather fedora-usermgmt won't work in RHEL4 (from the authors words). The optional RPM macros (to be used by packagers in spec files) in the more recent packages won't work. The package itself has branches for as old as RHL-8. From mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 23:46:48 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 00:46:48 +0100 Subject: EPEL vs Fedora main In-Reply-To: <20070308215632.GE2958@free.fr> References: <20070308185810.GC10906@neu.nirvana> <20070308203152.GA2958@free.fr> <20070308211406.GF10906@neu.nirvana> <20070308213214.GD2958@free.fr> <20070308214410.GH10906@neu.nirvana> <20070308215632.GE2958@free.fr> Message-ID: <20070309004648.69f0d587.mschwendt.tmp0701.nospam@arcor.de> On Thu, 8 Mar 2007 22:56:32 +0100, Patrice Dumas wrote: > Currently the guidelines are not finished, the relationship between > Fedora, EPEL and RHEL are not completly clear, let's not hurry on a > touchy subject like fedora-usermgt. There are many more important > things to discuss about that may be less controversial. Still, the discussion whether to use [or even want] fedora-usermgmt in EPEL can take place independently from discussing whether fedora-usermgmt is useless, broken, not considered the right solution, for a niche market only, and so on. ;o) From smooge at gmail.com Thu Mar 8 23:56:50 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 8 Mar 2007 16:56:50 -0700 Subject: package stability In-Reply-To: <20070308220347.GF2958@free.fr> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <80d7e4090703080840ua76c325jc271d9f0ece80609@mail.gmail.com> <20070308220347.GF2958@free.fr> Message-ID: <80d7e4090703081556y7412cc3dj84d9b2bc7c0792ea@mail.gmail.com> On 3/8/07, Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 09:40:41AM -0700, Stephen John Smoogen wrote: > > > > In my opinion this is a lesson that should be learned from Fedora > > Legacy. It takes a LOT of work to backport stuff.. and having un-paid > > volunteers do it is not something that will happen. > > Why? If this also benefit to them, sure they'll do the backport. > One prominent reason, in my opinion why Fedora Legacy died is that > RHEL/Centos were better substitutes. There is no substitute for EPEL, > we can expect more volunteers. Debian is run by volunteers and they > more or less achieve that, I can't see why we couldn't. > I really hate to say this, but you may have answered your un-stated question with your first sentence. There are only going to be so many volunteers in the world, and the ones looking for stable have found themselves Debian a better substitute. And even then Debian is not a 7 year stable environment. They are a 2-3 year stable environment... and getting security fixes for non-core packages have been a real pain last I heard from the Debian security people. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Thu Mar 8 23:57:27 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 8 Mar 2007 16:57:27 -0700 Subject: package stability In-Reply-To: <20070308223559.GI2958@free.fr> References: <20070303092601.GA2881@free.fr> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> <20070308223559.GI2958@free.fr> Message-ID: <80d7e4090703081557o5107264bm9b4a9cb3b3e0ec61@mail.gmail.com> On 3/8/07, Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 04:20:32PM -0600, Mike McGrath wrote: > > Fedora extras supports a lifecycle that is less than two years. > > Typically about 1 year. EPEL is different, requiring many years. If I > > release nagios 2.7 right now in EPEL (which I have), I'll still be > > maintaining it in 2010[1]. At which point in time nagios might not even > > exist anymore, or it could be at version 5.3. The fact is there is NO > > way you're going to get me to do backports of it if a vulnerability is > > found. Its just not going to happen, mostly because I'm a terribly > > crappy programmer. Packagers != programmers. Backporting requires > > skilled labor which not everyone (including myself) will be able to do > > for antient packages (which nagios 2.7 will be by 2010). > > Then maybe nagios isn't right for EPEL main, but better suited for > EPEL 'plus'? Anyway it is not necessarilly you who will do the backport. > Maybe you know that there are debian people who fix the security bugs, > maybe there are people interested in the package, but not in fedora/RHEL > who are willing to keep old versions. (by the way nagios is an app, > isn't it?). > What package are you going to say that you will support for the next 7 years for multiple releases of RHEL [say 2.1,3.8,4.x,5.x with 7 years for 5.x?] -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Fri Mar 9 00:04:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 01:04:35 +0100 Subject: package stability In-Reply-To: <80d7e4090703081557o5107264bm9b4a9cb3b3e0ec61@mail.gmail.com> References: <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> <20070308223559.GI2958@free.fr> <80d7e4090703081557o5107264bm9b4a9cb3b3e0ec61@mail.gmail.com> Message-ID: <20070309000435.GK2958@free.fr> On Thu, Mar 08, 2007 at 04:57:27PM -0700, Stephen John Smoogen wrote: > > What package are you going to say that you will support for the next 7 > years for multiple releases of RHEL [say 2.1,3.8,4.x,5.x with 7 years > for 5.x?] I am not going to say that I will support them for 7 years but that they may be realistically supported by the community. In my packages not counting apps for which there is no problem using the latest version, there is the cernlib, libsx, xbae, libnet, libchmxx -> I don't think these will ever change in an ABI incompatible way. libdockapp -> ensuring ABI compatibility shouldn't be hard. lesstif -> the ABI is constrained by openmotif. The one I know I won't be able to maintain is libdap. For cppunit I'll poke upstream. You may object that I maintain only old and dead stuff and that it cannot be easily generalized to other extra packages, well that's true. -- Pat From mattdm at mattdm.org Fri Mar 9 00:11:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 19:11:32 -0500 Subject: package stability In-Reply-To: <20070308220347.GF2958@free.fr> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <80d7e4090703080840ua76c325jc271d9f0ece80609@mail.gmail.com> <20070308220347.GF2958@free.fr> Message-ID: <20070309001132.GA12643@jadzia.bu.edu> On Thu, Mar 08, 2007 at 11:03:47PM +0100, Patrice Dumas wrote: > One prominent reason, in my opinion why Fedora Legacy died is that > RHEL/Centos were better substitutes. There is no substitute for EPEL, Traffic on the main Fedora list has convinced me that the actual reason is that a huge number of users don't care at all about updates until there's a general panic about something like timezone changes. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pertusus at free.fr Fri Mar 9 00:11:20 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 01:11:20 +0100 Subject: package stability In-Reply-To: <80d7e4090703081556y7412cc3dj84d9b2bc7c0792ea@mail.gmail.com> References: <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <80d7e4090703080840ua76c325jc271d9f0ece80609@mail.gmail.com> <20070308220347.GF2958@free.fr> <80d7e4090703081556y7412cc3dj84d9b2bc7c0792ea@mail.gmail.com> Message-ID: <20070309001120.GL2958@free.fr> On Thu, Mar 08, 2007 at 04:56:50PM -0700, Stephen John Smoogen wrote: > I really hate to say this, but you may have answered your un-stated > question with your first sentence. There are only going to be so many > volunteers in the world, and the ones looking for stable have found > themselves Debian a better substitute. And even then Debian is not a 7 > year stable environment. They are a 2-3 year stable environment... and > getting security fixes for non-core packages have been a real pain > last I heard from the Debian security people. Debian stable is not a substitute like centos is a substitute for fedora legacy for possible contributors. Somebody maintaining an EPEL package may collaborate with debian people and get their patches. That's what I do for the cernlib, for example (and I take their patches for libnet). From what I can see on the debian page, woody was maintained for 4 years. There are still 3 years missing, though... -- Pat From cmc at math.hmc.edu Fri Mar 9 01:56:22 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Thu, 08 Mar 2007 17:56:22 -0800 Subject: Release and update procedure for EPEL In-Reply-To: <20070301164414.2f73bcc3@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> <20070301125300.GA10127@neu.nirvana> <1172760542.3803.10.camel@localhost.localdomain> <20070301164414.2f73bcc3@python3.es.egwn.lan> Message-ID: <11840.1173405382@vosill.math.hmc.edu> "MS" == Matthias Saou "TC" == Tom 'spot' Callaway TC> FWIW, the CentOS people I spoke to at FOSDEM were very TC> much interested in the "fixed set, with bugfixes and TC> security updates only" model. MS> ...but also in providing a lot of recent stuff. They MS> already have php 5 and mysql 5 in a separate location for MS> people to use on CentOS 4. I'd say there's a case to be made for different sorts of packages getting updated at different rates. I suspect that where you stand on the issue has a lot to do with the sort of environment that you're in and what set of ``extra'' packages you want to use. We run CentOS on servers and workstations (used for teaching and doing research). So there are a bunch of things that I package (or grab from RPMForge) that I would like to see up to date for use on the workstations. Most of the stuff on the servers can stay stable (and older), but, on the other hand, there are things that would be nice to keep up to date on servers and workstations (e.g., Subversion). Where that all gets dicey is when you need to have newer versions of various packages that are part of the base distribution (as with, for example, Subversion). Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 9 05:45:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 06:45:01 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 Message-ID: <45F0F45D.40709@leemhuis.info> Hi everyone, find below my take for a "Package maintenance and update policy for EPEL". You an find it in the wiki at: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates If you spot typos (there are probably still some...) please fix them in the wiki directly -- that's why the document is there ;-) Did I miss anything? Do people like the general direction? CU thl = Package maintenance and update policy = EPEL wants to provide a common "look and feel" to the users of our repository. Thus the EPEL SIG wrote this policy that describes the regulations for package maintenance and updates in EPEL, that are a bit more stronger regulated then they are in Fedora now. [[TableOfContents]] == Digest == The goal is to have packages in EPEL that enhances the Enterprise Linux distributions the packages were build against without disturbing or replacing packages from that distribution. The Packages in the Repository should if possible get maintained in similar ways like the packages get maintained in the Enterprise Linux Distribution they get build against. In other words: have a mostly stable set of packages that normally does not change at all and only changes if there are good reasons for it -- so no "hey, there is a new version, it builds, let's ship it" mentality. == Policy == EPEL packages should only enhance and never disturb the Enterprise Linux distributions the packages were build for. Thus packages from EPEL should never replace packages from the base distribution they get build against; kernel-modules further are not allowed, as they can disturb the base kernel easily. The Packages in the Repository should if possible get maintained in similar ways like the packages get maintained in the Enterprise Linux Distribution they get build against. In other words: have a mostly stable set of packages that normally does not change at all and only changes if there are good reasons for changes. The changes that cant be avoided get routed into different release trees. Only updates that fix important bugs (say: data-corruption, security problems, really annoying bugs) go to a testing branch for a short time period and then build a second time for the stable branch; those people that sign and push the EPEL packages to the public repo will skim over the list of updated packages for the stable repo to make sure that sure the goal "only important updates for the stable branch" is fulfilled. Other updates get queued up in a testing repository over time. That repository becomes the new stable branch in parallel with the quarterly update that get released by the Linux Distributor that creates the Enterprise Linux the packages gets build against. There will be a short freeze time period before the quarterly update happens to make sure the repo and its packages are in a good shape. But even this updates should be limited to fixes only as far as possible and should be tested in Fedora beforehand if possible. Updated Packages that change the ABI or require config file adjustments must be avoided if somehow possible. Compat- Packages that provide the old ABI need to be provided in the repo if there is no way around a package update that changes the ABI. == Guidelines and Backgrounds for this policy == === Some examples of what package updates that are fine or not === Examples hopefully help to outline how to actually apply above policy in practise. ==== Minor version updates ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.0.2 * build for the stable branch only if it fixes serious bugs * build for the testing branch (which will be 5.1 later) is acceptable if the upstream release is mostly a bugfix release without new features and the package got run-time testing ==== A little bit bigger minor version updates ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and the existing config files continue to work * build for the stable branch only if it fixes a really serious bug * build for the testing branch (which will be 5.1 later) is acceptable if it fixes serious bugs ==== A yet again little bit bigger minor version updates ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but the config files need manual adjustments * build for the stable branch is normally not acceptable; a backport should be strongly considered if there are any serious bugs that must be fixed * build for the testing branch (which will be 5.1 later) is also disliked; but it is acceptable if there is no other easy way out to solve serious bugs; but the update and the config file adjustments need to be announced to the users properly -- say in form of release notes that get published together with the quarterly announcement. ==== A major version update ==== Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 2.0.0; the ABI changes or the config files need manual adjustments * this update should be avoided if possible at all. If there really is no other way out to fix a serious bug then it rare cases it might be acceptable to build the new version for the testing branch and mention the update and the needed adjustments in the release notes for the next update. An additional compat- packages with the old libs is necessary if the ABI changed. ==== Add more examples as they show up ==== If to many show up put them into a separate document. === Why not a rolling release with up2date packages like Extras? === Why should we? That would be what Fedora (Extras) did and worked and works well for it -- but that's mainly because Fedora (Core) has lots of updates and a nearly rolling-release scheme/quick release cycle, too. But the Enterprise Linux we build against is much more careful with updates and has longer life-cycle; thus we should do the same for EPEL, as most users will properly prefer it that way, as they chose a stable distro for some reasons -- if they want bleeding edge they might have chosen Fedora. Sure, there are lots of areas where having a mix of a stable base and a set of quite new packages on top of it is wanted. *Maybe* the EPEL project will provide a solution (in parallel to the carefully updated repository!) for those cases in the long term, but not for the start. BTW, there are already repositories out there that provide something in this direction, so users might be served by them already. Further: A rolling release scheme like Fedora (Extras) did/does is not possible for many EPEL packages for another reason, too. New Packages often require new versions of certain core libraries, too. But we we can't provide them in EPEL, as they would replace/disturb stuff from the base distribution. Example: This document was written round about when RHEL5 got released; many packages that get build for RHEL5 can't be build for RHEL4 at this point of time already, as the RHEL4-gtk2-Package is much two years old and way to old for many current applications, as they depend on a newer gtk2. So if even if we would try to have a rolling scheme with with quite new package we'd fail, as we can't build a bunch of package due to this dependencies on libs; in the end we would have a repo with some quite new packages while others are still quite old. That mix wouldn't make either of the "latest versions" or "careful updates only" sides happy; so we try to target the "careful updates only" sides. === How will the repo actually look like === Similar to what [ http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/ layout] CentOS uses. Rough example: {{{ * epel/ # topdir * 4/ # topdir for EPEL4 * 4 -> 4.5 # symbolic link to latest version * 4.1/ # this tree of course will never exists, as this is history, and is here just to show the example .... # 4.2, 4.3, 4.4; those won't ever exists, too * 4.5/ # 4.5, latest version, build target: fedora-epel-4-stable * 4.6 # not yet * .... # time will come * testing/ # testing repo, that together with the old packages that didn't get update becomes 4.6 when RHEL 4.6 # releases; build target: fedora-epel-5; gets frozen for a week or two before the quarterly update is # issued; new packages land here for a while, too * 5/ # topdir for EPEL4 * 5 -> 5.0 # symbolic link to latest version * 5.0/ # 5.0, latest version, build target: fedora-epel-5-stable * 5.1 # not yet * .... # time will come * testing/ # testing repo, that together with the old packages that didn't get update becomes 4.6 when RHEL 4.6 # releases; build target: fedora-epel-5; gets frozen for a week or two before the quarterly update is # issued; new packages land here for a while, too }}} This layout may looks complicated, but has one major benefit: Users can stick to a EPEL repo for a not up2date EL release while a newer EL quarterly update is already out (some users do that on purpose, others have no chance as for example the CentOS update gets normally released up to four weeks after RHEL released a quarterly update). The above layout can makes it possible to prevent that users run into dependency issues that might arise otherwise if packages in the new EPEL release depend on new packages in the new EL release. The EPEL quarterly update further isn't forced on users before they switch to the quarterly update. Each repo always has all the packages in it; hardlinks will be used to keep the space requirements on the server-side limited, as most packages won't change. From Axel.Thimm at ATrpms.net Fri Mar 9 08:52:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 09:52:46 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> References: <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070309085246.GE19382@neu.nirvana> On Thu, Mar 08, 2007 at 11:18:39PM +0100, Michael Schwendt wrote: > On Thu, 8 Mar 2007 22:34:54 +0100, Axel Thimm wrote: > > > > So, in your scenario any package that does "useradd foo" goes "boom"? > > > > No, not my scenario, but any scenario. There are two kind of packages: > > > > a) packages not requiring fixed uid/gids: useradd -r is more than > > enough > > For single hosts. Maybe. The next time you reinstall from scratch, > you cannot predict whether you end up with the same uids/gids, though. > > Just to be sure, don't get me wrong. It's not a feature with a huge target > group. > > > b) packages requiring fixed uid/gids: fedora-usermgmt's default of > > going useradd -r breaks the promise of fixed or semi-fixed uids/gids > > For _fixed_ (!) uids/gids, you don't use fedora-usermgmt, but useradd -u. > > useradd -r does not yield fixed, static or predictable results. And > fedora-usermgmt (when enabled) gives predictable and static uids/gids, > albeit not fixed ones. You don't need it when you need fixed uids/gids. > > Fixed => fixed world-wide => because a uid/gid may be compiled into the > software (!) and must be the same for every installation of Fedora. > This is not something fedora-usermgmt is used for. Exactly, so what *is* it used for? Not for fixed uids, not for non-fixed uids. But for "predictable" ones? Predictable by whom? The next package cannot predict what the previous one used, and indeed fedora-usrmgmnt is not even used that way. So predictable means for a human being that is able to add 300 plus 42. What's the benefit of these predictable uids? None, really. The promise of fedora-usermgmt was to deal with packages requiring *fixed* uids but these ran out so to the rescue came fedora-usermgmt. But we now agree that it does not really solve a fixed uid's problem, that's good. > > > > What? It does run at package installation time, right? That's far > > > > from being repository level. To put the above example in very > > > > simple words: Install package A with "usermgmt"-uid 42, then > > > > configure usermgmt, then install package B which will have a > > > > completely different view of "usermgmt"-uid 42. > > > > > > It provides means to avoid that *if* you want that. > > > > OK, I bite. Which means does it provide? > > less fedora-usermgmt.spec ; echo "And I've never said it would be pretty..." Nice, in case you ever have any question my answer will be find . -name \*.c -or \*.h | xargs cat So, please either explain what magic mechanism exists or not. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Mar 9 08:59:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 09:59:41 +0100 Subject: package stability In-Reply-To: <45F08C80.1030100@redhat.com> References: <20070303092601.GA2881@free.fr> <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070307224806.GA22202@nostromo.devel.redhat.com> <45EF4296.1030302@redhat.com> <20070308215926.GC5337@nostromo.devel.redhat.com> <45F08AE7.3050700@redhat.com> <20070308221233.GG5337@nostromo.devel.redhat.com> <45F08C80.1030100@redhat.com> Message-ID: <20070309085941.GF19382@neu.nirvana> On Thu, Mar 08, 2007 at 04:21:52PM -0600, Mike McGrath wrote: > Bill Nottingham wrote: > >Mike McGrath (mmcgrath at redhat.com) said: > > > >>>Sure. But I'm not sure I want an ISV saying "To run our app, > >>>please install XYZ from EPEL." > >>> > >>Why not? I think it'd be a great vehicle to get these companies > >>involved. > > > >If XYZ is something *not* maintained by that ISV, and Joe Packager > >goes AWOL? > > > Hopefully the ISV will have signed up to be a co-maintainer of that > package. It won't work every time but corporate sponsorship of > these packages could be a very good thing. I think its worth a shot > anyway. How about making that part of EPEL guidelines? If an ISV wants to point to EPEL for resources for his app, then he *needs* to sign up as a comaintainer with at least the responsibilities on testing his app against the lastest EPEL every now and then. There are similar ISV guidelines for RHEL updates, we could pick them up, especially the timeline parts of them, and adjust them for EPEL. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Mar 9 09:06:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 10:06:44 +0100 Subject: package stability In-Reply-To: <20070308222153.GI5337@nostromo.devel.redhat.com> References: <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> <20070308222153.GI5337@nostromo.devel.redhat.com> Message-ID: <20070309090644.GG19382@neu.nirvana> On Thu, Mar 08, 2007 at 05:21:53PM -0500, Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > > Fedora extras supports a lifecycle that is less than two years. > > Typically about 1 year. EPEL is different, requiring many years. If I > > release nagios 2.7 right now in EPEL (which I have), I'll still be > > maintaining it in 2010[1]. At which point in time nagios might not even > > exist anymore, or it could be at version 5.3. The fact is there is NO > > way you're going to get me to do backports of it if a vulnerability is > > found. Its just not going to happen, mostly because I'm a terribly > > crappy programmer. Packagers != programmers. Backporting requires > > skilled labor which not everyone (including myself) will be able to do > > for antient packages (which nagios 2.7 will be by 2010). > > An interesting side point is what some ISVs actually do. When RHEL 3 > was released, Adboe made a version of Acrobat Reader that ran on RHEL 3, > and supported it with various updates for security. > > However, as time has passed, they have officially EOLed the version that > ran on RHEL 3, as their only current version (with security fixes, etc.) > requires an entirely new GTK/Pango/etc stack. > > I suspect there will be plenty of stuff in EPEL that will eventually > be frozen to the point where it may only get a backported security > fix or two, simply because newer things just *will not build or run* > on that version of RHEL/CentOS. The question is how do we deal with it? Will we have enough resources to throw to backporting? Probably not, especially when there was a company once pushing a set of packages and suddenly drop them and moves on to the next RHEL version. What will we do in 12 months with say 40 packages in RHEL4 and 20 in RHEL5 with security issues requiring backporting labour that noone is willing to donate? Removing them from the repo will still leave many RHEL boxes vulnerable. Maybe the meta-package obsoleting/conflicting with some packages which Thorsten suggested in Fedora-land in a different context makes much more sense here? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Fri Mar 9 12:31:13 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 13:31:13 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309085246.GE19382@neu.nirvana> References: <20070308154916.GB31094@neu.nirvana> <20070308173629.a5c02c94.mschwendt.tmp0701.nospam@arcor.de> <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> Message-ID: <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> On Fri, 9 Mar 2007 09:52:46 +0100, Axel Thimm wrote: > > > b) packages requiring fixed uid/gids: fedora-usermgmt's default of > > > going useradd -r breaks the promise of fixed or semi-fixed uids/gids > > > > For _fixed_ (!) uids/gids, you don't use fedora-usermgmt, but useradd -u. > > > > useradd -r does not yield fixed, static or predictable results. And > > fedora-usermgmt (when enabled) gives predictable and static uids/gids, > > albeit not fixed ones. You don't need it when you need fixed uids/gids. > > > > Fixed => fixed world-wide => because a uid/gid may be compiled into the > > software (!) and must be the same for every installation of Fedora. > > This is not something fedora-usermgmt is used for. > > Exactly, so what *is* it used for? Not for fixed uids, not for > non-fixed uids. But for "predictable" ones? Predictable by whom? The > next package cannot predict what the previous one used, and indeed > fedora-usrmgmnt is not even used that way. > > So predictable means for a human being that is able to add 300 plus > 42. What's the benefit of these predictable uids? None, really. > > The promise of fedora-usermgmt was to deal with packages requiring > *fixed* uids but these ran out so to the rescue came > fedora-usermgmt. But we now agree that it does not really solve a > fixed uid's problem, that's good. Predictable means you can keep the uid/gid constant, but still have an influence on where that is within your range of values. Everytime you install a package again on a machine under control of a configured fedora-usermgmt, the package allocates the same uid/gid. The only alternative is useradd -u/groupadd -g with a larger range of uids/gids from which to occupy values per program per distribution. From fedora at leemhuis.info Fri Mar 9 14:20:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 15:20:02 +0100 Subject: package stability In-Reply-To: <20070309090644.GG19382@neu.nirvana> References: <20070303105114.GC27400@neu.nirvana> <20070307220247.GC25018@nostromo.devel.redhat.com> <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> <20070308222153.GI5337@nostromo.devel.redhat.com> <20070309090644.GG19382@neu.nirvana> Message-ID: <45F16D12.2070809@leemhuis.info> On 09.03.2007 10:06, Axel Thimm wrote: > [...] Removing them from the repo will still leave many > RHEL boxes vulnerable. Maybe the meta-package obsoleting/conflicting > with some packages which Thorsten suggested in Fedora-land in a > different context makes much more sense here? My idea was meant for dist updates (FC6->F7) only and crazy enough for that scenario already, as uninstalling packages behind the users back without asking them is not nice (tm). The idea for that reasons was rejected yesterday by FESCo. That fine for me as long as a proper solution for the problem at hand comes up (hopefully soon, but I doubt it). Back to EPEL: Removing packages behind the users back without asking them in a stable dist is just insane afaics. It might be a last resort in some very very rare cases, but that should be avoided at all costs. So no, that doesn't work. CU thl From Axel.Thimm at ATrpms.net Fri Mar 9 15:19:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 16:19:47 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> References: <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070309151947.GA15248@neu.nirvana> On Fri, Mar 09, 2007 at 01:31:13PM +0100, Michael Schwendt wrote: > Predictable means you can keep the uid/gid constant, in a floating window. "Constant" is the definition of a fixed uid. If there is need for a fixed uid, ask for one (yes, there _seems_ to be currently no space, but that is another issue), if not use useradd -r. > but still have an influence on where that is within your range of > values. Everytime you install a package again on a machine under > control of a configured fedora-usermgmt, the package allocates the > same uid/gid. sure - oops, the admin forgot to configure fedora-usermgmt on machine number 23. Now all uid/gid are messed up. That's an extremly fragile design, and if it even involves using these uid/gid in a security context a very fragile security setup. From any POV I look at it, this design is flawed ... > The only alternative is useradd -u/groupadd -g with a larger range of > uids/gids from which to occupy values per program per distribution. As Enrico pointed out: You need to adjust or violate the LSB. But we're fixing an issue which is none. I'm rather convinced that all packages using fedora-usermgmt don't need fixed uids. Or at least present a counter-example, where a package needs it. And then please explain how it can need a fixed uid/gid and still have survived that long in the fedora-usermgmt-defaults-to-useradd-r setup. We're really just vapour-talking. fedora-usermgmt "fixes" something that wasn't broken to begin with, and the fix is more broken than anything we try to suggest fedora-usermgmt would be able to fix. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Mar 9 15:26:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 16:26:13 +0100 Subject: package stability In-Reply-To: <45F16D12.2070809@leemhuis.info> References: <45EF3A86.5080403@redhat.com> <20070308094403.GA2891@free.fr> <45F004CF.6080509@math.unl.edu> <20070308132740.GC2880@free.fr> <45F021B8.3020708@redhat.com> <20070308220821.GG2958@free.fr> <45F08C30.6090109@redhat.com> <20070308222153.GI5337@nostromo.devel.redhat.com> <20070309090644.GG19382@neu.nirvana> <45F16D12.2070809@leemhuis.info> Message-ID: <20070309152613.GB15248@neu.nirvana> On Fri, Mar 09, 2007 at 03:20:02PM +0100, Thorsten Leemhuis wrote: > On 09.03.2007 10:06, Axel Thimm wrote: > > [...] Removing them from the repo will still leave many > > RHEL boxes vulnerable. Maybe the meta-package obsoleting/conflicting > > with some packages which Thorsten suggested in Fedora-land in a > > different context makes much more sense here? > > My idea was meant for dist updates (FC6->F7) only and crazy enough for > that scenario already, as uninstalling packages behind the users back > without asking them is not nice (tm). The idea for that reasons was > rejected yesterday by FESCo. That fine for me as long as a proper > solution for the problem at hand comes up (hopefully soon, but I doubt it). > > Back to EPEL: Removing packages behind the users back without asking > them in a stable dist is just insane afaics. It might be a last resort > in some very very rare cases, but that should be avoided at all costs. > So no, that doesn't work. I agree with fesco on rejecting the original setup: I'm not thinking of the garbarge-collector-standard-installed-package, but of an optional "epel-security-orphaned" package. The mechanism is similar (although I would not obsolete/provide, but simply conflict), but the semantics are different. Users can chose to run their systems with their pants down or install this package and be assured that at the very least if a security issue is not fixed it is removed. E.g. # foo 1.2 has a remote explit and we cannot backport the fix, nor # update this package Conflicts: foo <= 1.2 The "epel-security-orphaned" would be just another optional installed package. when you pull it in in cleanses any vulnerability by nuking the unfixable packages. Users' choice of running a secury RHEL/EPEL setup. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Fri Mar 9 16:26:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 17:26:02 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309151947.GA15248@neu.nirvana> References: <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> Message-ID: <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> On Fri, 9 Mar 2007 16:19:47 +0100, Axel Thimm wrote: > On Fri, Mar 09, 2007 at 01:31:13PM +0100, Michael Schwendt wrote: > > Predictable means you can keep the uid/gid constant, > > in a floating window. Eh? What do you mean with "floating"? That you refuse to keep the base value constant? Well, there are lots of other ways how to damage installations. > "Constant" is the definition of a fixed uid. If there is need for a > fixed uid, ask for one (yes, there _seems_ to be currently no space, but > that is another issue), if not use useradd -r. And with useradd -r, how do you get the same uid/gid for a package on all installations, when you want that? > > but still have an influence on where that is within your range of > > values. Everytime you install a package again on a machine under > > control of a configured fedora-usermgmt, the package allocates the > > same uid/gid. > > sure - oops, the admin forgot to configure fedora-usermgmt on machine > number 23. Now all uid/gid are messed up. In the same way you can install the wrong distribution on machine number 23 e.g. because you insert the wrong media. ;) fedora-usermgmt setup can be made available at installation time. > From any POV I look at it, this design is flawed ... Hyperbole. > > The only alternative is useradd -u/groupadd -g with a larger range of > > uids/gids from which to occupy values per program per distribution. > > As Enrico pointed out: You need to adjust or violate the LSB. Has nothing to do with this thread. > But we're fixing an issue which is none. I'm rather convinced that all > packages using fedora-usermgmt don't need fixed uids. As long as you continue with your very own definition of "fixed", it's hopeless anyway. > Or at least > present a counter-example, where a package needs it. You can't think of any environment, where predictable uids/gids make sense? > And then please > explain how it can need a fixed uid/gid and still have survived that > long in the fedora-usermgmt-defaults-to-useradd-r setup. Because default behaviour is transparent and just like "useradd foo". According to your murky theory, we should worry a lot, because none of the packagers and reviewers, who have dealt with fedora-usermgmt, have questioned the default behaviour. > We're really just vapour-talking. fedora-usermgmt "fixes" something > that wasn't broken to begin with, and the fix is more broken than > anything we try to suggest fedora-usermgmt would be able to fix. fedora-usermgmt is not about fixing something, but about adding a feature. Well, that's my point of view. I'm not a hardcore advocate of using it everywhere. But I don't understand why a simple EPEL steering decision is wrapped into a crusade against an optional tool. From Axel.Thimm at ATrpms.net Fri Mar 9 16:37:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 17:37:07 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> References: <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070309163707.GB24607@neu.nirvana> On Fri, Mar 09, 2007 at 05:26:02PM +0100, Michael Schwendt wrote: > On Fri, 9 Mar 2007 16:19:47 +0100, Axel Thimm wrote: > > On Fri, Mar 09, 2007 at 01:31:13PM +0100, Michael Schwendt wrote: > > > Predictable means you can keep the uid/gid constant, > > > > in a floating window. > > Eh? What do you mean with "floating"? That you refuse to keep the base > value constant? Well, there are lots of other ways how to damage > installations. Ehem, the floating window *is* the core feature of this package, but I agree that it's a bug called a feature ;) > > "Constant" is the definition of a fixed uid. If there is need for a > > fixed uid, ask for one (yes, there _seems_ to be currently no space, but > > that is another issue), if not use useradd -r. > > And with useradd -r, how do you get the same uid/gid for a package on all > installations, when you want that? Technically by just adding the uid/gid as an argument to useradd/groupadd. From a distibution POV you need to register a fixed uid/gid first, of course. And the entity that is in charge of handing out the fixed uid/gid will consider your application and accept or reject it. > > > but still have an influence on where that is within your range of > > > values. Everytime you install a package again on a machine under > > > control of a configured fedora-usermgmt, the package allocates the > > > same uid/gid. > > > > sure - oops, the admin forgot to configure fedora-usermgmt on machine > > number 23. Now all uid/gid are messed up. > > In the same way you can install the wrong distribution on machine number > 23 e.g. because you insert the wrong media. ;) fedora-usermgmt setup can > be made available at installation time. No, forgetting an additional imposed configure step is different than inserting your Vista CD. In fact if *all* package were to use this scheme, you would have no chance in configuring this before the first package makes it on disk. Or do you want anaconda to ask "please insert a random uid/gid base, don't worry if you don#t know what this is all about, just pick your lucky number" ;) Yet another issue with this scheme, how cool, one only needs to think it through to find one flaw after the other. > > From any POV I look at it, this design is flawed ... > > Hyperbole. Blind man talking? I wish we had a voting in the EPEL sig on that. Sigh. > > Or at least present a counter-example, where a package needs it. > > You can't think of any environment, where predictable uids/gids make > sense? Gimme the example. No more theories and rhetorics, please. :) > > And then please explain how it can need a fixed uid/gid and still > > have survived that long in the > > fedora-usermgmt-defaults-to-useradd-r setup. > > Because default behaviour is transparent and just like "useradd foo". Which means that the package didn't require anything more to begin with. QED. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Fri Mar 9 16:38:55 2007 From: steve at silug.org (Steven Pritchard) Date: Fri, 9 Mar 2007 10:38:55 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> References: <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070309163855.GA11508@osiris.silug.org> On Fri, Mar 09, 2007 at 05:26:02PM +0100, Michael Schwendt wrote: > And with useradd -r, how do you get the same uid/gid for a package on all > installations, when you want that? You create the user ahead of time. As long as the %pre script looks like this, there won't be a problem: id foo &>/dev/null || \ /usr/sbin/useradd -r -s /sbin/nologin -c FOO -d /usr/share/foo foo > You can't think of any environment, where predictable uids/gids make > sense? I certainly can't think of such an environment where it doesn't make *more* sense to either pre-create the user accounts with fixed uids/gids or just use LDAP/NIS/whatever. 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 fedora at leemhuis.info Fri Mar 9 16:47:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 17:47:34 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> References: <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45F18FA6.80508@leemhuis.info> Michael Schwendt schrieb: > > fedora-usermgmt is not about fixing something, but about adding a > feature. Well, that's my point of view. I'm not a hardcore advocate of > using it everywhere. But I don't understand why a simple EPEL steering > decision is wrapped into a crusade against an optional tool. Mainly for two reasons afaics: - Because the rules in EPEL imho should be as identical to the rules from Fedora as much as possible, as everything that differs between the two will make life harder for users and packagers (for example a package that currently uses fedora-usermgmt in Fedora could not simply be build for EPEL without adjustments) - Because having a tool like fedora-usermgmt that solves a particular problem is IMHO not worth much, if half of the Fedora packages use it, while the other half doesn't So having a solution for Fedora (use it everywhere, don't use it at all, use another solution that fixes the problems fedora-usermgmt tries to solve) would be the best for everyone. Cu thl From mattdm at mattdm.org Fri Mar 9 16:52:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Mar 2007 11:52:03 -0500 Subject: remove fedora-usermgmt? In-Reply-To: <20070309163707.GB24607@neu.nirvana> References: <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <20070309163707.GB24607@neu.nirvana> Message-ID: <20070309165203.GA21940@jadzia.bu.edu> On Fri, Mar 09, 2007 at 05:37:07PM +0100, Axel Thimm wrote: > Technically by just adding the uid/gid as an argument to > useradd/groupadd. > From a distibution POV you need to register a fixed uid/gid first, of > course. And the entity that is in charge of handing out the fixed > uid/gid will consider your application and accept or reject it. And, as Bill Nottingham said a few dozen posts ago, that's what we should do. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwilson at redhat.com Fri Mar 9 16:58:54 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 09 Mar 2007 11:58:54 -0500 Subject: remove fedora-usermgmt? In-Reply-To: <45F18FA6.80508@leemhuis.info> References: <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> Message-ID: <45F1924E.6040302@redhat.com> Thorsten Leemhuis wrote: > Michael Schwendt schrieb: >> fedora-usermgmt is not about fixing something, but about adding a >> feature. Well, that's my point of view. I'm not a hardcore advocate of >> using it everywhere. But I don't understand why a simple EPEL steering >> decision is wrapped into a crusade against an optional tool. > > Mainly for two reasons afaics: > > - Because the rules in EPEL imho should be as identical to the rules > from Fedora as much as possible, as everything that differs between the > two will make life harder for users and packagers (for example a package > that currently uses fedora-usermgmt in Fedora could not simply be build > for EPEL without adjustments) > > - Because having a tool like fedora-usermgmt that solves a particular > problem is IMHO not worth much, if half of the Fedora packages use it, > while the other half doesn't > > So having a solution for Fedora (use it everywhere, don't use it at all, > use another solution that fixes the problems fedora-usermgmt tries to > solve) would be the best for everyone. I vaguely recall seeing a spec someone wrote that had some conditionals added to determine if it should use fedora-usermgmt or simply run useradd. Extra overhead, but it'd let the same spec be viable for both fedora and epel w/o having to either bring fedora-usermgmt to epel or kill fedora-usermgmt altogether (though I'm in favor of the latter. ;) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Fri Mar 9 17:15:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 18:15:58 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F0F45D.40709@leemhuis.info> References: <45F0F45D.40709@leemhuis.info> Message-ID: <20070309171558.GD25722@free.fr> This seems right to me. And I don't find that complicated. I also had another thought. Maybe it could be possible to avoid packages in the testing repo to be published when the release time comes and the maintainer feels that it is not ready for the stable branch. In the document this looks like the push is more or less 'automatic'. -- Pat From mschwendt.tmp0701.nospam at arcor.de Fri Mar 9 17:32:37 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 18:32:37 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309163707.GB24607@neu.nirvana> References: <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <20070309163707.GB24607@neu.nirvana> Message-ID: <20070309183237.7475ee07.mschwendt.tmp0701.nospam@arcor.de> On Fri, 9 Mar 2007 17:37:07 +0100, Axel Thimm wrote: > > > > Predictable means you can keep the uid/gid constant, > > > > > > in a floating window. > > > > Eh? What do you mean with "floating"? That you refuse to keep the base > > value constant? Well, there are lots of other ways how to damage > > installations. > > Ehem, the floating window *is* the core feature of this package, but I > agree that it's a bug called a feature ;) And /etc/login.defs is its uncle. :) > > > "Constant" is the definition of a fixed uid. If there is need for a > > > fixed uid, ask for one (yes, there _seems_ to be currently no space, but > > > that is another issue), if not use useradd -r. > > > > And with useradd -r, how do you get the same uid/gid for a package on all > > installations, when you want that? > > Technically by just adding the uid/gid as an argument to > useradd/groupadd. > > From a distibution POV you need to register a fixed uid/gid first, of > course. And the entity that is in charge of handing out the fixed > uid/gid will consider your application and accept or reject it. https://www.redhat.com/archives/epel-devel-list/2007-March/msg00132.html > > > > but still have an influence on where that is within your range of > > > > values. Everytime you install a package again on a machine under > > > > control of a configured fedora-usermgmt, the package allocates the > > > > same uid/gid. > > > > > > sure - oops, the admin forgot to configure fedora-usermgmt on machine > > > number 23. Now all uid/gid are messed up. > > > > In the same way you can install the wrong distribution on machine number > > 23 e.g. because you insert the wrong media. ;) fedora-usermgmt setup can > > be made available at installation time. > > No, forgetting an additional imposed configure step is different than > inserting your Vista CD. The setup package would be included within the admin's configuration source, e.g. kickstart based network-install. > > > And then please explain how it can need a fixed uid/gid and still > > > have survived that long in the > > > fedora-usermgmt-defaults-to-useradd-r setup. > > > > Because default behaviour is transparent and just like "useradd foo". > > Which means that the package didn't require anything more to begin > with. QED. Did you really think they *require* fedora-useradd instead of useradd just to be installable by Joe User? =:-O The real "qed" comes after understanding that with plain "useradd foo" and without option -u you cannot get the behaviour of a cleanly configured fedora-usermgmt, because all your uids/gids are unpredictable. From fedora at leemhuis.info Fri Mar 9 17:44:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 18:44:12 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <20070309171558.GD25722@free.fr> References: <45F0F45D.40709@leemhuis.info> <20070309171558.GD25722@free.fr> Message-ID: <45F19CEC.7030608@leemhuis.info> Patrice Dumas schrieb: > This seems right to me. And I don't find that complicated. Thanks for your feedback. > I also had another thought. Maybe it could be possible to avoid packages > in the testing repo to be published when the release time comes and the > maintainer feels that it is not ready for the stable branch. In the > document this looks like the push is more or less 'automatic'. Well, it'd say it should be automatic. But removing packages should of course be possible, but it should not happen that often; so I'd say we should be able to handle it just like we do in Extras (e.g. a repo requests page in the wiki for removals). I don't think it's worth mentioning in this page. CU thl From fedora at leemhuis.info Fri Mar 9 17:53:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 18:53:18 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F19CEC.7030608@leemhuis.info> References: <45F0F45D.40709@leemhuis.info> <20070309171558.GD25722@free.fr> <45F19CEC.7030608@leemhuis.info> Message-ID: <45F19F0E.1010800@leemhuis.info> Thorsten Leemhuis schrieb: > Patrice Dumas schrieb: >> This seems right to me. And I don't find that complicated. > > Thanks for your feedback. > >> I also had another thought. Maybe it could be possible to avoid packages >> in the testing repo to be published when the release time comes and the >> maintainer feels that it is not ready for the stable branch. In the >> document this looks like the push is more or less 'automatic'. > > Well, it'd say it should be automatic. But removing packages should of > course be possible, but it should not happen that often; so I'd say we > should be able to handle it just like we do in Extras (e.g. a repo > requests page in the wiki for removals). I don't think it's worth > mentioning in this page. I changed my mind and will add a small note. Cu thl From mschwendt.tmp0701.nospam at arcor.de Fri Mar 9 17:55:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 18:55:15 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F18FA6.80508@leemhuis.info> References: <20070308171000.GA5543@neu.nirvana> <20070308184741.3f8ace89.mschwendt.tmp0701.nospam@arcor.de> <20070308180054.GE5543@neu.nirvana> <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> Message-ID: <20070309185515.e123fd75.mschwendt.tmp0701.nospam@arcor.de> On Fri, 09 Mar 2007 17:47:34 +0100, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > > > fedora-usermgmt is not about fixing something, but about adding a > > feature. Well, that's my point of view. I'm not a hardcore advocate of > > using it everywhere. But I don't understand why a simple EPEL steering > > decision is wrapped into a crusade against an optional tool. > > Mainly for two reasons afaics: > > - Because the rules in EPEL imho should be as identical to the rules > from Fedora as much as possible, as everything that differs between the > two will make life harder for users and packagers (for example a package > that currently uses fedora-usermgmt in Fedora could not simply be build > for EPEL without adjustments) Where are the useradd/fedora-useradd related rules of Fedora written down? Where are the packagers and reviewers in this discussion, who have dealt with fedora-useradd during review and during the life-time of their packages? Unless I've missed something, fedora-usermgmt is purely optional. Why are 34 uids for it in the registry in the Wiki? > - Because having a tool like fedora-usermgmt that solves a particular > problem is IMHO not worth much, if half of the Fedora packages use it, > while the other half doesn't That's not my problem. If EPEL management doesn't consider fedora-usermgmt ready enough or doesn't see any need in it or doesn't want the feature, they are free to disallow using it, aren't they? Occasionally, the people in committee positions need to take responsibility for such decisions. I've said more than once that the full power of fedora-usermgmt isn't pretty. Just for the record, when I maintained the official Fedora wesnoth package for some time, I've used plain useradd because it was appropriate and sufficient. The reason I still reply in this thread is because there are false accusations and the refusal to analyse fedora-usermgmt at a technical level before judging about it. From Axel.Thimm at ATrpms.net Fri Mar 9 19:48:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 20:48:38 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F18FA6.80508@leemhuis.info> References: <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> Message-ID: <20070309194838.GC31061@neu.nirvana> On Fri, Mar 09, 2007 at 05:47:34PM +0100, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > > > fedora-usermgmt is not about fixing something, but about adding a > > feature. Well, that's my point of view. I'm not a hardcore advocate of > > using it everywhere. But I don't understand why a simple EPEL steering > > decision is wrapped into a crusade against an optional tool. > > Mainly for two reasons afaics: > > - Because the rules in EPEL imho should be as identical to the rules > from Fedora as much as possible, as everything that differs between the > two will make life harder for users and packagers (for example a package > that currently uses fedora-usermgmt in Fedora could not simply be build > for EPEL without adjustments) Mostly agreed, but it tears on our nerves. We need to be able to veto some stuff from entering EPEL and throw them back in the Fedora pool to mature/be discussed there. En attendant Godot isn't good for EPEL ... So, how about vetoing instead of branching? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Mar 9 20:47:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Mar 2007 21:47:13 +0100 Subject: Request for voting SIG Message-ID: <20070309204713.GD31061@neu.nirvana> Hi, we need to get a voting body set up asap. Nominate a bunch of folks, maybe the ones in the wiki plus a couple more and give them fesco to ratify (by vote) and to formulate our mandate. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Fri Mar 9 21:21:00 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 9 Mar 2007 14:21:00 -0700 Subject: remove fedora-usermgmt? In-Reply-To: <20070309163707.GB24607@neu.nirvana> References: <20070308180054.GE5543@neu.nirvana> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <20070309163707.GB24607@neu.nirvana> Message-ID: <80d7e4090703091321l3914389fgd28cbe6f118b9924@mail.gmail.com> On 3/9/07, Axel Thimm wrote: > No, forgetting an additional imposed configure step is different than > inserting your Vista CD. > > In fact if *all* package were to use this scheme, you would have no > chance in configuring this before the first package makes it on > disk. Or do you want anaconda to ask "please insert a random uid/gid > base, don't worry if you don#t know what this is all about, just pick > your lucky number" ;) > > Yet another issue with this scheme, how cool, one only needs to think > it through to find one flaw after the other. > Ok the problem I have is that if I were to use the 'other repo' with FC6 and want to install clamav. I do not have any chance to configure fedora-usermgmt, nor do I know what it does until it is installed. I would rather have something that installs all the time a user with uid 123 than one that might or might not because I didn't configure it before hand (because I didnt know I had to configure it). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From P.R.Schaffner at ieee.org Fri Mar 9 23:53:01 2007 From: P.R.Schaffner at ieee.org (Philip Ray Schaffner) Date: Fri, 09 Mar 2007 18:53:01 -0500 Subject: RFP: octave and octave-forge for EL5 In-Reply-To: <20070308181535.GC2954@free.fr> References: <1173371973.3844.20.camel@hazard2.larc.nasa.gov> <20070308181535.GC2954@free.fr> Message-ID: <1173484381.5295.0.camel@ping0.tabb> On Thu, 2007-03-08 at 19:15 +0100, Patrice Dumas wrote: > On Thu, Mar 08, 2007 at 11:39:33AM -0500, Phil Schaffner wrote: > > > > libdap-3.7.2-3.fc7.src.rpm > > libnc-dap-3.6.2-5.fc7.src.rpm > > libnc-dap API/ABI is stable, but libdap is very unstable, and I am not > convinced that it is a right candidate for EPEL. I will discuss that > with upstream, however. OK - put please consider the context. No libdap, no octave-forge. Thanks, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at tummy.com Sat Mar 10 00:55:24 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 9 Mar 2007 17:55:24 -0700 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F0F45D.40709@leemhuis.info> References: <45F0F45D.40709@leemhuis.info> Message-ID: <20070309175524.057a6db3@ghistelwchlohm.scrye.com> On Fri, 09 Mar 2007 06:45:01 +0100 fedora at leemhuis.info (Thorsten Leemhuis) wrote: > Hi everyone, > > find below my take for a "Package maintenance and update policy for > EPEL". You an find it in the wiki at: > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates > > If you spot typos (there are probably still some...) please fix them > in the wiki directly -- that's why the document is there ;-) > > Did I miss anything? Do people like the general direction? Yeah, this looks good to me... Some minor comments: >The changes that cant be avoided get routed into different release > trees. Only updates that fix important bugs (say: data-corruption, > security problems, really annoying bugs) go to a testing branch for a > short time period and then build a second time for the stable branch; > those people that sign and push the EPEL packages to the public repo > will skim over the list of updated packages for the stable repo to > make sure that sure the goal "only important updates for the stable > branch" is fulfilled. Can we possibly require any package that wants to push to the current release to have a bug filed and mention that in the changelog? This would make looking and making sure a package is supposed to fix a data-corruption/security/serious bug much easier on people who push the updates. We might want to also mention (although perhaps it's just common sense) that if people have any questions about how they should handle an upgrade in their package, they should consult this list and/or the SIG members for input. It might be that someone here could find or be able to generate a backported fix when a maintainer is unable to. Anyhow, looks good to me. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Mar 10 09:21:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 10:21:34 +0100 Subject: Request for voting SIG In-Reply-To: <20070309204713.GD31061@neu.nirvana> References: <20070309204713.GD31061@neu.nirvana> Message-ID: <45F2789E.7070505@leemhuis.info> Axel Thimm schrieb: > we need to get a voting body set up asap. Nominate a bunch of folks, > maybe the ones in the wiki plus a couple more and give them fesco to > ratify (by vote) and to formulate our mandate. Well, it was never formally announced/ratified/written down, but afaics it works like in other SIGS. That is: the SIG members takes care of the sub-project (in this case EPEL), thus they are the ones that vote/decide. That is normally done via the preferred meeting channel -- I'd say for this SIG that is normally the meetings on IRC. Yes, as we grow we (might soon) need a more standardized procedure (similar how FESCo works I'd say). But above should work for now afaics. CU thl From fedora at leemhuis.info Sat Mar 10 09:33:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 10:33:43 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <20070309175524.057a6db3@ghistelwchlohm.scrye.com> References: <45F0F45D.40709@leemhuis.info> <20070309175524.057a6db3@ghistelwchlohm.scrye.com> Message-ID: <45F27B77.1080701@leemhuis.info> Kevin Fenzi schrieb: > Some minor comments: > >> The changes that cant be avoided get routed into different release >> trees. Only updates that fix important bugs (say: data-corruption, >> security problems, really annoying bugs) go to a testing branch for a >> short time period and then build a second time for the stable branch; >> those people that sign and push the EPEL packages to the public repo >> will skim over the list of updated packages for the stable repo to >> make sure that sure the goal "only important updates for the stable >> branch" is fulfilled. > Can we possibly require any package that wants to push to the current > release to have a bug filed and mention that in the changelog? > This would make looking and making sure a package is supposed to fix a > data-corruption/security/serious bug much easier on people who push the > updates. Yes, maybe that would be helpful, but on the other hand it makes things more complicated and buerocratic. My take: Bring this idea back up after EPEL has taken of and if people push to much stuff to the stable branch. > We might want to also mention (although perhaps it's just common sense) > that if people have any questions about how they should handle an > upgrade in their package, they should consult this list and/or the SIG > members for input. It might be that someone here could find or be able > to generate a backported fix when a maintainer is unable to. Might be a good idea. I'll add a short section. > Anyhow, looks good to me. thx. Cu thl From Axel.Thimm at ATrpms.net Sat Mar 10 09:42:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 10:42:50 +0100 Subject: Request for voting SIG In-Reply-To: <45F2789E.7070505@leemhuis.info> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> Message-ID: <20070310094250.GA17717@neu.nirvana> On Sat, Mar 10, 2007 at 10:21:34AM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > we need to get a voting body set up asap. Nominate a bunch of folks, > > maybe the ones in the wiki plus a couple more and give them fesco to > > ratify (by vote) and to formulate our mandate. > > Well, it was never formally announced/ratified/written down, but afaics > it works like in other SIGS. That is: the SIG members takes care of the > sub-project (in this case EPEL), thus they are the ones that > vote/decide. That is normally done via the preferred meeting channel -- > I'd say for this SIG that is normally the meetings on IRC. > > Yes, as we grow we (might soon) need a more standardized procedure > (similar how FESCo works I'd say). But above should work for now afaics. Not everyone can make it to the Sunday irc meeting, and there are now two precedents were either people doubt on the legitimacy of this group or this group silently avoids voting. So we should get things clarified/formalized to be able to *work* on issues instead of discussing them. Let fesco appoint a group and setup the framwork of our mandate. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Mar 10 09:44:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 10:44:46 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070309194838.GC31061@neu.nirvana> References: <20070308191119.7880e9a3.mschwendt.tmp0701.nospam@arcor.de> <20070308184824.GB10906@neu.nirvana> <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> Message-ID: <45F27E0E.2090606@leemhuis.info> Axel Thimm schrieb: > On Fri, Mar 09, 2007 at 05:47:34PM +0100, Thorsten Leemhuis wrote: >> Michael Schwendt schrieb: >>> fedora-usermgmt is not about fixing something, but about adding a >>> feature. Well, that's my point of view. I'm not a hardcore advocate of >>> using it everywhere. But I don't understand why a simple EPEL steering >>> decision is wrapped into a crusade against an optional tool. >> Mainly for two reasons afaics: >> - Because the rules in EPEL imho should be as identical to the rules >> from Fedora as much as possible, as everything that differs between the >> two will make life harder for users and packagers (for example a package >> that currently uses fedora-usermgmt in Fedora could not simply be build >> for EPEL without adjustments) > Mostly agreed, but it tears on our nerves. I still fail to see how fedora-usermgmt "tears on our nerves" (besides this discussion). Can somebody *please* show me two detailed examples where using fedora-usermgmt in a package does something bad/odd on peoples systems in the default install (e.g. in case the admin didn't set it up)? tia! > We need to be able to veto some > stuff from entering EPEL and throw them back in the Fedora pool to > mature/be discussed there. En attendant Godot isn't good for EPEL ... My take: For EPEL5 maybe (as EPEL is starting now), but only if we really really have to. For EPEL6 and later: By all means no -- there should be enough time to work out and test a solution in Fedora land in time for EPEL6 that fits both the needs of Fedora and EPEL. > So, how about vetoing instead of branching? I still fail to see why. These seems to be a lot of FUD around. CU thl From fedora at leemhuis.info Sat Mar 10 10:00:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 11:00:55 +0100 Subject: Request for voting SIG In-Reply-To: <20070310094250.GA17717@neu.nirvana> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> Message-ID: <45F281D7.30907@leemhuis.info> Axel Thimm schrieb: > > So we should get things clarified/formalized to be able to *work* on > issues instead of discussing them. Let fesco appoint a group and setup > the framwork of our mandate. The EPEL SIG is afaics appointed by FESCo to work on EPEL. Cu thl From Axel.Thimm at ATrpms.net Sat Mar 10 10:03:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 11:03:05 +0100 Subject: Request for voting SIG In-Reply-To: <45F281D7.30907@leemhuis.info> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> Message-ID: <20070310100305.GC17717@neu.nirvana> On Sat, Mar 10, 2007 at 11:00:55AM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > > > So we should get things clarified/formalized to be able to *work* on > > issues instead of discussing them. Let fesco appoint a group and setup > > the framwork of our mandate. > > The EPEL SIG is afaics appointed by FESCo to work on EPEL. Which means that we can finally initiate a vote on fedora-usrmgmt acceptance or banning? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 10:12:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 11:12:29 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F27E0E.2090606@leemhuis.info> References: <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> Message-ID: <20070310101229.GD17717@neu.nirvana> On Sat, Mar 10, 2007 at 10:44:46AM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Fri, Mar 09, 2007 at 05:47:34PM +0100, Thorsten Leemhuis wrote: > >> Michael Schwendt schrieb: > >>> fedora-usermgmt is not about fixing something, but about adding a > >>> feature. Well, that's my point of view. I'm not a hardcore advocate of > >>> using it everywhere. But I don't understand why a simple EPEL steering > >>> decision is wrapped into a crusade against an optional tool. > >> Mainly for two reasons afaics: > >> - Because the rules in EPEL imho should be as identical to the rules > >> from Fedora as much as possible, as everything that differs between the > >> two will make life harder for users and packagers (for example a package > >> that currently uses fedora-usermgmt in Fedora could not simply be build > >> for EPEL without adjustments) > > Mostly agreed, but it tears on our nerves. > > I still fail to see how fedora-usermgmt "tears on our nerves" (besides > this discussion). How else could it tear on them? I wasn't impling package installation time ... > Can somebody *please* show me two detailed examples where using > fedora-usermgmt in a package does something bad/odd on peoples > systems in the default install (e.g. in case the admin didn't set it > up)? tia! Please, there are two infinite threads with examples and arguments in them. Please read them, let's not loop again. This is exactly why we need to be able to resolve stuff by a simple vote. Give a topic some fair discussussion time, then vote on it and let it rip. > > We need to be able to veto some > > stuff from entering EPEL and throw them back in the Fedora pool to > > mature/be discussed there. En attendant Godot isn't good for EPEL ... > > My take: For EPEL5 maybe (as EPEL is starting now), but only if we > really really have to. For EPEL6 and later: By all means no -- there > should be enough time to work out and test a solution in Fedora land in > time for EPEL6 that fits both the needs of Fedora and EPEL. > > > So, how about vetoing instead of branching? > > I still fail to see why. These seems to be a lot of FUD around. Can you give me two examples of FUD? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Mar 10 10:25:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 11:25:09 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070310101229.GD17717@neu.nirvana> References: <20070308205048.46634a22.mschwendt.tmp0701.nospam@arcor.de> <20070308213454.GG10906@neu.nirvana> <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> Message-ID: <45F28785.1020007@leemhuis.info> Axel Thimm schrieb: >> Can somebody *please* show me two detailed examples where using >> fedora-usermgmt in a package does something bad/odd on peoples >> systems in the default install (e.g. in case the admin didn't set it >> up)? tia! > Please, there are two infinite threads with examples and arguments in > them. Then I missed them. Please point me two two detailed example that I can play around with here to understand the problems better. > [...] >>> So, how about vetoing instead of branching? >> I still fail to see why. These seems to be a lot of FUD around. > Can you give me two examples of FUD? No, because I said, "seems" -- In other words: I am unsure, and that's why I'm asking for detailed examples. CU thl From fedora at leemhuis.info Sat Mar 10 10:41:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 11:41:20 +0100 Subject: Request for voting SIG In-Reply-To: <20070310100305.GC17717@neu.nirvana> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> Message-ID: <45F28B50.9080700@leemhuis.info> Axel Thimm schrieb: > On Sat, Mar 10, 2007 at 11:00:55AM +0100, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> So we should get things clarified/formalized to be able to *work* on >>> issues instead of discussing them. Let fesco appoint a group and setup >>> the framwork of our mandate. >> The EPEL SIG is afaics appointed by FESCo to work on EPEL. > Which means that we can finally initiate a vote on fedora-usrmgmt > acceptance or banning? I'd say no (but that's just my opinion) -- until now the SIG worked mostly like this afaics: SIG members simply do stuff and keep the other members up2date with what they do and as long as nobody yells everything is fine. That's a whole lot easier for a getting stuff done in this startup phase. But is we start to have controversial topics with real battle-voting's then I'd say we have to get a lot of process in place first. E.g. - where to vote (IRC, mailing lists) - how many voters have to vote +1 to accept something - who coordinates the votes (chaos would arise if everybody calls out for voting's ) - control who becomes a SIG member (having voting with more then 20 people becomes problematic) - announce voting's beforehand and give members enough time to vote - some other stuff I'm forgetting now That's a lot of process to put in place and to document. I agree that we need that sooner or later, but I must say I had hoped we could finish this startup phase without all that overhead. CU thl From Axel.Thimm at ATrpms.net Sat Mar 10 10:44:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 11:44:43 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F28785.1020007@leemhuis.info> References: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> Message-ID: <20070310104443.GA20977@neu.nirvana> On Sat, Mar 10, 2007 at 11:25:09AM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > >> Can somebody *please* show me two detailed examples where using > >> fedora-usermgmt in a package does something bad/odd on peoples > >> systems in the default install (e.g. in case the admin didn't set it > >> up)? tia! > > Please, there are two infinite threads with examples and arguments in > > them. > > Then I missed them. Please point me two two detailed example that I can > play around with here to understand the problems better. > > > [...] > >>> So, how about vetoing instead of branching? > >> I still fail to see why. These seems to be a lot of FUD around. > > Can you give me two examples of FUD? > > No, because I said, "seems" -- In other words: I am unsure, and that's > why I'm asking for detailed examples. Of the top of my head, there are more in the thread, feel free to setup a wiki page: a) package A and B assume the user foo is at base+42. System installs A, admin configures fedora-usrmgmt, system install B => desynced uid assertion b) same as above, only that now thge admin wasn't "sloppy", but anaconda installed A. c) Admin buys fedora-usrmgmt "feature" set and *relies* on keeping foo the same across all his systems, forgets to configure system 23 after the bare bone installation, uids get mixed, possibly exposing sensitive information under another uid. d) Packager buys fedora-usrmgmt "feature" and relies on the fixed/semi-fixed approach, but is not aware that on almost 100% of user deployment noone has configured fedora-usrmgmt and therefore fedora-usrmgmt is just plain old useradd. so he tests with different assertions and the package fails on the tyopical user deployment. The method is fragile to say the least, and requires iron discipline form the admin with no room for errors. This does not surface in real life, because this method is *unused* by any package, which means that no package really relies on fixed/semi-fixed uids. So with fedora-usrmgmt we deliver a small bomb, and fortunately 99.99% of the users don't know how to arm it. Packages that use it are probably owned by the same author that wrote fedora-usrmgmt or are from the hype era of fedora-usrmgmt or are from packagers that searched for user management in the wiki and all thy could find was fedora-usrmgmt. User management is delicate and fedora-usermgmt is not the way to go. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Mar 10 10:59:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 11:59:56 +0100 Subject: Request for voting SIG In-Reply-To: <45F28B50.9080700@leemhuis.info> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> Message-ID: <20070310105956.GB20977@neu.nirvana> On Sat, Mar 10, 2007 at 11:41:20AM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Sat, Mar 10, 2007 at 11:00:55AM +0100, Thorsten Leemhuis wrote: > >> Axel Thimm schrieb: > >>> So we should get things clarified/formalized to be able to *work* on > >>> issues instead of discussing them. Let fesco appoint a group and setup > >>> the framwork of our mandate. > >> The EPEL SIG is afaics appointed by FESCo to work on EPEL. > > Which means that we can finally initiate a vote on fedora-usrmgmt > > acceptance or banning? > > I'd say no (but that's just my opinion) -- until now the SIG worked > mostly like this afaics: SIG members simply do stuff and keep the other > members up2date with what they do and as long as nobody yells everything > is fine. Doesn't the threads on fedora-usrmgmt look like a massive yelling? I'm sure if it comes to a vote the majority is against the imported fedora-usermgmt stuff. > That's a whole lot easier for a getting stuff done in this startup > phase. But is we start to have controversial topics with real > battle-voting's then I'd say we have to get a lot of process in place > first. E.g. That's not a battle-voting, it's just a conventional vote. > - where to vote (IRC, mailing lists) both, of course. > - how many voters have to vote +1 to accept something majority. With 13 members that makes 7 votes. What else would there be to discuss about? Or do you apply as a benevolent dictator? ;) > - who coordinates the votes (chaos would arise if everybody calls out > for voting's ) Every sig member, there is not more chaos than discussing things w/o ever voting. Voting will *reduce* chaos. > - control who becomes a SIG member (having voting with more then 20 > people becomes problematic) fesco nominates sig group, we can aid in suggesting the sig group members. I don't know if that has already happened though, your quote above says that fesco already appointed this sig on epel, so probably this step isn't needed anymore. There are now 13 people registred as sig members, that's a healthy size and fortunately an odd number, so the quorum is 7 votes. > - announce voting's beforehand and give members enough time to vote > - some other stuff I'm forgetting now > That's a lot of process to put in place and to document. I think everything is rather trivial and already in place, or do you really want to discuss whether we should vote only on IRC or IRC/list or whether we want majority votes? > I agree that we need that sooner or later, but I must say I had > hoped we could finish this startup phase without all that overhead. A steeringless project is inevitably following Brown's law rather than being productive. I certainly feel less than productive with the usermgmt stuff taking so much of my epel time. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Sat Mar 10 12:15:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 13:15:58 +0100 Subject: Request for voting SIG In-Reply-To: <20070310105956.GB20977@neu.nirvana> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> Message-ID: <20070310121558.GD3153@free.fr> On Sat, Mar 10, 2007 at 11:59:56AM +0100, Axel Thimm wrote: > > Doesn't the threads on fedora-usrmgmt look like a massive yelling? I'm > sure if it comes to a vote the majority is against the imported > fedora-usermgmt stuff. It is not a valid argument. Having a vote won't cut technical discussion threads. > That's not a battle-voting, it's just a conventional vote. It is battle voting. There is no consensus on this issue. > Every sig member, there is not more chaos than discussing things w/o > ever voting. Voting will *reduce* chaos. If you refer to the fedora-usermgmt threads voting won't be sufficient. Hopefully a vote won't stop people discussing. > A steeringless project is inevitably following Brown's law rather than > being productive. I certainly feel less than productive with the > usermgmt stuff taking so much of my epel time. A steering commitee won't help cutting discussions. Or do you want that? A steering commitee may be usefull, however if there is a decision to take on fedora-usermgmt. And for other decisions, of course. (I am not convinced that my advice is very important, but I agree with Thorsten that it is a bit too soon to have a voting body. Though I also agree with you that it should be needed soon). -- Pat From mschwendt.tmp0701.nospam at arcor.de Sat Mar 10 13:16:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 10 Mar 2007 14:16:44 +0100 Subject: Request for voting SIG In-Reply-To: <20070310121558.GD3153@free.fr> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> <20070310121558.GD3153@free.fr> Message-ID: <20070310141644.ab94ec9d.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Mar 2007 13:15:58 +0100, Patrice Dumas wrote: > On Sat, Mar 10, 2007 at 11:59:56AM +0100, Axel Thimm wrote: > > > > Doesn't the threads on fedora-usrmgmt look like a massive yelling? I'm > > sure if it comes to a vote the majority is against the imported > > fedora-usermgmt stuff. > > It is not a valid argument. Having a vote won't cut technical discussion > threads. Exactly. The decision on whether EPEL has a place/need for fedora-usermgmt ought to come *after* a technical analysis. In Fedora-land, examining and deciding on fedora-usermgmt has been neglected. When you know exactly what the tools do and what they try to achieve, you can judge about them and decide on their fate. Of course, you can also skip those steps and block a package for other reasons, e.g. political ones. What is happening in these threads is that wrong things written about fedora-usermgmt, biased opinions, and even FUD lead to corrections, which in turn are seen as opposition with the need to fight against. The repeated attempts at proving that something in fedora-usermgmt is broken have more than once ended in examples that involved PEBKAC. Personally, I don't have strong feelings about all this. I've given enough hints on how I think about fedora-usermgmt and any unavailable alternatives. > > That's not a battle-voting, it's just a conventional vote. > > It is battle voting. There is no consensus on this issue. You can skip the vote if there is consensus. ;o) From Axel.Thimm at ATrpms.net Sat Mar 10 13:20:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Mar 2007 14:20:56 +0100 Subject: Request for voting SIG In-Reply-To: <20070310121558.GD3153@free.fr> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> <20070310121558.GD3153@free.fr> Message-ID: <20070310132056.GB26349@neu.nirvana> On Sat, Mar 10, 2007 at 01:15:58PM +0100, Patrice Dumas wrote: > On Sat, Mar 10, 2007 at 11:59:56AM +0100, Axel Thimm wrote: > > Doesn't the threads on fedora-usrmgmt look like a massive yelling? > > I'm sure if it comes to a vote the majority is against the > > imported fedora-usermgmt stuff. > > It is not a valid argument. Having a vote won't cut technical discussion > threads. No, by all means, go on discussing until forever. We do need to come to an end, though. And that's why I see it beneficial, if EPEL decides to ban this until Fedora-land resolves it after the discussion comes to an "end". > > That's not a battle-voting, it's just a conventional vote. > > It is battle voting. There is no consensus on this issue. If there were consensus then there would *never* be a need for voting (and that doesn't only apply to EPEL), right? > > Every sig member, there is not more chaos than discussing things w/o > > ever voting. Voting will *reduce* chaos. > > If you refer to the fedora-usermgmt threads voting won't be sufficient. > Hopefully a vote won't stop people discussing. This is not about censorship, feel free to discuss until forever, I just want to see it resolved, there is now a thorn twisted in EPEL's side, and whatever the result of a vote would be it would at least bring peace to my trouble mind. I'm sure others would like to see this ending, too. > > A steeringless project is inevitably following Brown's law rather than > > being productive. I certainly feel less than productive with the > > usermgmt stuff taking so much of my epel time. > > A steering commitee won't help cutting discussions. Or do you want that? We are not censoring anyone, but we need to take actions, too. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Sat Mar 10 13:48:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 14:48:52 +0100 Subject: Request for voting SIG In-Reply-To: <20070310132056.GB26349@neu.nirvana> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> <20070310121558.GD3153@free.fr> <20070310132056.GB26349@neu.nirvana> Message-ID: <20070310134852.GF3153@free.fr> On Sat, Mar 10, 2007 at 02:20:56PM +0100, Axel Thimm wrote: > No, by all means, go on discussing until forever. We do need to come > to an end, though. And that's why I see it beneficial, if EPEL decides > to ban this until Fedora-land resolves it after the discussion comes > to an "end". We don't need to come to an end. What is this issue blocking? Is there any package using fedora-usermgmt wanting to enter EPEL? > This is not about censorship, feel free to discuss until forever, I > just want to see it resolved, there is now a thorn twisted in EPEL's > side, and whatever the result of a vote would be it would at least > bring peace to my trouble mind. I'm sure others would like to see this > ending, too. Peace of mind? -- Pat From fedora at leemhuis.info Sat Mar 10 15:31:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 16:31:56 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070310104443.GA20977@neu.nirvana> References: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> <20070310104443.GA20977@neu.nirvana> Message-ID: <45F2CF6C.5020906@leemhuis.info> Axel Thimm schrieb: > On Sat, Mar 10, 2007 at 11:25:09AM +0100, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: Just a note here: I don't want to advocate for fedora-usrmgmt, I just want to understand where the problems with it are. Further: I agree that having a bigger fixed uid space for packages would be the best solution, but we haven't one ATM afaics. >>>> Can somebody *please* show me two detailed examples where using >>>> fedora-usermgmt in a package does something bad/odd on peoples >>>> systems in the default install (e.g. in case the admin didn't set it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> up)? tia! ^^ >>> Please, there are two infinite threads with examples and arguments in >>> them. > [...] > Of the top of my head, there are more in the thread, feel free to > setup a wiki page: > > a) package A and B assume the user foo is at base+42. System installs > A, admin configures fedora-usrmgmt, system install B => desynced > uid assertion As I said, I wanted examples where the admin did "not* set it up (the default). Then fedora-usrmgmt works just like a normal useradd, doesn't it? Further: Is packages A and B both assume base+42 then we did something wrong, didn't we? And if the admin configures fedora-usrmgmt so that is uses a uid-space where some uid's already are used then he did something wrong, didn't he? > b) same as above, only that now thge admin wasn't "sloppy", but > anaconda installed A. Can't follow, sorry. > c) Admin buys fedora-usrmgmt "feature" set and *relies* on keeping foo > the same across all his systems, forgets to configure system 23 after > the bare bone installation, uids get mixed, possibly exposing > sensitive information under another uid. It's not fedora-usrmgmt's fault if the admin forgets something. He with fedora-usrmgmt at least has a chance to use the same uid on all his systems afaics, which he would not have without it. Or am I missing something? > d) Packager buys fedora-usrmgmt "feature" and relies on the > fixed/semi-fixed approach, but is not aware that on almost 100% of > user deployment noone has configured fedora-usrmgmt and therefore > fedora-usrmgmt is just plain old useradd. so he tests with > different assertions and the package fails on the tyopical user > deployment. I asked for examples where is does harm on users systems. Further: if it is just plain old useradd then nobody is hurt, isn't it? > The method is fragile to say the least, and requires iron discipline > form the admin with no room for errors. [...] I'd say you are shooting over the top here. > User management is delicate and fedora-usermgmt is not the way to go. It solved a problem afaics, that we have no better solution for in RHEL5. Does it do any harm if not or correctly configured? Don't know, I'm still looking for two examples that show me where it does. CU thl From fedora at leemhuis.info Sat Mar 10 15:42:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 16:42:36 +0100 Subject: Request for voting SIG In-Reply-To: <20070310105956.GB20977@neu.nirvana> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> Message-ID: <45F2D1EC.4000509@leemhuis.info> Axel Thimm schrieb: > [...] > A steeringless project is inevitably following Brown's law rather than > being productive. I certainly feel less than productive with the > usermgmt stuff taking so much of my epel time. It worked quite well in the past weeks afaics and there was much progress. Anyway, if people really want some kind of steering committee then I'm fine with it. But I think the SIG is already to big to be the "steering committee" -- 13 people are two much from my FESCo experiences (the plan is even to make FESCo smaller, too). I'd say 5 or 7 people should be enough for EPEL. CU thl From mschwendt.tmp0701.nospam at arcor.de Sat Mar 10 17:01:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 10 Mar 2007 18:01:10 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F2CF6C.5020906@leemhuis.info> References: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> <20070310104443.GA20977@neu.nirvana> <45F2CF6C.5020906@leemhuis.info> Message-ID: <20070310180110.cb9c6c45.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Mar 2007 16:31:56 +0100, Thorsten Leemhuis wrote: > Axel Thimm wrote: > > User management is delicate and fedora-usermgmt is not the way to go. > > It solved a problem afaics, that we have no better solution for in RHEL5. It doesn't. It adds a feature that can be enabled on demand. The feature fixes a problem, but since the tool is not enabled by default, it doesn't fix anything for us. There are other reasons why EPEL might not want the tool. Naming them is left as an exercise once all the critics have understood what the tool does and how it works. From mschwendt.tmp0701.nospam at arcor.de Sat Mar 10 17:08:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 10 Mar 2007 18:08:21 +0100 Subject: Request for voting SIG In-Reply-To: <20070310134852.GF3153@free.fr> References: <20070309204713.GD31061@neu.nirvana> <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> <20070310121558.GD3153@free.fr> <20070310132056.GB26349@neu.nirvana> <20070310134852.GF3153@free.fr> Message-ID: <20070310180821.6d1ae406.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Mar 2007 14:48:52 +0100, Patrice Dumas wrote: > On Sat, Mar 10, 2007 at 02:20:56PM +0100, Axel Thimm wrote: > > > No, by all means, go on discussing until forever. We do need to come > > to an end, though. And that's why I see it beneficial, if EPEL decides > > to ban this until Fedora-land resolves it after the discussion comes > > to an "end". > > We don't need to come to an end. What is this issue blocking? Is there > any package using fedora-usermgmt wanting to enter EPEL? fedora-usermgmt is in EPEL 4 and 5. Maybe as a requirement. Maybe without a rationale. However, I'm not informed enough about who has decided on what packages were permitted to enter the repo initially. EPEL 4 and 5 don't provide the same packages. That is questionable already IMO. From fedora at leemhuis.info Sat Mar 10 17:15:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Mar 2007 18:15:17 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <20070310180110.cb9c6c45.mschwendt.tmp0701.nospam@arcor.de> References: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> <20070310104443.GA20977@neu.nirvana> <45F2CF6C.5020906@leemhuis.info> <20070310180110.cb9c6c45.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45F2E7A5.7070006@leemhuis.info> Michael Schwendt schrieb: > On Sat, 10 Mar 2007 16:31:56 +0100, Thorsten Leemhuis wrote: >> Axel Thimm wrote: >>> User management is delicate and fedora-usermgmt is not the way to go. >> It solved a problem afaics, that we have no better solution for in RHEL5. > > It doesn't. It adds a feature that can be enabled on demand. The feature > fixes a problem, but since the tool is not enabled by default, it doesn't > fix anything for us. Okay, then let me rephrase: fedora-usermgmt can be used to solve a problem if the local admin wants to do it; fedora-usermgmt works the same way as useradd would if not configured and should do no more or less harm then useradd for users. Does that match better? > There are other reasons why EPEL might not want the tool. Naming them is > left as an exercise once all the critics have understood what the tool does > and how it works. /me still would like to see good reasons to ban it... /me sill wants this problems solved in Fedora-land once (e.g. in both EPEL and Fedora) CU thl From pertusus at free.fr Sat Mar 10 17:17:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 18:17:25 +0100 Subject: Request for voting SIG In-Reply-To: <20070310180821.6d1ae406.mschwendt.tmp0701.nospam@arcor.de> References: <45F2789E.7070505@leemhuis.info> <20070310094250.GA17717@neu.nirvana> <45F281D7.30907@leemhuis.info> <20070310100305.GC17717@neu.nirvana> <45F28B50.9080700@leemhuis.info> <20070310105956.GB20977@neu.nirvana> <20070310121558.GD3153@free.fr> <20070310132056.GB26349@neu.nirvana> <20070310134852.GF3153@free.fr> <20070310180821.6d1ae406.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070310171725.GC3377@free.fr> On Sat, Mar 10, 2007 at 06:08:21PM +0100, Michael Schwendt wrote: > > fedora-usermgmt is in EPEL 4 and 5. Maybe as a requirement. Maybe without > a rationale. However, I'm not informed enough about who has decided on > what packages were permitted to enter the repo initially. EPEL 4 and 5 > don't provide the same packages. That is questionable already IMO. If I have understood things right anybody can currently ask for an EPEL branch (4 or 5) and build. I don't know exactly what happens to the build afterwards. Maybe I am wrong, but that's what I remember from reading something from Thorsten. As for the packages already in the repo they have been put there during the build up phase by those who started EPEL. Until recently things were more or less in a testing phase. I guess that it may even be possible to have packages removed from the repo. Sorry if I misrepresent something I am not very informed but that's how I understand the state of affair. -- Pat From mschwendt.tmp0701.nospam at arcor.de Sat Mar 10 17:42:17 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 10 Mar 2007 18:42:17 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F2E7A5.7070006@leemhuis.info> References: <20070308231839.5a9b8984.mschwendt.tmp0701.nospam@arcor.de> <20070309085246.GE19382@neu.nirvana> <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> <20070310104443.GA20977@neu.nirvana> <45F2CF6C.5020906@leemhuis.info> <20070310180110.cb9c6c45.mschwendt.tmp0701.nospam@arcor.de> <45F2E7A5.7070006@leemhuis.info> Message-ID: <20070310184217.b846d51d.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Mar 2007 18:15:17 +0100, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > On Sat, 10 Mar 2007 16:31:56 +0100, Thorsten Leemhuis wrote: > >> Axel Thimm wrote: > >>> User management is delicate and fedora-usermgmt is not the way to go. > >> It solved a problem afaics, that we have no better solution for in RHEL5. > > > > It doesn't. It adds a feature that can be enabled on demand. The feature > > fixes a problem, but since the tool is not enabled by default, it doesn't > > fix anything for us. > > Okay, then let me rephrase: fedora-usermgmt can be used to solve a > problem if the local admin wants to do it; fedora-usermgmt works the > same way as useradd would if not configured and should do no more or > less harm then useradd for users. > > Does that match better? Yes. > > There are other reasons why EPEL might not want the tool. Naming them is > > left as an exercise once all the critics have understood what the tool does > > and how it works. > > /me still would like to see good reasons to ban it... For instance, but probably not limited to: - It is a wrapper around a system utility (user{add,del}/group{add,del}). - It is not particularly convenient to turn it on at install-time. - Non-standard user/group maintenance tools are not supported in RHEL. - Two set of tools, different possibly conflicting behaviour (if enabled). - You need people to maintain the package/tools for many years. - You need to keep it alive for many years, since offering it implies that your users may deploy it. - The relative values in pkg scriptlets are misleading as they look like constants, e.g. fedora-useradd 42 joe is not like useradd -u 42 joe - It is not pretty, see e.g. "fedora-useradd --help". - Has it seen enough QA before it's made available to the target group of EPEL? > /me sill wants this problems solved in Fedora-land once (e.g. in both > EPEL and Fedora) > > CU > thl From pertusus at free.fr Sat Mar 10 17:34:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 18:34:56 +0100 Subject: RFP: octave and octave-forge for EL5 In-Reply-To: <1173484381.5295.0.camel@ping0.tabb> References: <1173371973.3844.20.camel@hazard2.larc.nasa.gov> <20070308181535.GC2954@free.fr> <1173484381.5295.0.camel@ping0.tabb> Message-ID: <20070310173456.GD3377@free.fr> On Fri, Mar 09, 2007 at 06:53:01PM -0500, Philip Ray Schaffner wrote: > On Thu, 2007-03-08 at 19:15 +0100, Patrice Dumas wrote: > > On Thu, Mar 08, 2007 at 11:39:33AM -0500, Phil Schaffner wrote: > > > > > > libdap-3.7.2-3.fc7.src.rpm > > > libnc-dap-3.6.2-5.fc7.src.rpm > > > > libnc-dap API/ABI is stable, but libdap is very unstable, and I am not > > convinced that it is a right candidate for EPEL. I will discuss that > > with upstream, however. > > OK - put please consider the context. No libdap, no octave-forge. libdap API/ABI changes every 6 months, only the latest is maintained. In the case of that package I have very good relations with upstream, but I am not familiar enough with C++, the internal of libdap and binary compatibility to be able to readd the removed interfaces or backport critical fixes. If you (or anybody else) are volunteering to do that I'll happily do the packaging, but I cannot realistically commit to do it. I do consider the context of EPEL. I'll contact upstream, maybe now that there is a need for a more stable API they'll be willing to change their development model, but I cannot make any promise. -- Pat From Axel.Thimm at ATrpms.net Sat Mar 10 23:22:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 11 Mar 2007 00:22:43 +0100 Subject: remove fedora-usermgmt? In-Reply-To: <45F2CF6C.5020906@leemhuis.info> References: <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> <20070310104443.GA20977@neu.nirvana> <45F2CF6C.5020906@leemhuis.info> Message-ID: <20070310232243.GC5550@neu.nirvana> On Sat, Mar 10, 2007 at 04:31:56PM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Sat, Mar 10, 2007 at 11:25:09AM +0100, Thorsten Leemhuis wrote: > >> Axel Thimm schrieb: > > Just a note here: I don't want to advocate for fedora-usrmgmt, I just > want to understand where the problems with it are. > > Further: I agree that having a bigger fixed uid space for packages would > be the best solution, but we haven't one ATM afaics. > > >>>> Can somebody *please* show me two detailed examples where using > >>>> fedora-usermgmt in a package does something bad/odd on peoples > >>>> systems in the default install (e.g. in case the admin didn't set it > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>> up)? tia! > ^^ > >>> Please, there are two infinite threads with examples and arguments in > >>> them. > > [...] > > Of the top of my head, there are more in the thread, feel free to > > setup a wiki page: > > > > a) package A and B assume the user foo is at base+42. System installs > > A, admin configures fedora-usrmgmt, system install B => desynced > > uid assertion > > As I said, I wanted examples where the admin did "not* set it up (the > default). Then fedora-usrmgmt works just like a normal useradd, doesn't it? The admin may not even be aware that package A has been installed via fedora-usrmgmt. It might have been installed as part of anaconda, see b) > Further: Is packages A and B both assume base+42 then we did something > wrong, didn't we? Why? Imagine A being something like apache and B needing to use the same user. > And if the admin configures fedora-usrmgmt so that is uses a > uid-space where some uid's already are used then he did something > wrong, didn't he? That's not what this is about, I hope the explenation about clarify it. > > b) same as above, only that now thge admin wasn't "sloppy", but > > anaconda installed A. > > Can't follow, sorry. Well, consider this method being deployed so much that "F7 prime" contains package A, e.g. A is installed from DVD and the admin never had a chance to configure the system before the first fedora-usrmgmt controlled package hit the system. So A is always installed with the default fedora-usrmgmt behaviour. Then the admin gets his first shell login on this system, and even though configuring the flaoting uid space is the first thing he does, he already slipped package A, and package B will never be able to "predict" the uid used by package A. > > c) Admin buys fedora-usrmgmt "feature" set and *relies* on keeping foo > > the same across all his systems, forgets to configure system 23 after > > the bare bone installation, uids get mixed, possibly exposing > > sensitive information under another uid. > > It's not fedora-usrmgmt's fault if the admin forgets something. He with > fedora-usrmgmt at least has a chance to use the same uid on all his > systems afaics, which he would not have without it. Or am I missing > something? Yes, that the system becomes far more fragile, non-deterministic and insecure. An admin is required to show far more discipline here than in any other part of the system configuration. At least other errors with similar sloppyness in configuring the system don't expose security relevant parts or require reinstalling the system from scratch. > > d) Packager buys fedora-usrmgmt "feature" and relies on the > > fixed/semi-fixed approach, but is not aware that on almost 100% of > > user deployment noone has configured fedora-usrmgmt and therefore > > fedora-usrmgmt is just plain old useradd. so he tests with > > different assertions and the package fails on the tyopical user > > deployment. > > I asked for examples where is does harm on users systems. That's such an example. If the packager tested it in an environment where fedora-usrmgmt is activated and provides deterministic/predictable/ static uids, but breaks if fedora-usrmgmt defaults to useradd -r then it harms user systems. > Further: if it is just plain old useradd then nobody is hurt, isn't it? It was an explicit assumption in d) that this package really needs more than plain old useradd. And also add e) The fedora-usrmgmt is a configure-once-never-reconfigure option. Is this really evident to the end user/admin? Do we require the admins to be that much aware of the background of fedora-usrmgmt to understand that they can only nail the floating window once and that they will break havoc if they think they can relocate it by reconfiguring the base uid? There is nothing else comparable to this other than the type of filesystem maybe you chose. > > The method is fragile to say the least, and requires iron discipline > > form the admin with no room for errors. [...] > > I'd say you are shooting over the top here. Maybe the clarifications help to see the pitfalls that lie ahead. > > User management is delicate and fedora-usermgmt is not the way to go. > > It solved a problem afaics, that we have no better solution for in RHEL5. Which and whose problem? I still think that less than 100 people ever used that mechanism. Let's put that into perspective. > Does it do any harm if not or correctly configured? The question is not whether it does any harm while it's dormant. You could just the same argue on whether cat > /sbin/suicide << EOF #! /bin/sh echo Told you so rm -fr / EOF chmod +x /sbin/suicide is harmful as long as you don't call it. > Don't know, I'm still looking for two examples that show me where it > does. You got more than two examples. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Sun Mar 11 02:21:38 2007 From: steve at silug.org (Steven Pritchard) Date: Sat, 10 Mar 2007 20:21:38 -0600 Subject: remove fedora-usermgmt? In-Reply-To: <45F2CF6C.5020906@leemhuis.info> References: <20070309133113.9397a0d6.mschwendt.tmp0701.nospam@arcor.de> <20070309151947.GA15248@neu.nirvana> <20070309172602.dfc0965a.mschwendt.tmp0701.nospam@arcor.de> <45F18FA6.80508@leemhuis.info> <20070309194838.GC31061@neu.nirvana> <45F27E0E.2090606@leemhuis.info> <20070310101229.GD17717@neu.nirvana> <45F28785.1020007@leemhuis.info> <20070310104443.GA20977@neu.nirvana> <45F2CF6C.5020906@leemhuis.info> Message-ID: <20070311022138.GA13305@osiris.silug.org> On Sat, Mar 10, 2007 at 04:31:56PM +0100, Thorsten Leemhuis wrote: > Further: I agree that having a bigger fixed uid space for packages would > be the best solution, but we haven't one ATM afaics. And it wouldn't matter, since the whole point is (supposedly) to have consistent UIDs across systems, and the bigger fixed UID space would only apply to the latest Fedora/RHEL/whatever, not any older systems (possibly upgraded to the latest release) or any other non-Fedora-based systems. 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 fedora at leemhuis.info Sun Mar 11 17:38:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 11 Mar 2007 18:38:26 +0100 Subject: IRC Meetings: New meeting time? Message-ID: <45F43E92.9050501@leemhuis.info> Hi all! The EPEL SIG currently meets each Sunday at 16:00 UTC -- this was the time and date that matched most of the most active EPEL drivers when the EPEL SIG was quite small. Well, we have grown a bit, so we should probably re-discuss the meeting time again. So what date and time would you guys people prefer? My 2 cent: A meeting time between 16:00 and 20:30 local german time(?) would be the best for me(?). I'm nearly always afk later and at work/shopping/in the garden/cleaning the house earlier then 16:00. Cu thl (?) -- that's 15:00 to 19:30 UTC currently, and 14:00 to 18:30 UTC in two weeks from now, when Europe switches to DST (?) -- early mornings (6:40 till ~ 9:00) wound be fine for me Monday to Friday, too From Axel.Thimm at ATrpms.net Sun Mar 11 18:09:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 11 Mar 2007 19:09:47 +0100 Subject: IRC Meetings: New meeting time? In-Reply-To: <45F43E92.9050501@leemhuis.info> References: <45F43E92.9050501@leemhuis.info> Message-ID: <20070311180947.GR507@neu.nirvana> On Sun, Mar 11, 2007 at 06:38:26PM +0100, Thorsten Leemhuis wrote: > The EPEL SIG currently meets each Sunday at 16:00 UTC -- this was the > time and date that matched most of the most active EPEL drivers when the > EPEL SIG was quite small. > > Well, we have grown a bit, so we should probably re-discuss the meeting > time again. So what date and time would you guys people prefer? I'd plead for another day. According to http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel Mon/Wed/Fri is completely free. Perhaps Wed makes most sense and the since the time slots of fesco and fpc were really narrowed to these two trying to keep nightfall over the Pacific I'd suggest one of them. E.g. Wed 17:00 UTC or Wed 18:00 UTC -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sun Mar 11 18:20:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 11 Mar 2007 13:20:00 -0500 Subject: IRC Meetings: New meeting time? In-Reply-To: <20070311180947.GR507@neu.nirvana> References: <45F43E92.9050501@leemhuis.info> <20070311180947.GR507@neu.nirvana> Message-ID: <200703111320.00736.dennis@ausil.us> Once upon a time Sunday 11 March 2007, Axel Thimm wrote: > On Sun, Mar 11, 2007 at 06:38:26PM +0100, Thorsten Leemhuis wrote: > > The EPEL SIG currently meets each Sunday at 16:00 UTC -- this was the > > time and date that matched most of the most active EPEL drivers when the > > EPEL SIG was quite small. > > > > Well, we have grown a bit, so we should probably re-discuss the meeting > > time again. So what date and time would you guys people prefer? > > I'd plead for another day. > > According to http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > Mon/Wed/Fri is completely free. Perhaps Wed makes most sense and the > since the time slots of fesco and fpc were really narrowed to these > two trying to keep nightfall over the Pacific I'd suggest one of > them. > > E.g. > > Wed 17:00 UTC or > Wed 18:00 UTC I cant do that time. It would need to be between 23:00-3:00 UTC or 11:30-12:30 UTC or on the weekends. Dennis From Axel.Thimm at ATrpms.net Sun Mar 11 18:44:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 11 Mar 2007 19:44:18 +0100 Subject: IRC Meetings: New meeting time? In-Reply-To: <200703111320.00736.dennis@ausil.us> References: <45F43E92.9050501@leemhuis.info> <20070311180947.GR507@neu.nirvana> <200703111320.00736.dennis@ausil.us> Message-ID: <20070311184418.GS507@neu.nirvana> On Sun, Mar 11, 2007 at 01:20:00PM -0500, Dennis Gilmore wrote: > Once upon a time Sunday 11 March 2007, Axel Thimm wrote: > > On Sun, Mar 11, 2007 at 06:38:26PM +0100, Thorsten Leemhuis wrote: > > > The EPEL SIG currently meets each Sunday at 16:00 UTC -- this was the > > > time and date that matched most of the most active EPEL drivers when the > > > EPEL SIG was quite small. > > > > > > Well, we have grown a bit, so we should probably re-discuss the meeting > > > time again. So what date and time would you guys people prefer? > > > > I'd plead for another day. > I cant do that time. OK, we've had a similar situation at the FPC and Toshio created a nice wiki page to coordinate the best time slot. The original page is http://fedoraproject.org/wiki/Packaging/NewMeetingTime I cloned it, made some FPC -> EPEL adjustments and removed the entries from the FPC members: http://fedoraproject.org/wiki/EPEL/NewMeetingTime It also happens that this page had the summer UTC times, since we're about to switch I left the summer data. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sun Mar 11 18:55:36 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 11 Mar 2007 13:55:36 -0500 Subject: IRC Meetings: New meeting time? In-Reply-To: <20070311184418.GS507@neu.nirvana> References: <45F43E92.9050501@leemhuis.info> <200703111320.00736.dennis@ausil.us> <20070311184418.GS507@neu.nirvana> Message-ID: <200703111355.41191.dennis@ausil.us> Once upon a time Sunday 11 March 2007, Axel Thimm wrote: > On Sun, Mar 11, 2007 at 01:20:00PM -0500, Dennis Gilmore wrote: > > Once upon a time Sunday 11 March 2007, Axel Thimm wrote: > > > On Sun, Mar 11, 2007 at 06:38:26PM +0100, Thorsten Leemhuis wrote: > > > > The EPEL SIG currently meets each Sunday at 16:00 UTC -- this was the > > > > time and date that matched most of the most active EPEL drivers when > > > > the EPEL SIG was quite small. > > > > > > > > Well, we have grown a bit, so we should probably re-discuss the > > > > meeting time again. So what date and time would you guys people > > > > prefer? > > > > > > I'd plead for another day. > > > > I cant do that time. > > OK, we've had a similar situation at the FPC and Toshio created a nice > wiki page to coordinate the best time slot. The original page is > > http://fedoraproject.org/wiki/Packaging/NewMeetingTime > > I cloned it, made some FPC -> EPEL adjustments and removed the entries > from the FPC members: > > http://fedoraproject.org/wiki/EPEL/NewMeetingTime > > It also happens that this page had the summer UTC times, since we're > about to switch I left the summer data. Well the available times there. I cant do. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 12 17:03:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 12 Mar 2007 18:03:05 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F0F45D.40709@leemhuis.info> References: <45F0F45D.40709@leemhuis.info> Message-ID: <45F587C9.2020603@leemhuis.info> Thorsten Leemhuis schrieb: > find below my take for a "Package maintenance and update policy for > EPEL". You an find it in the wiki at: > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates > > If you spot typos (there are probably still some...) please fix them in > the wiki directly -- that's why the document is there ;-) > > Did I miss anything? Do people like the general direction? The page got some small enhancements, but nothing fundamental changed. I'll take this a rough agreement from the epel-sig for now (?) and will post this to fedora-maintainers for further comments from the rest of the Fedora world. CU thl (?) -- please speak up if you dislike something as people otherwise might soon start to actually act according to this stuff From notting at redhat.com Mon Mar 12 16:57:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Mar 2007 12:57:49 -0400 Subject: IRC Meetings: New meeting time? In-Reply-To: <20070311180947.GR507@neu.nirvana> References: <45F43E92.9050501@leemhuis.info> <20070311180947.GR507@neu.nirvana> Message-ID: <20070312165749.GB21768@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > Well, we have grown a bit, so we should probably re-discuss the meeting > > time again. So what date and time would you guys people prefer? > > I'd plead for another day. While I'll probably never be driving EPEL too much, I'd agree that weekend meetings are awful for me. Bill From fedora at leemhuis.info Mon Mar 12 18:50:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 12 Mar 2007 19:50:21 +0100 Subject: Summary from yesterdays EPEL meeting Message-ID: <45F5A0ED.1070802@leemhuis.info> Also in the wiki at http://fedoraproject.org/wiki/EPEL/Meetings/20070311 = Meeting 20070311 = [[TableOfContents]] == Attending == * dgilmore * mmcgrath (first part only) * nirik * quaid * thl == Summary == * getting RHEL5 on the builders is a priority now as we should use it before we actually tell contributors to "really start now"; dgilmore and mmcgrath will look into this; CentOS5 beta should hopefully be out soon for testing by users, too. * thl reworked the schedule a bit to reflect the current status a bit better * a shortcut for people wanting to branch lots of packages for EPEL might be helpful. Is anybody interested in writing two scripts? Maybe something like this: * a short script that parses owners.list for all your packages by e-mail and writes the list out on a single line (like "random at host.somewhere foo bar foobar") * another script then can be run on the branching machine that takes a string like "EL-4,EL-5 random at host.somewhere foo bar foobar" and then creates owners.epel.list entries for those packages (if they don't exists already; needs to get the description from owners.list) and creates the branches (the cvs admins would need to fill this part) Then we could use a wiki page and a branch method similar to the old Extras method for the EPEL start phase * quaid worked on http://fedoraproject.org/wiki/EPEL/CommunicationPlan ; "what I'm hoping is ... anyone here who knows something that should be in there, just pile it into the page if we get enough info, we'll spin off a stand-alone page for that topic; otherwise it can be covered in short there." * we'll probably remove all those "PLEASE READ: This is currently a being worked on and not yet finished -- consider it a draft and as not yet official" warning from the wiki at end of march. Guys, please review (and fix) what is written there! * some discussion about steering issues that got discussed on the list this week; seems people would like to prefer to stick to the current scheme as long as problems that need to be solved can get solved with an consensus on the list and in the meetings * discuss the meeting time on the list again (discussion kicked off already) Note: there are some takes on the schedule at http://fedoraproject.org/wiki/EPEL/Schedule that could need some help. Anybody for example interested in setting up a epel-release package, that people can install by "rpm -ivh foo.src.rpm" and contains key and repo files for EPEL so it is automatically used by up2date in RHEL 4, yum in RHEL 5 and yum on CentOS 4 + 5? == Full log == {{{ 00:00 * | thl looks around 00:00 < thl> | according to my clock it's EPEL meeting time 00:00 * | quaid kicks daylight savings in the shins 00:00 < thl> | ping dgilmore mmcgrath 00:00 < mmcgrath> | thl: pong 00:00 < thl> | hah 00:01 < thl> | quaid, yeah, we didn't change yet 00:01 < mmcgrath> | we had dst last night so it may be odd for people to get in. 00:01 < thl> | we'll change in two weeks from now 00:01 < thl> | I'm fine moing the meeting time so the effective meeting time stay the same 00:01 * | nirik is here, but also sick and on the phone. ;)_ 00:01 --> | jmbuser (John Babich) has joined #fedora-meeting 00:01 * | thl has some food in the oven that will be read in 15 minutes 00:01 < mmcgrath> | I've got an alarm clock that changes automatically but its at least 7 years old. I woner what will happen this year. 00:03 * | thl wonder if we should start the meeting or wait another hour 00:03 < mmcgrath> | hmm 00:03 < EvilBob> | waiting and hour would be bad 00:04 * | thl wonders if waiting an hour would be the wrong direction 00:04 < thl> | stupid dst changes 00:04 < jmbuser> | EvilBob: so you want to wait an hour? :-) 00:05 < EvilBob> | thl: FDSCo is waiting for the room 00:05 < thl> | EvilBob, k, noted, thx :) 00:05 < thl> | EvilBob, is that a regular meeting? then add it to http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel ;-) 00:06 < thl> | well, then let's start 00:06 < dgilmore> | pong 00:06 < thl> | I updated the schedule a bit 00:06 < thl> | hi dgilmore 00:06 < thl> | the two most important things afaics are: 00:06 < thl> | get RHEL5 onto the builders 00:07 < thl> | so people can actually start 00:07 < thl> | and find some kind oft shortbut for branching for people that have a lot of pacakges 00:07 < thl> | mmcgrath, quaid, do you have access to RHEL5 already? 00:07 < thl> | could you get it onto the builders? 00:07 < thl> | dgilmore, seems quite busy already afaics 00:08 < mmcgrath> | thl: Possibly, I'm waiting to hear back from the cusotmer service people. 00:08 < dgilmore> | thl: there is supposed to be a way using up2date to pull all teh packages i need to work it out. 00:08 < mmcgrath> | Just so the people here know for the future, our licenses have to go through Red Hat's customer service. 00:08 < quaid> | mmcgrath has much better theoretical chance than I do 00:08 * | dgilmore has not used up2date in many years 00:09 < mmcgrath> | and be extra careful about saying you need RHEL entitlements for Fedora not "Fedora Entitlements" Someone about killed me. 00:09 < nirik> | thl: is the centos 5 beta out yet? last time I checked it was not... 00:09 * | dgilmore really wants to just be able to rsync it 00:09 < dgilmore> | nirik: soon 00:09 < thl> | nirik, not yet; it was supposed to be out some days ago but then they delayed it "to fix some more bugs" 00:09 < quaid> | mmcgrath: are you forming an internal group through CS for all Fedora machines? 00:09 < nirik> | also, I think we should require all EL-4 branches to also branch EL-5... we don't want to drop packages in upgrade, do we? 00:09 < thl> | mmcgrath, for now it would be enough to get RHEL5 00:09 < thl> | building against the beta1 sucks 00:10 < thl> | I don't want to tell people to actually start before we have RHEL5 in the buildroots 00:10 < mmcgrath> | quaid: We actually have 150 RHEL licenses (I didn't realize that) 00:10 < thl> | nirik, well, there are some people that moved to core (and thus to RHEL5); we don#t want branches for those 00:10 < nirik> | well, it's also hard to start when you don't have any way of testing it (at least I prefer to be able to test builds on a new release) 00:10 < dgilmore> | mmcgrath: i noticed that the other day 00:11 < mmcgrath> | I'm still trying to get in touch with the right people to see what we can do with them and how to renew, they expire in May currently. 00:11 < thl> | nirik, I think it's okay to build blindly atm 00:11 < thl> | as stuff goes into a testing branch 00:11 < dgilmore> | RHEL 5 rhgb is ugly 00:11 < thl> | and hopefully CentOS5 will be out soon 00:11 < quaid> | mmcgrath: I recently set up a new group for the online services, I'll find the details and fwd. to you 00:11 < mmcgrath> | quaid: danke 00:11 < dgilmore> | thl: hopefully before the end of march 00:12 < thl> | dgilmore, I hope so 00:12 * | dgilmore installed beta2 as a kvm guest last night 00:12 < thl> | so, who takes over the RHEL5 on the builders task? mmcgrath? 00:12 < dgilmore> | thl: im fine with doing it 00:12 < thl> | is it possible to get RHEL5 until next week? 00:13 < mmcgrath> | I'll get the content (rpms) then dgilmore or I will set up the configs. 00:13 < thl> | dgilmore, k, also fine for me :) 00:13 < dgilmore> | i just need to work out the best way to do so and maintain them 00:13 < mmcgrath> | I wonder if we have a TAM or something :-D 00:13 < thl> | dgilmore, mmcgrath, well, is there any chance to get RHEL5 stuff onto the builders by next week? 00:13 < thl> | s/by/during/ 00:14 <-- | FrancescoUgolini has quit ("Quit") 00:14 * | thl looks after his food in the oven 00:14 < dgilmore> | thl: :) it is doable in one way or another 00:15 < mmcgrath> | thl: I think that should be doable, I've been having trouble finding the right email address to contact. 00:15 < thl> | dgilmore, mmcgrath that would be great; thx for your help 00:16 * | thl will leave soon for a while to eat the stuff that cooking 00:16 * | mmcgrath too might have a small interuption this morning 00:17 < thl> | sorry for the trouble 00:17 < mmcgrath> | and there it is, br 00:17 < mmcgrath> | b 00:17 < thl> | the schedule is at http://fedoraproject.org/wiki/EPEL/Schedule 00:17 < thl> | maybe you guys want to talk about other things? 00:17 < thl> | or we stop and meet again next week 00:18 < thl> | what about the steering issues thimm brought up? 00:18 < thl> | should we discuss them now? 00:18 < dgilmore> | there are alot of people not here 00:18 * | thl now afk for a while; sorry 00:18 < dgilmore> | quaid: how goes your work? 00:19 < quaid> | dgilmore: heh, which? for the most part, pretty good 00:19 < dgilmore> | quaid: :) cool anything to report in regards to EPEL 00:20 < quaid> | ah, you mean, on this topic :) 00:21 < quaid> | I haven't found the right people to propose subscriptions for EPEL maintainers 00:21 < dgilmore> | cool 00:21 < nirik> | dgilmore: I see there isn't a epel el5 version in bugzilla... should there be along with el4? or not until we get buildroots, etc spun up and happy? 00:21 < quaid> | I may want to coordinate with mmcgrath and have those added as aspecial subs to the Fedora group 00:22 < dgilmore> | nirik: i asked for it when it was setup and he didint do it 00:22 < nirik> | bummer 00:22 < dgilmore> | i figured ill bug him when RHEL 5 is released as final 00:22 * | quaid had several Firefox crashes while writing up CommunicationPlan, but there is at least a start there now 00:22 < dgilmore> | quaid: possibly 00:23 < quaid> | http://fedoraproject.org/wiki/EPEL/CommunicationPlan 00:23 < quaid> | what I'm hoping is ... 00:23 < quaid> | anyone here who knows something that should be in there, just pile it into the page 00:23 < quaid> | if we get enough info, we'll spin off a stand-alone page for that topic; 00:24 < quaid> | otherwise it can be covered in short there. 00:24 < dgilmore> | sounds good 00:24 * | thl back at the keyboard, with some food besides him 00:25 * | thl will take a closer look at http://fedoraproject.org/wiki/EPEL/CommunicationPlan later 00:25 < quaid> | thl's food is on the keyboard! 00:26 < thl> | btw, when do we plan to remove all those "PLEASE READ: This is currently a being worked on and not yet finished -- consider it a draft and as not yet official" warning from the wiki? 00:26 < dgilmore> | thl: what do you have to eat? 00:26 < nirik> | I would say we could do that when we offically announce and move things from testing to a main repo? 00:27 < quaid> | personally, I need to spend a few hours going over the language clarity, etc., before I want to remove draft warnings :) 00:27 < quaid> | but I'm always wanting to do that, so don't let that hold us back 00:28 < thl> | dgilmore, some pasta 00:28 < dgilmore> | thl: : 00:28 < dgilmore> | ;) yum 00:29 < thl> | quaid, I'd say we should plan to remove those in two or three weeks 00:29 < thl> | quaid, so there is still some time to fix all those stupid typos and grammatical mistakes thl made ;-) 00:29 < quaid> | :) 00:30 < thl> | shall we plan 20070401 as target date for remoal of those warnings? 00:30 < dgilmore> | wy is rhn down again 00:30 < f13> | dgilmore: RHEL5 syncup 00:30 < dgilmore> | thl: sounds good 00:30 < thl> | I can send a mail to the list asking people to look over it 00:30 < dgilmore> | f13: ahh 00:31 < quaid> | new code, too 00:31 < dgilmore> | f13: do you know of anyone we could bug that would let us be able to rsync trees from cvs-int 00:32 < mmcgrath> | Sorry guys I have to scoot, an out of town friend just dropped by :-/ 00:32 < dgilmore> | mmcgrath: have fun 00:32 < thl> | mmcgrath, yeah, have fun! 00:33 < thl> | btw, is anybody willig to work out two small scripts? 00:33 < thl> | so make it a bit easier for dgilmore to branch packages for EPEL? 00:34 < thl> | one script that looks at owners.list for all packages owned by foo 00:34 < thl> | and another script that creates owners.eple.list entries and the branches from a string like "EL-4 foo at bar baz foobar ..." 00:35 < thl> | quaid, btw, what's your take on the steering issues? 00:35 < thl> | should we have a steering committee soon? 00:35 < quaid> | thl: sorry, which? 00:35 < quaid> | oh 00:36 < quaid> | are we prepared to have an election for it? 00:36 < thl> | quaid, I'd say FESCo should appoint people 00:36 < thl> | and then we target for a election three months later 00:37 < nirik> | so all thats just so we can vote on fedora-usermanagement? 00:37 < dgilmore> | thl: if we have one thats how i would say we do it 00:37 < thl> | nirik, well, I think it's a general problem 00:37 < quaid> | thl: that's interesting, in that I don't think FP has a process for that 00:37 < thl> | the question "who decides" in not regulated afaics 00:38 < thl> | I can ask FESCo what they would prefer 00:38 < quaid> | http://fedoraproject.org/wiki/DefiningProjects 00:39 < quaid> | it's the last section 00:39 < thl> | quaid, I'd say we should not make a official project yet 00:39 * | thl takes a look 00:39 < quaid> | right, so to have a steering committee implies formal project 00:40 * | thl wonders why can't we have a SIG that has a steering committee without being a official project 00:40 * | quaid adds anchors and toC to that page 00:40 < quaid> | thl: maybe we can 00:40 < quaid> | thl: in which case, appointment is the form, i guess 00:41 < thl> | quaid, FESCo should be able to regulate it 00:41 < thl> | the question still is if we want one... 00:41 < quaid> | maybe wait until the SIG is too big? 00:42 < thl> | quaid, or until problems that need to be solved can't get solved without an real consensus 00:42 < quaid> | yeah 00:43 < thl> | other opinions? dgilmore, nirik ? 00:43 < nirik> | well, I hate to add a bunch of overhead just to solve one contentious issue... 00:44 < dgilmore> | nirik: indeed 00:44 < nirik> | didn't ensc say fedora-user-mgmt won't work on EL4? we could then remove it for now and let fedora come up with a solution down the road? 00:44 < thl> | nirik, well, having a steering committee might makes things easier sometimes, too 00:44 < dgilmore> | i think if we have a steering committe we are likely to diverge from fedora 00:44 < thl> | nirik, the lates version doesn#t work on EL4 00:44 < thl> | nirik, older ones do 00:44 < dgilmore> | id like to do whatever we can to make sure we dont 00:45 < nirik> | dgilmore: +1 00:45 < dgilmore> | thl: the version in EL-4 should be FC-3's 00:45 < dgilmore> | so it should work 00:46 < thl> | yeah, it should 00:47 < thl> | so we leave this open as see how it envolves over time? 00:48 < nirik> | I think it should be possible to come to some technical consensus... not easily, but it should be possible 00:49 < nirik> | I do see ensc has been putting up ideas for what should be addressed in a replacement, which is good. 00:49 < thl> | k 00:49 < thl> | so anything else? 00:50 < thl> | or shall we adjourn and meet again next week? 00:50 < nirik> | do we want to look at a new meeting time where more of the people from the list can make it? 00:51 < nirik> | might help solve some of the issues if we can get everyone talking... 00:51 < nirik> | s/talking/typing/ 00:51 < thl> | nirik, I asked once on the mailing list if people would like a new meeting time 00:51 < thl> | one or two weeks ago 00:51 < thl> | I got no replay 00:51 < thl> | reply 00:51 < quaid> | we should discuss it on list :) 00:51 < thl> | but I agree, we should ask once again on the list 00:51 < quaid> | now that we all experienced DST pain, it will be back on people's minds 00:52 < nirik> | huh... not sure I ever say it... ok. 00:52 < nirik> | ever saw it. Sorry, cold meds must be affecting my typing. ;) 00:53 < thl> | nirik, I think it was in a meeting summary 00:53 < thl> | so anything else? 00:53 < thl> | or close for today? 00:53 < nirik> | ok, we should post again now about it in it's own post. Can you do that thl ? or would you like me to? 00:53 < dgilmore> | i have nothing else 00:54 < dgilmore> | my time available for meetings is limited 00:54 < dgilmore> | i cant do it during work time 00:54 < thl> | nirik, I'll do 00:54 * | thl will close the meeting in 30 00:54 * | thl will close the meeting in 15 00:55 <-- | jmbuser has left #fedora-meeting ( "Leaving") 00:55 < thl> | -- MARK -- Meeting end 00:55 < thl> | thx guys 00:55 < nirik> | dgilmore: yeah, but after business hours some weeknight might work? 00:56 < nirik> | thanks thl 00:57 < thl> | nirik, thx in the middle of the night for me.... 00:57 < thl> | s/thx/that's/ 00:57 < nirik> | whats your TZ offset? if it's late enough here wouldn't it be your morning? 00:57 * | quaid notes that FDSCo is meeting currently in #fedora-docs 00:57 < thl> | everything later in the evening than FESCo is problematic for me 00:57 < thl> | nirik, UTC-1 00:58 < thl> | nirik, UTC-2 when in two weeks, when we get DST 00:58 < thl> | I'm on the yeboard at round about 6:40 local time in the mornings 00:58 < nirik> | quaid: might suggest switching to here? it's nice to have all the meetings in one place so people can lurk and hear about things they normally don't know about... 00:58 < dgilmore> | nirik: yep but i think its to late for europe 00:58 < quaid> | nirik: it's an ongoing discussion at the moment, actually 00:59 * | thl really likes #fedora-meeting -- that way one gets a chance to look what the others are discussing 00:59 < dgilmore> | thl: :) yep i like it to }}} From mschwendt.tmp0701.nospam at arcor.de Mon Mar 12 19:59:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 12 Mar 2007 20:59:26 +0100 Subject: Summary from yesterdays EPEL meeting In-Reply-To: <45F5A0ED.1070802@leemhuis.info> References: <45F5A0ED.1070802@leemhuis.info> Message-ID: <20070312205926.ba4a161f.mschwendt.tmp0701.nospam@arcor.de> On Mon, 12 Mar 2007 19:50:21 +0100, Thorsten Leemhuis wrote: > 00:25 < quaid> | thl's food is on the keyboard! Below the 'V' key to be precise. ;o) From tburke at redhat.com Mon Mar 12 20:36:25 2007 From: tburke at redhat.com (Tim Burke) Date: Mon, 12 Mar 2007 16:36:25 -0400 Subject: EPEL acceptance policy Message-ID: <45F5B9C9.30502@redhat.com> Hi, I was just checking out the acceptance policy listed here: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates There's a few acceptance criteria that I think it would help to blatantly spell out there. Perhaps this is really nit points and could be safely assumed, but I think it doesn't hurt to spell things out. I think the intention is to not ship in EPEL stuff which RH already ships. Specifically this is stated as: "Thus packages from EPEL should never replace packages from the target base distribution" I'm wondering if people may misinterpret that to think that things not on the base RHEL isos are fair game for replacement. Layered products from RH which are delivered separately from the OS come to mind. Another example would be packages which are only intended for certain release variants. For example, the GFS cluster components are not available to desktop / client configurations - server only. Tying to think of an alternative recommended wording: "thus packages from EPEL should never replace packages delivered by Red Hat - including those on the base distribution as well as layered products." From smooge at gmail.com Mon Mar 12 22:01:49 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 12 Mar 2007 16:01:49 -0600 Subject: EPEL acceptance policy In-Reply-To: <45F5B9C9.30502@redhat.com> References: <45F5B9C9.30502@redhat.com> Message-ID: <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> On 3/12/07, Tim Burke wrote: > Hi, > > I was just checking out the acceptance policy listed here: > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates > > There's a few acceptance criteria that I think it would help to > blatantly spell out there. Perhaps this is really nit points and could > be safely assumed, but I think it doesn't hurt to spell things out. > > I think the intention is to not ship in EPEL stuff which RH already > ships. Specifically this is stated as: "Thus packages from EPEL should > never replace packages from the target base distribution" > > I'm wondering if people may misinterpret that to think that things not > on the base RHEL isos are fair game for replacement. Layered products > from RH which are delivered separately from the OS come to mind. > Another example would be packages which are only intended for certain > release variants. For example, the GFS cluster components are not > available to desktop / client configurations - server only. > > Tying to think of an alternative recommended wording: > > "thus packages from EPEL should never replace packages delivered by Red > Hat - including those on the base distribution as well as layered products." > Well the one problem I can see that is a bootstrap problem.. if RHEL picks up some subset of EPEL packages for its own subchannel. However, that is really nitpicking something to death. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tburke at redhat.com Mon Mar 12 22:39:23 2007 From: tburke at redhat.com (Tim Burke) Date: Mon, 12 Mar 2007 18:39:23 -0400 Subject: EPEL acceptance policy In-Reply-To: <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> References: <45F5B9C9.30502@redhat.com> <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> Message-ID: <45F5D69B.5050105@redhat.com> Stephen John Smoogen wrote: > > Well the one problem I can see that is a bootstrap problem.. if RHEL > picks up some subset of EPEL packages for its own subchannel. However, > that is really nitpicking something to death. > > Good point. In this case I think the package would naturally stop evolving in EPEL, as the incentive for inclusion would be removed. However, that transition (exit?) would be purely voluntary on the part of the EPEL pkg maintainer ... as RH isn't going to "force" it. Similarly, what to do if a package is included in RHEL5 but not in RHEL4. I would think its fair game for EPEL to build the RHEL4 version but not the RHEL5 version. From mastahnke at gmail.com Tue Mar 13 01:29:55 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 12 Mar 2007 20:29:55 -0500 Subject: EPEL acceptance policy In-Reply-To: <45F5D69B.5050105@redhat.com> References: <45F5B9C9.30502@redhat.com> <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> <45F5D69B.5050105@redhat.com> Message-ID: <7874d9dd0703121829r7c1f5dcdw98c7c43ab34313da@mail.gmail.com> Does CentOS or another distro recompile/package the other RH channels that are not RHEL? I mean, if EPEL is people looking for best-effort supported packges, might they want the application server under best-effort rather than through a pay channel? I am not saying we should replace the channels, really I am mostly curious. MIKE On 3/12/07, Tim Burke wrote: > Stephen John Smoogen wrote: > > > > Well the one problem I can see that is a bootstrap problem.. if RHEL > > picks up some subset of EPEL packages for its own subchannel. However, > > that is really nitpicking something to death. > > > > > Good point. In this case I think the package would naturally stop > evolving in EPEL, as the incentive for inclusion would be removed. > However, that transition (exit?) would be purely voluntary on the part > of the EPEL pkg maintainer ... as RH isn't going to "force" it. > > Similarly, what to do if a package is included in RHEL5 but not in > RHEL4. I would think its fair game for EPEL to build the RHEL4 version > but not the RHEL5 version. > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From mmcgrath at redhat.com Tue Mar 13 02:09:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 12 Mar 2007 21:09:53 -0500 Subject: EPEL acceptance policy In-Reply-To: <7874d9dd0703121829r7c1f5dcdw98c7c43ab34313da@mail.gmail.com> References: <45F5B9C9.30502@redhat.com> <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> <45F5D69B.5050105@redhat.com> <7874d9dd0703121829r7c1f5dcdw98c7c43ab34313da@mail.gmail.com> Message-ID: <45F607F1.9020506@redhat.com> Michael Stahnke wrote: > Does CentOS or another distro recompile/package the other RH channels > that are not RHEL? I mean, if EPEL is people looking for best-effort > supported packges, might they want the application server under > best-effort rather than through a pay channel? I am not saying we > should replace the channels, really I am mostly curious. I'm not touching that with a ten-foot pole. IMO if it ships in any version RHEL-x, it doesn't ship in EPEL-x. -Mike From mastahnke at gmail.com Tue Mar 13 03:20:40 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 12 Mar 2007 22:20:40 -0500 Subject: EPEL acceptance policy In-Reply-To: <45F607F1.9020506@redhat.com> References: <45F5B9C9.30502@redhat.com> <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> <45F5D69B.5050105@redhat.com> <7874d9dd0703121829r7c1f5dcdw98c7c43ab34313da@mail.gmail.com> <45F607F1.9020506@redhat.com> Message-ID: <7874d9dd0703122020n3ef94d34yb898dfb7a16aba9f@mail.gmail.com> That's probably the correct answer Mike. Consider my question/comment/mail withdrawn. On 3/12/07, Mike McGrath wrote: > Michael Stahnke wrote: > > Does CentOS or another distro recompile/package the other RH channels > > that are not RHEL? I mean, if EPEL is people looking for best-effort > > supported packges, might they want the application server under > > best-effort rather than through a pay channel? I am not saying we > > should replace the channels, really I am mostly curious. > I'm not touching that with a ten-foot pole. IMO if it ships in any > version RHEL-x, it doesn't ship in EPEL-x. > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From mastahnke at gmail.com Tue Mar 13 03:23:14 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 12 Mar 2007 22:23:14 -0500 Subject: Summary from yesterdays EPEL meeting In-Reply-To: <20070312205926.ba4a161f.mschwendt.tmp0701.nospam@arcor.de> References: <45F5A0ED.1070802@leemhuis.info> <20070312205926.ba4a161f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <7874d9dd0703122023i48e832c3h2bbebf8ad2d7391a@mail.gmail.com> >Anybody for example interested in setting up >a epel-release package, that people can install by "rpm -ivh >foo.src.rpm" and contains key and repo files for EPEL so it is >automatically used by up2date in RHEL 4, yum in RHEL 5 and yum on CentOS >4 + 5? Sure, let me give it a whirl. Can I have until Sunday, or is that too late? On 3/12/07, Michael Schwendt wrote: > On Mon, 12 Mar 2007 19:50:21 +0100, Thorsten Leemhuis wrote: > > > 00:25 < quaid> | thl's food is on the keyboard! > > Below the 'V' key to be precise. ;o) > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From mastahnke at gmail.com Tue Mar 13 05:08:31 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 13 Mar 2007 00:08:31 -0500 Subject: Summary from yesterdays EPEL meeting In-Reply-To: <7874d9dd0703122023i48e832c3h2bbebf8ad2d7391a@mail.gmail.com> References: <45F5A0ED.1070802@leemhuis.info> <20070312205926.ba4a161f.mschwendt.tmp0701.nospam@arcor.de> <7874d9dd0703122023i48e832c3h2bbebf8ad2d7391a@mail.gmail.com> Message-ID: <7874d9dd0703122208j414e5cc6nab6f5be9fc190f40@mail.gmail.com> I started working on the epel-release package tonight. I have a few questions. How do I handle the yum dependency? RHEL 4 doesn't ship with yum. CentOS 4 does. Do I say it requires Yum in RHEL 4 or just use up2date? How will the testing repo be laid out? Will it have a separate GPG key like Core did/does? When will the yum repo be built for epel? I wrote a .repo file but right now it sees no repomd.xml which means either I am way wrong or it's not created, and I am hoping it's the latter. Will epel have any logo, documetnation or anything I should include in the doc directory other than a license file? How about any type of eula? I really don't want an eula, but IANAL. From fedora at leemhuis.info Tue Mar 13 05:59:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 13 Mar 2007 06:59:09 +0100 Subject: EPEL acceptance policy In-Reply-To: <45F5B9C9.30502@redhat.com> References: <45F5B9C9.30502@redhat.com> Message-ID: <45F63DAD.4090107@leemhuis.info> On 12.03.2007 21:36, Tim Burke wrote: > [...] > Tying to think of an alternative recommended wording: > > "thus packages from EPEL should never replace packages delivered by Red > Hat - including those on the base distribution as well as layered products." I'm fine with that mostly, but I have one big problem: I (and other probably as well) might simply don't know what "layered products from RH which are delivered separately from the OS" exists at all. CU thl From fedora at leemhuis.info Tue Mar 13 06:02:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 13 Mar 2007 07:02:48 +0100 Subject: Summary from yesterdays EPEL meeting In-Reply-To: <7874d9dd0703122208j414e5cc6nab6f5be9fc190f40@mail.gmail.com> References: <45F5A0ED.1070802@leemhuis.info> <20070312205926.ba4a161f.mschwendt.tmp0701.nospam@arcor.de> <7874d9dd0703122023i48e832c3h2bbebf8ad2d7391a@mail.gmail.com> <7874d9dd0703122208j414e5cc6nab6f5be9fc190f40@mail.gmail.com> Message-ID: <45F63E88.80003@leemhuis.info> Hi! On 13.03.2007 06:08, Michael Stahnke wrote: > I started working on the epel-release package tonight. Thanks for your help. > I have a few > questions. How do I handle the yum dependency? RHEL 4 doesn't ship > with yum. CentOS 4 does. Do I say it requires Yum in RHEL 4 or just > use up2date? Hmmm. I tend to think we can safely assume people have yum or up2date installed. If somebody is using smart then we can start shipping smart repo files in the packages, too. > How will the testing repo be laid out? There is something in: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates > Will it have a separate GPG key like Core did/does? I'm quite sure that we'll use the same key. > When will the yum repo be built for epel? I wrote a .repo file but > right now it sees no repomd.xml which means either I am way wrong or > it's not created, and I am hoping it's the latter. It's there http://download.fedora.redhat.com/pub/epel/5/i386/repodata/ > Will epel have any logo, Not for now I should say. > documetnation or anything I should include in > the doc directory other than a license file? How about any type of > eula? I really don't want an eula, but IANAL. I'd say go without docs for now -- or is anybody willing to write something up? Maybe just copy a bit of stuff from the wiki and point to the wiki for more informations might be enough already. Ohh, and I don't think we need a eula (quiad, speak up if we need one). CU th? From wtogami at redhat.com Tue Mar 13 21:18:59 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 13 Mar 2007 17:18:59 -0400 Subject: EPEL acceptance policy In-Reply-To: <45F5B9C9.30502@redhat.com> References: <45F5B9C9.30502@redhat.com> Message-ID: <45F71543.2010701@redhat.com> Tim Burke wrote: > I'm wondering if people may misinterpret that to think that things not > on the base RHEL isos are fair game for replacement. Layered products > from RH which are delivered separately from the OS come to mind. > Another example would be packages which are only intended for certain > release variants. For example, the GFS cluster components are not > available to desktop / client configurations - server only. > > Tying to think of an alternative recommended wording: > > "thus packages from EPEL should never replace packages delivered by Red > Hat - including those on the base distribution as well as layered > products." A few months ago Daniel Riek, Jesse Keating and theorized an easy to understand policy to recommend for EPEL. Layered products themselves are not duplicated in EPEL. EPEL provides layer repos that are built upon and require a corresponding RHEL layer. (these are not actual layer names, just examples) EPEL5 Bar requires RHEL5 Bar EPEL5 Foo requires RHEL5 Foo EPEL5 requires RHEL5 base Where the user chooses to use an EPEL layer, they must have the underlying layer from some source. Red Hat cannot stop an external project from building clone layers. This layered repo recommendation tries to be a clearly understood and fair compromise that recognizes this reality. I hope EPEL can accept something like this as in the EPEL5 policies. Warren Togami wtogami at redhat.com From buildsys at fedoraproject.org Wed Mar 14 11:29:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Mar 2007 07:29:18 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-03-14 Message-ID: <20070314112918.C4B6B152130@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW cfengine-2.1.22-1.el5 eggdrop-1.6.18-7.el5 NEW libsmbios-0.13.4-1.el5.1 NEW pastebin-0.50-3.el5 rpmlint-0.79-1.el5 Packages built and released for Fedora EPEL 4: 13 NEW cfengine-2.1.22-1.el4 eggdrop-1.6.18-7.el4 NEW libsmbios-0.13.4-1.el4.1 NEW nagios-plugins-1.4.6-3.el4 nfswatch-4.99.8-1.el4 NEW nrg2iso-0.4-2.el4 NEW pastebin-0.50-3.el4 NEW perl-Algorithm-Diff-1.1902-2.el4 perl-SOAP-Lite-0.68-5.el4 NEW perl-Text-Diff-0.35-3.el4 rpmlint-0.79-1.el4 NEW ssmtp-2.61-11.1.el4 NEW tcpxtract-1.0.1-7.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dag at wieers.com Wed Mar 14 11:49:13 2007 From: dag at wieers.com (Dag Wieers) Date: Wed, 14 Mar 2007 12:49:13 +0100 (CET) Subject: Repotag Message-ID: Hi, Could you please add a repotag to your EPEL packages ? I know you guys think you have enough authority to not require a repotag. And you generally do not care because the default policy will be to tell people other packages than EPEL are dangerous. (look at the release to identify a package) But by not tagging your packages, you take advantage of the fact that other repositories play nice and *do* tag their packages. But what will happen if I (and other repositories) start doing the same thing and drop the repotag ? I don't know if I have to start threaten to make you see the light, but I strongly consider dropping the repotag if Fedora and Red Hat cannot play nice. Thanks for taking notice. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dennis at ausil.us Wed Mar 14 12:08:31 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Mar 2007 07:08:31 -0500 Subject: Repotag In-Reply-To: References: Message-ID: <200703140708.36342.dennis@ausil.us> Once upon a time Wednesday 14 March 2007, Dag Wieers wrote: > Hi, > > Could you please add a repotag to your EPEL packages ? We do we use .elX as has been defined in the Fedora guidelines since it was started > I know you guys think you have enough authority to not require a repotag. > And you generally do not care because the default policy will be to tell > people other packages than EPEL are dangerous. (look at the release to > identify a package) > > But by not tagging your packages, you take advantage of the fact that > other repositories play nice and *do* tag their packages. > > But what will happen if I (and other repositories) start doing the same > thing and drop the repotag ? you are free to use .elX also that is perfectly ok. if you do i would ask that you set the Vendor tag. which you probably already do. If you do a rpm -qi on a epel package you will get something like rpm -qip nagios-2.7-2.el4.x86_64.rpm warning: nagios-2.7-2.el4.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 217521f6 Name : nagios Relocations: (not relocatable) Version : 2.7 Vendor: Fedora Project Release : 2.el4 Build Date: Tue 06 Feb 2007 01:16:24 PM EST Install Date: (not installed) Build Host: xenbuilder1.fedora.redhat.com Group : Applications/System Source RPM: nagios-2.7-2.el4.src.rpm Size : 4434495 License: GPL Signature : DSA/SHA1, Fri 02 Mar 2007 06:23:16 PM EST, Key ID 119cc036217521f6 Packager : Fedora Project URL : http://www.nagios.org/ Summary : Host/service/network monitoring program > I don't know if I have to start threaten to make you see the light, but I > strongly consider dropping the repotag if Fedora and Red Hat cannot play > nice. Seriously feel free to use the same disttag as we use. Please help me to understand better what it is that you want to achieve and what exactly you mean by tagging packages. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Wed Mar 14 12:27:57 2007 From: dag at wieers.com (Dag Wieers) Date: Wed, 14 Mar 2007 13:27:57 +0100 (CET) Subject: Repotag In-Reply-To: <200703140708.36342.dennis@ausil.us> References: <200703140708.36342.dennis@ausil.us> Message-ID: On Wed, 14 Mar 2007, Dennis Gilmore wrote: > Once upon a time Wednesday 14 March 2007, Dag Wieers wrote: > > Hi, > > > > Could you please add a repotag to your EPEL packages ? > > We do we use .elX as has been defined in the Fedora guidelines since it was > started That's what we call a disttag. It identifies for what distribution something is build. (Even though it is not enforced, this helps people that dowxnload and install packages manually) A disttag doesn't say where a package comes from. A repotag does. And even when that doesn't guarantee anything as anyone can fake that, just like the disttag, it helps people to identify who to report problems too. Or helps to identify who's responsible from command-line output. > > I know you guys think you have enough authority to not require a repotag. > > And you generally do not care because the default policy will be to tell > > people other packages than EPEL are dangerous. (look at the release to > > identify a package) > > > > But by not tagging your packages, you take advantage of the fact that > > other repositories play nice and *do* tag their packages. > > > > But what will happen if I (and other repositories) start doing the same > > thing and drop the repotag ? > > you are free to use .elX also that is perfectly ok. if you do i would ask > that you set the Vendor tag. which you probably already do. Sure, the vendor tag however is not seen from copy&pasted yum output. ANd is harder to grep for when doing package lists. (although not entirely impossible, but that's not the point here) > > I don't know if I have to start threaten to make you see the light, but I > > strongly consider dropping the repotag if Fedora and Red Hat cannot play > > nice. > > Seriously feel free to use the same disttag as we use. Please help me to > understand better what it is that you want to achieve and what exactly you > mean by tagging packages. [dag at rhun ~]# ls -l /dar/packages/nagios/*el*2.8* -rw-r--r-- 3 root root 35592 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el3.rf.i386.rpm -rw-r--r-- 3 root root 35575 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el3.rf.x86_64.rpm -rw-r--r-- 3 root root 35606 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el4.rf.i386.rpm -rw-r--r-- 3 root root 35580 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el4.rf.x86_64.rpm -rw-r--r-- 3 root root 37123 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el5.rf.i386.rpm -rw-r--r-- 3 root root 37027 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el5.rf.x86_64.rpm -rw-r--r-- 3 root root 35554 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.rh9.rf.i386.rpm Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From fedora at leemhuis.info Wed Mar 14 14:11:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Mar 2007 15:11:52 +0100 Subject: Repotag In-Reply-To: References: Message-ID: <45F802A8.4010205@leemhuis.info> Hi! On 14.03.2007 12:49, Dag Wieers wrote: > Could you please add a repotag to your EPEL packages ? > [...] I don't care much about having a repotag or not: I'm fine going with or without one. I think this decision is in the hands of the Fedora Packaging Committee, as that was set in place to maintain packaging guidelines across the different Fedora repositories -- that was Core and Extras in the past, now it's the Fedora Repository and EPEL afaics. I talked to some members of the Packaging Committee on IRC. Seems a repotag is unwanted. I can accept that. If somebody inside or outside EPEL or Fedora dislikes that it's best to bring this issue up on the Packaging Committee list fedora-packaging: https://www.redhat.com/archives/fedora-packaging/ I can forward the issue there, too, but I'm not going to advocate for either side in this game (?). Those that care have to do that themselves. CU thl (?) -- the only thing I'll advocate for on is having this problem solved once for all of Fedora, and as such it's IMHO in the hands of the Packaging Committe (thus this mail). From mmcgrath at redhat.com Wed Mar 14 17:04:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 14 Mar 2007 12:04:50 -0500 Subject: Time to go live? Message-ID: <45F82B32.4010500@redhat.com> We still have mentions of test only and "not meant for public consumption" Should I send an official announcement to the announce-list and get this party started? -Mike From smooge at gmail.com Wed Mar 14 17:25:55 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 14 Mar 2007 11:25:55 -0600 Subject: EPEL acceptance policy In-Reply-To: <45F5D69B.5050105@redhat.com> References: <45F5B9C9.30502@redhat.com> <80d7e4090703121501v47f3d11cs1db08c00b42e0938@mail.gmail.com> <45F5D69B.5050105@redhat.com> Message-ID: <80d7e4090703141025o6c7970f5x865af32f851adec1@mail.gmail.com> On 3/12/07, Tim Burke wrote: > Stephen John Smoogen wrote: > > > > Well the one problem I can see that is a bootstrap problem.. if RHEL > > picks up some subset of EPEL packages for its own subchannel. However, > > that is really nitpicking something to death. > > > > > Good point. In this case I think the package would naturally stop > evolving in EPEL, as the incentive for inclusion would be removed. > However, that transition (exit?) would be purely voluntary on the part > of the EPEL pkg maintainer ... as RH isn't going to "force" it. > > Similarly, what to do if a package is included in RHEL5 but not in > RHEL4. I would think its fair game for EPEL to build the RHEL4 version > but not the RHEL5 version. > Working on qa'ing the Centos-4.92 build.. I ran into a similar issue. Upgrading from 3.8 or 4.4 leaves around 148 'orphans' on a system. I am expecting that some of those might be candidates for EPEL-5.x as people like squirrelmail etc. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From fedora at leemhuis.info Wed Mar 14 17:27:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Mar 2007 18:27:52 +0100 Subject: Time to go live? In-Reply-To: <45F82B32.4010500@redhat.com> References: <45F82B32.4010500@redhat.com> Message-ID: <45F83098.3040907@leemhuis.info> Mike McGrath schrieb: > We still have mentions of test only and "not meant for public > consumption" Should I send an official announcement to the > announce-list and get this party started? I'd say a definite "no" as long as we don't have the "big picture" stuff from the schedule done. E.g. * RHEL5 on the builders * our Package Maintain and Updates policy in place * the final repo layout on the servers * a release rpm-package so people can actually use our stuff * Finish the wiki (remove "This is currently a being worked on and not yet finished" warnings ) I'd further prefer to have at least a bit more packages in the repo before announcing it. All that could be done in less then two weeks if we really want... CU thl From icon at fedoraproject.org Wed Mar 14 17:28:52 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 14 Mar 2007 13:28:52 -0400 Subject: Can I play? Message-ID: Hello, everyone: I'd like to participate in the EPEL process, since I'm responsible for a bunch of RHEL4 servers and figure that since I already rebuild a bunch of stuff from extras, I might as well share my efforts. :) I'll follow the discussions for a few days, just to get a hang of things, since the wiki is a little short on details at the moment. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From mmcgrath at redhat.com Wed Mar 14 17:51:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 14 Mar 2007 12:51:19 -0500 Subject: Time to go live? In-Reply-To: <45F83098.3040907@leemhuis.info> References: <45F82B32.4010500@redhat.com> <45F83098.3040907@leemhuis.info> Message-ID: <45F83617.8050008@redhat.com> Thorsten Leemhuis wrote: > Mike McGrath schrieb: > >> We still have mentions of test only and "not meant for public >> consumption" Should I send an official announcement to the >> announce-list and get this party started? >> > > I'd say a definite "no" as long as we don't have the "big picture" stuff > from the schedule done. E.g. > > * RHEL5 on the builders > * our Package Maintain and Updates policy in place > * the final repo layout on the servers > * a release rpm-package so people can actually use our stuff > * Finish the wiki (remove "This is currently a being worked on and not > yet finished" warnings ) > > I'd further prefer to have at least a bit more packages in the repo > before announcing it. All that could be done in less then two weeks if > we really want... > > Then we need to take the public mirror down or do something with it because people are reading "not ready for public" yet there it is. -Mike From mastahnke at gmail.com Wed Mar 14 23:51:08 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 14 Mar 2007 18:51:08 -0500 Subject: Time to go live? In-Reply-To: <45F83617.8050008@redhat.com> References: <45F82B32.4010500@redhat.com> <45F83098.3040907@leemhuis.info> <45F83617.8050008@redhat.com> Message-ID: <7874d9dd0703141651j725468afr415d8f8df6341489@mail.gmail.com> On 3/14/07, Mike McGrath wrote: > Thorsten Leemhuis wrote: > > Mike McGrath schrieb: > > > >> We still have mentions of test only and "not meant for public > >> consumption" Should I send an official announcement to the > >> announce-list and get this party started? > >> > > > > I'd say a definite "no" as long as we don't have the "big picture" stuff > > from the schedule done. E.g. > > > > * RHEL5 on the builders > > * our Package Maintain and Updates policy in place > > * the final repo layout on the servers > > * a release rpm-package so people can actually use our stuff > > * Finish the wiki (remove "This is currently a being worked on and not > > yet finished" warnings ) > > > > I'd further prefer to have at least a bit more packages in the repo > > before announcing it. All that could be done in less then two weeks if > > we really want... > > > > > Then we need to take the public mirror down or do something with it > because people are reading "not ready for public" yet there it is. I don't think we can take it down if people are testing. (For example when working on the right config for epel-release.) > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From Axel.Thimm at ATrpms.net Thu Mar 15 01:16:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 02:16:46 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F0F45D.40709@leemhuis.info> References: <45F0F45D.40709@leemhuis.info> Message-ID: <20070315011646.GA22805@neu.nirvana> On Fri, Mar 09, 2007 at 06:45:01AM +0100, Thorsten Leemhuis wrote: > kernel-modules further are not allowed, as they can disturb the base > kernel easily. Are we sure we really want that? The same argument applies to any daemon as well, and kernel modules are considered an added value by most RHEL consumers (but not RHEL kernel developers ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Mar 15 01:21:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 02:21:26 +0100 Subject: IRC Meetings: New meeting time? In-Reply-To: <20070312165749.GB21768@nostromo.devel.redhat.com> References: <45F43E92.9050501@leemhuis.info> <20070311180947.GR507@neu.nirvana> <20070312165749.GB21768@nostromo.devel.redhat.com> Message-ID: <20070315012126.GB22805@neu.nirvana> On Mon, Mar 12, 2007 at 12:57:49PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > Well, we have grown a bit, so we should probably re-discuss the meeting > > > time again. So what date and time would you guys people prefer? > > > > I'd plead for another day. > > While I'll probably never be driving EPEL too much, I'd agree that weekend > meetings are awful for me. And it will be awful with many RHEL people, especially professionals that will have RHEL/EPEL support in their job description and would like to deal with EPEL from Mo-Fr. We'd like to attract ISVs to put their people as (co)maintainers on packages in EPEL. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mastahnke at gmail.com Thu Mar 15 04:24:05 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 14 Mar 2007 23:24:05 -0500 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <20070315011646.GA22805@neu.nirvana> References: <45F0F45D.40709@leemhuis.info> <20070315011646.GA22805@neu.nirvana> Message-ID: <7874d9dd0703142124o691064a2lf6e56c14a9680133@mail.gmail.com> On 3/14/07, Axel Thimm wrote: > On Fri, Mar 09, 2007 at 06:45:01AM +0100, Thorsten Leemhuis wrote: > > kernel-modules further are not allowed, as they can disturb the base > > kernel easily. > > Are we sure we really want that? The same argument applies to any > daemon as well, and kernel modules are considered an added value by > most RHEL consumers (but not RHEL kernel developers ;) If I have to start loading kernel modules into my RHEL system to do what I need, I probably need Fedora. Otherwise I have just overpaid for a box that is no longer supported and I am trying to use in ways likely not all that entperprise focused. I'm sure there are exceptions, like wireless drivers and maybe advanced nic or storage controllers, but those are usually in RHEL after an update or two. I know if I was an RH developer, I wouldn't want kernel modules, and as a RHEL customers I think it sounds risky at best. > -- > Axel.Thimm at ATrpms.net > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > I know if I was an RH developer, I wouldn't want kernel modules, and as a RHEL customers I think it sounds risky at best. --MIKE > > From fedora at leemhuis.info Thu Mar 15 05:36:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Mar 2007 06:36:30 +0100 Subject: Time to go live? In-Reply-To: <45F83617.8050008@redhat.com> References: <45F82B32.4010500@redhat.com> <45F83098.3040907@leemhuis.info> <45F83617.8050008@redhat.com> Message-ID: <45F8DB5E.6060109@leemhuis.info> Mike McGrath schrieb: > Thorsten Leemhuis wrote: >> Mike McGrath schrieb: >> >>> We still have mentions of test only and "not meant for public >>> consumption" Should I send an official announcement to the >>> announce-list and get this party started? >>> >> I'd say a definite "no" as long as we don't have the "big picture" stuff >> from the schedule done. E.g. >> >> * RHEL5 on the builders >> * our Package Maintain and Updates policy in place >> * the final repo layout on the servers >> * a release rpm-package so people can actually use our stuff >> * Finish the wiki (remove "This is currently a being worked on and not >> yet finished" warnings ) >> >> I'd further prefer to have at least a bit more packages in the repo >> before announcing it. All that could be done in less then two weeks if >> we really want... > Then we need to take the public mirror down or do something with it > because people are reading "not ready for public" yet there it is. I asked dgilmore to put everything in a testing directory to make it more obvious that EPEL is not live yet. He did that iirc, but it seems the mirror scripts didn't take it up properly. CU thl From fedora at leemhuis.info Thu Mar 15 05:46:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Mar 2007 06:46:14 +0100 Subject: IRC Meetings: New meeting time? In-Reply-To: <20070315012126.GB22805@neu.nirvana> References: <45F43E92.9050501@leemhuis.info> <20070311180947.GR507@neu.nirvana> <20070312165749.GB21768@nostromo.devel.redhat.com> <20070315012126.GB22805@neu.nirvana> Message-ID: <45F8DDA6.9050701@leemhuis.info> Axel Thimm schrieb: > On Mon, Mar 12, 2007 at 12:57:49PM -0400, Bill Nottingham wrote: >> Axel Thimm (Axel.Thimm at ATrpms.net) said: >>>> Well, we have grown a bit, so we should probably re-discuss the meeting >>>> time again. So what date and time would you guys people prefer? >>> I'd plead for another day. >> While I'll probably never be driving EPEL too much, I'd agree that weekend >> meetings are awful for me. > And it will be awful with many RHEL people, especially professionals > that will have RHEL/EPEL support in their job description and would > like to deal with EPEL from Mo-Fr. We'd like to attract ISVs to put > their people as (co)maintainers on packages in EPEL. Agreed in general, but first EPEL must finally lift of (see my other mail from yesterday in the "Time to go live thread") before they can get involved. And it seems to me that the Sunday meeting time is fine for the key people that are working on getting EPEL running properly (e.g. getting the infrastructure in place -- docs in the wiki, buildsys for EPEL, repo setup, polcies, cvs, scripts, ...). So my 2 cent: I'd prefer to stick to the Sunday meeting time or an alternative time that the key drivers agree on over loosing the key drivers. After EPEL has taken of and all the crucial bits are in place try to find a different time for the meetings. CU thl From fedora at leemhuis.info Thu Mar 15 05:52:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Mar 2007 06:52:21 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <20070315011646.GA22805@neu.nirvana> References: <45F0F45D.40709@leemhuis.info> <20070315011646.GA22805@neu.nirvana> Message-ID: <45F8DF15.2080200@leemhuis.info> Axel Thimm schrieb: > On Fri, Mar 09, 2007 at 06:45:01AM +0100, Thorsten Leemhuis wrote: >> kernel-modules further are not allowed, as they can disturb the base >> kernel easily. > Are we sure we really want that? I think so. Red Hat asked patiently for this, too, but I had this on my list beforehand anyway. > The same argument applies to any > daemon as well, I'd like to disagree. Userland processes are clearly separated from each other normally. But each kernel module has access to the whole kernel space and can do a whole lot of damage everywhere -- on purpose or accidentally. That often is not obvious in error messages and thus a big problem for debugging. > and kernel modules are considered an added value by > most RHEL consumers (but not RHEL kernel developers ;) I'm sure there will be another repo soon where add-on kernel modules for EL-Distributions will find a home. CU thl From greg at runlevel7.ca Thu Mar 15 06:19:31 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Wed, 14 Mar 2007 23:19:31 -0700 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F0F45D.40709@leemhuis.info> References: <45F0F45D.40709@leemhuis.info> Message-ID: <45F8E573.5070609@runlevel7.ca> Thorsten Leemhuis wrote: > == Policy == > > EPEL packages should only enhance and never disturb the Enterprise > Linux distributions the packages were build for. Thus packages from > EPEL should never replace packages from the base distribution they get > build against; kernel-modules further are not allowed, as they can > disturb the base kernel easily. > > The Packages in the Repository should if possible get maintained in > similar ways like the packages get maintained in the Enterprise Linux > Distribution they get build against. In other words: have a mostly > stable set of packages that normally does not change at all and only > changes if there are good reasons for changes. > > The changes that cant be avoided get routed into different release > trees. Only updates that fix important bugs (say: data-corruption, > security problems, really annoying bugs) go to a testing branch for a > short time period and then build a second time for the stable branch; > those people that sign and push the EPEL packages to the public repo > will skim over the list of updated packages for the stable repo to > make sure that sure the goal "only important updates for the stable > branch" is fulfilled. > > Other updates get queued up in a testing repository over time. That > repository becomes the new stable branch in parallel with the > quarterly update that get released by the Linux Distributor that > creates the Enterprise Linux the packages gets build against. There > will be a short freeze time period before the quarterly update happens > to make sure the repo and its packages are in a good shape. But even > this updates should be limited to fixes only as far as possible and > should be tested in Fedora beforehand if possible. Updated Packages > that change the ABI or require config file adjustments must be avoided > if somehow possible. Compat- Packages that provide the old ABI need to > be provided in the repo if there is no way around a package update > that changes the ABI. > The discussion about repotag's makes me think we will soon see some of the same packages in 2 or 3 different repositories. I would hope all the packagers can work together and not duplicate each others efforts, but I guess that's not always possible due to different preferences in having the latest versus the more stable, or other differences of opinion. Anyways, as a start, I would suggest adding something like this to the 'Policy' section a paragraph suggesting maintainers of EPEL packages take in to account existing packages for EL4/5 from RPMforge, ATrpms, etc: "Before creating an EPEL branch for a package, maintainers should check if the package is available from RPMForge, ATrpms, or CentOS Extras (and others??). If that is the case, it would be best to consider that many thousands of users may have that package installed already on their EL4/EL5 systems. Maintainers should inform the other packager of their intention to create the EPEL branch, and include them in any discussion regarding the package. It is also recommended to ensure that the EPEL package is a compatible upgrade from the other package, while still ensuring the Fedora packaging guidelines are followed." Does that sound reasonable? Greg From pertusus at free.fr Thu Mar 15 08:47:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Mar 2007 09:47:39 +0100 Subject: RFC: Package maintenance and update policy for EPEL -- take 1 In-Reply-To: <45F8E573.5070609@runlevel7.ca> References: <45F0F45D.40709@leemhuis.info> <45F8E573.5070609@runlevel7.ca> Message-ID: <20070315084739.GA2855@free.fr> On Wed, Mar 14, 2007 at 11:19:31PM -0700, Greg Swallow wrote: > > "Before creating an EPEL branch for a package, maintainers should check > if the package is available from RPMForge, ATrpms, or CentOS Extras > (and others??). If that is the case, it would be best to consider that > many thousands of users may have that package installed already on their > EL4/EL5 systems. Maintainers should inform the other packager of their > intention to create the EPEL branch, and include them in any discussion > regarding the package. It is also recommended to ensure that the EPEL > package is a compatible upgrade from the other package, while still > ensuring the Fedora packaging guidelines are followed." > > Does that sound reasonable? It sounds reasonable to me, and important. But it would be even better if people running third party repos were invited to join EPEL. If I'm not wrong it is already the case for ATrpms and CentOS Extras. It also seems to me that Centos Extras is special since it uses the same base than EPEL. I don't know exactly what could be the implication, but maybe something automatic could be done (like when it appears on EPEL the Centos Extras build may be disabled). -- Pat From dag at wieers.com Thu Mar 15 12:16:09 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 15 Mar 2007 13:16:09 +0100 (CET) Subject: Repotag In-Reply-To: <45F802A8.4010205@leemhuis.info> References: <45F802A8.4010205@leemhuis.info> Message-ID: On Wed, 14 Mar 2007, Thorsten Leemhuis wrote: > On 14.03.2007 12:49, Dag Wieers wrote: > > Could you please add a repotag to your EPEL packages ? > > [...] > > I don't care much about having a repotag or not: I'm fine > going with or without one. > > I think this decision is in the hands of the Fedora Packaging Committee, > as that was set in place to maintain packaging guidelines across the > different Fedora repositories -- that was Core and Extras in the past, > now it's the Fedora Repository and EPEL afaics. > > I talked to some members of the Packaging Committee on IRC. Seems a > repotag is unwanted. I can accept that. If somebody inside or outside > EPEL or Fedora dislikes that it's best to bring this issue up on the > Packaging Committee list fedora-packaging: > https://www.redhat.com/archives/fedora-packaging/ > > I can forward the issue there, too, but I'm not going to advocate for > either side in this game (?). Those that care have to do that themselves. The problem is not a Fedora one. Since Fedora is considered a distribution and the distribution never has a repotag. EPEL is not part of the distribution and therefor does require a repotag to identify where packages come from. At least if you believe in the purpose of a repotag. If you don't and cannot envision what would happen if no repository ever had a repotag, then there lies the problem. If I hadn't a repotag, my nagios-packages would be numbered the same as the EPEL packages. Including the same release tag. If people then have problems, nobody could tell from the output whether this was an EPEL, non-EPEL, RPMforge or other package. The only reason why EPEL now can 'assume' that this is an EPEL package is because most of the other players play nice and use a repotag. For that reason EPEL should have a repotag. It is as much a community-member as the other repositories. This is an EPEL issue, not a Fedora issue. Why could there not be a rule that says Fedora packages do not have a repotag, but EPEL packages will ? Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mmcgrath at redhat.com Thu Mar 15 13:36:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 15 Mar 2007 08:36:26 -0500 Subject: Repotag In-Reply-To: References: <45F802A8.4010205@leemhuis.info> Message-ID: <45F94BDA.2070404@redhat.com> Dag Wieers wrote: > If I hadn't a repotag, my nagios-packages would be numbered the same as > the EPEL packages. Including the same release tag. If people then have > problems, nobody could tell from the output whether this was an EPEL, > non-EPEL, RPMforge or other package. > I can think of a couple ways to figure this out, none of which are very difficult. Buildhost, vendor, packager, and key signature come to mind. > This is an EPEL issue, not a Fedora issue. Why could there not be a rule > that says Fedora packages do not have a repotag, but EPEL packages will ? > Because its just one more thing to maintain/change/whatever that so far has only one supporter. -Mike From dag at wieers.com Thu Mar 15 17:25:03 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 15 Mar 2007 18:25:03 +0100 (CET) Subject: Repotag In-Reply-To: <45F94BDA.2070404@redhat.com> References: <45F802A8.4010205@leemhuis.info> <45F94BDA.2070404@redhat.com> Message-ID: On Thu, 15 Mar 2007, Mike McGrath wrote: > Dag Wieers wrote: > > If I hadn't a repotag, my nagios-packages would be numbered the same as the > > EPEL packages. Including the same release tag. If people then have problems, > > nobody could tell from the output whether this was an EPEL, non-EPEL, > > RPMforge or other package. > > I can think of a couple ways to figure this out, none of which are very > difficult. Buildhost, vendor, packager, and key signature come to mind. You can't tell all that from a posting on a forum. The problem is not that you can get that information from somewhere, the problem is that you have to have more communication via email/forums to get that information. > > This is an EPEL issue, not a Fedora issue. Why could there not be a rule > > that says Fedora packages do not have a repotag, but EPEL packages will ? > > Because its just one more thing to maintain/change/whatever that so far has > only one supporter. Fine, RPMforge will be dropping the repotag as well. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From greg at runlevel7.ca Thu Mar 15 17:34:26 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Thu, 15 Mar 2007 10:34:26 -0700 Subject: Repotag In-Reply-To: <45F94BDA.2070404@redhat.com> Message-ID: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> Mike McGrath wrote: > Dag Wieers wrote: > > If I hadn't a repotag, my nagios-packages would be numbered the same as > > the EPEL packages. Including the same release tag. If people then have > > problems, nobody could tell from the output whether this was an EPEL, > > non-EPEL, RPMforge or other package. > > > I can think of a couple ways to figure this out, none of which are very > difficult. Buildhost, vendor, packager, and key signature come to mind. What about if you don't have the package installed? If you have a failed 'yum upgrade' and are trying to figure out what's happening you only see the name/arch/epoch/version/release while it's resolving dependancies and if Dag takes away the repotag, using his example, 'yum list nagios' would show that 2 versions of nagios named identically are available. > > This is an EPEL issue, not a Fedora issue. Why could there not be a rule > > that says Fedora packages do not have a repotag, but EPEL packages will > ? > > > Because its just one more thing to maintain/change/whatever that so far > has only one supporter. You can add me as a supporter even just for the reason of keeping Dag happy. If you want everyone to work together (Dag, ATrpms, CentOS, EPEL) then respecting each others concerns is a good start. Adding %{repotag} is really not that big of a deal, is it? Greg From Axel.Thimm at ATrpms.net Thu Mar 15 17:42:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 18:42:37 +0100 Subject: Repotag In-Reply-To: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> References: <45F94BDA.2070404@redhat.com> <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> Message-ID: <20070315174237.GS25860@neu.nirvana> On Thu, Mar 15, 2007 at 10:34:26AM -0700, Greg Swallow wrote: > Mike McGrath wrote: > > Dag Wieers wrote: > > > If I hadn't a repotag, my nagios-packages would be numbered the same > as > > > the EPEL packages. Including the same release tag. If people then > have > > > problems, nobody could tell from the output whether this was an > EPEL, > > > non-EPEL, RPMforge or other package. > > > > > I can think of a couple ways to figure this out, none of which are > very > > difficult. Buildhost, vendor, packager, and key signature come to > mind. > > What about if you don't have the package installed? If you have a > failed 'yum upgrade' and are trying to figure out what's happening you > only see the name/arch/epoch/version/release while it's resolving > dependancies and if Dag takes away the repotag, using his example, 'yum > list nagios' would show that 2 versions of nagios named identically are > available. > > > > This is an EPEL issue, not a Fedora issue. Why could there not be a > rule > > > that says Fedora packages do not have a repotag, but EPEL packages > will > > ? > > > > > Because its just one more thing to maintain/change/whatever that so > far > > has only one supporter. > > You can add me as a supporter even just for the reason of keeping Dag > happy. If you want everyone to work together (Dag, ATrpms, CentOS, > EPEL) then respecting each others concerns is a good start. Adding > %{repotag} is really not that big of a deal, is it? FWIW I would support it, too, and it's even easier than defining %repotag, just define %disttag to be "el5.epel" or similar. E.g for ATrpms I use disttags like "fc6.at", "el5.at" etc. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From p.r.schaffner at larc.nasa.gov Thu Mar 15 12:44:42 2007 From: p.r.schaffner at larc.nasa.gov (Phil Schaffner) Date: Thu, 15 Mar 2007 08:44:42 -0400 Subject: Repotag In-Reply-To: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> References: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> Message-ID: <1173962682.5364.3.camel@c5.larc.nasa.gov> On Thu, 2007-03-15 at 10:34 -0700, Greg Swallow wrote: > You can add me as a supporter even just for the reason of keeping Dag > happy. If you want everyone to work together (Dag, ATrpms, CentOS, > EPEL) then respecting each others concerns is a good start. Adding > %{repotag} is really not that big of a deal, is it? +1 A "Red Hat community" standard on this would avoid a lot of confusion on the part of users who have enabled multiple repos, and would lead to fewer problems being incorrectly reported to the wrong maintainers/packagers. Phil Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Thu Mar 15 18:10:03 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 15 Mar 2007 14:10:03 -0400 Subject: Repotag In-Reply-To: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> References: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> Message-ID: <45F98BFB.5030702@redhat.com> Greg Swallow wrote: > Mike McGrath wrote: >> Dag Wieers wrote: >>> If I hadn't a repotag, my nagios-packages would be numbered the same > as >>> the EPEL packages. Including the same release tag. If people then > have >>> problems, nobody could tell from the output whether this was an > EPEL, >>> non-EPEL, RPMforge or other package. >>> >> I can think of a couple ways to figure this out, none of which are > very >> difficult. Buildhost, vendor, packager, and key signature come to > mind. > > What about if you don't have the package installed? If you have a > failed 'yum upgrade' and are trying to figure out what's happening you > only see the name/arch/epoch/version/release while it's resolving > dependancies and if Dag takes away the repotag, using his example, 'yum > list nagios' would show that 2 versions of nagios named identically are > available. Not a good example. The repo the package is in is listed in the output of yum list. # yum list kernel Loading "installonlyn" plugin Installed Packages kernel.ia64 2.6.20-2.2975.bz231219 installed kernel.ia64 2.6.20-1.2966.fc7 installed Available Packages kernel.ia64 2.6.20-1.2987.fc7 development >>> This is an EPEL issue, not a Fedora issue. Why could there not be a > rule >>> that says Fedora packages do not have a repotag, but EPEL packages > will >> ? >> Because its just one more thing to maintain/change/whatever that so > far >> has only one supporter. > > You can add me as a supporter even just for the reason of keeping Dag > happy. If you want everyone to work together (Dag, ATrpms, CentOS, > EPEL) then respecting each others concerns is a good start. Adding > %{repotag} is really not that big of a deal, is it? I'm sort of up in the air on this one. Fedora Extras is, er, was, an official project endorsed by RH, had no repotag, and EPEL is just an extension of this same project. Since its an official repo, it requires no repotag to identify the package. Of course, Fedora and RHEL are a wee bit different, and making the distinction that's easy to see at a glance between core RHEL packages and EPEL-for-RHEL certainly does have some merit that it doesn't have (or didn't when Extras was separate) in Fedora-land. It would likely be of help to RH support if they could tell if a package was from RHEL-proper or from EPEL without having to look anything up... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From greg at runlevel7.ca Thu Mar 15 18:37:35 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Thu, 15 Mar 2007 11:37:35 -0700 Subject: Repotag In-Reply-To: <45F98BFB.5030702@redhat.com> Message-ID: <5B8B3D66554D0246BF6D224D9E8169E00328536D@snshbea106.4smartphone.snx> Jarod Wilson wrote: > Not a good example. The repo the package is in is listed in the output > of yum list. > > # yum list kernel > Loading "installonlyn" plugin > Installed Packages > kernel.ia64 2.6.20-2.2975.bz231219 installed > kernel.ia64 2.6.20-1.2966.fc7 installed > Available Packages > kernel.ia64 2.6.20-1.2987.fc7 development Yes, but if dag and epel had the same package name/version/release (and no repotag) you might see: Available Packages nagios.i386 2.8-1.el4 dag nagios.i386 2.8-1.el4 epel If a yum upgrade fails while looking for a dependency of nagios, the output wouldn't tell you if it was the dag or epel package it was trying to install. > I'm sort of up in the air on this one. Fedora Extras is, er, was, an > official project endorsed by RH, had no repotag, and EPEL is just an > extension of this same project. Since its an official repo, it requires > no repotag to identify the package. That attitude doesn't seem to be conducive to getting everyone to work together. Remember Dag has been providing "EPEL" packages for years now. (Thanks Dag!) And I don't know if the RHEL support department would use the word "official". Sounds too much like a synonym of "100% safe and fully supported" maybe ;-) > Of course, Fedora and RHEL are a wee > bit different, and making the distinction that's easy to see at a glance > between core RHEL packages and EPEL-for-RHEL certainly does have some > merit that it doesn't have (or didn't when Extras was separate) in > Fedora-land. It would likely be of help to RH support if they could tell > if a package was from RHEL-proper or from EPEL without having to look > anything up... Yup, that's a good reason to add a repotag too. Greg From Axel.Thimm at ATrpms.net Thu Mar 15 18:40:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Mar 2007 19:40:18 +0100 Subject: RHEL5 builder content? Message-ID: <20070315184018.GT25860@neu.nirvana> Hi, this may have been documented somewhere, or perhaps discussed here, but I can't find it: What "repo" is used for the RHEL5 builds? Server, client or the sum or both? If it's the sum are you using *two* licenses for creating the repo? If it's open for debate I would argue that we should have the sum, e.g. the complete RHEL5 as a base. For reference: packages (as of today) that only exist in the server: Cluster_Administration-5.0.0-5 clustermon-0.8-27.el5 compat-gcc-295-2.95.3-85 conga-0.8-30.el5 elilo-3.6-2 gfs-kmod-0.1.16-5.2.6.18_8.1.1.el5 gfs-kmod-0.1.16-5.2.6.18_8.el5 gfs-utils-0.1.11-1.el5 Global_File_System-5.0.0-4 gnbd-1.1.5-1.el5 gnbd-kmod-0.1.3-4.2.6.18_8.1.1.el5 gnbd-kmod-0.1.3-4.2.6.18_8.el5 iprutils-2.1.5-3 ipvsadm-1.24-8.1 libica-1.3.7-5.el5 librtas-1.2.4-3.el5 libunwind-0.98.5-3 lvm2-cluster-2.02.16-3.el5 openssl-ibmca-1.0.0.rc2-1.el5.3 piranha-0.8.4-7.el5 ppc64-utils-0.11-2 prctl-1.4-5.2.1 redhat-release-5Server-5.0.0.9 redhat-release-notes-5Server-5 rgmanager-2.0.23-1 s390utils-1.5.3-10.el5.6 salinfo-1.1-2.el5 system-config-cluster-1.0.39-1.0 yaboot-1.3.13-3.el5 and such only existing for the client: compiz-0.0.13-0.36.20060817git.el5 ekiga-2.0.2-7 evolution-2.8.0-33.el5 evolution-connector-2.8.0-3.fc6 evolution-webcal-2.7.1-6 fribidi-0.10.7-5.1 gaim-2.0.0-0.28.beta5.el5 gnome-games-2.16.0-1.fc6 gnome-pilot-2.0.13-16 gnome-pilot-conduits-2.0.13-7.el5 gnome-spell-1.0.7-3.1 gnome-user-share-0.10-6.el5 hsqldb-1.8.0.4-3jpp.4 jpilot-0.99.8-7.1 k3b-0.12.17-1.el5 kdeaddons-3.5.4-1.fc6 kdegames-3.5.4-1.fc6 kdegraphics-3.5.4-1.fc6 kdemultimedia-3.5.4-2.fc6 kdepim-3.5.4-4.fc6 launchmail-4.0.0-1.el5 libgpod-0.4.0-1.el5 libsilc-1.0.2-2.fc6 libwpd-0.8.6-1 nautilus-sendto-0.7-5.fc6 opal-2.2.2-1.1 openoffice.org-2.0.4-5.4.17 perl-Archive-Zip-1.16-1.2.1 pilot-link-0.11.8-16 planner-0.14-3 pwlib-1.10.1-7.el5 python-imaging-1.1.5-5.el5 redhat-release-5Client-5.0.0.9 redhat-release-notes-5Client-5 rhythmbox-0.9.5-8.el5 scribus-1.3.3.2-3.el5 taskjuggler-2.2.0-3 thunderbird-1.5.0.9-6.el5 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Thu Mar 15 18:48:00 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 15 Mar 2007 14:48:00 -0400 Subject: Repotag In-Reply-To: <5B8B3D66554D0246BF6D224D9E8169E00328536D@snshbea106.4smartphone.snx> References: <5B8B3D66554D0246BF6D224D9E8169E00328536D@snshbea106.4smartphone.snx> Message-ID: <45F994E0.5080101@redhat.com> Greg Swallow wrote: > Jarod Wilson wrote: >> Not a good example. The repo the package is in is listed in the output >> of yum list. >> >> # yum list kernel >> Loading "installonlyn" plugin >> Installed Packages >> kernel.ia64 2.6.20-2.2975.bz231219 installed >> kernel.ia64 2.6.20-1.2966.fc7 installed >> Available Packages >> kernel.ia64 2.6.20-1.2987.fc7 development > > Yes, but if dag and epel had the same package name/version/release (and > no repotag) you might see: > > Available Packages > nagios.i386 2.8-1.el4 dag > nagios.i386 2.8-1.el4 epel > > If a yum upgrade fails while looking for a dependency of nagios, the > output wouldn't tell you if it was the dag or epel package it was trying > to install. True. >> I'm sort of up in the air on this one. Fedora Extras is, er, was, an >> official project endorsed by RH, had no repotag, and EPEL is just an >> extension of this same project. Since its an official repo, it > requires >> no repotag to identify the package. > > That attitude doesn't seem to be conducive to getting everyone to work > together. There would be that. > Remember Dag has been providing "EPEL" packages for years > now. (Thanks Dag!) Yep, I know. Used some of 'em in a previous life on RH7.3 and RHEL3 systems. > And I don't know if the RHEL support department would use the word > "official". Sounds too much like a synonym of "100% safe and fully > supported" maybe ;-) Exactly the point I was making below. >> Of course, Fedora and RHEL are a wee >> bit different, and making the distinction that's easy to see at a > glance >> between core RHEL packages and EPEL-for-RHEL certainly does have some >> merit that it doesn't have (or didn't when Extras was separate) in >> Fedora-land. It would likely be of help to RH support if they could > tell >> if a package was from RHEL-proper or from EPEL without having to look >> anything up... > > Yup, that's a good reason to add a repotag too. However, I believe support typically asks people to get them the output from the sysreport tool, which could be easily modified to add %vendor to the rpm listing it outputs (currently does %n-%v-%r-%arch). -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tla at rasmil.dk Fri Mar 16 12:25:43 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 16 Mar 2007 13:25:43 +0100 Subject: Repotag In-Reply-To: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> References: <5B8B3D66554D0246BF6D224D9E8169E003285313@snshbea106.4smartphone.snx> Message-ID: <45FA8CC7.8030502@rasmil.dk> > You can add me as a supporter even just for the reason of keeping Dag > happy. If you want everyone to work together (Dag, ATrpms, CentOS, > EPEL) then respecting each others concerns is a good start. Adding > %{repotag} is really not that big of a deal, is it? > +1 From pertusus at free.fr Fri Mar 16 13:12:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 14:12:03 +0100 Subject: Repotag In-Reply-To: References: <45F802A8.4010205@leemhuis.info> Message-ID: <20070316131203.GF2923@free.fr> On Thu, Mar 15, 2007 at 01:16:09PM +0100, Dag Wieers wrote: > > The problem is not a Fedora one. Since Fedora is considered a distribution > and the distribution never has a repotag. EPEL is not part of the > distribution and therefor does require a repotag to identify where > packages come from. It seems to me that EPEL is meant to be more than 'a community-member as the other repositories'. I am not saying that it is good or bad, but it seems to me that EPEL has the same hegemonic purpose Fedora Extras once had (and still has). Even though it is distinct from RHEL, it is meant to be the only big third party repo. That's my interpretation at least. I am biased toward considering that it is a good idea to have only one big repo, but I am open to other views. It certainly has pros and cons. The main argument in favor of having only one repo is that there is less confusion for the users, and less duplication of work. The argument against this approach is that the 'design' of the repo may be different, and also that it adds competition. Fedora Extras succeded in some way, since, in my opinion there is a lot of quality packaging and packagers that have found their way in it, including Matthias and Axel. The EPEL extension is a proof of that too. It didn't completly succeed, however since some packagers are still outside, especially you and dries. Back to the repotag issue, it seems to me to be fair to consider EPEL to be special and don't need a repotag, based on the fedora extras success. It would also be fair to treat other repos equally and provide a repotag since the fedora extras experience shows that other repos still coexist. The must, in my opinion, would be a peacefull merge with existing repos, packaging quality would certainly improve, and only new repos would use repotags, but (sadly in my opinion) history shows that it is not that likely to happen. -- Pat From buildsys at fedoraproject.org Fri Mar 16 20:28:39 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 16 Mar 2007 16:28:39 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-03-16 Message-ID: <20070316202839.5B6F4152130@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 8 NEW dclib-0.3.8-1.el5 NEW firmware-addon-dell-1.2.2-1.el5 NEW firmware-tools-1.2.3-1.el5 NEW naim-0.11.8.3-1.el5 NEW nethack-3.4.3-12.el5 NEW pork-0.99.8.1-6.el5 NEW python-cherrypy-2.2.1-6.el5 NEW xprobe2-0.3-8.el5 Packages built and released for Fedora EPEL 4: 5 NEW firmware-addon-dell-1.2.2-1.el4 NEW firmware-tools-1.2.3-1.el4 nas-1.8-13.el4 NEW perl-YAML-0.62-3.el4 qt4-4.2.3-3.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dlutter at redhat.com Fri Mar 16 23:24:36 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 16 Mar 2007 16:24:36 -0700 Subject: rpms that just need a rebuild... In-Reply-To: <45EE55C7.5090705@runlevel7.ca> References: <45EE55C7.5090705@runlevel7.ca> Message-ID: <1174087476.10131.13.camel@localhost.localdomain> On Tue, 2007-03-06 at 22:03 -0800, Greg Swallow wrote: > I admit I haven't been following all the EPEL discussion that closely, > so sorry if this has been brought up before... Just to be really late to the party: > But I was wondering if there is room in the plans for a "EPEL-unstable" > repository (or something like that), which is just an automatic rebuild > of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms > for EL5 that I just rebuilt from the Fedora Extras 6 sources - no > modifications to the spec files needed. It would be very interesting to have a uniform way to provide RHEL-addon packages that are unsupported. This would help people who want to evaluate things on RHEL that are available on Fedora, but aren't in a state that can be supported by EPEL's or RHEL's standards. I would like to point people to a standard repo for those things, and have them know that the packages were built in a sane way (because they went through the build system) w/o making any guarantees in terms of API stability etc. What I, and I suspect others, do right now is to build such packages whichever way we see fit, and then push them to a custom yum repo on people.redhat.com or et.redhat.com or ... As a case in point, I rebuild several of the packages I maintain for Fedora for RHEL4 and RHEL5, and people seem to be using them. This is particularly useful for RHEL4, where the rebuild might require small tweaks to the specfile. David From rtlm10 at gmail.com Sat Mar 17 05:40:26 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Sat, 17 Mar 2007 01:40:26 -0400 Subject: RHEL5 builder content? In-Reply-To: <20070315184018.GT25860@neu.nirvana> References: <20070315184018.GT25860@neu.nirvana> Message-ID: <1ed4a0130703162240xe1be228u5aeae606b80ffb7d@mail.gmail.com> On 3/15/07, Axel Thimm wrote: > > Hi, > > this may have been documented somewhere, or perhaps discussed here, > but I can't find it: What "repo" is used for the RHEL5 builds? Server, > client or the sum or both? If it's the sum are you using *two* > licenses for creating the repo? If it's open for debate I would argue > that we should have the sum, e.g. the complete RHEL5 as a base. This is a really good point. It even breaks down further when you look at client. From the totally useless desktop only entitlement (no emacs is still a sore spot for me) to the nearly complete desktop + workstation + virt. In the situation you've outlined packages would just fail the depsolver on systems without the correct entitlements. Not pretty, but maintaining multiple repos to account for the different Red Hat channels would be a ton of work. What I didn't get a clean picture on is what Red Hat's strategy around client would be. If they plan to be a little more forthcoming with updates on the client release (which they probably should) it means some of the common packages between client and server will fall out of sync. So even while a package in EPEL will build on each system the same package may not run on both because the linked in packages will be different. A client, server split would make since in that situation. We asked about this quite some time ago but Red Hat hasn't given us the final word on this yet. Probably because they still haven't decided how they'll handle the situation yet. Does anyone have a better picture now that RHEL-5 is out the door? Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From Axel.Thimm at ATrpms.net Sat Mar 17 18:38:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Mar 2007 19:38:14 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <1174087476.10131.13.camel@localhost.localdomain> References: <45EE55C7.5090705@runlevel7.ca> <1174087476.10131.13.camel@localhost.localdomain> Message-ID: <20070317183814.GD11578@neu.nirvana> On Fri, Mar 16, 2007 at 04:24:36PM -0700, David Lutterkort wrote: > On Tue, 2007-03-06 at 22:03 -0800, Greg Swallow wrote: > > I admit I haven't been following all the EPEL discussion that closely, > > so sorry if this has been brought up before... > > Just to be really late to the party: > > > But I was wondering if there is room in the plans for a "EPEL-unstable" > > repository (or something like that), which is just an automatic rebuild > > of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms > > for EL5 that I just rebuilt from the Fedora Extras 6 sources - no > > modifications to the spec files needed. > > It would be very interesting to have a uniform way to provide RHEL-addon > packages that are unsupported. This would help people who want to > evaluate things on RHEL that are available on Fedora, but aren't in a > state that can be supported by EPEL's or RHEL's standards. Then better massage them to meet those standards? Of course, you still need to define what those standards are, which is somehow blurry ATM. We all have a feeling when a Fedora package is suitable for RHEL or not, but there are no criteria written down as of yet. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Sun Mar 18 13:43:27 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 18 Mar 2007 14:43:27 +0100 (CET) Subject: [users] Dropping the repotag Message-ID: Hi, Maybe the below discussion could help introduce the repotag in EPEL. Please let me know when the repotag will be decided for EPEL, so I know when to unleash hell :) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] ---------- Forwarded message ---------- From: Dag Wieers To: Andreas Rogge Cc: RPMforge , Nicolas Thierry-Mieg Date: Sun, 18 Mar 2007 14:37:12 +0100 (CET) Subject: Re: [users] Dropping the repotag On Sun, 18 Mar 2007, Andreas Rogge wrote: > On Sat, 17 Mar 2007, Dag Wieers wrote: > > On Sat, 17 Mar 2007, Andreas Rogge wrote: > > > > > What if you could use for example "listrpms --vendor RPMForge" > > > instead of "rpm -qa | grep rf" and get a 100% result without > > > false-positives? > > > > It will not tell you which nagios-2.8-4.el5 breaks a dependency chain. > > Was it the one from EPEL or the one from RPMforge ? Both have the > > exact same release. > > > > yum doesn't say, you cannot query it because it is not installed. > > Hell, since both have the same filename you won't even know by querying the > > repositories. > > > > This is not solvable unless you either improve yum to report all other > > information (including keys and/or other tags), which still doesn't > > fix all the other tools and is plain confusing. Or if you make the > > filename more unique, which is what the repotag does. > > > > BTW rpm -qa | grep '\.rf$' is pretty conclusive _if_ everybody follows > > the same standard and you require packages to be signed. > > > > BTW2 Dissing the repotag usefulness is like dissing the disttag > > usefulness. It is as arbitrary, makes the release longer and is in > > essence not required. Still it has its use. > > First of all: yes, you're right. > > But we will face this issue with EPEL. A repotag will not help to blame > EPEL when something breaks (they don't have one). It will only help to > blame RPMForge (as RPMforge has one). That's why EPEL should have one. At least until something better comes around (if there ever will). People say a repotag should not be in the filename. But a filename is there to identify what it is. The version is there to identify what it is, just like the name and the arch. All of these are not required in the package name. In fact, rename whatever package you have to "this_package" (without the arch, without the extension) and rpm handles that fine, because it doesn't use the information in the filename, it uses the header. So the filename is there for the user to identify what it is. So what's wrong with having the repotag, like the disttag and like the version and name in the filename ? It helps (at least) some people as much as all that other information and it solves a practical problem with yum/rpm and other tools that cannot give all that other information right there when we need it. (and if they would, most people wouldn't understand why the signature or an arbitrary string is there the moment you have a dependency problem). > I don't think repotags should be dropped because they suck. I just think > that they're a workaround for broken/incomplete tools and have been in > place for too long. Hell, neither rpm nor yum nor anything else actually > knows there is something like a repotag. They just display it because we > hijack the package signature. It is a work around. Why else the disttag ? The repotag is arguably as useful as the disttag in the filename. Would you argue against the disttag in the same way ? In fact why have the release there at all. And the architecture ? Most people don't know what that means anyway. > People will need better tools anyway, because nobody will be able to > tell the difference between an EPEL and a base distro package. I think > yum should actually tell you vendor and distro on all packages. The problem is, even when you have 'better' tools, how would they present that information without filling the screen and actually helping to understand the information. The repotag is short and doesn't add as much noise as a signature or an arbitrary string would cause. I don't think it is practically fixable (if anybody would ever care to fix RPM and backport it to EL2.1, EL3, EL4 and now EL5 -> NEVER). So whatever 'better' technical solution you propose, it wouldn't be useful until EL5 is out of support. And not to be kidding, we had this discussion when EL3 was released and you know what: people also said it was not the correct solution. Do we have a correct solution today ? No. Will we have one tomorrow ? No. So why postpone a solution until we have a better one ? Especially when we cannot define what a better solution would look like and we cannot fix the tools. > We already had similar issues on x86_64 where you couldn't tell the > difference between i386 and x86_64 packages. Today yum reports every > package with its arch. Right. So more information is better. How would you ideally present the repository info in the output when there's a problem. The repotag is the most preferred (read: shortest) way IMNSHO. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] _______________________________________________ users mailing list users at lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/users From fedora at leemhuis.info Sun Mar 18 14:06:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 15:06:38 +0100 Subject: [users] Dropping the repotag In-Reply-To: References: Message-ID: <45FD476E.9040306@leemhuis.info> Dag Wieers schrieb: > Maybe the below discussion could help introduce the repotag in EPEL. > > Please let me know when the repotag will be decided for EPEL As I told you in https://www.redhat.com/archives/epel-devel-list/2007-March/msg00242.html Please bring that up to the Fedora Packaging committee on fedora-packaging at redhat.com, those guys are the ones that are responsible for the Packaging Standard used in both EPEL and Fedora. The offer still stands: I can forward this discussion/your mail there if you want. But the only position in this stuff I'll take is "Let the Packaging Committee" decide. Cu thl > ---------- Forwarded message ---------- > From: Dag Wieers > To: Andreas Rogge > Cc: RPMforge , > Nicolas Thierry-Mieg > Date: Sun, 18 Mar 2007 14:37:12 +0100 (CET) > Subject: Re: [users] Dropping the repotag > > On Sun, 18 Mar 2007, Andreas Rogge wrote: > >> On Sat, 17 Mar 2007, Dag Wieers wrote: >>> On Sat, 17 Mar 2007, Andreas Rogge wrote: >>> >>>> What if you could use for example "listrpms --vendor RPMForge" >>>> instead of "rpm -qa | grep rf" and get a 100% result without >>>> false-positives? >>> It will not tell you which nagios-2.8-4.el5 breaks a dependency chain. >>> Was it the one from EPEL or the one from RPMforge ? Both have the >>> exact same release. >>> >>> yum doesn't say, you cannot query it because it is not installed. >>> Hell, since both have the same filename you won't even know by querying the >>> repositories. >>> >>> This is not solvable unless you either improve yum to report all other >>> information (including keys and/or other tags), which still doesn't >>> fix all the other tools and is plain confusing. Or if you make the >>> filename more unique, which is what the repotag does. >>> >>> BTW rpm -qa | grep '\.rf$' is pretty conclusive _if_ everybody follows >>> the same standard and you require packages to be signed. >>> >>> BTW2 Dissing the repotag usefulness is like dissing the disttag >>> usefulness. It is as arbitrary, makes the release longer and is in >>> essence not required. Still it has its use. >> First of all: yes, you're right. >> >> But we will face this issue with EPEL. A repotag will not help to blame >> EPEL when something breaks (they don't have one). It will only help to >> blame RPMForge (as RPMforge has one). > > That's why EPEL should have one. At least until something better comes > around (if there ever will). > > People say a repotag should not be in the filename. But a filename is > there to identify what it is. The version is there to identify what it is, > just like the name and the arch. All of these are not required in the > package name. In fact, rename whatever package you have to "this_package" > (without the arch, without the extension) and rpm handles that fine, > because it doesn't use the information in the filename, it uses the > header. So the filename is there for the user to identify what it is. > > So what's wrong with having the repotag, like the disttag and like the > version and name in the filename ? It helps (at least) some people as much > as all that other information and it solves a practical problem with > yum/rpm and other tools that cannot give all that other information right > there when we need it. (and if they would, most people wouldn't understand > why the signature or an arbitrary string is there the moment you have a > dependency problem). > > >> I don't think repotags should be dropped because they suck. I just think >> that they're a workaround for broken/incomplete tools and have been in >> place for too long. Hell, neither rpm nor yum nor anything else actually >> knows there is something like a repotag. They just display it because we >> hijack the package signature. > > It is a work around. Why else the disttag ? The repotag is arguably as > useful as the disttag in the filename. Would you argue against the disttag > in the same way ? In fact why have the release there at all. And the > architecture ? Most people don't know what that means anyway. > > >> People will need better tools anyway, because nobody will be able to >> tell the difference between an EPEL and a base distro package. I think >> yum should actually tell you vendor and distro on all packages. > > The problem is, even when you have 'better' tools, how would they present > that information without filling the screen and actually helping to > understand the information. The repotag is short and doesn't add as much > noise as a signature or an arbitrary string would cause. > > I don't think it is practically fixable (if anybody would ever care to fix > RPM and backport it to EL2.1, EL3, EL4 and now EL5 -> NEVER). So whatever > 'better' technical solution you propose, it wouldn't be useful until EL5 > is out of support. > > And not to be kidding, we had this discussion when EL3 was released and > you know what: people also said it was not the correct solution. Do we > have a correct solution today ? No. Will we have one tomorrow ? No. > > So why postpone a solution until we have a better one ? Especially when we > cannot define what a better solution would look like and we cannot fix the > tools. > > >> We already had similar issues on x86_64 where you couldn't tell the >> difference between i386 and x86_64 packages. Today yum reports every >> package with its arch. > > Right. So more information is better. How would you ideally present the > repository info in the output when there's a problem. The repotag is the > most preferred (read: shortest) way IMNSHO. > > Kind regards, > -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- > [all I want is a warm bed and a kind word and unlimited power] > _______________________________________________ > users mailing list > users at lists.rpmforge.net > http://lists.rpmforge.net/mailman/listinfo/users > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Sun Mar 18 14:18:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 15:18:49 +0100 Subject: [users] Dropping the repotag In-Reply-To: <45FD476E.9040306@leemhuis.info> References: <45FD476E.9040306@leemhuis.info> Message-ID: <45FD4A49.3030108@leemhuis.info> Thorsten Leemhuis schrieb: > > Please bring that up to the Fedora Packaging committee on > fedora-packaging at redhat.com, those guys are the ones that are > responsible for the Packaging Standard used in both EPEL and Fedora. > > The offer still stands: I can forward this discussion/your mail there if > you want. Done now without waiting for an answer: https://www.redhat.com/archives/fedora-packaging/2007-March/msg00079.html People interested in this discussion please participate there! Cu thl From Axel.Thimm at ATrpms.net Sun Mar 18 16:00:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 17:00:12 +0100 Subject: Dropping the repotag In-Reply-To: <45FD476E.9040306@leemhuis.info> References: <45FD476E.9040306@leemhuis.info> Message-ID: <20070318160012.GB31755@neu.nirvana> On Sun, Mar 18, 2007 at 03:06:38PM +0100, Thorsten Leemhuis wrote: > Dag Wieers schrieb: > > Please let me know when the repotag will be decided for EPEL > > Please bring that up to the Fedora Packaging committee on > fedora-packaging at redhat.com, those guys are the ones that are > responsible for the Packaging Standard used in both EPEL and Fedora. > > The offer still stands: I can forward this discussion/your mail there if > you want. But the only position in this stuff I'll take is "Let the > Packaging Committee" decide. Does the rest of epel agree on this? Or will this be a ping pong of responsibilities? As a member of the FPC I don't see how suddenly we became authorities on EPEL. Not that I personally mind, but I miss the mandate. There still is no voting body to make any decisions around epel when it comes to things like fedora-usrmgmt, repotags and anything else where there is no 100% consensus. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun Mar 18 16:17:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 17:17:07 +0100 Subject: Dropping the repotag In-Reply-To: <20070318160012.GB31755@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <20070318160012.GB31755@neu.nirvana> Message-ID: <45FD6603.2030907@leemhuis.info> Axel Thimm schrieb: > On Sun, Mar 18, 2007 at 03:06:38PM +0100, Thorsten Leemhuis wrote: >> Dag Wieers schrieb: >>> Please let me know when the repotag will be decided for EPEL >> Please bring that up to the Fedora Packaging committee on >> fedora-packaging at redhat.com, those guys are the ones that are >> responsible for the Packaging Standard used in both EPEL and Fedora. >> >> The offer still stands: I can forward this discussion/your mail there if >> you want. But the only position in this stuff I'll take is "Let the >> Packaging Committee" decide. > > Does the rest of epel agree on this? Or will this be a ping pong of > responsibilities? That's why I already asked higher Groups to clarify. https://www.redhat.com/archives/fedora-advisory-board/2007-March/msg00072.html > As a member of the FPC I don't see how suddenly we > became authorities on EPEL. Not that I personally mind, but I miss the > mandate. I think the whole idea was to have one committee that is responsible for packaging in general (e.g. Core and Extras in the past), which IMHO includes EPEL now > [...] Cu thl From mmcgrath at redhat.com Sun Mar 18 17:34:56 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 18 Mar 2007 12:34:56 -0500 Subject: Dropping the repotag In-Reply-To: <45FD6603.2030907@leemhuis.info> References: <45FD476E.9040306@leemhuis.info> <20070318160012.GB31755@neu.nirvana> <45FD6603.2030907@leemhuis.info> Message-ID: <45FD7840.3070902@redhat.com> Thorsten Leemhuis wrote: > Axel Thimm schrieb: > >> On Sun, Mar 18, 2007 at 03:06:38PM +0100, Thorsten Leemhuis wrote: >> >>> Dag Wieers schrieb: >>> >>>> Please let me know when the repotag will be decided for EPEL >>>> >>> Please bring that up to the Fedora Packaging committee on >>> fedora-packaging at redhat.com, those guys are the ones that are >>> responsible for the Packaging Standard used in both EPEL and Fedora. >>> >>> The offer still stands: I can forward this discussion/your mail there if >>> you want. But the only position in this stuff I'll take is "Let the >>> Packaging Committee" decide. >>> >> Does the rest of epel agree on this? Or will this be a ping pong of >> responsibilities? >> > > That's why I already asked higher Groups to clarify. > https://www.redhat.com/archives/fedora-advisory-board/2007-March/msg00072.html > Thats the tricky part. Unfortunately our current governing model is still in extreme infancy. Partly because I think everyone has a different idea of who has what authority and partially because we (all of Fedora) have the ability to keep going forward and moving without these bodies. Actual enforcement powers is difficult and, AFAIK, all of our committees have very foggy powers. Governance is extremely difficult, especially in an environment like Fedora where you can't make anyone do anything. It's also not a very attractive thing to work on. In the past stuff like this has been: Hey, we should have a committee to do this this and this. Response from less than .1% of the community: Buhh, ok, whatever. or Response from less than .1%% of the community: It should do this this and this, NO! It should be this way! No, this way! Then it just kind of gets forgotten about or we end up with a SIG or group and what they actually do and when is very fuzzy. Like the packaging group, do they provide guidelines for our flagship product (the Operating System?) Or for all packages in Fedora. How about the packages we create just for Fedora Infrastructure? Who says? Long story short: I'd love the packaging committee to decide this, they know more about the consequences then I do. At the same time though we need to be prepared for them to say "This isn't our decision, your on your own." /2 cents -Mike From Axel.Thimm at ATrpms.net Sun Mar 18 17:43:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 18:43:43 +0100 Subject: Dropping the repotag In-Reply-To: <45FD7840.3070902@redhat.com> References: <45FD476E.9040306@leemhuis.info> <20070318160012.GB31755@neu.nirvana> <45FD6603.2030907@leemhuis.info> <45FD7840.3070902@redhat.com> Message-ID: <20070318174343.GE31755@neu.nirvana> On Sun, Mar 18, 2007 at 12:34:56PM -0500, Mike McGrath wrote: > Long story short: I'd love the packaging committee to decide this, they > know more about the consequences then I do. There is 99% politics in this decision and about 1% or less of technical points to discuss. The FPC can pick up the technical points, but not the politics. > At the same time though we need to be prepared for them to say "This > isn't our decision, your on your own." I already replied to the post made there in a similar way explaining that the FPC is the one body that tries to focus on purely technical points and can't make the political decision on EPEL's behalf (and perhaps even send w/o knowing EPEL on war with other repos). With my FPC hat on: "Tell us whether you want to mark packages, and we'll tell you how". With my EPEL hat on: "Let's do repotags and keep the peace". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From greg at runlevel7.ca Sun Mar 18 17:56:22 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Sun, 18 Mar 2007 10:56:22 -0700 Subject: [users] Dropping the repotag In-Reply-To: <45FD4A49.3030108@leemhuis.info> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> Message-ID: <45FD7D46.2040506@runlevel7.ca> Thorsten Leemhuis wrote: > Thorsten Leemhuis schrieb: > >> Please bring that up to the Fedora Packaging committee on >> fedora-packaging at redhat.com, those guys are the ones that are >> responsible for the Packaging Standard used in both EPEL and Fedora. >> >> The offer still stands: I can forward this discussion/your mail there if >> you want. >> > > Done now without waiting for an answer: > https://www.redhat.com/archives/fedora-packaging/2007-March/msg00079.html > > People interested in this discussion please participate there! > I already just joined this mailing list, now I need to join another? No thanks, I made my point clear here. Maybe the packaging committee (5-10 people?) could have joined the EPEL list next time a problem like this comes up. On the subject of getting a +1 or -1 from the community. I would say a very, very small percentage of the community is here on this list, and even fewer on the packaging committee list, so if you have even 3 or 4 people saying add the repotag, that's probably a few hundred thousand users. Dag is trying to speak for most of them, as I bet that many use his repo, and I'm trying to speak for maybe 5,000 that use SME Server (an EL4 and soon to be EL5 deriitave). So add 5000 +1's for me please on the other list ;-) Greg From fedora at leemhuis.info Sun Mar 18 18:23:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 19:23:41 +0100 Subject: [users] Dropping the repotag In-Reply-To: <45FD7D46.2040506@runlevel7.ca> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> Message-ID: <45FD83AD.8060109@leemhuis.info> Greg Swallow schrieb: > > I already just joined this mailing list, now I need to join another? > No thanks, I made my point clear here. That's why I forwarded the whole thread there. Cu thl From mschwendt.tmp0701.nospam at arcor.de Sun Mar 18 19:33:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 18 Mar 2007 20:33:44 +0100 Subject: [users] Dropping the repotag In-Reply-To: <45FD7D46.2040506@runlevel7.ca> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> Message-ID: <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> On Sun, 18 Mar 2007 10:56:22 -0700, Greg Swallow wrote: > Thorsten Leemhuis wrote: > > Thorsten Leemhuis schrieb: > > > >> Please bring that up to the Fedora Packaging committee on > >> fedora-packaging at redhat.com, those guys are the ones that are > >> responsible for the Packaging Standard used in both EPEL and Fedora. > >> > >> The offer still stands: I can forward this discussion/your mail there if > >> you want. > >> > > > > Done now without waiting for an answer: > > https://www.redhat.com/archives/fedora-packaging/2007-March/msg00079.html > > > > People interested in this discussion please participate there! > > > I already just joined this mailing list, now I need to join another? > No thanks, I made my point clear here. Maybe the packaging committee > (5-10 people?) could have joined the EPEL list next time a problem like > this comes up. > > On the subject of getting a +1 or -1 from the community. I would say a > very, very small percentage of the community is here on this list, and > even fewer on the packaging committee list, so if you have even 3 or 4 > people saying add the repotag, that's probably a few hundred thousand > users. Dag is trying to speak for most of them, as I bet that many use > his repo, and I'm trying to speak for maybe 5,000 that use SME Server > (an EL4 and soon to be EL5 deriitave). So add 5000 +1's for me please > on the other list ;-) Why would a __user__ want a repotag? All the users want is that repositories "just work" when they are enabled and installed from, even if it is an unusual mix of repositories. A repotag does not contribute anything to achieving that. If the repotag is abused for RPM version comparison (as the least-significant part of %release), so packages from one repo upgrade packages from another repo, that would be really bad. Similarly bad is it when repositories compete with eachother in what they contain and when that leads to incompatibilities. A repotag only attempts at pushing some of the dirt under the carpet. From greg at runlevel7.ca Sun Mar 18 20:08:08 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Sun, 18 Mar 2007 13:08:08 -0700 Subject: [users] Dropping the repotag In-Reply-To: <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45FD9C28.6030701@runlevel7.ca> Michael Schwendt wrote: > Why would a __user__ want a repotag? You're right - the average user probably doesn't (care). It's the people that have to deal with users through bug reports and other support situations that want a repotag. Greg From mschwendt.tmp0701.nospam at arcor.de Sun Mar 18 20:35:19 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 18 Mar 2007 21:35:19 +0100 Subject: [users] Dropping the repotag In-Reply-To: <45FD9C28.6030701@runlevel7.ca> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FD9C28.6030701@runlevel7.ca> Message-ID: <20070318213519.a0f316c6.mschwendt.tmp0701.nospam@arcor.de> On Sun, 18 Mar 2007 13:08:08 -0700, Greg Swallow wrote: > > Why would a __user__ want a repotag? > You're right - the average user probably doesn't (care). It's the > people that have to deal with users through bug reports and other > support situations that want a repotag. Everything other than a clear "Vendor" id in the package header is broken. It is only a matter of time before independent packagers not only set %dist, but also the repotag, mimicking Fedora or EPEL packages. In a support scenario you need enough details about the user's enabled repos anyway. From kanarip at kanarip.com Sun Mar 18 21:20:56 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 18 Mar 2007 22:20:56 +0100 Subject: [users] Dropping the repotag In-Reply-To: <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45FDAD38.1040404@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > > Why would a __user__ want a repotag? > I thought this was EPEL and did thus not involve any users rather then administrators of all kinds. Jeroen van Meeuwen - -kanarip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF/a04KN6f2pNCvwgRArrVAJ98CR2zJZVilC24raRLUGurW+I0awCguHss KnTwpwoWBC+zVa5ck5NWAE4= =otbp -----END PGP SIGNATURE----- From mmcgrath at redhat.com Sun Mar 18 21:26:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 18 Mar 2007 16:26:49 -0500 Subject: [users] Dropping the repotag In-Reply-To: <45FDAD38.1040404@kanarip.com> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FDAD38.1040404@kanarip.com> Message-ID: <45FDAE99.6040001@redhat.com> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Schwendt wrote: > >> Why would a __user__ want a repotag? >> > > > I thought this was EPEL and did thus not involve any users rather then > administrators of all kinds. > > I don't think we should get in the business of guessing about our users until they show up :-) I'd imagine people interested in EPEL range from extremely experienced admins and architects that understand the need for a community driven packaging repo, to people that don't realize that installing mandrake and SuSE RPM's on the same box is a bad thing and they just so happened to find us because Google said so. -Mike From Axel.Thimm at ATrpms.net Sun Mar 18 21:55:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 22:55:11 +0100 Subject: Dropping the repotag In-Reply-To: <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070318215511.GC4773@neu.nirvana> On Sun, Mar 18, 2007 at 08:33:44PM +0100, Michael Schwendt wrote: > Why would a __user__ want a repotag? All the users want is that > repositories "just work" when they are enabled and installed from, even if > it is an unusual mix of repositories. That way you could argue that a user doesn't need a release tag as well, right? > A repotag does not contribute anything to achieving that. If the > repotag is abused for RPM version comparison (as the > least-significant part of %release), so packages from one repo > upgrade packages from another repo, that would be really bad. Does any repo do that? I think not. Running a repo with the "lowest" repotag I can assure you that repotags are not abused in the way you imagine them to be. > Similarly bad is it when repositories compete with eachother in what > they contain and when that leads to incompatibilities. That has nothing to do with a repotag, ... > A repotag only attempts at pushing some of the dirt under the > carpet. ... which is why a repotag cannot improve this situation. A repotag is simply for a quick identification of a packge, be it in a simple rpm -qa list or as a package filename. That's all there is to it, it's not a magical compatibility layer. FWIW I would like to be able to distinguish RHEL packages from EPEL by a simple glance. Given RHEL's structure in several layered products I can never be sure whether it's RHEL, RHCS, RHGFS, RHAPPS already. At least when I see an "at", "rf", "centos", "sl", "kde" as a repotag I know it's none of the official stack. So it's not only distinguishing 3rd party repos, it's for distinguishing from the base os, too. And it's a matter of cooperation: Do we want EPEL to cooperate with existing 3rd party repos, or do we want EPEL to not do so and create a new rift? It's so much more a political issue than a technical one. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Sun Mar 18 22:26:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 18 Mar 2007 23:26:50 +0100 Subject: Dropping the repotag In-Reply-To: <20070318215511.GC4773@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> Message-ID: <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> On Sun, 18 Mar 2007 22:55:11 +0100, Axel Thimm wrote: > > Why would a __user__ want a repotag? All the users want is that > > repositories "just work" when they are enabled and installed from, even if > > it is an unusual mix of repositories. > > That way you could argue that a user doesn't need a release tag as > well, right? ??? No, not right. The release tag in the file name makes it possible to place multiple releases of a package in the same directory. Where that is unnecessary, naming packages %{name}.rpm would be enough. Same applies to %version, %arch, and %epoch (oops, it isn't part of the standard package file name). All the interesting values can be retrieved from the package headers. > > A repotag does not contribute anything to achieving that. If the > > repotag is abused for RPM version comparison (as the > > least-significant part of %release), so packages from one repo > > upgrade packages from another repo, that would be really bad. > > Does any repo do that? I think not. Running a repo with the "lowest" > repotag I can assure you that repotags are not abused in the way you > imagine them to be. This is not about imaginations, but about mixing repositories that offer overlapping or incompatible contents. Again, the same old story. > > Similarly bad is it when repositories compete with eachother in what > > they contain and when that leads to incompatibilities. > > That has nothing to do with a repotag, ... Still the repotag would be part of %release, which is bad for the same reasons as %dist is bad. > > A repotag only attempts at pushing some of the dirt under the > > carpet. > > ... which is why a repotag cannot improve this situation. A repotag is > simply for a quick identification of a packge, be it in a simple rpm > -qa list or as a package filename. That's all there is to it, it's not > a magical compatibility layer. Quick, maybe, but error-prone, as independent packagers already use %dist in the same way Fedora and Livna do. And Livna's tag is a two-in-one repo+dist tag. > FWIW I would like to be able to distinguish RHEL packages from EPEL by > a simple glance. Installed packages, I guess. Then query the RPM database or metadata with the proper options. > So it's not only distinguishing 3rd party repos, it's for > distinguishing from the base os, too. And still users will file bug reports about the wrong component as long as no tools aid them in collecting good details. > And it's a matter of cooperation: Do we want EPEL to cooperate with > existing 3rd party repos, or do we want EPEL to not do so and create a > new rift? It's so much more a political issue than a technical one. I have no doubts that you think about cooperation as you've already joined the fun with Fedora Extras. That doesn't apply to other repositories, though. What cooperation is reality for Fedora Extras and Fedora Core, for instance? Are there guidelines? A SIG with close contact to 3rd party maintainers? A steady exchange of bug reports, fixes, testing results? From Axel.Thimm at ATrpms.net Sun Mar 18 22:54:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 23:54:21 +0100 Subject: Dropping the repotag In-Reply-To: <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070318225421.GD4773@neu.nirvana> On Sun, Mar 18, 2007 at 11:26:50PM +0100, Michael Schwendt wrote: > On Sun, 18 Mar 2007 22:55:11 +0100, Axel Thimm wrote: > > > Why would a __user__ want a repotag? All the users want is that > > > repositories "just work" when they are enabled and installed from, even if > > > it is an unusual mix of repositories. > > > > That way you could argue that a user doesn't need a release tag as > > well, right? > > ??? > > No, not right. Well, you didn't get it, so let me exaggerate to make my point: A user doesn't even need a version, he doesn't need anything as long as everything works, not even the output of rpm -qa. Residing on the non-errant part is not a problem, the issue is what happens if someone needs to take a closer look? > > > A repotag does not contribute anything to achieving that. If the > > > repotag is abused for RPM version comparison (as the > > > least-significant part of %release), so packages from one repo > > > upgrade packages from another repo, that would be really bad. > > > > Does any repo do that? I think not. Running a repo with the "lowest" > > repotag I can assure you that repotags are not abused in the way you > > imagine them to be. > > This is not about imaginations, but about mixing repositories that offer > overlapping or incompatible contents. Again, the same old story. Which has nothing to do with repotags. > > > Similarly bad is it when repositories compete with eachother in what > > > they contain and when that leads to incompatibilities. > > > > That has nothing to do with a repotag, ... > > Still the repotag would be part of %release, which is bad for the > same reasons as %dist is bad. %dist bad? How come? It gives us nice upgrade paths w/o juggling through several *different* specfiles per distro just for the sake of human-controlled and human-error-prone housekeeping. > > A repotag is simply for a quick identification of a packge, be it > > in a simple rpm -qa list or as a package filename. That's all > > there is to it, it's not a magical compatibility layer. > > Quick, maybe, but error-prone, as independent packagers already use %dist > in the same way Fedora and Livna do. And Livna's tag is a two-in-one > repo+dist tag. I'm not sure if you mena that as a praise or blame. There is nothing wrong with livna's tagging. It is indeed a shortened and otherwise unusual disttag/repotag, but it fully serves its cause. > > FWIW I would like to be able to distinguish RHEL packages from EPEL by > > a simple glance. > > Installed packages, I guess. Then query the RPM database or metadata > with the proper options. Where's the "simple glance" in that? > > So it's not only distinguishing 3rd party repos, it's for > > distinguishing from the base os, too. > > And still users will file bug reports about the wrong component as > long as no tools aid them in collecting good details. Then provide them the tools as well. The repotag certainly doesn't discourage that. > > And it's a matter of cooperation: Do we want EPEL to cooperate with > > existing 3rd party repos, or do we want EPEL to not do so and create a > > new rift? It's so much more a political issue than a technical one. > > I have no doubts that you think about cooperation as you've already joined > the fun with Fedora Extras. That doesn't apply to other repositories, > though. What cooperation is reality for Fedora Extras and Fedora Core, for > instance? Are there guidelines? A SIG with close contact to 3rd party > maintainers? A steady exchange of bug reports, fixes, testing results? Why raise the bar that high? This is just making things more difficult to accomplish. Maybe all this kind of cooperation needs small signs of willingness to cooperate before a whole framework of sig, rules and further procedures is put up? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sun Mar 18 23:03:25 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 19 Mar 2007 00:03:25 +0100 Subject: [users] Dropping the repotag In-Reply-To: <45FDAE99.6040001@redhat.com> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FDAD38.1040404@kanarip.com> <45FDAE99.6040001@redhat.com> Message-ID: <45FDC53D.5010000@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McGrath wrote: > Jeroen van Meeuwen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Michael Schwendt wrote: >> >>> Why would a __user__ want a repotag? >>> >> >> >> I thought this was EPEL and did thus not involve any users rather then >> administrators of all kinds. >> >> > I don't think we should get in the business of guessing about our users > until they show up :-) I'd imagine people interested in EPEL range from > extremely experienced admins and architects that understand the need for > a community driven packaging repo, to people that don't realize that > installing mandrake and SuSE RPM's on the same box is a bad thing and > they just so happened to find us because Google said so. > > -Mike > True ;-) But to assume the audience is __users__ maybe contradicts the EL in EPEL ;-) It is also why I mentioned 'administrators of all kinds'. I should probably also mention that these 'administrators' will likely be supporting their own systems, and thus may want to know what repo a certain package came from -see comment from earlier message by Greg Swallow: >It's the people that have to deal with users through bug reports and other support situations that want a repotag. Kind regards, Jeroen van Meeuwen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF/cU9KN6f2pNCvwgRAuM/AKDM2IewApBJ2SN6zMij+OviR6JFNwCfYMYy rAXXn3nCejfjElU+XGr1oGQ= =Glwa -----END PGP SIGNATURE----- From tcallawa at redhat.com Mon Mar 19 03:05:27 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 18 Mar 2007 22:05:27 -0500 Subject: My thoughts on repotag Message-ID: <1174273527.4310.62.camel@localhost.localdomain> It seems like everyone keeps asking me in private to speak on the topic of using a repotag for EPEL, probably since I'm the one who decided to not use one for Fedora Extras (the decision predates the Fedora Packaging Committee). The first problem I have with overloading Release with a repotag is that we start to play games between repositories: foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel Is it really? Nah. This is just RPM trying to make sense of what we've shoved in there. Is this better than having two repositories with the same n-v-r? I don't think so. We're not really solving this problem by using the repotag. We're now in the realm of "my repotag is considered larger than yours by RPM". We might as well be playing games with epoch. Is this the intent? Almost certainly not, but it is the side-effect. Fedora Extras succeeded in this by having very good packages. If the primary repository has good packages, there is less need for other repositories to conflict. So, is EPEL intended as the primary repository for Enterprise Linux addon packages? Now, I absolutely don't mean this to imply that other EL addon repositories are lesser, bad, whatever. I'm simply noting how Fedora Extras managed to get by without having a repotag. I'd very much like to see EPEL as a place where packagers can put their FLOSS bits that aren't legally encumbered in the US. If we succeed in that, then rpm package conflicts are less likely. The second problem is determining where a package came from. This seems like a legitimate problem, but I'm not convinced that using a repotag is the best solution. To me, this seems like a better use for the Vendor tag. Now, if we use the Vendor tag, the problem becomes that users don't see the Vendor tag when they query the package to file a bug. The %{_query_all_fmt} tag controls the output that users see when they query installed package(s). Perhaps EPEL users (with epel-release package installed) get a%{_query_all_fmt} redefined to %{name}-%{version}-%{release}.%{vendor} (or something like that). Then, the origination repository is clear on an rpm query, so we solve this problem, without overloading Release. I always prefer to discuss problems and possible ways to solve them (and then try to find the least intrusive way). :) ~spot From dag at wieers.com Mon Mar 19 06:52:22 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 07:52:22 +0100 (CET) Subject: [users] Dropping the repotag In-Reply-To: <45FDC53D.5010000@kanarip.com> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FDAD38.1040404@kanarip.com> <45FDAE99.6040001@redhat.com> <45FDC53D.5010000@kanarip.com> Message-ID: On Mon, 19 Mar 2007, Jeroen van Meeuwen wrote: > Mike McGrath wrote: > > Jeroen van Meeuwen wrote: > >> Michael Schwendt wrote: > >> > >>> Why would a __user__ want a repotag? > >> > >> I thought this was EPEL and did thus not involve any users rather then > >> administrators of all kinds. > >> > > I don't think we should get in the business of guessing about our users > > until they show up :-) I'd imagine people interested in EPEL range from > > extremely experienced admins and architects that understand the need for > > a community driven packaging repo, to people that don't realize that > > installing mandrake and SuSE RPM's on the same box is a bad thing and > > they just so happened to find us because Google said so. > > True ;-) But to assume the audience is __users__ maybe contradicts the > EL in EPEL ;-) It is also why I mentioned 'administrators of all kinds'. > > I should probably also mention that these 'administrators' will likely > be supporting their own systems, and thus may want to know what repo a > certain package came from -see comment from earlier message by Greg Swallow: First of all, an Enterprise Linux is what every non-technical person should use if they'd pick a Linux distribution. My general remark to newcomers is to tell them that an Enterprise Linux is what 99.99% of the population needs. Fedora and other bleeding edge distributions that turn around every 8 or 10 months, are fine for technical people like you and me, but everyone else should not care about having the latest and greatest, and generally do not want to upgrade if there is no need to. So wrt. the audience, the majority is going to be non-technical users. Maybe not today, but in the unforeseeable future. Luring a non-technical newcomer into Fedora (or Gentoo for that matter) is a lost newcomer, unless they have their personal sysadmin (which only a few have and personal sysadmins scale bad). The experience will be worse than Windows and it will look like there was an alterior motive. Think of your mom as the audience and think of the system as a stable, non-changing environment that may only be reinstalled when there is an absolute need to. (She might not like the new Open Office changes, or the difference in behaviour or look of her computer, so why bother) (The 2 other major use-cases apart from non-technical desktops are servers and appliances like mythtv) BTW I do have a userbase and it does not include only technical people. A lot of users don't even use yum or apt, but google for packages. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Mon Mar 19 07:08:43 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 08:08:43 +0100 (CET) Subject: [users] Dropping the repotag In-Reply-To: <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Sun, 18 Mar 2007, Michael Schwendt wrote: > On Sun, 18 Mar 2007 10:56:22 -0700, Greg Swallow wrote: > > > Thorsten Leemhuis wrote: > > > Thorsten Leemhuis schrieb: > > > > > >> Please bring that up to the Fedora Packaging committee on > > >> fedora-packaging at redhat.com, those guys are the ones that are > > >> responsible for the Packaging Standard used in both EPEL and Fedora. > > >> > > >> The offer still stands: I can forward this discussion/your mail there if > > >> you want. > > >> > > > > > > Done now without waiting for an answer: > > > https://www.redhat.com/archives/fedora-packaging/2007-March/msg00079.html > > > > > > People interested in this discussion please participate there! > > > > > I already just joined this mailing list, now I need to join another? > > No thanks, I made my point clear here. Maybe the packaging committee > > (5-10 people?) could have joined the EPEL list next time a problem like > > this comes up. > > > > On the subject of getting a +1 or -1 from the community. I would say a > > very, very small percentage of the community is here on this list, and > > even fewer on the packaging committee list, so if you have even 3 or 4 > > people saying add the repotag, that's probably a few hundred thousand > > users. Dag is trying to speak for most of them, as I bet that many use > > his repo, and I'm trying to speak for maybe 5,000 that use SME Server > > (an EL4 and soon to be EL5 deriitave). So add 5000 +1's for me please > > on the other list ;-) > > Why would a __user__ want a repotag? All the users want is that > repositories "just work" when they are enabled and installed from, even if > it is an unusual mix of repositories. A repotag does not contribute > anything to achieving that. If the repotag is abused for RPM version > comparison (as the least-significant part of %release), so packages from > one repo upgrade packages from another repo, that would be really bad. > Similarly bad is it when repositories compete with eachother in what they > contain and when that leads to incompatibilities. A repotag only attempts > at pushing some of the dirt under the carpet. Hi Michael, welcome back, you haven't changed a bit. If a user just wants RPM packages that work and doesn't care for the repotag, then there's no harm of having it, is there ? It doesn't break packages from 'just' working. Secondly, there is currently *no* reason why the repotag would play a signifcant role in the version comparison. I mean come on, there is no relation between the release tags between repositories, so assuming that a repotag is there just to promote someones packages is STUPID. It's much easier to take a very big release-number to have certainty over version comparison. Thirdly, if you don't like it, why deny someone else from having it ? It helps to debug certain situations _without_ asking for specifics. eg. if a package tagged .rf. clearly fails in a dependency resolution, you can simply forward the problem report to the correct project instead of first having to ask to give more information. Yum doesn't where a package comes from and especially when the release-tag is identical (and this is not hypothetical) then you will have a hard time finding the cause. You say that a repotag does not contribute to things just working. Is that because you prefer people just use one repository ? What then if CentOS does not join EPEL (which is likely) and has it's own extras repository ? You know that CentOS has a much larger installbase than RHEL and may configure their repository by default. You understand that a single big repository in this light is less likely and that things may not 'just' work as you hope they may. In all those cases you want some information upfront to exclude possibilities. Lastly, I will drop my repotag if the consensus is that a repotag is not desirable for EPEL. You probably do not care about that, but maybe you are not the audience I am packaging for. (You do not use my packages anyway and would stick with only EPEL) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From greg at runlevel7.ca Mon Mar 19 07:04:57 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Mon, 19 Mar 2007 00:04:57 -0700 Subject: My thoughts on repotag In-Reply-To: <1174273527.4310.62.camel@localhost.localdomain> References: <1174273527.4310.62.camel@localhost.localdomain> Message-ID: <45FE3619.2030807@runlevel7.ca> Tom 'spot' Callaway wrote: > It seems like everyone keeps asking me in private to speak on the topic > of using a repotag for EPEL, probably since I'm the one who decided to > not use one for Fedora Extras (the decision predates the Fedora > Packaging Committee). > > The first problem I have with overloading Release with a repotag is that > we start to play games between repositories: > > foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel > > Is it really? Nah. This is just RPM trying to make sense of what we've > shoved in there. > > Is this better than having two repositories with the same n-v-r? I don't > think so. We're not really solving this problem by using the repotag. > We're now in the realm of "my repotag is considered larger than yours by > RPM". We might as well be playing games with epoch. Is this the intent? > Almost certainly not, but it is the side-effect. I think it's more useful to know that two packages are different than worry about the repotag with the exact same release and higher alphabetical version winning. Then at least when someone uses yum to upgrade from foo-0.9.9 and it fails because of a dependency, they know whose package is trying to be installed from the output of yum. > Fedora Extras succeeded in this by having very good packages. If the > primary repository has good packages, there is less need for other > repositories to conflict. So, is EPEL intended as the primary repository > for Enterprise Linux addon packages? > Well it certainly isn't yet. And to get the cooperation of the primary repository (Dag) would be smart IMO, especially if the goal is cooperation and having a package removed from the other repositories once it's in EPEL. > Now, I absolutely don't mean this to imply that other EL addon > repositories are lesser, bad, whatever. I'm simply noting how Fedora > Extras managed to get by without having a repotag. > > I'd very much like to see EPEL as a place where packagers can put their > FLOSS bits that aren't legally encumbered in the US. If we succeed in > that, then rpm package conflicts are less likely. I agree that it makes sense (in most cases) to have one package in one repository, and I think EPEL is fine place for that to happen as it lets interested people maintain packages they're interested in. But maintainers should check if the package they are going to branch for EPEL is in another EL addon repository and check it will upgrade that package cleanly. And then convince and give some time for the EL addon repository to communicate to their users that enabling the EPEL repository is needed, before they stop packaging (or updating) a certain package for EL4 or EL5. I suggested an addition to the EPEL guidelines regarding that already a few days ago on this list. > The second problem is determining where a package came from. This seems > like a legitimate problem, but I'm not convinced that using a repotag is > the best solution. To me, this seems like a better use for the Vendor > tag. Now, if we use the Vendor tag, the problem becomes that users don't > see the Vendor tag when they query the package to file a bug. > If the vendor tag was more descriptive than "Fedora" that would be good too. (ie. "Fedora EPEL-4" or "Fedora EPEL-5"). > The %{_query_all_fmt} tag controls the output that users see when they > query installed package(s). Perhaps EPEL users (with epel-release > package installed) get a%{_query_all_fmt} redefined to > %{name}-%{version}-%{release}.%{vendor} (or something like that). Then, > the origination repository is clear on an rpm query, so we solve this > problem, without overloading Release. > The other problem discussed already is packages that aren't installed - ie, failed yum upgrades, which does not show the repository of a package to be updated until it has a list of packages to be installed. > I always prefer to discuss problems and possible ways to solve them (and > then try to find the least intrusive way). :) > Good plan :) Greg > ~spot > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From Axel.Thimm at ATrpms.net Mon Mar 19 07:22:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 08:22:18 +0100 Subject: Dropping the repotag In-Reply-To: <20070318213519.a0f316c6.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FD9C28.6030701@runlevel7.ca> <20070318213519.a0f316c6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319072218.GE4773@neu.nirvana> On Sun, Mar 18, 2007 at 09:35:19PM +0100, Michael Schwendt wrote: > On Sun, 18 Mar 2007 13:08:08 -0700, Greg Swallow wrote: > > > > Why would a __user__ want a repotag? > > You're right - the average user probably doesn't (care). It's the > > people that have to deal with users through bug reports and other > > support situations that want a repotag. > > Everything other than a clear "Vendor" id in the package header is > broken. It is only a matter of time before independent packagers not only > set %dist, but also the repotag, mimicking Fedora or EPEL packages. This is far fetched science ficition. Disttags and repotags have been around long before Fedora existed and no repo was as brain-damaged to copy over another repo's repotag. If you assume maximum stupidity then everything is possible, of course, even a random permutation of name/version/release, does that lead us to dropping version and release, too? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Mon Mar 19 07:38:09 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 08:38:09 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <1174273527.4310.62.camel@localhost.localdomain> References: <1174273527.4310.62.camel@localhost.localdomain> Message-ID: On Sun, 18 Mar 2007, Tom 'spot' Callaway wrote: > It seems like everyone keeps asking me in private to speak on the topic > of using a repotag for EPEL, probably since I'm the one who decided to > not use one for Fedora Extras (the decision predates the Fedora > Packaging Committee). > > The first problem I have with overloading Release with a repotag is that > we start to play games between repositories: > > foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel > > Is it really? Nah. This is just RPM trying to make sense of what we've > shoved in there. If that really is a concern, then you loose anyway by not having one. foo-1.0.0-1.el5 < foo-1.0.0-1.el5.rf Besides this case is only useful when releases are identical, which often they aren't and there is no reason to assume that: foo-1.0.0-4.el5 > foo-1.0.0-2.el5.rf either. So whatever the point is, a repotag simply does not affect the version comparison in an important way, because releases from different repositories simply cannot be compared. Any attempt doing that is brain surgery. Higher does not mean better, besides RPMforge looses anyway because most packages have a release of 1, while EPEL seldom has 1. Moot artificial point. > Is this better than having two repositories with the same n-v-r? I don't > think so. We're not really solving this problem by using the repotag. There is nothing to solve. A repotag does not help or break release comparison. Nothing to compare here, please move along. > We're now in the realm of "my repotag is considered larger than yours by > RPM". We might as well be playing games with epoch. Is this the intent? > Almost certainly not, but it is the side-effect. Moot point. It must be paranoia talking if you think the only reason for a repotag is to influence the version comparison. First mention ever. (actually michael deserves that credit !) > The second problem is determining where a package came from. This seems > like a legitimate problem, but I'm not convinced that using a repotag is > the best solution. To me, this seems like a better use for the Vendor > tag. Now, if we use the Vendor tag, the problem becomes that users don't > see the Vendor tag when they query the package to file a bug. So you want to restrict Vendor tags to something short ? What will then hold the former Vendor information ? > The %{_query_all_fmt} tag controls the output that users see when they > query installed package(s). Perhaps EPEL users (with epel-release > package installed) get a%{_query_all_fmt} redefined to > %{name}-%{version}-%{release}.%{vendor} (or something like that). Then, > the origination repository is clear on an rpm query, so we solve this > problem, without overloading Release. Right. Let's see how that looks on a production system: [dag at host ~]$ rpm -qa --qf '%{name}-%{version}-%{release}.%{vendor}.%{arch}\n' apt-0.5.15lorg3.1-4.el3.rf.Dag Apt Repository, http://dag.wieers.com/apt/.i386 basesystem-8.0-2.Red Hat, Inc..noarch bash-2.05b-41.5.Red Hat, Inc..i386 InterDo-3.5.6-17.KaVaDo Inc. .i386 ISSXss-6-6.5.1.(none).i386 j2re-1.4.2_03-fcs.Sun Microsystems.i586 TIVsm-API-5.2.4-0.IBM.i386 TIVsm-BA-5.2.4-0.IBM.i386 (It amases me how proactive IBM at times can be) Now, will that affect Yum, Apt and other tools as well ? Do they use %{_query_all_fmt} ? Besides this breaks a lot of scripts that do not expect spaces (or dashes) in rpm -qa output and it becomes impossible to extract information from the filename like was possible in the past. name="${file%-*-*}" > I always prefer to discuss problems and possible ways to solve them (and > then try to find the least intrusive way). :) Thanks Tom ! PS If I sound bitter, it's just because after 5 years and having this discussion for 4 times we return to proposals like this one. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Axel.Thimm at ATrpms.net Mon Mar 19 08:15:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 09:15:08 +0100 Subject: My thoughts on repotag In-Reply-To: <1174273527.4310.62.camel@localhost.localdomain> References: <1174273527.4310.62.camel@localhost.localdomain> Message-ID: <20070319081508.GB24707@neu.nirvana> On Sun, Mar 18, 2007 at 10:05:27PM -0500, Tom 'spot' Callaway wrote: > The first problem I have with overloading Release with a repotag is that > we start to play games between repositories: > > foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel > > Is it really? Nah. This is just RPM trying to make sense of what we've > shoved in there. That is not the problem space the repotag tries to address. If you are as far as to whether a repotag matters or not, you already lost the game, Still ... > Is this better than having two repositories with the same n-v-r? I don't > think so. ... it is better to have any of the two win, than to have two identical packages of which yum and any other depsolver throws a dice to chose. Because in the later case you get both unreproducable bugs (50% pick the left package, and 50% the right) as well as users and bug assignees unsuspecting of the real cause since the reported package does existing in exactly that nvr in the repo. At the end this will lead to enough frustration on all sides to use only repo A or B. So even in this problem repotags are helpful, and are not causing any harm by themselves. > Fedora Extras succeeded in this by having very good packages. If the > primary repository has good packages, there is less need for other > repositories to conflict. So, is EPEL intended as the primary repository > for Enterprise Linux addon packages? > > Now, I absolutely don't mean this to imply that other EL addon > repositories are lesser, bad, whatever. I'm simply noting how Fedora > Extras managed to get by without having a repotag. Fedora Extras was from the beginning a merger of RHL and Fedora.us. Technically it took longer to make that happen, and with F7 we're there. The separation in Core and Extras was like Red Hat vs Community - dropping the repotag was both sane (it was intended to become one) and *political*, because you didn't want to mark community packages different than the big brother's. So it was a proper call to make IMHO. And in this case it is similar argumentation: Is RHEL and EPEL to become a merged project? Most probably not. Is it politically wise to add a repotag? It depends on the messege you want to deliver: No repotag means "We assume we are the only or main repo supporting RHEL, we don't care about other 3rd parties that may have established". A repotag means "We're the new kids on the block and are playing in the game like everybody else". > The second problem is determining where a package came from. This seems > like a legitimate problem, but I'm not convinced that using a repotag is > the best solution. To me, this seems like a better use for the Vendor > tag. How often have you seen a Vendor tag queried by end users or used on an online repo? And how often is it even set properly by various 3rd party repos? > The %{_query_all_fmt} tag controls the output that users see when they > query installed package(s). Perhaps EPEL users (with epel-release > package installed) get a%{_query_all_fmt} redefined to > %{name}-%{version}-%{release}.%{vendor} (or something like that). Then, > the origination repository is clear on an rpm query, so we solve this > problem, without overloading Release. That would break quite a lot of admin scripts that scrape the output of rpm, and believe me every RHEL admin out there has his bash scripts. We had this discussion a long time ago (adding epochs in the display), and had to drop this idea. I don't think that we'll have better arguments to change rpm's output on RHEL. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Mon Mar 19 10:45:24 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Mar 2007 10:45:24 +0000 Subject: My thoughts on repotag In-Reply-To: <1174273527.4310.62.camel@localhost.localdomain> References: <1174273527.4310.62.camel@localhost.localdomain> Message-ID: <45FE69C4.8090104@city-fan.org> Tom 'spot' Callaway wrote: > The second problem is determining where a package came from. This seems > like a legitimate problem, but I'm not convinced that using a repotag is > the best solution. To me, this seems like a better use for the Vendor > tag. Now, if we use the Vendor tag, the problem becomes that users don't > see the Vendor tag when they query the package to file a bug. > > The %{_query_all_fmt} tag controls the output that users see when they > query installed package(s). Perhaps EPEL users (with epel-release > package installed) get a%{_query_all_fmt} redefined to > %{name}-%{version}-%{release}.%{vendor} (or something like that). Then, > the origination repository is clear on an rpm query, so we solve this > problem, without overloading Release. I suspect that that would break a lot of scripts that make assumptions about the %{_query_all_fmt} value; in fact I suspect the default format would have been changed to %{name}-%{version}-%{release}.%{arch}\n a long time ago if it wasn't for this concern. Paul. From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 11:12:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 12:12:01 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> Message-ID: <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 08:38:09 +0100 (CET), Dag Wieers wrote: > On Sun, 18 Mar 2007, Tom 'spot' Callaway wrote: > > > It seems like everyone keeps asking me in private to speak on the topic > > of using a repotag for EPEL, probably since I'm the one who decided to > > not use one for Fedora Extras (the decision predates the Fedora > > Packaging Committee). > > > > The first problem I have with overloading Release with a repotag is that > > we start to play games between repositories: > > > > foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel > > > > Is it really? Nah. This is just RPM trying to make sense of what we've > > shoved in there. > > If that really is a concern, then you loose anyway by not having one. > > foo-1.0.0-1.el5 < foo-1.0.0-1.el5.rf > > Besides this case is only useful when releases are identical, which often > they aren't and there is no reason to assume that: > > foo-1.0.0-4.el5 > foo-1.0.0-2.el5.rf > > either. So whatever the point is, a repotag simply does not affect the > version comparison in an important way, because releases from different > repositories simply cannot be compared. Any attempt doing that is > brain surgery. Higher does not mean better, besides RPMforge looses anyway > because most packages have a release of 1, while EPEL seldom has 1. > > Moot artificial point. Is it? No, it is not. It is a real-world example. The scheme above assumes that the dist tag is mandatory. Mistake #1. A mandatory dist tag enters automatic Provides/Requires and also must be considered in manual Obsoletes/Provides/Conflicts. Bad. It then proceeds to adding a mandatory repo tag. Mistake #2. It still fails for branch-specific (i.e. dist-specific) fixes, where the least-significant portion of the full %release value is increased for rebuilds or minor fixes: foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf In the past, the proponents of mandatory dist tags have ignored that issue or have tried to fight it with their main counter-argument that updates are applied to all branches always. Mass-updates *always*. As I've explained before, more tags at the right of %release don't solve the repository mixing problems. They only try to hide the fundamental problem. The primary goal, once again, seems to be to add something mandatory to package names, which makes users point the finger at a specific repo when they run into repository mixing problems. Instead, it would be much better if repositories collaborated actually and shared common packages with the common goal of eliminating upgrade problems, conflicts, and redundant package development. From pertusus at free.fr Mon Mar 19 11:23:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 12:23:23 +0100 Subject: My thoughts on repotag In-Reply-To: <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319112323.GI3186@free.fr> On Mon, Mar 19, 2007 at 12:12:01PM +0100, Michael Schwendt wrote: > > They only try to hide the fundamental problem. The primary goal, once > again, seems to be to add something mandatory to package names, which > makes users point the finger at a specific repo when they run into > repository mixing problems. Instead, it would be much better if > repositories collaborated actually and shared common packages with > the common goal of eliminating upgrade problems, conflicts, and > redundant package development. While I mostly agree to you, I am not convinced that it is realistic for EPEL as it has been for fedora extras. To be sure that it is realistic we should first search for an agreement with third party repo prior from assuming that it will happen. -- Pat From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 11:38:33 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 12:38:33 +0100 Subject: [users] Dropping the repotag In-Reply-To: References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 08:08:43 +0100 (CET), Dag Wieers wrote: > > Why would a __user__ want a repotag? All the users want is that > > repositories "just work" when they are enabled and installed from, even if > > it is an unusual mix of repositories. A repotag does not contribute > > anything to achieving that. If the repotag is abused for RPM version > > comparison (as the least-significant part of %release), so packages from > > one repo upgrade packages from another repo, that would be really bad. > > Similarly bad is it when repositories compete with eachother in what they > > contain and when that leads to incompatibilities. A repotag only attempts > > at pushing some of the dirt under the carpet. > > Hi Michael, welcome back, you haven't changed a bit. Why should I? Afterall, there's still the same hypocrisy in threads like this, no signs of actual cooperation or collaboration, but only attempts at influencing a project's decisions from the outside without getting involved. The only difference in how I've changed is that I am not involved in EPEL, so feel free to agree on something without my blessing. ;) > Yum doesn't where a package comes from and especially when the release-tag > is identical (and this is not hypothetical) then you will have a hard time > finding the cause. Only because there are multiple sources, which try to provide the same thing or which go beyond that and offer competing packages, which upgrade and replace eachother. > You say that a repotag does not contribute to things just working. Is that > because you prefer people just use one repository ? No. I prefer a strict hierarchy of repositories, a tree where child nodes don't mess with fathers' stuff. > What then if CentOS > does not join EPEL (which is likely) and has it's own extras repository ? If they have the man-power to do that, fine. If they find a team of maintainer for every package, fine. If they rebuild EPEL packages with an added repo tag and forward bug reports to EPEL, fine. But wait! That would make the repo tag enter RPM version comparison for users, who enable CentOS Extras *and* EPEL. Or they go a step farther and create an upgrade race with EPEL by bumping %release or %version. Repository mixing problems again. Irresponsible, IMO. From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 11:39:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 12:39:38 +0100 Subject: Dropping the repotag In-Reply-To: <20070319072218.GE4773@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FD9C28.6030701@runlevel7.ca> <20070318213519.a0f316c6.mschwendt.tmp0701.nospam@arcor.de> <20070319072218.GE4773@neu.nirvana> Message-ID: <20070319123938.af3e7fc6.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 08:22:18 +0100, Axel Thimm wrote: > On Sun, Mar 18, 2007 at 09:35:19PM +0100, Michael Schwendt wrote: > > On Sun, 18 Mar 2007 13:08:08 -0700, Greg Swallow wrote: > > > > > > Why would a __user__ want a repotag? > > > You're right - the average user probably doesn't (care). It's the > > > people that have to deal with users through bug reports and other > > > support situations that want a repotag. > > > > Everything other than a clear "Vendor" id in the package header is > > broken. It is only a matter of time before independent packagers not only > > set %dist, but also the repotag, mimicking Fedora or EPEL packages. > > This is far fetched science ficition. Disttags and repotags have been > around long before Fedora existed and no repo was as brain-damaged to > copy over another repo's repotag. Check your facts. No further comment. From rdieter at math.unl.edu Mon Mar 19 12:09:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 07:09:56 -0500 Subject: Dropping the repotag In-Reply-To: <20070318174343.GE31755@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <20070318160012.GB31755@neu.nirvana> <45FD6603.2030907@leemhuis.info> <45FD7840.3070902@redhat.com> <20070318174343.GE31755@neu.nirvana> Message-ID: <45FE7D94.5060307@math.unl.edu> Axel Thimm wrote: > With my EPEL hat on: "Let's do repotags and keep the peace". +1. Long and short of it: Use repotags or dag/rpmforge won't play ball. Imo, it's mostly harmless, so "just do it". And, please no more "repotags are bad/evil, let's try other theoretical-but-never-gonna-happen-in-a-million-years way" arguments. -- Rex From lance at centos.org Mon Mar 19 12:27:48 2007 From: lance at centos.org (Lance Davis) Date: Mon, 19 Mar 2007 12:27:48 +0000 (GMT) Subject: My thoughts on repotag In-Reply-To: <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > It still fails for branch-specific (i.e. dist-specific) fixes, where the > least-significant portion of the full %release value is increased for > rebuilds or minor fixes: > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in the first place if you had those repos configured ... priorities plugin solves that one but I agree it isnt a 'nice' solution for end users ... It could be mandated that repotag always comes last and is preceeded by a (default 0) build id eg foo-1.0.0-2.el5.1.fdr > foo-1.0.0-2.el5.0.fdr Surely what really needs to happen for this to work to everyones satisfaction is n-e-v-r-t Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From dag at wieers.com Mon Mar 19 12:50:05 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 13:50:05 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 08:38:09 +0100 (CET), Dag Wieers wrote: > > > On Sun, 18 Mar 2007, Tom 'spot' Callaway wrote: > > > > > It seems like everyone keeps asking me in private to speak on the topic > > > of using a repotag for EPEL, probably since I'm the one who decided to > > > not use one for Fedora Extras (the decision predates the Fedora > > > Packaging Committee). > > > > > > The first problem I have with overloading Release with a repotag is that > > > we start to play games between repositories: > > > > > > foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel > > > > > > Is it really? Nah. This is just RPM trying to make sense of what we've > > > shoved in there. > > > > If that really is a concern, then you loose anyway by not having one. > > > > foo-1.0.0-1.el5 < foo-1.0.0-1.el5.rf > > > > Besides this case is only useful when releases are identical, which often > > they aren't and there is no reason to assume that: > > > > foo-1.0.0-4.el5 > foo-1.0.0-2.el5.rf > > > > either. So whatever the point is, a repotag simply does not affect the > > version comparison in an important way, because releases from different > > repositories simply cannot be compared. Any attempt doing that is > > brain surgery. Higher does not mean better, besides RPMforge looses anyway > > because most packages have a release of 1, while EPEL seldom has 1. > > > > Moot artificial point. > > Is it? No, it is not. It is a real-world example. It makes not difference what the release is. Whether it influences the release comparison or not, releases cannot be compared between repositories. There is no relation. A repotag makes no difference in a relation that doesn't exist. > It still fails for branch-specific (i.e. dist-specific) fixes, where the > least-significant portion of the full %release value is increased for > rebuilds or minor fixes: > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf Then you assume that minor numbers are behind the repotag, which is a bad implementation. > In the past, the proponents of mandatory dist tags have ignored that issue > or have tried to fight it with their main counter-argument that updates > are applied to all branches always. Mass-updates *always*. > > As I've explained before, more tags at the right of %release don't solve > the repository mixing problems. But it doesn't affect it either. The example you gave was a bad example. disttags and repotags are at the far right. > They only try to hide the fundamental problem. The primary goal, once > again, seems to be to add something mandatory to package names, which > makes users point the finger at a specific repo when they run into > repository mixing problems. Instead, it would be much better if > repositories collaborated actually and shared common packages with > the common goal of eliminating upgrade problems, conflicts, and > redundant package development. That's fine. Then the question is: why is Fedora creating EPEL packages? Why does Fedora mandate CentOS and not the other way around ? And we start from base one again. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rdieter at math.unl.edu Mon Mar 19 12:57:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 07:57:26 -0500 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45FE88B6.3070004@math.unl.edu> Dag Wieers wrote: > Then the question is: why is Fedora creating EPEL packages? > Why does Fedora mandate CentOS and not the other way around ? Fedora is creating EPEL packages because there exist acommunity of packagers/maintainers who want to do it and an infrastructure to enable that. No one is mandating anything to anyone. Point blank: If epel does do repotags, will you participate in epel? Or are there other blockers for you? -- Rex From dag at wieers.com Mon Mar 19 12:58:30 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 13:58:30 +0100 (CET) Subject: [users] Dropping the repotag In-Reply-To: <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 08:08:43 +0100 (CET), Dag Wieers wrote: > > > > Why would a __user__ want a repotag? All the users want is that > > > repositories "just work" when they are enabled and installed from, even if > > > it is an unusual mix of repositories. A repotag does not contribute > > > anything to achieving that. If the repotag is abused for RPM version > > > comparison (as the least-significant part of %release), so packages from > > > one repo upgrade packages from another repo, that would be really bad. > > > Similarly bad is it when repositories compete with eachother in what they > > > contain and when that leads to incompatibilities. A repotag only attempts > > > at pushing some of the dirt under the carpet. > > > > Hi Michael, welcome back, you haven't changed a bit. > > Why should I? > > Afterall, there's still the same hypocrisy in threads like this, no signs > of actual cooperation or collaboration, but only attempts at influencing a > project's decisions from the outside without getting involved. > > The only difference in how I've changed is that I am not involved in EPEL, > so feel free to agree on something without my blessing. ;) > > > Yum doesn't where a package comes from and especially when the release-tag > > is identical (and this is not hypothetical) then you will have a hard time > > finding the cause. > > Only because there are multiple sources, which try to provide the same > thing or which go beyond that and offer competing packages, which upgrade > and replace eachother. > > > You say that a repotag does not contribute to things just working. Is that > > because you prefer people just use one repository ? > > No. I prefer a strict hierarchy of repositories, a tree where child nodes > don't mess with fathers' stuff. > > > What then if CentOS > > does not join EPEL (which is likely) and has it's own extras repository ? > > If they have the man-power to do that, fine. > > If they find a team of maintainer for every package, fine. > > If they rebuild EPEL packages with an added repo tag and forward bug > reports to EPEL, fine. > > But wait! That would make the repo tag enter RPM version comparison for > users, who enable CentOS Extras *and* EPEL. Or they go a step farther and > create an upgrade race with EPEL by bumping %release or %version. > Repository mixing problems again. Irresponsible, IMO. And again, the repotag does not influence the release comparison. There is nothing to compare in releases if you consider multiple repositories. We get to the heart of the matter, which is (and has been): There is only one repository. I don't care about anything else. This argument has created tools (like yum) that do not consider a multi-repository world. For Fedora that worked in the sense that you forced people to join (as it was upstream) or FUD them out of existence. For RHEL this will not work, and as much as you want to force people into your community, and regardless of how well that works, it is not very nice. So welcome back ! Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Mon Mar 19 13:02:02 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 14:02:02 +0100 (CET) Subject: Dropping the repotag In-Reply-To: <20070319123938.af3e7fc6.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FD9C28.6030701@runlevel7.ca> <20070318213519.a0f316c6.mschwendt.tmp0701.nospam@arcor.de> <20070319072218.GE4773@neu.nirvana> <20070319123938.af3e7fc6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 08:22:18 +0100, Axel Thimm wrote: > > > On Sun, Mar 18, 2007 at 09:35:19PM +0100, Michael Schwendt wrote: > > > On Sun, 18 Mar 2007 13:08:08 -0700, Greg Swallow wrote: > > > > > > > > Why would a __user__ want a repotag? > > > > You're right - the average user probably doesn't (care). It's the > > > > people that have to deal with users through bug reports and other > > > > support situations that want a repotag. > > > > > > Everything other than a clear "Vendor" id in the package header is > > > broken. It is only a matter of time before independent packagers not only > > > set %dist, but also the repotag, mimicking Fedora or EPEL packages. > > > > This is far fetched science ficition. Disttags and repotags have been > > around long before Fedora existed and no repo was as brain-damaged to > > copy over another repo's repotag. > > Check your facts. No further comment. No, check *your* facts. fedora.us is not the Fedora project. And even if it were, repotags have been used in fedora.us _before_ the Fedora project. Besides, another moot point to divert from a normal conversation. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 13:26:14 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 14:26:14 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319142614.b6ea7832.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 13:50:05 +0100 (CET), Dag Wieers wrote: > > It still fails for branch-specific (i.e. dist-specific) fixes, where the > > least-significant portion of the full %release value is increased for > > rebuilds or minor fixes: > > > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf > > Then you assume that minor numbers are behind the repotag, which is a bad > implementation. Funnily, that implementation is used by Fedora and has worked well. The least-significant portion of %release however is blocked by and abused by a dist tag and a repo tag. > > In the past, the proponents of mandatory dist tags have ignored that issue > > or have tried to fight it with their main counter-argument that updates > > are applied to all branches always. Mass-updates *always*. > > > > As I've explained before, more tags at the right of %release don't solve > > the repository mixing problems. > > But it doesn't affect it either. The example you gave was a bad example. > disttags and repotags are at the far right. "Highest" repo tag does win RPM version comparison. From dag at wieers.com Mon Mar 19 13:26:36 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 14:26:36 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <45FE88B6.3070004@math.unl.edu> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <45FE88B6.3070004@math.unl.edu> Message-ID: On Mon, 19 Mar 2007, Rex Dieter wrote: > Dag Wieers wrote: > > > Then the question is: why is Fedora creating EPEL packages? > > Why does Fedora mandate CentOS and not the other way around ? > > Fedora is creating EPEL packages because there exist acommunity of > packagers/maintainers who want to do it and an infrastructure to enable that. > > No one is mandating anything to anyone. > > Point blank: If epel does do repotags, will you participate in epel? Or are > there other blockers for you? The repotag is not blocking me at all, but is necessary to allow multiple repositories to work together. Without it, it becomes harder to track were problems are coming from. I've discussed a few of the blockers we have to join EPEL (which are mostly related to how we build, what one is allowed to do with SPEC files and what policies there are for maintaining them). And Karanbir made some others (from CentOS) at FOSDEM to Tom Callaway. I'm not refusing to work with EPEL flat out (if I were, I wouldn't be on this list), but I wouldn't be as productive with the current Fedora guidelines. I have had quite a few discussions with Matthias concerning this and I question the forking of SPEC files (for different dists, think RHEL2.1, RHEL3, RHEL4 and RHEL5), the implementation of macros the way it is done with Fedora and the maintainership/ownership of SPEC files as done with Fedora. If I were to join, I bet all of these will bring in fierce discussions and since CentOS hasn't made a formal decision (mostly because CentOS5 is taking up all resources) I don't know what to do. Fact is that RPMforge as it is will end as soon as there is an alternative. Which at this point I don't think there is. And whetever EPEL decides to do, there will always be other requirements from other people (latest and greatest vs. stable and back-ported). So I doubt that whatever hole EPEL is going to fill and whatever hole CentOS is going to fill, other repositories will exist to fill other holes that EPEL doesn't do. And that means upgrading EPEL packages. Even with EPEL and CentOS I might still have another repository with recent versions of certain packages and these also have to coexist with whatever there is. Whatever your use case is, other people have other requirements and you cannot have a one-fit-all repository. EL is not only the server, there's also the desktop and also the appliance worlds that need stable or bleeding edge packages. And I consider RPMforge bleeding edge and it's up to the user or administrator to make intelligent decisions. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 13:36:53 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 14:36:53 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 12:27:48 +0000 (GMT), Lance Davis wrote: > On Mon, 19 Mar 2007, Michael Schwendt wrote: > > > It still fails for branch-specific (i.e. dist-specific) fixes, where the > > least-significant portion of the full %release value is increased for > > rebuilds or minor fixes: > > > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf > > but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in > the first place if you had those repos configured ... And that is flawed. The package release string gets longer without telling anything about which of the packages is newer. Anyone still want to claim that these tags don't influence RPM version comparison? ;) Packagers would be forced to increment the most-significant part of %release, breaking the dist-upgrade path, foo-1.0.0-3.el4.fdr > foo-1.0.0-2.el5.fdr unless superfluous mass-updates and mass-rebuilds are used. > It could be mandated that repotag always comes last and is preceeded by a > (default 0) build id > > eg foo-1.0.0-2.el5.1.fdr > foo-1.0.0-2.el5.0.fdr Looks like EL5.1 and EL5.0 to me and is something like: Release: 2%{?dist}.0%{?repo} ?? And then you want packagers to bump release in that macro-madness? %dist and %repo -- and %fedora and %rhel -- are undefined by default. Rebuild such src.rpms results in completely incompatible packages. foo-1.0.0-2.1 > foo-1.0.0-2.0 > foo-1.0.0-2.el5.1.fdr > ... From dag at wieers.com Mon Mar 19 13:37:38 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 14:37:38 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <20070319142614.b6ea7832.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319142614.b6ea7832.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 13:50:05 +0100 (CET), Dag Wieers wrote: > > > > It still fails for branch-specific (i.e. dist-specific) fixes, where the > > > least-significant portion of the full %release value is increased for > > > rebuilds or minor fixes: > > > > > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf > > > > Then you assume that minor numbers are behind the repotag, which is a bad > > implementation. > > Funnily, that implementation is used by Fedora and has worked well. Do you always work with circular logic ? What you give as an example would not work in a multi-repository world, which is what we are discussing and which is WHY we ask for a repotag. Take away the miltu-repository world and you can put whatever you want in your release-tag or your version comparison and it wouldn't matter. So if you are looking for self-serving examples that go beyond what we are discussing, please do not reply to my emails. > The least-significant portion of %release however is blocked by and abused by > a dist tag and a repo tag. No, it doesn't make the version comparison any more better or worse. Again I repeat myself, read it slowly and please think: Comparing release tags for packages from different repositories (with or without a repotag) makes no sense because there is *no* relation. So it might as well improve the version comparison :) It all depends what the user wanted, the system doesn't know. > > > In the past, the proponents of mandatory dist tags have ignored that issue > > > or have tried to fight it with their main counter-argument that updates > > > are applied to all branches always. Mass-updates *always*. > > > > > > As I've explained before, more tags at the right of %release don't solve > > > the repository mixing problems. > > > > But it doesn't affect it either. The example you gave was a bad example. > > disttags and repotags are at the far right. > > "Highest" repo tag does win RPM version comparison. There is nothing to win. If you don't add a repotag and you get these 2: nagios-2.8-2.el5 from EPEL nagios-2.8-3.el5 from RPMforge What does that mean ? It may be as problematic as the case where: nagios-2.8-3.el5 from EPEL nagios-2.8-2.el5 from RPMforge Add a repotag to both cases for your amusement, it would not matter. Now consider: nagios-2.8-2.el5 from EPEL nagios-2.8-2.el5 from RPMforge And in all cases, where it is questionable which one *should* have been taken. The two first examples are more common then the latter example (which is yours) and in none of the cases there is a real difference. Summary: there is no defined way which one should come out on top Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From fedora at leemhuis.info Mon Mar 19 13:43:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 14:43:05 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <45FE88B6.3070004@math.unl.edu> Message-ID: <45FE9369.70506@leemhuis.info> On 19.03.2007 14:26, Dag Wieers wrote: > [...] > And whetever EPEL decides to do, there will always be other requirements > from other people (latest and greatest vs. stable and back-ported). So I > doubt that whatever hole EPEL is going to fill and whatever hole CentOS > is going to fill, other repositories will exist to fill other holes that > EPEL doesn't do. And that means upgrading EPEL packages. > [...] > And I consider RPMforge bleeding edge and it's up to the user or > administrator to make intelligent decisions. +1 to those to paras. Cu thl (who still tries to stay out of this discussion) From dag at wieers.com Mon Mar 19 13:44:00 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 14:44:00 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 12:27:48 +0000 (GMT), Lance Davis wrote: > > > On Mon, 19 Mar 2007, Michael Schwendt wrote: > > > > > It still fails for branch-specific (i.e. dist-specific) fixes, where the > > > least-significant portion of the full %release value is increased for > > > rebuilds or minor fixes: > > > > > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf > > > > but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in > > the first place if you had those repos configured ... > > And that is flawed. > > The package release string gets longer without telling anything about > which of the packages is newer. Anyone still want to claim that these tags > don't influence RPM version comparison? ;) Packagers would be forced to > increment the most-significant part of %release, breaking the dist-upgrade > path, > > foo-1.0.0-3.el4.fdr > foo-1.0.0-2.el5.fdr > > unless superfluous mass-updates and mass-rebuilds are used. Once again a self-serving example, it has nothing to do with repotags. foo-1.0.0-3.el4 > foo-1.0.0-2.el5 I'm sure you could have come up with this: foo-1.0.0-2.el4.1.fdr < foo-1.0.0-2.el5.0.fdr Which is exactly how it used to be without the repotag. I can only see bad intent in the form of your examples. > > It could be mandated that repotag always comes last and is preceeded by a > > (default 0) build id > > > > eg foo-1.0.0-2.el5.1.fdr > foo-1.0.0-2.el5.0.fdr > > Looks like EL5.1 and EL5.0 to me and is something like: > > Release: 2%{?dist}.0%{?repo} > > ?? And then you want packagers to bump release in that macro-madness? > > %dist and %repo -- and %fedora and %rhel -- are undefined by default. > Rebuild such src.rpms results in completely incompatible packages. > > foo-1.0.0-2.1 > foo-1.0.0-2.0 > foo-1.0.0-2.el5.1.fdr > ... You are bringing up some good points that do not concern repotags at all. And which RPMforge does have a policy for. But it does not influence the decision on repotags. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 13:53:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 14:53:38 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319145338.0f5ee965.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 14:44:00 +0100 (CET), Dag Wieers wrote: > > > > It still fails for branch-specific (i.e. dist-specific) fixes, where the > > > > least-significant portion of the full %release value is increased for > > > > rebuilds or minor fixes: > > > > > > > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf > > > > > > but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in > > > the first place if you had those repos configured ... > > > > And that is flawed. > > > > The package release string gets longer without telling anything about > > which of the packages is newer. Anyone still want to claim that these tags > > don't influence RPM version comparison? ;) Packagers would be forced to > > increment the most-significant part of %release, breaking the dist-upgrade > > path, > > > > foo-1.0.0-3.el4.fdr > foo-1.0.0-2.el5.fdr > > > > unless superfluous mass-updates and mass-rebuilds are used. > > Once again a self-serving example, it has nothing to do with repotags. > > foo-1.0.0-3.el4 > foo-1.0.0-2.el5 > > I'm sure you could have come up with this: > > foo-1.0.0-2.el4.1.fdr < foo-1.0.0-2.el5.0.fdr > > Which is exactly how it used to be without the repotag. I can only see bad > intent in the form of your examples. Do you realise that now you've gone as far as comparing a release digit with a repo tag? 2.el4.1 wins over all 2.el4.somerepotag Version comparison hell. Upgrade race. Again and again. From rdieter at math.unl.edu Mon Mar 19 13:54:49 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 08:54:49 -0500 Subject: rpmforge blockers In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <45FE88B6.3070004@math.unl.edu> Message-ID: <45FE9629.3070702@math.unl.edu> Dag Wieers wrote: > I've discussed a few of the blockers we have to join EPEL (which are > mostly related to how we build, what one is allowed to do with SPEC files > and what policies there are for maintaining them). And Karanbir made some > others (from CentOS) at FOSDEM to Tom Callaway. OK, now we're getting somewhere. Details? -- Rex From rdieter at math.unl.edu Mon Mar 19 13:58:27 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 08:58:27 -0500 Subject: Dropping the repotag In-Reply-To: <45FE7D94.5060307@math.unl.edu> References: <45FD476E.9040306@leemhuis.info> <20070318160012.GB31755@neu.nirvana> <45FD6603.2030907@leemhuis.info> <45FD7840.3070902@redhat.com> <20070318174343.GE31755@neu.nirvana> <45FE7D94.5060307@math.unl.edu> Message-ID: <45FE9703.50707@math.unl.edu> Rex Dieter wrote: > Axel Thimm wrote: > >> With my EPEL hat on: "Let's do repotags and keep the peace". > > +1. > Long and short of it: Use repotags or dag/rpmforge won't play ball. > Imo, it's mostly harmless, so "just do it". Sigh, as dag just pointed out, this afterall, is not a blocker. I was only advocating repotag if there were a pot of gold (like rpmforge participation) linked to it's usage. > And, please no more "repotags are bad/evil, let's try other > theoretical-but-never-gonna-happen-in-a-million-years way" arguments. Have I mentioned arguing alternative repotag implementations/workarounds is a waste of time? -- Rex From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 14:04:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 15:04:28 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319142614.b6ea7832.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319150428.c5914439.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 14:37:38 +0100 (CET), Dag Wieers wrote: > > The least-significant portion of %release however is blocked by and abused by > > a dist tag and a repo tag. > > No, it doesn't make the version comparison any more better or worse. Again > I repeat myself, read it slowly and please think: > > Comparing release tags for packages from different repositories > (with or without a repotag) makes no sense because there is *no* > relation. Then why is the repotag included in the version comparison? Why does the repo with the "highest" tag win over packages with a "lower" tag? Why do foo-1.0-1.el4.epel.i386.rpm and foo-1.0-1.el4.blubb.i386.rpm differ in what they contain, what features they offer, how they are patched. even though the package release differs only in a repo tag? > > "Highest" repo tag does win RPM version comparison. > > There is nothing to win. If you don't add a repotag and you get these 2: > > nagios-2.8-2.el5 from EPEL > nagios-2.8-3.el5 from RPMforge > > What does that mean ? It may be as problematic as the case where: > > nagios-2.8-3.el5 from EPEL > nagios-2.8-2.el5 from RPMforge Right. If the two repositories don't collaborate, it can be bad indeed. The 3.el5 release may be worse than the 2.el5 release or vice versa. > Add a repotag to both cases for your amusement, it would not matter. Right. Upgrade race in most-significant portion of %release. Bad. > Now consider: > > nagios-2.8-2.el5 from EPEL > nagios-2.8-2.el5 from RPMforge > > And in all cases, where it is questionable which one *should* have been > taken. Right. Upgrade race. I repeat myself. :) > Summary: there is no defined way which one should come out on top Right, that's why the added repo tag already wins. Upgrade race part #1. Bad. Upgrade part #2 is when 3rd party repos bump release everytime they want to win version comparison always. From rdieter at math.unl.edu Mon Mar 19 14:19:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 09:19:39 -0500 Subject: Repotag In-Reply-To: References: Message-ID: <45FE9BFB.5040908@math.unl.edu> Dag Wieers wrote: > I know you guys think you have enough authority to not require a repotag. authority has nothing to do with it. Point is: is it a good or necessary thing? > And you generally do not care because the default policy will be to tell > people other packages than EPEL are dangerous. imo, you're making a false assumption here. > I don't know if I have to start threaten to make you see the light, but I > strongly consider dropping the repotag if Fedora and Red Hat cannot play > nice. threats will only harm your position/argument, so I'd recommend you don't. -- Rex From dag at wieers.com Mon Mar 19 14:42:58 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 15:42:58 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <20070319145338.0f5ee965.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> <20070319145338.0f5ee965.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 14:44:00 +0100 (CET), Dag Wieers wrote: > > > > > > It still fails for branch-specific (i.e. dist-specific) fixes, where the > > > > > least-significant portion of the full %release value is increased for > > > > > rebuilds or minor fixes: > > > > > > > > > > foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf > > > > > > > > but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in > > > > the first place if you had those repos configured ... > > > > > > And that is flawed. > > > > > > The package release string gets longer without telling anything about > > > which of the packages is newer. Anyone still want to claim that these tags > > > don't influence RPM version comparison? ;) Packagers would be forced to > > > increment the most-significant part of %release, breaking the dist-upgrade > > > path, > > > > > > foo-1.0.0-3.el4.fdr > foo-1.0.0-2.el5.fdr > > > > > > unless superfluous mass-updates and mass-rebuilds are used. > > > > Once again a self-serving example, it has nothing to do with repotags. > > > > foo-1.0.0-3.el4 > foo-1.0.0-2.el5 > > > > I'm sure you could have come up with this: > > > > foo-1.0.0-2.el4.1.fdr < foo-1.0.0-2.el5.0.fdr > > > > Which is exactly how it used to be without the repotag. I can only see bad > > intent in the form of your examples. > > Do you realise that now you've gone as far as comparing a release digit > with a repo tag? No, I am not. In fact I have the same number of components. 2 vs 2 el vs el 4.1 vs 5.0 fdr vs fdr > 2.el4.1 wins over all 2.el4.somerepotag I fail to see how that is a problem ? Since 2 packages from different repositories have no relation. There is no reason why this behaviour is right or wrong. In fact I would expect 2.el4.1 to win over 2.el4.repotag even in a single repository context. (eg. when you add a repotag but older packages have not) That's how RPM was designed, that's how I expect it to be. > Version comparison hell. Upgrade race. Again and again. Bad examples. Bad argumentation. Again and again. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 14:54:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 15:54:02 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> <20070319145338.0f5ee965.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319155402.306e88cd.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 15:42:58 +0100 (CET), Dag Wieers wrote: > > > I'm sure you could have come up with this: > > > > > > foo-1.0.0-2.el4.1.fdr < foo-1.0.0-2.el5.0.fdr > > > > > > Which is exactly how it used to be without the repotag. I can only see bad > > > intent in the form of your examples. > > > > Do you realise that now you've gone as far as comparing a release digit > > with a repo tag? > > No, I am not. In fact I have the same number of components. > > 2 vs 2 > el vs el > 4.1 vs 5.0 > fdr vs fdr ?? Has the proposal been changed? It used to be repotag at the right, so that is _three_ fields instead of four. You would compare packages with three fields against packages with four fields. Unless you want to enforce a very-specific format for %release to be used by all packagers and all repos. E.g. an ugly and inflexible 1%{?dist}.0%{?repo} > > 2.el4.1 wins over all 2.el4.somerepotag > > I fail to see how that is a problem ? > > Since 2 packages from different repositories have no relation. They don't have any relation? How comes? > There is no reason why this behaviour is right or wrong. > > In fact I would expect 2.el4.1 to win over 2.el4.repotag even in a single > repository context. (eg. when you add a repotag but older packages > have not) That's how RPM was designed, that's how I expect it to be. Sure, except that using %dist is confusing enough for several packagers already, as they do things like 2.1.fc6 > 2.fc7 With the repotag the situation doesn't improve. It's another string that enters RPM version comparison. From dag at wieers.com Mon Mar 19 15:05:10 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 16:05:10 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <20070319150428.c5914439.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319142614.b6ea7832.mschwendt.tmp0701.nospam@arcor.de> <20070319150428.c5914439.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 14:37:38 +0100 (CET), Dag Wieers wrote: > > > > The least-significant portion of %release however is blocked by and abused by > > > a dist tag and a repo tag. > > > > No, it doesn't make the version comparison any more better or worse. Again > > I repeat myself, read it slowly and please think: > > > > Comparing release tags for packages from different repositories > > (with or without a repotag) makes no sense because there is *no* > > relation. > > Then why is the repotag included in the version comparison? It's a tradeoff that has no effect on release comparison. The repotag was not intended to influence release comparison. The repotag is useful for other reasons and the easiest way to add itr without redesigning RPM is to add it there. Maybe you can work out with the RPM maintainers to improve it in the future. But we discussed this 5 years ago and it hasn't happened yet. > Why does the repo with the "highest" tag win over packages with a "lower" > tag? Because that's how the algorithm was designed to work. But since there is no relation between release of different repositories, it does not matter. > Why do foo-1.0-1.el4.epel.i386.rpm and foo-1.0-1.el4.blubb.i386.rpm differ > in what they contain, what features they offer, how they are patched. > even though the package release differs only in a repo tag? Because they are maintained by different people that have different ideas what goes in and what doesn't. Different set of patches, as close to upstream as possible, whatever. > > > "Highest" repo tag does win RPM version comparison. > > > > There is nothing to win. If you don't add a repotag and you get these 2: > > > > nagios-2.8-2.el5 from EPEL > > nagios-2.8-3.el5 from RPMforge > > > > What does that mean ? It may be as problematic as the case where: > > > > nagios-2.8-3.el5 from EPEL > > nagios-2.8-2.el5 from RPMforge > > Right. If the two repositories don't collaborate, it can be bad indeed. > The 3.el5 release may be worse than the 2.el5 release or vice versa. Sure, but that's up to the user (or hopefully the dep resolver) to decide. It really is up to whoever decides to use another repository, for whatever reason you cannot contain. And yum, apt, whatever should allow to define a policy. What repository to use for what ? Whether to restrict based on (only) version (from that repo). Fact is that if the user specifies to use a package from another repository, it only gets updated from that repository unless he overrides that behaviour again. Functionality like that can only exist if there is a mindset that multiple repository will exist. With Fedora this mindset has been destroyed and as a result the tools do not allow it. Which in its turn killed the diversity. For Fedora Extras that might have been a good thing, but for RHEL that will lead to problems. > > Add a repotag to both cases for your amusement, it would not matter. > > Right. Upgrade race in most-significant portion of %release. Bad. You haven't proved that and it doesn't matter anyhow. Releases from different repositories have no relation. (repeat after me) > > Now consider: > > > > nagios-2.8-2.el5 from EPEL > > nagios-2.8-2.el5 from RPMforge > > > > And in all cases, where it is questionable which one *should* have been > > taken. > > Right. Upgrade race. I repeat myself. :) Doesn't matter, none of these are intrinsically higher anyway. > > Summary: there is no defined way which one should come out on top > > Right, that's why the added repo tag already wins. Upgrade race part #1. > Bad. Upgrade part #2 is when 3rd party repos bump release everytime they > want to win version comparison always. There is no upgrade race between repositories because there should not be an upgrade path. As long as you think that a repotag will be bad for the upgrade path between repositories, you assume there is an upgrade path between repositories that have packages with the same version. It's all in your head. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Mon Mar 19 15:10:35 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 16:10:35 +0100 (CET) Subject: Repotag In-Reply-To: <45FE9BFB.5040908@math.unl.edu> References: <45FE9BFB.5040908@math.unl.edu> Message-ID: On Mon, 19 Mar 2007, Rex Dieter wrote: > Dag Wieers wrote: > > > I know you guys think you have enough authority to not require a repotag. > > authority has nothing to do with it. Point is: is it a good or necessary > thing? Well, the discussions have proven that EPEL considers itself upstream. And that a multi repository world is not wanted. I know this mindset exists and this is one of the reasons why I think Fedora is badly positioned to decide over RHEL packages. > > And you generally do not care because the default policy will be to tell > > people other packages than EPEL are dangerous. > > imo, you're making a false assumption here. That is what happened with Fedora Extras. RPMforge has been badmouthed because it was not upstream and a lot of FUD has been spread. In the end all the actions proof that a multi repository world was never wanted and we are now stuck with suboptimal tools that do not allow things that are perfectly valid. > > I don't know if I have to start threaten to make you see the light, but I > > strongly consider dropping the repotag if Fedora and Red Hat cannot play > > nice. > > threats will only harm your position/argument, so I'd recommend you don't. Whatever. All the arguments have been made in the past without any treaths. If the only extra argument I can make is that I drop the repotag just to follow Fedora's EPEL policy than that is what I will do. Just think of the consequences, whether you consider that a threat or not. (Apparently you only joined late in the discussions and someone pointed out my initial mail to have a change of opinion :)) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Mon Mar 19 15:14:14 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 19 Mar 2007 16:14:14 +0100 (CET) Subject: My thoughts on repotag In-Reply-To: <20070319155402.306e88cd.mschwendt.tmp0701.nospam@arcor.de> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> <20070319145338.0f5ee965.mschwendt.tmp0701.nospam@arcor.de> <20070319155402.306e88cd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Mon, 19 Mar 2007, Michael Schwendt wrote: > On Mon, 19 Mar 2007 15:42:58 +0100 (CET), Dag Wieers wrote: > > > > > I'm sure you could have come up with this: > > > > > > > > foo-1.0.0-2.el4.1.fdr < foo-1.0.0-2.el5.0.fdr > > > > > > > > Which is exactly how it used to be without the repotag. I can only see bad > > > > intent in the form of your examples. > > > > > > Do you realise that now you've gone as far as comparing a release digit > > > with a repo tag? > > > > No, I am not. In fact I have the same number of components. > > > > 2 vs 2 > > el vs el > > 4.1 vs 5.0 > > fdr vs fdr > > ?? Has the proposal been changed? It used to be repotag at the right, so > that is _three_ fields instead of four. You would compare packages with > three fields against packages with four fields. Unless you want to enforce > a very-specific format for %release to be used by all packagers and all > repos. E.g. an ugly and inflexible 1%{?dist}.0%{?repo} No, I added that after you mentioned it, assuming that is where you wanted to go. (You cut the part with your example) > > > 2.el4.1 wins over all 2.el4.somerepotag > > > > I fail to see how that is a problem ? > > > > Since 2 packages from different repositories have no relation. > > They don't have any relation? How comes? Because if RPMforge has release 3 and EPEL has release 4 you don't know what patches one has, or if one is an improvement over the other. You don't know, they are not based on the same SPEC file. Not the same repository. Hello ? > > There is no reason why this behaviour is right or wrong. > > > > In fact I would expect 2.el4.1 to win over 2.el4.repotag even in a single > > repository context. (eg. when you add a repotag but older packages > > have not) That's how RPM was designed, that's how I expect it to be. > > Sure, except that using %dist is confusing enough for several packagers > already, as they do things like 2.1.fc6 > 2.fc7 Right. That's why I thought you mentioned the above example. > With the repotag the situation doesn't improve. It's another string > that enters RPM version comparison. It doesn't improve, but doesn't worsen either. The repotag will not fix any deficits that you see with the disttag. If that was your expectation, I have to disappoint you. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rdieter at math.unl.edu Mon Mar 19 15:22:42 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 10:22:42 -0500 Subject: Repotag In-Reply-To: References: <45FE9BFB.5040908@math.unl.edu> Message-ID: <45FEAAC2.5010601@math.unl.edu> Dag Wieers wrote: > On Mon, 19 Mar 2007, Rex Dieter wrote: > >> Dag Wieers wrote: >> >>> I know you guys think you have enough authority to not require a repotag. >> authority has nothing to do with it. Point is: is it a good or necessary >> thing? > > Well, the discussions have proven that EPEL considers itself upstream. > And that a multi repository world is not wanted. imo, not true and irrelevant to boot. Anyone saying otherwise is selling something. And I'm not buying it. Please don't let the voices of a select few speak for all of EPEL. >>> And you generally do not care because the default policy will be to tell >>> people other packages than EPEL are dangerous. >> imo, you're making a false assumption here. > That is what happened with Fedora Extras. RPMforge has been badmouthed > because it was not upstream and a lot of FUD has been spread. That's in the past, *long* past. Again, not true anymore, yada yada. Please, since repotags aren't a blocker for you, can we *please* try to focus on the more-important issues that are? -- Rex From fedora at leemhuis.info Mon Mar 19 15:29:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 16:29:04 +0100 Subject: Repotag In-Reply-To: References: <45FE9BFB.5040908@math.unl.edu> Message-ID: <45FEAC40.20505@leemhuis.info> On 19.03.2007 16:10, Dag Wieers wrote: > Well, the discussions have proven that EPEL considers itself upstream. Huh? Where? There is no "upstream" in this game afaics. > And that a multi repository world is not wanted. I disagree. My opinion in one sentence: "A Mixing-repository-that were-not-designed-to-be-mixed world is not liked by many Fedora users afaics". Better tools could change that. Further: I have no problem with EPEL and rpmforge living in parallel. I actually would like it to be that way, as they afaics will serve different proposes: EPEL will be more careful and not replace packages from the base while rpmforge is more "bleeding edge". I think both approaches have there userbase. CU thl From Axel.Thimm at ATrpms.net Mon Mar 19 15:51:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 16:51:22 +0100 Subject: Repotag In-Reply-To: References: <45FE9BFB.5040908@math.unl.edu> Message-ID: <20070319155122.GA2212@neu.nirvana> On Mon, Mar 19, 2007 at 04:10:35PM +0100, Dag Wieers wrote: > Well, the discussions have proven that EPEL considers itself upstream. > And that a multi repository world is not wanted. I know this mindset > exists Don't let one person (?) on this list that by himself even proclaims not to be involved with EPEL fool you. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 19 15:57:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 16:57:45 +0100 Subject: Dropping the repotag In-Reply-To: <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319155745.GB2212@neu.nirvana> On Mon, Mar 19, 2007 at 12:38:33PM +0100, Michael Schwendt wrote: > Afterall, there's still the same hypocrisy in threads like this, no signs > of actual cooperation or collaboration, but only attempts at influencing a ========================= > project's decisions from the outside without getting involved. ============================================================== > The only difference in how I've changed is that I am not involved in EPEL, ========================= > so feel free to agree on something without my blessing. ;) OK, so you admit that it's a bad thing to influence a project from the outside when you're not involved, and you are not involved, but try to influence the project's decisions on fedora-usermgmt and repotags. Hm, now is it me or is there a blatant contradiction in the above? Or are you just saying that you're doing bad things and enjoy them? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 16:21:49 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 17:21:49 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319142614.b6ea7832.mschwendt.tmp0701.nospam@arcor.de> <20070319150428.c5914439.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319172149.9b658146.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 16:05:10 +0100 (CET), Dag Wieers wrote: > > > Comparing release tags for packages from different repositories > > > (with or without a repotag) makes no sense because there is *no* > > > relation. > > > > Then why is the repotag included in the version comparison? > > It's a tradeoff that has no effect on release comparison. It _is_ part of %release. It _is_ added to automatic versioned Provides. It _is_ added to manual Requires/Obsoletes/Conflicts that use %{release}. And all that is in addition to %dist, which must be considered in versioned Requires/Obsoletes/Conflicts already. Yet what benefit does it result in? A tradeoff? Just to give users a questionable way to see whose packages cause trouble during a yum update? > The repotag was not intended to influence release comparison. Nobody has said that this would be its intention. Still it is the least-significant portion of the package %release. > The repotag > is useful for other reasons and the easiest way to add itr without > redesigning RPM is to add it there. The easier way to add it is to use the Vendor tag and introduce a short macro with which to query the RPM database. Think repoquery, yum queries, tools that show the repository/vendor a package comes from. > > Why does the repo with the "highest" tag win over packages with a "lower" > > tag? > > Because that's how the algorithm was designed to work. But since there is > no relation between release of different repositories, it does not matter. A repository is either made to be a) compatible or b) incompatible. For a) either party can take precautions. For b) one party can make sure its packages win version comparison. a) is hurt when packages upgrade eachother just because of a different repotag. For b) there better is the recommendation to disable the incompatible repos in order to avoid potential trouble and upgrade races. Especially when upgrades add/remove features, your users do not like that at all. > > Why do foo-1.0-1.el4.epel.i386.rpm and foo-1.0-1.el4.blubb.i386.rpm differ > > in what they contain, what features they offer, how they are patched. > > even though the package release differs only in a repo tag? > > Because they are maintained by different people that have different ideas > what goes in and what doesn't. Different set of patches, as close to > upstream as possible, whatever. So, incompatible repos. Case closed. > Functionality like that can only exist if there is a mindset that > multiple repository will exist. With Fedora this mindset has been > destroyed and as a result the tools do not allow it. The only form of cooperation and collaboration that exists is added by a few individuals, who have become Fedora Extras maintainers while continueing with their private repositories. Nothing else has been worked on. No guidelines, no policies. Nothing. > Which in its turn killed the diversity. For Fedora Extras that might have > been a good thing, but for RHEL that will lead to problems. RHEL/EPEL must be even more careful about what software and what upstream releases they decide to ship. Fedora Extras over the past months has presented several examples of packages, where team-work would have been much better. EPEL will hopefully evaluate carefully what they include and how that compares with existing 3rd party repos such as yours. > > > Add a repotag to both cases for your amusement, it would not matter. > > > > Right. Upgrade race in most-significant portion of %release. Bad. > > You haven't proved that and it doesn't matter anyhow. ".rf" is higher than ".fdr" 1.*.rf > 1.*.fdr => upgrade 2.*.fdr > 1.*.rf => upgrade 2.*.rf > 2.*.fdr => upgrade qed Either the repos are compatible in that mixing them is not considered a problem. Or they are designed to be incompatible and error-prone to use, because even the slightest change in %release causes upgrades. > Releases from different repositories have no relation. (repeat after me) Then they ought not be enabled at once. From greg at runlevel7.ca Mon Mar 19 16:48:25 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Mon, 19 Mar 2007 09:48:25 -0700 Subject: My thoughts on repotag In-Reply-To: <20070319172149.9b658146.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <5B8B3D66554D0246BF6D224D9E8169E00343E8B9@snshbea106.4smartphone.snx> Michael Schwendt wrote: > On Mon, 19 Mar 2007 16:05:10 +0100 (CET), Dag Wieers wrote: > > Releases from different repositories have no relation. (repeat after me) > > Then they ought not be enabled at once. Michael. You made your point clear that you don't care about anything except EPEL. Can you please stop posting on the subject, as the majority of people here are trying to get everyone to work together. For you, and those like you, that just enable EPEL and nothing else - the added repotag does no harm. Dag, I am also interested to know what other issues you have about working with EPEL. I would think you'd want to lighten the load a bit - you do look after a lot of packages ;-) Thanks, Greg Swallow From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 16:51:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 17:51:02 +0100 Subject: Dropping the repotag In-Reply-To: <20070319155745.GB2212@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> <20070319155745.GB2212@neu.nirvana> Message-ID: <20070319175102.f5824658.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 16:57:45 +0100, Axel Thimm wrote: > > Afterall, there's still the same hypocrisy in threads like this, no signs > > of actual cooperation or collaboration, but only attempts at influencing a > ========================= > > project's decisions from the outside without getting involved. > ============================================================== > > > The only difference in how I've changed is that I am not involved in EPEL, > ========================= > > so feel free to agree on something without my blessing. ;) > > OK, so you admit that it's a bad thing to influence a project from the > outside when you're not involved, and you are not involved, but try to > influence the project's decisions on fedora-usermgmt and repotags. > > Hm, now is it me or is there a blatant contradiction in the above? Or > are you just saying that you're doing bad things and enjoy them? ;) Uh, come on, twisting words like that is a poor style. What has fedora-usermgmt to do with this? And why do you jump from "influence" to "bad things" in general? The sentences can't be so difficult to understand. There are requests for EPEL to do something in a way that allegedly fosters cooperation between EPEL and 3rd party repositories, but at the same time it is pointed out clearly that there are no intentions to make the repositories and packages compatible actually. Now, perhaps you've focused on attacking me blindly again, so let me make this clear. I don't request anything. I voice my concerns. You will enjoy the next sentence, since it is food for your rhetorical exercises, and you will rub your hands when you read it. ;) I have no particular interest in seeing fedora-usermgmt being used in EPEL packages. Rip this sentence out of context if you like to. But don't forget that I only participated in the discussion to correct some untruths that have been written about it. WRT repotags it is similar. Go ahead and add them if you see the benefit. Who cares about an upgrade path between RHEL4 and RHEL5 anyway? ;) The thing that concerns me is the relevance to Fedora. There are people from Fedora committees involved in these discussions. And they ought to know better before they introduce mandatory repotags, disttags and other unclean solutions. From tcallawa at redhat.com Mon Mar 19 16:52:17 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 19 Mar 2007 11:52:17 -0500 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1174323137.3484.19.camel@dhcp120.install.boston.redhat.com> On Mon, 2007-03-19 at 13:50 +0100, Dag Wieers wrote: > It makes not difference what the release is. Whether it influences the > release comparison or not, releases cannot be compared between > repositories. There is no relation. Alright. So, I was under the assumption that repotag was being used to compare packages between repositories. This is apparently not the case. Can you reiterate the actual problem that we need to solve here? :) It may turn out that using a repotag solves a problem, but I'd much rather approach the problem before arguing about the solution. ~spot From tcallawa at redhat.com Mon Mar 19 16:53:46 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 19 Mar 2007 11:53:46 -0500 Subject: rpmforge blockers In-Reply-To: <45FE9629.3070702@math.unl.edu> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <45FE88B6.3070004@math.unl.edu> <45FE9629.3070702@math.unl.edu> Message-ID: <1174323226.3484.21.camel@dhcp120.install.boston.redhat.com> On Mon, 2007-03-19 at 08:54 -0500, Rex Dieter wrote: > Dag Wieers wrote: > > > I've discussed a few of the blockers we have to join EPEL (which are > > mostly related to how we build, what one is allowed to do with SPEC files > > and what policies there are for maintaining them). And Karanbir made some > > others (from CentOS) at FOSDEM to Tom Callaway. > > OK, now we're getting somewhere. > > Details? I did ask for these blockers to be documented in email. Never got anything in writing, from anyone. I'd still like to hear them, either publicly or privately. ~spot From greg at runlevel7.ca Mon Mar 19 17:02:46 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Mon, 19 Mar 2007 10:02:46 -0700 Subject: rpmforge blockers In-Reply-To: <1174323226.3484.21.camel@dhcp120.install.boston.redhat.com> Message-ID: <5B8B3D66554D0246BF6D224D9E8169E00343E8DA@snshbea106.4smartphone.snx> Tom 'spot' Callaway wrote: > On Mon, 2007-03-19 at 08:54 -0500, Rex Dieter wrote: > > Dag Wieers wrote: > > > > > I've discussed a few of the blockers we have to join EPEL (which are > > > mostly related to how we build, what one is allowed to do with SPEC > files > > > and what policies there are for maintaining them). And Karanbir made > some > > > others (from CentOS) at FOSDEM to Tom Callaway. > > > > OK, now we're getting somewhere. > > > > Details? > > I did ask for these blockers to be documented in email. Never got > anything in writing, from anyone. I'd still like to hear them, either > publicly or privately. I am not a @centos.org person, but I am on their -devel list... I think there is some confusion/misinterpretation of the Fedora CLA that is causing some hesitation - http://lists.centos.org/pipermail/centos-devel/2007-March/003186.html - Maybe contact them again. Greg From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 17:07:32 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 18:07:32 +0100 Subject: My thoughts on repotag In-Reply-To: References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <20070319143653.1243b0b1.mschwendt.tmp0701.nospam@arcor.de> <20070319145338.0f5ee965.mschwendt.tmp0701.nospam@arcor.de> <20070319155402.306e88cd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319180732.30e91769.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 16:14:14 +0100 (CET), Dag Wieers wrote: > > > Since 2 packages from different repositories have no relation. > > > > They don't have any relation? How comes? > > Because if RPMforge has release 3 and EPEL has release 4 you don't know > what patches one has, or if one is an improvement over the other. Then apparently there is no cooperation or collaboration, and its dangerous to switch back and forth between EPEL and RPMforge as both repos add/remove features and bump release without coordinating that. > You don't know, they are not based on the same SPEC file. Not the same > repository. Hello ? Hello what? If there is no relationship between the packages, you still want the repositories to be mixable and packages recognisable by file name? From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 17:12:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 18:12:50 +0100 Subject: My thoughts on repotag In-Reply-To: <1174323137.3484.19.camel@dhcp120.install.boston.redhat.com> References: <1174273527.4310.62.camel@localhost.localdomain> <20070319121201.8830b1fc.mschwendt.tmp0701.nospam@arcor.de> <1174323137.3484.19.camel@dhcp120.install.boston.redhat.com> Message-ID: <20070319181250.e23b4eb7.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 11:52:17 -0500, Tom 'spot' Callaway wrote: > On Mon, 2007-03-19 at 13:50 +0100, Dag Wieers wrote: > > > It makes not difference what the release is. Whether it influences the > > release comparison or not, releases cannot be compared between > > repositories. There is no relation. > > Alright. So, I was under the assumption that repotag was being used to > compare packages between repositories. This is apparently not the case. > > Can you reiterate the actual problem that we need to solve here? :) > > It may turn out that using a repotag solves a problem, but I'd much > rather approach the problem before arguing about the solution. The repotag is supposed to be a human-readable repository identifier in the package NEVR. Its sole purpose is in aiding users in choosing the right bug tracking system where to report problems with a repository's packages during a repository mixing scenario. The side-effects and consequences of extending %release are ignored. It's called a trade-off without interest in the alternative solutions like "Vendor:". From Axel.Thimm at ATrpms.net Mon Mar 19 17:13:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 18:13:18 +0100 Subject: Dropping the repotag In-Reply-To: <20070319175102.f5824658.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070319123833.7e1564dd.mschwendt.tmp0701.nospam@arcor.de> <20070319155745.GB2212@neu.nirvana> <20070319175102.f5824658.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319171318.GG14393@neu.nirvana> On Mon, Mar 19, 2007 at 05:51:02PM +0100, Michael Schwendt wrote: > On Mon, 19 Mar 2007 16:57:45 +0100, Axel Thimm wrote: > > > > Afterall, there's still the same hypocrisy in threads like this, no signs > > > of actual cooperation or collaboration, but only attempts at influencing a > > ========================= > > > project's decisions from the outside without getting involved. > > ============================================================== > > > > > The only difference in how I've changed is that I am not involved in EPEL, > > ========================= > > > so feel free to agree on something without my blessing. ;) > > > > OK, so you admit that it's a bad thing to influence a project from the > > outside when you're not involved, and you are not involved, but try to > > influence the project's decisions on fedora-usermgmt and repotags. > > > > Hm, now is it me or is there a blatant contradiction in the above? Or > > are you just saying that you're doing bad things and enjoy them? ;) > > Uh, come on, twisting words like that is a poor style. Simple underlining can't be considered twisting. > Now, perhaps you've focused on attacking me blindly again, so let me make > this clear. I don't request anything. I voice my concerns. What makes you think I enjoy attacking you blindly? And you voiced your concerns quite enough times, we all got it. > You will enjoy the next sentence, since it is food for your > rhetorical exercises, and you will rub your hands when you read > it. ;) I have no particular interest in seeing fedora-usermgmt being > used in EPEL packages. Rip this sentence out of context if you like > to. But don't forget that I only participated in the discussion to > correct some untruths that have been written about it. No, I already supected that all you wanted are endless threads w/o any particular interest in either topic. > WRT repotags it is similar. Indeed ... > Go ahead and add them if you see the benefit. Who cares about an > upgrade path between RHEL4 and RHEL5 anyway? ;) Even with the smiley I really fail to see the joke. > The thing that concerns me is the relevance to Fedora. Just in case you misunderstood, no one suggested adding repotags to Fedora. > There are people from Fedora committees involved in these > discussions. And they ought to know better before they introduce > mandatory repotags, disttags and other unclean solutions. Indeed I'm one of them in favour of clean disttags and repotags. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 13:48:12 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 14:48:12 +0100 Subject: Dropping the repotag In-Reply-To: References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <45FD9C28.6030701@runlevel7.ca> <20070318213519.a0f316c6.mschwendt.tmp0701.nospam@arcor.de> <20070319072218.GE4773@neu.nirvana> <20070319123938.af3e7fc6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319144812.7d323223.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 14:02:02 +0100 (CET), Dag Wieers wrote: > > > > Everything other than a clear "Vendor" id in the package header is > > > > broken. It is only a matter of time before independent packagers not only > > > > set %dist, but also the repotag, mimicking Fedora or EPEL packages. > > > > > > This is far fetched science ficition. Disttags and repotags have been > > > around long before Fedora existed and no repo was as brain-damaged to > > > copy over another repo's repotag. > > > > Check your facts. No further comment. > > No, check *your* facts. > > fedora.us is not the Fedora project. And even if it were, repotags have > been used in fedora.us _before_ the Fedora project. You didn't get it. Let me help you. Quote: > no repo was as brain-damaged to > copy over another repo's repotag. That is not true. Period. From dlutter at redhat.com Mon Mar 19 18:01:33 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 19 Mar 2007 18:01:33 +0000 Subject: rpms that just need a rebuild... In-Reply-To: <20070317183814.GD11578@neu.nirvana> References: <45EE55C7.5090705@runlevel7.ca> <1174087476.10131.13.camel@localhost.localdomain> <20070317183814.GD11578@neu.nirvana> Message-ID: <1174327293.10131.34.camel@localhost.localdomain> On Sat, 2007-03-17 at 19:38 +0100, Axel Thimm wrote: > > It would be very interesting to have a uniform way to provide RHEL-addon > > packages that are unsupported. This would help people who want to > > evaluate things on RHEL that are available on Fedora, but aren't in a > > state that can be supported by EPEL's or RHEL's standards. > > Then better massage them to meet those standards? It's mainly an issue of how fast those projects change upstream and how mature they are, not so much one of packaging. I.e., you want to make it easy to try them out on RHEL even when you know that they change too rapidly to guarantee API stability etc. David From Axel.Thimm at ATrpms.net Mon Mar 19 20:41:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 21:41:52 +0100 Subject: rpms that just need a rebuild... In-Reply-To: <1174327293.10131.34.camel@localhost.localdomain> References: <45EE55C7.5090705@runlevel7.ca> <1174087476.10131.13.camel@localhost.localdomain> <20070317183814.GD11578@neu.nirvana> <1174327293.10131.34.camel@localhost.localdomain> Message-ID: <20070319204152.GD18607@neu.nirvana> On Mon, Mar 19, 2007 at 06:01:33PM +0000, David Lutterkort wrote: > On Sat, 2007-03-17 at 19:38 +0100, Axel Thimm wrote: > > > It would be very interesting to have a uniform way to provide RHEL-addon > > > packages that are unsupported. This would help people who want to > > > evaluate things on RHEL that are available on Fedora, but aren't in a > > > state that can be supported by EPEL's or RHEL's standards. > > > > Then better massage them to meet those standards? > > It's mainly an issue of how fast those projects change upstream and how > mature they are, not so much one of packaging. I.e., you want to make it > easy to try them out on RHEL even when you know that they change too > rapidly to guarantee API stability etc. If it's that experimental and changing then perhaps it's better off in some packager's private repo like p.r.c etc.? Otherwise putting it in a repo where we usually put stuff for doing QA for either updates for the current RHEL release ("updates-testing") or even for an upcoming ("rawhide") would not be that good, as we'd like to draw testers to these repos. Just to get the picture about what degree of maturity you are targeting: Where would you place such projects if it were about Fedora and not RHEL? Rawhide, current Fedora release or not at all? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Mon Mar 19 23:10:42 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 19 Mar 2007 23:10:42 +0000 Subject: rpms that just need a rebuild... In-Reply-To: <20070319204152.GD18607@neu.nirvana> References: <45EE55C7.5090705@runlevel7.ca> <1174087476.10131.13.camel@localhost.localdomain> <20070317183814.GD11578@neu.nirvana> <1174327293.10131.34.camel@localhost.localdomain> <20070319204152.GD18607@neu.nirvana> Message-ID: <1174345842.10131.62.camel@localhost.localdomain> On Mon, 2007-03-19 at 21:41 +0100, Axel Thimm wrote: > If it's that experimental and changing then perhaps it's better off in > some packager's private repo like p.r.c etc.? That's what I (and lots of others) are doing currently. The point of what I am talking about is to help users by removing the need to chase lots of different repos. > Just to get the picture about what degree of maturity you are > targeting: Where would you place such projects if it were about Fedora > and not RHEL? Rawhide, current Fedora release or not at all? Rawhide and current Fedora release. The stumbling stone for what I am talking about compared to the EPEL discussions so far is the long-term support and API guarantees; in other words, people that use these packages can expect them to work at a level similar to Fedora packages, but will need to be prepared for some churn and possibly incompatible changes. David From mschwendt.tmp0701.nospam at arcor.de Sun Mar 18 23:41:51 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 00:41:51 +0100 Subject: Dropping the repotag In-Reply-To: <20070318225421.GD4773@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> Message-ID: <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> On Sun, 18 Mar 2007 23:54:21 +0100, Axel Thimm wrote: > %dist bad? How come? It has been beaten to death in past discussions with several real-world examples. > It gives us nice upgrade paths w/o juggling > through several *different* specfiles per distro That's a myth. It breaks already when somebody creates CD/DVD snapshots of the distribution and performs a dist upgrade. That is because many packagers bump %version and %release way too often and in ways that strictly depend on a rolling-release with online updates. %dist cannot fix that. To fix the upgrade path, it would need a dist epoch, that is separate from ordinary RPM version comparison. > just for the sake of > human-controlled and human-error-prone housekeeping. *lol* How some packagers rely on %dist when copying a spec from devel to older branches, creates nothing else than chaos. > > > A repotag is simply for a quick identification of a packge, be it > > > in a simple rpm -qa list or as a package filename. That's all > > > there is to it, it's not a magical compatibility layer. > > > > Quick, maybe, but error-prone, as independent packagers already use %dist > > in the same way Fedora and Livna do. And Livna's tag is a two-in-one > > repo+dist tag. > > I'm not sure if you mena that as a praise or blame. There is nothing > wrong with livna's tagging. It is indeed a shortened and otherwise > unusual disttag/repotag, but it fully serves its cause. It's a good example of a pitfall. A package is from Livna, when it is signed with Livna's key, not necessarily when it has "lvn" somewhere in the file name. Users all around the world have been fooled by that before in the same way they've been fooled by other tags. > > > And it's a matter of cooperation: Do we want EPEL to cooperate with > > > existing 3rd party repos, or do we want EPEL to not do so and create a > > > new rift? It's so much more a political issue than a technical one. > > > > I have no doubts that you think about cooperation as you've already joined > > the fun with Fedora Extras. That doesn't apply to other repositories, > > though. What cooperation is reality for Fedora Extras and Fedora Core, for > > instance? Are there guidelines? A SIG with close contact to 3rd party > > maintainers? A steady exchange of bug reports, fixes, testing results? > > Why raise the bar that high? This is just making things more difficult > to accomplish. Maybe all this kind of cooperation needs small signs of > willingness to cooperate before a whole framework of sig, rules and > further procedures is put up? It is long ago since we've talked about forms of cooperation and collaboration for the first time. Yet it is still not carved into stone anywhere as what cooperation exists actually. Assume libfoo is offered by EPEL *and* a 3rd party repository. The repotag flags the package as coming from the 3rd party. A user is fully aware of the repotag and submits a bug report to the 3rd party. Where is the benefit of polluting %release (which influences RPM version comparison) and file names with more values, that ought not be part of the package release? Is it still only that the EPEL packager needs to find out about any 3rd party package that might be "out there" and lurk in bug reporting channels to learn about problems that affect compatibility with EPEL or affect EPEL, too? Has anything been done on making actual cooperation become reality? From Axel.Thimm at ATrpms.net Tue Mar 20 09:32:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 10:32:08 +0100 Subject: Completely OT: Remove disttag from EPEL and Fedora ... (was: Dropping the repotag) In-Reply-To: <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070320093208.GC14567@neu.nirvana> On Mon, Mar 19, 2007 at 12:41:51AM +0100, Michael Schwendt wrote: > On Sun, 18 Mar 2007 23:54:21 +0100, Axel Thimm wrote: > > %dist bad? How come? > > It has been beaten to death in past discussions with several > real-world examples. The *real-world* examples are half of Fedora and the sum of all 3rd party repos comprising several thousand packages outweighing by far the packages that still resit to disttags. So please no academic examples, disttags have proven extremely useful no matter what you try to imply. > > It gives us nice upgrade paths w/o juggling through several > > *different* specfiles per distro > > That's a myth. You myth is a myth. A meta-myth, so to say. > > just for the sake of human-controlled and human-error-prone > > housekeeping. > > *lol* How some packagers rely on %dist when copying a spec from devel to > older branches, creates nothing else than chaos. Stop exaggerationg please. Even if you can point out one or two messed up backports, it would had been quite worse if the packager had to restart guessing how the non-intuitive rpm ordering works, to set up the upgrade paths. rpm ordering twists your brain and disttags aid in keeping your brain sane. Please, this discussion is an echo from the past on the wrong list and on the wrong topic. This is about whether EPEL wants to add a repotag to the disttag, not whether EPEL is going to remove disttags or whether Fedora will do so. > It is long ago since we've talked about forms of cooperation and > collaboration for the first time. > > Yet it is still not carved into stone anywhere as what cooperation exists > actually. Yes, because people like you resisted and still resist on any kind of cooperation. The repotag costs nothing and is yet a political vehicle to signal to 3rd repos that EPEL is willing to cooperate. You are trying to find all kind of excuses to have EPEL go a route where it will become isolated, and you will be returning and will say that there was no cooperation. A self-fulfilling prophecy. Don't torpedo the cooperation efforts anymore, please. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Tue Mar 20 10:46:42 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 20 Mar 2007 11:46:42 +0100 Subject: Completely OT: Remove disttag from EPEL and Fedora ... (was: Dropping the repotag) In-Reply-To: <20070320093208.GC14567@neu.nirvana> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> <20070320093208.GC14567@neu.nirvana> Message-ID: <20070320114642.fbb19a3e.mschwendt.tmp0701.nospam@arcor.de> On Tue, 20 Mar 2007 10:32:08 +0100, Axel Thimm wrote: > On Mon, Mar 19, 2007 at 12:41:51AM +0100, Michael Schwendt wrote: > > On Sun, 18 Mar 2007 23:54:21 +0100, Axel Thimm wrote: > > > %dist bad? How come? > > > > It has been beaten to death in past discussions with several > > real-world examples. > > The *real-world* examples are half of Fedora and the sum of all 3rd > party repos comprising several thousand packages outweighing by far > the packages that still resit to disttags. So please no academic > examples, disttags have proven extremely useful no matter what you try > to imply. Your reply to an old message, that has taken many hours to be delivered, shows that it is not just me who keeps making this thread longer. Because %dist tags are not undisputed, they have not been made mandatory. They may be helpful for mass-updates to multiple distribution targets (a pitfall for some packagers, unfortunately). But they don't solve anything beyond that. They create problems for the average non-freak packager, e.g. when tagging package releases and having to fix something afterwards. And they do not solve the dist-upgrade path problem, because %release is less significant than %version. This is a known thing for many years, even before %dist tags were invented as a form of package branding. > > It is long ago since we've talked about forms of cooperation and > > collaboration for the first time. > > > > Yet it is still not carved into stone anywhere as what cooperation exists > > actually. > > Yes, because people like you resisted and still resist on any kind of > cooperation. How? When? "Resist on any kind of cooperation"? Perhaps you've learned in not so recent threads that you can drive me off a mailing-list with personal insults when everything else doesn't help. > The repotag costs nothing and is yet a political vehicle to signal to > 3rd repos that EPEL is willing to cooperate. Cooperate in what way? The packages don't relate to eachother, yet they are compared with eachother in RPM version comparison. From dag at wieers.com Tue Mar 20 11:03:31 2007 From: dag at wieers.com (Dag Wieers) Date: Tue, 20 Mar 2007 12:03:31 +0100 (CET) Subject: Completely OT: Remove disttag from EPEL and Fedora ... (was: Dropping the repotag) In-Reply-To: <20070320114642.fbb19a3e.mschwendt.tmp0701.nospam@arcor.de> References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> <20070320093208.GC14567@neu.nirvana> <20070320114642.fbb19a3e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Tue, 20 Mar 2007, Michael Schwendt wrote: > On Tue, 20 Mar 2007 10:32:08 +0100, Axel Thimm wrote: > > On Mon, Mar 19, 2007 at 12:41:51AM +0100, Michael Schwendt wrote: > > > On Sun, 18 Mar 2007 23:54:21 +0100, Axel Thimm wrote: > > > > %dist bad? How come? > > > > > > It has been beaten to death in past discussions with several > > > real-world examples. > > > > The *real-world* examples are half of Fedora and the sum of all 3rd > > party repos comprising several thousand packages outweighing by far > > the packages that still resit to disttags. So please no academic > > examples, disttags have proven extremely useful no matter what you try > > to imply. > > Your reply to an old message, that has taken many hours to be delivered, > shows that it is not just me who keeps making this thread longer. > > Because %dist tags are not undisputed, they have not been made mandatory. > > They may be helpful for mass-updates to multiple distribution targets > (a pitfall for some packagers, unfortunately). > But they don't solve anything beyond that. They create problems for the > average non-freak packager, e.g. when tagging package releases and having > to fix something afterwards. > And they do not solve the dist-upgrade path problem, because %release > is less significant than %version. This is a known thing for many years, > even before %dist tags were invented as a form of package branding. It doesn't fix the world food problem either. This is a known thing for many years as well. Let's drop the dist tag and the repo tag ! That won't fix the world food problem either, but hey, it's an argument like any other. Let's kill the discussion with bogus arguments so normal people don't understand anything anymore and get sick of the thread and the topic as well. I've seen the tactic before. The majority of my users think a repotag and disttag is useful. I think you're the only one denying the use of both. Others at least accept it does fix something. Whether they believe it is a real issue is something else. Fact is, I will stop using a repotag since EPEL is not coming to a conclusion and I think it never will. This is going nowhere. PS One of the reasons blocking me from joining EPEL is exactly discussions like this. It burned me out during the initial Fedora Extras discussions as well. And it drove me from the Fedora mailinglists. And you (and Jeff) were directly responsible for that. I just don't have the time to read or reply to discussions like this with you. So whatever you blame Axel for... Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mschwendt.tmp0701.nospam at arcor.de Tue Mar 20 11:28:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 20 Mar 2007 12:28:26 +0100 Subject: Completely OT: Remove disttag from EPEL and Fedora ... (was: Dropping the repotag) In-Reply-To: References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> <20070320093208.GC14567@neu.nirvana> <20070320114642.fbb19a3e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070320122826.67db4d76.mschwendt.tmp0701.nospam@arcor.de> On Tue, 20 Mar 2007 12:03:31 +0100 (CET), Dag Wieers wrote: > PS One of the reasons blocking me from joining EPEL is exactly discussions > like this. It burned me out during the initial Fedora Extras discussions > as well. And it drove me from the Fedora mailinglists. And you (and > Jeff) were directly responsible for that. I just don't have the time to > read or reply to discussions like this with you. > > So whatever you blame Axel for... > > Kind regards, Thanks for the praise. I'm going to leave this list now. -------------- 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 Tue Mar 20 12:01:11 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Mar 2007 07:01:11 -0500 Subject: Completely OT: Remove disttag from EPEL and Fedora ... In-Reply-To: References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> <20070320093208.GC14567@neu.nirvana> <20070320114642.fbb19a3e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45FFCD07.9040104@math.unl.edu> Dag Wieers wrote: > PS One of the reasons blocking me from joining EPEL is exactly discussions > like this. Take a break. Don't read/listen for awhile. Read a book. Watch a movie. Play a game. Relax. Ignore the folks that bother you (for awhile anyway). Feel better yet? :) -- Rex From Axel.Thimm at ATrpms.net Tue Mar 20 12:25:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 13:25:26 +0100 Subject: Missing packages owned by non-EPEL interested parties Message-ID: <20070320122526.GI14567@neu.nirvana> Hi, I know this will be solved long-term by co-maintainership, release managers and the like. But what is done now if such a situation arises? Contact the package maintainer and ask for co-maintainership on EPEL? If he agrees what are the next steps, ask cvsadmin-members to branch and set ACLs proper? Can cvsadmin-members touch ACLs at all, or is there another entity involved? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Mar 20 12:31:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 20 Mar 2007 13:31:56 +0100 Subject: Missing packages owned by non-EPEL interested parties In-Reply-To: <20070320122526.GI14567@neu.nirvana> References: <20070320122526.GI14567@neu.nirvana> Message-ID: <20070320123156.GC2900@free.fr> On Tue, Mar 20, 2007 at 01:25:26PM +0100, Axel Thimm wrote: > Hi, > > But what is done now if such a situation arises? Contact the package > maintainer and ask for co-maintainership on EPEL? If he agrees what > are the next steps, ask cvsadmin-members to branch and set ACLs > proper? Can cvsadmin-members touch ACLs at all, or is there another > entity involved? Unless I am wrong, there are currently 2 possibilities to have comaintainership: * 'full comaintainership': added in a field of owners.list. See http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure for the procedure. The comaintainer has full access to all the branches, and may even change te ACLs (unless I'm wrong). * tacit comaintainership: agree with maintainer, and be comaintainer. somebody should then ask for an EPEL branch (as in http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure ) and the primary package maintainer should adjust ACLs such that the comaintainer can touch on the EPEL branches. -- Pat From fedora at leemhuis.info Tue Mar 20 12:52:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 13:52:30 +0100 Subject: Missing packages owned by non-EPEL interested parties In-Reply-To: <20070320122526.GI14567@neu.nirvana> References: <20070320122526.GI14567@neu.nirvana> Message-ID: <45FFD90E.7050702@leemhuis.info> On 20.03.2007 13:25, Axel Thimm wrote: > > I know this will be solved long-term by co-maintainership, release > managers and the like. I'm not sure If I got your question right. Does the section "I want to build packages for EPEL but some of my packages dependencies are not available in EPEL" on http://fedoraproject.org/wiki/EPEL/FAQ help? UC thl From Axel.Thimm at ATrpms.net Tue Mar 20 13:05:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 14:05:55 +0100 Subject: Missing packages owned by non-EPEL interested parties In-Reply-To: <45FFD90E.7050702@leemhuis.info> References: <20070320122526.GI14567@neu.nirvana> <45FFD90E.7050702@leemhuis.info> Message-ID: <20070320130555.GM14567@neu.nirvana> On Tue, Mar 20, 2007 at 01:52:30PM +0100, Thorsten Leemhuis wrote: > On 20.03.2007 13:25, Axel Thimm wrote: > > > > I know this will be solved long-term by co-maintainership, release > > managers and the like. > > I'm not sure If I got your question right. Does the section "I want to > build packages for EPEL but some of my packages dependencies are not > available in EPEL" on > http://fedoraproject.org/wiki/EPEL/FAQ > help? Thanks! I wasn't sure the comaintainership was already working for the EPEL stuff. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Mar 20 13:11:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 14:11:35 +0100 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? Message-ID: <20070320131135.GN14567@neu.nirvana> There are a couple of useful macros available in Fedora >=5 (maybe even 4) due to the higher rpm version like the bcond macros and maybe more. If a Fedora package uses these macros then for RHEL5 there is no problem, but it breaks on RHEL4 and RHEL3. The fast way out is to add the macro definitions at the top of the specfile. But this will fork specfiles for no real reason, I'd rather see keeping the same specfile for EPEL and Fedora (unless abi/api/stability force chosing another version for EPEL than for Fedora). Could we have the few macros available in Fedora but not older RHEL releases placed in an epel-rpm-config package and have this be part of the default build chroots? That way EPEL builds are more compatible to conventional Fedora builds. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Mar 20 13:22:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 14:22:58 +0100 Subject: Missing packages owned by non-EPEL interested parties In-Reply-To: <20070320130555.GM14567@neu.nirvana> References: <20070320122526.GI14567@neu.nirvana> <45FFD90E.7050702@leemhuis.info> <20070320130555.GM14567@neu.nirvana> Message-ID: <45FFE032.4070809@leemhuis.info> On 20.03.2007 14:05, Axel Thimm wrote: > On Tue, Mar 20, 2007 at 01:52:30PM +0100, Thorsten Leemhuis wrote: >> On 20.03.2007 13:25, Axel Thimm wrote: >>> I know this will be solved long-term by co-maintainership, release >>> managers and the like. >> I'm not sure If I got your question right. Does the section "I want to >> build packages for EPEL but some of my packages dependencies are not >> available in EPEL" on >> http://fedoraproject.org/wiki/EPEL/FAQ >> help? > Thanks! I wasn't sure the comaintainership was already working for the > EPEL stuff. I see no reasons why it shouldn't. But I hope we get the PackageDB into production soon, as that should make the co-maintainer stuff a whole lot easier to deal with. CU thl From Christian.Iseli at licr.org Tue Mar 20 13:35:46 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 20 Mar 2007 14:35:46 +0100 Subject: Completely OT: Remove disttag from EPEL and Fedora ... (was: Dropping the repotag) In-Reply-To: References: <45FD476E.9040306@leemhuis.info> <45FD4A49.3030108@leemhuis.info> <45FD7D46.2040506@runlevel7.ca> <20070318203344.854ad40b.mschwendt.tmp0701.nospam@arcor.de> <20070318215511.GC4773@neu.nirvana> <20070318232650.a51d5f32.mschwendt.tmp0701.nospam@arcor.de> <20070318225421.GD4773@neu.nirvana> <20070319004151.6ab7d4d7.mschwendt.tmp0701.nospam@arcor.de> <20070320093208.GC14567@neu.nirvana> <20070320114642.fbb19a3e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070320143546.409cd92f@ludwig-alpha.unil.ch> On Tue, 20 Mar 2007 12:03:31 +0100 (CET), Dag Wieers wrote: > Fact is, I will stop using a repotag since EPEL is not coming to a > conclusion and I think it never will. This is going nowhere. Dude, please relax and take a deep breath. This EPEL thing has been brewing for several months now, and although we are making good progress it does seem to take time to get all things sorted out and implemented properly. Please do not take it personally if it takes more than a couple days to reach a conclusion on your disttag proposal. AFAICT, it boils down mostly to a political issue about nice cooperation between different repositories, and in this case I think it would be proper to hear an opinion from the Fedora Advisory Board, since they are the ones to decide the politics in Fedora. Rex is on that board, and I've seen he's posted some comments in that thread already. Fedora is composed of a vast variety of people, and we like to hear all opinions (can be tedious at times, but that's what you get in a bazaar). In the end, it is not necessarily the most vocal one that gets implemented. Not being able to make everyone happy sucks, but that's life I guess... Cheers, Christian From tcallawa at redhat.com Tue Mar 20 09:11:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 04:11:23 -0500 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: <20070320131135.GN14567@neu.nirvana> References: <20070320131135.GN14567@neu.nirvana> Message-ID: <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> On Tue, 2007-03-20 at 14:11 +0100, Axel Thimm wrote: > There are a couple of useful macros available in Fedora >=5 (maybe > even 4) due to the higher rpm version like the bcond macros and maybe > more. > > If a Fedora package uses these macros then for RHEL5 there is no > problem, but it breaks on RHEL4 and RHEL3. The fast way out is to add > the macro definitions at the top of the specfile. > > But this will fork specfiles for no real reason, I'd rather see > keeping the same specfile for EPEL and Fedora (unless > abi/api/stability force chosing another version for EPEL than for > Fedora). > > Could we have the few macros available in Fedora but not older RHEL > releases placed in an epel-rpm-config package and have this be part of > the default build chroots? That way EPEL builds are more compatible to > conventional Fedora builds. This seems to make sense to me, +1. ~spot From dennis at ausil.us Tue Mar 20 14:20:36 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 20 Mar 2007 09:20:36 -0500 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: <20070320131135.GN14567@neu.nirvana> References: <20070320131135.GN14567@neu.nirvana> Message-ID: <200703200920.36684.dennis@ausil.us> On Tuesday 20 March 2007 08:11:35 am Axel Thimm wrote: > There are a couple of useful macros available in Fedora >=5 (maybe > even 4) due to the higher rpm version like the bcond macros and maybe > more. > > If a Fedora package uses these macros then for RHEL5 there is no > problem, but it breaks on RHEL4 and RHEL3. The fast way out is to add > the macro definitions at the top of the specfile. > > But this will fork specfiles for no real reason, I'd rather see > keeping the same specfile for EPEL and Fedora (unless > abi/api/stability force chosing another version for EPEL than for > Fedora). > > Could we have the few macros available in Fedora but not older RHEL > releases placed in an epel-rpm-config package and have this be part of > the default build chroots? That way EPEL builds are more compatible to > conventional Fedora builds. Sounds fine to me. feel free to write up a spec. would it make sense to have them in epel-release or elsewhere? -- Dennis Gilmore, RHCE From dag at wieers.com Tue Mar 20 14:24:18 2007 From: dag at wieers.com (Dag Wieers) Date: Tue, 20 Mar 2007 15:24:18 +0100 (CET) Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> References: <20070320131135.GN14567@neu.nirvana> <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> Message-ID: On Tue, 20 Mar 2007, Tom "spot" Callaway wrote: > On Tue, 2007-03-20 at 14:11 +0100, Axel Thimm wrote: > > There are a couple of useful macros available in Fedora >=5 (maybe > > even 4) due to the higher rpm version like the bcond macros and maybe > > more. > > > > If a Fedora package uses these macros then for RHEL5 there is no > > problem, but it breaks on RHEL4 and RHEL3. The fast way out is to add > > the macro definitions at the top of the specfile. > > > > But this will fork specfiles for no real reason, I'd rather see > > keeping the same specfile for EPEL and Fedora (unless > > abi/api/stability force chosing another version for EPEL than for > > Fedora). > > > > Could we have the few macros available in Fedora but not older RHEL > > releases placed in an epel-rpm-config package and have this be part of > > the default build chroots? That way EPEL builds are more compatible to > > conventional Fedora builds. > > This seems to make sense to me, +1. +1 for me with one remark to not make it EPEL specific. Also, would it be possible to have macros per distribution like RPMforge is doing ? So that something like this becomes possible: %{?el3:%define _without_alsa 1} %{!?_without_alsa:BuildRequires: alsa-lib-devel} I understand this is another item that may cause a fierce battle between proponents and opponents. It makes it much shorter and less obtrusive to use these macros. Thanks in advance, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From pertusus at free.fr Tue Mar 20 14:36:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 20 Mar 2007 15:36:07 +0100 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: References: <20070320131135.GN14567@neu.nirvana> <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> Message-ID: <20070320143607.GA6831@free.fr> On Tue, Mar 20, 2007 at 03:24:18PM +0100, Dag Wieers wrote: > > Also, would it be possible to have macros per distribution like RPMforge > is doing ? > > So that something like this becomes possible: > > %{?el3:%define _without_alsa 1} > > %{!?_without_alsa:BuildRequires: alsa-lib-devel} > > I understand this is another item that may cause a fierce battle between > proponents and opponents. It makes it much shorter and less obtrusive to > use these macros. Unless I'm wrong this is already accepted and used. See http://fedoraproject.org/wiki/Packaging/DistTag?action=show&redirect=DistTag#head-1c550109af0705ccb71329619b99428af2fd3e25 Or is it something else that you have in mind? -- Pat From steve at silug.org Tue Mar 20 14:40:24 2007 From: steve at silug.org (Steven Pritchard) Date: Tue, 20 Mar 2007 09:40:24 -0500 Subject: branching core packages? Message-ID: <20070320144024.GA3658@osiris.silug.org> It looks like perl-Archive-Tar isn't available in RHEL4, and unfortunately I need it for perl-Module-Build. What's the best way to get it available in EPEL? Submit it for a normal review? Wait until Core and Extras are merged in CVS so I can just request a branch? 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 dag at wieers.com Tue Mar 20 15:00:04 2007 From: dag at wieers.com (Dag Wieers) Date: Tue, 20 Mar 2007 16:00:04 +0100 (CET) Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: <20070320143607.GA6831@free.fr> References: <20070320131135.GN14567@neu.nirvana> <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> <20070320143607.GA6831@free.fr> Message-ID: On Tue, 20 Mar 2007, Patrice Dumas wrote: > On Tue, Mar 20, 2007 at 03:24:18PM +0100, Dag Wieers wrote: > > > > Also, would it be possible to have macros per distribution like RPMforge > > is doing ? > > > > So that something like this becomes possible: > > > > %{?el3:%define _without_alsa 1} > > > > %{!?_without_alsa:BuildRequires: alsa-lib-devel} > > > > I understand this is another item that may cause a fierce battle between > > proponents and opponents. It makes it much shorter and less obtrusive to > > use these macros. > > Unless I'm wrong this is already accepted and used. See > http://fedoraproject.org/wiki/Packaging/DistTag?action=show&redirect=DistTag#head-1c550109af0705ccb71329619b99428af2fd3e25 > > Or is it something else that you have in mind? Yes, this is something different. Our use of %dist predates Fedora's standard. What we generally do in this context is set: %{?dist: %{expand: %%define %dist 1}} What matthias does to map Fedora's %fedora macro to what we use, he adds: %{?fedora: %{expand: %%define fc%{fedora} 1}} So that if fedora is set to 7, the following macro is set: %define fc7 1 In RPMforge %dist is set to either fcX or elY, _and_ a macro fcX or elY is set to 1 so that the above becomes possible. That way one does not have to use %if and %endif and makes things straight forward. Fedora is using a dot in the dist-tag, which makes the above not work. What currently is possible with the standard in the URL you gave me is to make a distinction by using the existence of the fedora or rhel macro, or use %if's to specify something else. Which makes it very hard to define what capabilities each distribution has and use the capability where it is required. So while you can do: %{?rhel: } you cannot do: %{?el5: a} %{?el4: b} %{?el3: c} %{?el2: d} and have to do something like: %if "%rhel" == "5" a %endif %if "%rhel" == "4" b %endif %if "%rhel" == "3" c %endif %if "%rhel" == "2" d %endif Plus, you can't do these inline. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Axel.Thimm at ATrpms.net Tue Mar 20 15:31:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 16:31:48 +0100 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: <200703200920.36684.dennis@ausil.us> References: <20070320131135.GN14567@neu.nirvana> <200703200920.36684.dennis@ausil.us> Message-ID: <20070320153148.GB6726@neu.nirvana> On Tue, Mar 20, 2007 at 09:20:36AM -0500, Dennis Gilmore wrote: > On Tuesday 20 March 2007 08:11:35 am Axel Thimm wrote: > > There are a couple of useful macros available in Fedora >=5 (maybe > > even 4) due to the higher rpm version like the bcond macros and maybe > > more. > > > > If a Fedora package uses these macros then for RHEL5 there is no > > problem, but it breaks on RHEL4 and RHEL3. The fast way out is to add > > the macro definitions at the top of the specfile. > > > > But this will fork specfiles for no real reason, I'd rather see > > keeping the same specfile for EPEL and Fedora (unless > > abi/api/stability force chosing another version for EPEL than for > > Fedora). > > > > Could we have the few macros available in Fedora but not older RHEL > > releases placed in an epel-rpm-config package and have this be part of > > the default build chroots? That way EPEL builds are more compatible to > > conventional Fedora builds. > Sounds fine to me. feel free to write up a spec. would it make sense to have > them in epel-release or elsewhere? I'd leave them with epel-rpm-config, as epel-release is supposed to be more an end user thing with yum/rhn configs while epel-rpm-config should have bits that are used only by rpmbuild and higher. I'll craft together something and submit it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Mar 20 19:00:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 20:00:24 +0100 Subject: Summary from last Sunday's SIG meeting Message-ID: <46002F48.7070604@leemhuis.info> = Meeting 20070318 = [[TableOfContents]] == Attending == * entr0py * nirik * quaid * thimm * thl == Summary == * Some discussions about the meeting time; seems to be quite important for some people to make sure the current main EPEL drivers can make the meeting; But Sundays on the other hand are bad for some people (especially people that might get payed for packaging stuff in EPEL) and we try to check for alternative times by using the wiki page: http://fedoraproject.org/wiki/EPEL/NewMeetingTime ; if you would be interested to join the SIG meetings times please fill that table out! tia! * RHEL5 on the builders -- there are some issues getting RHEL5 in place, but they hopefully sort out soon; the current plan is to use a merged tree for building (as agreed on in the past) * we probably need to split the repo up for different users like CentOS, RHEL5 Desktop (4 flavours afaics: Client, VT, Workstation, WOrkstation + VT) and Server (2 flavours) to make sure yum doesn't run into missing-dep situations; maybe this can be done with a yum plugin, needs to be investigated. Anyone interested to help? thl will look into this, but that might take some days as he has others things on this plate * Some discussions on http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates * thimm wants to allow kernel modules, but thl and nirik would like to avoid them for now * some discussions how to push packages to the different repos and tested pacakge to the stable repo ; it was suggested to use three repos: * stable -- main repo * stable-testing -- test packages there for a short time period before they get *moved* to stable * devel/testing/updates-nextrel -- packages get queued up here; this becomes stable with the next quarterly update The current proposal works with just two repos and suggested to build packages for devel/testing (against the latest updates that might become the next quarterly update) and then build the pacakge anew for stable if everything looks fine Please discuss on the list! * thimm urges to have a "Voting body & fesco mandate" (btw, we have a fesco mandate, but it's not actually clearly written down). thl will write something up and present it to the world and FESCo Note: there are some takes on the schedule at http://fedoraproject.org/wiki/EPEL/Schedule that could need some help. == Full log == {{{ 17:00 --- | thl has changed the topic to: EPEL SIG meeting 17:00 < thl> | ping EPEL SIG members 17:00 < thl> | who's around? 17:00 * | quaid is here 17:00 * | thimm is 17:00 < entr0py> | bjohnson here 17:00 * | nirik is here. 17:00 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule 17:01 < thl> | hi everyone 17:01 * | kanarip is here 17:01 < thl> | dgilmore mentioned it would be likely that he could not join us today 17:01 < thimm> | :/ 17:01 < thimm> | Isn't he the only one that insists on Sunday meetings? 17:02 < nirik> | yeah, sunday or off business hours during the week... 17:02 < thl> | nirik, yes, something like that was what dgilmore wants 17:03 < thl> | and even if someone asks for this is doesn't mean that he has free time each week ;-) 17:03 < nirik> | true... 17:03 < thimm> | So, how about we move the meeting time into the work week? 17:03 < thl> | I pinged mmcgrath in #fedora-devel 17:03 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- meeting time 17:04 < thl> | thimm, well, "off business hours" in the US means probably middle of the night for us europeans 17:04 < nirik> | thimm: where was the link to that wiki timeschedule page you made? I was meaning to look at it and add, perhaps we could see what time works best based on that? 17:04 < thimm> | Isn't he down-under? 17:04 < thimm> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime 17:04 < thl> | thimm, dgilmore? no 17:04 < thimm> | But noone entered anything in there 17:04 < thl> | he comes from down under iirc, but is in the US for some years now 17:05 < nirik> | do we have any west coast people at all? perhaps we could use that time as well? 17:05 < nirik> | (for now) 17:05 < nirik> | yeah, I think he's in MN.us. 17:05 < thl> | quaid, are you on the west coast? 17:05 < quaid> | I am 17:06 < nirik> | ah, sorry, thought there weren't any west coast folks. :) My mistake 17:07 < quaid> | we used this to figure out likely slots for our far-flung FDSCo members: 17:07 < quaid> | http://fedoraproject.org/wiki/BobJensen/MeetingTimes 17:07 < thl> | well, I stated my preferred times on the list in https://www.redhat.com/archives/epel-devel-list/2007-March/msg00203.html 17:07 < quaid> | each person put in their unavailability by their initial, and we looked for the ligthest coverage 17:07 < thimm> | similar to what we did with FPC 17:07 < quaid> | thl: right, we tried that for a while, but it failed to make it obvious when the best times were 17:08 < quaid> | so, if passing ideas back and forth doesn't help, me may need a matrix like this 17:08 < thimm> | See http://fedoraproject.org/wiki/Packaging/NewMeetingTime 17:08 < thimm> | This is what I used as a template for http://fedoraproject.org/wiki/EPEL/NewMeetingTime 17:08 < nirik> | I would prefer to have dgilmore around, since he is dealing with so much of the infrastructure, but most times are ok with me otherwise. 17:09 < nirik> | thimm: sundays are usually bad for you? 17:09 < thl> | nirik, +1, we need to make sure the certain key driers so far can join the meeting normally 17:09 < thimm> | Yes 17:09 < thimm> | Sundays seems to be bad for many people including @RH.com 17:09 < nirik> | yeah, true... 17:10 < nirik> | from dgilmore's email to the list: " It would need to be between 23:00-3:00 UTC or 11:30-12:30 UTC or on the weekends." 17:10 < thimm> | We'd like more participation from the enterprise world and people with jobs like to work on Mo-Fr 17:10 --> | che (Rudolf Kastl) has joined #fedora-meeting 17:10 < thl> | thimm, we fist need to lift of... 17:10 < nirik> | thimm: agreed. 17:11 < thimm> | thl: If we close doors, how will we lift off? 17:11 < thl> | anyway, can somebody fill out http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what we know so far 17:11 < thl> | then we can ask the others to put up their time 17:11 < thl> | and then we can look further 17:11 < thl> | thimm, it's not that bad currently 17:12 < thl> | and those that showed most interested seems to agree on sunday 17:12 < thl> | for now 17:12 * | thimm looks around 17:12 < nirik> | I think we are left with sunday or not having dgilmore available at the meetings. 17:12 < thl> | nirik, +1 17:12 < thimm> | nirik: Or both like today ... 17:13 < thimm> | I won't be able to make it on other Sundays 17:13 < thimm> | This is my first Sunday I could make it anyway 17:13 < nirik> | what about saturday? 17:13 < thimm> | Well, weekends in general are bad, but Saturday early (in UTC speech) are the lesser evil 17:14 < nirik> | perhaps we can propose that to dgilmore. Or just pick a weekday meeting time and move on. 17:15 --> | engwnbie (Leo Canale) has joined #fedora-meeting 17:15 * | thl still votes that somebody that pre-fills http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what is publically known; then we ask others to add their info, and then we'll look at it next week 17:15 < thimm> | It would make sense for everyone interested to fill out his own slots 17:15 < thimm> | That's how it worked at the FPC 17:16 < thimm> | Cross out what you can't attend and ++ the lsots you prefer 17:16 < thl> | thimm, go ahead and to it 17:16 < thimm> | s/lsots/slots/ 17:16 < thl> | thimm, somebody needs to start 17:16 < thl> | so others know how it shall look like 17:16 < thl> | add mine and dglimores times, too 17:16 < thl> | and others will join 17:16 < nirik> | in my case as long as it's not fesco and at times I am awake it's ok with me. ;) 17:17 < thl> | let's fill out the form until next week and then look at it? 17:17 < thl> | and move on now? 17:18 < nirik> | ok 17:18 < thl> | somebody just needs to start afaics 17:18 * | thl will move on 17:18 --> | glezos (Dimitris Glezos) has joined #fedora-meeting 17:18 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- RHEL5 on the builders 17:19 < thl> | we have some issues getting RHEL5 in place 17:19 < thl> | but they hopefully sort out soon 17:19 < nirik> | I think dgilmore was working on that. ;) 17:19 < thl> | dgilmore, yes, he and mmcgrath are working on it 17:19 < nirik> | FYI, centos has a 4.92 beta out to test with... 17:19 < thl> | the big problem is: 17:19 < thl> | do we need one merged tree 17:20 < thl> | or different ones for Client and server 17:20 < thl> | I'd say: 17:20 < thimm> | thl: OK, my part is done 17:20 < nirik> | I think we agreed on one merged tree in the past. I think Client and Server would make things too complicated. 17:20 < thl> | nirik, +1 17:20 < thl> | nirik, neertheless we need to split stuff somehow 17:20 < thl> | otherwise Client users will run into missing dep issues 17:20 < nirik> | split how? 17:21 < thl> | if a pacakge requires something from the server 17:21 < thl> | split the repo into Client (Desktop, VT, Workstation, VT+Workstation) and Server 17:21 < thl> | or use a yum plugin 17:22 < thl> | that prevents that people run into missing dep issues 17:22 < thimm> | yum plugin sounds nicer 17:22 < thl> | thimm, +1 17:22 < thl> | that's my plan, too 17:22 < nirik> | yuck. Yeah, yum plugin would be better... 17:22 < thl> | as we would hae just one repo 17:22 < thimm> | It will deal with any furture layering of RHEL products, too 17:22 < thl> | and centos users simply could use all 17:22 < nirik> | but who is going to write it? :) 17:22 < thl> | nirik, that's the problem... 17:22 < thimm> | Well, is it really a plugin? 17:23 < che> | thl, well but the plugin cant just ignore missing deps 17:23 < thimm> | Maybe it is yum core functionality 17:23 < thl> | che, we'd need to ship list of packages 17:23 < thimm> | Like a switch to deal with missing/broekn deps 17:23 < thl> | where we know that deps will be missing 17:23 < thl> | well, or something like that... 17:23 < thimm> | This switch would be usefull for rawhide as well 17:23 < thl> | I'll try to look into this during the week 17:23 < thl> | and post to the list 17:24 < thl> | but well, if somebody else is interested in solving this I won't mind :) 17:24 < thl> | is anyone? 17:24 < nirik> | didn't someone post a list of packages that were just in server/client? I can't find the list now... 17:24 < thimm> | I did on epel and rhelv5 lists 17:24 < thl> | nirik, is more complicated then just server vs client 17:25 < thimm> | Just grep for evolution in the body 17:25 < thl> | nirik, there are different client versions 17:25 < nirik> | thl: in 4, but not 5, right? 17:25 < thimm> | thl: sure? 17:25 < nirik> | 5 just has a since client/workstation I thought. 17:25 < thimm> | thl: difference in premium etc is support, not content 17:25 < thl> | only RHEL5-Client-Workstation for example ships PHP and eclipse 17:26 < thl> | thimm, not 100% sure, but quite sure, yes 17:26 < thl> | you have a isntall-number 17:26 < nirik> | ah, found the list... it's pretty small... 17:26 < thl> | you have to fill in during install 17:26 < thl> | and that decides about the package set you can install 17:26 < thimm> | I see 17:27 < quaid> | are the "not available" packages not oon RHN for those install types? 17:27 < thimm> | so one media, several outputs 17:27 < thl> | well, as I said, I'll try to look at this closer during the week 17:27 < thl> | thimm, yes 17:27 < thl> | quaid, are they? 17:27 < quaid> | I don't know 17:27 < thimm> | Makes organisation quite messy 17:27 * | thl has no RHEL5 at hand ATM 17:27 < quaid> | this is a bit unexpected thinking to me ... 17:27 < thimm> | quaid: It wouldn't make much sense, or not? 17:27 < quaid> | well 17:28 < quaid> | from a support perspective, sure, if you have Server and call about Eclipse on it ... 17:28 < quaid> | but does that mean there is no way to get the package? 17:28 < quaid> | I'm thinking about dep resoling in particular 17:28 < thl> | let's stop here 17:28 < thl> | and further investigate during the week 17:28 < quaid> | and not being to replace packages i nthe distro, etc. 17:28 < quaid> | ok 17:28 < thimm> | If the install number prohibit installtion of eclipse from the media they should also do so from the channels 17:28 < thl> | does that sound sane? 17:28 < nirik> | yeah, I think further investigation would be good. 17:29 < nirik> | I would really prefer to just have one repo per release of epel... otherwise it's getting very complex for maintainers. 17:29 < thl> | nirik, +1 17:29 < thl> | and for us, too 17:29 * | thl will move on soon if nobody yells 17:29 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates 17:30 < thl> | do we all agree on that this is the way forward? 17:30 * | nirik re-reads it again quickly 17:30 < thl> | not much changed in the past week 17:31 < thl> | actually, the changes since the initial posting were quite small in general 17:31 < thimm> | I disagree on kernel module policy 17:32 < thl> | thimm, suggestions please :) 17:32 < thl> | this was discussed on the list, wasn#t it? 17:32 < thl> | did you speak up there? (/me wonders if he missed that) 17:32 < thimm> | I did 17:32 < thimm> | And you replied 17:32 < thimm> | But I still disagree :) 17:32 < nirik> | kernel modules are a nice can of worms. I think we want to at least avoid them until everything else is up... 17:32 < thl> | nirik, +100 :) 17:33 < thimm> | Also: why rebuild packages? 17:33 < che> | from a usability point of view i like the dkms approach 17:33 < thl> | thimm, ? 17:33 < thimm> | From testing to stable transition 17:33 < thimm> | Doesn't that defeat any testing/QA done? 17:33 < thl> | thimm, that's not written there afaics 17:34 < thl> | the testing branch simply becomes the stable branch when the quarterly update happens 17:34 < thimm> | "go to a testing branch for a short time period and then build a second time for the stable branch" 17:34 < nirik> | yeah, shouldn't need to do that... since ABI/API should keep stable in minor releases of RHEL, right? 17:34 < thl> | thimm, that's something different 17:34 < thl> | that's more a: "updates-testing" meachnism 17:34 < thl> | and only for those rare cases where updates to stable are needed 17:34 < thimm> | Yes, and this should be rebuilt as well 17:35 < thimm> | Otherwise the "testing" part gets reset 17:35 < nirik> | isn't that more "there were problems in testing, so a new release was needed to fix them before pushing to stable" ? 17:35 < thimm> | That's different 17:35 < thimm> | If the package has a bug it needs to get fixed in testng 17:35 < nirik> | agreed. 17:35 < thl> | thimm, can you please outline your thoughts on the list 17:35 < thimm> | And when the bugs are off move the final testing package to stable 17:35 < thl> | I think that would be the better place 17:36 < thimm> | Well, these are no "thoughts", just general pratice 17:36 < thl> | thimm, don#t forget that packages in testing might get build agianst something else then the ones in stable 17:36 < nirik> | thimm: I agree, perhaps we need to clarify the document in that? 17:36 < thl> | stable=rh-latest 17:36 < thimm> | thl: that should not happen 17:37 < thl> | testing=rh-what-becomes-next-quarterly-update 17:37 < thl> | thimm, let's move this to the list 17:37 < thl> | it becomes to complicated here on IRC in my opinion 17:37 < thimm> | thl: There are two concepts mixes up then 17:37 < nirik> | The only time I would think that would happen is if there were several packages in epel that depended on each other and needed to be pushed at once. 17:37 < thimm> | You want "rawhide" and "updates-testing" in one repo 17:37 < thimm> | That won't wokr 17:38 < thimm> | For development we need to separate them, just like FC does 17:38 < thl> | development is fedora 17:38 < thimm> | security and major bugfxies go to the "updates-testing" 17:38 < thl> | security and major bugfxies go to the "updates-testing" +1 17:38 < thimm> | Any the prepeation for quarterly go to epel's "rawhide" 17:39 < thl> | no 17:39 * | thl stopps here, this doens't lead to anything 17:39 < thl> | lets move it to the list 17:39 < thimm> | Why? 17:39 < nirik> | security and major bugfixes go to "updates-testing" for a short time only and then get pushed to fix the security/major bug, right? 17:39 < thimm> | Yes 17:39 < thimm> | W/o rebuilding 17:39 < thimm> | Otherwise the QA gets lost 17:39 < nirik> | the minor updates/versions just keep sitting in updates-testing until the next minor 17:40 < thl> | I'd say with rebuilding 17:40 < thimm> | Yes, but that needs to be a separate repo 17:40 < nirik> | thimm: +1 to no rebuild. 17:40 < thl> | at leat if we build against rhel-what-becomes-update soon 17:40 < thimm> | E.g. one for quarterly long-term updates and one for near-term updates to the current minor 17:40 < nirik> | updates-testing and updates-nextrel ? 17:41 <-- | engwnbie has left #fedora-meeting ( "I'm Done") 17:41 < thl> | thimm, then we'd need to have 3 repos 17:41 * | thl thinks that's to much 17:41 < thimm> | Whch three? 17:41 < thl> | that will fail just as updates-testing fail 17:41 * | thl repeats: let's discuss it on the list 17:41 < thl> | we don#t understnad each other here 17:41 < thimm> | Let's talk in FC naming: 17:41 * | thl votes for moving on 17:42 < thl> | and reisiting this next week and on the list 17:42 < thl> | revisit 17:42 < thl> | stupid keyboard 17:42 < nirik> | so for each release, say RHEL5... there is a "5" repo with main packages, stable, pushed out. A 'updates-testing' thats usually empty, but sometimes has major security/bugfix packages, and a 'updates-nextrel' that has the packge updates for 5.1 waiting in it. 17:42 < nirik> | thl: ok. 17:43 < thimm> | nirik: something like that, yes 17:43 < thimm> | Where the two latter repo are consdiered our development repos 17:43 < thimm> | Not development as in == rawhide, but development as in where we do QA and shape packages for the next quarterly 17:43 < thimm> | Anyway, let's move on 17:44 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- what else? 17:44 < nirik> | right. I think thats all doable, and mostly autopmagically so maintainers don't need to mess with it too much. 17:44 < thl> | anything else for today? 17:44 < thl> | repotag? 17:44 < thimm> | Voting body & fesco mandate? 17:44 < thl> | thimm, was discussed last week 17:44 --> | ChitleshGoorah (Chitlesh GOORAH) has joined #fedora-meeting 17:44 < thl> | but we can bring it up again 17:44 < thimm> | I'm sure it wasn't voted on ;) 17:45 < thimm> | repotag, fedr-ausrmgmt etc need a final voting somewhere 17:45 < thl> | sure, because we'd need to ask FESCo first how to set up a voting body 17:45 < nirik> | thimm: so what are you looking for? voting on tech issues where there is no consensus? 17:45 < thimm> | It's either the sig or fesco 17:45 < thl> | and the fest members around just said "try to continue without a oting body" 17:45 --> | lancelan (Lance Davis) has joined #fedora-meeting 17:45 < thimm> | thl: we need to suggest something and get iot ratified 17:45 < thl> | thimm, seems a lot of people disagreed last week 17:46 < thimm> | Last week? 17:46 < thl> | last meeting 17:46 < thimm> | On this irc? 17:46 < nirik> | I think repotag should fall under packaging... 17:46 < thl> | nirik, +1 17:46 < thimm> | Where less than half of the sig can participate? 17:46 < thl> | the summaries get send to the list 17:46 < thl> | so people can look at it 17:46 < thl> | and yell if they don#t like something 17:46 < thl> | nobody yelled 17:47 < thimm> | That's not to be deducted into everybody agrees 17:47 < quaid> | fwiw, we aren't near ready to be a formal project 17:47 < thl> | thimm, see https://www.redhat.com/archives/epel-devel-list/2007-March/msg00210.html 17:47 < quaid> | so it is SIG or nothing , afaict 17:47 < nirik> | I would much rather get to some tech consensus than brute force voting on issues where everyone gets unhappy in the end. 17:47 < thimm> | Well, every sig does have to make decisions, right? 17:47 < thl> | thimm, "some discussion about steering issues that got discussed on the list" 17:48 < thl> | nirik, +1 17:48 < quaid> | right, a SIG can vote, can't it? I mean, anyone can hjold a vote, unless they are somewhere they will get shot for doing it :/ 17:49 < thl> | quaid, well, yes, but who is allowed to vote 17:49 < thimm> | So the N people mentioned on the SIg list already form a voting body, is that what you're saying? 17:49 < thl> | that can quickly become confusing if people just join the sig just to be able to vote 17:49 < thl> | and how many votes does something need to get accepted 17:49 < thimm> | 50% 17:49 < thimm> | >50% 17:50 < thl> | to much 17:50 < thl> | that will deadlock soon 17:50 < thimm> | That's how voting works 17:50 < nirik> | so this is all for fedora-usermgmt banning? or ? 17:50 < thimm> | No, its for everything 17:50 < thl> | I'd say a group that decides about how epel moves forward should be 5 or 7 people 17:50 < thl> | not more 17:50 < thimm> | Then make a suggestion and have fesco ratify the list 17:50 < nirik> | well, what I mean is what "everything" do we need voting for now? aside from usermgmt? 17:51 < thimm> | repotag? 17:51 < thimm> | repo layout? 17:51 < thimm> | guidelines? 17:51 < thimm> | policies? 17:51 < thl> | thimm, we just do it the "if nobody yells it's okay" way currently 17:51 < thl> | and that was what FESCo members in the last meeting prefered 17:51 < thimm> | Which means 100% consensus or people are not paing attention 17:51 < thl> | and non-FESCo members, too afaics 17:51 < thl> | thimm, yes 17:51 < thimm> | That's not a healthy way of a project 17:52 < thl> | it worked so far 17:52 < thl> | sure, if we grow 17:52 < thimm> | It depends on the view I guess 17:52 < thl> | then we need a committee 17:52 < thimm> | so how do you deal with disagreement? 17:52 < thl> | we try to avoid it for now 17:53 < thimm> | Discuss until RHEL6? 17:53 < thl> | or move it to FESCo 17:53 < thimm> | Burry it under the carpet? 17:53 < thimm> | Oh fesco will be grateful for esalating any decision to them 17:53 < thimm> | For example repotag 17:53 < thimm> | I would agree that pushing it to FPc is the right thing to do 17:54 < nirik> | well, I would prefer to avoid the overhead, but if you want voting on issues, how about: anyone with a EPEL package can vote... voting to take place on a wiki page somewhere on each issue? 17:54 < thimm> | At least not w/o a preference form EPEL 17:54 < thl> | thimm, just out of interest, what's your opinion on repotag? 17:54 < thl> | nirik, that has other disadantages 17:54 < thl> | okay, I'll write something up for FESCo 17:54 < thimm> | I don't really care, I would like to see one, but I wopuld rather see it decided upon either way before it gets an infininte thread 17:54 < thl> | I'll of course send it to the list beforehand 17:55 < thimm> | thl: thanks! :) 17:55 < thl> | anything else? 17:55 < thimm> | Off the meeting: How do I import all my packages to EPEL? 17:55 * | thl will be afk soon anyway 17:56 < thimm> | (All but a few non-EPELizable) 17:56 < thimm> | Can someone here do a mass branching for me? 17:56 < thl> | thimm, I asked last week for people to write a script to simplyfy mass-branching in cvs 17:56 < thimm> | Who's doing the branches for EPEL, dgilmore? 17:56 < thl> | thimm, I'll do this script properly myself later as no one showed interest 17:57 < nirik> | might be best to generate a list and mail cvsadmins at fedoraproject.org? 17:57 < thl> | thimm, cvsadmins, that includes dgilmore 17:57 < thimm> | OK, I will try cvsadmins, thanks 17:57 < thl> | anything else? 17:57 * | thl will close the meeting in 30 17:58 < thimm> | bye all! 17:58 * | thl will close the meeting in 10 17:58 < thl> | -- MARK -- Meeting end }}} From tcallawa at redhat.com Tue Mar 20 21:32:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 16:32:17 -0500 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: References: <20070320131135.GN14567@neu.nirvana> <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> <20070320143607.GA6831@free.fr> Message-ID: <1174426337.8930.17.camel@dhcp83-55.boston.redhat.com> On Tue, 2007-03-20 at 16:00 +0100, Dag Wieers wrote: > Yes, this is something different. Our use of %dist predates Fedora's > standard. What we generally do in this context is set: > > %{?dist: %{expand: %%define %dist 1}} > > What matthias does to map Fedora's %fedora macro to what we use, he adds: > > %{?fedora: %{expand: %%define fc%{fedora} 1}} > > So that if fedora is set to 7, the following macro is set: > > %define fc7 1 I'm not opposed to adding what matthias is doing to to the disttag macro defines (for Fedora and EPEL) Seems to have value for conditionals. I'll work on a PackagingDraft for it. ~spot From wtogami at redhat.com Tue Mar 20 22:18:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 18:18:53 -0400 Subject: branching core packages? In-Reply-To: <20070320144024.GA3658@osiris.silug.org> References: <20070320144024.GA3658@osiris.silug.org> Message-ID: <46005DCD.6000005@redhat.com> Steven Pritchard wrote: > It looks like perl-Archive-Tar isn't available in RHEL4, and > unfortunately I need it for perl-Module-Build. > > What's the best way to get it available in EPEL? Submit it for a > normal review? Wait until Core and Extras are merged in CVS so I can > just request a branch? > > Steve perl-Archive-Tar in EL-4 should match the EL-5 version. The old version (from FC-3) is insufficient for several typical modern uses. For example, spamassassin-3.1.8 ships in RHEL-4.5, but cannot provide perl-Archive-Tar in RHEL-4 so users cannot use sa-update. RHEL4 does not officially support the use of sa-update, but it seems to work if users add the requisite perl modules. It is fine if they obtain this from EPEL-4. Copy perl-Archive-Tar from EL-5 to EPEL-4. Make sure rpmvercmp would upgrade properly from EPEL-4 to EL-5's version. It'll work out. Warren Togami wtogami at redhat.com From buildsys at fedoraproject.org Wed Mar 21 18:07:49 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Mar 2007 14:07:49 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-03-21 Message-ID: <20070321180749.3549B152130@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 14 NEW apt-0.5.15lorg3.2-9.el5 NEW chrpath-0.13-1.1.el5 NEW fail2ban-0.6.2-3.el5 NEW fakechroot-2.5-12.el5 NEW fakeroot-1.6.4-15.el5 NEW gnustep-make-1.12.0-5.el5 NEW greylistd-0.8.3.2-8.el5 NEW libFoundation-1.1.3-10.el5 NEW libcdaudio-0.99.12p2-8.el5 NEW perl-ExtUtils-CBuilder-0.18-1.el5 NEW perl-ExtUtils-ParseXS-2.18-1.el5 NEW perl-Text-CharWidth-0.04-2.el5 NEW perl-Text-WrapI18N-0.06-2.el5 NEW perl-pmtools-1.01-2.el5 Packages built and released for Fedora EPEL 4: 18 NEW apt-0.5.15cnc7-1.1 NEW chrpath-0.13-1.1.el4 NEW fail2ban-0.6.2-3.el4 NEW fakeroot-1.6.4-15.el4 NEW gnustep-make-1.12.0-5.el4 NEW greylistd-0.8.3.2-8.el4 NEW libFoundation-1.1.3-10.el4 NEW libcdaudio-0.99.12p2-8.el4 NEW libsieve-2.2.5-1.el4 NEW perl-ExtUtils-CBuilder-0.18-1.el4 NEW perl-ExtUtils-ParseXS-2.18-1.el4 NEW perl-Text-CharWidth-0.04-2.el4 NEW perl-Text-WrapI18N-0.06-2.el4 NEW perl-pmtools-1.01-2.el4 NEW python-setuptools-0.6c5-1.el4 NEW synaptic-0.57.2-1.el4 NEW tmda-1.1.11-2.el4 NEW unpaper-0_2-2.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From pertusus at free.fr Thu Mar 22 22:41:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 22 Mar 2007 23:41:19 +0100 Subject: howto coordinate with RHEL packages/pakagers? Message-ID: <20070322224119.GA3145@free.fr> Hello, Maybe there is something obvious I didn't figured out, but I don't know where to look for some information about RHEL packages: * is there somewhere a list of packages in RHEL? And versions/maintainer information? * where are the spec file available? Do we have to expand srpms or is there something convenient similar with the fedora cvs? I can't even find the srpms. I can see a communication channel, bugzilla, but it is not necessarily the most convenient, it can be a bit heavy sometime. -- Pat From mmcgrath at redhat.com Thu Mar 22 23:12:20 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 22 Mar 2007 18:12:20 -0500 Subject: howto coordinate with RHEL packages/pakagers? In-Reply-To: <20070322224119.GA3145@free.fr> References: <20070322224119.GA3145@free.fr> Message-ID: <46030D54.2090806@redhat.com> Patrice Dumas wrote: > * is there somewhere a list of packages in RHEL? And versions/maintainer > information? > Change logs > * where are the spec file available? Do we have to expand srpms or > is there something convenient similar with the fedora cvs? I can't > even find the srpms. > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ > I can see a communication channel, bugzilla, but it is not necessarily > the most convenient, it can be a bit heavy sometime. > Bugzilla is the way we do things. -Mike From steve at silug.org Thu Mar 22 23:17:42 2007 From: steve at silug.org (Steven Pritchard) Date: Thu, 22 Mar 2007 18:17:42 -0500 Subject: branching core packages? In-Reply-To: <46005DCD.6000005@redhat.com> References: <20070320144024.GA3658@osiris.silug.org> <46005DCD.6000005@redhat.com> Message-ID: <20070322231742.GA19393@osiris.silug.org> On Tue, Mar 20, 2007 at 06:18:53PM -0400, Warren Togami wrote: > Copy perl-Archive-Tar from EL-5 to EPEL-4. Make sure rpmvercmp would > upgrade properly from EPEL-4 to EL-5's version. It'll work out. Sounds like a great plan. Is someone going to have to do an official review or something to make it happen though? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From pertusus at free.fr Thu Mar 22 23:30:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 Mar 2007 00:30:00 +0100 Subject: ABI diff tools Message-ID: <20070322233000.GB3145@free.fr> Hello, I am searching for a program that would allow to compare 2 libs or a lib and an application, find the binary interface differences and display them conveniently. Does something like that exist? I think that it would be very convenient to help maintaining ABI compatibility in EPEL packages. -- Pat From Axel.Thimm at ATrpms.net Thu Mar 22 23:51:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 00:51:03 +0100 Subject: ABI diff tools In-Reply-To: <20070322233000.GB3145@free.fr> References: <20070322233000.GB3145@free.fr> Message-ID: <20070322235103.GA3448@neu.nirvana> On Fri, Mar 23, 2007 at 12:30:00AM +0100, Patrice Dumas wrote: > I am searching for a program that would allow to compare 2 libs or a lib > and an application, find the binary interface differences and display > them conveniently. Does something like that exist? I think that it would > be very convenient to help maintaining ABI compatibility in EPEL packages. That would be a nice tool, but how would it help EPEL? It would rather help creating a clone of RHEL, for example CentOS and verify that the rebuild is still providing the same ABI. For creating such a tool the nearest you could get would be to simply dump and sort the symbols including function signatures if available and compare them. But C does not encode arguments to functions into the symbols so large part of the ABI information is implicit. But at least you would get part of the ABI to check. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Fri Mar 23 15:30:58 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 23 Mar 2007 09:30:58 -0600 Subject: branch sources Message-ID: <4603F2B2.6050103@cora.nwra.com> Just requested EPEL (4 and 5) branches for apcupsd and cmake. It appears that the EL-4 branch came from devel and EL-5 came from FC-6. This seems odd to me, and it ended up with versions in EL-4 being higher than in EL-5. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From dennis at ausil.us Fri Mar 23 15:57:56 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 23 Mar 2007 10:57:56 -0500 Subject: branch sources In-Reply-To: <4603F2B2.6050103@cora.nwra.com> References: <4603F2B2.6050103@cora.nwra.com> Message-ID: <200703231057.56912.dennis@ausil.us> On Friday 23 March 2007 10:30:58 am Orion Poplawski wrote: > Just requested EPEL (4 and 5) branches for apcupsd and cmake. It > appears that the EL-4 branch came from devel and EL-5 came from FC-6. > This seems odd to me, and it ended up with versions in EL-4 being higher > than in EL-5. The way the branch scripts work if there is a FC-3 branch EL-4 will come from that if not devel. EL-5 will come from FC-6 if it exists if not devel. Perhaps i should make EL-4 come from FC-3 then FC-6 then devel. Ill get it done that way. you can quite easily make it the older version for EL-4 -- Dennis Gilmore, RHCE From rdieter at math.unl.edu Fri Mar 23 17:07:06 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Mar 2007 12:07:06 -0500 Subject: epel4/ppc? missing sqlite? Message-ID: <4604093A.4050007@math.unl.edu> wtf? http://buildsys.fedoraproject.org/build-status/job.psp?uid=30189 First off, I guess I didn't even realize el4/ppc existed, ok, fine. But, No Package Found for sqlite-devel ? -- Rex From tcallawa at redhat.com Fri Mar 23 17:08:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 23 Mar 2007 12:08:20 -0500 Subject: Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config? In-Reply-To: <1174426337.8930.17.camel@dhcp83-55.boston.redhat.com> References: <20070320131135.GN14567@neu.nirvana> <1174381883.3563.3.camel@dhcp83-55.boston.redhat.com> <20070320143607.GA6831@free.fr> <1174426337.8930.17.camel@dhcp83-55.boston.redhat.com> Message-ID: <1174669700.5072.18.camel@1cc-dhcp-162.media.mit.edu> On Tue, 2007-03-20 at 16:32 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-03-20 at 16:00 +0100, Dag Wieers wrote: > > > Yes, this is something different. Our use of %dist predates Fedora's > > standard. What we generally do in this context is set: > > > > %{?dist: %{expand: %%define %dist 1}} > > > > What matthias does to map Fedora's %fedora macro to what we use, he adds: > > > > %{?fedora: %{expand: %%define fc%{fedora} 1}} > > > > So that if fedora is set to 7, the following macro is set: > > > > %define fc7 1 > > I'm not opposed to adding what matthias is doing to to the disttag macro > defines (for Fedora and EPEL) Seems to have value for conditionals. > > I'll work on a PackagingDraft for it. I've worked up a PackagingDraft for these macros: http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros We'll discuss and vote on the Draft next week during our regular meeting. This is also a reminder that anyone who thinks that there are missing items or items which need amending in the Fedora Packaging Guidelines can submit a draft for review by the Fedora Packaging Committee. The process on how it all works is documented here: http://fedoraproject.org/wiki/Packaging/Committee Thanks, ~spot From fedora at leemhuis.info Fri Mar 23 17:53:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Mar 2007 18:53:07 +0100 Subject: Proposal for a EPEL Steering Committee Message-ID: <46041403.6010406@leemhuis.info> Hi all! The initial goal of the EPEL SIG was to have some kind of "work in the open, announce potential controversial topics in public before you realize them, and as long as nobody yells everything is fine and everyone glad" kind of organization. Well, seems at some EPEL-SIG members seems unhappy with that and strongly urged on the epel-devel-list to form some kind of government body. So I wrote something up, which you can find below. Start of proposal ---- == EPEL Steering Committee == An EPEL Steering Committee will be formed as government body for EPEL. It will consist of seven members. The initial committee will be filled with the first seven EPEL SIG members that are also those that invested most of the time and work for the EPEL idea until now. That includes these people: Dennis Gilmore, Mike McGrath, Michael Stahnke, Kevin Fenzi, Thorsten Leemhuis, Karsten Wade and Axel Thimm (those people can appoint different members if they don't want to be in the committee). They will take care of EPEL until 30.09.2007. Then then a new committee will be formed; FESCo and the EPEL Steering Committee until then will work out how this committee will get constituted; a mix of appointed and elected members is likely. The EPEL Steering Committee will continue to report to FESCo and will continue to be a SIG that is below FESCo in the project hierarchy. The EPEL Steering Committee will work similar how FESCo works; that means: * things normally get discusses and decided in open-to-all IRC meetings; members can send in their vote via mail/wiki if they can make the meeting. Approving something require at least four Steering Committee members to vote and the majority of the votes wins. But the goal remains to have a consensus between Committee members normally * important things get discussed on the list before they get voted upon and the goal it to find a consensus that seems to be fine for the majority of people involved * meeting summaries get send to the list, wiki and will get discussed in FESCo meetings in necessary * each point that receives strong opposition on the list after it got decided will get revisited once in the next meeting if someone asks for it The EPEL Steering Committee won't handle issues around theoretical Packaging (e.g. everything around writing specfiles) -- the Packaging Committee will take care of this for EPEL, too. Practical packaging (for example: maintenance and update policy for EPEL) on the other hand is regulated by the EPEL Steering Committee. The goal is to let the EPEL Steering Committee work on it's own (e.g. without FESCo involvement) for all things that are specific to EPEL. Sometimes it might be necessary to solve issues hand in hand with FESCo or other SIGs. For example: * where the EPEL steering committee can't agree with another committee that is on the same hierarchy level in the Fedora Project (say the Packaging Committee). * when FESCo member reads what the EPEL Steering Committee decided and disagrees with that ---- End of proposal Note: I'll send it to Fedora-maintainers after initial discussion on this list. Later to FESCo for ratifying when we agree roughly that this is the route to take. CU thl P.S.: The proposal is also in the wiki at http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee From Axel.Thimm at ATrpms.net Fri Mar 23 21:54:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 22:54:00 +0100 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <46041403.6010406@leemhuis.info> References: <46041403.6010406@leemhuis.info> Message-ID: <20070323215400.GB21465@neu.nirvana> On Fri, Mar 23, 2007 at 06:53:07PM +0100, Thorsten Leemhuis wrote: > == EPEL Steering Committee == First of all thanks a lot for this, I agree with all parts, just two comments below: > Approving something require at least four Steering Committee members > to vote and the majority of the votes wins. Isn't that the same? The majority of 7 people is always 4+. Or are you saying that we need the majority to attend to a vote and of that majority again the majority? The latter doesn't sound that good, as you would end up with passing votes that are less than the majority. I would strictly stick to having a majority quorum of positive votes compared to the full number of members, irrespective of how many are attending the voting. > * when FESCo member reads what the EPEL Steering Committee decided and > disagrees with that Since the decisions of this committee are reported and ratified by fesco, is this needed? This sounds like we do some work and get it approved by fesco. And then two weeks later a fesco member returns from vacation and quotes this sentence to undo everything. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Mar 23 22:05:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Mar 2007 23:05:59 +0100 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <20070323215400.GB21465@neu.nirvana> References: <46041403.6010406@leemhuis.info> <20070323215400.GB21465@neu.nirvana> Message-ID: <46044F47.2070608@leemhuis.info> Axel Thimm schrieb: > On Fri, Mar 23, 2007 at 06:53:07PM +0100, Thorsten Leemhuis wrote: > >> Approving something require at least four Steering Committee members >> to vote and the majority of the votes wins. > Isn't that the same? The majority of 7 people is always 4+. Or are you > saying that we need the majority to attend to a vote and of that > majority again the majority? The latter. > The latter doesn't sound that good, as you would end up with passing > votes that are less than the majority. I would strictly stick to > having a majority quorum of positive votes compared to the full number > of members, irrespective of how many are attending the voting. I feared/fear that we run into situations where members simply are not present in votings or not really responsive even on the list; to avoid that I copied how FESCo works/worked afaics. But well, you have a point, too. I'll remove that cornercase for now, but will bring that quickly bring up as adjustments if my fears should become true. Does that sound sane? >> * when FESCo member reads what the EPEL Steering Committee decided and >> disagrees with that > Since the decisions of this committee are reported and ratified by > fesco, is this needed? This sounds like we do some work and get it > approved by fesco. And then two weeks later a fesco member returns > from vacation and quotes this sentence to undo everything. It was more meant as clarification, but seems it is more confusing that helping now that I look at it again. I'll take a look to make this more clear later and will set a definite timeframe for a FESCo veto, to make it more clear. CU thk From Axel.Thimm at ATrpms.net Fri Mar 23 22:20:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Mar 2007 23:20:22 +0100 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <46044F47.2070608@leemhuis.info> References: <46041403.6010406@leemhuis.info> <20070323215400.GB21465@neu.nirvana> <46044F47.2070608@leemhuis.info> Message-ID: <20070323222022.GA23093@neu.nirvana> On Fri, Mar 23, 2007 at 11:05:59PM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Fri, Mar 23, 2007 at 06:53:07PM +0100, Thorsten Leemhuis wrote: > > > >> Approving something require at least four Steering Committee members > >> to vote and the majority of the votes wins. > > Isn't that the same? The majority of 7 people is always 4+. Or are you > > saying that we need the majority to attend to a vote and of that > > majority again the majority? > > The latter. > > > The latter doesn't sound that good, as you would end up with passing > > votes that are less than the majority. I would strictly stick to > > having a majority quorum of positive votes compared to the full number > > of members, irrespective of how many are attending the voting. > > I feared/fear that we run into situations where members simply are not > present in votings or not really responsive even on the list; to avoid > that I copied how FESCo works/worked afaics. But well, you have a point, > too. I'll remove that cornercase for now, but will bring that quickly > bring up as adjustments if my fears should become true. Does that sound > sane? A member can still vote via mail/wiki, and if he/she is not even available for doing that within a reasonable amount of time, then that member is effectivly out of the game and needs to be either temporarily taken from the committee or removed altogether. Effectively that's what your adjustments do also, but in a more automatic way. I'd say better handle that case (if it comes up) by disabling/removing the MIA member temporarily or permanantly upon the member's request or at the rest of the committee's discretion. We had that situation once in the FPC, and did just that at the end. > >> * when FESCo member reads what the EPEL Steering Committee decided and > >> disagrees with that > > Since the decisions of this committee are reported and ratified by > > fesco, is this needed? This sounds like we do some work and get it > > approved by fesco. And then two weeks later a fesco member returns > > from vacation and quotes this sentence to undo everything. > > It was more meant as clarification, but seems it is more confusing that > helping now that I look at it again. I'll take a look to make this more > clear later and will set a definite timeframe for a FESCo veto, to make > it more clear. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Mar 23 22:32:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 Mar 2007 23:32:30 +0100 Subject: ABI diff tools In-Reply-To: <20070322235103.GA3448@neu.nirvana> References: <20070322233000.GB3145@free.fr> <20070322235103.GA3448@neu.nirvana> Message-ID: <20070323223230.GD17494@free.fr> On Fri, Mar 23, 2007 at 12:51:03AM +0100, Axel Thimm wrote: > On Fri, Mar 23, 2007 at 12:30:00AM +0100, Patrice Dumas wrote: > > I am searching for a program that would allow to compare 2 libs or a lib > > and an application, find the binary interface differences and display > > them conveniently. Does something like that exist? I think that it would > > be very convenient to help maintaining ABI compatibility in EPEL packages. > > That would be a nice tool, but how would it help EPEL? It would rather I maintain library foo in epel. Upstream issue a new version. I use the ABI comparison to patch the new version to re-add the symbols needed to keep ABI compatibility. But maybe this is never that simple... > For creating such a tool the nearest you could get would be to simply > dump and sort the symbols including function signatures if available > and compare them. Indeed i am searching something that does that. > But C does not encode arguments to functions into > the symbols so large part of the ABI information is implicit. But at > least you would get part of the ABI to check. So that part of the ABI is only visible in header files, or by seeing a segfault at runtime? -- Pat From plazonic at math.princeton.edu Fri Mar 23 23:56:19 2007 From: plazonic at math.princeton.edu (=?UTF-8?B?Sm9za28gUGxhem9uaWM=?=) Date: Fri, 23 Mar 2007 23:56:19 +0000 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <20070323222022.GA23093@neu.nirvana> References: <46041403.6010406@leemhuis.info><20070323215400.GB21465@neu.nirvana><46044F47.2070608@leemhuis.info> <20070323222022.GA23093@neu.nirvana> Message-ID: <1465413308-1174694181-cardhu_blackberry.rim.net-516681733-@bwe059-cell00.bisx.prod.on.blackberry> Alora, domani mattina ho da fare e non credo di essere libero prima di 15-16:00. Dunque domenica mi suona meglio. Hai qualcosa in mente - da vedere/visitare o non hai piani/desideri? Stai di nuovo a New York? Josko P. -----Original Message----- From: Axel Thimm Date: Fri, 23 Mar 2007 23:20:22 To:EPEL development disccusion Subject: Re: Proposal for a EPEL Steering Committee On Fri, Mar 23, 2007 at 11:05:59PM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Fri, Mar 23, 2007 at 06:53:07PM +0100, Thorsten Leemhuis wrote: > > > >> Approving something require at least four Steering Committee members > >> to vote and the majority of the votes wins. > > Isn't that the same? The majority of 7 people is always 4+. Or are you > > saying that we need the majority to attend to a vote and of that > > majority again the majority? > > The latter. > > > The latter doesn't sound that good, as you would end up with passing > > votes that are less than the majority. I would strictly stick to > > having a majority quorum of positive votes compared to the full number > > of members, irrespective of how many are attending the voting. > > I feared/fear that we run into situations where members simply are not > present in votings or not really responsive even on the list; to avoid > that I copied how FESCo works/worked afaics. But well, you have a point, > too. I'll remove that cornercase for now, but will bring that quickly > bring up as adjustments if my fears should become true. Does that sound > sane? A member can still vote via mail/wiki, and if he/she is not even available for doing that within a reasonable amount of time, then that member is effectivly out of the game and needs to be either temporarily taken from the committee or removed altogether. Effectively that's what your adjustments do also, but in a more automatic way. I'd say better handle that case (if it comes up) by disabling/removing the MIA member temporarily or permanantly upon the member's request or at the rest of the committee's discretion. We had that situation once in the FPC, and did just that at the end. > >> * when FESCo member reads what the EPEL Steering Committee decided and > >> disagrees with that > > Since the decisions of this committee are reported and ratified by > > fesco, is this needed? This sounds like we do some work and get it > > approved by fesco. And then two weeks later a fesco member returns > > from vacation and quotes this sentence to undo everything. > > It was more meant as clarification, but seems it is more confusing that > helping now that I look at it again. I'll take a look to make this more > clear later and will set a definite timeframe for a FESCo veto, to make > it more clear. -- Axel.Thimm at ATrpms.net _______________________________________________ epel-devel-list mailing list epel-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list From plazonic at math.princeton.edu Sat Mar 24 00:07:43 2007 From: plazonic at math.princeton.edu (=?UTF-8?B?Sm9za28gUGxhem9uaWM=?=) Date: Sat, 24 Mar 2007 00:07:43 +0000 Subject: Proposal for a EPEL Steering Committee In-Reply-To: <1465413308-1174694181-cardhu_blackberry.rim.net-516681733-@bwe059-cell00.bisx.prod.on.blackberry> References: <46041403.6010406@leemhuis.info><20070323215400.GB21465@neu.nirvana><46044F47.2070608@leemhuis.info><20070323222022.GA23093@neu.nirvana> <1465413308-1174694181-cardhu_blackberry.rim.net-516681733-@bwe059-cell00.bisx.prod.on.blackberry> Message-ID: <2101846267-1174694865-cardhu_blackberry.rim.net-801649279-@bwe014-cell00.bisx.prod.on.blackberry> Apologies - please disregard the idiot who hit the reply on the wrong email (in my defence I did it is on a tiny phone screen where you can hardly see to who you are writing....). Josko P. -----Original Message----- From: "Josko Plazonic" Date: Fri, 23 Mar 2007 23:56:19 To:"EPEL development disccusion" Subject: Re: Proposal for a EPEL Steering Committee Alora, domani mattina ho da fare e non credo di essere libero prima di 15-16:00. Dunque domenica mi suona meglio. Hai qualcosa in mente - da vedere/visitare o non hai piani/desideri? Stai di nuovo a New York? Josko P. -----Original Message----- From: Axel Thimm Date: Fri, 23 Mar 2007 23:20:22 To:EPEL development disccusion Subject: Re: Proposal for a EPEL Steering Committee On Fri, Mar 23, 2007 at 11:05:59PM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Fri, Mar 23, 2007 at 06:53:07PM +0100, Thorsten Leemhuis wrote: > > > >> Approving something require at least four Steering Committee members > >> to vote and the majority of the votes wins. > > Isn't that the same? The majority of 7 people is always 4+. Or are you > > saying that we need the majority to attend to a vote and of that > > majority again the majority? > > The latter. > > > The latter doesn't sound that good, as you would end up with passing > > votes that are less than the majority. I would strictly stick to > > having a majority quorum of positive votes compared to the full number > > of members, irrespective of how many are attending the voting. > > I feared/fear that we run into situations where members simply are not > present in votings or not really responsive even on the list; to avoid > that I copied how FESCo works/worked afaics. But well, you have a point, > too. I'll remove that cornercase for now, but will bring that quickly > bring up as adjustments if my fears should become true. Does that sound > sane? A member can still vote via mail/wiki, and if he/she is not even available for doing that within a reasonable amount of time, then that member is effectivly out of the game and needs to be either temporarily taken from the committee or removed altogether. Effectively that's what your adjustments do also, but in a more automatic way. I'd say better handle that case (if it comes up) by disabling/removing the MIA member temporarily or permanantly upon the member's request or at the rest of the committee's discretion. We had that situation once in the FPC, and did just that at the end. > >> * when FESCo member reads what the EPEL Steering Committee decided and > >> disagrees with that > > Since the decisions of this committee are reported and ratified by > > fesco, is this needed? This sounds like we do some work and get it > > approved by fesco. And then two weeks later a fesco member returns > > from vacation and quotes this sentence to undo everything. > > It was more meant as clarification, but seems it is more confusing that > helping now that I look at it again. I'll take a look to make this more > clear later and will set a definite timeframe for a FESCo veto, to make > it more clear. -- Axel.Thimm at ATrpms.net _______________________________________________ epel-devel-list mailing list epel-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list _______________________________________________ epel-devel-list mailing list epel-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list From Axel.Thimm at ATrpms.net Sat Mar 24 00:24:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 24 Mar 2007 01:24:29 +0100 Subject: ABI diff tools In-Reply-To: <20070323223230.GD17494@free.fr> References: <20070322233000.GB3145@free.fr> <20070322235103.GA3448@neu.nirvana> <20070323223230.GD17494@free.fr> Message-ID: <20070324002429.GA25468@neu.nirvana> On Fri, Mar 23, 2007 at 11:32:30PM +0100, Patrice Dumas wrote: > > But C does not encode arguments to functions into > > the symbols so large part of the ABI information is implicit. But at > > least you would get part of the ABI to check. > > So that part of the ABI is only visible in header files, or by seeing > a segfault at runtime? The header files expose the API: if you check that for equivalence, then the ABI is given, as the ABI is derived from API and environment (e.g. platform, architecture and toolchain). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Mar 24 01:13:34 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 23 Mar 2007 21:13:34 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-03-23 Message-ID: <20070324011334.5B050152130@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW apcupsd-3.14.0-1.el5 NEW lzo-2.02-2.el5 NEW openvpn-2.1-0.17.rc2.el5 NEW python-setuptools-0.6c5-1.el5 NEW sqlgrey-1.7.5-1.el5 Packages built and released for Fedora EPEL 4: 4 NEW apcupsd-3.14.0-1.el4 NEW lzo-1.08-2 NEW openvpn-2.1-0.17.rc2.el4 NEW sqlgrey-1.7.5-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From pertusus at free.fr Sat Mar 24 17:46:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 24 Mar 2007 18:46:12 +0100 Subject: ABI diff tools In-Reply-To: <20070324002429.GA25468@neu.nirvana> References: <20070322233000.GB3145@free.fr> <20070322235103.GA3448@neu.nirvana> <20070323223230.GD17494@free.fr> <20070324002429.GA25468@neu.nirvana> Message-ID: <20070324174612.GA3159@free.fr> On Sat, Mar 24, 2007 at 01:24:29AM +0100, Axel Thimm wrote: > On Fri, Mar 23, 2007 at 11:32:30PM +0100, Patrice Dumas wrote: > > > But C does not encode arguments to functions into > > > the symbols so large part of the ABI information is implicit. But at > > > least you would get part of the ABI to check. > > > > So that part of the ABI is only visible in header files, or by seeing > > a segfault at runtime? > > The header files expose the API: if you check that for equivalence, > then the ABI is given, as the ABI is derived from API and environment > (e.g. platform, architecture and toolchain). Indeed, but sometimes API differences are not easy to spot (and for fortran in many cases there is no API), I hoped it was possible to use more easily ABI differences. Seems like it isn't really possible if prototypes are not in the ABI. -- Pat From buildsys at fedoraproject.org Mon Mar 26 12:05:10 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 26 Mar 2007 08:05:10 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-03-26 Message-ID: <20070326120510.37EBF152130@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 8 ganglia-3.0.4-2.el5 NEW php-pecl-zip-1.8.8-1.el5 NEW postgresql-dbi-link-2.0.0-3.el5 NEW python-html2text-2.26-2.el5 NEW rss2email-2.60-3.el5 NEW ssmtp-2.61-11.1.el5 NEW yumex-1.9.5-1.0.el5 NEW zziplib-0.13.49-1.el5 Packages built and released for Fedora EPEL 4: 6 NEW epel-release-4-5 lzo-1.08-2.el4 NEW postgresql-dbi-link-2.0.0-3.el4 NEW python-html2text-2.26-2.el4 NEW rss2email-2.60-3.el4 NEW zziplib-0.13.49-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Mon Mar 26 12:12:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 07:12:10 -0500 Subject: epel4/ppc? missing sqlite? In-Reply-To: <4604093A.4050007@math.unl.edu> References: <4604093A.4050007@math.unl.edu> Message-ID: <4607B89A.4020406@math.unl.edu> Rex Dieter wrote: > wtf? > http://buildsys.fedoraproject.org/build-status/job.psp?uid=30189 > > First off, I guess I didn't even realize el4/ppc existed, ok, fine. > > But, > No Package Found for sqlite-devel > ? While we're on the topic, I was going to conditionalize out support for sqlite on el4/ppc, but just noticed something, our builders define the macro 'epel 4' but not 'rhel 4', is that on purpose or an oversight? -- Rex From dag at wieers.com Mon Mar 26 12:15:36 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 26 Mar 2007 14:15:36 +0200 (CEST) Subject: epel4/ppc? missing sqlite? In-Reply-To: <4607B89A.4020406@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <4607B89A.4020406@math.unl.edu> Message-ID: On Mon, 26 Mar 2007, Rex Dieter wrote: > Rex Dieter wrote: > > wtf? > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=30189 > > > > First off, I guess I didn't even realize el4/ppc existed, ok, fine. > > > > But, > > No Package Found for sqlite-devel > > ? > > While we're on the topic, I was going to conditionalize out support for sqlite > on el4/ppc, but just noticed something, our builders define the macro 'epel 4' > but not 'rhel 4', is that on purpose or an oversight? Shouldn't it be 'el 4' ? That's what RPMforge uses since the packages are not specific to Red Hat and the disttag is el4 anyway, not rhel4. As I mentioned before, we also set the macro 'el4 1', and not 'rhel4 1'. A little consistency between disttags and macros would be nice. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rdieter at math.unl.edu Mon Mar 26 12:19:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 07:19:55 -0500 Subject: epel4/ppc? missing sqlite? In-Reply-To: References: <4604093A.4050007@math.unl.edu> <4607B89A.4020406@math.unl.edu> Message-ID: <4607BA6B.4040709@math.unl.edu> Dag Wieers wrote: > On Mon, 26 Mar 2007, Rex Dieter wrote: > >> Rex Dieter wrote: >>> wtf? >>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=30189 >>> >>> First off, I guess I didn't even realize el4/ppc existed, ok, fine. >>> >>> But, >>> No Package Found for sqlite-devel >>> ? >> While we're on the topic, I was going to conditionalize out support for sqlite >> on el4/ppc, but just noticed something, our builders define the macro 'epel 4' >> but not 'rhel 4', is that on purpose or an oversight? > > Shouldn't it be 'el 4' ? Well, previous discussions said rhel, but honestly, I don't care... > A little consistency between disttags and macros would be nice. +1 -- Rex From rdieter at math.unl.edu Mon Mar 26 12:23:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 07:23:39 -0500 Subject: epel4/ppc? missing sqlite? In-Reply-To: <4607BA6B.4040709@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <4607B89A.4020406@math.unl.edu> <4607BA6B.4040709@math.unl.edu> Message-ID: <4607BB4B.4030609@math.unl.edu> Rex Dieter wrote: > Dag Wieers wrote: >> On Mon, 26 Mar 2007, Rex Dieter wrote: >> >>> Rex Dieter wrote: >>>> wtf? >>>> http://buildsys.fedoraproject.org/build-status/job.psp?uid=30189 >>>> >>>> First off, I guess I didn't even realize el4/ppc existed, ok, fine. >>>> >>>> But, >>>> No Package Found for sqlite-devel >>>> ? >>> While we're on the topic, I was going to conditionalize out support >>> for sqlite >>> on el4/ppc, but just noticed something, our builders define the macro >>> 'epel 4' >>> but not 'rhel 4', is that on purpose or an oversight? >> >> Shouldn't it be 'el 4' ? > > Well, previous discussions said rhel, but honestly, I don't care... My bad, dgilmore pointed out in irc that this is only when issuing local builds in the cvs dir, via e.g. 'make i386', it sets --define "dist .el4" --define "epel 4" So, not buildsys-related at all, my bad, move on, nothing to see here. -- Rex From Michael_E_Brown at dell.com Mon Mar 26 18:15:05 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 26 Mar 2007 13:15:05 -0500 Subject: epel4/ppc? missing sqlite? In-Reply-To: <4607BA6B.4040709@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <4607B89A.4020406@math.unl.edu> <4607BA6B.4040709@math.unl.edu> Message-ID: <20070326181504.GE6065@humbolt.us.dell.com> On Mon, Mar 26, 2007 at 07:19:55AM -0500, Rex Dieter wrote: > Dag Wieers wrote: > >On Mon, 26 Mar 2007, Rex Dieter wrote: > >>While we're on the topic, I was going to conditionalize out support for > >>sqlite > >>on el4/ppc, but just noticed something, our builders define the macro > >>'epel 4' > >>but not 'rhel 4', is that on purpose or an oversight? > > > >Shouldn't it be 'el 4' ? > > Well, previous discussions said rhel, but honestly, I don't care... > > >A little consistency between disttags and macros would be nice. > > +1 +1 -- Michael From rdieter at math.unl.edu Mon Mar 26 18:27:30 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 13:27:30 -0500 Subject: epel4: missing sqlite? In-Reply-To: <4604093A.4050007@math.unl.edu> References: <4604093A.4050007@math.unl.edu> Message-ID: <46081092.1000607@math.unl.edu> Rex Dieter wrote: > No Package Found for sqlite-devel OK, now it's not finding sqlite-devel for el4/x86_64 too. http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log All I know, is that sqlite (and sqlite-devel) *is* there in centos4 (4.4, i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include sqlite, where did centos4 get it from? -- Rex From Axel.Thimm at ATrpms.net Mon Mar 26 18:42:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 20:42:45 +0200 Subject: epel4: missing sqlite? In-Reply-To: <46081092.1000607@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> Message-ID: <20070326184245.GF9977@neu.nirvana> On Mon, Mar 26, 2007 at 01:27:30PM -0500, Rex Dieter wrote: > Rex Dieter wrote: > > >No Package Found for sqlite-devel > > OK, now it's not finding sqlite-devel for el4/x86_64 too. > http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log > > All I know, is that sqlite (and sqlite-devel) *is* there in centos4 > (4.4, i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include > sqlite, where did centos4 get it from? There is no sqlite in RHEL4 or RHEL5. The package CentOS is using is perhaps in the extras repository. ATrpms also needed sqlite for RHEL4/3 and had to rebuild it from FC. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 26 18:56:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Mar 2007 20:56:03 +0200 Subject: epel4: missing sqlite? In-Reply-To: <20070326184245.GF9977@neu.nirvana> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> Message-ID: <46081743.5060902@leemhuis.info> Axel Thimm schrieb: > On Mon, Mar 26, 2007 at 01:27:30PM -0500, Rex Dieter wrote: >> Rex Dieter wrote: >> >>> No Package Found for sqlite-devel >> OK, now it's not finding sqlite-devel for el4/x86_64 too. >> http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log >> >> All I know, is that sqlite (and sqlite-devel) *is* there in centos4 >> (4.4, i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include >> sqlite, where did centos4 get it from? > > There is no sqlite in RHEL4 Likely, but I don't have a tree at hand to test. > or RHEL5. Wrong afaics; loop backed RHEL5-Destkop-ISO: $ find . -name 'sqli*' ./Client/sqlite-3.3.6-2.i386.rpm ./Workstation/sqlite-devel-3.3.6-2.i386.rpm > [...] Cu thl From Axel.Thimm at ATrpms.net Mon Mar 26 19:11:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 21:11:19 +0200 Subject: epel4: missing sqlite? In-Reply-To: <46081743.5060902@leemhuis.info> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <46081743.5060902@leemhuis.info> Message-ID: <20070326191119.GI9977@neu.nirvana> On Mon, Mar 26, 2007 at 08:56:03PM +0200, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > >On Mon, Mar 26, 2007 at 01:27:30PM -0500, Rex Dieter wrote: > >>Rex Dieter wrote: > >> > >>>No Package Found for sqlite-devel > >>OK, now it's not finding sqlite-devel for el4/x86_64 too. > >>http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log > >> > >>All I know, is that sqlite (and sqlite-devel) *is* there in centos4 > >>(4.4, i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include > >>sqlite, where did centos4 get it from? > > > >There is no sqlite in RHEL4 > > Likely, but I don't have a tree at hand to test. > > >or RHEL5. > > Wrong afaics; Sorry that was a typo, it should be RHEL3. Anyway here are the builds I'm using since Aug 2006 for RHEL4 and RHEL3: http://atrpms.net/name/sqlite/ For RHEL5 I'm using what RHEL5 ships, of course. RHEL5 ships 3.3.6-2, ATrpms' RHEL4/5 3.1.2-2.99_2 (a side-port from FC's 3.1.2-3, the 2.99 is intended to be lesses than 3). I checked Dag, but he's not shipping any sqlite fro RHEL, not sure where Rex picked sqlite at CentOS. So if EPEL4/3 will build sqlite it would be best to be between 3.1.2-3 and 3.3.6-2 to accomodate for RHEL5 and ATrpms. Rex, which version of sqlite did you get on CentOS4? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 26 19:24:46 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 14:24:46 -0500 Subject: epel4: missing sqlite? In-Reply-To: <20070326184245.GF9977@neu.nirvana> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> Message-ID: <46081DFE.7020705@math.unl.edu> Axel Thimm wrote: > On Mon, Mar 26, 2007 at 01:27:30PM -0500, Rex Dieter wrote: >> Rex Dieter wrote: >> >>> No Package Found for sqlite-devel >> OK, now it's not finding sqlite-devel for el4/x86_64 too. >> http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log >> >> All I know, is that sqlite (and sqlite-devel) *is* there in centos4 >> (4.4, i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include >> sqlite, where did centos4 get it from? > > There is no sqlite in RHEL4 or RHEL5. The package CentOS is using is > perhaps in the extras repository. double-checked, it's in the centos4 main/os repo. Maybe I should go ask on a centos list where it came from... -- Rex From rdieter at math.unl.edu Mon Mar 26 19:37:02 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 14:37:02 -0500 Subject: epel4: missing sqlite? In-Reply-To: <46081DFE.7020705@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <46081DFE.7020705@math.unl.edu> Message-ID: <460820DE.6020009@math.unl.edu> Rex Dieter wrote: > Axel Thimm wrote: >> There is no sqlite in RHEL4 or RHEL5. The package CentOS is using is >> perhaps in the extras repository. > double-checked, it's in the centos4 main/os repo. > Maybe I should go ask on a centos list where it came from... OK, from the horse's mouth: sqlite was included in centos4 (only) for yum. -- Rex From Axel.Thimm at ATrpms.net Mon Mar 26 19:38:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 21:38:58 +0200 Subject: epel4: missing sqlite? In-Reply-To: <460820DE.6020009@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <46081DFE.7020705@math.unl.edu> <460820DE.6020009@math.unl.edu> Message-ID: <20070326193858.GA16942@neu.nirvana> On Mon, Mar 26, 2007 at 02:37:02PM -0500, Rex Dieter wrote: > Rex Dieter wrote: > >Axel Thimm wrote: > > >>There is no sqlite in RHEL4 > > >double-checked, it's in the centos4 main/os repo. > >Maybe I should go ask on a centos list where it came from... > > OK, from the horse's mouth: sqlite was included in centos4 (only) for yum. Which version? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 26 19:41:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 14:41:56 -0500 Subject: epel4: missing sqlite? In-Reply-To: <20070326191119.GI9977@neu.nirvana> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <46081743.5060902@leemhuis.info> <20070326191119.GI9977@neu.nirvana> Message-ID: <46082204.3020205@math.unl.edu> Axel Thimm wrote: > So if EPEL4/3 will build sqlite it would be best to be between 3.1.2-3 > and 3.3.6-2 to accomodate for RHEL5 and ATrpms. Rex, which version of > sqlite did you get on CentOS4? $rpm -q sqlite sqlite-3.3.3-1.2 -- Rex From Axel.Thimm at ATrpms.net Mon Mar 26 19:53:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 21:53:44 +0200 Subject: epel4: missing sqlite? In-Reply-To: <46082204.3020205@math.unl.edu> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <46081743.5060902@leemhuis.info> <20070326191119.GI9977@neu.nirvana> <46082204.3020205@math.unl.edu> Message-ID: <20070326195344.GC16942@neu.nirvana> On Mon, Mar 26, 2007 at 02:41:56PM -0500, Rex Dieter wrote: > Axel Thimm wrote: > > >So if EPEL4/3 will build sqlite it would be best to be between 3.1.2-3 > >and 3.3.6-2 to accomodate for RHEL5 and ATrpms. Rex, which version of > >sqlite did you get on CentOS4? > > $rpm -q sqlite > sqlite-3.3.3-1.2 That's an FC5 rebuild. OK, the EPEL4 would do best to use something between 3.3.3-1.2 and 3.3.6-2 to satisfy all upgrade paths. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Mar 27 09:39:54 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 11:39:54 +0200 Subject: howto coordinate with RHEL packages/pakagers? In-Reply-To: <46030D54.2090806@redhat.com> References: <20070322224119.GA3145@free.fr> <46030D54.2090806@redhat.com> Message-ID: <20070327093954.GD2896@free.fr> On Thu, Mar 22, 2007 at 06:12:20PM -0500, Mike McGrath wrote: > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ Ok, it is indeed enough to have the srpms. However it would be very convenient to have the mapping of a package name to a RH release, otherwise it is very complicated to check that a package exists, and for which bundle exactly. For example, there could be: ant/4/RHAPS2/i386/ant-1.6.2-3jpp_4rh.src.rpm Or is there another possibility? > Bugzilla is the way we do things. Ok. With the srpms it should be enough. -- Pat From wolfy at pcnet.ro Mon Mar 26 18:57:18 2007 From: wolfy at pcnet.ro (lonely wolf) Date: Mon, 26 Mar 2007 21:57:18 +0300 Subject: epel4: missing sqlite? In-Reply-To: <20070326184245.GF9977@neu.nirvana> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> Message-ID: <4608178E.8010400@pcnet.ro> On 03/26/2007 09:42 PM, Axel Thimm wrote: > On Mon, Mar 26, 2007 at 01:27:30PM -0500, Rex Dieter wrote: > >> Rex Dieter wrote: >> >> >>> No Package Found for sqlite-devel >>> >> OK, now it's not finding sqlite-devel for el4/x86_64 too. >> http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log >> >> All I know, is that sqlite (and sqlite-devel) *is* there in centos4 >> (4.4, i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include >> sqlite, where did centos4 get it from? >> > > There is no sqlite in RHEL4 or RHEL5. The package CentOS is using is > perhaps in the extras repository. ATrpms also needed sqlite for > RHEL4/3 and had to rebuild it from FC. > sqlite is in the karan.centos.org repo, not in base. From lance at centos.org Tue Mar 27 12:47:07 2007 From: lance at centos.org (Lance Davis) Date: Tue, 27 Mar 2007 13:47:07 +0100 (BST) Subject: epel4: missing sqlite? In-Reply-To: <4608178E.8010400@pcnet.ro> References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <4608178E.8010400@pcnet.ro> Message-ID: On Mon, 26 Mar 2007, lonely wolf wrote: > On 03/26/2007 09:42 PM, Axel Thimm wrote: >> On Mon, Mar 26, 2007 at 01:27:30PM -0500, Rex Dieter wrote: >> >>> Rex Dieter wrote: >>> >>> >>>> No Package Found for sqlite-devel >>>> >>> OK, now it's not finding sqlite-devel for el4/x86_64 too. >>> http://buildsys.fedoraproject.org/logs/fedora-4-epel/30483-qt4-4.2.3-6.el4.3/x86_64/root.log >>> >>> All I know, is that sqlite (and sqlite-devel) *is* there in centos4 (4.4, >>> i386/x86_64 anyway). If our (rh)el4 buildsys doesn't include sqlite, >>> where did centos4 get it from? >>> >> >> There is no sqlite in RHEL4 or RHEL5. The package CentOS is using is >> perhaps in the extras repository. ATrpms also needed sqlite for >> RHEL4/3 and had to rebuild it from FC. >> > sqlite is in the karan.centos.org repo, not in base. http://mirror.centos.org/centos-4/4.4/os/i386/CentOS/RPMS/sqlite-3.3.3-1.2.i386.rpm Looks like base to me ... -- uklinux.net - The ISP of choice for the discerning Linux user. From rdieter at math.unl.edu Tue Mar 27 12:50:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 07:50:47 -0500 Subject: fyi: qt4: rhel5 vs epel-4 Message-ID: <46091327.3000409@math.unl.edu> Just checked that rhel5 includes qt4. Biggest issue being: 1. upgrade path is busted. rhel5's qt4-4.2.1-1 vs epel4's qt4-4.2.3 I guess there's not much to do about that now. Suggestions? Is it worth worrying much about at this point? And to a lesser degree: 2. the rhel5 pkg only loosely followed extras's qt4 packaging (it varies in a few significant ways). I'll make rh maintainer aware. -- Rex From wolfy at nobugconsulting.ro Tue Mar 27 13:01:59 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 27 Mar 2007 16:01:59 +0300 Subject: epel4: missing sqlite? In-Reply-To: References: <4604093A.4050007@math.unl.edu> <46081092.1000607@math.unl.edu> <20070326184245.GF9977@neu.nirvana> <4608178E.8010400@pcnet.ro> Message-ID: <460915C7.6040600@nobugconsulting.ro> Lance Davis wrote: >> sqlite is in the karan.centos.org repo, not in base. > > http://mirror.centos.org/centos-4/4.4/os/i386/CentOS/RPMS/sqlite-3.3.3-1.2.i386.rpm > > > Looks like base to me ... yes, you are right. I was on drugs :) (actually I used rpm -qi and misinterpreted the output) From Axel.Thimm at ATrpms.net Tue Mar 27 13:36:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Mar 2007 15:36:30 +0200 Subject: fyi: qt4: rhel5 vs epel-4 In-Reply-To: <46091327.3000409@math.unl.edu> References: <46091327.3000409@math.unl.edu> Message-ID: <20070327133630.GB29067@neu.nirvana> On Tue, Mar 27, 2007 at 07:50:47AM -0500, Rex Dieter wrote: > Just checked that rhel5 includes qt4. Biggest issue being: > 1. upgrade path is busted. rhel5's qt4-4.2.1-1 vs epel4's qt4-4.2.3 > I guess there's not much to do about that now. Suggestions? Is it > worth worrying much about at this point? I think the current state of affairs is more like rawhide, e.g. you can downgrade a package, I guess. Better than to have unupgradeable items. There is a mass rebuilkd happening (or happened) anyway for beta -> GA. We should probably make sure that RHEL4+EPEL4 upgrades properly to RHEL5 for all packages (not only qt4) before EPEL4 is user-announced. > And to a lesser degree: > 2. the rhel5 pkg only loosely followed extras's qt4 packaging (it > varies in a few significant ways). I'll make rh maintainer aware. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Mar 27 14:29:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Mar 2007 16:29:05 +0200 Subject: Rebuild for RHEL5 final Message-ID: <46092A31.3040001@leemhuis.info> Hi all! In the meeting last Sunday (I'll write the summary later) it was agreed on to rebuild all the packages of EPEL5 once we have RHEL5 in place on the builders (which should happen soon or has already happened) as everything which is in EPEL5 now was build against RHEL5Beta1, which is quite old and a lot of stuff changed for the final. The idea that was agreed on in the meeting was to just delete the EEPL5 repo and rebuild everything once automatically in the proper order without changing %release. Now that I've thought about it some more I don't like that plan that much anymore, as then it's not possible to differentiate if people have the old or the new package installed. Sure, that shouldn't be many people yet, but nevertheless it could create problems. Opinions? Just ignore that? Or simply do a script-build mass rebuild of EPEL5 with increased %release? CUI thl From orion at cora.nwra.com Tue Mar 27 15:17:09 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 27 Mar 2007 09:17:09 -0600 Subject: Rebuild for RHEL5 final In-Reply-To: <46092A31.3040001@leemhuis.info> References: <46092A31.3040001@leemhuis.info> Message-ID: <46093575.30103@cora.nwra.com> Thorsten Leemhuis wrote: > Hi all! > > Now that I've thought about it some more I don't like that plan that > much anymore, as then it's not possible to differentiate if people have > the old or the new package installed. Sure, that shouldn't be many > people yet, but nevertheless it could create problems. > > Opinions? Just ignore that? Or simply do a script-build mass rebuild of > EPEL5 with increased %release? Script release bump works for me. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Michael_E_Brown at dell.com Tue Mar 27 15:19:07 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 27 Mar 2007 10:19:07 -0500 Subject: Rebuild for RHEL5 final In-Reply-To: <46093575.30103@cora.nwra.com> References: <46092A31.3040001@leemhuis.info> <46093575.30103@cora.nwra.com> Message-ID: <20070327151907.GA30488@humbolt.us.dell.com> On Tue, Mar 27, 2007 at 09:17:09AM -0600, Orion Poplawski wrote: > Thorsten Leemhuis wrote: > >Hi all! > > > >Now that I've thought about it some more I don't like that plan that > >much anymore, as then it's not possible to differentiate if people have > >the old or the new package installed. Sure, that shouldn't be many > >people yet, but nevertheless it could create problems. > > > >Opinions? Just ignore that? Or simply do a script-build mass rebuild of > >EPEL5 with increased %release? > > Script release bump works for me. Works for me as well. Please very clearly communicate what you are going to be doing in a new thread once it has been decided. Thanks, Michael From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 27 15:23:43 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Mar 2007 17:23:43 +0200 Subject: Rebuild for RHEL5 final In-Reply-To: <20070327151907.GA30488@humbolt.us.dell.com> References: <46092A31.3040001@leemhuis.info> <46093575.30103@cora.nwra.com> <20070327151907.GA30488@humbolt.us.dell.com> Message-ID: <20070327172343.12f57f77@python3.es.egwn.lan> Michael E Brown wrote : > On Tue, Mar 27, 2007 at 09:17:09AM -0600, Orion Poplawski wrote: > > Thorsten Leemhuis wrote: > > >Hi all! > > > > > >Now that I've thought about it some more I don't like that plan that > > >much anymore, as then it's not possible to differentiate if people have > > >the old or the new package installed. Sure, that shouldn't be many > > >people yet, but nevertheless it could create problems. > > > > > >Opinions? Just ignore that? Or simply do a script-build mass rebuild of > > >EPEL5 with increased %release? > > > > Script release bump works for me. > > Works for me as well. Please very clearly communicate what you are going to be > doing in a new thread once it has been decided. Doesn't work that well for me, since I use a lot of identical spec files across distros and releases. Could work if the devel branches of my packages were also bumped, as otherwise the next devel update I would then "backport" to EL5 would be an invalid build (same EVR as the bumped rebuild). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 0.34 0.33 0.28 From dennis at ausil.us Tue Mar 27 16:09:11 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 27 Mar 2007 11:09:11 -0500 Subject: Rebuild for RHEL5 final In-Reply-To: <20070327172343.12f57f77@python3.es.egwn.lan> References: <46092A31.3040001@leemhuis.info> <20070327151907.GA30488@humbolt.us.dell.com> <20070327172343.12f57f77@python3.es.egwn.lan> Message-ID: <200703271109.11401.dennis@ausil.us> On Tuesday 27 March 2007 10:23:43 am Matthias Saou wrote: > Michael E Brown wrote : > > On Tue, Mar 27, 2007 at 09:17:09AM -0600, Orion Poplawski wrote: > > > Thorsten Leemhuis wrote: > > > >Hi all! > > > > > > > >Now that I've thought about it some more I don't like that plan that > > > >much anymore, as then it's not possible to differentiate if people > > > > have the old or the new package installed. Sure, that shouldn't be > > > > many people yet, but nevertheless it could create problems. > > > > > > > >Opinions? Just ignore that? Or simply do a script-build mass rebuild > > > > of EPEL5 with increased %release? > > > > > > Script release bump works for me. > > > > Works for me as well. Please very clearly communicate what you are going > > to be doing in a new thread once it has been decided. > > Doesn't work that well for me, since I use a lot of identical spec > files across distros and releases. Could work if the devel branches > of my packages were also bumped, as otherwise the next devel update I > would then "backport" to EL5 would be an invalid build (same EVR as > the bumped rebuild). > > Matthias rebuild would happen with a .1 appended to your next build will be ok -- Dennis Gilmore, RHCE From fedora at leemhuis.info Tue Mar 27 17:05:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Mar 2007 19:05:21 +0200 Subject: Log from last EPEL SIG meeting Message-ID: <46094ED1.7090204@leemhuis.info> = Meeting 20070325 = [[TableOfContents]] == Attending == * dgilmore * mmcgrath * nirik * quaid * stahnma * thimm * thl == Summary == * RHEL5 final should be on the builders soon (maybe already when you read this); thl will announce to Fedora contributors to actually start to build for EPEL5 -- seems to him a lot of people wait for a "Go" signal. The packages currently in EPEL5 probably need a rebuild; it was discussed to simply delete the repo and build the packages again, but between the meeting and writing the logs this issue was raised again on the list * repo layout -- outlined in http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates might need updates/modified tools; anyone willing to help? * shortcut for branching ; dgilmore has something locally; for now send him an email or irc ping and i can ping all of a owners packages ; including a list of packages might be helpful in case you don't want all of your packages branched * we sooner or later need scripts that check upgrade paths, repoclosure and similar stuff (like: making sure no packages enter the repo that are part of the base); reuse the Fedora scripts? should work, but they probably need adjustments and enhancements ; anyone willing to help? * EPEL Steering Committee proposal http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee ; small details were mentioned and added to the proposal; will get send to fedora-maintainers (happened already) and then to FESCo for further discussion and ratifying * New meeting time -- it was agreed on to meet on Wednesday at 17:00 UTC in the future == Full Log == {{{ 00:00 < dgilmore> | thl, thimm, stahnma, mmcgrath, quaid, spot, jima. EEPLE meeting ping 00:00 < mmcgrath> | pong 00:00 --- | thl has changed the topic to: EPEL meeting 00:00 < thl> | dgilmore, pong 00:01 < dgilmore> | http://fedoraproject.org/wiki/EPEL/Schedule schedule 00:01 * | nirik is here too. 00:01 < thl> | dgilmore, what the RHEL5 on builder status? 00:01 < dgilmore> | sorry nirik forgot to ping you too 00:02 < nirik> | no worries. ;) 00:02 < dgilmore> | thl: Im going to make it happen today 00:02 < thl> | dgilmore, great 00:02 < thl> | well, that creates two questions afaics: 00:02 * | mmcgrath notes we still don't have clearence to do that. 00:02 < nirik> | for testing is the centos beta pretty close to the same as whatsa in el5? 00:02 < thl> | a) shall we tell everybody to actually start for real? 00:02 < thl> | b) rebuild everything again? 00:02 --> | thim1 (Axel Thimm) has joined #fedora-meeting 00:02 <-- | thim1 has quit (Client Quit) 00:02 < thl> | nirik, centos beta is rhel5beta2 00:02 < mmcgrath> | I think b) would be good to do if for no other reason then to help test koji. 00:03 < thl> | nirik, but that should be good enough; and the final should be out soon afaics 00:03 --> | thim1 has joined #fedora-meeting 00:03 --> | thim1 is Axel Thimm 00:03 * | dgilmore has been stuck in koji for last couple of days 00:03 < nirik> | ok. Does a rebuild mean bump release on everything? 00:03 < dgilmore> | nirik: yep 00:03 < thl> | nirik, yes, but we can use the script 00:03 < thl> | mmcgrath, -ECanFollow 00:03 < nirik> | also, only el-5? or el-4 as well? 00:04 < thl> | mmcgrath, do the builders use koji already? 00:04 < dgilmore> | nirik: only EL-5 00:04 < thl> | nirik, what dgilmore said 00:04 < nirik> | ok 00:04 < thl> | nirik, I can do that 00:04 < mmcgrath> | thl: not yet but they're close. When were you thinking the rebuild would happen? 00:04 < dgilmore> | thl: today or toomoorow they will have koji and plague 00:04 < nirik> | we also might want to make sure that everything thats in el4 is also in el5, and/or was moved into core, or some other good reason why it's not in there... 00:05 < thl> | mmcgrath, I'd say we should annouce it once, so people that want to do the rebuild theirselfs can do; then we can script the rest 00:05 < mmcgrath> | dgilmore: how close is it to actually being put into a package build -> sign -> move to mirror. 00:05 < thl> | dgilmore, sounds fun :) 00:06 < dgilmore> | mmcgrath: right now all id need to do is setup a cron job to rsync results to buildsys 00:06 < mmcgrath> | Cool 00:06 < thl> | so, shall we tell people to actually start now? Seems some fedora contributors are waiting for a "go" 00:06 < dgilmore> | mmcgrath: I need to get on lmacken and get bohdi working 00:06 < thim1> | I missed the first couple of minutes (irc kicked me out)=> why rebuild? 00:06 * | quaid is a'lurking 00:06 < mmcgrath> | 00:07 < thl> | hi thimm thim1 00:07 < mmcgrath> | thim1: The current packages are built against betas. 00:07 < dgilmore> | thim1: to have things linked against RHEL5 final 00:07 < thl> | thimm, sopme people feared there might be problems as we build against beta1 until now 00:07 < thl> | z00dax did, and he has a point afaics 00:07 < thim1> | I didn't know that, I thought we were riding on GA 00:07 < mmcgrath> | Personally I'm not worried about it, but I don't want people coming up to us with "such and such package doesn't work. Must be because it was compiled against the beta" 00:08 < thim1> | I agree with rebuilding against GA 00:08 < thim1> | That's why GA != beta 00:08 < thim1> | :) 00:08 < thim1> | But do we need to bump releases? 00:08 < thl> | I'll announce that; wait some days, and script-rebuild the rest 00:08 < dgilmore> | so next on the list is final repo layout 00:08 < thim1> | Can we assume that EPEL was a sandbox and rebuild on the same NVRs? 00:08 < dgilmore> | thats going to take some work to make it happen 00:09 < dgilmore> | thim1: we could if we delete everything first 00:09 < mmcgrath> | honestly since we're still not 'official' I'd be fine deleting all the bin's we currently have. 00:09 < thim1> | Lots of specfiles are now in sync Fedora <-> EPEL, would be sad to frok them all 00:09 < thl> | dgilmore, I'd still like to know if should Fedora controbutors to actually start now 00:09 < thl> | mmcgrath, +1 00:09 < thim1> | I'd go with deleting and rebuilding 00:09 < thim1> | w/o bumping releases 00:09 < mmcgrath> | it just seems less.... murky :-) 00:10 < thim1> | Well, we're not started yet 00:10 < thim1> | ;) 00:10 < dgilmore> | that can be done 00:10 < thl> | mmcgrath, but then you or dgilmore have to do it afaics 00:10 < thl> | I don#t think i have the permissions everywhere to do that 00:10 < thim1> | NExt time we should consider using a disttag of el4.92 for example 00:10 < dgilmore> | thl: id like to wait until we have RHEL5 final but then open the flood gates 00:10 < mmcgrath> | I'm not even sure I have permission to do that. 00:10 < mmcgrath> | I still don't have direct access to the main mirror (I think I'm caught up in a ticket queue) 00:10 < thl> | dgilmore, sure, that what I mean; but if you reall do it today, then we could annouce "go" soon 00:11 < dgilmore> | thl: sure 00:11 < dgilmore> | thl: what do you want me to do? 00:11 < thl> | dgilmore, k, then I'll annouce it when you annouce the RHEL5 GA is in place 00:11 < thl> | dgilmore, well, the rebuild with delete 00:11 < dgilmore> | thl: deleting ok 00:11 < thl> | can you handle that? 00:12 < dgilmore> | thl: yes 00:12 < thl> | also queuing the rebuilds? Or do you need help with that? 00:12 < mmcgrath> | dgilmore: how do we delete whats there? I'm not that familiar with the actual sync script. do they just do a rsync --delete? 00:12 < dgilmore> | thl: there are some scripts to do that 00:12 < dgilmore> | mmcgrath: rm -rf on buildsys 00:12 < thl> | dgilmore, remember to keep the buildorder if possible 00:13 < mmcgrath> | dgilmore:k 00:13 < dgilmore> | mmcgrath: the rsync to master mirror has a --delete-after 00:13 <-- | thimm has quit (Read error: 110 (Connection timed out)) 00:13 < stahnma> | sorry im late 00:13 < mmcgrath> | I figured, didn't want to assume. 00:14 < thl> | k, move to "final repo layout"? 00:14 < thl> | hi stahnma ; thim1 still around? 00:14 < thl> | (just wondering) 00:14 * | thim1 is here 00:14 < dgilmore> | thl: i think what you have proposed is fine but current tools can not work with it 00:14 < thl> | dgilmore, would it be hard to adjust? where is the problem? push scripts? 00:15 < dgilmore> | current tools do do testing either 00:15 < dgilmore> | thl: pushscripts 00:15 < thl> | do do? 00:15 < dgilmore> | thl: bohdi may be better 00:15 < nirik> | what is the proposed repo layout? 00:15 < thl> | nirik, http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates 00:15 < thl> | (near the end) 00:16 < thl> | dgilmore, so what do we do? 00:16 < dgilmore> | i need to get with lmacken and make sure it will work for us 00:16 < thl> | dgilmore, can we have different build targets for now, that get pushed to different directories? 00:16 < thl> | dgilmore, the stuff from lmacken supports testing afaik 00:16 < dgilmore> | thl: we could but that will require work on packagers 00:17 < dgilmore> | thl: it supports testing. Not sure about the sub dir part 00:17 < thl> | dgilmore, can we simply use the testing repo for now as in the layout 00:17 < dgilmore> | does anyone object to the layout? 00:17 < mmcgrath> | not me. 00:18 < thim1> | Where do security updates go into? 00:18 < dgilmore> | thl: for the tetsing part requires changes to push scripts 00:18 < thl> | dgilmore, no, I meant just use testing for now 00:18 < dgilmore> | thim1: straight into the repo not testing 00:18 < thl> | and nothing else 00:18 < thl> | that makes it obvious that this stuff is not ready for the public yet, too 00:18 < dgilmore> | thl: it would require me to for the extras push scripts to do 00:18 < thim1> | OK, are we discussion rebuilds or layout? 00:19 < dgilmore> | s/for/fork/ 00:19 < thl> | dgilmore, can't you just configure a different target dir? 00:19 < thl> | thim1, layout 00:19 < dgilmore> | thl: not that im aware ill look see if i can 00:19 < thim1> | Why are push scripts a problem for the layout? 00:19 < nirik> | how far away is bodhi? 00:19 < dgilmore> | nirik: AFAIK close 00:20 < mmcgrath> | lmacken: ping? 00:20 < dgilmore> | hopefully we can switch to bohdi and koji at the same time 00:20 < thl> | dgilmore, thx; let me know if I can help you with them 00:20 < thim1> | We already have similar setup on the Fedora side of the infrastructure, can't we reuse that? 00:20 < nirik> | cool. That would be ideal... then we have testing support, security updates marking, etc. 00:20 < thl> | thim1, the fedora extras stuff does not handle testing at all 00:20 < thl> | the new stuff from lmacken should 00:21 < thim1> | thl: Understand, thanks! 00:21 < dgilmore> | lets move on 00:21 < thl> | dgilmore, +1 00:21 < dgilmore> | Next on teh list is shortcut for branching 00:21 < mmcgrath> | thim1: 'bohdi' is a whole updates system, its more robust then just our current scripts. Its a good thing :-) 00:21 < thim1> | I know, looking forward to it :) 00:21 < dgilmore> | for now send me an email or irc ping and i can ping all of a owners packages 00:21 --- | thl has changed the topic to: EPEL meeting -- shortcut for branching 00:22 < thl> | dgilmore, is there a way to say "don't branch foo"? 00:22 < dgilmore> | thl: not in what i currently have 00:22 * | nirik needs to branch another of his packages soon... but needs to get the maintainer of the prereqs to branch first. 00:22 < thl> | I for example have several packages that got moved to core 00:22 < thl> | (and thus to RHEL5) 00:22 < dgilmore> | i could quite easily pass a list of packages and branch them 00:23 < thim1> | branch and delete superfluous branches? 00:23 < thl> | dgilmore, maybe something like that would be nice 00:23 < dgilmore> | thl: ill add tho my script the ability to exclude a list 00:23 < thl> | dgilmore, sounds sane, too 00:23 < nirik> | we do need to make sure if something was branched for epel-4 that it's still in epel-5 or rhel-5 core... 00:23 < dgilmore> | nirik: indeed 00:23 < thim1> | We can't control RHEL5 core :) 00:24 < nirik> | sure, but we shouldn't drop a package on upgrade if we can at all avoid it. 00:24 < dgilmore> | nirik: though AFAIK upgrades fron RHEL4 ->RHEL5 are unsupported 00:24 < thim1> | That's not true anymore 00:24 < nirik> | really? wow. ok. 00:24 < dgilmore> | thim1: im wrong? i konda hope so 00:25 < thim1> | Yes, it was an important discussion topic between customers/partners and RHEL 00:25 < thim1> | But maybe not all subscribtion models support it, though 00:25 < dgilmore> | no idea 00:25 < thim1> | Ask you local RHEL representatiove for a detailed product view ;) 00:25 < dgilmore> | but regardless we want to make sure the same functionality exists 00:26 < thim1> | We must make sure that upgrades are not obstructed by EPEL 00:26 < thl> | scripts? 00:26 < thim1> | Otherwise what RHEL and partners have agreed is a different thing 00:26 < dgilmore> | all the branching needs to happen on the cvs server so an admin has to handle it 00:26 < thim1> | thl: scripts? 00:26 < thl> | scripts could check if the upgrade path are fine 00:27 < thim1> | thl+++ 00:27 < thl> | or if a pacakge accidentally enters EPEL5, even if it is part of RHEL5 00:27 < thl> | someone would just need to write them 00:27 < thim1> | Like for FC6+FE6 currently 00:27 < thl> | yeah, but they probably need some adjustments for RHEL 00:27 < thim1> | Reuse the Fedora scripts? 00:27 < thim1> | Sure, depends also on layout 00:27 < thim1> | And testing the testing repo, too 00:28 < nirik> | I think also bodhi does some checking on newly built packages... 00:28 < nirik> | ie, EVR, broken deps, etc. 00:28 < thim1> | About the layout: Do we really want /epel/5/5.0/... or epel/5/5/....? 00:28 < thl> | nirik, yeah, I think so, too 00:28 < dgilmore> | nirik: its supposed to not push packages if it breaks deps 00:28 < thl> | thim1, the reasons for that are in the proposal 00:29 < thl> | I'd say we should keep those scripts in mind, but they are no high priority for the start 00:29 < nirik> | well, if we can start with bodhi they shouldn't be needed... 00:30 < dgilmore> | thl: Tell contributors to start | as sson as RHEL5 is sorted out 00:30 < thl> | dgilmore, will do 00:30 < dgilmore> | moving to next areas 00:30 < thl> | nirik, I don#t want to be a testbed for new stuff ;-) 00:30 < thim1> | thl: I reread the proposal, where is the reason for "5/5.0" ? 00:30 --> | stahnma_ (Michael Stahnke) has joined #fedora-meeting 00:30 < thl> | nirik, at least not more then strictly needed 00:30 < nirik> | thl: sure, but we already are to some extent... koji, etc. ;) 00:31 < dgilmore> | koji will happen for all soon 00:31 < thl> | thim1, below it; starts with "This layout may looks complicated, but has one major benefit:..." 00:31 < thim1> | That explains 5.0, 5.1 etc 00:31 < thim1> | not 5/5.0 00:32 < dgilmore> | thim1: can we talk about the layout on the list please 00:32 < thl> | thim1, you mean the extra 5/ in it? 00:32 < thl> | dgilmore, +1 00:32 < thim1> | thl: yes 00:32 < dgilmore> | lets move on for now and discuss it on the list and come to an agreement 00:32 < thl> | thim1, makes everything a bit easier IMHO 00:32 < thl> | dgilmore, +1 00:32 < dgilmore> | I want to talk about thl's EPEL Steering Committie proposal 00:33 < stahnma_> | +1 00:33 < thl> | dgilmore, I just modified it a small bit 00:33 < thl> | as requested by thim1 on the list 00:33 < thl> | http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee?action=diff&rev2=4&rev1=3 00:34 --- | thl has changed the topic to: EPEL meeting -- EPEL Steering Committee 00:34 < thl> | I'd say I post it to fedora-maintainers tomorrow 00:34 < dgilmore> | thl: ok 00:34 < thl> | and then FESCo can look at it on Thursday, people agree that this is the way forward 00:34 * | mmcgrath is apathetic about SIG vs Steering Committee. 00:35 < thim1> | thl: I like it +1 00:35 < dgilmore> | does anyone have anything to say for or against the propossal 00:35 < mmcgrath> | just as long as progress continues to get made. 00:35 < thl> | mmcgrath, +1 00:35 < thl> | mmcgrath, we probably need to use the wiki a bit more for votings 00:35 < nirik> | it's fine with me, I don't much care either, but if we need to vote on hard things and make decisions, thats fine. 00:35 < dgilmore> | thl: wiki or mailing list 00:36 < thl> | dgilmore, +1 00:36 < thl> | and we should annouce votings beforehand if possible 00:36 < thl> | to make sure people can send in their opinions, even if they can't make the meeting 00:36 < mmcgrath> | thl: +1, yeah people get very picky about that type of voting. 00:36 < thl> | I'll add a note to the proposal 00:37 < thl> | mmcgrath, I know, I'm one of those people sometimes (see FAB list, even if it was no voting) ;-) 00:37 < thl> | other stuff that is missing? 00:38 < dgilmore> | OK time to moveon thl send the propossal out today or toomoorw 00:38 < thl> | k 00:38 < stahnma_> | me fear about the SC is that if we want to get companies and customers involved in EPEL, the SC seems to close them out 00:38 < thim1> | New meeting time? 00:38 --- | dgilmore has changed the topic to: EPEL Meeting -- Free Chat 00:38 < stahnma_> | it's like they have to jump through hoops to get a voice 00:39 < stahnma_> | (my isp will probabl drop during this meeting, so just keep talking if I die) 00:39 < thl> | stahnma_, primary discussion channel is the list 00:39 < thim1> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime 00:39 < thim1> | Only thl and myself added some time slots 00:39 < nirik> | I think we should strive for reaching a consensus on issues, and only vote when there is some kind of deadlock... so normally they would have a voice I would think. 00:39 < thl> | IRC is always just a add on, as not all people can do / like IRC 00:39 < dgilmore> | thim1: all the available times i cant attend 00:40 < thim1> | dgilmore: Which weekday time slots are free for you? 00:40 < nirik> | thim1: almost anytime is ok for me... 00:40 < stahnma_> | just curious, do we a have a US west-coasters? 00:40 < thl> | stahnma_, yes, quaid is 00:40 < mmcgrath> | stahnma_: just quaid 00:40 < mmcgrath> | AFAIK 00:40 < quaid> | but 00:41 < stahnma_> | I thought most were out of Eastern and Central 00:41 < quaid> | I'm very flexible 00:41 < quaid> | like, i was going to approve some Midnight PDT times 00:41 < dgilmore> | thim1: 00:41 < dgilmore> | 23:00-3:00 UTC or 00:41 < dgilmore> | 11:30-12:30 UTC 00:41 < quaid> | and others :) 00:42 < quaid> | there are some early mornings PDT I can do, like Noon UTC 00:42 < dgilmore> | basicly i cant do it doing work time $DayJob wont allow me any more time 00:42 <-- | stahnma has quit (Read error: 110 (Connection timed out)) 00:42 < thim1> | The how about a noon UTc slot? 00:42 < thl> | bad for me 00:42 * | stahnma_ has a similar situation... I am normally on IRC at work, but can't promise a time 00:42 < quaid> | hmm 00:43 < dgilmore> | 11:30UTC is when i get up 00:43 < quaid> | I usually don't have this problem with just East Coast/Europe 00:43 < quaid> | like, what about 2200 UTC? 00:44 < thim1> | That's 0:00 in main parts of Europe 00:44 * | thl heads to bead at around 01:00 UTC 00:44 < quaid> | ah, early to bed, early to rise :) 00:44 < thl> | bed 00:44 < thl> | quaid, yes :) 00:44 < dgilmore> | quaid: i finish work at 23:00UTC 00:44 * | stahnma_ too or 0:00 00:45 < quaid> | evil bosses! 00:45 < thl> | I think the sunday meeting time still seems to match most people best 00:45 < thl> | I know it's not ideal 00:45 < thim1> | I won't be able to come on Sundays 00:45 < thl> | but for now it seems the best afaics 00:45 < dgilmore> | quaid: i hope to have a new one soon but dont want to assume i will 00:45 < quaid> | dgilmore: yeah, i hear dat 00:46 < stahnma_> | I can probably do a day meeting---but I might be unresponsive if I have "real work" to do :) 00:46 < dgilmore> | the only time i could possibly commit to is lunch 00:47 < nirik> | would sat be any better than sunday? 00:47 < dgilmore> | which is when FESCo meeting happens 00:47 < thl> | nirik, thim1's times are http://fedoraproject.org/wiki/EPEL/NewMeetingTime 00:47 < thl> | (mine, too, but no one else used it) 00:48 < thim1> | dgilmore: lunch: when is that in UTC? 00:48 < nirik> | thl: so wed at 00:00UTC wouldn't work for you? 00:49 < thl> | a bit critical now with the dst switch... 00:49 < thl> | (often it's a bit earlier than 01:00 UTC when I seitch of the computers) 00:49 < thim1> | dgilmore: lunchtime=fesco: How about fesco slot on Wed? 00:50 < thl> | btw, FESCo is back to 17:00 UTC iirc, isn#t it? 00:50 < thl> | now with the DST change? 00:50 < dgilmore> | thim1: i added to the list 00:50 < dgilmore> | i cant guarantee my availablility 00:50 < dgilmore> | thl: i cant remeber 00:50 < thim1> | thl: DST changes in the US were two weeks ago 00:50 < thl> | I'd say we give this another week, and try to sort out the details on the list 00:50 < thim1> | So it wn't change agin 00:51 < thl> | thim1, they already switched FESCo last time iirc 00:51 < thim1> | That's what I mean 00:51 < thim1> | They won't switch again 00:51 < thl> | thim1, but it's wrong in http://fedoraproject.org/wiki/EPEL/NewMeetingTime then 00:51 < thim1> | Currently it is 00:00 UTC, that's what it will stay for the summer time 00:52 < thl> | thim1, http://fedoraproject.org/wiki/Development/SteeringCommittee 00:52 < thl> | "Affectionately known as FESCo. Currently meets every Thursday on the Freenode IRC Network in #fedora-meeting at 17:00 UTC." 00:52 < thl> | that what I'm trying to tell you ;-) 00:52 < mmcgrath> | heh 00:52 < thim1> | OK, one of the wiki pages is wrong :) 00:52 < thim1> | Anyway, we should just pick another day than fesco to not collide 00:52 < mmcgrath> | s/one/many/ s/is/are/ :) 00:53 < thl> | thim1, no, it was 00:00 until one or two weeks ago iirc 00:53 < dgilmore> | anyone else have anything else to talk about 00:53 < nirik> | I have one quick Q... 00:53 < mmcgrath> | not I 00:53 < thim1> | dgilmore: when is your lunch time in UTC? 00:53 --> | FrancescoUgolini (Francesco Ugolini) has joined #fedora-meeting 00:54 < nirik> | centos has a 'extras' repo... do we know if they are going to keep doing that? or get those things in epel? do we have any centos contacts? 00:54 < mmcgrath> | don't ask him to give up his lunch. he's a busy guy as it is :P 00:54 < thl> | z00dax in #epel should know 00:54 < nirik> | The main reason I ask is that they have Xfce in there... but it's the old version. I have gotten several requests for 4.4 for epel, but I don't want to step on their toes. 00:54 < dgilmore> | thim1: 17:00:00 UTC 00:54 < thim1> | mmcgrath: dgilmore offered, I'm wouldn't ask otheriwse 00:55 < dgilmore> | nirik: i think they are dropping it not sure 00:55 < mmcgrath> | oh :) 00:55 < thl> | nirik, I'd say asz z00dax 00:55 < nirik> | ok, can check with him. thanks. 00:55 < dgilmore> | thim1: i usually only take lunch one or two days a week 00:56 < stahnma_> | dgilmore: that is a sad state of affairs 00:56 < dgilmore> | stahnma_: it is but i usually dont ahve time to take it 00:56 < dgilmore> | thursdays i take it for fesco 00:58 < dgilmore> | lancelan: ping 00:59 < thim1> | thl: Wed 00:00 UTC? 00:59 < thl> | Wed 17:00 UTC? 01:00 <-- | FrancescoUgolini has quit ("Leaving") 01:00 < dgilmore> | thl: i cant guarantte but i could try 01:00 < mmcgrath> | both WORKSFORME 01:00 < mmcgrath> | as long as I remember :D 01:01 < stahnma_> | please send out a notice on list, and I will try to attend 01:01 < stahnma_> | also a reminder in #epel will help :) 01:01 < thl> | stahnma_, sorry, forgot about it this week 01:01 < stahnma_> | thl it's ok, that's not why I was late today 01:01 < thl> | quaid, wed 17:00 UTC? 01:02 < thim1> | thl: Wed 17:00 UTC OK with me :) 01:02 < dgilmore> | ok So next meeting will be at 17:00 UTC on wednesday 01:03 < dgilmore> | im going to close this meeting in 60 01:03 < thl> | this wednesday? 01:03 < thl> | e.g. in three days? 01:03 < thl> | or in 10 from now? 01:03 < dgilmore> | yes unless you want to wait 10 days 01:03 < thl> | unsure; I'm fine with both :) 01:03 < dgilmore> | lets make it 10 days 01:04 < thl> | dgilmore, +1 01:04 < dgilmore> | probaly wont have much to report in 3 01:04 < stahnma_> | +1 01:04 < dgilmore> | closing in 30 01:04 < dgilmore> | closing in 20 01:04 < dgilmore> | closing in 10 01:05 < dgilmore> | --- Meeting closed -- }}} From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 27 17:07:09 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Mar 2007 19:07:09 +0200 Subject: Rebuild for RHEL5 final In-Reply-To: <200703271109.11401.dennis@ausil.us> References: <46092A31.3040001@leemhuis.info> <20070327151907.GA30488@humbolt.us.dell.com> <20070327172343.12f57f77@python3.es.egwn.lan> <200703271109.11401.dennis@ausil.us> Message-ID: <20070327190709.06868160@python3.es.egwn.lan> Dennis Gilmore wrote : > On Tuesday 27 March 2007 10:23:43 am Matthias Saou wrote: > > Michael E Brown wrote : > > > On Tue, Mar 27, 2007 at 09:17:09AM -0600, Orion Poplawski wrote: > > > > Thorsten Leemhuis wrote: > > > > >Hi all! > > > > > > > > > >Now that I've thought about it some more I don't like that plan that > > > > >much anymore, as then it's not possible to differentiate if people > > > > > have the old or the new package installed. Sure, that shouldn't be > > > > > many people yet, but nevertheless it could create problems. > > > > > > > > > >Opinions? Just ignore that? Or simply do a script-build mass rebuild > > > > > of EPEL5 with increased %release? > > > > > > > > Script release bump works for me. > > > > > > Works for me as well. Please very clearly communicate what you are going > > > to be doing in a new thread once it has been decided. > > > > Doesn't work that well for me, since I use a lot of identical spec > > files across distros and releases. Could work if the devel branches > > of my packages were also bumped, as otherwise the next devel update I > > would then "backport" to EL5 would be an invalid build (same EVR as > > the bumped rebuild). > > > > Matthias > > rebuild would happen with a .1 appended to your next build will be ok OK, if it's not "increased %release" (as it was written), but a ".1" appended to the release, then it does also work for me :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 11.40 11.98 10.89 From Axel.Thimm at ATrpms.net Tue Mar 27 18:13:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Mar 2007 20:13:34 +0200 Subject: Rebuild for RHEL5 final In-Reply-To: <46092A31.3040001@leemhuis.info> References: <46092A31.3040001@leemhuis.info> Message-ID: <20070327181334.GA24089@neu.nirvana> On Tue, Mar 27, 2007 at 04:29:05PM +0200, Thorsten Leemhuis wrote: > Now that I've thought about it some more I don't like that plan that > much anymore, as then it's not possible to differentiate if people have > the old or the new package installed. Sure, that shouldn't be many > people yet, but nevertheless it could create problems. The reason for not doing so were that one would fork all specfiles. > Opinions? Just ignore that? Or simply do a script-build mass rebuild of > EPEL5 with increased %release? I'd say ignore it. The current users of EPEL are on this list. We'll have also other issues to resolve (like qt4 on EPEL4 > qt4 on RHEL5, and if we check we'll probably find more) and we need to keep a rawhide attitude (aka flexibility) otherwise we'll have to start using epochs before launching. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Mar 28 05:45:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Mar 2007 07:45:23 +0200 Subject: Rebuild for RHEL5 final In-Reply-To: <20070327181334.GA24089@neu.nirvana> References: <46092A31.3040001@leemhuis.info> <20070327181334.GA24089@neu.nirvana> Message-ID: <460A00F3.60307@leemhuis.info> On 27.03.2007 20:13, Axel Thimm wrote: > On Tue, Mar 27, 2007 at 04:29:05PM +0200, Thorsten Leemhuis wrote: > [...] >> Opinions? Just ignore that? Or simply do a script-build mass rebuild of >> EPEL5 with increased %release? > I'd say ignore it. The current users of EPEL are on this list. I'm not that sure on this -- EPEL got even mentioned quite a bit in the press already. Those two were the first ones afaics: http://www.phoronix.com/scan.php?page=news_item&px=NTIxNg http://www.pro-linux.de/news/2007/10918.html > We'll have also other issues to resolve (like qt4 on EPEL4 > qt4 on > RHEL5, and if we check we'll probably find more) and we need to keep a > rawhide attitude (aka flexibility) otherwise we'll have to start using > epochs before launching. Regarding that I'd say: Simply remove the current qt4 package from EPEL4 and try to get one in with a lower EVR then the package in RHEL5. CU thl From Axel.Thimm at ATrpms.net Wed Mar 28 08:22:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Mar 2007 10:22:42 +0200 Subject: Rebuild for RHEL5 final In-Reply-To: <460A00F3.60307@leemhuis.info> References: <46092A31.3040001@leemhuis.info> <20070327181334.GA24089@neu.nirvana> <460A00F3.60307@leemhuis.info> Message-ID: <20070328082242.GA8137@neu.nirvana> On Wed, Mar 28, 2007 at 07:45:23AM +0200, Thorsten Leemhuis wrote: > On 27.03.2007 20:13, Axel Thimm wrote: > > On Tue, Mar 27, 2007 at 04:29:05PM +0200, Thorsten Leemhuis wrote: > > [...] > >> Opinions? Just ignore that? Or simply do a script-build mass rebuild of > >> EPEL5 with increased %release? > > I'd say ignore it. The current users of EPEL are on this list. > > I'm not that sure on this -- EPEL got even mentioned quite a bit in the > press already. Those two were the first ones afaics: > > http://www.phoronix.com/scan.php?page=news_item&px=NTIxNg > http://www.pro-linux.de/news/2007/10918.html That doesn't matter I think. It is not that we argue on being secretive, we never announced that the repo contained packages that were already intended for public consumption, the only official source of information, the wiki, is scattered with warnings on beng work in progress. The repo was and is of a rawhide state where we are allowed to do errors and undo them w/o resorting to trickery to get upgrade paths right. E.g. we may remove, rebuild, change the layout etc. at will until we decide we're there. > > We'll have also other issues to resolve (like qt4 on EPEL4 > qt4 on > > RHEL5, and if we check we'll probably find more) and we need to keep a > > rawhide attitude (aka flexibility) otherwise we'll have to start using > > epochs before launching. > > Regarding that I'd say: Simply remove the current qt4 package from EPEL4 > and try to get one in with a lower EVR then the package in RHEL5. Yes, and you can only do that if you assume that the state of the repo was tagged as "experimental, no upgrade paths ensured". And we may hit more, we haven't yet QA scripts in place, we don't even have done any manual QA, and we argue that we value testing and QA even more than Fedora. So let's keep the experimenal-rawhide-like tag on while gathering contributors and building/testing the set. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 29 10:33:49 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 29 Mar 2007 12:33:49 +0200 Subject: Log from last EPEL SIG meeting In-Reply-To: <46094ED1.7090204@leemhuis.info> References: <46094ED1.7090204@leemhuis.info> Message-ID: <20070329123349.20773c9e@python3.es.egwn.lan> Thorsten Leemhuis wrote : > * RHEL5 final should be on the builders soon (maybe already when you > read this); thl will announce to Fedora contributors to actually start > to build for EPEL5 -- seems to him a lot of people wait for a "Go" > signal. The packages currently in EPEL5 probably need a rebuild; it was > discussed to simply delete the repo and build the packages again, but > between the meeting and writing the logs this issue was raised again on > the list So, what is it going to be? Delete everything and rebuild or append .1 to the release and make new builds? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 2.15 2.54 2.85 From bjohnson-sender-11eeb1 at symetrix.com Thu Mar 29 18:10:57 2007 From: bjohnson-sender-11eeb1 at symetrix.com (Bernard Johnson) Date: Thu, 29 Mar 2007 12:10:57 -0600 Subject: brp-python-bytecompile in EL4 Message-ID: <460C0131.9070803@symetrix.com> Is there anything that we can do to add the brp-python-bytecompile to EPEL4 buildsys? Out of all the "current" buildsys environments (FE5, FE6, F7 devel, EPEL4, EPEL5), it is the only one that doesn't do the automatic byte compilation. Because of this, I have to either add conditional code specifically to byte-compile for EL4 in my spec (ugly) or branch my spec specifically for EL4 (ugly). Neither of these is ideal. It would be easy to add this brp-* script and the macros to trigger it in the EPEL4 system. This has the side effect of requiring scripts/macros that a base EL4 doesn't have and the package will not build on a base EL4. But I don't see this as a blocker, since we are already adding macros that will break building on a base EL4 system (if used). The way to fix this would be assure that the macros can be made available back to the EL4 system. There is currently a discussion on fedora-devel regarding adding macros back into the base system. Check it out "Opinions: Providing 'buildsys-macros' in the installed system". It cover most of the stuff that I just brought up, just not specifically about brp-python-bytecompile.. From Michael_E_Brown at dell.com Thu Mar 29 20:52:54 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 29 Mar 2007 15:52:54 -0500 Subject: brp-python-bytecompile in EL4 In-Reply-To: <460C0131.9070803@symetrix.com> References: <460C0131.9070803@symetrix.com> Message-ID: <20070329205253.GC10779@humbolt.us.dell.com> On Thu, Mar 29, 2007 at 12:10:57PM -0600, Bernard Johnson wrote: > Is there anything that we can do to add the brp-python-bytecompile to > EPEL4 buildsys? Out of all the "current" buildsys environments (FE5, > FE6, F7 devel, EPEL4, EPEL5), it is the only one that doesn't do the > automatic byte compilation. > > Because of this, I have to either add conditional code specifically to > byte-compile for EL4 in my spec (ugly) or branch my spec specifically > for EL4 (ugly). > > Neither of these is ideal. > > It would be easy to add this brp-* script and the macros to trigger it > in the EPEL4 system. This has the side effect of requiring > scripts/macros that a base EL4 doesn't have and the package will not > build on a base EL4. +1 I maintain a couple python packages and this would be useful. -- Michael From buildsys at fedoraproject.org Fri Mar 30 02:55:20 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 29 Mar 2007 22:55:20 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-03-29 Message-ID: <20070330025520.BD5F3152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 30 NEW TurboGears-1.0.1-2.el5 NEW cmucl-19d-3.el5 firmware-addon-dell-1.2.6-1.el5 NEW libnet-1.1.2.1-10.el5 libsmbios-0.13.5-1.el5 NEW nas-1.8b-1.el5 NEW numpy-1.0.1-2.2.el5 NEW pgfouine-0.7.2-3.el5 NEW phpPgAdmin-4.1.1-1.el5 NEW python-TestGears-0.2-4.el5 NEW python-cherrytemplate-1.0.0-5.el5 NEW python-clientform-0.2.6-1.el5 NEW python-configobj-4.4.0-1.el5 NEW python-formencode-0.7-2.el5 NEW python-irclib-0.4.6-3.el5 NEW python-json-3.4-3.el5 NEW python-mechanize-0.1.6-0.1.b.el5 NEW python-myghty-1.1-3.el5 NEW python-nose-0.9.2-1.el5 NEW python-paste-1.2.1-1.el5 NEW python-paste-deploy-1.1-1.el5 NEW python-paste-script-1.1-1.el5 NEW python-psycopg2-2.0.5.1-3.el5 NEW python-ruledispatch-0.5a0-0.4.svnr2115.el5 NEW python-simplejson-1.5-1.el5 NEW python-sqlobject-0.7.3-1.el5 NEW python-tgfastdata-0.9a6-6.el5 NEW python-turbocheetah-0.9.5-7.el5 NEW python-turbojson-0.9.9-3.el5 NEW python-turbokid-0.9.9-4.el5 Packages built and released for Fedora EPEL 4: 10 jasper-1.900.1-1.el4 NEW libnet-1.1.2.1-7.el4 libsmbios-0.13.5-1.el4 maxima-5.11.0-8.el4 nas-1.8b-1.el4 NEW pgfouine-0.7.2-1.el4 NEW phpPgAdmin-4.1.1-1.el4 NEW python-psycopg2-2.0.5.1-8.el4 NEW queuegraph-1.1-1.el4 sbcl-1.0.4-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/