From jspaleta at gmail.com Sat Jul 1 00:47:04 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 30 Jun 2006 16:47:04 -0800 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <4485B20F.3020103@thecodergeek.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <4471E231.1070409@thecodergeek.com> <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> <4485B20F.3020103@thecodergeek.com> Message-ID: <604aa7910606301747y5d6e4a4dkcc39365c5d3cbbef@mail.gmail.com> On 6/6/06, Peter Gordon wrote: > Done. Good luck with the move, Jeff! :) Good Morning, I'm sortof back online, but I'm not in a state where I can do any sort of Extras work. Any problems with assuming maintainership of glabels? -jef From fedora at leemhuis.info Sat Jul 1 10:10:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 01 Jul 2006 12:10:51 +0200 Subject: FESCo election -- only some hours left, go vote Message-ID: <44A64A2B.2050609@leemhuis.info> Hi! For those that forgot -- the election for the next FESCo still runs and will end soon (soon=tomorrow, July 2nd at 23:59 UTC -- round about 34 hours from now)! So if you are a Fedora Extras contributor go and vote the right people for the next FESCo at https://admin.fedoraproject.org/voting/vote.cgi More details about the election can be found at: https://www.redhat.com/archives/fedora-maintainers/2006-June/msg00104.html CU thl From nicolas.mailhot at laposte.net Sat Jul 1 11:56:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 01 Jul 2006 13:56:30 +0200 Subject: Removing zoo from Fedora Extras Message-ID: <1151754990.9339.86.camel@rousalka.dyndns.org> Hi, I'm going to ask the removal of the zoo archiver suite from Fedora Extras repositories. The existing zoo codebase is potentially insecure, and there is no one to audit it and coordinate fixes. This unfortunate situation haven't changed since the last CERT alerts, and the rushed fixes we used then. As far as I know zoo was never used in Fedora except as a pluggin in mail filters to uncompress zoo attachements and scan them. Needless to say the last thing you want when processing external uncontrolled input is old crufty orphaned unaudited code. If you need zoo for something please ping me and I'll give over maintainership to you. But please remember accepting the maintainership now implies doing the security audit zoo sorely needs, as I don't see how the package could be kept in Fedora repositories otherwise. If no one objects I'll go on with the orphaning and request for repository removal tomorrow evening (CET time) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gdk at redhat.com Sat Jul 1 14:54:36 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Sat, 1 Jul 2006 10:54:36 -0400 (EDT) Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <604aa7910606301747y5d6e4a4dkcc39365c5d3cbbef@mail.gmail.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <4471E231.1070409@thecodergeek.com> <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> <4485B20F.3020103@thecodergeek.com> <604aa7910606301747y5d6e4a4dkcc39365c5d3cbbef@mail.gmail.com> Message-ID: On Fri, 30 Jun 2006, Jeff Spaleta wrote: > On 6/6/06, Peter Gordon wrote: > > Done. Good luck with the move, Jeff! :) > > Good Morning, > > I'm sortof back online, but I'm not in a state where I can do any sort > of Extras work. That state being Alaska, I presume? :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From dennis at ausil.us Sun Jul 2 03:23:46 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 1 Jul 2006 22:23:46 -0500 Subject: Legacy in Build Roots Message-ID: <200607012223.47065.dennis@ausil.us> Hey all, I put in a request and was asked to take it here. What i want is to make sure that FC3 extras packages have legacy updates in the build root. This will also include FC4 legacy updates soon. Why do i want this. 1) while hopefully not likely its possible a legacy update will break a extras package. 2) if something is statically linked and legacy fixes a security issue we need a way to build against the fix. 3) it will ensure that things are nice and clean as it should be the same environment that is in use. Some of you will say i don't care about older releases. as things stand right now. Extras are responsible for extras packages until A release is declared EOL. Right now FE3 is not EOL. If you as a maintainer don't fix security issues in older releases then the security team has to do it. When Legacy takes over core they do not take over extras. does this mean you need to release an update for every branch everytime you have a new version? no. but what you should care about is at the very least security issues. I see this as part of the legacy integration into the rest of Fedora https://www.redhat.com/archives/fedora-advisory-board/2006-June/msg00021.html for a little more info. whats involved? some changes to the mock configs to ensure the legacy updates are there and a rsync of legacy updates from there current location. There is not alot of work involved in making this happen. It should be a positive thing. I personally think it is the right thing to do. Comments, thoughts, suggestions ? -- Dennis Gilmore, RHCE Proud Australian From bugs.michael at gmx.net Sun Jul 2 10:46:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 2 Jul 2006 12:46:44 +0200 Subject: Legacy in Build Roots In-Reply-To: <200607012223.47065.dennis@ausil.us> References: <200607012223.47065.dennis@ausil.us> Message-ID: <20060702124644.12b28a88.bugs.michael@gmx.net> On Sat, 1 Jul 2006 22:23:46 -0500, Dennis Gilmore wrote: > Hey all, > > I put in a request and was asked to take it here. What i want is to make sure > that FC3 extras packages have legacy updates in the build root. This will > also include FC4 legacy updates soon. > > Why do i want this. > 1) while hopefully not likely its possible a legacy update will break a extras > package. > 2) if something is statically linked and legacy fixes a security issue we > need a way to build against the fix. > 3) it will ensure that things are nice and clean as it should be the same > environment that is in use. > > > Some of you will say i don't care about older releases. as things stand right > now. Extras are responsible for extras packages until A release is declared > EOL. Right now FE3 is not EOL. If you as a maintainer don't fix security > issues in older releases then the security team has to do it. When Legacy > takes over core they do not take over extras. does this mean you need to > release an update for every branch everytime you have a new version? no. > but what you should care about is at the very least security issues. The open questions and the reasons why I find it necessary to talk more about it and to see a couple of things carved into stone: Fedora Legacy is a team of volunteers who enlengthen the life of old FC releases. Who will do the same for old FE branches? Recall this: https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html (Don't answer "the Security Team" right now. Read on.) Fedora Legacy has been an optional thing so far. A repository to enable manually. For anyone getting FC+Updates from official Fedora download locations or mirrors, there has not been any Fedora Legacy in there so far, e.g. http://wftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/ Will Fedora Legacy Updates enter the primary download location of Fedora Core Updates, so the transition would be transparent? There are no clear details about whether this will be done: http://fedoraproject.org/wiki/Board/Meetings/2006-06-06 There's only a vague suggestion that legacy updates may be pushed to download.fedora.redhat.com, not that they will go into the existing updates folders. (it would also become necessary to merge bugzilla, btw) Any FE packager, who still wants to support all his FE packages, now must track Legacy and test current and future packages appropriately as legacy upgrades may break things at run-time and/or build-time. Unless Legacy Updates remain in a separate repository and are not merged with FC Updates. In that case, FE packagers would face two targets, however. Conclusively, we would need a policy that Fedora Legacy becomes mandatory for old FE branches, which are in maintenance state. When the FE buildsys enables Legacy packages, it must be mandatory that the packagers track Legacy Updates and test their packages appropriately. With regard to https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html there doesn't seem to be any signs of the security team in the Wiki yet. Who is on the security team and will take over maintenance of old FE branches? I'd like FE packagers to be able to drop their old FE packages and re-assign incoming bug reports to those, who will keep them current with Legacy. Previously, the Fedora Legacy team has not shown any interest in doing or participating in legacy updates for FE. But now that the FE buildsys would include their packages, they would have a direct influence on old FE branches both at build-time and run-time. Unlike before, the Fedora Legacy maintainers need to take extra precautions that they don't break FE because they look only at FC. It is vital that there is a clear announcement about who will take care of any induced breakage in FE (including broken upgrade paths due to inappropriate EVR, and upgrades requiring a chain of upgrades in FE). From ville.skytta at iki.fi Mon Jul 3 18:39:44 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 03 Jul 2006 21:39:44 +0300 Subject: Legacy in Build Roots In-Reply-To: <20060702124644.12b28a88.bugs.michael@gmx.net> References: <200607012223.47065.dennis@ausil.us> <20060702124644.12b28a88.bugs.michael@gmx.net> Message-ID: <1151951984.2728.27.camel@localhost.localdomain> On Sun, 2006-07-02 at 12:46 +0200, Michael Schwendt wrote: > With regard to > https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html > there doesn't seem to be any signs of the security team in the Wiki yet. http://fedoraproject.org/wiki/Security/ResponseTeam (since May, and yes, much more info is needed) > Who is on the security team and will take over maintenance of old FE > branches? I'd like FE packagers to be able to drop their old FE packages > and re-assign incoming bug reports to those, who will keep them current > with Legacy. My .02?: I don't think anyone can really answer that yet, but I've posted to the security list with some suggestions that could help in finding it out. fedora-security-list at redhat.com has a Bugzilla account which can be used to Cc the team on security related issues. (Please don't assign issues to the list just yet.) From chitlesh at fedoraproject.org Mon Jul 3 21:16:03 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 3 Jul 2006 23:16:03 +0200 Subject: whereis my package? Message-ID: <13dbfe4f0607031416j2e4872d8s909d1906cf43980d@mail.gmail.com> Hello there, Im looking for my package kdirstat which was successfully build: 11915 (kdirstat): Build on target fedora-5-extras succeeded. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-5-extras/11915-kdirstat-2.5.3-3.fc5/ -bash-3.1# yum install kdirstat Loading "installonlyn" plugin Setting up Install Process Setting up repositories extras [1/5] extras 100% |=========================| 1.1 kB 00:00 extras-source [2/5] extras-source 100% |=========================| 951 B 00:00 updates [3/5] updates 100% |=========================| 951 B 00:00 core [4/5] core 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 787 kB 00:05 extras : ################################################## 2235/2235 Added 451 new packages, deleted 2277 old in 12.82 seconds primary.xml.gz 100% |=========================| 577 kB 00:04 extras-sou: ################################################## 2410/2410 Added 24 new packages, deleted 12 old in 2.39 seconds Parsing package install arguments No Match for argument: kdirstat Nothing to do Anyone can tell me what happend to it ? -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Mon Jul 3 21:35:12 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 3 Jul 2006 23:35:12 +0200 Subject: whereis my package? In-Reply-To: <13dbfe4f0607031416j2e4872d8s909d1906cf43980d@mail.gmail.com> References: <13dbfe4f0607031416j2e4872d8s909d1906cf43980d@mail.gmail.com> Message-ID: <13dbfe4f0607031435m4a0cdf48kb00aa02fe0705b4b@mail.gmail.com> But I was able to download with the src.rpm of kdirstat chitlesh(~)[1]$yumdownloader --source kdirstat extras [1/5] extras 100% |=========================| 1.1 kB 00:00 extras-source [2/5] extras-source 100% |=========================| 951 B 00:00 updates [3/5] updates 100% |=========================| 951 B 00:00 core [4/5] core 100% |=========================| 1.1 kB 00:00 primary.xml.gz 100% |=========================| 577 kB 00:04 extras-sou: ################################################## 2410/2410 Added 138 new packages, deleted 68 old in 2.47 seconds primary.xml.gz 100% |=========================| 8.0 kB 00:59 primary.xml.gz 100% |=========================| 483 kB 16:03 updates : ################################################## 1422/1422 Added 507 new packages, deleted 226 old in 11.03 seconds primary.xml.gz 100% |=========================| 138 kB 00:00 livna : ################################################## 410/410 Added 41 new packages, deleted 6 old in 0.74 seconds kdirstat-2.5.3-3.fc5.src. 100% |=========================| 666 kB 00:05 -- http://clunixchit.blogspot.com From dennis at ausil.us Mon Jul 3 21:50:10 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 3 Jul 2006 16:50:10 -0500 Subject: whereis my package? In-Reply-To: <13dbfe4f0607031416j2e4872d8s909d1906cf43980d@mail.gmail.com> References: <13dbfe4f0607031416j2e4872d8s909d1906cf43980d@mail.gmail.com> Message-ID: <200607031650.10316.dennis@ausil.us> On Monday 03 July 2006 4:16 pm, Chitlesh GOORAH wrote: > Hello there, Im looking for my package kdirstat which was successfully > build: > > 11915 (kdirstat): Build on target fedora-5-extras succeeded. > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-5-extras/11915-kdirstat-2.5.3 >-3.fc5/ > > > > > Anyone can tell me what happend to it ? its probably waiting for mirrors to sync it will be on some but not all mirrors -- Dennis Gilmore, RHCE Proud Australian From harald at redhat.com Wed Jul 5 10:13:31 2006 From: harald at redhat.com (Harald Hoyer) Date: Wed, 05 Jul 2006 12:13:31 +0200 Subject: some minor Core pruning In-Reply-To: <20060612214812.GA16446@nostromo.devel.redhat.com> References: <20060612214812.GA16446@nostromo.devel.redhat.com> Message-ID: <44AB90CB.6020605@redhat.com> Bill Nottingham wrote: > Running some dependency analysis on Core yielded a few packages > in the following groups. This isn't exhaustive, by any means; there > are still quite a few leaf nodes that are potential Extras candidates. > > libvolume_id Will be needed by our cluster suite!! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3621 bytes Desc: S/MIME Cryptographic Signature URL: From dwmw2 at infradead.org Wed Jul 5 11:43:26 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Jul 2006 12:43:26 +0100 Subject: Packaging guidelines: IPv6 Message-ID: <1152099806.32572.65.camel@pmac.infradead.org> Since we're going through all Fedora packages (well, at least Core for now; I'm sure we'll get to Extras next) and filing bugs for any which lack IPv6 support, should we also update the guidelines on the Wiki to recommend that any package which supports Legacy IP should also be able to use IPv6 and should do so 'out of the box' where appropriate? Would anyone object if I amended the PackageReviewGuidelines to include something along the lines of... SHOULD: If any form of networking over IPv4 networking is supported, the same functionality over IPv6 should also be supported, and should be enabled by default if the IPv4 support is. MUST: If IPv4 networking is supported, but for some reason the 'SHOULD support IPv6' documented elsewhere is not obeyed, a bug must be opened which should block the IPv6 tracker bug, and should contain a full justification for the lack. -- dwmw2 From skvidal at linux.duke.edu Wed Jul 5 12:02:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 08:02:39 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152099806.32572.65.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> Message-ID: <1152100959.3458.20.camel@cutter> On Wed, 2006-07-05 at 12:43 +0100, David Woodhouse wrote: > Since we're going through all Fedora packages (well, at least Core for > now; I'm sure we'll get to Extras next) and filing bugs for any which > lack IPv6 support, should we also update the guidelines on the Wiki to > recommend that any package which supports Legacy IP should also be able > to use IPv6 and should do so 'out of the box' where appropriate? > > Would anyone object if I amended the PackageReviewGuidelines to include > something along the lines of... > > SHOULD: If any form of networking over IPv4 networking is supported, the > same functionality over IPv6 should also be supported, and should be > enabled by default if the IPv4 support is. > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > support IPv6' documented elsewhere is not obeyed, a bug must be opened > which should block the IPv6 tracker bug, and should contain a full > justification for the lack. requiring functionality in software is not part of the requirements for PACKAGING the software. We don't have i18n requirements for extras software, either. so I do not think a must is appropriate. the justification for the lack is not the duty of the packager. For that you should talk to the upstream maintainer. -sv From veillard at redhat.com Wed Jul 5 12:17:55 2006 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 5 Jul 2006 08:17:55 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152099806.32572.65.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> Message-ID: <20060705121754.GD967@redhat.com> On Wed, Jul 05, 2006 at 12:43:26PM +0100, David Woodhouse wrote: > Since we're going through all Fedora packages (well, at least Core for > now; I'm sure we'll get to Extras next) and filing bugs for any which > lack IPv6 support, should we also update the guidelines on the Wiki to > recommend that any package which supports Legacy IP should also be able > to use IPv6 and should do so 'out of the box' where appropriate? > > Would anyone object if I amended the PackageReviewGuidelines to include > something along the lines of... > > SHOULD: If any form of networking over IPv4 networking is supported, the > same functionality over IPv6 should also be supported, and should be > enabled by default if the IPv4 support is. > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > support IPv6' documented elsewhere is not obeyed, a bug must be opened > which should block the IPv6 tracker bug, and should contain a full > justification for the lack. My experience with IPv6: 3 years of portability nightmare since I accepted the patch provided by Sun to 'add IPv6 support' in libxml2. That single contribution led to most of the portability problems on verious unixes, different breakages on different version of AIX, troubles with HP-UX and don't ever start to look at the various Windows targetting toolchains. So my answer to your MUST is: give me configure and code patches which won't break on the various legacy platforms I try to support in my software. My experience with it as libxml2 upstream maintainer has been abysmal, maybe it's due to the quality of the initial patch, but what you try to present as a done deal here, is still a not fully resolved issue upstream. Mandating a fix here, is the equivalent of putting the blame on the people who want to keep their software portable. If only the tone was cooled down that would be easier to accept, but frankly your cruisade is not fun when you are stuck on the other end. You want that feature, send the patches ! Pressuring the packagers or maintainers is just bad behaviour IMHO. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rdieter at math.unl.edu Wed Jul 5 12:40:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Jul 2006 07:40:20 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152100959.3458.20.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> Message-ID: <44ABB334.70309@math.unl.edu> seth vidal wrote: > On Wed, 2006-07-05 at 12:43 +0100, David Woodhouse wrote: >>Would anyone object if I amended the PackageReviewGuidelines to include >>something along the lines of... >> >>SHOULD: If any form of networking over IPv4 networking is supported, the >>same functionality over IPv6 should also be supported, and should be >>enabled by default if the IPv4 support is. >> >>MUST: If IPv4 networking is supported, but for some reason the 'SHOULD >>support IPv6' documented elsewhere is not obeyed, a bug must be opened >>which should block the IPv6 tracker bug, and should contain a full >>justification for the lack. > > > requiring functionality in software is not part of the requirements for > PACKAGING the software. Keep in mind the "MUST" proposal is only to *document* (via bugzilla) IPv6 deficiency. Personally, I consider this a good thing. -- Rex From dwmw2 at infradead.org Wed Jul 5 12:50:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Jul 2006 13:50:25 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152100959.3458.20.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> Message-ID: <1152103825.32572.73.camel@pmac.infradead.org> On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > > SHOULD: If any form of networking over IPv4 networking is supported, the > > same functionality over IPv6 should also be supported, and should be > > enabled by default if the IPv4 support is. > > > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > > support IPv6' documented elsewhere is not obeyed, a bug must be opened > > which should block the IPv6 tracker bug, and should contain a full > > justification for the lack. > > requiring functionality in software is not part of the requirements for > PACKAGING the software. It's a question of code quality. > We don't have i18n requirements for extras software, either. Perhaps we should? I thought we at least required that they join us in the 21st century and operate correctly with UTF-8. Do we have _no_ written guidelines on the quality of the software we accept to be packaged? > so I do not think a must is appropriate. You're aware it was "SHOULD support IPv6", "else MUST explain why not", right? > the justification for the lack is not the duty of the packager. For that > you should talk to the upstream maintainer. Dealing with the upstream maintainer is the responsibility of the Fedora package maintainer. -- dwmw2 From jwboyer at jdub.homelinux.org Wed Jul 5 12:50:39 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 07:50:39 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABB334.70309@math.unl.edu> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> Message-ID: <1152103839.22623.25.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 07:40 -0500, Rex Dieter wrote: > seth vidal wrote: > > On Wed, 2006-07-05 at 12:43 +0100, David Woodhouse wrote: > > >>Would anyone object if I amended the PackageReviewGuidelines to include > >>something along the lines of... > >> > >>SHOULD: If any form of networking over IPv4 networking is supported, the > >>same functionality over IPv6 should also be supported, and should be > >>enabled by default if the IPv4 support is. > >> > >>MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > >>support IPv6' documented elsewhere is not obeyed, a bug must be opened > >>which should block the IPv6 tracker bug, and should contain a full > >>justification for the lack. > > > > > > requiring functionality in software is not part of the requirements for > > PACKAGING the software. > > Keep in mind the "MUST" proposal is only to *document* (via bugzilla) > IPv6 deficiency. Personally, I consider this a good thing. I believe it depends on the definition of "full justification for the lack." As Seth said, particular functionality is not part of the requirements for packaging it, so having to write a long justification as to why IPv6 isn't present seems wrong. If "upstream doesn't support it" is sufficient, then I'd be ok with it. The intention is a bit unclear perhaps. Is it to simply track which packages lack IPv6 support, or is it to force all of them to add support. josh From jwboyer at jdub.homelinux.org Wed Jul 5 12:56:14 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 07:56:14 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152103825.32572.73.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> Message-ID: <1152104174.22623.31.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: > On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > > > SHOULD: If any form of networking over IPv4 networking is supported, the > > > same functionality over IPv6 should also be supported, and should be > > > enabled by default if the IPv4 support is. > > > > > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > > > support IPv6' documented elsewhere is not obeyed, a bug must be opened > > > which should block the IPv6 tracker bug, and should contain a full > > > justification for the lack. > > > > requiring functionality in software is not part of the requirements for > > PACKAGING the software. > > It's a question of code quality. /me puts on a troll hat Support for IPv6 is not a question of quality. It's a feature. It's often a geo-centric issue as well. I live in .us where IPv6 support sucks from the ISPs. I could care less. Luddites unite! /me takes the troll hat off > > the justification for the lack is not the duty of the packager. For that > > you should talk to the upstream maintainer. > > Dealing with the upstream maintainer is the responsibility of the Fedora > package maintainer. Sure. And it's not unreasonable to even open an upstream report if a package lacks IPv6 support. But _requiring_ maintainers to do so is a different story. josh From arjan at fenrus.demon.nl Wed Jul 5 12:57:05 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 05 Jul 2006 14:57:05 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152103825.32572.73.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> Message-ID: <1152104225.3201.27.camel@laptopd505.fenrus.org> On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: > On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > > > SHOULD: If any form of networking over IPv4 networking is supported, the > > > same functionality over IPv6 should also be supported, and should be > > > enabled by default if the IPv4 support is. > > > > > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > > > support IPv6' documented elsewhere is not obeyed, a bug must be opened > > > which should block the IPv6 tracker bug, and should contain a full > > > justification for the lack. > > > > requiring functionality in software is not part of the requirements for > > PACKAGING the software. > > It's a question of code quality. > > > We don't have i18n requirements for extras software, either. > > Perhaps we should? I thought we at least required that they join us in > the 21st century and operate correctly with UTF-8. Do we have _no_ > written guidelines on the quality of the software we accept to be > packaged? I assume basic security quality is at least part of the review process.. or I hope it is... if it is, then that is already about functionality and not packaging.. there would then seem to be a bit of a gray area (which is ok, it's what us humans are good at by making smart decisions rather than by-the-book decisions)... And if there is really no functional requirements in the spec.. maybe there should be a second spec/recommendation for functional things? That could be useful for external projects as well, as a checklist in the "did we forget anything to be useful to a wide audience" kind of way.. From fedora at leemhuis.info Wed Jul 5 13:37:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 15:37:47 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152104225.3201.27.camel@laptopd505.fenrus.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> Message-ID: <44ABC0AB.3050905@leemhuis.info> Arjan van de Ven schrieb: > On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: >> On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > I assume basic security quality is at least part of the review process.. > or I hope it is... No there isn't. In an ideal world there should be one, but there are a lot of others things that aren't done currently that should be done first before we get a step closer to that ideal world. Further: A basic security check would mean that each packager and the reviewer must understand and know the programming language the software he packages is written in. And that's often not the case and would make packaging and reviewing even more complicated (it hard enough already) Heck, it's probably even worse: There are afaik a lot of Extras packagers that simply are no real programmers at all. I for example don't know C or C++, my Java skills are limited, I never found enough time to really dig into python and the only think I understand well is bash -- and that's not a real programming language. It seems to me that a lot of people often forget that. But does that mean that I (and all the other non-programmers) should stop contributing to Extras? >[...] > And if there is really no functional requirements in the spec.. maybe > there should be a second spec/recommendation for functional things? That > could be useful for external projects as well, as a checklist in the > "did we forget anything to be useful to a wide audience" kind of way.. Can't hurt. Cu thl From skvidal at linux.duke.edu Wed Jul 5 13:48:18 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 09:48:18 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABB334.70309@math.unl.edu> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> Message-ID: <1152107298.8883.10.camel@cutter> On Wed, 2006-07-05 at 07:40 -0500, Rex Dieter wrote: > seth vidal wrote: > > On Wed, 2006-07-05 at 12:43 +0100, David Woodhouse wrote: > > >>Would anyone object if I amended the PackageReviewGuidelines to include > >>something along the lines of... > >> > >>SHOULD: If any form of networking over IPv4 networking is supported, the > >>same functionality over IPv6 should also be supported, and should be > >>enabled by default if the IPv4 support is. > >> > >>MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > >>support IPv6' documented elsewhere is not obeyed, a bug must be opened > >>which should block the IPv6 tracker bug, and should contain a full > >>justification for the lack. > > > > > > requiring functionality in software is not part of the requirements for > > PACKAGING the software. > > Keep in mind the "MUST" proposal is only to *document* (via bugzilla) > IPv6 deficiency. Personally, I consider this a good thing. > 1. How the hell should I, as the packager, know this? 2. I don't have access to any ipv6 networks - how and WHY should I test this? 3. why is it my responsibility to document this and clutter up bugzilla? If there is someone with a hard-on about ipv6 then they can do it. I don't need to write up justifications for why there isn't a translation into mandarin chinese for a package, why should I do the same for some other FEATURE? -sv From skvidal at linux.duke.edu Wed Jul 5 13:50:38 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 09:50:38 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152104174.22623.31.camel@weaponx.rchland.ibm.com> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104174.22623.31.camel@weaponx.rchland.ibm.com> Message-ID: <1152107438.8883.12.camel@cutter> On Wed, 2006-07-05 at 07:56 -0500, Josh Boyer wrote: > On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: > > On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > > > > SHOULD: If any form of networking over IPv4 networking is supported, the > > > > same functionality over IPv6 should also be supported, and should be > > > > enabled by default if the IPv4 support is. > > > > > > > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > > > > support IPv6' documented elsewhere is not obeyed, a bug must be opened > > > > which should block the IPv6 tracker bug, and should contain a full > > > > justification for the lack. > > > > > > requiring functionality in software is not part of the requirements for > > > PACKAGING the software. > > > > It's a question of code quality. > > /me puts on a troll hat > > Support for IPv6 is not a question of quality. It's a feature. It's > often a geo-centric issue as well. I live in .us where IPv6 support > sucks from the ISPs. I could care less. Luddites unite! > > /me takes the troll hat off > > > > > the justification for the lack is not the duty of the packager. For that > > > you should talk to the upstream maintainer. > > > > Dealing with the upstream maintainer is the responsibility of the Fedora > > package maintainer. > > Sure. And it's not unreasonable to even open an upstream report if a > package lacks IPv6 support. But _requiring_ maintainers to do so is a > different story. > ding ding ding - winner. I say let the people who care about ipv6 be the guardians of this sort of thing. -sv From skvidal at linux.duke.edu Wed Jul 5 13:52:07 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 09:52:07 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABC0AB.3050905@leemhuis.info> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> Message-ID: <1152107528.8883.15.camel@cutter> On Wed, 2006-07-05 at 15:37 +0200, Thorsten Leemhuis wrote: > Arjan van de Ven schrieb: > > On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: > >> On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > > I assume basic security quality is at least part of the review process.. > > or I hope it is... > > No there isn't. In an ideal world there should be one, but there are a > lot of others things that aren't done currently that should be done > first before we get a step closer to that ideal world. > > Further: A basic security check would mean that each packager and the > reviewer must understand and know the programming language the software > he packages is written in. And that's often not the case and would make > packaging and reviewing even more complicated (it hard enough already) > > Heck, it's probably even worse: There are afaik a lot of Extras > packagers that simply are no real programmers at all. I for example > don't know C or C++, my Java skills are limited, I never found enough > time to really dig into python and the only think I understand well is > bash -- and that's not a real programming language. > > It seems to me that a lot of people often forget that. But does that > mean that I (and all the other non-programmers) should stop contributing > to Extras? > > >[...] > > And if there is really no functional requirements in the spec.. maybe > > there should be a second spec/recommendation for functional things? That > > could be useful for external projects as well, as a checklist in the > > "did we forget anything to be useful to a wide audience" kind of way.. > > Can't hurt. > Who would do this and what would motivate them? If it is just their own interest in the package then by all means, let them, but leave this out of the extras packaging guidelines. it does not bear even a passing resemblance to something useful to further clutter up the packaging guidelines with. -sv From arjan at fenrus.demon.nl Wed Jul 5 13:50:04 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 05 Jul 2006 15:50:04 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABC0AB.3050905@leemhuis.info> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> Message-ID: <1152107404.3201.34.camel@laptopd505.fenrus.org> > Further: A basic security check would mean that each packager and the > reviewer must understand and know the programming language the software > he packages is written in. actually only a reviewer.... well depends on what you want; a general "this looks sane enough" is different from a detailed audit. > It seems to me that a lot of people often forget that. But does that > mean that I (and all the other non-programmers) should stop contributing > to Extras? absolutely not! From jgarzik at redhat.com Wed Jul 5 14:03:27 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Wed, 5 Jul 2006 10:03:27 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152107298.8883.10.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> <1152107298.8883.10.camel@cutter> Message-ID: <20060705140327.GA17038@devserv.devel.redhat.com> On Wed, Jul 05, 2006 at 09:48:18AM -0400, seth vidal wrote: > 2. I don't have access to any ipv6 networks Sure you do. Via 6to4, if not a better tunnel. This presumes you have IPv4 access of course :) Jeff From fedora at leemhuis.info Wed Jul 5 14:11:37 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 16:11:37 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152107528.8883.15.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107528.8883.15.camel@cutter> Message-ID: <44ABC899.8050609@leemhuis.info> seth vidal schrieb: > On Wed, 2006-07-05 at 15:37 +0200, Thorsten Leemhuis wrote: >> Arjan van de Ven schrieb: >>> On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: >>>> On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: [...] >>> And if there is really no functional requirements in the spec.. maybe >>> there should be a second spec/recommendation for functional things? That >>> could be useful for external projects as well, as a checklist in the >>> "did we forget anything to be useful to a wide audience" kind of way.. >> Can't hurt. > Who would do this and what would motivate them? It seemed to me some people were interested in maintaining such a list. E.g. like "A superb extras package should - support UTF8 - IPv6 ..." If some people want that then it okay for me. > If it is just their own > interest in the package then by all means, let them, but leave this out > of the extras packaging guidelines. Of course. > it does not bear even a passing resemblance to something useful to > further clutter up the packaging guidelines with. Exactly. Cu thl From rc040203 at freenet.de Wed Jul 5 14:12:31 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 05 Jul 2006 16:12:31 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152107404.3201.34.camel@laptopd505.fenrus.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> Message-ID: <1152108751.6721.31.camel@mccallum.corsepiu.local> On Wed, 2006-07-05 at 15:50 +0200, Arjan van de Ven wrote: > > Further: A basic security check would mean that each packager and the > > reviewer must understand and know the programming language the software > > he packages is written in. > > actually only a reviewer.... > well depends on what you want; a general "this looks sane enough" is > different from a detailed audit. It's even worse: All FE currently has is an "initial this looks sane enough" review. Once a package is in FE, there actually is no QA nor audit on packages at all. Nobody but the package owner is allowed to change packages. If he doesn't want to listen, nothing will happen, maintainers have all kind of freedom to commit all kind of stupidities they want. > > It seems to me that a lot of people often forget that. But does that > > mean that I (and all the other non-programmers) should stop contributing > > to Extras? > > absolutely not! As I've just said in another posting: We need teams of competent people to deal with dedicated tasks. Security/code auditing would be one example for such task. Ralf From dwmw2 at infradead.org Wed Jul 5 14:19:11 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Jul 2006 15:19:11 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152107298.8883.10.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> <1152107298.8883.10.camel@cutter> Message-ID: <1152109151.32572.93.camel@pmac.infradead.org> On Wed, 2006-07-05 at 09:48 -0400, seth vidal wrote: > 1. How the hell should I, as the packager, know this? If you aren't capable of working it out, you really aren't the kind of person who should be maintaining packages yet, until you've learned more. Thl keeps setting himself forward as an example of a non-programmer packager, but 'even' he is capable of basic stuff like that. > 2. I don't have access to any ipv6 networks - how and WHY should I > test this? Utter crap. Everyone has access to IPv6 networks -- it's trivial, even in the US. > 3. why is it my responsibility to document this Because we expect a certain level of quality from Fedora packages -- or at least I thought we did. I _thought_ we'd decided that Fedora Extras wasn't going to just be a random second-rate dumping ground for crap, but it was going to aspire to follow the same goals and achieve the same quality as Fedora Core. > and clutter up bugzilla? 'clutter up bugzilla'? Yeah, right. Now we're just getting silly, aren't we? -- dwmw2 From jima at beer.tclug.org Wed Jul 5 14:28:09 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 5 Jul 2006 09:28:09 -0500 (CDT) Subject: Packaging guidelines: IPv6 In-Reply-To: <1152108751.6721.31.camel@mccallum.corsepiu.local> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <1152108751.6721.31.camel@mccallum.corsepiu.local> Message-ID: On Wed, 5 Jul 2006, Ralf Corsepius wrote: > It's even worse: All FE currently has is an "initial this looks sane > enough" review. Once a package is in FE, there actually is no QA nor > audit on packages at all. Nobody but the package owner is allowed to > change packages. If he doesn't want to listen, nothing will happen, > maintainers have all kind of freedom to commit all kind of stupidities > they want. Huh? If a packager is committing "all kinds of stupidities" (catchy phrase, I like it) to their packages, someone's bound to notice in the emails to fedora-extras-commits (unless the packager is *really* good at hitting ^C at the right times!). If not, someone might notice bizarre behavior in the package and eyeball the CVS. Once one of the stupidities is discovered, they're free to submit a bug report on the package. If the packager fails to respond appropriately (or at all!) to the bug, I'm fairly certain the next step of escalation would be to contact the person's sponsor (which you should be able to find in the cvsextras group in the Accounts system) with the information you have. That sponsor then can decide what the best path forward would be. See? We have oversight. If you do stupid things, you'll likely get noticed doing so. Another feature of Open Source. Jima From skvidal at linux.duke.edu Wed Jul 5 14:34:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 10:34:36 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152109151.32572.93.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> <1152107298.8883.10.camel@cutter> <1152109151.32572.93.camel@pmac.infradead.org> Message-ID: <1152110076.8883.20.camel@cutter> On Wed, 2006-07-05 at 15:19 +0100, David Woodhouse wrote: > On Wed, 2006-07-05 at 09:48 -0400, seth vidal wrote: > > 1. How the hell should I, as the packager, know this? > > If you aren't capable of working it out, you really aren't the kind of > person who should be maintaining packages yet, until you've learned > more. Thl keeps setting himself forward as an example of a > non-programmer packager, but 'even' he is capable of basic stuff like > that. I disagree - a lot of software has seldom-used network support that I may never encounter just b/c I happen to package it up. > > 2. I don't have access to any ipv6 networks - how and WHY should I > > test this? > > Utter crap. Everyone has access to IPv6 networks -- it's trivial, even > in the US. Well, if I do I don't know how to access it and I'm not overly-inspired to learn about it right now. > > > 3. why is it my responsibility to document this > > Because we expect a certain level of quality from Fedora packages -- or > at least I thought we did. I _thought_ we'd decided that Fedora Extras > wasn't going to just be a random second-rate dumping ground for crap, > but it was going to aspire to follow the same goals and achieve the same > quality as Fedora Core. There are goals and quality in core?? News to me - I thought core was just what could get passed jeremy, notting and sopwith. :) > > and clutter up bugzilla? > > 'clutter up bugzilla'? Yeah, right. Now we're just getting silly, aren't > we? no, we started out silly with your first post. :) -sv From Matt_Domsch at dell.com Wed Jul 5 14:30:47 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 5 Jul 2006 09:30:47 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152099806.32572.65.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> Message-ID: <20060705143047.GB5063@lists.us.dell.com> On Wed, Jul 05, 2006 at 12:43:26PM +0100, David Woodhouse wrote: > Since we're going through all Fedora packages (well, at least Core for > now; I'm sure we'll get to Extras next) and filing bugs for any which > lack IPv6 support, should we also update the guidelines on the Wiki to > recommend that any package which supports Legacy IP should also be able > to use IPv6 and should do so 'out of the box' where appropriate? > > Would anyone object if I amended the PackageReviewGuidelines to include > something along the lines of... > > SHOULD: If any form of networking over IPv4 networking is supported, the > same functionality over IPv6 should also be supported, and should be > enabled by default if the IPv4 support is. Clearly dependant on upstream. However, suggesting that packagers use "configure --enable-ipv6" where appropriate makes sense (e.g. xchat). As for IPv6 usage, there's at least 3 things you can do today. 1) install radvd on your local router and advertise no routes, just a local prefix. Then your internal connections can start using ipv6. 2) enable 6to4. Kind of sucks in the US, as there are so few 6to4 servers in the US. 3) use a tunnel service like sixxs.net provides (and aiccu is now in Extras). Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From paul at city-fan.org Wed Jul 5 14:43:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 05 Jul 2006 15:43:07 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <1152108751.6721.31.camel@mccallum.corsepiu.local> Message-ID: <44ABCFFB.5060709@city-fan.org> Jima wrote: > On Wed, 5 Jul 2006, Ralf Corsepius wrote: >> It's even worse: All FE currently has is an "initial this looks sane >> enough" review. Once a package is in FE, there actually is no QA nor >> audit on packages at all. Nobody but the package owner is allowed to >> change packages. If he doesn't want to listen, nothing will happen, >> maintainers have all kind of freedom to commit all kind of stupidities >> they want. > > Huh? If a packager is committing "all kinds of stupidities" (catchy > phrase, I like it) to their packages, someone's bound to notice in the > emails to fedora-extras-commits (unless the packager is *really* good at > hitting ^C at the right times!). Ralf is one of the very few people that actually seem to read fedora-extras-commits. I read the commits of the people that I sponsor but that's about it. If more people read the commits list (which would take quite a lot of time every day) it might work as a QA mechanism but at the moment it's not a big help. > If not, someone might notice bizarre > behavior in the package and eyeball the CVS. Once one of the > stupidities is discovered, they're free to submit a bug report on the > package. That could be a bit on the late side depending on the severity of the stupidity. The trick really is to get the right balance of QA and flexibility to get things done. I don't know what the solution for that is though. Paul. From dwmw2 at infradead.org Wed Jul 5 14:48:52 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Jul 2006 15:48:52 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABC0AB.3050905@leemhuis.info> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> Message-ID: <1152110932.2987.10.camel@pmac.infradead.org> On Wed, 2006-07-05 at 15:37 +0200, Thorsten Leemhuis wrote: > No there isn't. In an ideal world there should be one, but there are a > lot of others things that aren't done currently that should be done > first before we get a step closer to that ideal world. > > Further: A basic security check would mean that each packager and the > reviewer must understand and know the programming language the software > he packages is written in. And that's often not the case and would make > packaging and reviewing even more complicated (it hard enough already) I think that a basic understanding of the code which you're patching and shipping _should_ be considered a requirement in the general case, yes. I've said it before, and because I'm right I'll say it again: Fedora needs _maintainers_, not just package-monkeys. > Heck, it's probably even worse: There are afaik a lot of Extras > packagers that simply are no real programmers at all. I for example > don't know C or C++, my Java skills are limited, I never found enough > time to really dig into python and the only think I understand well is > bash -- and that's not a real programming language. > > It seems to me that a lot of people often forget that. But does that > mean that I (and all the other non-programmers) should stop contributing > to Extras? You, Thorsten, are a special case -- you're downplaying your own capabilities. I know perfectly well that you pay attention to detail and you're entirely capable of seeking out assistance when you need it. And I don't suggest that even in general such people should "stop contributing to Extras"; just that they should not be sponsored as package _maintainers_ -- at least for packages containing code they don't understand. -- dwmw2 From rc040203 at freenet.de Wed Jul 5 14:51:55 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 05 Jul 2006 16:51:55 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <1152108751.6721.31.camel@mccallum.corsepiu.local> Message-ID: <1152111115.6721.47.camel@mccallum.corsepiu.local> On Wed, 2006-07-05 at 09:28 -0500, Jima wrote: > On Wed, 5 Jul 2006, Ralf Corsepius wrote: > > It's even worse: All FE currently has is an "initial this looks sane > > enough" review. Once a package is in FE, there actually is no QA nor > > audit on packages at all. Nobody but the package owner is allowed to > > change packages. If he doesn't want to listen, nothing will happen, > > maintainers have all kind of freedom to commit all kind of stupidities > > they want. > > Huh? If a packager is committing "all kinds of stupidities" (catchy > phrase, I like it) to their packages, someone's bound to notice in the > emails to fedora-extras-commits (unless the packager is *really* good at > hitting ^C at the right times!). How many people are reading fedora-commits? I guess very few ... I read it "batch style" every now and then and occasionally comment on some (from my POV) eye-striking "oddities" ... In many cases, packagers prefer to ignore such comments and to remain silent. > If not, someone might notice bizarre > behavior in the package and eyeball the CVS. Well, in many cases the "bizarre behavior" is noticed by the public, when such a bug hits the "common man". Classical examples having hit fairly frequently would be * "SONAME changes" * broken NEVRs. * Shipping immature/premature beta/alpha stable SW. With a little carefulness at least the former 2 cases would be avoidable, and with a little team spirit, they in many cases would often be easy to fix. So far this apparently isn't the case. Instead we are watching mails concerning "broken deps", and every now and then are facing the consequences of SONAME changes (rebuild requests) or shipping immature SW. Ralf From jima at beer.tclug.org Wed Jul 5 15:16:00 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 5 Jul 2006 10:16:00 -0500 (CDT) Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABCFFB.5060709@city-fan.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <1152108751.6721.31.camel@mccallum.corsepiu.local> <44ABCFFB.5060709@city-fan.org> Message-ID: On Wed, 5 Jul 2006, Paul Howarth wrote: >> If not, someone might notice bizarre >> behavior in the package and eyeball the CVS. Once one of the stupidities >> is discovered, they're free to submit a bug report on the package. > > That could be a bit on the late side depending on the severity of the > stupidity. > > The trick really is to get the right balance of QA and flexibility to get > things done. I don't know what the solution for that is though. I'm not sure there's a failsafe solution short of fully-moderated CVS commits. If someone has a better solution, I welcome them to speak up. If not, I suspect this may be a moot point. Jima From mattdm at mattdm.org Wed Jul 5 15:24:45 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 11:24:45 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152108751.6721.31.camel@mccallum.corsepiu.local> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <1152108751.6721.31.camel@mccallum.corsepiu.local> Message-ID: <20060705152445.GA2787@jadzia.bu.edu> On Wed, Jul 05, 2006 at 04:12:31PM +0200, Ralf Corsepius wrote: > It's even worse: All FE currently has is an "initial this looks sane > enough" review. Once a package is in FE, there actually is no QA nor > audit on packages at all. Nobody but the package owner is allowed to > change packages. If he doesn't want to listen, nothing will happen, > maintainers have all kind of freedom to commit all kind of stupidities > they want. While I understand your point and agree with what you're advocating for, maybe this could be rephrased in a way that's less antagonistic to the maintainers? And also, it's worth noting that at least from an outsider's point of view, this appears to be largely the case with Core as well.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From cweyl at alumni.drew.edu Wed Jul 5 16:49:37 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 5 Jul 2006 09:49:37 -0700 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152100959.3458.20.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> Message-ID: <7dd7ab490607050949y685c9ca1ib7f68b4d3519135e@mail.gmail.com> On 7/5/06, seth vidal wrote: > requiring functionality in software is not part of the requirements for > PACKAGING the software. > [...] > > the justification for the lack is not the duty of the packager. For that > you should talk to the upstream maintainer. +1. While maintainers are sometimes packagers, packagers are not maintainers. -Chris -- Chris Weyl Ex astris, scientia From skvidal at linux.duke.edu Wed Jul 5 17:12:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 13:12:29 -0400 Subject: FESCo Election Results In-Reply-To: <44ABCDFF.8030609@fedoraproject.org> References: <44ABCDFF.8030609@fedoraproject.org> Message-ID: <1152119550.8883.42.camel@cutter> On Wed, 2006-07-05 at 09:34 -0500, Mike McGrath wrote: > Below are the election results for the recent FESCo Election. I'd > encourage another person to verify these results. The cutoff line was 13. > > Votes | Human_name | Fedora_account_id > > 61 Tom Callaway 100061 > 60 Jeremy Katz 100036 > 57 Thorsten Leemhuis 100066 > 56 Ville Skytta 100055 > 53 Rex Dieter 100082 > 50 Michael Schwendt 100044 > 49 Jason Tibbitts 100158 > 44 Warren Togami 100073 > 41 Seth Vidal 100059 > 38 Toshio Ernie Kuratomi 100068 > 33 Joshua W. Boyer 100115 > 32 Dennis Gilmore 100103 > 31 Andreas Bierfert 100011 > --------------------------------------- > 30 Christian Iseli 100114 > 28 Brian Pepple 100012 > 25 Michael J Knox 100390 > 25 Kevin Fenzi 100037 > 17 Jose Pedro Oliveira 100033 > > Hi Everyone, I was 'elected' in some sense or another however as I promised I am willing to step down if someone else among those nominated but not elected wish to take my place. As Christian received the most votes below the line I'm offering to step down and for him to take my place. Everyone cool w/that? -sv From jwboyer at jdub.homelinux.org Wed Jul 5 17:24:56 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 12:24:56 -0500 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <1152120296.22623.42.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 13:12 -0400, seth vidal wrote: > > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? Fine with me. josh From ville.skytta at iki.fi Wed Jul 5 17:26:02 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Jul 2006 20:26:02 +0300 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152111115.6721.47.camel@mccallum.corsepiu.local> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <1152108751.6721.31.camel@mccallum.corsepiu.local> <1152111115.6721.47.camel@mccallum.corsepiu.local> Message-ID: <1152120362.2728.119.camel@localhost.localdomain> On Wed, 2006-07-05 at 16:51 +0200, Ralf Corsepius wrote: > How many people are reading fedora-commits? I guess very few ... > > I read it "batch style" every now and then and occasionally comment on > some (from my POV) eye-striking "oddities" ... Ditto. > In many cases, packagers > prefer to ignore such comments and to remain silent. Fortunately, I've met only a few cases like that, and a subsequent Bugzilla report has fixed it sooner or later IIRC in all cases. Dunno if it makes any difference, but I tend to whine in personal mail first on issues that look like one-off thinkos. From mattdm at mattdm.org Wed Jul 5 17:34:13 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 13:34:13 -0400 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <20060705173413.GA8086@jadzia.bu.edu> On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > Everyone cool w/that? Yes. That's exactly what I presumed the "contingent" comment on the nominations page meant. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ville.skytta at iki.fi Wed Jul 5 17:37:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Jul 2006 20:37:57 +0300 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ABB334.70309@math.unl.edu> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> Message-ID: <1152121077.2728.129.camel@localhost.localdomain> On Wed, 2006-07-05 at 07:40 -0500, Rex Dieter wrote: > Keep in mind the "MUST" proposal is only to *document* (via bugzilla) > IPv6 deficiency. Personally, I consider this a good thing. Me too, but mileages vary. These things do put some additional burden on packagers and reviewers, but I think the situation is similar as with let's say x86_64 not too long ago; there were similar objections and concerns but I think eventually things worked out pretty well. From skvidal at linux.duke.edu Wed Jul 5 17:44:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 13:44:19 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152121077.2728.129.camel@localhost.localdomain> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> <1152121077.2728.129.camel@localhost.localdomain> Message-ID: <1152121460.8883.48.camel@cutter> On Wed, 2006-07-05 at 20:37 +0300, Ville Skytt? wrote: > On Wed, 2006-07-05 at 07:40 -0500, Rex Dieter wrote: > > > Keep in mind the "MUST" proposal is only to *document* (via bugzilla) > > IPv6 deficiency. Personally, I consider this a good thing. > > Me too, but mileages vary. These things do put some additional burden > on packagers and reviewers, but I think the situation is similar as with > let's say x86_64 not too long ago; there were similar objections and > concerns but I think eventually things worked out pretty well. except the onus of explaining what was broken was not on the packager. -sv From fedora at leemhuis.info Wed Jul 5 17:50:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 19:50:28 +0200 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <20060705173413.GA8086@jadzia.bu.edu> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> Message-ID: <44ABFBE4.1010303@leemhuis.info> Matthew Miller schrieb: > On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: >> I was 'elected' in some sense or another however as I promised I am >> willing to step down if someone else among those nominated but not >> elected wish to take my place. As Christian received the most votes >> below the line I'm offering to step down and for him to take my place. >> Everyone cool w/that? > Yes. That's exactly what I presumed the "contingent" comment on the > nominations page meant. Just my 2 cent: Yes, that's what the "contingent" comment means in general. But from my point of view those three are still free to join FESCo -- e.g. if one of them says "Hey, I got so many votes, it seems people really want me to do the job" then I think they should do the job if they want to. CU thl From bugs.michael at gmx.net Wed Jul 5 17:59:04 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 5 Jul 2006 19:59:04 +0200 Subject: Leaving - Re: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <20060705195904.eddbfd03.bugs.michael@gmx.net> On Wed, 05 Jul 2006 13:12:29 -0400, seth vidal wrote: > On Wed, 2006-07-05 at 09:34 -0500, Mike McGrath wrote: > > Below are the election results for the recent FESCo Election. I'd > > encourage another person to verify these results. The cutoff line was 13. > > > > Votes | Human_name | Fedora_account_id > > > > 61 Tom Callaway 100061 > > 60 Jeremy Katz 100036 > > 57 Thorsten Leemhuis 100066 > > 56 Ville Skytta 100055 > > 53 Rex Dieter 100082 > > 50 Michael Schwendt 100044 > > 49 Jason Tibbitts 100158 > > 44 Warren Togami 100073 > > 41 Seth Vidal 100059 > > 38 Toshio Ernie Kuratomi 100068 > > 33 Joshua W. Boyer 100115 > > 32 Dennis Gilmore 100103 > > 31 Andreas Bierfert 100011 > > --------------------------------------- > > 30 Christian Iseli 100114 > > 28 Brian Pepple 100012 > > 25 Michael J Knox 100390 > > 25 Kevin Fenzi 100037 > > 17 Jose Pedro Oliveira 100033 > > > > > > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? > > -sv > > Same here. I already acknowledged it in private mail, but was asked to announce it publicly. Brian Pepple, who has the second highest number of votes of the people below the line, may take my place. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed Jul 5 18:01:23 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 13:01:23 -0500 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <44ABFBE4.1010303@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> <44ABFBE4.1010303@leemhuis.info> Message-ID: <1152122483.22623.47.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 19:50 +0200, Thorsten Leemhuis wrote: > > Matthew Miller schrieb: > > On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: > >> I was 'elected' in some sense or another however as I promised I am > >> willing to step down if someone else among those nominated but not > >> elected wish to take my place. As Christian received the most votes > >> below the line I'm offering to step down and for him to take my place. > >> Everyone cool w/that? > > Yes. That's exactly what I presumed the "contingent" comment on the > > nominations page meant. > > Just my 2 cent: Yes, that's what the "contingent" comment means in > general. But from my point of view those three are still free to join > FESCo -- e.g. if one of them says "Hey, I got so many votes, it seems > people really want me to do the job" then I think they should do the job > if they want to. Right. Seth has already said Christian is welcome to his seat. It's up to Michael (S) and Ville to decide if they want to vacate their seats to Brian and Michael (K). josh From michael at knox.net.nz Wed Jul 5 18:12:34 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 06:12:34 +1200 Subject: FESCo Election Results In-Reply-To: <44ABCDFF.8030609@fedoraproject.org> References: <44ABCDFF.8030609@fedoraproject.org> Message-ID: <44AC0112.2060101@knox.net.nz> Well Done lads! Michael Mike McGrath wrote: > Below are the election results for the recent FESCo Election. I'd > encourage another person to verify these results. The cutoff line was 13. > Votes | Human_name | Fedora_account_id > > 61 Tom Callaway 100061 > 60 Jeremy Katz 100036 > 57 Thorsten Leemhuis 100066 > 56 Ville Skytta 100055 > 53 Rex Dieter 100082 > 50 Michael Schwendt 100044 > 49 Jason Tibbitts 100158 > 44 Warren Togami 100073 > 41 Seth Vidal 100059 > 38 Toshio Ernie Kuratomi 100068 > 33 Joshua W. Boyer 100115 > 32 Dennis Gilmore 100103 > 31 Andreas Bierfert 100011 > --------------------------------------- > 30 Christian Iseli 100114 > 28 Brian Pepple 100012 > 25 Michael J Knox 100390 > 25 Kevin Fenzi 100037 > 17 Jose Pedro Oliveira 100033 > > > Total Votes: 730 > Total Ballots: 69 > > > -Mike > From toshio at tiki-lounge.com Wed Jul 5 18:14:24 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 05 Jul 2006 11:14:24 -0700 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <1152123264.24961.63.camel@localhost> On Wed, 2006-07-05 at 13:12 -0400, seth vidal wrote: > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? Yes and no. We really should have discussed this case a bit more before the elections but it slipped my mind and apparently everyone else's as well. You can't have an election if there's no one to vote for. You can't have a good election if there's no one to vote against. Without having sufficiently more candidates on the ballot than open seats to fill, there's really no choice being given to the voters. In this particular election we had 18 candidates and 13 seats. If the three who made their candidacy contingent step down, then this election really only decided the outcome for two seats rather than making a difference for five seats and five platforms (over a third of FESCo as opposed to less than a sixth.) Additionally, each of the three candidates who made their candidacy contingent fell within the top half of vote getters. This tells me that there is pretty strong support to having these people sit on FESCo and make decisions. If all three of the candidates who conditionalized their candidacy step down, then I think we're doing the people who made an effort to vote a disservice as they made a conscious choice to elect them to this position. On the other hand, the candidates themselves know how much time they have and what contributions they're making to Fedora outside of FESCo so if they feel they cannot do the job at present they are best qualified to make that decision. I would encourage them to think hard on the decision first, though, and not feel that they must step down because they initially made their candidacy contingent on the number of candidates to step forward. -Toshio P.S. If any of the candidates do feel honor bound to let someone further down the chain in but feel they have the time to continue doing the job I fell below the top 50% of the vote and would be happy to give my spot to *any* one of them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Wed Jul 5 18:27:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Jul 2006 21:27:53 +0300 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <44ABFBE4.1010303@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> <44ABFBE4.1010303@leemhuis.info> Message-ID: <1152124073.2728.149.camel@localhost.localdomain> On Wed, 2006-07-05 at 19:50 +0200, Thorsten Leemhuis wrote: > Matthew Miller schrieb: > On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: > >> I was 'elected' in some sense or another however as I promised I am > >> willing to step down if someone else among those nominated but not > >> elected wish to take my place. As Christian received the most votes > >> below the line I'm offering to step down and for him to take my place. > >> Everyone cool w/that? > > Yes. That's exactly what I presumed the "contingent" comment on the > > nominations page meant. > > Just my 2 cent: Yes, that's what the "contingent" comment means in > general. Not being a native English speaker nor familiar with that word before the initial discussions about the election, my understanding of it is based on http://www.m-w.com/dictionary/contingent which seems to me to leave more things open than the interpretation above... > But from my point of view those three are still free to join > FESCo -- e.g. if one of them says "Hey, I got so many votes, it seems > people really want me to do the job" then I think they should do the job > if they want to. ...and after some consideration, that would be me. Because it looks like I can find enough time to make myself useful, dropping out now would not seem fair towards the voters, so I'll stick around for this round. Thanks and sorry ;) From skvidal at linux.duke.edu Wed Jul 5 18:34:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 14:34:15 -0400 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <1152124073.2728.149.camel@localhost.localdomain> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> <44ABFBE4.1010303@leemhuis.info> <1152124073.2728.149.camel@localhost.localdomain> Message-ID: <1152124455.8883.53.camel@cutter> On Wed, 2006-07-05 at 21:27 +0300, Ville Skytt? wrote: > ...and after some consideration, that would be me. Because it looks > like I can find enough time to make myself useful, dropping out now > would not seem fair towards the voters, so I'll stick around for this > round. Thanks and sorry ;) Or given how highly you ranked in the list we should call them: Your adoring fans. :-D -sv From skvidal at linux.duke.edu Wed Jul 5 20:13:32 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:13:32 -0400 Subject: ambiguity in the guidelines Message-ID: <1152130412.8883.57.camel@cutter> Hey, I'd love to hear more comments on this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 I've read the guidelines and I don't see where it mandates the format of the changelog lines. thanks, -sv From j.w.r.degoede at hhs.nl Wed Jul 5 20:19:00 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 05 Jul 2006 22:19:00 +0200 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <44AC1EB4.3000209@hhs.nl> seth vidal wrote: > Hey, > I'd love to hear more comments on this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. > The guidelines indeed don't mandate this. However everybody does it. I've not apprioved reviews because of the rpmlint warning not doing this causes. More importantly, without adding the version its really hard to find out what exactly changed with which release. So even if you can pin a problem down to showing up after a certain release, you still do not know what has caused the problem. I believe the guidelines must be fixed to make adding the version to the changelog a must! Then the only ambiguity left is that some people put " - " between the email and the version and others only " ". Now i think that both are ok as long as they are used consistent within a package. Regards, Hans From notting at redhat.com Wed Jul 5 20:15:24 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Jul 2006 16:15:24 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <20060705201524.GA25405@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > Hey, > I'd love to hear more comments on this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. Obviously, changelogs should be removed from the spec file and generated auotmatically from CVS commits and inserted into the package at tag time. :P Bill From michael at knox.net.nz Wed Jul 5 20:17:39 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 08:17:39 +1200 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <44AC1E63.2040104@knox.net.nz> seth vidal wrote: > Hey, > I'd love to hear more comments on this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. > It should be simple to resolve... Does the FE package guidelines out weigh rpmlint output or does rpmlint out weigh the FE guidelines? If rpmlint is of higher priority, then the chnagelog needs fixing, if the FE packaging is higher, then its fine as is... Michael From jwboyer at jdub.homelinux.org Wed Jul 5 20:17:43 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 15:17:43 -0500 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <1152130663.22623.52.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 16:13 -0400, seth vidal wrote: > Hey, > I'd love to hear more comments on this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. I think it's a waste of time to bicker back and forth over a few stupid numbers. I'd suggest bringing the debate on whether or not the changelog has to adhere to a specific format to FESCo. They can decide whether to be overly anal-retentive or not. josh From skvidal at linux.duke.edu Wed Jul 5 20:30:14 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:30:14 -0400 Subject: ambiguity in the guidelines In-Reply-To: <44AC1EB4.3000209@hhs.nl> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> Message-ID: <1152131414.8883.60.camel@cutter> On Wed, 2006-07-05 at 22:19 +0200, Hans de Goede wrote: > > seth vidal wrote: > > Hey, > > I'd love to hear more comments on this > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > > > > I've read the guidelines and I don't see where it mandates the format of > > the changelog lines. > > > > The guidelines indeed don't mandate this. However everybody does it. > I've not apprioved reviews because of the rpmlint warning not doing this > causes. > > More importantly, without adding the version its really hard to find out > what exactly changed with which release. So even if you can pin a > problem down to showing up after a certain release, you still do not > know what has caused the problem. > > I believe the guidelines must be fixed to make adding the version to the > changelog a must! Then the only ambiguity left is that some people put > " - " between the email and the version and others only " ". Now i think > that both are ok as long as they are used consistent within a package. > I think it should not be a must - it overloads a field. the tag name in the rpm header is: changelogname notice it doesn't say 'changelogname and other arbitrary crap' it says changelogname. if we want version-specific info stored per-changelog entry then we need a new tag. -sv From skvidal at linux.duke.edu Wed Jul 5 20:30:59 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:30:59 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152130663.22623.52.camel@weaponx.rchland.ibm.com> References: <1152130412.8883.57.camel@cutter> <1152130663.22623.52.camel@weaponx.rchland.ibm.com> Message-ID: <1152131459.8883.62.camel@cutter> On Wed, 2006-07-05 at 15:17 -0500, Josh Boyer wrote: > On Wed, 2006-07-05 at 16:13 -0400, seth vidal wrote: > > Hey, > > I'd love to hear more comments on this > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > > > > I've read the guidelines and I don't see where it mandates the format of > > the changelog lines. > > I think it's a waste of time to bicker back and forth over a few stupid > numbers. > it's not over a few stupid numbers - it is over the ABUSE of a tag. plus I think bickering is fun :) but I'm fine with fesco making the decision. -sv From notting at redhat.com Wed Jul 5 20:41:42 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Jul 2006 16:41:42 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152131414.8883.60.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> <1152131414.8883.60.camel@cutter> Message-ID: <20060705204142.GA25651@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > notice it doesn't say 'changelogname and other arbitrary crap' > > it says changelogname. > > if we want version-specific info stored per-changelog entry then we need > a new tag. ... and it should be taken out of the spec so it can't be gotten wrong, so it could easily be tied to the NVRE (with the build system assigning the R!), and all sorts of other bluesky stuff. :) Bill From mattdm at mattdm.org Wed Jul 5 20:44:27 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 16:44:27 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <20060705204427.GA16093@jadzia.bu.edu> On Wed, Jul 05, 2006 at 04:13:32PM -0400, seth vidal wrote: > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. If it's worth anything at all, as a sysadmin, I find having (e:)v-r information in the changelog to be incredibly useful. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Wed Jul 5 20:49:34 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:49:34 -0400 Subject: ambiguity in the guidelines In-Reply-To: <20060705204142.GA25651@nostromo.devel.redhat.com> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> <1152131414.8883.60.camel@cutter> <20060705204142.GA25651@nostromo.devel.redhat.com> Message-ID: <1152132574.8883.70.camel@cutter> On Wed, 2006-07-05 at 16:41 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > notice it doesn't say 'changelogname and other arbitrary crap' > > > > it says changelogname. > > > > if we want version-specific info stored per-changelog entry then we need > > a new tag. > > ... and it should be taken out of the spec so it can't be gotten wrong, so > it could easily be tied to the NVRE (with the build system assigning the R!), > and all sorts of other bluesky stuff. :) Sounds like a winner - but in the short run my solution of letting it be up to the discretion of the packager works. :) -sv From skvidal at linux.duke.edu Wed Jul 5 20:50:09 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:50:09 -0400 Subject: ambiguity in the guidelines In-Reply-To: <20060705204427.GA16093@jadzia.bu.edu> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> Message-ID: <1152132609.8883.72.camel@cutter> On Wed, 2006-07-05 at 16:44 -0400, Matthew Miller wrote: > On Wed, Jul 05, 2006 at 04:13:32PM -0400, seth vidal wrote: > > I've read the guidelines and I don't see where it mandates the format of > > the changelog lines. > > If it's worth anything at all, as a sysadmin, I find having (e:)v-r > information in the changelog to be incredibly useful. why? the date tells me more b/c at least that has _something_ to do with the versions, etc. -sv From pertusus at free.fr Wed Jul 5 20:45:22 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Jul 2006 22:45:22 +0200 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <20060705204522.GF5078@free.fr> On Wed, Jul 05, 2006 at 04:13:32PM -0400, seth vidal wrote: > Hey, > > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. Except when there is a technical reason to ignore rpmlint warnings they are blockers when reviewing packages. At least that's what happens for all the reviews I'm aware of and I believe it is sane not to leave it to the packager. -- Pat From skvidal at linux.duke.edu Wed Jul 5 20:52:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:52:54 -0400 Subject: ambiguity in the guidelines In-Reply-To: <20060705204522.GF5078@free.fr> References: <1152130412.8883.57.camel@cutter> <20060705204522.GF5078@free.fr> Message-ID: <1152132774.8883.74.camel@cutter> On Wed, 2006-07-05 at 22:45 +0200, Patrice Dumas wrote: > On Wed, Jul 05, 2006 at 04:13:32PM -0400, seth vidal wrote: > > Hey, > > > > I've read the guidelines and I don't see where it mandates the format of > > the changelog lines. > > Except when there is a technical reason to ignore rpmlint warnings they > are blockers when reviewing packages. At least that's what happens for > all the reviews I'm aware of and I believe it is sane not to leave it to > the packager. > I believe it is sane to not overload tags. -sv From Christian.Iseli at licr.org Wed Jul 5 21:40:52 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 23:40:52 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: Your message of "Wed, 05 Jul 2006 13:44:19 EDT." <1152121460.8883.48.camel@cutter> Message-ID: <200607052140.k65LerJE001224@mx3.redhat.com> skvidal at linux.duke.edu said: > On Wed, 2006-07-05 at 20:37 +0300, Ville Skytt? wrote: > > On Wed, 2006-07-05 at 07:40 -0500, Rex Dieter wrote: > > > > > Keep in mind the "MUST" proposal is only to *document* (via bugzilla) > > > IPv6 deficiency. Personally, I consider this a good thing. > > > > Me too, but mileages vary. These things do put some additional burden > > on packagers and reviewers, but I think the situation is similar as with > > let's say x86_64 not too long ago; there were similar objections and > > concerns but I think eventually things worked out pretty well. > > except the onus of explaining what was broken was not on the packager. AFAIK, FE's mantra is still "upstream" So if some software doesn't support IPv6, I fail to see why it should become a burden to the packager. Just file a bug report upstream. Of course, if upstream does provide IPv6 support then I agree the FE package should have that feature enabled. Now if dwmw2 wants to force all Core packages to support IPv6, that's fine with me. But I don't think mandating it for FE packages is right, nor implying that FE is a dumping ground simply because it doesn't mandate enough features. We want working, maintained, secure packages, but we don't necessarily want creeping featuritism... Christian From nicolas.mailhot at laposte.net Wed Jul 5 22:02:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Jul 2006 00:02:31 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <200607052140.k65LerJE001224@mx3.redhat.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> Message-ID: <1152136951.5277.28.camel@rousalka.dyndns.org> Le mercredi 05 juillet 2006 ? 23:40 +0200, Christian.Iseli at licr.org a ?crit : > AFAIK, FE's mantra is still "upstream" > > So if some software doesn't support IPv6, I fail to see why it should become > a burden to the packager. Just file a bug report upstream. ... > Now if dwmw2 wants to force all Core packages to support IPv6, that's fine > with me. dwmw2 needs IPv6 for OLPC > But I don't think mandating it for FE packages is right, nor > implying that FE is a dumping ground simply because it doesn't mandate enough > features. There's so much material to package and so little time. You don't do FE packagers any favour by accepting everything they propose blindly. Sometimes providing a checklist of strongly recommended technical features will help them choose between competing apps. And they don't discover after months of gruelling packaging work they bet on the wrong horse - no one's interested in foo app because bar does the same (and is IPv6/UTF-8/x86-64/GTK-2 whatever compatible) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Wed Jul 5 22:15:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Jul 2006 00:15:08 +0200 Subject: ambiguity in the guidelines In-Reply-To: <1152132609.8883.72.camel@cutter> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> <1152132609.8883.72.camel@cutter> Message-ID: <1152137708.5277.36.camel@rousalka.dyndns.org> Le mercredi 05 juillet 2006 ? 16:50 -0400, seth vidal a ?crit : > On Wed, 2006-07-05 at 16:44 -0400, Matthew Miller wrote: > > On Wed, Jul 05, 2006 at 04:13:32PM -0400, seth vidal wrote: > > > I've read the guidelines and I don't see where it mandates the format of > > > the changelog lines. > > > > If it's worth anything at all, as a sysadmin, I find having (e:)v-r > > information in the changelog to be incredibly useful. > > why? the date tells me more b/c at least that has _something_ to do with > the versions, etc. When you compare two systems, the date is worthless and the (e:)v-r pure gold. (e:)v-r will tell you when devel and update packages where synced for example. Date will tell you "these two package where produced at about the same time". It won't tell you if one was based on a three-years-old fork and the other on current upstream snapshot. (and sure you can find the info with a little archeology but that's not the point. When I see two changelogs with the same (e:)v-r and different comments I know the packages have diverged. When I see two changelogs with the same date and different comments - are the packages diverging or the maintainer holding up an patch for one branch till it's ready?) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Wed Jul 5 22:24:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 06 Jul 2006 01:24:33 +0300 Subject: ambiguity in the guidelines In-Reply-To: <44AC1E63.2040104@knox.net.nz> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> Message-ID: <1152138273.2728.260.camel@localhost.localdomain> On Thu, 2006-07-06 at 08:17 +1200, Michael J. Knox wrote: > Does the FE package guidelines out weigh rpmlint output or does rpmlint > out weigh the FE guidelines? > > If rpmlint is of higher priority, then the chnagelog needs fixing, if > the FE packaging is higher, then its fine as is... I happened to reply to a related message in private mail a few minutes ago, so I'll take the chance to copy/paste relevant bits of that reply. By the way, shouldn't packaging issues be discussed on the fedora-packaging list instead of here? --- Changes to the guidelines go through the packaging committee, and I'll continue to try to make rpmlint behave as well as possible within their scope as well as sensibly outside of it when there are no explicit rules. I think warning from rpmlint, not an error is the right thing to do at the moment. FWIW, my opinion is that including EVR information in changelog entries should be at least a SHOULD (and I wouldn't mind a MUST). FWIW #2, and FYI in case you're interested, there's also an upstream RFE about recognizing and "allowing" different ways of specifying the EVR in changelog entries: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/23 I'm not a big fan of that suggestion, but if the alternative is that people are inclined to omit the EVR altogether, then I'm all for it. From ville.skytta at iki.fi Wed Jul 5 22:41:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 06 Jul 2006 01:41:46 +0300 Subject: ambiguity in the guidelines In-Reply-To: <1152131414.8883.60.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> <1152131414.8883.60.camel@cutter> Message-ID: <1152139306.2728.277.camel@localhost.localdomain> On Wed, 2006-07-05 at 16:30 -0400, seth vidal wrote: > the tag name in the rpm header is: > > changelogname > > notice it doesn't say 'changelogname and other arbitrary crap' But "name" of a changelog entry is ambiguous. createrepo takes the position of calling it the author of the changelog entry, which was surprising to me in our discussion a couple of years ago, and you seemed to understand that point of view: https://lists.dulug.duke.edu/pipermail/rpm-metadata/2004-July/000397.html https://lists.dulug.duke.edu/pipermail/rpm-metadata/2004-July/000398.html https://lists.dulug.duke.edu/pipermail/rpm-metadata/2004-July/000399.html Has something changed since, like the purpose of changelogname documented to have a certain official meaning? changelogname->changelogauthor could be called overloading or narrowing too... ;) From michael at knox.net.nz Wed Jul 5 22:45:53 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 10:45:53 +1200 Subject: ambiguity in the guidelines In-Reply-To: <1152138273.2728.260.camel@localhost.localdomain> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> Message-ID: <44AC4121.6050508@knox.net.nz> Ville Skytt? wrote: > Changes to the guidelines go through the packaging committee, and I'll > continue to try to make rpmlint behave as well as possible within their > scope as well as sensibly outside of it when there are no explicit > rules. I think warning from rpmlint, not an error is the right thing to > do at the moment. Perhaps the "defacto" policy should be that if two or more guidelines/tools/people/etc disagree that the current FE packaging guidelines be considered correct. Should the other guidelines/tools/people/etc feel strongly enough to do so, they should be put forward for consideration. Having this could easily avoid situations like this and allow for a more fluid growth and change in the packing guidelines rather than a heavy handed approach that seems to have been used. Just my 20cents (cuz the NZ dollar is pretty week ;P ) > FWIW, my opinion is that including EVR information in changelog entries > should be at least a SHOULD (and I wouldn't mind a MUST). > > FWIW #2, and FYI in case you're interested, there's also an upstream RFE > about recognizing and "allowing" different ways of specifying the EVR in > changelog entries: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/23 > I'm not a big fan of that suggestion, but if the alternative is that > people are inclined to omit the EVR altogether, then I'm all for it. I have always used EVR and will continue to do so until is not allowed (which I doubt would happen). It should be a SHOULD and not a MUST unless there is an overwhelming technical and logical reason to be so. Thanks Michael From chris.stone at gmail.com Wed Jul 5 23:26:40 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 16:26:40 -0700 Subject: ambiguity in the guidelines In-Reply-To: <44AC4121.6050508@knox.net.nz> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> Message-ID: The way I see it is that Fedora packages and Fedora packagers should strive to have the best spec files possible. If providing a version number in the changelog makes it easier for users of the package in any way then it should be added to spec files. I don't see this as an overloading of a tag issue, I see this as a packager being lazy issue. Just my wooden nickle. From chris.stone at gmail.com Wed Jul 5 23:29:57 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 16:29:57 -0700 Subject: ambiguity in the guidelines In-Reply-To: <44AC1EB4.3000209@hhs.nl> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> Message-ID: On 7/5/06, Hans de Goede wrote: > I believe the guidelines must be fixed to make adding the version to the > changelog a must! Then the only ambiguity left is that some people put > " - " between the email and the version and others only " ". Now i think > that both are ok as long as they are used consistent within a package. +1 and it should be a " " as a seperate because all other fields are seperates as spaces. :) From jwboyer at jdub.homelinux.org Thu Jul 6 00:41:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 19:41:30 -0500 Subject: ambiguity in the guidelines In-Reply-To: <1152138273.2728.260.camel@localhost.localdomain> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> Message-ID: <1152146490.3164.2.camel@vader.jdub.homelinux.org> On Thu, 2006-07-06 at 01:24 +0300, Ville Skytt? wrote: > By the way, shouldn't packaging issues be discussed on the > fedora-packaging list instead of here? This is an issue with the guidelines themselves. Personally, I think fedora-maintainers is better than the packaging list. That's just my $0.02 cents, but I believe the audience on this list is a bit wider and that is a good thing when discussing possible changes to the guidelines that effect _everyone_. josh From mattdm at mattdm.org Thu Jul 6 00:49:15 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 20:49:15 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152132609.8883.72.camel@cutter> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> <1152132609.8883.72.camel@cutter> Message-ID: <20060706004915.GA23776@jadzia.bu.edu> On Wed, Jul 05, 2006 at 04:50:09PM -0400, seth vidal wrote: > > If it's worth anything at all, as a sysadmin, I find having (e:)v-r > > information in the changelog to be incredibly useful. > why? the date tells me more b/c at least that has _something_ to do with > the versions, etc. I often have to look for "in what version of the package was bug X or problem Y addressed?" Knowing it was fixed in May 2005 is *kinda* helpful, but knowing that it was fixed in a certain version is usually exactly what I need to know. I agree that it's less than elegant to put this data in the packager name field, but given that anything else would require patching RPM, backporting that patch to every distro, and changing every package, I'm okay with it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Thu Jul 6 01:38:09 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 21:38:09 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> Message-ID: <1152149890.12287.0.camel@cutter> On Wed, 2006-07-05 at 16:26 -0700, Christopher Stone wrote: > The way I see it is that Fedora packages and Fedora packagers should > strive to have the best spec files possible. > > If providing a version number in the changelog makes it easier for > users of the package in any way then it should be added to spec files. > > I don't see this as an overloading of a tag issue, I see this as a > packager being lazy issue. Just my wooden nickle. It's an overloaded tag b/c the tag did not originally have that intent. it's an added bullshit item that clutters up the data. -sv From skvidal at linux.duke.edu Thu Jul 6 01:39:34 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 21:39:34 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152139306.2728.277.camel@localhost.localdomain> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> <1152131414.8883.60.camel@cutter> <1152139306.2728.277.camel@localhost.localdomain> Message-ID: <1152149975.12287.2.camel@cutter> On Thu, 2006-07-06 at 01:41 +0300, Ville Skytt? wrote: > On Wed, 2006-07-05 at 16:30 -0400, seth vidal wrote: > > > the tag name in the rpm header is: > > > > changelogname > > > > notice it doesn't say 'changelogname and other arbitrary crap' > > But "name" of a changelog entry is ambiguous. createrepo takes the > position of calling it the author of the changelog entry, which was > surprising to me in our discussion a couple of years ago, and you seemed > to understand that point of view: > > https://lists.dulug.duke.edu/pipermail/rpm-metadata/2004-July/000397.html > https://lists.dulug.duke.edu/pipermail/rpm-metadata/2004-July/000398.html > https://lists.dulug.duke.edu/pipermail/rpm-metadata/2004-July/000399.html > > Has something changed since, like the purpose of changelogname > documented to have a certain official meaning? > changelogname->changelogauthor could be called overloading or narrowing > too... ;) > I understand it - and what's changed is my interest in the guessing game of what will or will not be in that field. name == author to me and evr should be in a different tag. -sv From skvidal at linux.duke.edu Thu Jul 6 01:40:59 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 21:40:59 -0400 Subject: ambiguity in the guidelines In-Reply-To: <20060706004915.GA23776@jadzia.bu.edu> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> <1152132609.8883.72.camel@cutter> <20060706004915.GA23776@jadzia.bu.edu> Message-ID: <1152150059.12287.4.camel@cutter> On Wed, 2006-07-05 at 20:49 -0400, Matthew Miller wrote: > On Wed, Jul 05, 2006 at 04:50:09PM -0400, seth vidal wrote: > > > If it's worth anything at all, as a sysadmin, I find having (e:)v-r > > > information in the changelog to be incredibly useful. > > why? the date tells me more b/c at least that has _something_ to do with > > the versions, etc. > > I often have to look for "in what version of the package was bug X or > problem Y addressed?" Knowing it was fixed in May 2005 is *kinda* helpful, > but knowing that it was fixed in a certain version is usually exactly what I > need to know. > > I agree that it's less than elegant to put this data in the packager name > field, but given that anything else would require patching RPM, backporting > that patch to every distro, and changing every package, I'm okay with it. No - we need to fix rpm in fedora and that's all that matters we're more or less maintaining a fork of rpm in fedora anyway - let's just DO IT and be done. it's not like upstream rpm has any meaning anymore, anyway. -sv From chris.stone at gmail.com Thu Jul 6 01:58:37 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 18:58:37 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152149890.12287.0.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> Message-ID: On 7/5/06, seth vidal wrote: > On Wed, 2006-07-05 at 16:26 -0700, Christopher Stone wrote: > > The way I see it is that Fedora packages and Fedora packagers should > > strive to have the best spec files possible. > > > > If providing a version number in the changelog makes it easier for > > users of the package in any way then it should be added to spec files. > > > > I don't see this as an overloading of a tag issue, I see this as a > > packager being lazy issue. Just my wooden nickle. > > It's an overloaded tag b/c the tag did not originally have that intent. > > it's an added bullshit item that clutters up the data. It's not bullshit. I have myself used rpm -q --changelog to find out which changes were made for a particular version. It should not be required, because you should be able to add entries to the change log without a release, such as changes only made in cvs. But when you do an actual release you should match the date with the release number to make it easier for users to associate dates with releases. Yes you can argue that rpm should do this automatically somehow, but where is this rpm patch that you have been working on? I think it is not unreasonable to ask packagers to place version numbers on changelog entries that are associated with a release. This provides a common courtesy to those using the rpm. We understand your point that it is redundant information, but I think the better solution is to provide a source patch to fix rpm, or file a bug against rpm and place the extra information in the changelog in the meantime. From skvidal at linux.duke.edu Thu Jul 6 02:07:11 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 22:07:11 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> Message-ID: <1152151631.12287.19.camel@cutter> On Wed, 2006-07-05 at 18:58 -0700, Christopher Stone wrote: > We understand your point that it is redundant information, but I think > the better solution is to provide a source patch to fix rpm, or file a > bug against rpm and place the extra information in the changelog in > the meantime. I never said it was redundant info. I said it was in the wrong place, in an overloaded field. -sv From chris.stone at gmail.com Thu Jul 6 02:09:34 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 19:09:34 -0700 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> Message-ID: On 7/5/06, Christopher Stone wrote: > On 7/5/06, seth vidal wrote: > > On Wed, 2006-07-05 at 16:26 -0700, Christopher Stone wrote: > > > The way I see it is that Fedora packages and Fedora packagers should > > > strive to have the best spec files possible. > > > > > > If providing a version number in the changelog makes it easier for > > > users of the package in any way then it should be added to spec files. > > > > > > I don't see this as an overloading of a tag issue, I see this as a > > > packager being lazy issue. Just my wooden nickle. > > > > It's an overloaded tag b/c the tag did not originally have that intent. > > > > it's an added bullshit item that clutters up the data. > > It's not bullshit. I have myself used rpm -q --changelog to find out > which changes were made for a particular version. > > It should not be required, because you should be able to add entries > to the change log without a release, such as changes only made in cvs. > But when you do an actual release you should match the date with the > release number to make it easier for users to associate dates with > releases. > > Yes you can argue that rpm should do this automatically somehow, but > where is this rpm patch that you have been working on? I think it is > not unreasonable to ask packagers to place version numbers on > changelog entries that are associated with a release. This provides a > common courtesy to those using the rpm. > > We understand your point that it is redundant information, but I think > the better solution is to provide a source patch to fix rpm, or file a > bug against rpm and place the extra information in the changelog in > the meantime. > BTW if you decide to patch rpm (somehow) it would have to be tied into the official build system so that rpm actually knows that it is doing a release for this particular changelog entry. Or else we would have to require that every changelog entry be associated with a release which I don't think is a good idea. Basically my point is that it is courtesy to add this historical information in the spec file. It is a lot easier for a user to find the information he needs. If you have some type of egregious hack in your spec file do you add a comment explaining the hack or do you leave out all comments in your spec files because they are not required information? A comment is afterall redundant information as anyone should be able to reverse engineer your hack to determine why it is there. From chris.stone at gmail.com Thu Jul 6 02:21:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 19:21:45 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152151631.12287.19.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> Message-ID: On 7/5/06, seth vidal wrote: > On Wed, 2006-07-05 at 18:58 -0700, Christopher Stone wrote: > > > We understand your point that it is redundant information, but I think > > the better solution is to provide a source patch to fix rpm, or file a > > bug against rpm and place the extra information in the changelog in > > the meantime. > > I never said it was redundant info. I said it was in the wrong place, in > an overloaded field. So are you suggesting that the changelog section be broken up into different fields? If it is just a field name you are concerned about you could break the changelog line into seperate fields and call each field by a different name. Do you agree that historical release information is useful to have available from an rpm query command? From mattdm at mattdm.org Thu Jul 6 02:25:53 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 22:25:53 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152150059.12287.4.camel@cutter> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> <1152132609.8883.72.camel@cutter> <20060706004915.GA23776@jadzia.bu.edu> <1152150059.12287.4.camel@cutter> Message-ID: <20060706022553.GA26892@jadzia.bu.edu> On Wed, Jul 05, 2006 at 09:40:59PM -0400, seth vidal wrote: > No - we need to fix rpm in fedora and that's all that matters we're more > or less maintaining a fork of rpm in fedora anyway - let's just DO IT > and be done. By different dists I really meant different versions of Fedora. Or are we going to need different specfiles for otherwise identical packages in Extras just over this? But, uh, if we ARE going that route, can we add a place to put bugzilla references too? :) > it's not like upstream rpm has any meaning anymore, anyway. Did it ever? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 6 02:26:58 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 22:26:58 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> Message-ID: <20060706022658.GB26892@jadzia.bu.edu> On Wed, Jul 05, 2006 at 06:58:37PM -0700, Christopher Stone wrote: > It should not be required, because you should be able to add entries > to the change log without a release, such as changes only made in cvs. Bump the release number. There's plenty of integers. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Thu Jul 6 04:51:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 00:51:19 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> Message-ID: <1152161479.12287.28.camel@cutter> On Wed, 2006-07-05 at 19:21 -0700, Christopher Stone wrote: > On 7/5/06, seth vidal wrote: > > On Wed, 2006-07-05 at 18:58 -0700, Christopher Stone wrote: > > > > > We understand your point that it is redundant information, but I think > > > the better solution is to provide a source patch to fix rpm, or file a > > > bug against rpm and place the extra information in the changelog in > > > the meantime. > > > > I never said it was redundant info. I said it was in the wrong place, in > > an overloaded field. > > So are you suggesting that the changelog section be broken up into > different fields? If it is just a field name you are concerned about > you could break the changelog line into seperate fields and call each > field by a different name. > > Do you agree that historical release information is useful to have > available from an rpm query command? sure - but it's in the wrong place - put it in the text field of the changelog if you MUST have it. ie: * Wed Jun 1 2005 Seth Vidal - 3.4-1%{?dist}.0 - made life miserable for users * Tue May 31 2005 Seth Vidal - 3.4-1%{?dist}.0 - intentionally made others suffer. etc, etc, etc. that way we've left the changelogname field alone and you still have your precious version data in each entry. Ideally I'd prefer if it were: * Tue May 31 2005 Seth Vidal ** Version: 3.4-1%{?dist}.0 - comment here - comment there or some such thing. -sv From dlutter at redhat.com Thu Jul 6 04:59:52 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 05 Jul 2006 21:59:52 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152149890.12287.0.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> Message-ID: <1152161992.28380.39.camel@localhost.localdomain> On Wed, 2006-07-05 at 21:38 -0400, seth vidal wrote: > On Wed, 2006-07-05 at 16:26 -0700, Christopher Stone wrote: > > The way I see it is that Fedora packages and Fedora packagers should > > strive to have the best spec files possible. > > > > If providing a version number in the changelog makes it easier for > > users of the package in any way then it should be added to spec files. > > > > I don't see this as an overloading of a tag issue, I see this as a > > packager being lazy issue. Just my wooden nickle. > > It's an overloaded tag b/c the tag did not originally have that intent. > > it's an added bullshit item that clutters up the data. Is this based on any actual problems for tools ? Is yum having trouble b/c of people sticking version numbers into the changelogname ? Or is the main concern the added amount of typing such a guideline would cause and/or the overloading of this field ? David From n0dalus+redhat at gmail.com Thu Jul 6 05:11:30 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 6 Jul 2006 14:41:30 +0930 Subject: ambiguity in the guidelines In-Reply-To: <1152149890.12287.0.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> Message-ID: <6280325c0607052211j2f7293d3w45dc3ab32bdfd300@mail.gmail.com> On 7/6/06, seth vidal wrote: > > it's an added bullshit item that clutters up the data. > Seth, I don't really think this language is entirely appropriate coming from someone in your position (or even appropriate for this mailing list or bugzilla). As you are a member of the Fedora Project Board and FESCo, what you say affects the reputation and image of Fedora, so I think you should be more careful. Perhaps this language is not offensive to you, but I think a large number of people (me included) are/would be offended by this. n0dalus. From skvidal at linux.duke.edu Thu Jul 6 05:41:28 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 01:41:28 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152161992.28380.39.camel@localhost.localdomain> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152161992.28380.39.camel@localhost.localdomain> Message-ID: <1152164488.12287.30.camel@cutter> On Wed, 2006-07-05 at 21:59 -0700, David Lutterkort wrote: > Is this based on any actual problems for tools ? Is yum having trouble > b/c of people sticking version numbers into the changelogname ? Or is > the main concern the added amount of typing such a guideline would cause > and/or the overloading of this field ? no, yum doesn't care about it - the problem is the same issue as always - it is a mistake to count on string parsing to separate out this string. If we want it in the changelog data then put it in there but not in that field. -sv From skvidal at linux.duke.edu Thu Jul 6 05:46:43 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 01:46:43 -0400 Subject: ambiguity in the guidelines In-Reply-To: <6280325c0607052211j2f7293d3w45dc3ab32bdfd300@mail.gmail.com> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <6280325c0607052211j2f7293d3w45dc3ab32bdfd300@mail.gmail.com> Message-ID: <1152164803.12287.36.camel@cutter> On Thu, 2006-07-06 at 14:41 +0930, n0dalus wrote: > On 7/6/06, seth vidal wrote: > > > > it's an added bullshit item that clutters up the data. > > > > Seth, I don't really think this language is entirely appropriate > coming from someone in your position (or even appropriate for this > mailing list or bugzilla). As you are a member of the Fedora Project > Board and FESCo, what you say affects the reputation and image of > Fedora, so I think you should be more careful. Perhaps this language > is not offensive to you, but I think a large number of people (me > included) are/would be offended by this. > I'm offended by puritanical values. But I can't ask people to give those up and feel righteously indignant about it. Wait, I guess I can - but they probably won't do it. I'm not afraid of ANY words except for those that censor my speech b/c of someone else's values or religion. thanks, -sv From chris.stone at gmail.com Thu Jul 6 05:50:06 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 22:50:06 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152161479.12287.28.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> Message-ID: On 7/5/06, seth vidal wrote: > On Wed, 2006-07-05 at 19:21 -0700, Christopher Stone wrote: > > On 7/5/06, seth vidal wrote: > > > On Wed, 2006-07-05 at 18:58 -0700, Christopher Stone wrote: > > > > > > > We understand your point that it is redundant information, but I think > > > > the better solution is to provide a source patch to fix rpm, or file a > > > > bug against rpm and place the extra information in the changelog in > > > > the meantime. > > > > > > I never said it was redundant info. I said it was in the wrong place, in > > > an overloaded field. > > > > So are you suggesting that the changelog section be broken up into > > different fields? If it is just a field name you are concerned about > > you could break the changelog line into seperate fields and call each > > field by a different name. > > > > Do you agree that historical release information is useful to have > > available from an rpm query command? > > sure - but it's in the wrong place - put it in the text field of the > changelog if you MUST have it. > > ie: > > * Wed Jun 1 2005 Seth Vidal > - 3.4-1%{?dist}.0 > - made life miserable for users > > * Tue May 31 2005 Seth Vidal > - 3.4-1%{?dist}.0 > - intentionally made others suffer. > > > etc, etc, etc. > > > that way we've left the changelogname field alone and you still have > your precious version data in each entry. > > Ideally I'd prefer if it were: > * Tue May 31 2005 Seth Vidal > ** Version: 3.4-1%{?dist}.0 > - comment here > - comment there > > or some such thing. Actually I was thinking more along the lines of just splitting the line by parsing it as "Date spec \b name \b version spec" using some perl regular expression and then sending the pieces to the appropriate variable names. (Not that this is even technically needed for anything right now, but atleast you won't feel this name is "overloaded"). It seems to me from this argument that it really is basically a laziness issue. Trying to claim it will "intentionally make others suffer". Why not try to make your spec file as useful as possible? I have seen packagers refuse to add %{?dist} tags to their spec file because its not "a bug". Well so what? If it makes it a better spec file why not add it? Do these packagers refuse to do these things because of ego or laziness or some other reason? If anyone here finds any way to improve upon my packages I am more than happy to oblige. I want my spec files to be the best they can be and I don't mind spending a little extra effort to achieve that goal. From n0dalus+redhat at gmail.com Thu Jul 6 06:02:32 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 6 Jul 2006 15:32:32 +0930 Subject: ambiguity in the guidelines In-Reply-To: <1152164803.12287.36.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <6280325c0607052211j2f7293d3w45dc3ab32bdfd300@mail.gmail.com> <1152164803.12287.36.camel@cutter> Message-ID: <6280325c0607052302m40287314l12f50b73238f9920@mail.gmail.com> On 7/6/06, seth vidal wrote: > > I'm not afraid of ANY words except for those that censor my speech b/c > of someone else's values or religion. > This isn't about censorship. It's about respecting other people. You are free as always to say whatever you want, but that doesn't mean you should. n0dalus. From skvidal at linux.duke.edu Thu Jul 6 06:28:08 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 02:28:08 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> Message-ID: <1152167288.12287.41.camel@cutter> On Wed, 2006-07-05 at 22:50 -0700, Christopher Stone wrote: > It seems to me from this argument that it really is basically a > laziness issue. Trying to claim it will "intentionally make others > suffer". > If you had 2 fields: First Name and Last Name and someone told you to add the address into "Last Name" b/c other people do it - would you think that an appropriate use of the field? > Why not try to make your spec file as useful as possible? I have seen > packagers refuse to add %{?dist} tags to their spec file because its > not "a bug". Well so what? If it makes it a better spec file why not > add it? Do these packagers refuse to do these things because of ego > or laziness or some other reason? > > If anyone here finds any way to improve upon my packages I am more > than happy to oblige. I want my spec files to be the best they can be > and I don't mind spending a little extra effort to achieve that goal. I am trying to make my spec file useful - by not abusing fields. -sv From chris.stone at gmail.com Thu Jul 6 06:28:38 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 23:28:38 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152167288.12287.41.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> <1152167288.12287.41.camel@cutter> Message-ID: On 7/5/06, seth vidal wrote: > On Wed, 2006-07-05 at 22:50 -0700, Christopher Stone wrote: > > > It seems to me from this argument that it really is basically a > > laziness issue. Trying to claim it will "intentionally make others > > suffer". > > > > > If you had 2 fields: > First Name > and > Last Name > > and someone told you to add the address into "Last Name" b/c other > people do it - would you think that an appropriate use of the field? I see this more as: If you had 2 fields: General subject line Change description Would I divide "General subject line" into multiple fields even though there was no technical necissity to do so at the moment, but would provide for cleaner code to allow for features to possibly be more easily added in the future? hmm tough one, as I really like clean code, but I think I would leave it as is for now since splitting the General subject line field using a perl expression seems feasible and easy to do should the need arise in the future. From skvidal at linux.duke.edu Thu Jul 6 06:37:31 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 02:37:31 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> <1152167288.12287.41.camel@cutter> Message-ID: <1152167851.12287.44.camel@cutter> On Wed, 2006-07-05 at 23:28 -0700, Christopher Stone wrote: > I see this more as: > > If you had 2 fields: > General subject line > Change description > > Would I divide "General subject line" into multiple fields even though > there was no technical necissity to do so at the moment, but would > provide for cleaner code to allow for features to possibly be more > easily added in the future? > > hmm tough one, as I really like clean code, but I think I would leave > it as is for now since splitting the General subject line field using > a perl expression seems feasible and easy to do should the need arise > in the future. Do you seriously think relying on regexes for parsing out data is safe and reliable for human-inputted strings w/o confirmation? -sv From chris.stone at gmail.com Thu Jul 6 06:43:35 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 23:43:35 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152167851.12287.44.camel@cutter> References: <1152130412.8883.57.camel@cutter> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> <1152167288.12287.41.camel@cutter> <1152167851.12287.44.camel@cutter> Message-ID: On 7/5/06, seth vidal wrote: > Do you seriously think relying on regexes for parsing out data is safe > and reliable for human-inputted strings w/o confirmation? About as safe as anything rpmlint detects now. But the discussion is moot because there is no reason to actually parse the string right now. If you had some killer feature that required parsing of the change log entries then it would be worth discussing. From skvidal at linux.duke.edu Thu Jul 6 06:58:13 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 02:58:13 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <1152149890.12287.0.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> <1152167288.12287.41.camel@cutter> <1152167851.12287.44.camel@cutter> Message-ID: <1152169093.12287.49.camel@cutter> On Wed, 2006-07-05 at 23:43 -0700, Christopher Stone wrote: > On 7/5/06, seth vidal wrote: > > Do you seriously think relying on regexes for parsing out data is safe > > and reliable for human-inputted strings w/o confirmation? > > About as safe as anything rpmlint detects now. But the discussion is > moot because there is no reason to actually parse the string right > now. If you had some killer feature that required parsing of the > change log entries then it would be worth discussing. so correctness is not a feature in and of itself? sheesh. Let's be clear about what's going on here: 1. I do not think it is an appropriate to overload the field 2. I do not wish to take part in that particular dirtiness 3. until today no one has questioned the desire for correctness on my part 4. I'm not asking anyone else to do what I'm doing - I'm just trying to do what I think is most correct and appropriate given the technology available. that's it! -sv From chris.stone at gmail.com Thu Jul 6 07:13:06 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 00:13:06 -0700 Subject: ambiguity in the guidelines In-Reply-To: <1152169093.12287.49.camel@cutter> References: <1152130412.8883.57.camel@cutter> <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> <1152167288.12287.41.camel@cutter> <1152167851.12287.44.camel@cutter> <1152169093.12287.49.camel@cutter> Message-ID: On 7/5/06, seth vidal wrote: > Let's be clear about what's going on here: > 1. I do not think it is an appropriate to overload the field > 2. I do not wish to take part in that particular dirtiness > 3. until today no one has questioned the desire for correctness on my > part > 4. I'm not asking anyone else to do what I'm doing - I'm just trying to > do what I think is most correct and appropriate given the technology > available. Okay, but you have not explained _why_ adding version information to this field is "overloading" it. How does this affect anything? You have not given any reason to not include version information other than the name of the field which if I recall from this thread is called "changelogname". So why is this important to not include version information in this field? Why is it important that this field only contain date, packager name and email? Is there some technical reason why this field should only contain this particular data? What if we called the field "changeloginfo" rather than "changelogname" or whatever it is called now? Would this change things in your mind? From andreas.bierfert at lowlatency.de Thu Jul 6 10:39:49 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 6 Jul 2006 12:39:49 +0200 Subject: ambiguity in the guidelines In-Reply-To: <1152149975.12287.2.camel@cutter> References: <1152130412.8883.57.camel@cutter> <44AC1EB4.3000209@hhs.nl> <1152131414.8883.60.camel@cutter> <1152139306.2728.277.camel@localhost.localdomain> <1152149975.12287.2.camel@cutter> Message-ID: <20060706123949.74b1e350@arcturus.a.lan> On Wed, 05 Jul 2006 21:39:34 -0400 seth vidal wrote: > name == author to me and evr should be in a different tag. +1 - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred From dwmw2 at infradead.org Thu Jul 6 12:28:09 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Jul 2006 13:28:09 +0100 Subject: ambiguity in the guidelines In-Reply-To: <20060705204427.GA16093@jadzia.bu.edu> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> Message-ID: <1152188889.2987.121.camel@pmac.infradead.org> On Wed, 2006-07-05 at 16:44 -0400, Matthew Miller wrote: > On Wed, Jul 05, 2006 at 04:13:32PM -0400, seth vidal wrote: > > I've read the guidelines and I don't see where it mandates the format of > > the changelog lines. > > If it's worth anything at all, as a sysadmin, I find having (e:)v-r > information in the changelog to be incredibly useful. I agree. It's _extremely_ useful to have the version information in the changelog. If it isn't in the guidelines, it _should_ be. I don't care if we change things internally to get around the whining pedantic objections, or if we continue to do it the way that almost everyone has always done it anyway, but we _should_ include version numbers in changelogs. -- dwmw2 From dwmw2 at infradead.org Thu Jul 6 12:45:26 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Jul 2006 13:45:26 +0100 Subject: ambiguity in the guidelines In-Reply-To: <6280325c0607052302m40287314l12f50b73238f9920@mail.gmail.com> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <6280325c0607052211j2f7293d3w45dc3ab32bdfd300@mail.gmail.com> <1152164803.12287.36.camel@cutter> <6280325c0607052302m40287314l12f50b73238f9920@mail.gmail.com> Message-ID: <1152189926.2987.131.camel@pmac.infradead.org> On Thu, 2006-07-06 at 15:32 +0930, n0dalus wrote: > This isn't about censorship. It's about respecting other people. You > are free as always to say whatever you want, but that doesn't mean you > should. While I happen to think Seth is full of shit on this occasion, I'll defend his right to state his position in any way he sees fit. I was brought up in a predominantly Christian country, and the first book of the Bible makes it entirely clear that to be ashamed of nakedness and natural bodily functions is a sign of sin. I therefore believe that if you find something offensive about the word 'shit', then you are going to burn in hell. More seriously, I believe you're misguided when you bring 'respect' into it too. If I respect you, then I will speak freely in front of you, and I will not assume that you have a moronic puritanical attitude to language. If I don't respect you, or don't trust you to be a normal, well-adjusted human being, then I may be _far_ more guarded about what I say in your presence. Do not mistake that reticence for respect. -- dwmw2 From fedora at camperquake.de Thu Jul 6 12:47:25 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 6 Jul 2006 14:47:25 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152107404.3201.34.camel@laptopd505.fenrus.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> Message-ID: <20060706144725.25b503d6@voip.int.addix.net> Hi. On Wed, 05 Jul 2006 15:50:04 +0200, Arjan van de Ven wrote: > actually only a reviewer.... > well depends on what you want; a general "this looks sane enough" is > different from a detailed audit. Not a lot of people are able to do a detailed security audit. I know I could not, although I am not unfamiliar with C and know some of the more or less obvious quirks that are likely to occur. What is even worse, if we really held an audit across FE, I am afraid that not may packages would remain alive. There is some spectacular stuff out there. From pertusus at free.fr Thu Jul 6 12:47:03 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 6 Jul 2006 14:47:03 +0200 Subject: ambiguity in the guidelines In-Reply-To: <1152188889.2987.121.camel@pmac.infradead.org> References: <1152130412.8883.57.camel@cutter> <20060705204427.GA16093@jadzia.bu.edu> <1152188889.2987.121.camel@pmac.infradead.org> Message-ID: <20060706124703.GA10552@free.fr> > I agree. It's _extremely_ useful to have the version information in the > changelog. If it isn't in the guidelines, it _should_ be. In my opinion the issue is not whether the version should be in the changelog or not, but maybe how it should be in the changelog. Should we enforce that the version has to be on the author/date line, or could it be acceptable to have it in the changelog comments? In any case I think everybody agree or don't disagree that having the version somewhere in the changelog is a good thing and it should be in the guidelines. -- Pat From jkeating at redhat.com Thu Jul 6 12:51:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 08:51:43 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152130412.8883.57.camel@cutter> References: <1152130412.8883.57.camel@cutter> Message-ID: <200607060851.43217.jkeating@redhat.com> On Wednesday 05 July 2006 16:13, seth vidal wrote: > ?I'd love to hear more comments on this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > I've read the guidelines and I don't see where it mandates the format of > the changelog lines. After reading all the comments, my opinion is A) Changelog format should not be a MUST, we could allow for some flexibility in the packager. B) There could be a generic 'The changelog SHOULD have the version-release noted in it somewhere' rule, where that version-release winds up is up to the packager, and its a should rather than a Must. Reviews shouldn't be blocked because of this, its just a suggested practice. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Thu Jul 6 12:54:40 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 06 Jul 2006 14:54:40 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: Your message of "Thu, 06 Jul 2006 00:02:31 +0200." <1152136951.5277.28.camel@rousalka.dyndns.org> Message-ID: <200607061254.k66CseKp029012@ludwig-alpha.unil.ch> nicolas.mailhot at laposte.net said: > There's so much material to package and so little time. You don't do FE > packagers any favour by accepting everything they propose blindly. Please. I'm not sure how you can interpret what I wrote as "accepting everything they propose blindly". FE is a collection of packages that someone found useful enough to take the time to generate a clean package spec and push through review. We have duplicated functionnality in many packages. We offer choice. We also do our best to avoid bad packages. But I have a hard time equating missing feature with bad, that's all. > Sometimes > providing a checklist of strongly recommended technical features will help > them choose between competing apps. And they don't discover after months of > gruelling packaging work they bet on the wrong horse - no one's interested in > foo app because bar does the same (and is IPv6/UTF-8/x86-64/GTK-2 whatever > compatible) I'm not convinced packagers choose software to package randomly. I'm sure they have a reason when they try to package something, and if they choose to package foo instead of bar: why do you think it's a problem ? If bar is useful and so much better, someone is bound to package it at some point... Christian From dwmw2 at infradead.org Thu Jul 6 12:58:16 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Jul 2006 13:58:16 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152121460.8883.48.camel@cutter> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <44ABB334.70309@math.unl.edu> <1152121077.2728.129.camel@localhost.localdomain> <1152121460.8883.48.camel@cutter> Message-ID: <1152190696.2987.143.camel@pmac.infradead.org> On Wed, 2006-07-05 at 13:44 -0400, seth vidal wrote: > except the onus of explaining what was broken was not on the packager. I don't like the word 'packager' -- it's ambiguous. If the 'package maintainer' is really only a 'package-monkey' and isn't capable of getting the problem fixed or _even_ providing a coherent explanation of why IPv6 support isn't present, why the package doesn't compile on PowerPC/x86_64, or whatever the problem is, then they really aren't someone we want to be responsible for a package in Fedora. Let them contribute, by all means, but do not let them own and be solely responsible for packages. -- dwmw2 From nicolas.mailhot at laposte.net Thu Jul 6 13:04:39 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 6 Jul 2006 15:04:39 +0200 (CEST) Subject: Packaging guidelines: IPv6 In-Reply-To: <200607061254.k66CseKp029012@ludwig-alpha.unil.ch> References: Your message of "Thu, 06 Jul 2006 00:02:31 +0200." <1152136951.5277.28.camel@rousalka.dyndns.org> <200607061254.k66CseKp029012@ludwig-alpha.unil.ch> Message-ID: <48274.192.54.193.52.1152191079.squirrel@rousalka.dyndns.org> Le Jeu 6 juillet 2006 14:54, Christian.Iseli at licr.org a ?crit : > I'm not convinced packagers choose software to package randomly. I'm sure > they have a reason when they try to package something, and if they choose > to package foo instead of bar: why do you think it's a problem ? If bar is > useful and so much better, someone is bound to package it at some point... Many many times the FE process starts like this : I need to do something, there is no app to do this something in Fedora, I'll package an app which does this something for Fedora Extras. Then goes fishing for the best something-doing app, based on biaised ML advice, obsolete web reviews, etc. Most packagers do not care which something-doing app they package as long as Fedora Extra gains the something-capability. So guidelines to help choose a candidate for packaging certainly help. -- Nicolas Mailhot From dwmw2 at infradead.org Thu Jul 6 13:06:31 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Jul 2006 14:06:31 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152136951.5277.28.camel@rousalka.dyndns.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> Message-ID: <1152191191.2987.151.camel@pmac.infradead.org> On Thu, 2006-07-06 at 00:02 +0200, Nicolas Mailhot wrote: > > Now if dwmw2 wants to force all Core packages to support IPv6, that's fine > > with me. > > dwmw2 needs IPv6 for OLPC Actually, the requirement for _all_ Core packages to support IPv6 isn't my idea -- it's coming from elsewhere. IPv6 is an increasingly common requirement these days -- and when I say 'requirement', I mean that a product can't be considered for use unless it fully supports IPv6. Since I feel strongly that Extras packages should not be 'second-class citizens', and that Extras shouldn't be a dumping ground for random crap which wouldn't be acceptable in Core, I made the suggestion that we should have similar requirements for Extras. If we're serious about Extras, we need to keep up with Core in portability and features. IPv6 isn't such an esoteric feature these days, just as UTF-8 isn't. Either we keep up, or we turn into Debian. -- dwmw2 From rc040203 at freenet.de Thu Jul 6 13:08:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Jul 2006 15:08:39 +0200 Subject: ambiguity in the guidelines In-Reply-To: <200607060851.43217.jkeating@redhat.com> References: <1152130412.8883.57.camel@cutter> <200607060851.43217.jkeating@redhat.com> Message-ID: <1152191320.5770.86.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 08:51 -0400, Jesse Keating wrote: > On Wednesday 05 July 2006 16:13, seth vidal wrote: > > I'd love to hear more comments on this > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197699 > > > > > > I've read the guidelines and I don't see where it mandates the format of > > the changelog lines. > > After reading all the comments, my opinion is > > A) Changelog format should not be a MUST, we could allow for some flexibility > in the packager. > > B) There could be a generic 'The changelog SHOULD have the version-release > noted in it somewhere' rule, where that version-release winds up is up to the > packager, and its a should rather than a Must. Reviews shouldn't be blocked > because of this, its just a suggested practice. I fail to see how this would be helpful. All this (and the warning in rpmlint) does, is to add confusion. I prefer strict and clear guidelines. I.e. either 1) CHANGELOGNAME is a freeform string. You can stick anything into it you might find useful. 2) Mandate a text format for CHANGELOGNAME. No exceptions allowed. Ralf From jwboyer at jdub.homelinux.org Thu Jul 6 13:12:12 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 06 Jul 2006 08:12:12 -0500 Subject: ambiguity in the guidelines In-Reply-To: <1152189926.2987.131.camel@pmac.infradead.org> References: <1152130412.8883.57.camel@cutter> <44AC1E63.2040104@knox.net.nz> <1152138273.2728.260.camel@localhost.localdomain> <44AC4121.6050508@knox.net.nz> <1152149890.12287.0.camel@cutter> <6280325c0607052211j2f7293d3w45dc3ab32bdfd300@mail.gmail.com> <1152164803.12287.36.camel@cutter> <6280325c0607052302m40287314l12f50b73238f9920@mail.gmail.com> <1152189926.2987.131.camel@pmac.infradead.org> Message-ID: <1152191532.22623.59.camel@weaponx.rchland.ibm.com> On Thu, 2006-07-06 at 13:45 +0100, David Woodhouse wrote: > On Thu, 2006-07-06 at 15:32 +0930, n0dalus wrote: > > This isn't about censorship. It's about respecting other people. You > > are free as always to say whatever you want, but that doesn't mean you > > should. > > While I happen to think Seth is full of shit on this occasion, I'll > defend his right to state his position in any way he sees fit. Please take this discussion off list if it must continue. It's neither relevant to the topic at hand, nor helpful in any way. josh From rc040203 at freenet.de Thu Jul 6 13:13:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Jul 2006 15:13:36 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <20060706144725.25b503d6@voip.int.addix.net> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> <1152104225.3201.27.camel@laptopd505.fenrus.org> <44ABC0AB.3050905@leemhuis.info> <1152107404.3201.34.camel@laptopd505.fenrus.org> <20060706144725.25b503d6@voip.int.addix.net> Message-ID: <1152191616.5770.90.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 14:47 +0200, Ralf Ertzinger wrote: > What is even worse, if we really held an audit across FE, I am afraid > that not may packages would remain alive. There is some spectacular stuff > out there. Not that running rpmlint would mean serious auditing, ... If you should have a couple of spare minutes, try running "rpmlint *rpm" over all packages currently having been released in FE. ... now start talking about security auditing ... ;) Ralf From jkeating at redhat.com Thu Jul 6 13:16:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 09:16:57 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152191320.5770.86.camel@mccallum.corsepiu.local> References: <1152130412.8883.57.camel@cutter> <200607060851.43217.jkeating@redhat.com> <1152191320.5770.86.camel@mccallum.corsepiu.local> Message-ID: <200607060916.58040.jkeating@redhat.com> On Thursday 06 July 2006 09:08, Ralf Corsepius wrote: > All this (and the warning in rpmlint) does, is to add confusion. I > prefer strict and clear guidelines. > > I.e. either > 1) CHANGELOGNAME is a freeform string. You can stick anything into it > you might find useful. > > 2) Mandate a text format for CHANGELOGNAME. No exceptions allowed. There is plenty of room between the 'do whatever you want' and 'YOU MUST DO EXACTLY AS WE SAY OR ELSE!!!' standpoints. CHANGELOGNAME is somewhat freeform. You can put as little or as much as you want. Best practices would have you put your name, email address, and optionally the version-release associated with this changelog. You could also put that version-release within the changelog entry rather than on the CHANGELOGNAME line. This is up to the packager's discretion. There, now we have something of 1, but with some suggested formatting. Much nicer and much easier to swallow than a 400lb gorilla with a boulder and a bad attitude standing over you telling you how you must make a changelog entry. Reviewers can suggest that the packager follow the best practice, but in the end it would be up to the packager on this issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sgrubb at redhat.com Thu Jul 6 13:18:17 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 6 Jul 2006 09:18:17 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152191191.2987.151.camel@pmac.infradead.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> Message-ID: <200607060918.17855.sgrubb@redhat.com> On Thursday 06 July 2006 09:06, David Woodhouse wrote: > Actually, the requirement for _all_ Core packages to support IPv6 isn't > my idea -- it's coming from elsewhere. IPv6 is an increasingly common > requirement these days -- and when I say 'requirement', I mean that a > product can't be considered for use unless it fully supports IPv6. Just to back David up on this, I'd like to point people to a recent slashdot article (there's other articles, too. But people here should be familiar with slashdot): http://it.slashdot.org/article.pl?sid=06/06/22/1746243&from=rss Just in case you don't want to read it, it says the US govt will adopt IPv6 in 2008. IPv6 readiness should be viewed as a preliminary step to make sure we aren't disqualified when this goes into effect. I think we all feel the pain of this transition, but the end result should be Linux being qualified to be deployed in all environments. -Steve From jkeating at redhat.com Thu Jul 6 13:19:36 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 09:19:36 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152130412.8883.57.camel@cutter> <1152161479.12287.28.camel@cutter> Message-ID: <200607060919.37145.jkeating@redhat.com> On Thursday 06 July 2006 01:50, Christopher Stone wrote: > I have seen > packagers refuse to add %{?dist} tags to their spec file because its > not "a bug". ?Well so what? On this side subject, a %{?dist} tag is really a convenience tool for the maintainer in question. If they choose not to use it, so what? Doesn't really effect end users outside of hyperboles. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From misa at redhat.com Thu Jul 6 13:24:52 2006 From: misa at redhat.com (Mihai Ibanescu) Date: Thu, 6 Jul 2006 09:24:52 -0400 Subject: ambiguity in the guidelines In-Reply-To: References: <1152151631.12287.19.camel@cutter> <1152161479.12287.28.camel@cutter> <1152167288.12287.41.camel@cutter> <1152167851.12287.44.camel@cutter> <1152169093.12287.49.camel@cutter> Message-ID: <20060706132452.GA21060@abulafia.devel.redhat.com> On Thu, Jul 06, 2006 at 12:13:06AM -0700, Christopher Stone wrote: > On 7/5/06, seth vidal wrote: > >Let's be clear about what's going on here: > >1. I do not think it is an appropriate to overload the field > >2. I do not wish to take part in that particular dirtiness > >3. until today no one has questioned the desire for correctness on my > >part > >4. I'm not asking anyone else to do what I'm doing - I'm just trying to > >do what I think is most correct and appropriate given the technology > >available. > > Okay, but you have not explained _why_ adding version information to > this field is "overloading" it. > > How does this affect anything? You have not given any reason to not > include version information other than the name of the field which if > I recall from this thread is called "changelogname". > > So why is this important to not include version information in this > field? Why is it important that this field only contain date, > packager name and email? Is there some technical reason why this > field should only contain this particular data? > > What if we called the field "changeloginfo" rather than > "changelogname" or whatever it is called now? Would this change things > in your mind? For completeness' sake, rpm does parse changelog entries, and stores it in 3 fields: RPMTAG_CHANGELOGTIME, RPMTAG_CHANGELOGNAME and RPMTAG_CHANGELOGTEXT In an entry: * Thu Jul 6 2006 Mihai Ibanescu foo bar - this is the text rpm will enforce the format of the first line to be a valid date, and will store it in RPMTAG_CHANGELOGTIME. Everything from the first line after that is stored in RPMTAG_CHANGELOGNAME. The next lines are stored in RPMTAG_CHANGELOGTEXT. Seth's argument is that, if we want to enforce the format of the entry, then we should create another header field and parse the extra data accordingly. Several years ago, in RHN, we tried to compute some statistics on how many entries were edited by a particular packager, and I found out the hard way that you can't quite rely on the contents of RPMTAG_CHANGELOGNAME. Sure, you can parse that data somehow. But who guarantees (without running some tests on all core + extras packages) that the name itself is parseable by a regex? Even the not-so-standard "misa at redhat dot com" shouldn't have been left in by RPM, imo. If you want privacy, register a yahoo account and use that for packaging (of course nobody would trust you - but I digress). rpm's rules are way too loose, and people have taken advantage of them in all sorts of ways. Enforcing rules should start with making rpm consistent first. I do find the version information extremely useful in the changelogs, but I agree with Seth we should do it right as opposed to taking advatage of rpm's spec parser. Misa From jwboyer at jdub.homelinux.org Thu Jul 6 13:24:31 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 06 Jul 2006 08:24:31 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152191191.2987.151.camel@pmac.infradead.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> Message-ID: <1152192271.22623.64.camel@weaponx.rchland.ibm.com> On Thu, 2006-07-06 at 14:06 +0100, David Woodhouse wrote: > On Thu, 2006-07-06 at 00:02 +0200, Nicolas Mailhot wrote: > > > Now if dwmw2 wants to force all Core packages to support IPv6, that's fine > > > with me. > > > > dwmw2 needs IPv6 for OLPC > > Actually, the requirement for _all_ Core packages to support IPv6 isn't > my idea -- it's coming from elsewhere. IPv6 is an increasingly common > requirement these days -- and when I say 'requirement', I mean that a > product can't be considered for use unless it fully supports IPv6. And if a package in Core doesn't support IPv6 what happens? Does it get thrown out of Core (and by the proposed standards Extras as well)? josh From rc040203 at freenet.de Thu Jul 6 13:24:56 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Jul 2006 15:24:56 +0200 Subject: ambiguity in the guidelines In-Reply-To: <200607060919.37145.jkeating@redhat.com> References: <1152130412.8883.57.camel@cutter> <1152161479.12287.28.camel@cutter> <200607060919.37145.jkeating@redhat.com> Message-ID: <1152192296.5770.95.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 09:19 -0400, Jesse Keating wrote: > On Thursday 06 July 2006 01:50, Christopher Stone wrote: > > I have seen > > packagers refuse to add %{?dist} tags to their spec file because its > > not "a bug". Well so what? > > On this side subject, a %{?dist} tag is really a convenience tool for the > maintainer in question. If they choose not to use it, so what? Doesn't > really effect end users outside of hyperboles. Wrong. It renders it Release tags non-deterministic and unnecessarily complicates things. Ralf From arjan at fenrus.demon.nl Thu Jul 6 13:24:58 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 06 Jul 2006 15:24:58 +0200 Subject: Packaging guidelines: IPv6 In-Reply-To: <200607060918.17855.sgrubb@redhat.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <200607060918.17855.sgrubb@redhat.com> Message-ID: <1152192298.3084.35.camel@laptopd505.fenrus.org> On Thu, 2006-07-06 at 09:18 -0400, Steve Grubb wrote: > On Thursday 06 July 2006 09:06, David Woodhouse wrote: > > Actually, the requirement for _all_ Core packages to support IPv6 isn't > > my idea -- it's coming from elsewhere. IPv6 is an increasingly common > > requirement these days -- and when I say 'requirement', I mean that a > > product can't be considered for use unless it fully supports IPv6. > > Just to back David up on this, I'd like to point people to a recent slashdot > article (there's other articles, too. But people here should be familiar with > slashdot): > > http://it.slashdot.org/article.pl?sid=06/06/22/1746243&from=rss > > Just in case you don't want to read it, it says the US govt will adopt IPv6 in > 2008. IPv6 readiness should be viewed as a preliminary step to make sure we > aren't disqualified when this goes into effect. that's a good thing for RHEL... that doesn't mean it's relevant for Fedora Extras..... From rc040203 at freenet.de Thu Jul 6 13:30:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Jul 2006 15:30:18 +0200 Subject: ambiguity in the guidelines In-Reply-To: <200607060916.58040.jkeating@redhat.com> References: <1152130412.8883.57.camel@cutter> <200607060851.43217.jkeating@redhat.com> <1152191320.5770.86.camel@mccallum.corsepiu.local> <200607060916.58040.jkeating@redhat.com> Message-ID: <1152192618.5770.102.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 09:16 -0400, Jesse Keating wrote: > On Thursday 06 July 2006 09:08, Ralf Corsepius wrote: > > All this (and the warning in rpmlint) does, is to add confusion. I > > prefer strict and clear guidelines. > > > > I.e. either > > 1) CHANGELOGNAME is a freeform string. You can stick anything into it > > you might find useful. > > > > 2) Mandate a text format for CHANGELOGNAME. No exceptions allowed. > > There is plenty of room between the 'do whatever you want' and 'YOU MUST DO > EXACTLY AS WE SAY OR ELSE!!!' standpoints. > > CHANGELOGNAME is somewhat freeform. Technically, it is 100% freeform - I checked the source code. Nothing inside of CHANGELOGNAME is explicitly parsed. Not even email addresses. It's just a \0 terminated char[] starting after the Date string. > You can put as little or as much as you > want. Best practices would have you put your name, email address, and > optionally the version-release associated with this changelog. You could > also put that version-release within the changelog entry rather than on the > CHANGELOGNAME line. This is up to the packager's discretion. Your last sentence is what I find not helpful. As I perceive it, you seem to be keen on "making things unnecessarily complicated and confusing". > Reviewers can suggest that the packager follow the best practice, but in the > end it would be up to the packager on this issue. ... simply confusion. Ralf From dwmw2 at infradead.org Thu Jul 6 13:32:15 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Jul 2006 14:32:15 +0100 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152192271.22623.64.camel@weaponx.rchland.ibm.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <1152192271.22623.64.camel@weaponx.rchland.ibm.com> Message-ID: <1152192735.2987.175.camel@pmac.infradead.org> On Thu, 2006-07-06 at 08:24 -0500, Josh Boyer wrote: > And if a package in Core doesn't support IPv6 what happens? Does it get > thrown out of Core (and by the proposed standards Extras as well)? No. It gets fixed. Because we have package _maintainers_ in Core, not just package-monkeys. We're working on that already -- the first step is identifying all the packages which need fixing, and filing bugs. Hence the growing list at https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=195271 -- dwmw2 From sgrubb at redhat.com Thu Jul 6 13:46:13 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 6 Jul 2006 09:46:13 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152192298.3084.35.camel@laptopd505.fenrus.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <200607060918.17855.sgrubb@redhat.com> <1152192298.3084.35.camel@laptopd505.fenrus.org> Message-ID: <200607060946.13268.sgrubb@redhat.com> On Thursday 06 July 2006 09:24, Arjan van de Ven wrote: > that's a good thing for RHEL... that doesn't mean it's relevant for > Fedora Extras..... This is just not about RHEL. There are a fair number of govt admins that use Fedora Core as their platform - not RHEL. I think that we should collectively look at this as a significant customer setting the bar higher. We have a choice to jump over the bar or limbo under it. For years I've heard people all over the world ask when IPv6 will become the standard...we are running out of IPv4 address space...etc. This is the call to arms to do something about it. This is a chance to show that Linux is ready and able to be deployed. -Steve From jwboyer at jdub.homelinux.org Thu Jul 6 13:46:57 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 06 Jul 2006 08:46:57 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152192735.2987.175.camel@pmac.infradead.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <1152192271.22623.64.camel@weaponx.rchland.ibm.com> <1152192735.2987.175.camel@pmac.infradead.org> Message-ID: <1152193617.22623.73.camel@weaponx.rchland.ibm.com> On Thu, 2006-07-06 at 14:32 +0100, David Woodhouse wrote: > On Thu, 2006-07-06 at 08:24 -0500, Josh Boyer wrote: > > And if a package in Core doesn't support IPv6 what happens? Does it get > > thrown out of Core (and by the proposed standards Extras as well)? > > No. It gets fixed. Because we have package _maintainers_ in Core, not > just package-monkeys. And that's viable for people who have time and skill to do so. Extras developers who wish to do that are always welcome to. Those that can't can certainly work with upstream. > We're working on that already -- the first step is identifying all the > packages which need fixing, and filing bugs. Hence the growing list at > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=195271 That's great. Personally, I have no problems with adding Extras packages to that bug. However, I don't see it as a requirement. The major point here is, it should not be a blocker if something doesn't support IPv6 at the moment. Somewhere someone found such a package useful and spent time to push it through review. You might think that's crap, but one man's crap is another man's treasure. An analogy for you: I have a VCR from 1984 in my house. It's almost as old as I am. It's ugly, heavy, big, and loud. I consider it crappy even. But it _works_ and I find it useful. I'm not going to throw it away just because it doesn't support playing a shiny disc. josh From jkeating at redhat.com Thu Jul 6 15:00:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 11:00:32 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152192618.5770.102.camel@mccallum.corsepiu.local> References: <1152130412.8883.57.camel@cutter> <200607060916.58040.jkeating@redhat.com> <1152192618.5770.102.camel@mccallum.corsepiu.local> Message-ID: <200607061100.32189.jkeating@redhat.com> On Thursday 06 July 2006 09:30, Ralf Corsepius wrote: > > ?You can put as little or as much as you > > want. ?Best practices would have you put your name, email address, and > > optionally the version-release associated with this changelog. ?You could > > also put that version-release within the changelog entry rather than on > > the CHANGELOGNAME line. ?This is up to the packager's discretion. > > Your last sentence is what I find not helpful. As I perceive it, you > seem to be keen on "making things unnecessarily complicated and > confusing". > > > Reviewers can suggest that the packager follow the best practice, but in > > the end it would be up to the packager on this issue. > > ... simply confusion. Our packagers are not drooling idiots. If they are, they should not be sponsored. If you can't understand a simple suggested layout, with provided examples, perhaps you shouldn't be packaging for Fedora. I will not support draconian approaches to packaging though. Silly things like this should be a packagers choice. Things that really matter, like the release string, or other such fields that are parsed should have rules. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Jul 6 15:12:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Jul 2006 17:12:36 +0200 Subject: ambiguity in the guidelines In-Reply-To: <200607061100.32189.jkeating@redhat.com> References: <1152130412.8883.57.camel@cutter> <200607060916.58040.jkeating@redhat.com> <1152192618.5770.102.camel@mccallum.corsepiu.local> <200607061100.32189.jkeating@redhat.com> Message-ID: <1152198756.5770.115.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 11:00 -0400, Jesse Keating wrote: > On Thursday 06 July 2006 09:30, Ralf Corsepius wrote: > I will not support draconian approaches to packaging though. We are not talking about "draconian approaches". We are talking about restrictions/conventions to KISS. > Silly things like this should be a packagers choice. I disagree, things should be simple and clear. Whether you like it or not, simplicity often means "silly" or "stupid" or "restrictive". Ralf From jkeating at redhat.com Thu Jul 6 15:26:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 11:26:35 -0400 Subject: ambiguity in the guidelines In-Reply-To: <1152198756.5770.115.camel@mccallum.corsepiu.local> References: <1152130412.8883.57.camel@cutter> <200607061100.32189.jkeating@redhat.com> <1152198756.5770.115.camel@mccallum.corsepiu.local> Message-ID: <200607061126.35473.jkeating@redhat.com> On Thursday 06 July 2006 11:12, Ralf Corsepius wrote: > > I will not support draconian approaches to packaging though. > > We are not talking about "draconian approaches". We are talking about > restrictions/conventions to KISS. > > > ? Silly things like this should be a packagers choice. > > I disagree, things should be simple and clear. Whether you like it or > not, simplicity often means "silly" or "stupid" or "restrictive". I'm pretty sure we can agree to disagree on this matter. I'm more in favor of keeping the RULES simple so that the barrier to packaging is low, and leave silly little things that don't _really_ matter up to the packager. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jul 6 15:27:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 11:27:12 -0400 Subject: ambiguity in the guidelines In-Reply-To: <200607061100.32189.jkeating@redhat.com> References: <1152130412.8883.57.camel@cutter> <1152192618.5770.102.camel@mccallum.corsepiu.local> <200607061100.32189.jkeating@redhat.com> Message-ID: <200607061127.12341.jkeating@redhat.com> On Thursday 06 July 2006 11:00, Jesse Keating wrote: > If you can't understand a simple suggested layout, with provided > examples, perhaps you shouldn't be packaging for Fedora. I should have worded this: If a new packager can't understand a simple suggested layout, with provided examples, perhaps said packager shouldn't be packaging for Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgarzik at redhat.com Thu Jul 6 16:35:25 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Thu, 6 Jul 2006 12:35:25 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152191191.2987.151.camel@pmac.infradead.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> Message-ID: <20060706163525.GE17038@devserv.devel.redhat.com> On Thu, Jul 06, 2006 at 02:06:31PM +0100, David Woodhouse wrote: > If we're serious about Extras, we need to keep up with Core in > portability and features. IPv6 isn't such an esoteric feature these > days, just as UTF-8 isn't. Just to point out to the crowd here: Lack of IPv6 and UTF-8 support means you are locking out huge swaths of Asian users (and Middle Easterners too, depending on the language). These are not just arbitrary features on some manager's checklist. Real users are being locked out... Jeff From jgarzik at redhat.com Thu Jul 6 16:38:06 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Thu, 6 Jul 2006 12:38:06 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152193617.22623.73.camel@weaponx.rchland.ibm.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <1152192271.22623.64.camel@weaponx.rchland.ibm.com> <1152192735.2987.175.camel@pmac.infradead.org> <1152193617.22623.73.camel@weaponx.rchland.ibm.com> Message-ID: <20060706163806.GF17038@devserv.devel.redhat.com> On Thu, Jul 06, 2006 at 08:46:57AM -0500, Josh Boyer wrote: > An analogy for you: I have a VCR from 1984 in my house. It's almost as > old as I am. It's ugly, heavy, big, and loud. I consider it crappy > even. But it _works_ and I find it useful. I'm not going to throw it > away just because it doesn't support playing a shiny disc. Poor analogy. A better analogy would be forcing VHS VCRs on owners of VHS tapes, and also on owners of Betamax tapes. Jeff From jwboyer at jdub.homelinux.org Thu Jul 6 17:29:43 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 06 Jul 2006 12:29:43 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <20060706163806.GF17038@devserv.devel.redhat.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <1152192271.22623.64.camel@weaponx.rchland.ibm.com> <1152192735.2987.175.camel@pmac.infradead.org> <1152193617.22623.73.camel@weaponx.rchland.ibm.com> <20060706163806.GF17038@devserv.devel.redhat.com> Message-ID: <1152206983.22623.82.camel@weaponx.rchland.ibm.com> On Thu, 2006-07-06 at 12:38 -0400, Jeff Garzik wrote: > On Thu, Jul 06, 2006 at 08:46:57AM -0500, Josh Boyer wrote: > > An analogy for you: I have a VCR from 1984 in my house. It's almost as > > old as I am. It's ugly, heavy, big, and loud. I consider it crappy > > even. But it _works_ and I find it useful. I'm not going to throw it > > away just because it doesn't support playing a shiny disc. > > Poor analogy. A better analogy would be forcing VHS VCRs on owners of > VHS tapes, and also on owners of Betamax tapes. No, nobody is forcing anything on anybody. But whatever, the analogy isn't really worth fighting over :) josh From nicolas.mailhot at laposte.net Thu Jul 6 19:05:55 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Jul 2006 21:05:55 +0200 Subject: ambiguity in the guidelines In-Reply-To: <200607061126.35473.jkeating@redhat.com> References: <1152130412.8883.57.camel@cutter> <200607061100.32189.jkeating@redhat.com> <1152198756.5770.115.camel@mccallum.corsepiu.local> <200607061126.35473.jkeating@redhat.com> Message-ID: <1152212755.26100.2.camel@rousalka.dyndns.org> Le jeudi 06 juillet 2006 ? 11:26 -0400, Jesse Keating a ?crit : > I'm pretty sure we can agree to disagree on this matter. > > I'm more in favor of keeping the RULES simple so that the barrier to packaging > is low, and leave silly little things that don't _really_ matter up to the > packager. The rules can be draconian or fuzzy. Does not matter What matters they are clearly documented. So my position is : if you manage to express a rule in a document that is easy to parse by contributors, and if the rule is semi-sane, it's in -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From smooge at gmail.com Thu Jul 6 19:06:25 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 6 Jul 2006 13:06:25 -0600 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152103825.32572.73.camel@pmac.infradead.org> References: <1152099806.32572.65.camel@pmac.infradead.org> <1152100959.3458.20.camel@cutter> <1152103825.32572.73.camel@pmac.infradead.org> Message-ID: <80d7e4090607061206kf53a726h13b5e6daa865c7cf@mail.gmail.com> On 7/5/06, David Woodhouse wrote: > > We don't have i18n requirements for extras software, either. > > Perhaps we should? I thought we at least required that they join us in > the 21st century and operate correctly with UTF-8. Do we have _no_ > written guidelines on the quality of the software we accept to be > packaged? > Well first, what do you mean by code quality? That can mean anything from "Uses XZY blessed coding style", "Uses AGH technique so that formal methods can be used to confirm correctness of each routine", to "Dude, it compiled with ' -Wall -Wextra -pedantic-errors' without any crashes." Other questions that seem to come out of this are: What coding knowledge must a maintainer have? What hardware/software/network access must a maintainer have? -- Stephen J Smoogen. CSIRT/Linux System Administrator From steve at kspei.com Thu Jul 6 20:38:39 2006 From: steve at kspei.com (Steven Pritchard) Date: Thu, 6 Jul 2006 15:38:39 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152192735.2987.175.camel@pmac.infradead.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <1152192271.22623.64.camel@weaponx.rchland.ibm.com> <1152192735.2987.175.camel@pmac.infradead.org> Message-ID: <20060706203839.GA5992@osiris.silug.org> On Thu, Jul 06, 2006 at 02:32:15PM +0100, David Woodhouse wrote: > We're working on that already -- the first step is identifying all the > packages which need fixing, and filing bugs. Hence the growing list at > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=195271 So is there an Extras equivalent of that yet? If so, 190165 should be added to it... 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 jwboyer at jdub.homelinux.org Thu Jul 6 20:48:14 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 06 Jul 2006 15:48:14 -0500 Subject: Packaging guidelines: IPv6 In-Reply-To: <20060706203839.GA5992@osiris.silug.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <1152191191.2987.151.camel@pmac.infradead.org> <1152192271.22623.64.camel@weaponx.rchland.ibm.com> <1152192735.2987.175.camel@pmac.infradead.org> <20060706203839.GA5992@osiris.silug.org> Message-ID: <1152218894.22623.128.camel@weaponx.rchland.ibm.com> On Thu, 2006-07-06 at 15:38 -0500, Steven Pritchard wrote: > On Thu, Jul 06, 2006 at 02:32:15PM +0100, David Woodhouse wrote: > > We're working on that already -- the first step is identifying all the > > packages which need fixing, and filing bugs. Hence the growing list at > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=195271 > > So is there an Extras equivalent of that yet? If so, 190165 should be > added to it... Does there really need to be a separate Extras bug? If people want Core and Extras to be in-sync on this issue, then they can use the same bug. josh From blizzard at redhat.com Fri Jul 7 00:56:12 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 06 Jul 2006 20:56:12 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <1152136951.5277.28.camel@rousalka.dyndns.org> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> Message-ID: <44ADB12C.4080509@redhat.com> Nicolas Mailhot wrote: >> Now if dwmw2 wants to force all Core packages to support IPv6, that's fine >> with me. > > dwmw2 needs IPv6 for OLPC Yeah, but we only need it for a limited subset of packages. --Chris From notting at redhat.com Fri Jul 7 00:59:35 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Jul 2006 20:59:35 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ADB12C.4080509@redhat.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <44ADB12C.4080509@redhat.com> Message-ID: <20060707005935.GA3805@nostromo.devel.redhat.com> Christopher Blizzard (blizzard at redhat.com) said: > >dwmw2 needs IPv6 for OLPC > > Yeah, but we only need it for a limited subset of packages. But... but... we're not shipping nethack on olpc? Bill From peter at thecodergeek.com Fri Jul 7 01:00:40 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 06 Jul 2006 18:00:40 -0700 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <604aa7910606301747y5d6e4a4dkcc39365c5d3cbbef@mail.gmail.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <4471E231.1070409@thecodergeek.com> <604aa7910606041833x1b108f37j3f522aa23033a753@mail.gmail.com> <4485B20F.3020103@thecodergeek.com> <604aa7910606301747y5d6e4a4dkcc39365c5d3cbbef@mail.gmail.com> Message-ID: <44ADB238.9040309@thecodergeek.com> Jeff Spaleta wrote: > On 6/6/06, Peter Gordon wrote: >> Done. Good luck with the move, Jeff! :) > > Good Morning, > > I'm sortof back online, but I'm not in a state where I can do any sort > of Extras work. Any problems with assuming maintainership of glabels? > I'd be happy to assume sole maintainership of it for you, sure. Do you want to be on the initialcclist in owners.list? (Sorry for the late reply: I was upstate for a few days.) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From blizzard at redhat.com Fri Jul 7 01:05:29 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 06 Jul 2006 21:05:29 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <20060707005935.GA3805@nostromo.devel.redhat.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <44ADB12C.4080509@redhat.com> <20060707005935.GA3805@nostromo.devel.redhat.com> Message-ID: <44ADB359.7060903@redhat.com> Bill Nottingham wrote: > Christopher Blizzard (blizzard at redhat.com) said: >>> dwmw2 needs IPv6 for OLPC >> Yeah, but we only need it for a limited subset of packages. > > But... but... we're not shipping nethack on olpc? > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers Can you say easter egg? --Chris From jgarzik at redhat.com Fri Jul 7 01:13:53 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Thu, 6 Jul 2006 21:13:53 -0400 Subject: Packaging guidelines: IPv6 In-Reply-To: <44ADB12C.4080509@redhat.com> References: <200607052140.k65LerJE001224@mx3.redhat.com> <1152136951.5277.28.camel@rousalka.dyndns.org> <44ADB12C.4080509@redhat.com> Message-ID: <20060707011353.GA13054@devserv.devel.redhat.com> On Thu, Jul 06, 2006 at 08:56:12PM -0400, Christopher Blizzard wrote: > Nicolas Mailhot wrote: > >>Now if dwmw2 wants to force all Core packages to support IPv6, that's > >>fine with me. > > > >dwmw2 needs IPv6 for OLPC > > Yeah, but we only need it for a limited subset of packages. Yes, the Japanese and Koreans on IPv6-only networks agree with this. Jeff From rc040203 at freenet.de Fri Jul 7 06:45:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Jul 2006 08:45:43 +0200 Subject: bugzilla: Insufficient disk space Message-ID: <1152254744.14649.36.camel@mccallum.corsepiu.local> Hi, bugzilla seems to be broken: After replying to a PR, I received this: Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for apache Insufficient disk space; try again later returntosender: cannot select queue for postmaster putbody: write error: No space left on device Error writing control file qfk676gJPT024578: No space left on device Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for apache Insufficient disk space; try again later returntosender: cannot select queue for postmaster putbody: write error: No space left on device Error writing control file qfk676gJPd024580: No space left on device Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for apache Insufficient disk space; try again later returntosender: cannot select queue for postmaster putbody: write error: No space left on device Error writing control file qfk676gKkM024581: No space left on device Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for apache Insufficient disk space; try again later returntosender: cannot select queue for postmaster putbody: write error: No space left on device Error writing control file qfk676gKXW024583: No space left on device Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for apache Insufficient disk space; try again later returntosender: cannot select queue for postmaster putbody: write error: No space left on device Error writing control file qfk676gKFc024584: No space left on device [Yes, one big, unformated big blob of text] Ralf From michael at knox.net.nz Fri Jul 7 06:49:35 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 07 Jul 2006 18:49:35 +1200 Subject: bugzilla: Insufficient disk space In-Reply-To: <1152254744.14649.36.camel@mccallum.corsepiu.local> References: <1152254744.14649.36.camel@mccallum.corsepiu.local> Message-ID: <44AE03FF.2070609@knox.net.nz> Ralf Corsepius wrote: > Hi, > > bugzilla seems to be broken: > > After replying to a PR, I received this: > > Insufficient disk space; try again later Insufficient disk space; try [snip] > [Yes, one big, unformated big blob of text] > Holy crap.. BZ has been having a rough time lately :( I hope its sorted quickly and not reports are lost this time. Michael From mattdm at mattdm.org Fri Jul 7 18:09:35 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Jul 2006 14:09:35 -0400 Subject: A Heads-Up: moving all FC3 bugs to "needinfo" Message-ID: <20060707180935.GA17747@jadzia.bu.edu> As I did with FC2 long ago, I'm going to go through and mark all open FC3 bugs as "needinfo". This is a last-ditch attempt to make sure any of those that really need to be addressed by Fedora Legacy get the attention they need, and that anything still open that's still an issue in current releases doesn't get lost forever. I should have done this a long time ago, but I'm going to pull the "had a baby" excuse on that. When FC4 goes to Legacy, I'll do the same thing for those. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Fri Jul 7 21:23:21 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Jul 2006 17:23:21 -0400 Subject: FC6 test2 freeze slipping by a week Message-ID: <1152307401.18501.0.camel@aglarond.local> Due to a desire to integrate the DT_GNU_HASH changes for binutils and glibc (which provide an ~ 50% speedup for dynamic linking) and the necessity of doing a rebuild for these changes, we are going to slip the freeze for FC6 test2 by one week. The new freeze date will be Wednesday, 19 July 2006. This should also allow a few other things that are straggling time to be tested a little bit more in time for the feature freeze at test2. Jeremy From jkeating at redhat.com Fri Jul 7 21:23:26 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Jul 2006 17:23:26 -0400 Subject: Mass rebuild of core packages coming soon In-Reply-To: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> Message-ID: <200607071723.26888.jkeating@redhat.com> On Friday 30 June 2006 15:47, Jesse Keating wrote: > I've been requested to rebuild every Core package for a few reasons. > > 1) rpm signing w/ sha256sum > 2) New toolset feature to speed up dynamic lib linking by 50%~ > 3) get all packages built through new build system (brew) > > We're waiting for some stuff to finalize upstream, but would like to > start on the building next week. > > Please give me a list of packages you'd prefer I didn't build and I'll > blacklist them from my massbuild scripts. Looks like the sha256sum stuff will make FC6, so we're just rebuilding for brew and the binutils / libtool stuff. We're still waiting on upstream approval on the toolset changes, and thus we are waiting on the rebuild. It is still coming. See Jeremy's email about the slip. -- Jesse Keating Release Engineer: Fedora From arjan at fenrus.demon.nl Fri Jul 7 21:37:22 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 07 Jul 2006 23:37:22 +0200 Subject: Mass rebuild of core packages coming soon In-Reply-To: <200607071723.26888.jkeating@redhat.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <200607071723.26888.jkeating@redhat.com> Message-ID: <1152308242.3111.154.camel@laptopd505.fenrus.org> On Fri, 2006-07-07 at 17:23 -0400, Jesse Keating wrote: > On Friday 30 June 2006 15:47, Jesse Keating wrote: > > I've been requested to rebuild every Core package for a few reasons. > > > > 1) rpm signing w/ sha256sum > > 2) New toolset feature to speed up dynamic lib linking by 50%~ > > 3) get all packages built through new build system (brew) > > > > We're waiting for some stuff to finalize upstream, but would like to > > start on the building next week. > > > > Please give me a list of packages you'd prefer I didn't build and I'll > > blacklist them from my massbuild scripts. > > Looks like the sha256sum stuff will make FC6, so we're just rebuilding for > brew and the binutils / libtool stuff. We're still waiting on upstream > approval on the toolset changes, and thus we are waiting on the rebuild. It > is still coming. See Jeremy's email about the slip. > can we make sure the change to x86-64 binutils to use a 2Mb default alignment is in as well? That'll be key for having transparent hugepages for text etc... (eg higher performance) From jwboyer at jdub.homelinux.org Fri Jul 7 21:40:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 07 Jul 2006 16:40:30 -0500 Subject: FC6 test2 freeze slipping by a week In-Reply-To: <1152307401.18501.0.camel@aglarond.local> References: <1152307401.18501.0.camel@aglarond.local> Message-ID: <1152308430.17827.9.camel@weaponx.rchland.ibm.com> On Fri, 2006-07-07 at 17:23 -0400, Jeremy Katz wrote: > Due to a desire to integrate the DT_GNU_HASH changes for binutils and > glibc (which provide an ~ 50% speedup for dynamic linking) and the > necessity of doing a rebuild for these changes, we are going to slip the > freeze for FC6 test2 by one week. The new freeze date will be > Wednesday, 19 July 2006. This should also allow a few other things that > are straggling time to be tested a little bit more in time for the > feature freeze at test2. Is it worth respinning Extras to pick up this performance speedup for test2? Or is it pain enough just getting Extras respun for release? josh From gauret at free.fr Fri Jul 7 21:43:21 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 7 Jul 2006 23:43:21 +0200 Subject: Update of libvisual Message-ID: <200607072343.27403.gauret@free.fr> Hey fellow maintainers, I need version 0.4.0 of libvisual for the new version of Amarok. Repoquery tells me that libvisual-plugins and gstreamer08-plugins depend on the current version 0.2.0 in Extras. I've tried to rebuild your packages with the new version. Libvisual-plugins obviously needs to be updated to 0.4.0 too, but it is pretty straightforward (both patches are included upstream now). Unfortunately gstreamer08-plugins requires libvisual 0.2.0. So I have two options : - if Brian considers the visual plugins are not very important in gstreamer08-plugins (which is already a compatibility package), we could update libvisual to 0.4.0, rebuild gstreamer08-plugins and and drop support of libvisual in it. - else I could create a compat-libvisual02 package, but I'd like to avoid that if possible. What do you think ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Sat Jul 8 07:34:53 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 8 Jul 2006 09:34:53 +0200 Subject: Update of libvisual In-Reply-To: <1152310461.5989.30.camel@atlantis.mpeters.local> References: <200607072343.27403.gauret@free.fr> <1152310461.5989.30.camel@atlantis.mpeters.local> Message-ID: <200607080935.02073.gauret@free.fr> > Hi - I've had a spec file for new libvisual plugins in cvs for awhile > (but not building it) - whenever you want to move to new libvisual, I'm > all for it. > > With respect to gstreamer08 - I'm of the opinion that the libvisual > plugin should be dropped from it. Core gstreamer plugins never had it, > and there's not much out there that can take advantage of it. Brian replied me privately that he's OK with dropping support for libvisual plugins in gstreamer08-plugins (which can be done by a simple rebuild). He's also OK with me rebuilding the package since he's on vacation. So here's the plan : - I'm going to update libvisual to 0.4.0 - I'll change the gstreamer08-plugins package to bump the release, drop the libvisual-devel build dep and add --disable-libvisual to the configure - Michael, please update libvisual-plugins as soon as possible. That is going to happen in the devel branch and the FC-5 branch. Cheers, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr A Black Hole is where God divided by zero. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sat Jul 8 12:33:44 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 8 Jul 2006 14:33:44 +0200 Subject: Take Over : PCB : Permission Message-ID: <13dbfe4f0607080533t3020a5dat305049cb0bdd8cac@mail.gmail.com> Hello there, It's nearly 3 months, now since the last activity. PCB is an application, I personnally will be dependent on since Im an electronic student. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189482 Im asking whether I can take over it, can I ? I have already a spec file - with the latest release 20060422 - rpmlint does not complain - builds successfully under mock (i386) SPEC : http://beta.glwb.info/pcb/pcb.spec SRPM : http://beta.glwb.info/pcb/pcb-0.20060422-1.src.rpm regards, Chitlesh Goorah -- http://clunixchit.blogspot.com From katzj at redhat.com Sat Jul 8 17:38:57 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 08 Jul 2006 13:38:57 -0400 Subject: FC6 test2 freeze slipping by a week In-Reply-To: <1152308430.17827.9.camel@weaponx.rchland.ibm.com> References: <1152307401.18501.0.camel@aglarond.local> <1152308430.17827.9.camel@weaponx.rchland.ibm.com> Message-ID: <1152380337.18501.7.camel@aglarond.local> On Fri, 2006-07-07 at 16:40 -0500, Josh Boyer wrote: > On Fri, 2006-07-07 at 17:23 -0400, Jeremy Katz wrote: > > Due to a desire to integrate the DT_GNU_HASH changes for binutils and > > glibc (which provide an ~ 50% speedup for dynamic linking) and the > > necessity of doing a rebuild for these changes, we are going to slip the > > freeze for FC6 test2 by one week. The new freeze date will be > > Wednesday, 19 July 2006. This should also allow a few other things that > > are straggling time to be tested a little bit more in time for the > > feature freeze at test2. > > Is it worth respinning Extras to pick up this performance speedup for > test2? Or is it pain enough just getting Extras respun for release? There's already been the start of discussion around an Extras rebuild before final... the main reason we pick test2 as a stake in the ground for Core is just due to how Core is tested and released being somewhat different from the rolling nature of Extras. Jeremy From Matt_Domsch at dell.com Sun Jul 9 20:42:02 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 9 Jul 2006 15:42:02 -0500 Subject: obsolete dependencies on libsysfs.so.1 Message-ID: <20060709204202.GA18609@lists.us.dell.com> Core no longer contains libsysfs.so.1. The following packages currently in -development have dependencies on this library. This causes these apps to fail to upgrade (I noticed this as kdebase requires lm_sensors which requires libsysfs.so.1 thus that upgrade failed; there are other failure paths as well of course...). Core: cpufreq-utils-002-1.1.37 device-mapper-multipath-0.4.7-2.0 lm_sensors-2.10.0-2 (BZ #198055 filed) openhpi-2.4.1-4 Extras: directfb-0.9.24-5.fc5 (BZ #198111 filed) libibverbs-1.0.3-1.fc6 libibverbs-utils-1.0.3-1.fc6 Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dwmw2 at infradead.org Sun Jul 9 22:18:32 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 09 Jul 2006 23:18:32 +0100 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <20060709204202.GA18609@lists.us.dell.com> References: <20060709204202.GA18609@lists.us.dell.com> Message-ID: <1152483512.3018.16.camel@pmac.infradead.org> On Sun, 2006-07-09 at 15:42 -0500, Matt Domsch wrote: > Core no longer contains libsysfs.so.1. The following packages > currently in -development have dependencies on this library. This > causes these apps to fail to upgrade (I noticed this as kdebase > requires lm_sensors which requires libsysfs.so.1 thus that upgrade > failed; there are other failure paths as well of course...). > > Core: > cpufreq-utils-002-1.1.37 > device-mapper-multipath-0.4.7-2.0 > lm_sensors-2.10.0-2 (BZ #198055 filed) > openhpi-2.4.1-4 Your list is missing iprutils. -- dwmw2 From Matt_Domsch at dell.com Sun Jul 9 23:00:44 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 9 Jul 2006 18:00:44 -0500 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <1152483512.3018.16.camel@pmac.infradead.org> References: <20060709204202.GA18609@lists.us.dell.com> <1152483512.3018.16.camel@pmac.infradead.org> Message-ID: <20060709230044.GB18609@lists.us.dell.com> On Sun, Jul 09, 2006 at 11:18:32PM +0100, David Woodhouse wrote: > On Sun, 2006-07-09 at 15:42 -0500, Matt Domsch wrote: > > Core no longer contains libsysfs.so.1. The following packages > > currently in -development have dependencies on this library. This > > causes these apps to fail to upgrade (I noticed this as kdebase > > requires lm_sensors which requires libsysfs.so.1 thus that upgrade > > failed; there are other failure paths as well of course...). > > > > Core: > > cpufreq-utils-002-1.1.37 > > device-mapper-multipath-0.4.7-2.0 > > lm_sensors-2.10.0-2 (BZ #198055 filed) > > openhpi-2.4.1-4 > > Your list is missing iprutils. indeed, and bridge-utils. I hadn't realized these were being caught by the daily rawhide report, and that for Core, package maintainers get auto-spammed by same. I went and filed bugs though against those in my last message that didn't have bugs filed. What's the Core equivalent of Extras' owners/owners.list? Each of the tools that's generating Core+Extras stats could make use of such to identify package owneres too. Thanks, Mat -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dwmw2 at infradead.org Mon Jul 10 10:18:36 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 10 Jul 2006 11:18:36 +0100 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <20060709230044.GB18609@lists.us.dell.com> References: <20060709204202.GA18609@lists.us.dell.com> <1152483512.3018.16.camel@pmac.infradead.org> <20060709230044.GB18609@lists.us.dell.com> Message-ID: <1152526716.3373.16.camel@pmac.infradead.org> On Sun, 2006-07-09 at 18:00 -0500, Matt Domsch wrote: > indeed, and bridge-utils. Nah, I updated and rebuilt bridge-utils yesterday. Actually, I think I _asked_ for sysfsutils to be updated a few weeks ago so that I could update bridge-utils, because by chance I happened to noticed that the autocrap stuff in new bridge-utils silently builds tools for a 2.4 kernel if you don't have sysfsutils-2.0.0. But I thought the answer was "not this late in the cycle", so I was vaguely surprised to see it change without getting any further email on the subject other than the dependency nag. > What's the Core equivalent of Extras' owners/owners.list? Each of the > tools that's generating Core+Extras stats could make use of such to > identify package owneres too. Er, not sure. I think bugzilla and/or brew has a list but I'm not sure how to access it. -- dwmw2 From mattdm at mattdm.org Mon Jul 10 16:40:51 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 10 Jul 2006 12:40:51 -0400 Subject: bugzilla issue: my bulk-change powers foiled! [was Re: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060707180935.GA17747@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> Message-ID: <20060710164051.GA27655@jadzia.bu.edu> On Fri, Jul 07, 2006 at 02:09:35PM -0400, Matthew Miller wrote: > As I did with FC2 long ago, I'm going to go through and mark all open FC3 > bugs as "needinfo". This is a last-ditch attempt to make sure any of those > that really need to be addressed by Fedora Legacy get the attention they > need, and that anything still open that's still an issue in current releases > doesn't get lost forever. Hmmm. I am foiled: Not allowed You tried to change the Priority field from normal to --do_not_change--, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field. I don't think that the problem here is that I'm not "sufficiently empowered", but rather that it's not properly reading the magic "--do_not_change--" value. Can someone fix this? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Jul 10 17:10:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Jul 2006 13:10:17 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) Message-ID: <200607101310.17402.jkeating@redhat.com> libtool stuff got accepted upstream so the mass rebuild will start tomorrow (after a maint window that effects one of our build arches). Let the good times roll. BTW, Core folks, if you don't want me to rebuild your package, let me know by then (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jul 10 17:22:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Jul 2006 13:22:05 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607101310.17402.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> Message-ID: <200607101322.05453.jkeating@redhat.com> On Monday 10 July 2006 13:10, Jesse Keating wrote: > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > (after a maint window that effects one of our build arches). ?Let the good > times roll. Er, not libtool, but rather binutils, linker and glibc improvements for much faster dynamic lib loading. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Jul 10 19:11:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:11:52 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607101322.05453.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> Message-ID: <20060710191152.GD13423@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Monday 10 July 2006 13:10, Jesse Keating wrote: > > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > > (after a maint window that effects one of our build arches). ?Let the good > > times roll. > > Er, not libtool, but rather binutils, linker and glibc improvements for much > faster dynamic lib loading. Is there a particular period where binutils exists for building such that packages built then (say, today) don't need rebuilt? Bill From jakub at redhat.com Mon Jul 10 19:17:45 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 10 Jul 2006 15:17:45 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <20060710191152.GD13423@nostromo.devel.redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> <20060710191152.GD13423@nostromo.devel.redhat.com> Message-ID: <20060710191745.GF3115@devserv.devel.redhat.com> On Mon, Jul 10, 2006 at 03:11:52PM -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > On Monday 10 July 2006 13:10, Jesse Keating wrote: > > > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > > > (after a maint window that effects one of our build arches). ?Let the good > > > times roll. > > > > Er, not libtool, but rather binutils, linker and glibc improvements for much > > faster dynamic lib loading. > > Is there a particular period where binutils exists for building such that packages > built then (say, today) don't need rebuilt? Not yet. Jakub From dkl at redhat.com Mon Jul 10 19:19:48 2006 From: dkl at redhat.com (David Lawrence) Date: Mon, 10 Jul 2006 15:19:48 -0400 Subject: bugzilla issue: my bulk-change powers foiled! [was Re: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060710164051.GA27655@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060710164051.GA27655@jadzia.bu.edu> Message-ID: <44B2A854.6000508@redhat.com> I think I may have this fixed now. Can you try to reproduce the problem? Dave Matthew Miller wrote: > On Fri, Jul 07, 2006 at 02:09:35PM -0400, Matthew Miller wrote: >> As I did with FC2 long ago, I'm going to go through and mark all open FC3 >> bugs as "needinfo". This is a last-ditch attempt to make sure any of those >> that really need to be addressed by Fedora Legacy get the attention they >> need, and that anything still open that's still an issue in current releases >> doesn't get lost forever. > > > Hmmm. > > I am foiled: > > Not allowed > > You tried to change the Priority field from normal to --do_not_change--, > but only the owner or submitter of the bug, or a sufficiently empowered > user, may change that field. > > I don't think that the problem here is that I'm not "sufficiently > empowered", but rather that it's not properly reading the magic > "--do_not_change--" value. Can someone fix this? > > > > -- David Lawrence, RHCE dkl at redhat.com ------------------------------------ Red Hat, Inc. Web: www.redhat.com 1801 Varsity Drive Raleigh, NC 27606 From mattdm at mattdm.org Mon Jul 10 19:54:36 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 10 Jul 2006 15:54:36 -0400 Subject: bugzilla issue: my bulk-change powers foiled! [was Re: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <44B2A854.6000508@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060710164051.GA27655@jadzia.bu.edu> <44B2A854.6000508@redhat.com> Message-ID: <20060710195436.GA4101@jadzia.bu.edu> On Mon, Jul 10, 2006 at 03:19:48PM -0400, David Lawrence wrote: > I think I may have this fixed now. Can you try to reproduce the problem? Works now -- thanks. Before I go and do the big bulk change, lemme ask you this: is it problematic at all from a technical point of view for me to make a change to ~1100 bugs through the web interface? Or would it be better done with some behind-the-scenes magic? Or smaller batches? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dkl at redhat.com Mon Jul 10 19:59:12 2006 From: dkl at redhat.com (David Lawrence) Date: Mon, 10 Jul 2006 15:59:12 -0400 Subject: bugzilla issue: my bulk-change powers foiled! [was Re: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060710195436.GA4101@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060710164051.GA27655@jadzia.bu.edu> <44B2A854.6000508@redhat.com> <20060710195436.GA4101@jadzia.bu.edu> Message-ID: <44B2B190.20703@redhat.com> Any change is always better using the UI for couple reasons. One, it does proper email notification if the change is important to others, and two it updates all of the different activity tables so that proper history is maintained. It is possible to do some changes from a script or direct db access but then you have to remember to update all of the other places that need it as well and not just the values in the main bugs table. I have thought about adding a checkbox to the multiple bug edit form that will essentially disable email notifications for those who just want to make a simple change but generate unnecessary spam. But that functionality is not there yet. Dave Matthew Miller wrote: > On Mon, Jul 10, 2006 at 03:19:48PM -0400, David Lawrence wrote: >> I think I may have this fixed now. Can you try to reproduce the problem? > > Works now -- thanks. > > Before I go and do the big bulk change, lemme ask you this: is it > problematic at all from a technical point of view for me to make a change to > ~1100 bugs through the web interface? Or would it be better done with some > behind-the-scenes magic? Or smaller batches? > -- David Lawrence, RHCE dkl at redhat.com ------------------------------------ Red Hat, Inc. Web: www.redhat.com 1801 Varsity Drive Raleigh, NC 27606 From jakub at redhat.com Mon Jul 10 20:11:21 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 10 Jul 2006 16:11:21 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607101322.05453.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> Message-ID: <20060710201121.GH3115@devserv.devel.redhat.com> On Mon, Jul 10, 2006 at 01:22:05PM -0400, Jesse Keating wrote: > On Monday 10 July 2006 13:10, Jesse Keating wrote: > > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > > (after a maint window that effects one of our build arches). ?Let the good > > times roll. > > Er, not libtool, but rather binutils, linker and glibc improvements for much > faster dynamic lib loading. The binutils side is already approved and we are just polishing the binutils and glibc patches now, should take just a few hours. But there is a question how to enable this and what defaults should be used, and that's something where wider input is desirable. Just a quick note what changed: In ELF, .hash section (with DT_HASH dynamic tag pointing to it) is used during dynamic linking for symbol lookup, the dynamic linker for each symbol it needs to resolve uses that section to map it to a set of symbol indexes of possible symbol definitions. We wrote changes that introduce a new section (.gnu.hash, DT_GNU_HASH dynamic tag) that serves the same purpose, but is much more efficient (gives far fewer symbol definition candidates and uses far fewer cachelines). The dynamic linker in glibc will, starting with tomorrow's build, use DT_GNU_HASH if it exist and fallback to DT_HASH if it does not. ld has new option, --hash-style: --hash-style=sysv (the default) creates just the old .hash section (i.e. no change from current behavior) --hash-style=both creates both .hash and .gnu.hash section (advantage is that libraries/binaries linked with this option can be used both with any dynamic linker and the new one will be able to use the optimized .gnu.hash section). Disadvantage is that it wastes disk space and more importantly memory in the apps (although the mapping is just read-only, it still occupies address space, etc.). --hash-style=gnu creates just the .gnu.hash section and not .hash. Such binaries or shared libraries can be only used with the new glibc dynamic linker. Now, I think it would be good to use --hash-style=gnu in most of our packages, after all, during FC5 rebuilt everything was built with -fstack-protector and therefore basically all packages rely on libc.so.6(GLIBC_2.4) and can't be used on older distros either. One exception perhaps should be libraries dlopened by statically linked binaries (so, essentially a subset of glibc libraries and nss_* package shared libraries). The question is, should that be the default gcc enforces for everybody (i.e. if you compile your own proglet in FC6, is it ok if it only has .gnu.hash section and not .hash?) or should that be only selected from redhat-rpm-config passed flags? Also, I guess we should add Provides: ld-linux.so.2(GNU_HASH) (and similar for other arch dynamic linkers) to glibc that supports this and for packages built with --hash-style=gnu (i.e. if they have DT_GNU_HASH dynamic tag and not DT_HASH) automatically add the corresponding Requires. Jakub From mattdm at mattdm.org Mon Jul 10 20:12:26 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 10 Jul 2006 16:12:26 -0400 Subject: bugzilla issue: my bulk-change powers foiled! [was Re: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <44B2B190.20703@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060710164051.GA27655@jadzia.bu.edu> <44B2A854.6000508@redhat.com> <20060710195436.GA4101@jadzia.bu.edu> <44B2B190.20703@redhat.com> Message-ID: <20060710201226.GA5645@jadzia.bu.edu> On Mon, Jul 10, 2006 at 03:59:12PM -0400, David Lawrence wrote: > Any change is always better using the UI for couple reasons. One, it > does proper email notification if the change is important to others, and > two it updates all of the different activity tables so that proper > history is maintained. It is possible to do some changes from a script > or direct db access but then you have to remember to update all of the > other places that need it as well and not just the values in the main > bugs table. I have thought about adding a checkbox to the multiple bug > edit form that will essentially disable email notifications for those > who just want to make a simple change but generate unnecessary spam. But > that functionality is not there yet. Okay, just making sure. I actually _want_ to generate a bunch of messages with this. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Jul 10 20:16:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Jul 2006 16:16:39 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <20060710201121.GH3115@devserv.devel.redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> <20060710201121.GH3115@devserv.devel.redhat.com> Message-ID: <200607101616.42859.jkeating@redhat.com> On Monday 10 July 2006 16:11, Jakub Jelinek wrote: > Now, I think it would be good to use --hash-style=gnu in most of our > packages, after all, during FC5 rebuilt everything was built with > -fstack-protector and therefore basically all packages rely on > libc.so.6(GLIBC_2.4) and can't be used on older distros either. > One exception perhaps should be libraries dlopened by statically linked > binaries (so, essentially a subset of glibc libraries and nss_* package > shared libraries). > > The question is, should that be the default gcc enforces for everybody > (i.e. if you compile your own proglet in FC6, is it ok if it only has > .gnu.hash section and not .hash?) or should that be only selected from > redhat-rpm-config passed flags? > > Also, I guess we should add > Provides: ld-linux.so.2(GNU_HASH) > (and similar for other arch dynamic linkers) to glibc that supports this > and for packages built with --hash-style=gnu (i.e. if they have > DT_GNU_HASH dynamic tag and not DT_HASH) automatically add the > corresponding Requires. I think my opinion is to make it the default to use gnu hashing. If a user wants to build for other releases, they really should be using a chroot anyway, but they can add the linker option. If our packages we're pulling into the tree don't work with the gnu has, well those packages need to be updated. Plain and simple. We can't let old compatibility stand in the way of progress (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caolanm at redhat.com Tue Jul 11 11:17:05 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 11 Jul 2006 12:17:05 +0100 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607101322.05453.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> Message-ID: <1152616626.2628.18.camel@soulcrusher.caolan.org> On Mon, 2006-07-10 at 13:22 -0400, Jesse Keating wrote: > On Monday 10 July 2006 13:10, Jesse Keating wrote: > > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > > (after a maint window that effects one of our build arches). Let the good > > times roll. > > Er, not libtool, but rather binutils, linker and glibc improvements for much > faster dynamic lib loading. Leave OOo for me, I'll take the opportunity to wedge in a few minor fixes. C. From mattdm at mattdm.org Tue Jul 11 17:18:46 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 13:18:46 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060707180935.GA17747@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> Message-ID: <20060711171846.GA17627@jadzia.bu.edu> On Fri, Jul 07, 2006 at 02:09:35PM -0400, Matthew Miller wrote: > As I did with FC2 long ago, I'm going to go through and mark all open FC3 > bugs as "needinfo". This is a last-ditch attempt to make sure any of those > that really need to be addressed by Fedora Legacy get the attention they > need, and that anything still open that's still an issue in current releases > doesn't get lost forever. So, this seems to be going pretty well. Of the 1100+ bugs, only two angry responses about how the bug should have been fixed long ago, and quite a lot of helpful action. So, I'm going to go and get the 148 FC1 bugs still open, which I never did. That should be pretty straightforward -- I'll add the note that Legacy isn't going to be doing FC1 for much longer either. *Then*, there's the question of _before_ that. There's 1051 bugs in open states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. Obviously a lot of that isn't going to be helpful or interesting after all these years -- and RHL9 is finally going out of Legacy support too. However, it's possible that there's some overlooked important/useful/still-relevant reports that would still apply to Fedora or RHEL. Does it seem worth it to stir this up? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Jul 11 17:27:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 13:27:01 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711171846.GA17627@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> Message-ID: <200607111327.01506.jkeating@redhat.com> On Tuesday 11 July 2006 13:18, Matthew Miller wrote: > *Then*, there's the question of _before_ that. There's 1051 bugs in open > states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. > Obviously a lot of that isn't going to be helpful or interesting after all > these years -- and RHL9 is finally going out of Legacy support too. > However, it's possible that there's some overlooked > important/useful/still-relevant reports that would still apply to Fedora or > RHEL. > > Does it seem worth it to stir this up? My feeling is that once Legacy stops support for RHL (seems we decided later this year) that all the bugs could be closed WONTFIX. If it doesn't come from a paying RH customer through RHEL support, it most likely won't get looked at for a RHEL update, and Fedora has moved so far beyond that it doesn't really matter. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Tue Jul 11 17:24:30 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 11 Jul 2006 11:24:30 -0600 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711171846.GA17627@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> Message-ID: <80d7e4090607111024r13f98ebcve879c037148f7802@mail.gmail.com> On 7/11/06, Matthew Miller wrote: > On Fri, Jul 07, 2006 at 02:09:35PM -0400, Matthew Miller wrote: > > As I did with FC2 long ago, I'm going to go through and mark all open FC3 > > bugs as "needinfo". This is a last-ditch attempt to make sure any of those > > that really need to be addressed by Fedora Legacy get the attention they > > need, and that anything still open that's still an issue in current releases > > doesn't get lost forever. > > So, this seems to be going pretty well. Of the 1100+ bugs, only two angry > responses about how the bug should have been fixed long ago, and quite a lot > of helpful action. > > So, I'm going to go and get the 148 FC1 bugs still open, which I never did. > That should be pretty straightforward -- I'll add the note that Legacy isn't > going to be doing FC1 for much longer either. > > *Then*, there's the question of _before_ that. There's 1051 bugs in open > states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. > Obviously a lot of that isn't going to be helpful or interesting after all > these years -- and RHL9 is finally going out of Legacy support too. However, > it's possible that there's some overlooked important/useful/still-relevant > reports that would still apply to Fedora or RHEL. > > Does it seem worth it to stir this up? > Yes.. I did one of these back in 2001 where I went through the first 3000 tickets to see what was still available. A lot of the things were still outstanding (I have 2 bugs in NEW state from RHL9 that may still occur or were feature requests). I would go with a 30-60 day NEEDINFO -> CLOSED. IF the problem is still around and can be reproduced or the person hasnt changed to Ubuntu because something hasnt had its state changed in 5 years... then it should be managed from above after that. -- Stephen J Smoogen. CSIRT/Linux System Administrator From sundaram at fedoraproject.org Tue Jul 11 17:24:39 2006 From: sundaram at fedoraproject.org (Rahul) Date: Tue, 11 Jul 2006 22:54:39 +0530 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711171846.GA17627@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> Message-ID: <44B3DED7.6020702@fedoraproject.org> Matthew Miller wrote: > On Fri, Jul 07, 2006 at 02:09:35PM -0400, Matthew Miller wrote: >> As I did with FC2 long ago, I'm going to go through and mark all open FC3 >> bugs as "needinfo". This is a last-ditch attempt to make sure any of those >> that really need to be addressed by Fedora Legacy get the attention they >> need, and that anything still open that's still an issue in current releases >> doesn't get lost forever. > > So, this seems to be going pretty well. Of the 1100+ bugs, only two angry > responses about how the bug should have been fixed long ago, and quite a lot > of helpful action. > Good to know that you got helpful responses. Were the ones that got a angry response critical ones? > So, I'm going to go and get the 148 FC1 bugs still open, which I never did. > That should be pretty straightforward -- I'll add the note that Legacy isn't > going to be doing FC1 for much longer either. > > *Then*, there's the question of _before_ that. There's 1051 bugs in open > states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. > Obviously a lot of that isn't going to be helpful or interesting after all > these years -- and RHL9 is finally going out of Legacy support too. However, > it's possible that there's some overlooked important/useful/still-relevant > reports that would still apply to Fedora or RHEL. > > Does it seem worth it to stir this up? I would say close them all and let people reopen it if any of it still applies to a currently maintained version of Fedora and/REHL . RHEL bugs are better deal with through the formal support channels though. Rahul From smooge at gmail.com Tue Jul 11 17:27:40 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 11 Jul 2006 11:27:40 -0600 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607111327.01506.jkeating@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <200607111327.01506.jkeating@redhat.com> Message-ID: <80d7e4090607111027w5d669569qe25cb4bd5b1b0134@mail.gmail.com> On 7/11/06, Jesse Keating wrote: > On Tuesday 11 July 2006 13:18, Matthew Miller wrote: > > *Then*, there's the question of _before_ that. There's 1051 bugs in open > > states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. > > Obviously a lot of that isn't going to be helpful or interesting after all > > these years -- and RHL9 is finally going out of Legacy support too. > > However, it's possible that there's some overlooked > > important/useful/still-relevant reports that would still apply to Fedora or > > RHEL. > > > > Does it seem worth it to stir this up? > > My feeling is that once Legacy stops support for RHL (seems we decided later > this year) that all the bugs could be closed WONTFIX. If it doesn't come > from a paying RH customer through RHEL support, it most likely won't get > looked at for a RHEL update, and Fedora has moved so far beyond that it > doesn't really matter. > I think that is sort of letting whoever didn't 'look' at it inside of RH lightly. Some of those 'bugs' were feature requests and such that were looked as being useful at one point for a future release.. A WONTFIX could be the wrong answer in those cases. I think the NEED_INFO -> WONTFIX / Relabel to more accurate info would be better. [With the relabel being the person who opened the ticket if their email address is still accurate etc.] -- Stephen J Smoogen. CSIRT/Linux System Administrator From jkeating at redhat.com Tue Jul 11 17:49:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 13:49:02 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607101310.17402.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> Message-ID: <200607111349.02819.jkeating@redhat.com> On Monday 10 July 2006 13:10, Jesse Keating wrote: > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > (after a maint window that effects one of our build arches). ?Let the good > times roll. > > BTW, Core folks, if you don't want me to rebuild your package, let me know > by then (: We're just waiting on glibc and rpm to finish, so that we can build gcc. Once GCC is built and hits the buildroots I'll begin the mass build. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jul 11 17:49:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 13:49:09 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <44B3DED7.6020702@fedoraproject.org> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <44B3DED7.6020702@fedoraproject.org> Message-ID: <20060711174909.GA18513@jadzia.bu.edu> On Tue, Jul 11, 2006 at 10:54:39PM +0530, Rahul wrote: > Good to know that you got helpful responses. Were the ones that got a > angry response critical ones? Actually only one is overtly angry. The other is merely simmering. The angry one is bug #144592, and the report is about odd behavior in nautilus. Not a solid bug report, but it would have been good for it to have gotten a quick triage reply. The second (bug #141587) is about a coding error in evolution-data-server, which probably also should have gotten the quick reply "good catch; this should be fixed upstream". [re: rhl9 and before] > I would say close them all and let people reopen it if any of it still > applies to a currently maintained version of Fedora and/REHL . RHEL bugs > are better deal with through the formal support channels though. I think I'd do the NEEDINFO thing and maybe close in 60 days. Although maybe it'd be nice if someone @redhat.com did the actual closing? Do you have any particular wording I should use about the formal support channels for RHEL? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jul 11 17:54:26 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 13:54:26 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607111327.01506.jkeating@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <200607111327.01506.jkeating@redhat.com> Message-ID: <20060711175426.GA19646@jadzia.bu.edu> On Tue, Jul 11, 2006 at 01:27:01PM -0400, Jesse Keating wrote: > My feeling is that once Legacy stops support for RHL (seems we decided later > this year) that all the bugs could be closed WONTFIX. If it doesn't come Jesse, is this schedule documented in a table somewhere? I couldn't find it. (Also, could maybe http://fedoralegacy.org be made to redirect into the fedoraproject.org wiki?) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Jul 11 18:18:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 14:18:11 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711175426.GA19646@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <200607111327.01506.jkeating@redhat.com> <20060711175426.GA19646@jadzia.bu.edu> Message-ID: <200607111418.11734.jkeating@redhat.com> On Tuesday 11 July 2006 13:54, Matthew Miller wrote: > Jesse, is this schedule documented in a table somewhere? I couldn't find > it. > > (Also, could maybe http://fedoralegacy.org be made to redirect into the > fedoraproject.org wiki?) We haven't documented it. The proposal was made at an IRC meeting and I forwarded it to the fedora-legacy list and was giving it a week to stew. Fedora Core 1 and Fedora Core 2 go EOL (dropped by us) when we pick up Fedora Core 4. This follows our stated lifespan policy. RHL7.3/9 get a staged death: New issues (bugs) will be accepted until October 1st. No new bugs after that mark. Existing bugs will be resolved by Dec 31st or never resolved. So far I've not seen any real negative reactions to this schedule. As far as the wiki, yes, I plan on moving some / all of fedoralegacy.org over to fedoraproject.org. Both wiki content and some stuff in Plone CMS. But that's a later task, after getting things like CVS working, and plague, and publishing to the fedora updates directories, and.. and.. and... (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jul 11 18:16:20 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 14:16:20 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711174909.GA18513@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <44B3DED7.6020702@fedoraproject.org> <20060711174909.GA18513@jadzia.bu.edu> Message-ID: <20060711181620.GA20856@jadzia.bu.edu> On Tue, Jul 11, 2006 at 01:49:09PM -0400, Matthew Miller wrote: > > Good to know that you got helpful responses. Were the ones that got a > > angry response critical ones? > Actually only one is overtly angry. The other is merely simmering. The angry > one is bug #144592, and the report is about odd behavior in nautilus. Not a > solid bug report, but it would have been good for it to have gotten a quick > triage reply. The second (bug #141587) is about a coding error in > evolution-data-server, which probably also should have gotten the quick > reply "good catch; this should be fixed upstream". Oh, also: bug #156201. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Tue Jul 11 18:28:16 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 11 Jul 2006 13:28:16 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines Message-ID: <1152642496.12430.232.camel@localhost.localdomain> The following Fedora Core packages from development (rawhide-20060711) are in violation of the Fedora Package Naming Guidelines. There are undoubtedly other packages in violation, but these are the most egregious that I could identify: Uses incorrect dist tag ======================== anacron-2.3-38.FC6.src.rpm avahi-0.6.10-3.FC6.src.rpm bind-9.3.2-26.FC6.src.rpm dhcdbd-1.15-1.FC6.src.rpm dmraid-1.0.0.rc11-FC6.src.rpm gdb-6.3.0.0-1.132.FC6.src.rpm lftp-3.4.7-2.FC6.src.rpm perl-DBD-MySQL-3.0004-1.FC6.src.rpm perl-DBD-Pg-1.49-1.FC6.src.rpm perl-String-CRC32-1.4-1.FC6.src.rpm perl-XML-Dumper-0.81-1.FC6.src.rpm python-2.4.3-11.FC6.src.rpm system-config-bind-4.0.0-41_FC6.src.rpm system-config-lvm-1.0.18-1.2.FC6.src.rpm system-config-netboot-0.1.41-1.FC6.src.rpm tog-pegasus-2.5.1-10.FC6.src.rpm vixie-cron-4.1-55.FC6.src.rpm xterm-213-1.FC6.src.rpm Uses invalid release (Release value starts at 1, not 0) ======================================================= cairo-java-1.0.4-0.src.rpm frysk-0.0.1.2006.06.28.rh1-0.src.rpm glib-java-0.2.5-0.src.rpm libglade-java-2.12.4-0.src.rpm libgnome-java-2.12.3-0.src.rpm libgtk-java-2.8.5-0.src.rpm libvte-java-0.12.0-0.src.rpm ypbind-1.19-0.src.rpm ypserv-2.19-0.src.rpm yp-tools-2.9-0.src.rpm Invalid non-numeric characters in release ========================================== adaptx-0.9.6-1jpp_3fc.1.src.rpm ant-1.6.5-1jpp_9fc.src.rpm antlr-2.7.4-2jpp_6fc.src.rpm avalon-framework-4.1.4-2jpp_9fc.src.rpm avalon-logkit-1.2-3jpp_3fc.src.rpm axis-1.2.1-2jpp_2fc.src.rpm bcel-5.1-1jpp_6fc.src.rpm bsf-2.3.0-6jpp_4fc.src.rpm bsh-1.3.0-5jpp_1fc.1.1.src.rpm castor-0.9.5-1jpp_4fc.src.rpm classpathx-jaf-1.0-2jpp_5fc.src.rpm classpathx-mail-1.0-4jpp_5fc.src.rpm concurrent-1.3.2-2jpp_2fc.src.rpm cryptix-3.2.0-4jpp_3fc.src.rpm cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm eclipse-3.2.0-1jpp_1fc.src.rpm eclipse-cdt-3.1.0-1jpp_1fc.src.rpm geronimo-specs-1.0-0.M2.2jpp_7fc.src.rpm gnu-crypto-2.1.0-1jpp_2fc.src.rpm gnu.getopt-1.0.9-4jpp_4fc.src.rpm hsqldb-1.80.1-1jpp_9fc.src.rpm jakarta-commons-beanutils-1.7.0-2jpp_6fc.src.rpm jakarta-commons-codec-1.3-2jpp_4fc.src.rpm jakarta-commons-collections-3.1-2jpp_5fc.src.rpm jakarta-commons-daemon-1.0-2jpp_4fc.src.rpm jakarta-commons-dbcp-1.2.1-3jpp_3fc.src.rpm jakarta-commons-digester-1.7-2jpp_10fc.src.rpm jakarta-commons-discovery-0.3-1jpp_3fc.src.rpm jakarta-commons-el-1.0-5jpp_1fc.src.rpm jakarta-commons-fileupload-1.0-3jpp_5fc.src.rpm jakarta-commons-httpclient-3.0-0.rc2.0jpp_4fc.src.rpm jakarta-commons-lang-2.0-2jpp_4fc.src.rpm jakarta-commons-launcher-0.9-3jpp_3fc.src.rpm jakarta-commons-logging-1.0.4-2jpp_10fc.src.rpm jakarta-commons-modeler-1.1-4jpp_6fc.src.rpm jakarta-commons-pool-1.2-2jpp_4fc.src.rpm jakarta-commons-validator-1.1.4-1jpp_5fc.src.rpm jakarta-taglibs-standard-1.1.1-4jpp_5fc.src.rpm java-1.4.2-gcj-compat-1.4.2.0-40jpp_87rh.src.rpm javacc-3.2-1jpp_6fc.src.rpm java_cup-0.10-0.k.1jpp_9fc.src.rpm jdepend-2.6-2jpp_4fc.1.1.src.rpm jdom-1.0-1jpp_5fc.src.rpm jgroups-2.2.6-1jpp_4fc.src.rpm jlex-1.2.6-1jpp_3fc.src.rpm jpackage-utils-1.6.6-1jpp_2rh.src.rpm jrefactory-2.8.9-3jpp_1fc.1.1.src.rpm jsch-0.1.28-1jpp_1fc.src.rpm junit-3.8.1-3jpp_7fc.src.rpm jzlib-1.0.5-2jpp_2fc.src.rpm ldapjdk-4.17-1jpp_3fc.1.1.src.rpm libtheora-1.0alpha5-1.2.1.src.rpm log4j-1.2.8-7jpp_8fc.src.rpm lucene-1.4.3-1jpp_11fc.src.rpm mockobjects-0.09-12jpp_4fc.src.rpm mx4j-3.0.1-1jpp_9fc.src.rpm oro-2.0.8-1jpp_4fc.src.rpm postgresql-jdbc-8.1.407-1jpp.src.rpm puretls-0.9-0.b4.1jpp_4fc.src.rpm regexp-1.3-2jpp_7fc.src.rpm struts-1.2.8-2jpp_12fc.src.rpm tanukiwrapper-3.1.1-4jpp_7fc.src.rpm tomcat5-5.5.17-3jpp_1fc.src.rpm velocity-1.4-3jpp_4fc.src.rpm werken.xpath-0.9.4-0.beta.9jpp_3fc.src.rpm wsdl4j-1.5.1-1jpp_4fc.src.rpm xalan-j2-2.6.0-3jpp_9fc.src.rpm xdoclet-1.2.2-2jpp_6fc.src.rpm xerces-j2-2.7.1-6jpp_7fc.src.rpm xjavadoc-1.1-1jpp_5fc.src.rpm xml-commons-1.3.02-0.b2.7jpp_7fc.src.rpm xml-commons-resolver-1.1-1jpp_8fc.src.rpm xmlrpc-2.0.1-1jpp_8fc.src.rpm xorg-x11-xkbdata-1.0.1-8.xkbc0.8.0.src.rpm xorg-x11-drv-i810-1.6.0-6.modeset20060707.src.rpm Bad CVS naming (cvs should be at end of date, not beginning) ============================================================ krb5-auth-dialog-0.6.cvs20060212-3.src.rpm NetworkManager-0.7.0-0.cvs20060529.1.src.rpm Bad alpha naming (should be e.g. foo-1.8.1-0.1.alpha9) ======================================================= cdparanoia-alpha9.8-27.1.src.rpm libtheora-1.0alpha5-1.2.1.src.rpm perl-XML-Grove-0.46alpha-29.1.src.rpm Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5) ===================================================== aqbanking-1.8.1beta-5.src.rpm autofs-5.0.0_beta6-5.src.rpm dovecot-1.0-0.beta8.2.src.rpm werken.xpath-0.9.4-0.beta.9jpp_3fc.src.rpm Invalid use of underscore ========================== adaptx-0.9.6-1jpp_3fc.1.src.rpm ant-1.6.5-1jpp_9fc.src.rpm antlr-2.7.4-2jpp_6fc.src.rpm autofs-5.0.0_beta6-5.src.rpm avalon-framework-4.1.4-2jpp_9fc.src.rpm avalon-logkit-1.2-3jpp_3fc.src.rpm axis-1.2.1-2jpp_2fc.src.rpm bcel-5.1-1jpp_6fc.src.rpm bsf-2.3.0-6jpp_4fc.src.rpm bsh-1.3.0-5jpp_1fc.1.1.src.rpm castor-0.9.5-1jpp_4fc.src.rpm classpathx-jaf-1.0-2jpp_5fc.src.rpm classpathx-mail-1.0-4jpp_5fc.src.rpm concurrent-1.3.2-2jpp_2fc.src.rpm cryptix-3.2.0-4jpp_3fc.src.rpm cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm eclipse-3.2.0-1jpp_1fc.src.rpm eclipse-cdt-3.1.0-1jpp_1fc.src.rpm eclipse-changelog-2.1.0_fc-1.src.rpm eclipse-pydev-0.9.3_fc-15.src.rpm geronimo-specs-1.0-0.M2.2jpp_7fc.src.rpm gnu-crypto-2.1.0-1jpp_2fc.src.rpm gnu.getopt-1.0.9-4jpp_4fc.src.rpm hsqldb-1.80.1-1jpp_9fc.src.rpm jakarta-commons-beanutils-1.7.0-2jpp_6fc.src.rpm jakarta-commons-codec-1.3-2jpp_4fc.src.rpm jakarta-commons-collections-3.1-2jpp_5fc.src.rpm jakarta-commons-daemon-1.0-2jpp_4fc.src.rpm jakarta-commons-dbcp-1.2.1-3jpp_3fc.src.rpm jakarta-commons-digester-1.7-2jpp_10fc.src.rpm jakarta-commons-discovery-0.3-1jpp_3fc.src.rpm jakarta-commons-el-1.0-5jpp_1fc.src.rpm jakarta-commons-fileupload-1.0-3jpp_5fc.src.rpm jakarta-commons-httpclient-3.0-0.rc2.0jpp_4fc.src.rpm jakarta-commons-lang-2.0-2jpp_4fc.src.rpm jakarta-commons-launcher-0.9-3jpp_3fc.src.rpm jakarta-commons-logging-1.0.4-2jpp_10fc.src.rpm jakarta-commons-modeler-1.1-4jpp_6fc.src.rpm jakarta-commons-pool-1.2-2jpp_4fc.src.rpm jakarta-commons-validator-1.1.4-1jpp_5fc.src.rpm jakarta-taglibs-standard-1.1.1-4jpp_5fc.src.rpm java-1.4.2-gcj-compat-1.4.2.0-40jpp_87rh.src.rpm javacc-3.2-1jpp_6fc.src.rpm java_cup-0.10-0.k.1jpp_9fc.src.rpm jdepend-2.6-2jpp_4fc.1.1.src.rpm jdom-1.0-1jpp_5fc.src.rpm jgroups-2.2.6-1jpp_4fc.src.rpm jlex-1.2.6-1jpp_3fc.src.rpm jpackage-utils-1.6.6-1jpp_2rh.src.rpm jrefactory-2.8.9-3jpp_1fc.1.1.src.rpm jsch-0.1.28-1jpp_1fc.src.rpm junit-3.8.1-3jpp_7fc.src.rpm jzlib-1.0.5-2jpp_2fc.src.rpm ldapjdk-4.17-1jpp_3fc.1.1.src.rpm linuxwacom-0.7.4_1-2.src.rpm log4j-1.2.8-7jpp_8fc.src.rpm lucene-1.4.3-1jpp_11fc.src.rpm mockobjects-0.09-12jpp_4fc.src.rpm mod_perl-2.0.2-6.src.rpm mod_python-3.2.8-3.src.rpm mx4j-3.0.1-1jpp_9fc.src.rpm nss_db-2.2-35.src.rpm nss_ldap-250-5.src.rpm oro-2.0.8-1jpp_4fc.src.rpm puretls-0.9-0.b4.1jpp_4fc.src.rpm regexp-1.3-2jpp_7fc.src.rpm salinfo-0.5-1.11_FC5.src.rpm struts-1.2.8-2jpp_12fc.src.rpm system-config-bind-4.0.0-41_FC6.src.rpm tanukiwrapper-3.1.1-4jpp_7fc.src.rpm tomcat5-5.5.17-3jpp_1fc.src.rpm velocity-1.4-3jpp_4fc.src.rpm webalizer-2.01_10-30.src.rpm werken.xpath-0.9.4-0.beta.9jpp_3fc.src.rpm wsdl4j-1.5.1-1jpp_4fc.src.rpm xalan-j2-2.6.0-3jpp_9fc.src.rpm xdoclet-1.2.2-2jpp_6fc.src.rpm xerces-j2-2.7.1-6jpp_7fc.src.rpm xjavadoc-1.1-1jpp_5fc.src.rpm xml-commons-1.3.02-0.b2.7jpp_7fc.src.rpm xml-commons-resolver-1.1-1jpp_8fc.src.rpm xmlrpc-2.0.1-1jpp_8fc.src.rpm ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Tue Jul 11 18:32:21 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 14:32:21 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607111418.11734.jkeating@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <200607111327.01506.jkeating@redhat.com> <20060711175426.GA19646@jadzia.bu.edu> <200607111418.11734.jkeating@redhat.com> Message-ID: <20060711183221.GA21517@jadzia.bu.edu> On Tue, Jul 11, 2006 at 02:18:11PM -0400, Jesse Keating wrote: > We haven't documented it. The proposal was made at an IRC meeting and I > forwarded it to the fedora-legacy list and was giving it a week to stew. Yeah, I actually saw the post there but was unclear on the result of the stewing. > As far as the wiki, yes, I plan on moving some / all of fedoralegacy.org over > to fedoraproject.org. Both wiki content and some stuff in Plone CMS. But > that's a later task, after getting things like CVS working, and plague, and > publishing to the fedora updates directories, and.. and.. and... (: I've had several people make comments to me (not as part of the current bugzilla project) based on misinformation from the old page. I wonder it'd just be best to make a big redirect _now_.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Jul 11 18:51:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 14:51:45 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711183221.GA21517@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <200607111418.11734.jkeating@redhat.com> <20060711183221.GA21517@jadzia.bu.edu> Message-ID: <200607111451.45952.jkeating@redhat.com> On Tuesday 11 July 2006 14:32, Matthew Miller wrote: > I've had several people make comments to me (not as part of the current > bugzilla project) based on misinformation from the old page. I wonder it'd > just be best to make a big redirect _now_.... If somebody is volunteering their time to do it, and make sure that the redirect goes to good information, I'm not going to stop them. I just have none of that fabled 'spare time' myself (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jul 11 18:51:57 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 14:51:57 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607111451.45952.jkeating@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <200607111418.11734.jkeating@redhat.com> <20060711183221.GA21517@jadzia.bu.edu> <200607111451.45952.jkeating@redhat.com> Message-ID: <20060711185157.GA22611@jadzia.bu.edu> On Tue, Jul 11, 2006 at 02:51:45PM -0400, Jesse Keating wrote: > > I've had several people make comments to me (not as part of the current > > bugzilla project) based on misinformation from the old page. I wonder it'd > > just be best to make a big redirect _now_.... > If somebody is volunteering their time to do it, and make sure that the > redirect goes to good information, I'm not going to stop them. I just have > none of that fabled 'spare time' myself (: The current wiki is better information that fedoralegacy.org, which says "Parse error: parse error in /data/web/warren/html/header.html on line 1" and then some other outdated information. Can we find someone to make the spare time to make the one-line apache config change to redirect everything? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Jul 11 19:00:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 15:00:54 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711185157.GA22611@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <200607111451.45952.jkeating@redhat.com> <20060711185157.GA22611@jadzia.bu.edu> Message-ID: <200607111500.55071.jkeating@redhat.com> On Tuesday 11 July 2006 14:51, Matthew Miller wrote: > The current wiki is better information that fedoralegacy.org, which says > "Parse error: parse error in /data/web/warren/html/header.html on line 1" > and then some other outdated information. > > Can we find someone to make the spare time to make the one-line apache > config change to redirect everything? :) My web box had critical hardware failure, I thought fedoralegacy.org was working. I'm now on a new host, and it looks like I'm missing some xml packages so that apache can grok it. Let me fix that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jul 11 19:14:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 15:14:16 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607111500.55071.jkeating@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711185157.GA22611@jadzia.bu.edu> <200607111500.55071.jkeating@redhat.com> Message-ID: <200607111514.21182.jkeating@redhat.com> On Tuesday 11 July 2006 15:00, Jesse Keating wrote: > On Tuesday 11 July 2006 14:51, Matthew Miller wrote: > > The current wiki is better information that fedoralegacy.org, which says > > "Parse error: parse error in /data/web/warren/html/header.html on line 1" > > and then some other outdated information. > > > > Can we find someone to make the spare time to make the one-line apache > > config change to redirect everything? :) > > My web box had critical hardware failure, I thought fedoralegacy.org was > working. ?I'm now on a new host, and it looks like I'm missing some xml > packages so that apache can grok it. ?Let me fix that. Ok, look now. There is some information that is not duplicated yet, such as the advisories pages (although they are outdated). What we really need is for somebody to compare fedoralegacy.org webpages to counterparts in the wiki, and make a list of things that aren't duplicated so that we have a task list of what to create so that we CAN do the redirect. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jul 11 19:21:56 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 15:21:56 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607111514.21182.jkeating@redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711185157.GA22611@jadzia.bu.edu> <200607111500.55071.jkeating@redhat.com> <200607111514.21182.jkeating@redhat.com> Message-ID: <20060711192156.GA28987@jadzia.bu.edu> On Tue, Jul 11, 2006 at 03:14:16PM -0400, Jesse Keating wrote: > Ok, look now. Yeah, so now it's not broken, just horribly misleading. :) :) :) (I know all about spare time, so I'm not saying this in an antagonistic way, I promise!) > There is some information that is not duplicated yet, such as the advisories > pages (although they are outdated). > What we really need is for somebody to compare fedoralegacy.org webpages to > counterparts in the wiki, and make a list of things that aren't duplicated so > that we have a task list of what to create so that we CAN do the redirect. *nod* Anyone else want to volunteer? Otherwise I'll take a look at it after my current project (and probably after OLS). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Tue Jul 11 19:27:35 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 12 Jul 2006 00:57:35 +0530 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711192156.GA28987@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711185157.GA22611@jadzia.bu.edu> <200607111500.55071.jkeating@redhat.com> <200607111514.21182.jkeating@redhat.com> <20060711192156.GA28987@jadzia.bu.edu> Message-ID: <44B3FBA7.1030301@fedoraproject.org> Hi >> There is some information that is not duplicated yet, such as the advisories >> pages (although they are outdated). >> What we really need is for somebody to compare fedoralegacy.org webpages to >> counterparts in the wiki, and make a list of things that aren't duplicated so >> that we have a task list of what to create so that we CAN do the redirect. > > *nod* > > Anyone else want to volunteer? Otherwise I'll take a look at it after my > current project (and probably after OLS). > I will do that tomorrow. Rahul From stickster at gmail.com Tue Jul 11 20:13:04 2006 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 11 Jul 2006 16:13:04 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <20060710201121.GH3115@devserv.devel.redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> <20060710201121.GH3115@devserv.devel.redhat.com> Message-ID: <1152648784.1484.200.camel@localhost.localdomain> On Mon, 2006-07-10 at 16:11 -0400, Jakub Jelinek wrote: > On Mon, Jul 10, 2006 at 01:22:05PM -0400, Jesse Keating wrote: > > On Monday 10 July 2006 13:10, Jesse Keating wrote: > > > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > > > (after a maint window that effects one of our build arches). Let the good > > > times roll. > > > > Er, not libtool, but rather binutils, linker and glibc improvements for much > > faster dynamic lib loading. > > The binutils side is already approved and we are just polishing the binutils > and glibc patches now, should take just a few hours. > > But there is a question how to enable this and what defaults should be used, > and that's something where wider input is desirable. > > Just a quick note what changed: [...snip...] Jakub, If at all humanly possible, please do one of two things with this kind of information, which is important enough for release notes. In order of preference: 1. Edit the Docs/Beats for the appropriate area -- in this case the DevelTools beat -- or contact the Beats maintainer with the appropriate info. Don't worry about style nitpicking, we take care of that in editorial sessions. 2. Use the '*docs*' keyword in your commit message -- a neat trick we've had in effect for about a year that alerts the Docs team to information that is relnotes-worthy. We are grabbing this information for the Beats since they're going to XML for translation today to make test2 release. Thanks! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 jmoyer at redhat.com Tue Jul 11 21:13:21 2006 From: jmoyer at redhat.com (Jeff Moyer) Date: Tue, 11 Jul 2006 17:13:21 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152642496.12430.232.camel@localhost.localdomain> (Tom Callaway's message of "Tue, 11 Jul 2006 13:28:16 -0500") References: <1152642496.12430.232.camel@localhost.localdomain> Message-ID: ==> Regarding Core Packages in Violation of the Fedora Naming Guidelines; "Tom 'spot' Callaway" adds: tcallawa> The following Fedora Core packages from development (rawhide-20060711) tcallawa> are in violation of the Fedora Package Naming Guidelines. There are tcallawa> undoubtedly other packages in violation, but these are the most tcallawa> egregious that I could identify: tcallawa> Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5) tcallawa> ===================================================== tcallawa> autofs-5.0.0_beta6-5.src.rpm The upstream package is named autofs-5.0.0_betaX. You can't impose Fedora naming conventions on upstream packages. -Jeff From tcallawa at redhat.com Tue Jul 11 21:18:10 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 11 Jul 2006 16:18:10 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> Message-ID: <1152652690.12430.250.camel@localhost.localdomain> On Tue, 2006-07-11 at 17:13 -0400, Jeff Moyer wrote: > ==> Regarding Core Packages in Violation of the Fedora Naming Guidelines; "Tom 'spot' Callaway" adds: > > tcallawa> The following Fedora Core packages from development (rawhide-20060711) > tcallawa> are in violation of the Fedora Package Naming Guidelines. There are > tcallawa> undoubtedly other packages in violation, but these are the most > tcallawa> egregious that I could identify: > > tcallawa> Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5) > tcallawa> ===================================================== > tcallawa> autofs-5.0.0_beta6-5.src.rpm > > The upstream package is named autofs-5.0.0_betaX. You can't impose Fedora > naming conventions on upstream packages. The tarball can be named goldfishrule.tar.gz for all Fedora cares. The versioning and release numbering for the RPM package is where we have standards. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From katzj at redhat.com Tue Jul 11 21:31:22 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 11 Jul 2006 17:31:22 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> Message-ID: <1152653482.6394.1.camel@aglarond.local> On Tue, 2006-07-11 at 17:13 -0400, Jeff Moyer wrote: > ==> Regarding Core Packages in Violation of the Fedora Naming Guidelines; "Tom 'spot' Callaway" adds: > tcallawa> Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5) > tcallawa> ===================================================== > tcallawa> autofs-5.0.0_beta6-5.src.rpm > > The upstream package is named autofs-5.0.0_betaX. You can't impose Fedora > naming conventions on upstream packages. The upstream tarball can be named based on whatever upstream wants to smoke. But by versioning the package this way, there isn't an upgrade path from 5.0.0 beta to 5.0.0 final unless you a) add an epoch or b) do something silly like autofs-5.0.0_final. Jeremy From jmoyer at redhat.com Tue Jul 11 22:54:44 2006 From: jmoyer at redhat.com (Jeff Moyer) Date: Tue, 11 Jul 2006 18:54:44 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152653482.6394.1.camel@aglarond.local> (Jeremy Katz's message of "Tue, 11 Jul 2006 17:31:22 -0400") References: <1152642496.12430.232.camel@localhost.localdomain> <1152653482.6394.1.camel@aglarond.local> Message-ID: ==> Regarding Re: Core Packages in Violation of the Fedora Naming Guidelines; Jeremy Katz adds: katzj> On Tue, 2006-07-11 at 17:13 -0400, Jeff Moyer wrote: >> ==> Regarding Core Packages in Violation of the Fedora Naming Guidelines; "Tom 'spot' Callaway" adds: tcallawa> Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5) tcallawa> ===================================================== tcallawa> autofs-5.0.0_beta6-5.src.rpm >> >> The upstream package is named autofs-5.0.0_betaX. You can't impose Fedora >> naming conventions on upstream packages. katzj> The upstream tarball can be named based on whatever upstream wants to katzj> smoke. But by versioning the package this way, there isn't an upgrade katzj> path from 5.0.0 beta to 5.0.0 final unless you a) add an epoch or b) do katzj> something silly like autofs-5.0.0_final. Yeah, thanks for pointing this out. How do you suggest this gets fixed moving forward, then? -Jeff From tibbs at math.uh.edu Tue Jul 11 23:18:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 11 Jul 2006 18:18:27 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: (Jeff Moyer's message of "Tue, 11 Jul 2006 18:54:44 -0400") References: <1152642496.12430.232.camel@localhost.localdomain> <1152653482.6394.1.camel@aglarond.local> Message-ID: >>>>> "JM" == Jeff Moyer writes: JM> Yeah, thanks for pointing this out. How do you suggest this gets JM> fixed moving forward, then? Why not just fix the name? Updates involving the test releases aren't supported anyway. - J< From sundaram at fedoraproject.org Tue Jul 11 23:22:45 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 12 Jul 2006 04:52:45 +0530 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <1152653482.6394.1.camel@aglarond.local> Message-ID: <44B432C5.5030405@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "JM" == Jeff Moyer writes: > > JM> Yeah, thanks for pointing this out. How do you suggest this gets > JM> fixed moving forward, then? > > Why not just fix the name? Updates involving the test releases aren't > supported anyway. > Not supported but its definitely useful to fix and we would avoid getting a number of threads on the same topic a few days later. Rahul From tcallawa at redhat.com Tue Jul 11 23:56:10 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 11 Jul 2006 18:56:10 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <17588.10023.637464.36766@localhost.redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> Message-ID: <1152662171.12430.317.camel@localhost.localdomain> On Tue, 2006-07-11 at 18:33 -0400, Elena Zannoni wrote: > I suspect RHN will get very confused if these changes are not made > correctly. Can you please address each of the categories with the > correct way to do the naming? I.e, what does incorrect distro tag > mean, and what would be the right way to do it. BTW I doubt that we > can fix these for FC6t2. (speaking for the tools ones) What's the > impact of fixing this stuff later? Tossing this back on the list, as I know others will have the same questions. Some of these items might need epoch changes. I'll describe the specifics: > > Uses incorrect dist tag > > ======================== > > anacron-2.3-38.FC6.src.rpm The "all caps" hardcoded dist tag is wrong. Instead, you should use %{?dist} to let the buildsystem (both plague and brew support this) determine what the distribution tag is. It will fill in %{dist} with .fc6, for example. The dist tag bits are documented here: http://fedoraproject.org/wiki/DistTag Hardcoding the value for the dist tag is no longer allowed, since the buildsystem can do it for you. So, for example: > > gdb-6.3.0.0-1.132.FC6.src.rpm With the proper dist tag usage, this package becomes: gdb-6.3.0.0-1.132.fc6.src.rpm Inside the spec, you'd see: Release: 1.132%{?dist} rpm thinks that fc6 > FC6, so there should be no update issues in remedying this. > > Uses invalid release (Release value starts at 1, not 0) > > ======================================================= This one should be pretty straightforward. Don't use Release: 0. Start at 1. > > cairo-java-1.0.4-0.src.rpm To fix this package, all you need to do is bump the release number to 1. cairo-java-1.0.4-1.src.rpm > > Invalid non-numeric characters in release > > ========================================== The Fedora rules are pretty straightforward about non-numeric characters in the Release field. Unless it is a pre-release package (alpha/beta) or a snapshot release (cvs/svn), then you cannot put non-numeric characters into the release field. To fix these packages, the most obvious way is to strip out all the junk that is in the Release field after the initial number, then increment that number. The only exception to this rule is for the dist tag, and you have to use %{?dist} in the release field as documented. (after the integer, with nothing else after it). I highly encourage that you use integers in the Release field, and not whole numbers (e.g. use 3, not 3.206), because that is the best way to confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to run out of integers anytime soon. Also, unless you're following the snapshot rules, don't put dates in the Release field. The full set of rules, with examples, are here: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease So, some examples: > > adaptx-0.9.6-1jpp_3fc.1.src.rpm Fixed: adaptx-0.9.6-2.src.rpm Fixed (with dist tag): adaptx-0.9.6-2.fc6.src.rpm > > xorg-x11-xkbdata-1.0.1-8.xkbc0.8.0.src.rpm Fixed: xorg-x11-xkbdata-1.0.1-9.src.rpm Fixed (with dist tag): xorg-x11-xkbdata-1.0.1-9.fc6.src.rpm > > Bad CVS naming (cvs should be at end of date, not beginning) > > ============================================================ CVS falls under the snapshot rules. To handle snapshots, first identify, is this a pre-release, or a post-release? > > krb5-auth-dialog-0.6.cvs20060212-3.src.rpm I'll assume this is a pre-release, and that 0.6 has yet to be released. In this case, this package should be fixed as: Fixed: krb5-auth-dialog-0.6-0.7.20060212cvs.src.rpm Fixed (with dist tag): krb5-auth-dialog-0.6-0.7.20060212cvs.fc6.src.rpm If you need to patch a pre-release or put in a new cvs checkout, you bump the non-zero integer in the Release field, but LEAVE THE ZERO AS ZERO. This is important. Unfortunately, this is a case where conforming to the guidelines will require a one-time epoch bump in the new package, since rpm thinks that 0.6.cvs20060212-3 is newer than 0.6. Now, when 0.6 actually releases, you release a new package like: Fixed: krb5-auth-dialog-0.6-1.src.rpm Fixed (with dist tag): krb5-auth-dialog-0.6-1.fc6.src.rpm > > NetworkManager-0.7.0-0.cvs20060529.1.src.rpm I'll assume this is a post-release snapshot. Something that has come out after 0.7.0, but I don't know if the next release will be 0.7.1 or not. At some point in time, there was a: NetworkManager-0.7.0-1.src.rpm The post release package would then look like: Fixed: NetworkManager-0.7.0-2.20060529cvs.src.rpm Fixed (with dist tag): NetworkManager-0.7.0-2.20060529cvs.fc6.src.rpm Now, with post release packages, you should make sure that you keep incrementing that first integer field as you make changes. So, if you make a newer cvs checkout, say 20060611, then you'd get: Fixed: NetworkManager-0.7.0-3.20060611cvs.src.rpm Fixed (with dist tag): NetworkManager-0.7.0-3.20060611cvs.fc6.src.rpm Only when you increment the Version field, should you reset the Release back to 1. (or fail to increment it) Example: Fixed: NetworkManager-0.7.1-1.src.rpm Fixed (with dist tag): NetworkManager-0.7.1-1.fc6.src.rpm > > Bad alpha naming (should be e.g. foo-1.8.1-0.1.alpha9) > > ======================================================= Alphas are pre-releases. Even if something has been in alpha for eons. > > cdparanoia-alpha9.8-27.1.src.rpm Fixed, this becomes: Fixed: cdparanoia-9.8-0.28.alpha.src.rpm Fixed (with dist tag): cdparanoia-9.8-0.28.alpha.fc6.src.rpm Doesn't require an epoch bump. > > libtheora-1.0alpha5-1.2.1.src.rpm Fixed: libtheora-1.0-0.2.alpha5.src.rpm Fixed (with dist tag): libtheora-1.0-0.2.alpha5.fc6.src.rpm Requires a one-time epoch bump. > > perl-XML-Grove-0.46alpha-29.1.src.rpm Fixed: perl-XML-Grove-0.46-0.30.alpha.src.rpm Fixed (with dist tag): perl-XML-Grove-0.46-0.30.alpha.fc6.src.rpm Requires a one-time epoch bump. > > Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5) > > ===================================================== Same logic and naming scheme as alpha. > > aqbanking-1.8.1beta-5.src.rpm Fixed: aqbanking-1.8.1-0.6.beta.src.rpm Fixed (with dist tag): aqbanking-1.8.1-0.6.beta.fc6.src.rpm Requires a one-time epoch bump. > > autofs-5.0.0_beta6-5.src.rpm Fixed: autofs-5.0.0-0.6.beta6.src.rpm Fixed (with dist tag): autofs-5.0.0-0.6.beta6.fc6.src.rpm Requires a one-time epoch bump. > > Invalid use of underscore > > ========================== Underscores are not valid delimiters for any field, unless they are in the name. This is documented here: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NormalPackages > > adaptx-0.9.6-1jpp_3fc.1.src.rpm This package also has all sorts of non-numeric addon fun. We fixed him above, but just to reillustrate: Fixed: adaptx-0.9.6-2.src.rpm Fixed (with dist tag): adaptx-0.9.6-2.fc6.src.rpm > > eclipse-changelog-2.1.0_fc-1.src.rpm This guy looks like he just needs a proper dist tag: Fixed (with dist tag): eclipse-changelog-2.1.0-2.fc6.src.rpm It also needs a one-time epoch bump, since rpm thinks that 2.1.0_fc > 2.1.0. Why are we making everyone follow these rules? So that we avoid pain, confusion, and having to make rpm cry. (Everytime I think about RPM now, I think about Meatwad from Aqua Teen Hunger Force) These rules ensure clean, predictable upgrades, and the ability to look at a package and easily determine key information about it. Is it a pre-release? Did it come from a CVS checkout? All of the Naming Guidelines are here: http://fedoraproject.org/wiki/Packaging/NamingGuidelines If you're not sure if you need to bump the epoch when you make the change, use fedora-rpmvercmp. It's in the fedora-rpmdevtools package, and it will let you compare a Epoch:Version-Release to another Epoch:Version-Release, and tell you what rpm thinks is greater. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From katzj at redhat.com Wed Jul 12 01:24:57 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 11 Jul 2006 21:24:57 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152662171.12430.317.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> Message-ID: <1152667497.2860.15.camel@aglarond.local> On Tue, 2006-07-11 at 18:56 -0500, Tom 'spot' Callaway wrote: > > > Uses incorrect dist tag > > > ======================== > > > anacron-2.3-38.FC6.src.rpm > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > %{?dist} to let the buildsystem (both plague and brew support this) > determine what the distribution tag is. It will fill in %{dist} > with .fc6, for example. The dist tag bits are documented here: > http://fedoraproject.org/wiki/DistTag > > Hardcoding the value for the dist tag is no longer allowed, since the > buildsystem can do it for you. I thought that things allowed hardcoding as long as you used the "right" value. Granted, doing so is probably kind of silly, but forcing syntactic sugar is also overkill Jeremy From mattdm at mattdm.org Wed Jul 12 02:25:25 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 11 Jul 2006 22:25:25 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152667497.2860.15.camel@aglarond.local> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> Message-ID: <20060712022525.GA19221@jadzia.bu.edu> On Tue, Jul 11, 2006 at 09:24:57PM -0400, Jeremy Katz wrote: > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > %{?dist} to let the buildsystem (both plague and brew support this) > > determine what the distribution tag is. It will fill in %{dist} > > with .fc6, for example. The dist tag bits are documented here: > > http://fedoraproject.org/wiki/DistTag > > Hardcoding the value for the dist tag is no longer allowed, since the > > buildsystem can do it for you. > I thought that things allowed hardcoding as long as you used the "right" > value. Granted, doing so is probably kind of silly, but forcing > syntactic sugar is also overkill Also, 'cause sometimes maybe your spec file _is_ specifically for that release for some reason, and it's too different for a bunch of %ifs to make sense? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Jul 12 04:28:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 00:28:07 -0400 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607111349.02819.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607111349.02819.jkeating@redhat.com> Message-ID: <200607120028.11093.jkeating@redhat.com> On Tuesday 11 July 2006 13:49, Jesse Keating wrote: > We're just waiting on glibc and rpm to finish, so that we can build gcc. > ?Once GCC is built and hits the buildroots I'll begin the mass build. gcc just finished building. I'm waiting for it to show up in the buildroots so I can start throwing builds at it. A weee bit later than I wanted to start this, but that's software (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed Jul 12 05:27:08 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 00:27:08 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152667497.2860.15.camel@aglarond.local> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> Message-ID: <1152682028.12430.325.camel@localhost.localdomain> On Tue, 2006-07-11 at 21:24 -0400, Jeremy Katz wrote: > On Tue, 2006-07-11 at 18:56 -0500, Tom 'spot' Callaway wrote: > > > > Uses incorrect dist tag > > > > ======================== > > > > anacron-2.3-38.FC6.src.rpm > > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > %{?dist} to let the buildsystem (both plague and brew support this) > > determine what the distribution tag is. It will fill in %{dist} > > with .fc6, for example. The dist tag bits are documented here: > > http://fedoraproject.org/wiki/DistTag > > > > Hardcoding the value for the dist tag is no longer allowed, since the > > buildsystem can do it for you. > > I thought that things allowed hardcoding as long as you used the "right" > value. Granted, doing so is probably kind of silly, but forcing > syntactic sugar is also overkill Ehh. The standard says no, because: - Its easy to get it wrong. - It leads to things like .fc5 packages in the devel branch - It opens the door to arguments like "if i can hardcode .fc6, why can't I hardcode .omg.wtf.bbq also" ? ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Wed Jul 12 05:27:39 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 00:27:39 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712022525.GA19221@jadzia.bu.edu> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> Message-ID: <1152682059.12430.327.camel@localhost.localdomain> On Tue, 2006-07-11 at 22:25 -0400, Matthew Miller wrote: > On Tue, Jul 11, 2006 at 09:24:57PM -0400, Jeremy Katz wrote: > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > > %{?dist} to let the buildsystem (both plague and brew support this) > > > determine what the distribution tag is. It will fill in %{dist} > > > with .fc6, for example. The dist tag bits are documented here: > > > http://fedoraproject.org/wiki/DistTag > > > Hardcoding the value for the dist tag is no longer allowed, since the > > > buildsystem can do it for you. > > I thought that things allowed hardcoding as long as you used the "right" > > value. Granted, doing so is probably kind of silly, but forcing > > syntactic sugar is also overkill > > Also, 'cause sometimes maybe your spec file _is_ specifically for that > release for some reason, and it's too different for a bunch of %ifs to make > sense? Even in those cases, %{dist} will always be correct. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From n0dalus+redhat at gmail.com Wed Jul 12 05:39:09 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 12 Jul 2006 15:09:09 +0930 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <20060710201121.GH3115@devserv.devel.redhat.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> <20060710201121.GH3115@devserv.devel.redhat.com> Message-ID: <6280325c0607112239w8238749seaafb49ef79cd55d@mail.gmail.com> On 7/11/06, Jakub Jelinek wrote: > > Just a quick note what changed: > In ELF, .hash section (with DT_HASH dynamic tag pointing to it) is used > during dynamic linking for symbol lookup, the dynamic linker for each symbol > it needs to resolve uses that section to map it to a set of symbol indexes > of possible symbol definitions. > > We wrote changes that introduce a new section (.gnu.hash, DT_GNU_HASH > dynamic tag) that serves the same purpose, but is much more efficient > (gives far fewer symbol definition candidates and uses far fewer > cachelines). > Is this for speeding up building or does this speed up program startup? How much faster is using .gnu.hash over .hash? Just curious, n0dalus. From tagoh at redhat.com Wed Jul 12 05:56:16 2006 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 12 Jul 2006 14:56:16 +0900 (JST) Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <200607101310.17402.jkeating@redhat.com> References: <200607101310.17402.jkeating@redhat.com> Message-ID: <20060712.145616.-1474626277.tagoh@redhat.com> >>>>> On Mon, 10 Jul 2006 13:10:17 -0400, >>>>> "JK" == Jesse Keating wrote: JK> libtool stuff got accepted upstream so the mass rebuild will start tomorrow JK> (after a maint window that effects one of our build arches). Let the good JK> times roll. JK> BTW, Core folks, if you don't want me to rebuild your package, let me know by JK> then (: the mass rebuild script seems to not like a dist tag ;) and I suspect -1.1.fc6 isn't greater than -1.fc6. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Wed Jul 12 06:34:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 08:34:20 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152682059.12430.327.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> Message-ID: <20060712083420.3d6e60ad.bugs.michael@gmx.net> On Wed, 12 Jul 2006 00:27:39 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-07-11 at 22:25 -0400, Matthew Miller wrote: > > On Tue, Jul 11, 2006 at 09:24:57PM -0400, Jeremy Katz wrote: > > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > > > %{?dist} to let the buildsystem (both plague and brew support this) > > > > determine what the distribution tag is. It will fill in %{dist} > > > > with .fc6, for example. The dist tag bits are documented here: > > > > http://fedoraproject.org/wiki/DistTag > > > > Hardcoding the value for the dist tag is no longer allowed, since the > > > > buildsystem can do it for you. > > > I thought that things allowed hardcoding as long as you used the "right" > > > value. Granted, doing so is probably kind of silly, but forcing > > > syntactic sugar is also overkill > > > > Also, 'cause sometimes maybe your spec file _is_ specifically for that > > release for some reason, and it's too different for a bunch of %ifs to make > > sense? > > Even in those cases, %{dist} will always be correct. In the resulting binaries, yes, but not in the .spec file. As the package maintainer, you don't want to be confused by seeing %{?dist} and assuming it is a valid spec for multiple dists when in fact it is not. This avoids mistakes during mass-updates to your package branches. Using %{?dist} must not be mandatory. Hardcoding the value %{dist} would expand to is justified in some cases. From nicolas.mailhot at laposte.net Wed Jul 12 06:53:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 08:53:28 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152662171.12430.317.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> Message-ID: <1152687209.5821.1.camel@rousalka.dyndns.org> Le mardi 11 juillet 2006 ? 18:56 -0500, Tom 'spot' Callaway a ?crit : > Fixed: adaptx-0.9.6-2.src.rpm > Fixed (with dist tag): adaptx-0.9.6-2.fc6.src.rpm Actually all the java packages need some sort of alphatag-like convention to indicate what JPackage package they're derived from. I agree the current convention of the Java team is rather ugly, but the reasons it's there are real reasons. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Wed Jul 12 07:00:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 12 Jul 2006 09:00:24 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712083420.3d6e60ad.bugs.michael@gmx.net> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> Message-ID: <1152687624.4569.77.camel@mccallum.corsepiu.local> On Wed, 2006-07-12 at 08:34 +0200, Michael Schwendt wrote: > On Wed, 12 Jul 2006 00:27:39 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2006-07-11 at 22:25 -0400, Matthew Miller wrote: > > > On Tue, Jul 11, 2006 at 09:24:57PM -0400, Jeremy Katz wrote: > > > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > > > > %{?dist} to let the buildsystem (both plague and brew support this) > > > > > determine what the distribution tag is. It will fill in %{dist} > > > > > with .fc6, for example. The dist tag bits are documented here: > > > > > http://fedoraproject.org/wiki/DistTag > > > > > Hardcoding the value for the dist tag is no longer allowed, since the > > > > > buildsystem can do it for you. > > > > I thought that things allowed hardcoding as long as you used the "right" > > > > value. Granted, doing so is probably kind of silly, but forcing > > > > syntactic sugar is also overkill > > > > > > Also, 'cause sometimes maybe your spec file _is_ specifically for that > > > release for some reason, and it's too different for a bunch of %ifs to make > > > sense? > > > > Even in those cases, %{dist} will always be correct. > > In the resulting binaries, yes, but not in the .spec file. As the package > maintainer, you don't want to be confused by seeing %{?dist} and assuming > it is a valid spec for multiple dists when in fact it is not. As a maintainer you see one spec-file per-distro in CVS. > This avoids > mistakes during mass-updates to your package branches. How that? As a maintainer you have one spec-file per-distro, whether %{?dist} is present or not doesn't imply anything on whether a spec is buildable for a different distro. Using it, however has advantages for specs, which are designed to be shared across different distros. > Using %{?dist} must not be mandatory. Hardcoding the value %{dist} would > expand to is justified in some cases. IMO, you are drawing invalid conclusions. Ralf From bugs.michael at gmx.net Wed Jul 12 10:45:08 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 12:45:08 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152687624.4569.77.camel@mccallum.corsepiu.local> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> Message-ID: <20060712124508.90cf6c79.bugs.michael@gmx.net> On Wed, 12 Jul 2006 09:00:24 +0200, Ralf Corsepius wrote: > As a maintainer you see one spec-file per-distro in CVS. Many packagers keep a single spec file for all dist releases. During updates/upgrades they copy the modified spec to all branches. That's called a mass-update. On the contrary, there are packagers (also in Core) who maintain separate branches with distinct spec files. Even during version upgrades, when they upgrade an older branch to the same version as released for newer branches, they do not want to lose old %changelog details and hence do not want to copy spec files to multiple branches. Additionally, if they want to express that the [source] package is for a specific dist release, it is perfectly fine and appropriate when they hardcode a distribution tag in the package release field. > > This avoids > > mistakes during mass-updates to your package branches. > > How that? As a maintainer you have one spec-file per-distro, whether > %{?dist} is present or not doesn't imply anything on whether a spec is > buildable for a different distro. %{?dist} is a variable, giving the false impression that the source package may be valid for arbitrary dist releases and that filling it in would be enough and that no other package updates are required. Even worse, the dist tag enters the file names of the built packages. > Using it, however has advantages for specs, which are designed to be > shared across different distros. That is an optional minor advantage, not a mandatory advantage. ;) > > Using %{?dist} must not be mandatory. Hardcoding the value %{dist} would > > expand to is justified in some cases. > > IMO, you are drawing invalid conclusions. Fine. I can live with that. IMO it is short-sighted if packagers are not permitted to hardcode a dist tag where appropriate. Btw, the %{?dist} as we use it remains insufficient for CD/DVD release-based distribution upgrades anyway. It gives a false impression of upgrade-path safety. And unfortunately, RPM doesn't offer a DistRelease Epoch which would fix the situation. From bugs.michael at gmx.net Wed Jul 12 10:48:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 12:48:26 +0200 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <20060712.145616.-1474626277.tagoh@redhat.com> References: <200607101310.17402.jkeating@redhat.com> <20060712.145616.-1474626277.tagoh@redhat.com> Message-ID: <20060712124826.3c0fb829.bugs.michael@gmx.net> On Wed, 12 Jul 2006 14:56:16 +0900 (JST), Akira TAGOH wrote: > JK> libtool stuff got accepted upstream so the mass rebuild will start tomorrow > JK> (after a maint window that effects one of our build arches). Let the good > JK> times roll. > > JK> BTW, Core folks, if you don't want me to rebuild your package, let me know by > JK> then (: > > the mass rebuild script seems to not like a dist tag ;) > and I suspect -1.1.fc6 isn't greater than -1.fc6. It is. All numbers are greater than all letters: 1 > f From mattdm at mattdm.org Wed Jul 12 10:58:08 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 06:58:08 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152682028.12430.325.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <1152682028.12430.325.camel@localhost.localdomain> Message-ID: <20060712105808.GA2908@jadzia.bu.edu> On Wed, Jul 12, 2006 at 12:27:08AM -0500, Tom 'spot' Callaway wrote: > Ehh. The standard says no, because: > - Its easy to get it wrong. > - It leads to things like .fc5 packages in the devel branch This could be considered *good*. Then it is obvious that the package needs fixing. But alternately, how about "one can hardcode the disttag in old releases only?" That's where it makes more sense for the case I'm suggesting, anyway. > - It opens the door to arguments like "if i can hardcode .fc6, why can't > I hardcode .omg.wtf.bbq also" ? I can't? Damn. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Wed Jul 12 11:20:32 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Jul 2006 07:20:32 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152682028.12430.325.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <1152682028.12430.325.camel@localhost.localdomain> Message-ID: <1152703232.2860.48.camel@aglarond.local> On Wed, 2006-07-12 at 00:27 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-07-11 at 21:24 -0400, Jeremy Katz wrote: > > On Tue, 2006-07-11 at 18:56 -0500, Tom 'spot' Callaway wrote: > > > > > Uses incorrect dist tag > > > > > ======================== > > > > > anacron-2.3-38.FC6.src.rpm > > > > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > > %{?dist} to let the buildsystem (both plague and brew support this) > > > determine what the distribution tag is. It will fill in %{dist} > > > with .fc6, for example. The dist tag bits are documented here: > > > http://fedoraproject.org/wiki/DistTag > > > > > > Hardcoding the value for the dist tag is no longer allowed, since the > > > buildsystem can do it for you. > > > > I thought that things allowed hardcoding as long as you used the "right" > > value. Granted, doing so is probably kind of silly, but forcing > > syntactic sugar is also overkill > > Ehh. The standard says no, because: I know for a fact when I originally, grudgingly gave in on the %{?dist} issue, that we did *not* have it like this. Unfortunately, as pages moved around, my subscriptions to get wiki-spam lapsed :( > - Its easy to get it wrong. This is a reason why you _have_ convenience things -- it's hardly an excuse to force them down people's throats. That's like saying "because rm is easy to get wrong, we're going to require you to confirm all deletes". Sure, we set things up so that you get that as a convenience, but unalias rm or rm -f let you do what you want. > - It leads to things like .fc5 packages in the devel branch ... and you still have .fc5 packages if people don't rebuild. > - It opens the door to arguments like "if i can hardcode .fc6, why can't > I hardcode .omg.wtf.bbq also" ? Because .omg.wtf.bbq isn't the distribution which is (one of) the reasons for non-numerics in the release tag. I don't really see this as a real reason either. Jeremy From nicolas.mailhot at laposte.net Wed Jul 12 11:30:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 13:30:42 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712124508.90cf6c79.bugs.michael@gmx.net> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> Message-ID: <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 12:45, Michael Schwendt a ?crit : > %{?dist} is a variable, giving the false impression that the source > package may be valid for arbitrary dist releases and that filling it in > would be enough and that no other package updates are required. Even > worse, the dist tag enters the file names of the built packages. If you know your package will break on another release because foo package was updated and changed its behaviour, you should require or BR foo with the right version (and yes I know it does not work right now but that's what versionned requires were there for). Blocking on distro version is utterly misleading as FE for example is very dynamic but even very static releases like RHEL do have incompatible updates every one in a while (5 years is a long time, can't froze all the major versions when there is a big problem) -- Nicolas Mailhot From jkeating at redhat.com Wed Jul 12 11:53:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 07:53:07 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152687209.5821.1.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <1152662171.12430.317.camel@localhost.localdomain> <1152687209.5821.1.camel@rousalka.dyndns.org> Message-ID: <200607120753.07602.jkeating@redhat.com> On Wednesday 12 July 2006 02:53, Nicolas Mailhot wrote: > Actually all the java packages need some sort of alphatag-like > convention to indicate what JPackage package they're derived from. I > agree the current convention of the Java team is rather ugly, but the > reasons it's there are real reasons. You've told us they need it, but haven't told us _why_ they need it. I don't buy this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Jul 12 11:56:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 06:56:35 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607120753.07602.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152662171.12430.317.camel@localhost.localdomain> <1152687209.5821.1.camel@rousalka.dyndns.org> <200607120753.07602.jkeating@redhat.com> Message-ID: <44B4E373.2080004@math.unl.edu> Jesse Keating wrote: > On Wednesday 12 July 2006 02:53, Nicolas Mailhot wrote: > >>Actually all the java packages need some sort of alphatag-like >>convention to indicate what JPackage package they're derived from. I >>agree the current convention of the Java team is rather ugly, but the >>reasons it's there are real reasons. > > > You've told us they need it, but haven't told us _why_ they need it. I don't > buy this. The "why" is that the they'd like to indicate in the Release tag the "Release" of the JPackage.org equivalent that it was derived from. -- Rex From nicolas.mailhot at laposte.net Wed Jul 12 12:02:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 14:02:41 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607120753.07602.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152662171.12430.317.camel@localhost.localdomain> <1152687209.5821.1.camel@rousalka.dyndns.org> <200607120753.07602.jkeating@redhat.com> Message-ID: <62405.192.54.193.51.1152705761.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 13:53, Jesse Keating a ?crit : > On Wednesday 12 July 2006 02:53, Nicolas Mailhot wrote: >> Actually all the java packages need some sort of alphatag-like >> convention to indicate what JPackage package they're derived from. I >> agree the current convention of the Java team is rather ugly, but the >> reasons it's there are real reasons. > > You've told us they need it, but haven't told us _why_ they need it. I > don't buy this. They (and the users) need to track when a package was forked from JPP. It's a two-level upstream : 1. first upstream : source code 2. second upstream : initial rpm packaging at JPP, with a lot of grunt work in the spec files 3. fedora packaging : adaptations on 2. -- Nicolas Mailhot From laroche at redhat.com Wed Jul 12 12:04:46 2006 From: laroche at redhat.com (Florian La Roche) Date: Wed, 12 Jul 2006 14:04:46 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152703232.2860.48.camel@aglarond.local> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <1152682028.12430.325.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> Message-ID: <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> > > - It leads to things like .fc5 packages in the devel branch > > ... and you still have .fc5 packages if people don't rebuild. I think we should not set dist for the -devel branch and only add this once a release is done and we build update packages. regards, Florian La Roche From jkeating at redhat.com Wed Jul 12 12:08:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 08:08:12 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> Message-ID: <200607120808.12606.jkeating@redhat.com> On Wednesday 12 July 2006 08:04, Florian La Roche wrote: > I think we should not set dist for the -devel branch and only add > this once a release is done and we build update packages. That won't work. foo-2.3-4%{?dist} for fc5 would become foo-2.3-4.fc5 and for devel it would be foo-2.3-4. Now you have an fc5 package that is rpmnewer than the devel package. -EBROKENUPGRADEPATH :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Wed Jul 12 12:11:32 2006 From: laroche at redhat.com (Florian La Roche) Date: Wed, 12 Jul 2006 14:11:32 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607120808.12606.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> <200607120808.12606.jkeating@redhat.com> Message-ID: <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> On Wed, Jul 12, 2006 at 08:08:12AM -0400, Jesse Keating wrote: > On Wednesday 12 July 2006 08:04, Florian La Roche wrote: > > I think we should not set dist for the -devel branch and only add > > this once a release is done and we build update packages. > > That won't work. > > foo-2.3-4%{?dist} for fc5 would become foo-2.3-4.fc5 and for devel it would be > foo-2.3-4. Now you have an fc5 package that is rpmnewer than the devel > package. -EBROKENUPGRADEPATH :/ But you first have to add a patch and increase the number if you build a package for the updates, so this should really work nicely. regards, Florian La Roche From jkeating at redhat.com Wed Jul 12 12:12:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 08:12:19 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <62405.192.54.193.51.1152705761.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120753.07602.jkeating@redhat.com> <62405.192.54.193.51.1152705761.squirrel@rousalka.dyndns.org> Message-ID: <200607120812.19608.jkeating@redhat.com> On Wednesday 12 July 2006 08:02, Nicolas Mailhot wrote: > They (and the users) need to track when a package was forked from JPP. > It's a two-level upstream : > > 1. first upstream : source code > 2. second upstream : initial rpm packaging at JPP, with a lot of grunt > work in the spec files > 3. fedora packaging : adaptations on 2. Does that mean that when we adopt a package from SuSE we should put the suse release information in the dist tag too? What about if we pick up a package from Axel? Or suddenly a patent goes poof and we grab a package from Livna? We can certainly put credit when credit is due in the package info, or in the documentation, but come on, in the release field? Why break our naming conventions and make babies cry when they look at the regex to try and deal with these awful release strings to do an autobump? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Wed Jul 12 12:18:01 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 12 Jul 2006 08:18:01 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607120808.12606.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> <200607120808.12606.jkeating@redhat.com> Message-ID: <20060712121801.GC32572@devserv.devel.redhat.com> On Wed, Jul 12, 2006 at 08:08:12AM -0400, Jesse Keating wrote: > On Wednesday 12 July 2006 08:04, Florian La Roche wrote: > > I think we should not set dist for the -devel branch and only add > > this once a release is done and we build update packages. > > That won't work. > > foo-2.3-4%{?dist} for fc5 would become foo-2.3-4.fc5 and for devel it would be > foo-2.3-4. Now you have an fc5 package that is rpmnewer than the devel > package. -EBROKENUPGRADEPATH :/ Yeah, we would need a macro with argument like Release: %dist(5) which would for rawhide give 5 and for other releases 4.fc5 etc. (i.e. subtract one from the number). Jakub From nicolas.mailhot at laposte.net Wed Jul 12 12:18:44 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 14:18:44 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> <200607120808.12606.jkeating@redhat.com> <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> Message-ID: <4913.192.54.193.51.1152706724.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 14:11, Florian La Roche a ?crit : > On Wed, Jul 12, 2006 at 08:08:12AM -0400, Jesse Keating wrote: >> On Wednesday 12 July 2006 08:04, Florian La Roche wrote: >> > I think we should not set dist for the -devel branch and only add >> > this once a release is done and we build update packages. >> >> That won't work. >> >> foo-2.3-4%{?dist} for fc5 would become foo-2.3-4.fc5 and for devel it >> would be >> foo-2.3-4. Now you have an fc5 package that is rpmnewer than the devel >> package. -EBROKENUPGRADEPATH :/ > > But you first have to add a patch and increase the number if you build > a package for the updates, so this should really work nicely. You can probably have devel = fcn.50, test 1 fcn.90, release = fcn+1 if you really want it -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Jul 12 12:21:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 14:21:36 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607120812.19608.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120753.07602.jkeating@redhat.com> <62405.192.54.193.51.1152705761.squirrel@rousalka.dyndns.org> <200607120812.19608.jkeating@redhat.com> Message-ID: <17085.192.54.193.51.1152706896.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 14:12, Jesse Keating a ?crit : > On Wednesday 12 July 2006 08:02, Nicolas Mailhot wrote: >> They (and the users) need to track when a package was forked from JPP. >> It's a two-level upstream : >> >> 1. first upstream : source code >> 2. second upstream : initial rpm packaging at JPP, with a lot of grunt >> work in the spec files >> 3. fedora packaging : adaptations on 2. > > Does that mean that when we adopt a package from SuSE we should put the > suse release information in the dist tag too? You didn't read me, it's not an "adopting" process, it's a continuous back-and forth. The Fedora changes are periodically rebased on JPP releases, and non distro-specific bits are pushed from Fedora to JPP -- Nicolas Mailhot From mclasen at redhat.com Wed Jul 12 12:29:34 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 12 Jul 2006 08:29:34 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152703232.2860.48.camel@aglarond.local> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <1152682028.12430.325.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> Message-ID: <1152707374.3048.10.camel@localhost.localdomain> On Wed, 2006-07-12 at 07:20 -0400, Jeremy Katz wrote: > This is a reason why you _have_ convenience things -- it's hardly an > excuse to force them down people's throats. That's like saying "because > rm is easy to get wrong, we're going to require you to confirm all > deletes". Sure, we set things up so that you get that as a convenience, > but unalias rm or rm -f let you do what you want. > Exactly. All my packages have a separate spec file per distro, and I don't see myself polluting them with %dist stuff anytime soon. Now send the packaging police after me... From jkeating at redhat.com Wed Jul 12 12:33:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 08:33:05 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <17085.192.54.193.51.1152706896.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120812.19608.jkeating@redhat.com> <17085.192.54.193.51.1152706896.squirrel@rousalka.dyndns.org> Message-ID: <200607120833.06129.jkeating@redhat.com> On Wednesday 12 July 2006 08:21, Nicolas Mailhot wrote: > You didn't read me, it's not an "adopting" process, it's a continuous > back-and forth. The Fedora changes are periodically rebased on JPP > releases, and non distro-specific bits are pushed from Fedora to JPP We'll be doing the same in Extras for RHEL, should RHEL packages have an fe4 tag somewhere in the release string, along with the .rhel5 tag? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 12 12:35:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 08:35:25 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120808.12606.jkeating@redhat.com> <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> Message-ID: <200607120835.25586.jkeating@redhat.com> On Wednesday 12 July 2006 08:11, Florian La Roche wrote: > But you first have to add a patch and increase the number if you build > a package for the updates, so this should really work nicely. er, no. Upstream issues a new release of foo. The maintainer of foo wants to release this for all the currently live distro releases, say FC6, FC5, and the development tree. So the package is exactly the same across the board, the only differences are the dist tag. You wind up with .fc5 and .fc6 added on to the updates version, and no tag on the development version. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ikent at redhat.com Wed Jul 12 12:36:29 2006 From: ikent at redhat.com (Ian Kent) Date: Wed, 12 Jul 2006 20:36:29 +0800 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <1152653482.6394.1.camel@aglarond.local> Message-ID: <1152707790.2930.40.camel@raven.themaw.net> On Tue, 2006-07-11 at 18:18 -0500, Jason L Tibbitts III wrote: > >>>>> "JM" == Jeff Moyer writes: > > JM> Yeah, thanks for pointing this out. How do you suggest this gets > JM> fixed moving forward, then? > > Why not just fix the name? Updates involving the test releases aren't > supported anyway. But Jeff's question was asking how not to cause a bunch of bzs from a bunch of unhappy users. So I've made a mistake in the naming, it's easy to fix, but how bout suggestions of how to minimize the hassle for our uses. We want lots of exposure to this so upsetting people is not going to help. Ian From nalin at redhat.com Wed Jul 12 13:27:21 2006 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 12 Jul 2006 09:27:21 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152642496.12430.232.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> Message-ID: <20060712132721.GA7898@redhat.com> On Tue, Jul 11, 2006 at 01:28:16PM -0500, Tom 'spot' Callaway wrote: > Invalid use of underscore > ========================== [snip] > java_cup-0.10-0.k.1jpp_9fc.src.rpm [snip] > nss_db-2.2-35.src.rpm > nss_ldap-250-5.src.rpm Dude, what? These three are listed in PackageNamingGuidelines as examples of packages which naturally contain underscores in their upstream names. I suspect that java_cup made the list because it's using an underscore in the release field, but huh? Nalin From rc040203 at freenet.de Wed Jul 12 13:44:20 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 12 Jul 2006 15:44:20 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712121801.GC32572@devserv.devel.redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> <200607120808.12606.jkeating@redhat.com> <20060712121801.GC32572@devserv.devel.redhat.com> Message-ID: <1152711860.4569.95.camel@mccallum.corsepiu.local> On Wed, 2006-07-12 at 08:18 -0400, Jakub Jelinek wrote: > On Wed, Jul 12, 2006 at 08:08:12AM -0400, Jesse Keating wrote: > > On Wednesday 12 July 2006 08:04, Florian La Roche wrote: > > > I think we should not set dist for the -devel branch and only add > > > this once a release is done and we build update packages. > > > > That won't work. > > > > foo-2.3-4%{?dist} for fc5 would become foo-2.3-4.fc5 and for devel it would be > > foo-2.3-4. Now you have an fc5 package that is rpmnewer than the devel > > package. -EBROKENUPGRADEPATH :/ > > Yeah, we would need a macro with argument like > Release: %dist(5) > which would for rawhide give 5 and for other releases 4.fc5 etc. > (i.e. subtract one from the number). I don't see how this would be substantially different from using dist=.fc6 for rawhide or test-releases. Ralf From mattdm at mattdm.org Wed Jul 12 13:45:42 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 09:45:42 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> Message-ID: <20060712134542.GA13080@jadzia.bu.edu> On Wed, Jul 12, 2006 at 01:30:42PM +0200, Nicolas Mailhot wrote: > > %{?dist} is a variable, giving the false impression that the source > > package may be valid for arbitrary dist releases and that filling it in > > would be enough and that no other package updates are required. Even > > worse, the dist tag enters the file names of the built packages. > If you know your package will break on another release because foo package > was updated and changed its behaviour, you should require or BR foo with > the right version But isn't it more convenient to then have the one that is designed to work on that dist to say so? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jima at beer.tclug.org Wed Jul 12 13:55:39 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 12 Jul 2006 08:55:39 -0500 (CDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152662171.12430.317.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> Message-ID: On Tue, 11 Jul 2006, Tom 'spot' Callaway wrote: > The only exception to this rule is for the dist tag, and you have to use > %{?dist} in the release field as documented. (after the integer, with > nothing else after it). Okay, just to clarify, is it no longer proper to use "Release: 1%{?dist}.1" to bump within one branch without affecting later branches? Because last I heard, that seemed to be the advocated method for doing so. If that's no longer the case, it'd probably be best to make it well-known (i.e., here). > I highly encourage that you use integers in the Release field, and not > whole numbers (e.g. use 3, not 3.206), because that is the best way to > confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to > run out of integers anytime soon. Err, I think you kinda contradicted yourself there; I think you're telling people TO use whole numbers, and not decimals. Unless my brain is warping the definition of "whole numbers," which is also possible (although a cursory Google suggests not). Jima From nicolas.mailhot at laposte.net Wed Jul 12 14:08:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 16:08:43 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607120833.06129.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120812.19608.jkeating@redhat.com> <17085.192.54.193.51.1152706896.squirrel@rousalka.dyndns.org> <200607120833.06129.jkeating@redhat.com> Message-ID: <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 14:33, Jesse Keating a ?crit : > On Wednesday 12 July 2006 08:21, Nicolas Mailhot wrote: >> You didn't read me, it's not an "adopting" process, it's a continuous >> back-and forth. The Fedora changes are periodically rebased on JPP >> releases, and non distro-specific bits are pushed from Fedora to JPP > > We'll be doing the same in Extras for RHEL, should RHEL packages have an > fe tag somewhere in the release string, along with the .rhel5 tag? Probably depends on how often the packages are forked and rebased, and the amount of changes you do above the original packaging It'd be great to have a common naming convention when stacked packaging happens though -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Jul 12 14:12:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 16:12:23 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712134542.GA13080@jadzia.bu.edu> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712134542.GA13080@jadzia.bu.edu> Message-ID: <28772.192.54.193.51.1152713543.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 15:45, Matthew Miller a ?crit : > On Wed, Jul 12, 2006 at 01:30:42PM +0200, Nicolas Mailhot wrote: >> > %{?dist} is a variable, giving the false impression that the source >> > package may be valid for arbitrary dist releases and that filling it >> in >> > would be enough and that no other package updates are required. Even >> > worse, the dist tag enters the file names of the built packages. >> If you know your package will break on another release because foo >> package >> was updated and changed its behaviour, you should require or BR foo with >> the right version > > But isn't it more convenient to then have the one that is designed to work > on that dist to say so? You're assuming the package/versionset of a given distro is a constant which is not the case (RHEL/FC updates, rolling releases). -- Nicolas Mailhot From tcallawa at redhat.com Wed Jul 12 14:14:33 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 09:14:33 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712132721.GA7898@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <20060712132721.GA7898@redhat.com> Message-ID: <1152713673.12430.343.camel@localhost.localdomain> On Wed, 2006-07-12 at 09:27 -0400, Nalin Dahyabhai wrote: > On Tue, Jul 11, 2006 at 01:28:16PM -0500, Tom 'spot' Callaway wrote: > > Invalid use of underscore > > ========================== > [snip] > > java_cup-0.10-0.k.1jpp_9fc.src.rpm > [snip] > > nss_db-2.2-35.src.rpm > > nss_ldap-250-5.src.rpm > > Dude, what? These three are listed in PackageNamingGuidelines as > examples of packages which naturally contain underscores in their > upstream names. I suspect that java_cup made the list because it's > using an underscore in the release field, but huh? Yeah. nss_* are false positives there. My bad. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Wed Jul 12 14:14:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 16:14:42 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> Message-ID: <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 15:55, Jima a ?crit : > On Tue, 11 Jul 2006, Tom 'spot' Callaway wrote: >> The only exception to this rule is for the dist tag, and you have to use >> %{?dist} in the release field as documented. (after the integer, with >> nothing else after it). > > Okay, just to clarify, is it no longer proper to use > "Release: 1%{?dist}.1" to bump within one branch without affecting later > branches? Because last I heard, that seemed to be the advocated method > for doing so. It was never proper and never made it to the official naming guidelines >> I highly encourage that you use integers in the Release field, and not >> whole numbers (e.g. use 3, not 3.206), because that is the best way to >> confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to >> run out of integers anytime soon. > > Err, I think you kinda contradicted yourself there; I think you're > telling people TO use whole numbers, and not decimals. Unless my brain is > warping the definition of "whole numbers," which is also possible > (although a cursory Google suggests not). You've missed the "in release" part. And there are exceptions like pre/post release packages (alphatags) -> read the naming guidelines -- Nicolas Mailhot From tcallawa at redhat.com Wed Jul 12 14:15:57 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 09:15:57 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> Message-ID: <1152713757.12430.345.camel@localhost.localdomain> On Wed, 2006-07-12 at 08:55 -0500, Jima wrote: > On Tue, 11 Jul 2006, Tom 'spot' Callaway wrote: > > I highly encourage that you use integers in the Release field, and not > > whole numbers (e.g. use 3, not 3.206), because that is the best way to > > confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to > > run out of integers anytime soon. > > Err, I think you kinda contradicted yourself there; I think you're > telling people TO use whole numbers, and not decimals. Unless my brain is > warping the definition of "whole numbers," which is also possible > (although a cursory Google suggests not). Yes. Whole numbers, not decimals. I'm allowed to get math wrong, it comes with my North Carolina School of Science & Math diploma. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Wed Jul 12 14:29:15 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Jul 2006 09:29:15 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Wed, 12 Jul 2006 16:14:42 +0200 (CEST)") References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: [blah-1.fc3.1] NM> It was never proper and never made it to the official naming NM> guidelines Then someone needs to provide a way to bump the FC3 build of a package without forcing version bumps for FC4, FC5, FC6, etc. You've just shot down the only thing that could possibly allow that. - J< From rdieter at math.unl.edu Wed Jul 12 14:36:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 09:36:06 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> Message-ID: <44B508D6.6000902@math.unl.edu> Nicolas Mailhot wrote: > Le Mer 12 juillet 2006 15:55, Jima a ?crit : >> On Tue, 11 Jul 2006, Tom 'spot' Callaway wrote: >>> The only exception to this rule is for the dist tag, and you have to use >>> %{?dist} in the release field as documented. (after the integer, with >>> nothing else after it). >> Okay, just to clarify, is it no longer proper to use >> "Release: 1%{?dist}.1" to bump within one branch without affecting later >> branches? Because last I heard, that seemed to be the advocated method >> for doing so. > > It was never proper and never made it to the official naming guidelines I disagree that it's not proper, and as Jason has pointed out, it is currently the only method to push a %dist-specific update without having to touch other branches, afaik. -- Rex From rdieter at math.unl.edu Wed Jul 12 14:36:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 09:36:33 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <4913.192.54.193.51.1152706724.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <1152703232.2860.48.camel@aglarond.local> <20060712120446.GA9679@dudweiler.stuttgart.redhat.com> <200607120808.12606.jkeating@redhat.com> <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> <4913.192.54.193.51.1152706724.squirrel@rousalka.dyndns.org> Message-ID: <44B508F1.3050105@math.unl.edu> On Wed, 12 Jul 2006, Nicolas Mailhot wrote: > > Le Mer 12 juillet 2006 14:11, Florian La Roche a ?crit : >> On Wed, Jul 12, 2006 at 08:08:12AM -0400, Jesse Keating wrote: >>> On Wednesday 12 July 2006 08:04, Florian La Roche wrote: >>>> I think we should not set dist for the -devel branch and only add >>>> this once a release is done and we build update packages. >>> >>> That won't work. >>> >>> foo-2.3-4%{?dist} for fc5 would become foo-2.3-4.fc5 and for devel it >>> would be >>> foo-2.3-4. Now you have an fc5 package that is rpmnewer than the devel >>> package. -EBROKENUPGRADEPATH :/ >> >> But you first have to add a patch and increase the number if you build >> a package for the updates, so this should really work nicely. > > You can probably have devel = fcn.50, test 1 fcn.90, release = fcn+1 if > you really want it That's approximately what Axel had proposed awhile back. -- Rex From nicolas.mailhot at laposte.net Wed Jul 12 14:38:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 16:38:51 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> Message-ID: <12491.192.54.193.51.1152715131.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 16:29, Jason L Tibbitts III a ?crit : >>>>>> "NM" == Nicolas Mailhot writes: > > [blah-1.fc3.1] > NM> It was never proper and never made it to the official naming > NM> guidelines > > Then someone needs to provide a way to bump the FC3 build of a package > without forcing version bumps for FC4, FC5, FC6, etc. You've just > shot down the only thing that could possibly allow that. I didn't shot it down, the guidelines people did, IIRC because it was unsafe when dist was not defined -- Nicolas Mailhot From tcallawa at redhat.com Wed Jul 12 14:45:23 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 09:45:23 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> Message-ID: <1152715523.12430.368.camel@localhost.localdomain> On Wed, 2006-07-12 at 09:29 -0500, Jason L Tibbitts III wrote: > >>>>> "NM" == Nicolas Mailhot writes: > > [blah-1.fc3.1] > NM> It was never proper and never made it to the official naming > NM> guidelines > > Then someone needs to provide a way to bump the FC3 build of a package > without forcing version bumps for FC4, FC5, FC6, etc. You've just > shot down the only thing that could possibly allow that. It is worth noting that right now, there is no documented way of doing this. It also stands to reason that this is something the Fedora Packaging Committee should try to resolve. I've put it on the agenda to discuss this week. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jkeating at redhat.com Wed Jul 12 14:58:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 10:58:41 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <4913.192.54.193.51.1152706724.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> <4913.192.54.193.51.1152706724.squirrel@rousalka.dyndns.org> Message-ID: <200607121058.48094.jkeating@redhat.com> On Wednesday 12 July 2006 08:18, Nicolas Mailhot wrote: > You can probably have devel = fcn.50, test 1 fcn.90, release = fcn+1 if > you really want it But what does this actually solve? You want to remove dist tags for the devel branch, only to reintroduce them in a way that isn't consistant with the other dist tags? I don't get it.... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 12 15:05:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 11:05:22 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> Message-ID: <200607121105.26089.jkeating@redhat.com> On Wednesday 12 July 2006 10:08, Nicolas Mailhot wrote: > Probably depends on how often the packages are forked and rebased, and the > amount of changes you do above the original packaging > > It'd be great to have a common naming convention when stacked packaging > happens though Why though? What real problem does it actually solve? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Jul 12 15:02:37 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 17:02:37 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121058.48094.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <20060712121132.GA9920@dudweiler.stuttgart.redhat.com> <4913.192.54.193.51.1152706724.squirrel@rousalka.dyndns.org> <200607121058.48094.jkeating@redhat.com> Message-ID: <42561.192.54.193.51.1152716557.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 16:58, Jesse Keating a ?crit : > On Wednesday 12 July 2006 08:18, Nicolas Mailhot wrote: >> You can probably have devel = fcn.50, test 1 fcn.90, release = fcn+1 if >> you really want it > > But what does this actually solve? It solves the "package name says it's for fc6, but it's not really for fc6 but some older rawhide/test state" > You want to remove dist tags for the devel > branch, only to reintroduce them in a way that isn't consistant with the > other dist tags? I don't get it.... People don't want to remove dist from devel, what they want is to avoid people pulling an old "fc6" package from some badly synced mirror after fc6 is released only to discover it's not really for the released fc6 -- Nicolas Mailhot From jkeating at redhat.com Wed Jul 12 15:14:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 11:14:58 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <42561.192.54.193.51.1152716557.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121058.48094.jkeating@redhat.com> <42561.192.54.193.51.1152716557.squirrel@rousalka.dyndns.org> Message-ID: <200607121114.59460.jkeating@redhat.com> On Wednesday 12 July 2006 11:02, Nicolas Mailhot wrote: > > But what does this actually solve? > > It solves the "package name says it's for fc6, but it's not really for fc6 > but some older rawhide/test state" By that method, at release time we'll have _no_ packages that are for fc6 since they'll all come from the devel branch. If you want packages that aren't for the next release, don't put them in devel, scratch build them, mock build them, whatever. > > You want to remove dist tags for the devel > > branch, only to reintroduce them in a way that isn't consistant with the > > other dist tags? ?I don't get it.... > > People don't want to remove dist from devel, what they want is to avoid > people pulling an old "fc6" package from some badly synced mirror after > fc6 is released only to discover it's not really for the released fc6 If they're pulling packages by hand they get to keep all the pieces they break. If they're pulling from an out of date mirror, we need to fix the mirroring system to prevent this, not break the build system to accommodate a broken mirroring system. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Jul 12 15:23:35 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 11:23:35 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152713757.12430.345.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152713757.12430.345.camel@localhost.localdomain> Message-ID: <20060712152335.GA19314@jadzia.bu.edu> On Wed, Jul 12, 2006 at 09:15:57AM -0500, Tom 'spot' Callaway wrote: > > > I highly encourage that you use integers in the Release field, and not > > > whole numbers (e.g. use 3, not 3.206), because that is the best way to > > > confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to > > > run out of integers anytime soon. > > Err, I think you kinda contradicted yourself there; I think you're > > telling people TO use whole numbers, and not decimals. Unless my brain is > > warping the definition of "whole numbers," which is also possible > > (although a cursory Google suggests not). > Yes. Whole numbers, not decimals. I'm allowed to get math wrong, it > comes with my North Carolina School of Science & Math diploma. Can one use whole numbers separated by a dot? (That is, use it in the way RPM interprets it?) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Jul 12 15:28:34 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 11:28:34 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <28772.192.54.193.51.1152713543.squirrel@rousalka.dyndns.org> References: <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712134542.GA13080@jadzia.bu.edu> <28772.192.54.193.51.1152713543.squirrel@rousalka.dyndns.org> Message-ID: <20060712152834.GB19314@jadzia.bu.edu> On Wed, Jul 12, 2006 at 04:12:23PM +0200, Nicolas Mailhot wrote: > > But isn't it more convenient to then have the one that is designed to work > > on that dist to say so? > You're assuming the package/versionset of a given distro is a constant > which is not the case (RHEL/FC updates, rolling releases). But what if it's a design decision _for this package_ and not something dependent on anything else? For a (theoretical) example, say I decide that the libGL/libGLU dependency isn't such a big deal, and so decide to merge the wxGTK-gl subpackage back into the main wxGTK package for FC6 and on. However, I don't want to force this onto the existing FC5 package, since I don't want to make surprising changes for people on running systems. To me, it makes sense at this point to fork the spec file and tag the older releases with their proper name. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From smooge at gmail.com Wed Jul 12 15:31:46 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Jul 2006 09:31:46 -0600 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712083420.3d6e60ad.bugs.michael@gmx.net> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> Message-ID: <80d7e4090607120831y10369abflf6baa8816842544e@mail.gmail.com> On 7/12/06, Michael Schwendt wrote: > On Wed, 12 Jul 2006 00:27:39 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2006-07-11 at 22:25 -0400, Matthew Miller wrote: > > > On Tue, Jul 11, 2006 at 09:24:57PM -0400, Jeremy Katz wrote: > > > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use > > > > > %{?dist} to let the buildsystem (both plague and brew support this) > > > > > determine what the distribution tag is. It will fill in %{dist} > > > > > with .fc6, for example. The dist tag bits are documented here: > > > > > http://fedoraproject.org/wiki/DistTag > > > > > Hardcoding the value for the dist tag is no longer allowed, since the > > > > > buildsystem can do it for you. > > > > I thought that things allowed hardcoding as long as you used the "right" > > > > value. Granted, doing so is probably kind of silly, but forcing > > > > syntactic sugar is also overkill > > > > > > Also, 'cause sometimes maybe your spec file _is_ specifically for that > > > release for some reason, and it's too different for a bunch of %ifs to make > > > sense? > > > > Even in those cases, %{dist} will always be correct. > > In the resulting binaries, yes, but not in the .spec file. As the package > maintainer, you don't want to be confused by seeing %{?dist} and assuming > it is a valid spec for multiple dists when in fact it is not. This avoids > mistakes during mass-updates to your package branches. > > Using %{?dist} must not be mandatory. Hardcoding the value %{dist} would > expand to is justified in some cases. > My own private rpms that are only good for a certain release have a BuildRequires: %{dist} == fc4 # change to appropriate buildsystem name for FC4 This way I know that it will not build on something else, and I don't have to rely on the intelligence of others to understand my stupidity. -- Stephen J Smoogen. CSIRT/Linux System Administrator From tcallawa at redhat.com Wed Jul 12 15:46:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 10:46:06 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712152335.GA19314@jadzia.bu.edu> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152713757.12430.345.camel@localhost.localdomain> <20060712152335.GA19314@jadzia.bu.edu> Message-ID: <1152719166.12430.377.camel@localhost.localdomain> On Wed, 2006-07-12 at 11:23 -0400, Matthew Miller wrote: > On Wed, Jul 12, 2006 at 09:15:57AM -0500, Tom 'spot' Callaway wrote: > > > > I highly encourage that you use integers in the Release field, and not > > > > whole numbers (e.g. use 3, not 3.206), because that is the best way to > > > > confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to > > > > run out of integers anytime soon. > > > Err, I think you kinda contradicted yourself there; I think you're > > > telling people TO use whole numbers, and not decimals. Unless my brain is > > > warping the definition of "whole numbers," which is also possible > > > (although a cursory Google suggests not). > > Yes. Whole numbers, not decimals. I'm allowed to get math wrong, it > > comes with my North Carolina School of Science & Math diploma. > > Can one use whole numbers separated by a dot? (That is, use it in the way > RPM interprets it?) I'd rather people didn't, as many will forget how RPM interprets it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Wed Jul 12 15:58:48 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 11:58:48 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060711171846.GA17627@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> Message-ID: <20060712155848.GA20076@jadzia.bu.edu> On Tue, Jul 11, 2006 at 01:18:46PM -0400, Matthew Miller wrote: > *Then*, there's the question of _before_ that. There's 1051 bugs in open > states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. > Obviously a lot of that isn't going to be helpful or interesting after all > these years -- and RHL9 is finally going out of Legacy support too. However, > it's possible that there's some overlooked important/useful/still-relevant > reports that would still apply to Fedora or RHEL. I'm going to go ahead with this after OLS and after FC4, unless someone really objects. For Red Hat Linux 7.3 and 9 (472 bugs, by the way), I'm going to use a message like: Red Hat Linux 7.3 and Red Hat Linux 9 are maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, change the version to match. (In either case, make sure to check the box indicating that the requested information was provided -- thanks!) Please note that Legacy security update support for these products will stop on December 31st, 2006. Please upgrade any systems still running these releases to a current Fedora Core release or Red Hat Enterprise Linux or comparable. After the end of this year, any Red Hat Linux 7.3 and Red Hat Linux 9 bugs still awaiting information will be closed as "can't fix". Thank you for your help. (Um, I'd really like to point people at CentOS. But I can understand that probably there's some preference for me not to. Any objection to the above wording?) For earlier Red Hat Linux releases (579 bugs): This release of Red Hat Linux is no longer supported. However, the Fedora Project is interested in making sure that important issues which are still relevant do not slip through the cracks. If this issue still exists in Fedora Core 5 or in the FC6 test release, please change the version to match and check the box indicating that the requested information was provided. I'm sorry this issue was unable to be resolved before this time. Thank you very much for your help. Any comments? Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From smooge at gmail.com Wed Jul 12 16:16:08 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Jul 2006 10:16:08 -0600 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712155848.GA20076@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> Message-ID: <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> On 7/12/06, Matthew Miller wrote: > On Tue, Jul 11, 2006 at 01:18:46PM -0400, Matthew Miller wrote: > > *Then*, there's the question of _before_ that. There's 1051 bugs in open > > states attached to the "Red Hat Linux" and "Red Hat Linux Beta" products. > > Obviously a lot of that isn't going to be helpful or interesting after all > > these years -- and RHL9 is finally going out of Legacy support too. However, > > it's possible that there's some overlooked important/useful/still-relevant > > reports that would still apply to Fedora or RHEL. > > I'm going to go ahead with this after OLS and after FC4, unless someone > really objects. > > For Red Hat Linux 7.3 and 9 (472 bugs, by the way), I'm going to use a > message like: > > Red Hat Linux 7.3 and Red Hat Linux 9 are maintained by the Fedora Legacy > project for security updates only. If this problem is a security issue, > please reassign to the Fedora Legacy product. If it is not a security > issue and hasn't been resolved in the current FC5 updates or in the FC6 > test release, change the version to match. (In either case, make sure to > check the box indicating that the requested information was provided -- > thanks!) > > Please note that Legacy security update support for these products will > stop on December 31st, 2006. Please upgrade any systems still running > these releases to a current Fedora Core release or Red Hat Enterprise > Linux or comparable. After the end of this year, any Red Hat Linux 7.3 > and Red Hat Linux 9 bugs still awaiting information will be closed as > "can't fix". > > Thank you for your help. > Well I would go with a list of links at the end of each name in parenthesis: For the latest Fedora: http://fedoraproject.org/wiki/ For Red Hat Enterprise: http://www.redhat.com/rhel-link-goes-here For a comparable OS: http://www.centos.org,https://www.scientificlinux.org/ -- Stephen J Smoogen. CSIRT/Linux System Administrator From nicolas.mailhot at laposte.net Wed Jul 12 16:17:04 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 18:17:04 +0200 (CEST) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712152834.GB19314@jadzia.bu.edu> References: <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712134542.GA13080@jadzia.bu.edu> <28772.192.54.193.51.1152713543.squirrel@rousalka.dyndns.org> <20060712152834.GB19314@jadzia.bu.edu> Message-ID: <52696.192.54.193.51.1152721024.squirrel@rousalka.dyndns.org> Le Mer 12 juillet 2006 17:28, Matthew Miller a ?crit : > For a (theoretical) example, say I decide that the libGL/libGLU dependency > isn't such a big deal, and so decide to merge the wxGTK-gl subpackage back > into the main wxGTK package for FC6 and on. However, I don't want to force > this onto the existing FC5 package, since I don't want to make surprising > changes for people on running systems. To me, it makes sense at this point > to fork the spec file and tag the older releases with their proper name. Remember tagging is an hint, nothing more, you can rename rpms to whatever you want, so relying on the dist to have packages installed on the "right" version is dangerous. The only safe thing are R + BR in a context where people don't do full-distro regular updates for badnwidth reasons or others. Dist is a wonderful thing, but do not try to replace the dep resolver with fuzzy dist matching. (it does not work terribly for that other os) -- Nicolas Mailhot From jima at beer.tclug.org Wed Jul 12 17:18:34 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 12 Jul 2006 12:18:34 -0500 (CDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <38701.192.54.193.51.1152713682.squirrel@rousalka.dyndns.org> Message-ID: On Wed, 12 Jul 2006, Nicolas Mailhot wrote: > Le Mer 12 juillet 2006 15:55, Jima a ?crit : >> Okay, just to clarify, is it no longer proper to use >> "Release: 1%{?dist}.1" to bump within one branch without affecting later >> branches? Because last I heard, that seemed to be the advocated method >> for doing so. > > It was never proper and never made it to the official naming guidelines Whether or not it was ever "proper" by whatever definition you're choosing to use, or endorsed by the Packaging Board (?), it was *the* answer given out on more than a few occasions. And judging by the response to my claim, it was clearly embraced for a reason. >> Err, I think you kinda contradicted yourself there; I think you're >> telling people TO use whole numbers, and not decimals. Unless my brain is >> warping the definition of "whole numbers," which is also possible >> (although a cursory Google suggests not). > > You've missed the "in release" part. > And there are exceptions like pre/post release packages (alphatags) > -> read the naming guidelines I'm not sure you caught the context of my question, as Spot himself confirmed the correction (in his typical entertaining way). Jima From jima at beer.tclug.org Wed Jul 12 17:26:21 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 12 Jul 2006 12:26:21 -0500 (CDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152713757.12430.345.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152713757.12430.345.camel@localhost.localdomain> Message-ID: On Wed, 12 Jul 2006, Tom 'spot' Callaway wrote: > On Wed, 2006-07-12 at 08:55 -0500, Jima wrote: >> Err, I think you kinda contradicted yourself there; I think you're >> telling people TO use whole numbers, and not decimals. Unless my brain is >> warping the definition of "whole numbers," which is also possible >> (although a cursory Google suggests not). > > Yes. Whole numbers, not decimals. I'm allowed to get math wrong, it > comes with my North Carolina School of Science & Math diploma. Fair enough! It might be worth noting that a probable exception to the "whole numbers" rule would be pre-release, where the whole number would be prepended by "0."...right? Sorry if I'm blurring the point too much; I'm just trying to avoid screwing up wherever possible. Jima From peter at thecodergeek.com Wed Jul 12 17:33:01 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 12 Jul 2006 10:33:01 -0700 (PDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152713757.12430.345.camel@localhost.localdomain> Message-ID: <51628.127.0.0.1.1152725581.squirrel@www.thecodergeek.com> > Fair enough! It might be worth noting that a probable exception to the > "whole numbers" rule would be pre-release, where the whole number would be > prepended by "0."...right? Correct. A prerelease version would use the to-be version in the Version tag, and 0.RELEASE.PRE-RELEASE-TAG; so that the official upstread release would be the "first" ("-1") release of the package. For example, with my packaging of Openbox 3.3-rc2, I use the following: Version: 3.3 Release: 0.8.rc2%{?dist} That way, when 3.3 final is release, I can update the Release tag to simply: Release: 1%{?dist} Take a look at the wiki's Packaging/NamingGuidelines page, especially the "Pre-Release packages" section, for more information. Hope that helps. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From jima at beer.tclug.org Wed Jul 12 17:33:13 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 12 Jul 2006 12:33:13 -0500 (CDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <80d7e4090607120831y10369abflf6baa8816842544e@mail.gmail.com> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <80d7e4090607120831y10369abflf6baa8816842544e@mail.gmail.com> Message-ID: On Wed, 12 Jul 2006, Stephen John Smoogen wrote: > My own private rpms that are only good for a certain release have a > > BuildRequires: %{dist} == fc4 # change to appropriate buildsystem name for > FC4 > > This way I know that it will not build on something else, and I don't > have to rely on the intelligence of others to understand my stupidity. 1: I imagine you meant ".fc4" in the BR above? 2. Another option is to BR "%{fedora} == 4"; I believe it's just as well-supported in the buildsys as %{dist}. (I used some similar mojo, as suggested by Dennis Gilmore, in my dnsmasq package.) Jima From jima at beer.tclug.org Wed Jul 12 17:36:54 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 12 Jul 2006 12:36:54 -0500 (CDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <51628.127.0.0.1.1152725581.squirrel@www.thecodergeek.com> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152713757.12430.345.camel@localhost.localdomain> <51628.127.0.0.1.1152725581.squirrel@www.thecodergeek.com> Message-ID: On Wed, 12 Jul 2006, Peter Gordon wrote: > Correct. A prerelease version would use the to-be version in the Version > tag, and 0.RELEASE.PRE-RELEASE-TAG; so that the official upstread release > would be the "first" ("-1") release of the package. I thought so, but wanted to get that bit of dirty laundry aired. > Take a look at the wiki's Packaging/NamingGuidelines page, especially the > "Pre-Release packages" section, for more information. I did before asking, actually; the question was mainly to verify that that was still an exception to the recommendation. Jima From mattdm at mattdm.org Wed Jul 12 17:41:07 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 13:41:07 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> Message-ID: <20060712174107.GA25617@jadzia.bu.edu> On Wed, Jul 12, 2006 at 10:16:08AM -0600, Stephen John Smoogen wrote: > Well I would go with a list of links at the end of each name in parenthesis: > > For the latest Fedora: http://fedoraproject.org/wiki/ > For Red Hat Enterprise: http://www.redhat.com/rhel-link-goes-here > For a comparable OS: http://www.centos.org,https://www.scientificlinux.org/ Good suggestion, thanks. Will, in fact, anyone be unhappy if I point to Scientific Linux or CentOS in this way? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Jul 12 17:43:15 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 13:43:15 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <52696.192.54.193.51.1152721024.squirrel@rousalka.dyndns.org> References: <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712134542.GA13080@jadzia.bu.edu> <28772.192.54.193.51.1152713543.squirrel@rousalka.dyndns.org> <20060712152834.GB19314@jadzia.bu.edu> <52696.192.54.193.51.1152721024.squirrel@rousalka.dyndns.org> Message-ID: <20060712174315.GB25617@jadzia.bu.edu> On Wed, Jul 12, 2006 at 06:17:04PM +0200, Nicolas Mailhot wrote: > > For a (theoretical) example, say I decide that the libGL/libGLU dependency > > isn't such a big deal, and so decide to merge the wxGTK-gl subpackage back > > into the main wxGTK package for FC6 and on. However, I don't want to force > > this onto the existing FC5 package, since I don't want to make surprising > > changes for people on running systems. To me, it makes sense at this point > > to fork the spec file and tag the older releases with their proper name. > Remember tagging is an hint, nothing more, you can rename rpms to whatever > you want, so relying on the dist to have packages installed on the "right" > version is dangerous. Okay. That doesn't seem relevant. > The only safe thing are R + BR in a context where people don't do > full-distro regular updates for badnwidth reasons or others. BR? BuildRequires? > Dist is a wonderful thing, but do not try to replace the dep resolver with > fuzzy dist matching. (it does not work terribly for that other os) Okay. Again, doesn't seem relevant to what I'm saying. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From peter at thecodergeek.com Wed Jul 12 17:49:20 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 12 Jul 2006 10:49:20 -0700 (PDT) Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <51628.127.0.0.1.1152725581.squirrel@www.thecodergeek.com> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152713757.12430.345.camel@localhost.localdomain> <51628.127.0.0.1.1152725581.squirrel@www.thecodergeek.com> Message-ID: <51917.127.0.0.1.1152726560.squirrel@www.thecodergeek.com> Peter Gordon wrote: > [...] A prerelease version would use the to-be version in the Version > tag, and 0.RELEASE.PRE-RELEASE-TAG; so that the official upstread release > would be the "first" ("-1") release of the package. That should read: "A prerelease version would use the to-be version in the Version tag, and 0.RELEASE.PRE-RELEASE-TAG in the Release tag; so that the official upstream release would be the "first" ("-1") release of the package." Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From notting at redhat.com Wed Jul 12 17:50:46 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 13:50:46 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712174107.GA25617@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> Message-ID: <20060712175045.GA30012@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Wed, Jul 12, 2006 at 10:16:08AM -0600, Stephen John Smoogen wrote: > > Well I would go with a list of links at the end of each name in parenthesis: > > > > For the latest Fedora: http://fedoraproject.org/wiki/ > > For Red Hat Enterprise: http://www.redhat.com/rhel-link-goes-here > > For a comparable OS: http://www.centos.org,https://www.scientificlinux.org/ > > Good suggestion, thanks. Will, in fact, anyone be unhappy if I point to > Scientific Linux or CentOS in this way? For RHL bugs in Red Hat's bugzilla? Yeah, I'm a little leery about that. There's also http://www.redhat.com/rhel/migrate/whichlinux/ which you can point to. Bill From mattdm at mattdm.org Wed Jul 12 17:55:32 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 13:55:32 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712175045.GA30012@nostromo.devel.redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> Message-ID: <20060712175532.GA26268@jadzia.bu.edu> On Wed, Jul 12, 2006 at 01:50:46PM -0400, Bill Nottingham wrote: > > > Well I would go with a list of links at the end of each name in parenthesis: > > > > > > For the latest Fedora: http://fedoraproject.org/wiki/ > > > For Red Hat Enterprise: http://www.redhat.com/rhel-link-goes-here > > > For a comparable OS: http://www.centos.org,https://www.scientificlinux.org/ > > > > Good suggestion, thanks. Will, in fact, anyone be unhappy if I point to > > Scientific Linux or CentOS in this way? > For RHL bugs in Red Hat's bugzilla? Yeah, I'm a little leery about that. See, I thought maybe there would be some concern. :) > There's also http://www.redhat.com/rhel/migrate/whichlinux/ which you > can point to. That's a little more marketspeaky/anti-fedora than I'd like. ("None", "None", "None", "None", "N/A", etc.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From alan at redhat.com Wed Jul 12 18:04:17 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Jul 2006 14:04:17 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> Message-ID: <20060712180417.GB20392@devserv.devel.redhat.com> On Wed, Jul 12, 2006 at 10:16:08AM -0600, Stephen John Smoogen wrote: > Well I would go with a list of links at the end of each name in > parenthesis: There is a Red Hat page about this that might be a simple place to point http://www.redhat.com/rhel/migrate/whichlinux/ From skvidal at linux.duke.edu Wed Jul 12 18:05:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 12 Jul 2006 14:05:58 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712180417.GB20392@devserv.devel.redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712180417.GB20392@devserv.devel.redhat.com> Message-ID: <1152727558.28994.23.camel@cutter> On Wed, 2006-07-12 at 14:04 -0400, Alan Cox wrote: > On Wed, Jul 12, 2006 at 10:16:08AM -0600, Stephen John Smoogen wrote: > > Well I would go with a list of links at the end of each name in > > parenthesis: > > There is a Red Hat page about this that might be a simple place to point > > http://www.redhat.com/rhel/migrate/whichlinux/ > Will there ever be a time when fedora can call a spade and a spade and not speak with a trembling voice when we suggest that there are other alternatives to rhel? :) -sv From alan at redhat.com Wed Jul 12 18:11:16 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Jul 2006 14:11:16 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712180417.GB20392@devserv.devel.redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712180417.GB20392@devserv.devel.redhat.com> Message-ID: <20060712181116.GA23428@devserv.devel.redhat.com> On Wed, Jul 12, 2006 at 02:04:17PM -0400, Alan Cox wrote: > There is a Red Hat page about this that might be a simple place to point > > http://www.redhat.com/rhel/migrate/whichlinux/ Even better and more related would be: http://www.redhat.com/rhel/migrate/redhatlinux/ which is the RHL 7/8/9 to where page From fnasser at redhat.com Wed Jul 12 19:18:06 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 12 Jul 2006 15:18:06 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121105.26089.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> Message-ID: <44B54AEE.8020104@redhat.com> Jesse Keating wrote: > On Wednesday 12 July 2006 10:08, Nicolas Mailhot wrote: > >> Probably depends on how often the packages are forked and rebased, and the >> amount of changes you do above the original packaging >> >> It'd be great to have a common naming convention when stacked packaging >> happens though >> > > Why though? What real problem does it actually solve? > > Several reasons. First, as these packages are maintained upstream (not only the software, but the spec files and other SRPM bits) it is important to know in which EVR they are based on. So, if you know that ......6jpp has a fix for some problem then if the one you have installed is .....6jpp References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> Message-ID: <20060712214433.137610a1.bugs.michael@gmx.net> On Wed, 12 Jul 2006 13:30:42 +0200 (CEST), Nicolas Mailhot wrote: > > Le Mer 12 juillet 2006 12:45, Michael Schwendt a ?crit : > > > %{?dist} is a variable, giving the false impression that the source > > package may be valid for arbitrary dist releases and that filling it in > > would be enough and that no other package updates are required. Even > > worse, the dist tag enters the file names of the built packages. > > If you know your package will break on another release because foo package > was updated and changed its behaviour, you should require or BR foo with > the right version Who said there exists such a dependency or BR? Or do you suggest "Requires: fedora-release-5"? :) It might be that the src.rpm builds just fine on a newer dist. Doesn't matter. The src.rpm was created for and tested for a specific dist, and I don't understand why the spec file is not permitted to reflect that. Sure, I can get the dist tag wrong. I can forget to update it, for instance. So what? There are so many other problems (and worse problems) I can get into a package. From jkeating at redhat.com Wed Jul 12 19:44:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 15:44:58 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B54AEE.8020104@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> Message-ID: <200607121544.58894.jkeating@redhat.com> On Wednesday 12 July 2006 15:18, Fernando Nasser wrote: > First, as these packages are maintained upstream (not only the software, > but the spec files and other SRPM bits) it is important to know in which > EVR they are based on. ?So, if you know that ......6jpp has a fix for > some problem then if the one you have installed is .....6jpp suffix) also has it. ?That is what Nicholas was talking about. This almost sounds like it should be in the name of the package instead. You're repackaging a package, but want to keep the upstream package information. foo-6jpp-release-version. Or if you _really_ have to, move it to the Version field, not the release field. You're packaging the 6jpp VERSION of upstream. The RELEASE is relative to what Red Hat does with it. Combine that with a Provides line and you're getting to sanity. However even this is not really approved of in the naming guidelines, but could become one more case of non-numeric in version: Name: foo Version: 2.6.0.6jpp Release: 1%{?dist} Provides: foo = 2.6.0-6jpp > Second, these packages are supposed to interoperate with other > repositories (remember that only a fraction of Java packages is AOT > built on Fedora), so preserving the upstream EVR string is fundamental > for that to work. ?This ensure no packages are unduly overwritten when > the two repositories are enabled and that the latest version/releases > prevail. Provides: foo-2.6.0-6jpp Then you can provide exactly what it is named upstream. > All Java releases for RHEL have been done this way, by adding _NNrh to > whatever the upstream JPackage EVR was with success. > For Fedora 3 and Fedora package a _NNfc was adopted. ?Gary Benson used > to have a document describing it, which I thought lived in Fedora pages > somewhere. > > There are hundreds of Java packages there, all rebuilt from upstream > JPackage.org, shipped on Fedora for a couple of years with this EVR > convention. > > W.r.t. the suffix added after the upstream EVR it does not really > matter. ?It can be anything people here want it to be. ?We are updating > the packages so we can use a new suffix as we get them from upstream JPP > 1.7 if it is agreed upon quickly (time is running out). > > Should we change from the _NNfc convention? > If so, now is my turn to ask: Why? Just because it has been done this way doesn't make it right or clean. There is no proper dist tag that separates a fc6 package from an fc5 package. I ran into many instances where the FC-4 version was higher than the FC-5 version and the devel version because the number before fc was bumped, but fc remained just fc. This is just one of the issues. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed Jul 12 19:47:41 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 14:47:41 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B54AEE.8020104@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> Message-ID: <1152733661.12430.394.camel@localhost.localdomain> On Wed, 2006-07-12 at 15:18 -0400, Fernando Nasser wrote: > Jesse Keating wrote: > > On Wednesday 12 July 2006 10:08, Nicolas Mailhot wrote: > > > >> Probably depends on how often the packages are forked and rebased, and the > >> amount of changes you do above the original packaging > >> > >> It'd be great to have a common naming convention when stacked packaging > >> happens though > >> > > > > Why though? What real problem does it actually solve? > > > > > > Several reasons. > > First, as these packages are maintained upstream (not only the software, > but the spec files and other SRPM bits) it is important to know in which > EVR they are based on. So, if you know that ......6jpp has a fix for > some problem then if the one you have installed is .....6jpp suffix) also has it. That is what Nicholas was talking about. IMHO, this tracking belongs in the upstream versioning, NOT the packaging Release field. This is how every single other OSS package handles it. That's how I know if httpd has a feature in 2.2.1 that isn't in 2.2.0, or if a bug fix is in 2.2.2. > Second, these packages are supposed to interoperate with other > repositories (remember that only a fraction of Java packages is AOT > built on Fedora), so preserving the upstream EVR string is fundamental > for that to work. This ensure no packages are unduly overwritten when > the two repositories are enabled and that the latest version/releases > prevail. Again, if upstream would use the version as it is intended, this would be a non-issue. Packages could depend on foo = %{version} > All Java releases for RHEL have been done this way, by adding _NNrh to > whatever the upstream JPackage EVR was with success. > For Fedora 3 and Fedora package a _NNfc was adopted. Gary Benson used > to have a document describing it, which I thought lived in Fedora pages > somewhere. > > There are hundreds of Java packages there, all rebuilt from upstream > JPackage.org, shipped on Fedora for a couple of years with this EVR > convention. Perhaps its time to revisit this. Yes, it will be painful, but the way that these packages are named is painful. > W.r.t. the suffix added after the upstream EVR it does not really > matter. If this is indeed the case, lets drop it altogether. Adding this suffix (and the jpp naming) is merely going to cause rpm confusion down the road. Especially if every repo that is supposed to be interoperable with the same set of packages is using a different suffix. I'm really going to stand firm on this one, and unless I'm outvoted in the Fedora Packaging Committee, I don't see us permitting this JPackage naming scheme. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Wed Jul 12 19:52:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 21:52:06 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121544.58894.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <200607121544.58894.jkeating@redhat.com> Message-ID: <1152733926.10992.17.camel@rousalka.dyndns.org> Le mercredi 12 juillet 2006 ? 15:44 -0400, Jesse Keating a ?crit : > On Wednesday 12 July 2006 15:18, Fernando Nasser wrote: > > First, as these packages are maintained upstream (not only the software, > > but the spec files and other SRPM bits) it is important to know in which > > EVR they are based on. So, if you know that ......6jpp has a fix for > > some problem then if the one you have installed is .....6jpp > suffix) also has it. That is what Nicholas was talking about. > > This almost sounds like it should be in the name of the package instead. > You're repackaging a package, but want to keep the upstream package > information. foo-6jpp-release-version. Or if you _really_ have to, move it > to the Version field, not the release field. If you move it to the version you're breaking jpp -> fc upgrade paths If you put it as Provides it's ok from the package manager POW but not for users (there are reasons why we use long descriptive filenames and not DOS-like 8:3 names) Sure it's not necessary from the package manager POW but nor is the alphatag and we are still requiring descriptive alphatags. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kwade at redhat.com Wed Jul 12 19:53:52 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 12 Jul 2006 12:53:52 -0700 Subject: Wiki Docs/Beats opened for changes for Web-only release notes Message-ID: <1152734032.7064.215.camel@erato.phig.org> You may continue to edit the Wiki at: http://fedoraproject.org/wiki/Docs/Beats Next Monday we are going to take another snapshot to output to XML[1] and make available as a Web-only release notes to coincide with the test2 release. This test release notes is the last one that you can afford to leave your project's content empty. If you do not have content in place for test3, your content does not gain the community vetting before FC6 release. So, please come follow the open content methodology. - Karsten [1] We used a Wiki running the new code from the Summer of Code project that has already greatly improved the XML output capabilities of Moin Moin. When this SoC project is completed, it is going to be very, very easy to use the Wiki as a drafting and authoring tool, then output to XML/XHTML for DocBook and the Plone CMS. -- 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 nicolas.mailhot at laposte.net Wed Jul 12 19:54:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 21:54:28 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060712214433.137610a1.bugs.michael@gmx.net> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712214433.137610a1.bugs.michael@gmx.net> Message-ID: <1152734069.10992.19.camel@rousalka.dyndns.org> Le mercredi 12 juillet 2006 ? 21:44 +0200, Michael Schwendt a ?crit : > On Wed, 12 Jul 2006 13:30:42 +0200 (CEST), Nicolas Mailhot wrote: > > > > > Le Mer 12 juillet 2006 12:45, Michael Schwendt a ?crit : > > > > > %{?dist} is a variable, giving the false impression that the source > > > package may be valid for arbitrary dist releases and that filling it in > > > would be enough and that no other package updates are required. Even > > > worse, the dist tag enters the file names of the built packages. > > > > If you know your package will break on another release because foo package > > was updated and changed its behaviour, you should require or BR foo with > > the right version > > Who said there exists such a dependency or BR? If you know it will break with some other FC/FE version there is such a dependency or BR If you don't know it will break, restricting the package in any way is 100% useless silliness Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Wed Jul 12 19:54:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 15:54:52 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712175532.GA26268@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> Message-ID: <20060712195452.GA3323@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Wed, Jul 12, 2006 at 01:50:46PM -0400, Bill Nottingham wrote: > > > > Well I would go with a list of links at the end of each name in parenthesis: > > > > > > > > For the latest Fedora: http://fedoraproject.org/wiki/ > > > > For Red Hat Enterprise: http://www.redhat.com/rhel-link-goes-here > > > > For a comparable OS: http://www.centos.org,https://www.scientificlinux.org/ > > > > > > Good suggestion, thanks. Will, in fact, anyone be unhappy if I point to > > > Scientific Linux or CentOS in this way? > > For RHL bugs in Red Hat's bugzilla? Yeah, I'm a little leery about that. > > See, I thought maybe there would be some concern. :) > > > There's also http://www.redhat.com/rhel/migrate/whichlinux/ which you > > can point to. > > That's a little more marketspeaky/anti-fedora than I'd like. ("None", > "None", "None", "None", "N/A", etc.) OK, so how about just: For the latest Fedora Core: http://fedoraproject.org/ For Red Hat Enterprise Linux: http://www.redhat.com/rhel/migrate/redhatlinux/ Bill From jkeating at redhat.com Wed Jul 12 20:03:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 16:03:33 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152733926.10992.17.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121544.58894.jkeating@redhat.com> <1152733926.10992.17.camel@rousalka.dyndns.org> Message-ID: <200607121603.33532.jkeating@redhat.com> On Wednesday 12 July 2006 15:52, Nicolas Mailhot wrote: > If you move it to the version you're breaking jpp -> fc upgrade paths > If you put it as Provides it's ok from the package manager POW but not > for users (there are reasons why we use long descriptive filenames and > not DOS-like 8:3 names) In which ways are we breaking it? jpp has foo-2.6.0-6jpp. Fedora has foo-2.6.0.6jpp-1.fc6. 2.6.0.6 is rpmnewer than 2.6.0-6, upgrade path exists. If jpp issues 2.6.0-7jpp, its going to be newer than what FC provides yes, but do we want users picking up that package? Shouldn't they stay with the FC provided one? Or do you want it replaced and then replaced again when FC bumps the package? So then put it in the name rather than the version. "Upstream": foo-2.6.0-6jpp Name: foo-6jpp Version: 2.6.0 Release: 1%{?dist} Provides: foo = 2.6.0-6jpp -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Jul 12 20:15:10 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Jul 2006 16:15:10 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121603.33532.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121544.58894.jkeating@redhat.com> <1152733926.10992.17.camel@rousalka.dyndns.org> <200607121603.33532.jkeating@redhat.com> Message-ID: <1152735310.10660.9.camel@aglarond.local> On Wed, 2006-07-12 at 16:03 -0400, Jesse Keating wrote: > On Wednesday 12 July 2006 15:52, Nicolas Mailhot wrote: > > If you move it to the version you're breaking jpp -> fc upgrade paths > > If you put it as Provides it's ok from the package manager POW but not > > for users (there are reasons why we use long descriptive filenames and > > not DOS-like 8:3 names) > > In which ways are we breaking it? jpp has foo-2.6.0-6jpp. Fedora has > foo-2.6.0.6jpp-1.fc6. 2.6.0.6 is rpmnewer than 2.6.0-6, upgrade path exists. > If jpp issues 2.6.0-7jpp, its going to be newer than what FC provides yes, > but do we want users picking up that package? Shouldn't they stay with the > FC provided one? Or do you want it replaced and then replaced again when FC > bumps the package? This breaks if upstream ever releases foo-2.6.0.1. Jeremy From fnasser at redhat.com Wed Jul 12 20:14:03 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 12 Jul 2006 16:14:03 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121603.33532.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121544.58894.jkeating@redhat.com> <1152733926.10992.17.camel@rousalka.dyndns.org> <200607121603.33532.jkeating@redhat.com> Message-ID: <44B5580B.3070709@redhat.com> Jesse Keating wrote: > On Wednesday 12 July 2006 15:52, Nicolas Mailhot wrote: > >> If you move it to the version you're breaking jpp -> fc upgrade paths >> If you put it as Provides it's ok from the package manager POW but not >> for users (there are reasons why we use long descriptive filenames and >> not DOS-like 8:3 names) >> > > In which ways are we breaking it? jpp has foo-2.6.0-6jpp. Fedora has > foo-2.6.0.6jpp-1.fc6. Why? I've answered your question, you did not answer mine. > 2.6.0.6 is rpmnewer than 2.6.0-6, upgrade path exists. > Where does the version ends and the relase begins in this? 6jpp is part of the release, not the version, and it can be prefixed. What do you do with foo-2.7-0.cvs20060123.4jpp ? > If jpp issues 2.6.0-7jpp, its going to be newer than what FC provides yes, > but do we want users picking up that package? Shouldn't they stay with the > FC provided one? Or do you want it replaced and then replaced again when FC > bumps the package? > > We want the upstream package to take precedence, as fixes go there first. Once we import that version and produce a pre-compiled (AOT) equivalent, that takes precedence. > So then put it in the name rather than the version. > > "Upstream": foo-2.6.0-6jpp > > Name: foo-6jpp > Version: 2.6.0 > Release: 1%{?dist} > > Provides: foo = 2.6.0-6jpp > > Versions in package names? The namespace will explode in no time, no history, imagine adding new packages all the time to the bug repository lists, and so on. Huge implications. We do have a few release-marked packages but that is done only as an extreme measure due to incompatible API changes and usually for a limited time (the versioned package is just kept for backward compatibility purposes for the least possible time). Regards, Fernando From nicolas.mailhot at laposte.net Wed Jul 12 20:17:45 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 22:17:45 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121603.33532.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121544.58894.jkeating@redhat.com> <1152733926.10992.17.camel@rousalka.dyndns.org> <200607121603.33532.jkeating@redhat.com> Message-ID: <1152735465.10992.25.camel@rousalka.dyndns.org> Le mercredi 12 juillet 2006 ? 16:03 -0400, Jesse Keating a ?crit : > On Wednesday 12 July 2006 15:52, Nicolas Mailhot wrote: > > If you move it to the version you're breaking jpp -> fc upgrade paths > > If you put it as Provides it's ok from the package manager POW but not > > for users (there are reasons why we use long descriptive filenames and > > not DOS-like 8:3 names) > > In which ways are we breaking it? jpp has foo-2.6.0-6jpp. Fedora has > foo-2.6.0.6jpp-1.fc6. 2.6.0.6 is rpmnewer than 2.6.0-6, upgrade path exists. But not it the right direction -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fnasser at redhat.com Wed Jul 12 20:21:32 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 12 Jul 2006 16:21:32 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152733661.12430.394.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> Message-ID: <44B559CC.40900@redhat.com> Tom 'spot' Callaway wrote: >> First, as these packages are maintained upstream (not only the software, >> but the spec files and other SRPM bits) it is important to know in which >> EVR they are based on. So, if you know that ......6jpp has a fix for >> some problem then if the one you have installed is .....6jpp> suffix) also has it. That is what Nicholas was talking about. >> > > IMHO, this tracking belongs in the upstream versioning, NOT the > packaging Release field. This is how every single other OSS package > handles it. That's how I know if httpd has a feature in 2.2.1 that isn't > in 2.2.0, or if a bug fix is in 2.2.2. > > You are not considering the two levels of usptream. The upstream here is the RPM, not the sotware. The Java RPM packages are created and maintained by a community upstream, just imported into Fedora (and Suse and RHEL, and Mandriva and....) As they are RPMs, they already have a Release field which indicates the packaging version. The version field is indeed from the upstream**2 as you say it should. Regards, Fernando From nicolas.mailhot at laposte.net Wed Jul 12 20:21:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 22:21:32 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152733661.12430.394.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> Message-ID: <1152735692.10992.29.camel@rousalka.dyndns.org> Le mercredi 12 juillet 2006 ? 14:47 -0500, Tom 'spot' Callaway a ?crit : > On Wed, 2006-07-12 at 15:18 -0400, Fernando Nasser wrote: > > Jesse Keating wrote: > > All Java releases for RHEL have been done this way, by adding _NNrh to > > whatever the upstream JPackage EVR was with success. > > For Fedora 3 and Fedora package a _NNfc was adopted. Gary Benson used > > to have a document describing it, which I thought lived in Fedora pages > > somewhere. > > > > There are hundreds of Java packages there, all rebuilt from upstream > > JPackage.org, shipped on Fedora for a couple of years with this EVR > > convention. > > Perhaps its time to revisit this. Yes, it will be painful, but the way > that these packages are named is painful. So you're arguing to break technical features just because you find the current naming ugly ? How about working on a less-ugly naming with the same characteristics > > W.r.t. the suffix added after the upstream EVR it does not really > > matter. > > If this is indeed the case, lets drop it altogether. Adding this suffix > (and the jpp naming) is merely going to cause rpm confusion down the > road. I think it's been used long enough on a packageset big enough to show this is not the case -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Wed Jul 12 20:34:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 16:34:02 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B5580B.3070709@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121603.33532.jkeating@redhat.com> <44B5580B.3070709@redhat.com> Message-ID: <200607121634.02588.jkeating@redhat.com> On Wednesday 12 July 2006 16:14, Fernando Nasser wrote: > Versions in package names? ?The namespace will explode in no time, no > history, imagine adding new packages all the time to the bug repository > lists, and so on. ?Huge implications. But now we have upstream versions in downstream releases and release namespace is exploading. So putting it in the name is wrong, putting it in version is wrong, putting it in release is wrong, that leaves Provides. It seems to me that the only REAL reason for having the jpp in the nevr is for user visibility, which could be accomplished by rpm -q --provides. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Jul 12 20:46:50 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 16:46:50 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712195452.GA3323@nostromo.devel.redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> Message-ID: <20060712204650.GA1928@jadzia.bu.edu> On Wed, Jul 12, 2006 at 03:54:52PM -0400, Bill Nottingham wrote: > > That's a little more marketspeaky/anti-fedora than I'd like. ("None", > > "None", "None", "None", "N/A", etc.) > > OK, so how about just: > For the latest Fedora Core: http://fedoraproject.org/ > For Red Hat Enterprise Linux: http://www.redhat.com/rhel/migrate/redhatlinux/ Yeah. Does the phrase "or comparable" after RHEL in the text bother you? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fnasser at redhat.com Wed Jul 12 20:58:49 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 12 Jul 2006 16:58:49 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152735692.10992.29.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> Message-ID: <44B56289.9000203@redhat.com> Nicolas Mailhot wrote: > I think it's been used long enough on a packageset big enough to show > this is not the case > > And this sounds like an extemporaneous nitypicking for me. I was not yet given a technical reason for changing, just someone's subjective sense of esthetics. It is a huge change, on a huge number of packages, involving an upstream community that does this work for years, on something that has been done successifuly for two generations of Fedora Core (FC3 and FC4) plus several releases on RHEL (not to mention Suse Mandriva et al.) and the changes proposed have serious practical implications as already noted on this thread (and note also that the people now requesting a change have been dealing with this same release naming for all this time.) And for what? What are the technical advantages that will be obtained with this change? If we knew what effect wants to be obtained we could perhaps think together in a better way to solve it. I strongly suggest that we spend our time producing something that can improve the experience for Fedora 6 users. Like an updated AOT compiled Java stack with Open Source AppServers on it. What about better video drivers? I had to give up on my dual-head video card when upgrading to Fedora 5 (a real regression)? And instead we are discussing an established release tagging scheme? What a waste of cycles. Is there any _constructive_ way to resolve this issue? There is a clear distinction between the Java stack and ordinary packages, like two levels of upstream, Java-specific develper communities characteristics, etc. What about proposing making Gary Benson's description of the Java packages tagging official for Java packages, as it has already been used for Fc3 and FC4 and it is basically the same used by other Linux distros (Red Hat RHEL, Nocvell Suse, Mandriva..)? Regards to all, Fernando From tcallawa at redhat.com Wed Jul 12 21:05:36 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 12 Jul 2006 16:05:36 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B56289.9000203@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> Message-ID: <1152738336.12430.426.camel@localhost.localdomain> On Wed, 2006-07-12 at 16:58 -0400, Fernando Nasser wrote: > And for what? What are the technical advantages that will be obtained > with this change? If we knew what effect wants to be obtained we could > perhaps think together in a better way to solve it. Consistency, cleanliness, and organization. If we permit this off the wall naming scheme which violates the Fedora Naming Guidelines for the Java packages, we open the door for every other possible group to abuse the namespace. I'm willing to put this in front of the Fedora Packaging Committee for a vote, but I fully intend to vote against it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toshio at tiki-lounge.com Wed Jul 12 21:14:37 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 12 Jul 2006 14:14:37 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B56289.9000203@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> Message-ID: <1152738877.5959.2.camel@localhost> On Wed, 2006-07-12 at 16:58 -0400, Fernando Nasser wrote: > Is there any _constructive_ way to resolve this issue? > > There is a clear distinction between the Java stack and ordinary > packages, like two levels of upstream, Java-specific develper > communities characteristics, etc. What about proposing making Gary > Benson's description of the Java packages tagging official for Java > packages, as it has already been used for Fc3 and FC4 Could you send a link to Gary Benson's description please? Then we'll be able to comment on the rules the java package naming is following currently, rather than just seeing how it deviates from the rest of the distribution. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dlutter at redhat.com Wed Jul 12 22:16:54 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 12 Jul 2006 15:16:54 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607121634.02588.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121603.33532.jkeating@redhat.com> <44B5580B.3070709@redhat.com> <200607121634.02588.jkeating@redhat.com> Message-ID: <1152742614.26066.26.camel@localhost.localdomain> On Wed, 2006-07-12 at 16:34 -0400, Jesse Keating wrote: > On Wednesday 12 July 2006 16:14, Fernando Nasser wrote: > > Versions in package names? The namespace will explode in no time, no > > history, imagine adding new packages all the time to the bug repository > > lists, and so on. Huge implications. > > But now we have upstream versions in downstream releases and release namespace > is exploading. So putting it in the name is wrong, putting it in version is > wrong, putting it in release is wrong, that leaves Provides. It seems to me > that the only REAL reason for having the jpp in the nevr is for user > visibility, which could be accomplished by rpm -q --provides. There is also the issue that people want to get the latest from jpackage _or_ Fedora, whichever is newer, so it's not just cosmetic. The order that is wanted is 1jpp < 1jpp.1.fc5 < 2jpp < 2jpp.1.fc5 etc. I can't think of another scheme to achieve this interleaving given that both the name and the version are fixed (cause they are determined by the upstream source) and that jpackage needs to set some sort of release for their packages, too. David From toshio at tiki-lounge.com Wed Jul 12 23:14:21 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 12 Jul 2006 16:14:21 -0700 Subject: Packaging Committee Information Message-ID: <1152746061.5959.13.camel@localhost> I've started a page for packaging committee with the date and time of the meetings and other information. If you want to find out about the packaging committee go ahead and read it. If you're on the Packaging Committee and want to hack it, go ahead. If you don't have permission to edit the page but want something added or modified, send mail to fedora-packaging or hop onto #fedora-packaging on IRC. http://www.fedoraproject.org/wiki/Packaging/Committee -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Jul 12 22:16:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 18:16:37 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712204650.GA1928@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> <20060712204650.GA1928@jadzia.bu.edu> Message-ID: <20060712221637.GA24754@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Wed, Jul 12, 2006 at 03:54:52PM -0400, Bill Nottingham wrote: > > > That's a little more marketspeaky/anti-fedora than I'd like. ("None", > > > "None", "None", "None", "N/A", etc.) > > > > OK, so how about just: > > For the latest Fedora Core: http://fedoraproject.org/ > > For Red Hat Enterprise Linux: http://www.redhat.com/rhel/migrate/redhatlinux/ > > Yeah. Does the phrase "or comparable" after RHEL in the text bother you? Red Hat Linux was a Red Hat product, sold and supported; if we're going to close out bugs in that, we should really point to the official Red Hat, um, 'descendants.' Actually, come to think of it, it probably should be a @redhat person doing the bug closing too. Bill From mattdm at mattdm.org Wed Jul 12 23:57:34 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 19:57:34 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712221637.GA24754@nostromo.devel.redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> <20060712204650.GA1928@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> Message-ID: <20060712235734.GA8421@jadzia.bu.edu> On Wed, Jul 12, 2006 at 06:16:37PM -0400, Bill Nottingham wrote: Red Hat > Linux was a Red Hat product, sold and supported; if we're going to close > out bugs in that, we should really point to the official Red Hat, um, > 'descendants.' Yeah, but ignoring the business side (which I recognize as an important side), CentOS is often the best choice for many people stuck on RHL 9 or 7.3. And my goal is really to do the best thing for the people who went to all the trouble to report a bug. > Actually, come to think of it, it probably should be a @redhat person > doing the bug closing too. I agree for the pre-7.3 (and the poor, lonely 8), but 7.3 and 9 are currently maintained by Legacy, so I don't feel bad about putting them into NEEDINFO. If a Red Hat person would do the actual closing in early 2007, that'd be cool. Does someone @redhat want to do the honors on the ancient ones sometime soon? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From toshio at tiki-lounge.com Thu Jul 13 01:52:07 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 12 Jul 2006 18:52:07 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152738877.5959.2.camel@localhost> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> Message-ID: <1152755527.5959.60.camel@localhost> On Wed, 2006-07-12 at 14:14 -0700, Toshio Kuratomi wrote: > On Wed, 2006-07-12 at 16:58 -0400, Fernando Nasser wrote: > > Is there any _constructive_ way to resolve this issue? > > > > There is a clear distinction between the Java stack and ordinary > > packages, like two levels of upstream, Java-specific develper > > communities characteristics, etc. What about proposing making Gary > > Benson's description of the Java packages tagging official for Java > > packages, as it has already been used for Fc3 and FC4 > > Could you send a link to Gary Benson's description please? Then we'll > be able to comment on the rules the java package naming is following > currently, rather than just seeing how it deviates from the rest of the > distribution. Well, I found these links for emails from Gary Benson. http://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00082.html Is a post by gbenson that says that he was going to propose the Xjpp_Nfc release tag for the Package Naming Guidelines. Unfortunately, it doesn't look like he followed up on that at the time. http://www.redhat.com/archives/fedora-devel-java-list/2005-September/msg00082.html Is another post by gbenson. This one says that the local modifications to the jpackage packages could include bugfixes, native compiled code and other things that will not get merged with upstream(jpp). So you do not want to flip flop from Fedora provided package to jpp package. http://www.redhat.com/archives/fedora-devel-java-list/2005-September/msg00038.html Also within that thread is this message from Thomas Fitzsimmons where he says that Fedora users should prefer Fedora packages when available and jpackage packages otherwise. This can't work 100% with either the Xjpp_Nfc or N.fcZ schemes. It could with something like 9Xjpp.N.fcZ but I shudder to think I even mentioned that. So it looks like the idea of "upgrading" from a Fedora package to JPackage to Fedora that was expressed by Fernando Nasser [1]_ is an anti-goal (ie: It is explicitly not the desired behaviour.) This leaves the use of Xjpp_Nfc to indicate what jpackage version it was derived from. Nicolas has said users and packagers need to find this information in the release tag. After reading the archives that say users should stick to Fedora packages when they're available, I don't see why users should know this. kernel packages don't have the git tree they're based off in the filename, only in the changelog for the same reason. The package should just work or Fedora will provide an update that does. packagers may find it convenient to know the jpackage fork with a glance at the filename. But it doesn't need to be there. It needs to be readily found by the packager. Is the filename really the best place for this? When you check out the cvs tree for a package, there's no rpm prebuilt so having the jpp information in the filename doesn't help. You still have to read the spec file to find out what upstream version it's built on. Once you read the spec file, it doesn't matter if its in the Release, a comment, or a Provides: foo-jpp = 6; they're pretty much equally convenient. My first choice, then, would be to not include the jpp version in NEVR. If someone does come up with a convincing reason to put the jpp version in the NEVR, then I think the post release snapshot guidelines are the closest current guidelines. So jpackage packages would end up like this: Current: jgroups-2.2.6-1jpp_4fc.src.rpm New: jgroups-2.2.6-4.1jpp.fc6.src.rpm With a cvs snapshot: jgroups-2.2.6-4.1jpp.20060707cvs.fc6.src.rpm [1]_ http://www.redhat.com/archives/fedora-maintainers/2006-July/msg00255.html -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Thu Jul 13 01:57:09 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 12 Jul 2006 18:57:09 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152755527.5959.60.camel@localhost> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> Message-ID: <1152755829.5959.63.camel@localhost> On Wed, 2006-07-12 at 18:52 -0700, Toshio Kuratomi wrote: > http://www.redhat.com/archives/fedora-devel-java-list/2005-September/msg00038.html > Also within that thread is this message from Thomas Fitzsimmons where he > says that Fedora users should prefer Fedora packages when available and > jpackage packages otherwise. This can't work 100% with either the > Xjpp_Nfc or N.fcZ schemes. It could with something like 9Xjpp.N.fcZ but > I shudder to think I even mentioned that. Scratch that. It takes care of new releases pretty well but doesn't handle new upstream versions. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu Jul 13 02:13:34 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 13 Jul 2006 07:43:34 +0530 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712175532.GA26268@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> Message-ID: <44B5AC4E.4020606@fedoraproject.org> Matthew Miller wrote: > On Wed, Jul 12, 2006 at 01:50:46PM -0400, Bill Nottingham wrote: >>>> Well I would go with a list of links at the end of each name in parenthesis: >>>> >>>> For the latest Fedora: http://fedoraproject.org/wiki/ >>>> For Red Hat Enterprise: http://www.redhat.com/rhel-link-goes-here >>>> For a comparable OS: http://www.centos.org,https://www.scientificlinux.org/ >>> Good suggestion, thanks. Will, in fact, anyone be unhappy if I point to >>> Scientific Linux or CentOS in this way? >> For RHL bugs in Red Hat's bugzilla? Yeah, I'm a little leery about that. > > See, I thought maybe there would be some concern. :) > >> There's also http://www.redhat.com/rhel/migrate/whichlinux/ which you >> can point to. > > That's a little more marketspeaky/anti-fedora than I'd like. ("None", > "None", "None", "None", "N/A", etc.) Max Spevack (cc'ed) earlier said he would look into this. Rahul From sundaram at fedoraproject.org Thu Jul 13 02:41:25 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 13 Jul 2006 08:11:25 +0530 Subject: Mass Rebuild to begin tomorrow (Tuesday, July 11) In-Reply-To: <6280325c0607112239w8238749seaafb49ef79cd55d@mail.gmail.com> References: <200607101310.17402.jkeating@redhat.com> <200607101322.05453.jkeating@redhat.com> <20060710201121.GH3115@devserv.devel.redhat.com> <6280325c0607112239w8238749seaafb49ef79cd55d@mail.gmail.com> Message-ID: <44B5B2D5.5000901@fedoraproject.org> n0dalus wrote: > On 7/11/06, Jakub Jelinek wrote: >> >> Just a quick note what changed: >> In ELF, .hash section (with DT_HASH dynamic tag pointing to it) is used >> during dynamic linking for symbol lookup, the dynamic linker for each >> symbol >> it needs to resolve uses that section to map it to a set of symbol >> indexes >> of possible symbol definitions. >> >> We wrote changes that introduce a new section (.gnu.hash, DT_GNU_HASH >> dynamic tag) that serves the same purpose, but is much more efficient >> (gives far fewer symbol definition candidates and uses far fewer >> cachelines). >> > > Is this for speeding up building or does this speed up program > startup? How much faster is using .gnu.hash over .hash? > This was all discussion earlier in the same list. Details at http://sources.redhat.com/ml/binutils/2006-06/msg00418.html Rahul From notting at redhat.com Thu Jul 13 02:48:09 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 22:48:09 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712235734.GA8421@jadzia.bu.edu> References: <20060711171846.GA17627@jadzia.bu.edu> <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> <20060712204650.GA1928@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> Message-ID: <20060713024809.GA27340@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Wed, Jul 12, 2006 at 06:16:37PM -0400, Bill Nottingham wrote: Red Hat > > Linux was a Red Hat product, sold and supported; if we're going to close > > out bugs in that, we should really point to the official Red Hat, um, > > 'descendants.' > > Yeah, but ignoring the business side (which I recognize as an important > side), CentOS is often the best choice for many people stuck on RHL 9 or > 7.3. And my goal is really to do the best thing for the people who went to > all the trouble to report a bug. Yeah, but really, these could very well be bugs from people who paid Red Hat money. The more I think about it, I feel it's best that someone from Red Hat take the task to do this, as it's really our responsiblity. Heck, I'll do it, but it may not be tonight. Bill From notting at redhat.com Thu Jul 13 02:51:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 22:51:16 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060713024809.GA27340@nostromo.devel.redhat.com> References: <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> <20060712204650.GA1928@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <20060713024809.GA27340@nostromo.devel.redhat.com> Message-ID: <20060713025116.GB27340@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Matthew Miller (mattdm at mattdm.org) said: > > On Wed, Jul 12, 2006 at 06:16:37PM -0400, Bill Nottingham wrote: Red Hat > > > Linux was a Red Hat product, sold and supported; if we're going to close > > > out bugs in that, we should really point to the official Red Hat, um, > > > 'descendants.' > > > > Yeah, but ignoring the business side (which I recognize as an important > > side), CentOS is often the best choice for many people stuck on RHL 9 or > > 7.3. And my goal is really to do the best thing for the people who went to > > all the trouble to report a bug. > > Yeah, but really, these could very well be bugs from people who paid Red > Hat money. The more I think about it, I feel it's best that someone from > Red Hat take the task to do this, as it's really our responsiblity. BTW, if someone on the board level hasn't said it before, we really do appreciate all the work you're putting into this - it's just that RH should really take the pain for the old RHL bugs. Bill From mattdm at mattdm.org Thu Jul 13 03:13:15 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 23:13:15 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060713024809.GA27340@nostromo.devel.redhat.com> References: <20060712155848.GA20076@jadzia.bu.edu> <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> <20060712204650.GA1928@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <20060713024809.GA27340@nostromo.devel.redhat.com> Message-ID: <20060713031315.GA14866@jadzia.bu.edu> On Wed, Jul 12, 2006 at 10:48:09PM -0400, Bill Nottingham wrote: > Yeah, but really, these could very well be bugs from people who paid Red > Hat money. The more I think about it, I feel it's best that someone from > Red Hat take the task to do this, as it's really our responsiblity. > Heck, I'll do it, but it may not be tonight. Cool. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 13 03:16:16 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 23:16:16 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060713025116.GB27340@nostromo.devel.redhat.com> References: <80d7e4090607120916l55c718b1y41a5a558522c227c@mail.gmail.com> <20060712174107.GA25617@jadzia.bu.edu> <20060712175045.GA30012@nostromo.devel.redhat.com> <20060712175532.GA26268@jadzia.bu.edu> <20060712195452.GA3323@nostromo.devel.redhat.com> <20060712204650.GA1928@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <20060713024809.GA27340@nostromo.devel.redhat.com> <20060713025116.GB27340@nostromo.devel.redhat.com> Message-ID: <20060713031616.GB14866@jadzia.bu.edu> On Wed, Jul 12, 2006 at 10:51:16PM -0400, Bill Nottingham wrote: > BTW, if someone on the board level hasn't said it before, we really do > appreciate all the work you're putting into this - it's just that RH > should really take the pain for the old RHL bugs. Thanks. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Thu Jul 13 03:41:45 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 13 Jul 2006 09:11:45 +0530 Subject: Move dbus-qt into Fedora Core? Message-ID: <44B5C0F9.2000309@fedoraproject.org> Hi dbus-qt is a package in Fedora Extras that K3b (as a build time optional dependency whicht takes advantage of hal to do things better) and possibly other KDE applications can take advantage of. If KDE itself is not being moved into Fedora Extras repository before the FC6 release (realistically by the second test release) then we probably should import dbus-qt into Fedora Core. A related bug report - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176106 Rahul From sundaram at fedoraproject.org Thu Jul 13 05:09:19 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 13 Jul 2006 10:39:19 +0530 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B56289.9000203@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> Message-ID: <44B5D57F.5070500@fedoraproject.org> Fernando Nasser wrote: > Nicolas Mailhot wrote: >> I think it's been used long enough on a packageset big enough to show >> this is not the case >> >> > And this sounds like an extemporaneous nitypicking for me. I was not yet > given a technical reason for changing, just someone's subjective sense > of esthetics. > > It is a huge change, on a huge number of packages, involving an upstream > community that does this work for years, on something that has been done > successifuly for two generations of Fedora Core (FC3 and FC4) plus > several releases on RHEL (not to mention Suse Mandriva et al.) and the > changes proposed have serious practical implications as already noted on > this thread (and note also that the people now requesting a change have > been dealing with this same release naming for all this time.) > > And for what? What are the technical advantages that will be obtained > with this change? If we knew what effect wants to be obtained we could > perhaps think together in a better way to solve it. > > I strongly suggest that we spend our time producing something that can > improve the experience for Fedora 6 users. Like an updated AOT compiled > Java stack with Open Source AppServers on it. What about better video > drivers? I had to give up on my dual-head video card when upgrading to > Fedora 5 (a real regression)? Have a bug report on that? Arguing that we shouldnt talk about packaging issues just because we have a video driver regression is like claiming that people should fix kernel bugs instead of drawing new icons. It ignores the fact that multiple people with different skill sets are working on these issues and spending time on one doesnt take away the time spend on another. Rahul From jamatos at fc.up.pt Thu Jul 13 05:58:38 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 13 Jul 2006 06:58:38 +0100 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060712235734.GA8421@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> Message-ID: <200607130658.39480.jamatos@fc.up.pt> On Thursday 13 July 2006 00:57, Matthew Miller wrote: > On Wed, Jul 12, 2006 at 06:16:37PM -0400, Bill Nottingham wrote: Red Hat > > > Linux was a Red Hat product, sold and supported; if we're going to close > > out bugs in that, we should really point to the official Red Hat, um, > > 'descendants.' > > Yeah, but ignoring the business side (which I recognize as an important > side), CentOS is often the best choice for many people stuck on RHL 9 or > 7.3. And my goal is really to do the best thing for the people who went to > all the trouble to report a bug. With all the due respect Matthew but if people don't know CentOS by now, I don't think that it is a bugzilla entry that will make any difference. For completeness what you are trying to do makes sense, in practical terms I doubt about the efficacy of it. Please take this as constructive critic that it is, I appreciate the work that you doing. :-) -- Jos? Ab?lio From nicolas.mailhot at laposte.net Thu Jul 13 06:43:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Jul 2006 08:43:28 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152755527.5959.60.camel@localhost> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> Message-ID: <1152773008.21931.8.camel@rousalka.dyndns.org> Le mercredi 12 juillet 2006 ? 18:52 -0700, Toshio Kuratomi a ?crit : > So it looks like the idea of "upgrading" from a Fedora package to > JPackage to Fedora that was expressed by Fernando Nasser [1]_ is an > anti-goal (ie: It is explicitly not the desired behaviour.) The migration is more jpp -> fc but even if fc -> jpp should never be desirable ideally the truth is fc sometimes lags behind and users would rather use the latest jpp package than the old fc-customized one. It's not a simple problem-space. Someone wrote the other day FC had all the hard packages - well java packages are so hard Fedora mostly didn't do them before JPP arrived to help it (and BTW if you don't like what JPP produces it's an FLOSS project they'll gladly accept any helping hand) Ideally Fedora would have the manpower to package everything jpp does (and more) but we're not in an ideal world. The current convention tries to make the best of the existing situation for Fedora users. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mattdm at mattdm.org Thu Jul 13 10:54:33 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Jul 2006 06:54:33 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <200607130658.39480.jamatos@fc.up.pt> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> Message-ID: <20060713105433.GA28661@jadzia.bu.edu> On Thu, Jul 13, 2006 at 06:58:38AM +0100, Jose' Matos wrote: With all the > due respect Matthew but if people don't know CentOS by now, I > don't think that it is a bugzilla entry that will make any difference. You might be surprised then about the number of "Red Hat 9 is going away? I have NO CHOICE but to switch to [some other distro]" type comments Legacy gets. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From arjan at fenrus.demon.nl Thu Jul 13 11:04:34 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 13 Jul 2006 13:04:34 +0200 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060713105433.GA28661@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> <20060713105433.GA28661@jadzia.bu.edu> Message-ID: <1152788674.3024.35.camel@laptopd505.fenrus.org> On Thu, 2006-07-13 at 06:54 -0400, Matthew Miller wrote: > On Thu, Jul 13, 2006 at 06:58:38AM +0100, Jose' Matos wrote: With all the > > due respect Matthew but if people don't know CentOS by now, I > > don't think that it is a bugzilla entry that will make any difference. > > You might be surprised then about the number of "Red Hat 9 is going away? I > have NO CHOICE but to switch to [some other distro]" type comments Legacy > gets. Maybe the answer is "We offer you Fedora as other distro", and maybe it can be preempted by saying "Due to lack of interest, RHL9 support is going away". From mattdm at mattdm.org Thu Jul 13 11:23:53 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Jul 2006 07:23:53 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <1152788674.3024.35.camel@laptopd505.fenrus.org> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> <20060713105433.GA28661@jadzia.bu.edu> <1152788674.3024.35.camel@laptopd505.fenrus.org> Message-ID: <20060713112353.GA29539@jadzia.bu.edu> On Thu, Jul 13, 2006 at 01:04:34PM +0200, Arjan van de Ven wrote: > On Thu, 2006-07-13 at 06:54 -0400, Matthew Miller wrote: > > On Thu, Jul 13, 2006 at 06:58:38AM +0100, Jose' Matos wrote: With all the > > > due respect Matthew but if people don't know CentOS by now, I > > > don't think that it is a bugzilla entry that will make any difference. > > You might be surprised then about the number of "Red Hat 9 is going away? I > > have NO CHOICE but to switch to [some other distro]" type comments Legacy > > gets. > Maybe the answer is "We offer you Fedora as other distro", and maybe it That's certainly *an* answer. However, someone who has stayed on RHL 9 for so long probably has done so because they really *don't* want a bunch of things which are design goals for Fedora, including "rapid change" and "leading edge". > can be preempted by saying "Due to lack of interest, RHL9 support is > going away". Well, that's a problem -- there's really not a lack of interest. There's lack of resources, but not interest. And by definition, anyone who wants RHL9 still supported will respond to the above with "But *I* am interested!" -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From alan at redhat.com Thu Jul 13 12:11:24 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 13 Jul 2006 08:11:24 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060713112353.GA29539@jadzia.bu.edu> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> <20060713105433.GA28661@jadzia.bu.edu> <1152788674.3024.35.camel@laptopd505.fenrus.org> <20060713112353.GA29539@jadzia.bu.edu> Message-ID: <20060713121124.GB13690@devserv.devel.redhat.com> On Thu, Jul 13, 2006 at 07:23:53AM -0400, Matthew Miller wrote: > Well, that's a problem -- there's really not a lack of interest. There's > lack of resources, but not interest. And by definition, anyone who wants > RHL9 still supported will respond to the above with "But *I* am interested!" Then invite them to become the RHL9 legacy team and see how fast they shut up From skvidal at linux.duke.edu Thu Jul 13 12:13:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 13 Jul 2006 08:13:58 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <20060713121124.GB13690@devserv.devel.redhat.com> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> <20060713105433.GA28661@jadzia.bu.edu> <1152788674.3024.35.camel@laptopd505.fenrus.org> <20060713112353.GA29539@jadzia.bu.edu> <20060713121124.GB13690@devserv.devel.redhat.com> Message-ID: <1152792838.31398.7.camel@cutter> On Thu, 2006-07-13 at 08:11 -0400, Alan Cox wrote: > On Thu, Jul 13, 2006 at 07:23:53AM -0400, Matthew Miller wrote: > > Well, that's a problem -- there's really not a lack of interest. There's > > lack of resources, but not interest. And by definition, anyone who wants > > RHL9 still supported will respond to the above with "But *I* am interested!" > > Then invite them to become the RHL9 legacy team and see how fast they shut > up > from personal experience they won't shut up. They'll just whine more yet do nothing. -sv From arjan at fenrus.demon.nl Thu Jul 13 13:10:20 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 13 Jul 2006 15:10:20 +0200 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <1152792838.31398.7.camel@cutter> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> <20060713105433.GA28661@jadzia.bu.edu> <1152788674.3024.35.camel@laptopd505.fenrus.org> <20060713112353.GA29539@jadzia.bu.edu> <20060713121124.GB13690@devserv.devel.redhat.com> <1152792838.31398.7.camel@cutter> Message-ID: <1152796220.3024.47.camel@laptopd505.fenrus.org> On Thu, 2006-07-13 at 08:13 -0400, seth vidal wrote: > On Thu, 2006-07-13 at 08:11 -0400, Alan Cox wrote: > > On Thu, Jul 13, 2006 at 07:23:53AM -0400, Matthew Miller wrote: > > > Well, that's a problem -- there's really not a lack of interest. There's > > > lack of resources, but not interest. And by definition, anyone who wants > > > RHL9 still supported will respond to the above with "But *I* am interested!" > > > > Then invite them to become the RHL9 legacy team and see how fast they shut > > up > > > > from personal experience they won't shut up. > > They'll just whine more yet do nothing. I suppose at some point it's just a matter of ignoring the whine. If they're not willing to help, and it's a small (yet vocal) group of people... it's their problem. It's not like RHL9 is anywhere near as nice for most things as current FC's are... their loss for not using it From jkeating at redhat.com Thu Jul 13 13:27:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Jul 2006 09:27:05 -0400 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <1152796220.3024.47.camel@laptopd505.fenrus.org> References: <20060707180935.GA17747@jadzia.bu.edu> <1152792838.31398.7.camel@cutter> <1152796220.3024.47.camel@laptopd505.fenrus.org> Message-ID: <200607130927.05532.jkeating@redhat.com> On Thursday 13 July 2006 09:10, Arjan van de Ven wrote: > > from personal experience they won't shut up. > > > > They'll just whine more yet do nothing. > > I suppose at some point it's just a matter of ignoring the whine. If > they're not willing to help, and it's a small (yet vocal) group of > people... it's their problem. It's not like RHL9 is anywhere near as > nice for most things as current FC's are... their loss for not using it I've been ignoring those whiners for a while (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Thu Jul 13 13:40:42 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 13 Jul 2006 07:40:42 -0600 Subject: Drunk on power: FC1 and before.... [was: A Heads-Up: moving all FC3 bugs to "needinfo"] In-Reply-To: <1152796220.3024.47.camel@laptopd505.fenrus.org> References: <20060707180935.GA17747@jadzia.bu.edu> <20060712221637.GA24754@nostromo.devel.redhat.com> <20060712235734.GA8421@jadzia.bu.edu> <200607130658.39480.jamatos@fc.up.pt> <20060713105433.GA28661@jadzia.bu.edu> <1152788674.3024.35.camel@laptopd505.fenrus.org> <20060713112353.GA29539@jadzia.bu.edu> <20060713121124.GB13690@devserv.devel.redhat.com> <1152792838.31398.7.camel@cutter> <1152796220.3024.47.camel@laptopd505.fenrus.org> Message-ID: <80d7e4090607130640p6276db9dy2f4781b24be4cd2f@mail.gmail.com> On 7/13/06, Arjan van de Ven wrote: > On Thu, 2006-07-13 at 08:13 -0400, seth vidal wrote: > > On Thu, 2006-07-13 at 08:11 -0400, Alan Cox wrote: > > > On Thu, Jul 13, 2006 at 07:23:53AM -0400, Matthew Miller wrote: > > > > Well, that's a problem -- there's really not a lack of interest. There's > > > > lack of resources, but not interest. And by definition, anyone who wants > > > > RHL9 still supported will respond to the above with "But *I* am interested!" > > > > > > Then invite them to become the RHL9 legacy team and see how fast they shut > > > up > > > > > > > from personal experience they won't shut up. > > > > They'll just whine more yet do nothing. > > I suppose at some point it's just a matter of ignoring the whine. If > they're not willing to help, and it's a small (yet vocal) group of > people... it's their problem. It's not like RHL9 is anywhere near as > nice for most things as current FC's are... their loss for not using it > I prefer the "SmoogeSpace offers legacy support for Red Hat Linux 7.3/9. Cost is $250.00/hour, minimum 1 hour, first hour in advance. No refunds and no promises, guarentees" I figure PT Barnum might make me rich some day. -- Stephen J Smoogen. CSIRT/Linux System Administrator From bugs.michael at gmx.net Thu Jul 13 14:29:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 13 Jul 2006 16:29:15 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152734069.10992.19.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712214433.137610a1.bugs.michael@gmx.net> <1152734069.10992.19.camel@rousalka.dyndns.org> Message-ID: <20060713162915.57b2ea28.bugs.michael@gmx.net> On Wed, 12 Jul 2006 21:54:28 +0200, Nicolas Mailhot wrote: > Le mercredi 12 juillet 2006 ? 21:44 +0200, Michael Schwendt a ?crit : > > On Wed, 12 Jul 2006 13:30:42 +0200 (CEST), Nicolas Mailhot wrote: > > > > > > > > Le Mer 12 juillet 2006 12:45, Michael Schwendt a ?crit : > > > > > > > %{?dist} is a variable, giving the false impression that the source > > > > package may be valid for arbitrary dist releases and that filling it in > > > > would be enough and that no other package updates are required. Even > > > > worse, the dist tag enters the file names of the built packages. > > > > > > If you know your package will break on another release because foo package > > > was updated and changed its behaviour, you should require or BR foo with > > > the right version > > > > Who said there exists such a dependency or BR? > > If you know it will break with some other FC/FE version there is such a > dependency or BR No. Maybe, maybe sometimes it is possible to put such a requirement into explicit+versioned BR. Ugly. Explicit dependencies on specific versions (or max.versions, which are often guess-work) are ugly. > If you don't know it will break, restricting the package in any way is > 100% useless silliness No, it's packager's freedom to make clear that the src.rpm was created for a specific distribution. And if rebuilt for a different dist, without any changes in the src.rpm contents (e.g. dist-specific patches or options), the resulting binaries should not automatically look like they are for the different dist. From mattdm at mattdm.org Thu Jul 13 15:27:43 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Jul 2006 11:27:43 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060713162915.57b2ea28.bugs.michael@gmx.net> References: <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712214433.137610a1.bugs.michael@gmx.net> <1152734069.10992.19.camel@rousalka.dyndns.org> <20060713162915.57b2ea28.bugs.michael@gmx.net> Message-ID: <20060713152743.GA7290@jadzia.bu.edu> On Thu, Jul 13, 2006 at 04:29:15PM +0200, Michael Schwendt wrote: > No, it's packager's freedom to make clear that the src.rpm was created for > a specific distribution. And if rebuilt for a different dist, without any > changes in the src.rpm contents (e.g. dist-specific patches or options), > the resulting binaries should not automatically look like they are for the > different dist. +1. Or +2 if I can get away with that. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 13 17:33:20 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Jul 2006 13:33:20 -0400 Subject: A request for Core maintainers: please check your FC4 bugs before it's gone. Message-ID: <20060713173320.GA12246@jadzia.bu.edu> As I'm sure everyone Core developer knows (and probably can't wait for), FC4 is going to Legacy in a couple of weeks. I know it's pretty much the definition of Not Fun At All, but if you have some time, could ya'll go through your open FC4 issues and 1) make sure all security bugs are resolved and 2) knock off low-hanging fruit if possible and 3) resolve any serious-but-non-security issues you can? And then actually get updates pushed? *Especially* cases which were filed a long time ago -- people went to the trouble of reporting bugs, and while the "saved by the bell! school's out! no more updates for this release!" solution is sometimes a relief for overworked package maintainers, it's *incredibly* frustrating for the bug reporters. Sure, we'll try to get people on newer releases, but for Fedora to be a viable option in the enthusiast space beyond the absolute geekiest, Legacy is important, and it be a nice gesture to the community for the release to be as clean as (reasonably) possible (given the circumstances). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Thu Jul 13 17:42:22 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Jul 2006 19:42:22 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060713162915.57b2ea28.bugs.michael@gmx.net> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712214433.137610a1.bugs.michael@gmx.net> <1152734069.10992.19.camel@rousalka.dyndns.org> <20060713162915.57b2ea28.bugs.michael@gmx.net> Message-ID: <1152812542.26551.3.camel@rousalka.dyndns.org> Le jeudi 13 juillet 2006 ? 16:29 +0200, Michael Schwendt a ?crit : > On Wed, 12 Jul 2006 21:54:28 +0200, Nicolas Mailhot wrote: > > If you don't know it will break, restricting the package in any way is > > 100% useless silliness > > No, it's packager's freedom to make clear that the src.rpm was created for > a specific distribution. And if rebuilt for a different dist, without any > changes in the src.rpm contents (e.g. dist-specific patches or options), > the resulting binaries should not automatically look like they are for the > different dist. I think you misunderstood me but anyway : how do you rebuild a package for a different dist, without any changes in the src.rpm contents, if it's been restricted to a specific dist via R or BR ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Thu Jul 13 18:13:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Jul 2006 13:13:54 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152812542.26551.3.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> <1152667497.2860.15.camel@aglarond.local> <20060712022525.GA19221@jadzia.bu.edu> <1152682059.12430.327.camel@localhost.localdomain> <20060712083420.3d6e60ad.bugs.michael@gmx.net> <1152687624.4569.77.camel@mccallum.corsepiu.local> <20060712124508.90cf6c79.bugs.michael@gmx.net> <45403.192.54.193.51.1152703842.squirrel@rousalka.dyndns.org> <20060712214433.137610a1.bugs.michael@gmx.net> <1152734069.10992.19.camel@rousalka.dyndns.org> <20060713162915.57b2ea28.bugs.michael@gmx.net> <1152812542.26551.3.camel@rousalka.dyndns.org> Message-ID: <44B68D62.2060400@math.unl.edu> Nicolas Mailhot wrote: > I think you misunderstood me but anyway : how do you rebuild a package > for a different dist, without any changes in the src.rpm contents, if > it's been restricted to a specific dist via R or BR ? That's the point (I think), you don't. That's why the R/BR restrictions were put in place. -- Rex From jamatos at fc.up.pt Thu Jul 13 18:22:51 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 13 Jul 2006 19:22:51 +0100 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B68D62.2060400@math.unl.edu> References: <1152642496.12430.232.camel@localhost.localdomain> <1152812542.26551.3.camel@rousalka.dyndns.org> <44B68D62.2060400@math.unl.edu> Message-ID: <200607131922.51302.jamatos@fc.up.pt> On Thursday 13 July 2006 19:13, Rex Dieter wrote: > Nicolas Mailhot wrote: > > I think you misunderstood me but anyway : how do you rebuild a package > > for a different dist, without any changes in the src.rpm contents, if > > it's been restricted to a specific dist via R or BR ? > > That's the point (I think), you don't. That's why the R/BR restrictions > were put in place. The package names present in Requires and BuildRequires depend on the distribution for which you are building. That is why if you want to port some rpm spec from Mandriva to Fedora, or the other way around, you have to change those names (and eventually delete and/or add others). So it is not possible to use the original src.rpm unchanged, that was the point, I think. :-) > -- Rex -- Jos? Ab?lio From dlutter at redhat.com Thu Jul 13 21:56:05 2006 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 13 Jul 2006 14:56:05 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152773008.21931.8.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> Message-ID: <1152827765.14874.21.camel@localhost.localdomain> On Thu, 2006-07-13 at 08:43 +0200, Nicolas Mailhot wrote: > Le mercredi 12 juillet 2006 ? 18:52 -0700, Toshio Kuratomi a ?crit : > > > So it looks like the idea of "upgrading" from a Fedora package to > > JPackage to Fedora that was expressed by Fernando Nasser [1]_ is an > > anti-goal (ie: It is explicitly not the desired behaviour.) > > The migration is more jpp -> fc but even if fc -> jpp should never be > desirable ideally the truth is fc sometimes lags behind and users would > rather use the latest jpp package than the old fc-customized one. > > It's not a simple problem-space. That's why it would be very helpful if somebody who is familiar with that problem space could write up what the packaging guideline should be, and why it should be that way. Even better if somebody starts a page http://fedoraproject.org/wiki/PackagingDrafts/Java There seem to be conflicting views on how exactly the jpp/fc thing should play out for users, especially with respect to upgrades interleaving (or not) jpp and fc packages. The main reason this is needed is to enable reviews of Java packages for FE and make sure they take advantage of the knowledge about Java packaging that jpackage has accumulated over the years. David From nicolas.mailhot at laposte.net Thu Jul 13 23:48:52 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 01:48:52 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152827765.14874.21.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> <1152827765.14874.21.camel@localhost.localdomain> Message-ID: <1152834532.4511.73.camel@rousalka.dyndns.org> Le jeudi 13 juillet 2006 ? 14:56 -0700, David Lutterkort a ?crit : > On Thu, 2006-07-13 at 08:43 +0200, Nicolas Mailhot wrote: > > Le mercredi 12 juillet 2006 ? 18:52 -0700, Toshio Kuratomi a ?crit : > > > > > So it looks like the idea of "upgrading" from a Fedora package to > > > JPackage to Fedora that was expressed by Fernando Nasser [1]_ is an > > > anti-goal (ie: It is explicitly not the desired behaviour.) > > > > The migration is more jpp -> fc but even if fc -> jpp should never be > > desirable ideally the truth is fc sometimes lags behind and users would > > rather use the latest jpp package than the old fc-customized one. > > > > It's not a simple problem-space. > > That's why it would be very helpful if somebody who is familiar with > that problem space could write up what the packaging guideline should > be, and why it should be that way. I don't follow JPackage these days and didn't propose the original interleaving spec. So all I'll write there is based is based on my personal understanding, which may not be current. The current convention aims to make full interleaving possible. A JPP-like stacked release flow looks like this : 1. java project releases a code dump 2. someone @jpp does the initial sanity checking and rpm packaging. People from various distributions (Fedora, Suse...) follow the process and review the result (the @jpp someone may be a @rh or @suse someone too) 3. the fedora java team cherry-picks the packages it deems the most interesting, and releases tweaked versions in fc/rhel (aot compiling, killing of all the deps which do not have a viable FLOSS version yet, etc) Rince and repeat for every release of a java app. This is a continuous FE-like rolling release process. Now even if it would be much easier on everyone involved if only rolling releases happened, sometimes core java packages (jvm, ant, tomcat...) have a major version change, and require a full repository rebuild (as in every package/spec needs to be audited to check it will work with the new core). A FC-like release process then takes place, with a devel branch populated like Rawhide, and tested till it's ready to be declared the new jpp release. Needless to say core JPP packaging policy changes only happen during this sort of full-repo release. The naming guidelines must allow transparent transition from 2 to 3 : ie supposing you have a system with a set of jpp packages installed, allow update of all or part of them to their fedora-enhanced forks. ie if JPP released foo-2.3-1jpp allow yum update to foo-2.3-something, where something tells yum its 1jpp plus some enhancements However should JPP release foo-2.3-2jpp with some important fixes in the packaging, and @rh people can't repackage it on a timely manner because they're swamped by a RHEL release, upgrade from foo-2.3-something to foo-2.3-2jpp is also desirable. Of course that paves the way to foo-2.3-2jpp to foo-2.3-somethingelse upgrades once fc did its forking. So you have a foo-2.3-1jpp -> foo-2.3-something -> foo-2.3-2jpp -> foo-2.3-somethingelse pattern. Needless to say Fedora has no control over the release tags jpp uses (However it's certainly possible to propose JPP a new streamlined release naming convention for its packages, but it will only take effect when every JPP package is rebuild, and probably not fully till the next JPP release. Impatient people can always join the JPP packaging team to make things happen faster) The jpp -> fc transitions are explicitely encouraged by the rh java team. The fc -> jpp transitions should not happen in ideal life, but are a necessary evil. They are needed for when the fc repackaging lags, or when users need package versions in the JPP devel branch (needless to say FC only forks stable JPP repository states, not devel). The advice to users is to inhibit them either by not enabling the jpp repo or by adding specific excludes for the stuff they don't want upgraded by jpp. But should the user decide to enable them, they must work in yum too. You must realise the worst case for the time a java app takes to hit FC is : 1. java project releases a code dump 2. someone @jpp does the initial packaging. However app needs a new major version of a core java component, so it's released in the JPP devel branch 3. ... wait some months till the devel branch graduates to stable JPP 4. ... wait some weeks till the fedora java team does the fc repackaging. Result hits rawhide 5. ... wait some months till rawhide graduates to stable FC 6. ... wait some months/years till stable FC is forked in RHEL the fc->jpp update path is designed to allow users who can't wait for 6. or 5. use 2. or 3. Also the length of 1 -> 2 and 2 -> 3 is pretty much only dependant on the manpower JPP got at the time, it can go faster or slower depending on the packaging time individual people donate. This process is much slower than what happens in FE, because java includes glibc-like core packages, not only packages with little or no dependency relations with one another. Aside from the current rh/fc java team, Paul Nasrat and Ville Skytt? spent several months of their lives as core JPackage contributors, and are probably as qualified as me (if not more) to comment on all this. Anyone with delusions like "all this dependencies on JPackage suck, let's dump the FC/JPP relationship and do all the packaging within Fedora with our own conventions" is cordially invited to join JPP a few months to get a direct experience on what packaging Java actually means in terms of work. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fnasser at redhat.com Fri Jul 14 00:33:03 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 13 Jul 2006 20:33:03 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152742614.26066.26.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <200607121603.33532.jkeating@redhat.com> <44B5580B.3070709@redhat.com> <200607121634.02588.jkeating@redhat.com> <1152742614.26066.26.camel@localhost.localdomain> Message-ID: <44B6E63F.4030709@redhat.com> David Lutterkort wrote: > On Wed, 2006-07-12 at 16:34 -0400, Jesse Keating wrote: >> On Wednesday 12 July 2006 16:14, Fernando Nasser wrote: >>> Versions in package names? The namespace will explode in no time, no >>> history, imagine adding new packages all the time to the bug repository >>> lists, and so on. Huge implications. >> But now we have upstream versions in downstream releases and release namespace >> is exploading. So putting it in the name is wrong, putting it in version is >> wrong, putting it in release is wrong, that leaves Provides. It seems to me >> that the only REAL reason for having the jpp in the nevr is for user >> visibility, which could be accomplished by rpm -q --provides. > > There is also the issue that people want to get the latest from jpackage > _or_ Fedora, whichever is newer, so it's not just cosmetic. The order > that is wanted is 1jpp < 1jpp.1.fc5 < 2jpp < 2jpp.1.fc5 etc. > > I can't think of another scheme to achieve this interleaving given that > both the name and the version are fixed (cause they are determined by > the upstream source) and that jpackage needs to set some sort of release > for their packages, too. > Exactly. This has been working fine for a couple of years already. From fnasser at redhat.com Fri Jul 14 00:42:49 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 13 Jul 2006 20:42:49 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152738336.12430.426.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738336.12430.426.camel@localhost.localdomain> Message-ID: <44B6E889.4070500@redhat.com> Tom 'spot' Callaway wrote: > On Wed, 2006-07-12 at 16:58 -0400, Fernando Nasser wrote: > >> And for what? What are the technical advantages that will be obtained >> with this change? If we knew what effect wants to be obtained we could >> perhaps think together in a better way to solve it. > > Consistency, cleanliness, and organization. > All subjectibve concepts. As it should be clear from this thread, several of us consider the current approach the one thagt provide "Consistency, cleanliness, and organization". So, as I suspected, no technical reasons. > If we permit this off the wall naming scheme which violates the Fedora > Naming Guidelines for the Java packages, we open the door for every > other possible group to abuse the namespace. > That was not created taking into account the situation and needs of the Java stack. Discussions for finding out what is appropriate and necessary ammendments would have to be made before attempting to apply it. Using the current one as a "one-size-fits-all" tool for things that clearly have a special situation is abuse. > I'm willing to put this in front of the Fedora Packaging Committee for a > vote, but I fully intend to vote against it. > Before voting, more thought has to be put into it. The middle of a release was a very bad time for that BTW. And I think multi-distro practices should be taken into account as well as more respect for te community that created this system of Java packaging. I see none. From fnasser at redhat.com Fri Jul 14 00:54:16 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 13 Jul 2006 20:54:16 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152834532.4511.73.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> <1152827765.14874.21.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> Message-ID: <44B6EB38.4010609@redhat.com> Hi Nicolas, As you know handling this number of Java packages is an incredible amount of work. The first attempt at maintaining the Fedora packages separately resulted in them lagging behind, interoperability problems (Fedora does not have all Java packages, they are in excess of 500 now) and on bug fixes not being propagated upstream, so updates caused regressions and so one. The typical maladies of a fork. So, someone from GNU Java land created a script that add AOT bits to the original JPackage spec files, so they can build with GCJ on Fedora. JPackage has agreed to add these bits to their own spec files, so they will be virtually the same. Now, not only the JPackage community, BEA, Sun, Suse, Mandriva and RHEL can work on the upstream packages and benefit from the fixes, but also Fedora folks can make the fixes usptream. This not only benefits the Linux community at large but also relieves the immense burden to maintain a forked set of packages. Best regards, Fernando From jkeating at redhat.com Fri Jul 14 01:23:14 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Jul 2006 21:23:14 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B56289.9000203@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> Message-ID: <200607132123.17705.jkeating@redhat.com> On Wednesday 12 July 2006 16:58, Fernando Nasser wrote: > And for what? ?What are the technical advantages that will be obtained > with this change? ?If we knew what effect wants to be obtained we could > perhaps think together in a better way to solve it. Right now it is difficult to respin a release on say FC5 w/out running into having it be versioned HIGHER than that in FC6 or in devel. If we're going to adopt the jpackage naming scheme into our guidelines there needs to be some thought put around this. We recently approved the ability to add an int after the dist tag for this purpose, so that the release could be: %{?dist}. or once translated: 3.fc6.1 This keeps it lower than say 3.fc7 but allows for it to be respun w/out having to bump the fc7 version. How can this fit into the jpp naming scheme as it stands? Currently there is just 'fc', no indication which Fedora release, and there are no numbers after it. This should be addressed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Jul 14 09:51:00 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 11:51:00 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B6E889.4070500@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738336.12430.426.camel@localhost.localdomain> <44B6E889.4070500@redhat.com> Message-ID: <1152870660.16190.25.camel@rousalka.dyndns.org> Le jeudi 13 juillet 2006 ? 20:42 -0400, Fernando Nasser a ?crit : Hi Fernando, > Tom 'spot' Callaway wrote: > > On Wed, 2006-07-12 at 16:58 -0400, Fernando Nasser wrote: > > > >> And for what? What are the technical advantages that will be obtained > >> with this change? If we knew what effect wants to be obtained we could > >> perhaps think together in a better way to solve it. > > > > Consistency, cleanliness, and organization. > > > > All subjectibve concepts. > > As it should be clear from this thread, several of us consider the > current approach the one thagt provide "Consistency, cleanliness, and > organization". > > So, as I suspected, no technical reasons. Fedora current naming guidelines try to address several mistakes packagers (even @rh packagers) used to do, mistakes which resulted in broken yum upgrade paths and epoch inflation. (it's true most of the people which have been complaining there seem to have completely forgotten the guidelines original technical aims to remember only the ?sthetical side-effects). My personal opinion at this point is the only sane technical solution is to have release defined as %{jpackage_release}%{fedora_release} in the java package case. However %{upstream_release} may need some work. JPackage is using some constructs Fedora and RHEL used to have but won't anymore (nothing dangerous or utterly broken as far as I can see, since JPP is very yum/urpmi/apt-aware). I feel the way Fedora formalised it is a tad better) IMHO JPP should just steal a page from Fedora and use the Fedora Guidelines, replacing the final %{dist} by hardcoded .jpp or jpp But I don't have any prescription power be it at Fedora or JPackage, so do as you think is best. You're doing a great job BTW, it's a pleasure to peek at the project every few months and see how it evolves. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Jul 14 10:20:03 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 12:20:03 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B6EB38.4010609@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> <1152827765.14874.21.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> <44B6EB38.4010609@redhat.com> Message-ID: <1152872403.16190.36.camel@rousalka.dyndns.org> Hi Fernando, I see you are true to the original aim of minimising JPP/FC differences so work can be shared and everyone does not have to reinvent the wheel. As you wrote, this paves the way to mass import of packages in Fedora. Since I don't think the PTB will let you do the import in Core, that means Extras mostly and a big round of review (which will probably benefit JPackage as much as Fedora). Have you though about how you were going to organise this? IMHO you'll want to push the fixes Fedora reviewers suggest upstream as fast as possible, and playing the middleman between JPP and FE is going to be inefficient and exhausting. Some sort of Java Fedora SIG or another semi-permanent liaison group will be needed, possibly with special rules so review can directly happen at the JPP level. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugs.michael at gmx.net Fri Jul 14 15:42:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 14 Jul 2006 17:42:15 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607131922.51302.jamatos@fc.up.pt> References: <1152642496.12430.232.camel@localhost.localdomain> <1152812542.26551.3.camel@rousalka.dyndns.org> <44B68D62.2060400@math.unl.edu> <200607131922.51302.jamatos@fc.up.pt> Message-ID: <20060714174215.866c8eb2.bugs.michael@gmx.net> On Thu, 13 Jul 2006 19:22:51 +0100, Jose' Matos wrote: > On Thursday 13 July 2006 19:13, Rex Dieter wrote: > > Nicolas Mailhot wrote: > > > I think you misunderstood me but anyway : how do you rebuild a package > > > for a different dist, without any changes in the src.rpm contents, if > > > it's been restricted to a specific dist via R or BR ? > > > > That's the point (I think), you don't. That's why the R/BR restrictions > > were put in place. > > The package names present in Requires and BuildRequires depend on the > distribution for which you are building. > > That is why if you want to port some rpm spec from Mandriva to Fedora, or > the other way around, you have to change those names (and eventually delete > and/or add others). > > So it is not possible to use the original src.rpm unchanged, that was the > point, I think. :-) Plus, there may be patches in the src.rpm which are dist-specific. It may or may not be possible [in rather ugly ways] to express the dist-requirements in explicit and versioned R (or BR) by guessing maximum versions or by introducing deps on specific versions. Broken explicit deps are particularly bad, avoid them like the plague! We see them regularly in the broken deps reports. Bad, bad, bad. Further, the unmodified src.rpm may build fine for a newer dist, but that's not the primary goal. The primary goal is to create and ship tested and working binaries, prepared by the package maintainer(s), and which if rebuilt without modification do not pretend that they have been made for the different dist. All I suggest is, don't limit packagers' freedom. When I know that %dist expands to .fc4, I ought to be permitted to use .fc4 in my spec. Anyway, this debate has found an end for me at this point. Keep fighting for no visible benefit. Seeing a big thread about jpackage Release hacks, I'm not going to voice my opinion on this any longer. %{?dist} is not mandatory, and hence the work-around is to not use any dist tag at all and to forbid anybody who modifies the spec to add %{?dist} without prior permission. From fitzsim at redhat.com Fri Jul 14 19:11:57 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 14 Jul 2006 15:11:57 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152834532.4511.73.camel@rousalka.dyndns.org> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> <1152827765.14874.21.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> Message-ID: <44B7EC7D.3040502@redhat.com> Hi, Nicolas Mailhot wrote: > So you have a > foo-2.3-1jpp -> foo-2.3-something -> foo-2.3-2jpp -> foo-2.3-somethingelse > pattern. Needless to say Fedora has no control over the release tags jpp > uses How about this convention for Fedora: Release: %{jpackage_release_number}.%{fedora_release_number} This example becomes: foo-2.3-1jpp -> foo-2.3-1.1 -> foo-2.3-2jpp -> foo-2.3-2.1 with further Fedora updates being: foo-2.3-2.1 -> foo-2.3-2.2 -> foo-2.3-2.3 The release string convention for JPackage packages in Fedora would resemble the convention for pre-release packages. The release field would no longer contain underscores or non-numeric characters, but it would still be easy for users and developers to see which JPackage release a given Fedora package was derived from. Because the update path is preserved, this change could be introduced gradually, package by package. Tom From jkeating at redhat.com Fri Jul 14 19:32:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Jul 2006 15:32:01 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B7EC7D.3040502@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> <44B7EC7D.3040502@redhat.com> Message-ID: <200607141532.01974.jkeating@redhat.com> On Friday 14 July 2006 15:11, Thomas Fitzsimmons wrote: > How about this convention for Fedora: > > Release: %{jpackage_release_number}.%{fedora_release_number} > > This example becomes: > > foo-2.3-1jpp -> foo-2.3-1.1 -> foo-2.3-2jpp -> foo-2.3-2.1 > > with further Fedora updates being: > > foo-2.3-2.1 -> foo-2.3-2.2 -> foo-2.3-2.3 > > The release string convention for JPackage packages in Fedora would > resemble the convention for pre-release packages. ?The release field would > no longer contain underscores or non-numeric characters, but it would still > be easy for users and developers to see which JPackage release a given > Fedora package was derived from. ?Because the update path is preserved, > this change could be introduced gradually, package by package. Add to this the dist tag and I think that's pretty acceptable. It somewhat breaks our %{?dist}. scheme, but its better than having jpp in there. so %{jpackage_release_number}.%{fedora_release_number}%{?dist} foo-2.3-2jpp -> foo-2.3-1.2.fc6 THen we can respin the .fc6 version, .fc6.1 w/out having to bump the fc7 version which might be foo-2.3-2.1.fc7 -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Jul 14 20:00:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 22:00:20 +0200 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607141532.01974.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> <44B7EC7D.3040502@redhat.com> <200607141532.01974.jkeating@redhat.com> Message-ID: <1152907220.3087.95.camel@rousalka.dyndns.org> Le vendredi 14 juillet 2006 ? 15:32 -0400, Jesse Keating a ?crit : > On Friday 14 July 2006 15:11, Thomas Fitzsimmons wrote: > > How about this convention for Fedora: > > > > Release: %{jpackage_release_number}.%{fedora_release_number} > > > > This example becomes: > > > > foo-2.3-1jpp -> foo-2.3-1.1 -> foo-2.3-2jpp -> foo-2.3-2.1 is 1jpp < 1.1 for rpm ? > Add to this the dist tag and I think that's pretty acceptable. It somewhat > breaks our %{?dist}. scheme, but its better than having jpp in > there. > > so %{jpackage_release_number}.%{fedora_release_number}%{?dist} > > foo-2.3-2jpp -> foo-2.3-1.2.fc6 This one won't work, as 2jpp > 1.2.fc6 Also you need to consider jpackage may need non-integer releases (like alphatags) as much as Fedora, so without some sort on non-ambiguious marker between the jpp and fc release things will break. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Fri Jul 14 20:06:55 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 13:06:55 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607141532.01974.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> <44B7EC7D.3040502@redhat.com> <200607141532.01974.jkeating@redhat.com> Message-ID: <1152907615.3010.94.camel@localhost> On Fri, 2006-07-14 at 15:32 -0400, Jesse Keating wrote: > On Friday 14 July 2006 15:11, Thomas Fitzsimmons wrote: > > How about this convention for Fedora: > > > > Release: %{jpackage_release_number}.%{fedora_release_number} > > > > This example becomes: > > > > foo-2.3-1jpp -> foo-2.3-1.1 -> foo-2.3-2jpp -> foo-2.3-2.1 > > > > with further Fedora updates being: > > > > foo-2.3-2.1 -> foo-2.3-2.2 -> foo-2.3-2.3 > > > > The release string convention for JPackage packages in Fedora would > > resemble the convention for pre-release packages. The release field would > > no longer contain underscores or non-numeric characters, but it would still > > be easy for users and developers to see which JPackage release a given > > Fedora package was derived from. Because the update path is preserved, > > this change could be introduced gradually, package by package. > > Add to this the dist tag and I think that's pretty acceptable. It somewhat > breaks our %{?dist}. scheme, but its better than having jpp in > there. > > so %{jpackage_release_number}.%{fedora_release_number}%{?dist} > > foo-2.3-2jpp -> foo-2.3-1.2.fc6 > > THen we can respin the .fc6 version, .fc6.1 w/out having to bump the fc7 > version which might be foo-2.3-2.1.fc7 What are you going to do when snapshots enter the picture? db-ddlutils-1.0-0.060220.2jpp becomes one of the following: db-ddlutils-1.0-0.060220.2.1.fc5 db-ddlutils-1.0-0.060220.2.0.1.20060220cvs.fc5 db-ddlutils-1.0-2.0.1.20060220cvs.fc5 I believe jpackage sets "2jpp" back to "1jpp" when they update the snapshot, so the last example wil break and shouldn't be used. In either of the first two, the Fedora packager and reviewer have to be aware of both the Fedora Naming Guidelines and the JPackage naming guidelines which is going to be confusing and an extra burden on reviewers. FESCo was worried about the Fedora Packaging Guidelines becoming too big and cumbersome yesterday, do we really want to force two sets of Package Naming Guidelines on people? Also to be aware of: Interspersed Milestones and snapshots: JPackage: axion-1.0-0.20060220.2jpp => axion-1.0-1.M3.1jpp => axion-1.0-2.1jpp We have to break the "0" metaphor for prerelease packages because the jpackage places the jpackage release number at the end rather than the beginning. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fnasser at redhat.com Fri Jul 14 20:59:01 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 14 Jul 2006 16:59:01 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607132123.17705.jkeating@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <200607132123.17705.jkeating@redhat.com> Message-ID: <44B80595.6000902@redhat.com> Hi Jesse, Jesse Keating wrote: > On Wednesday 12 July 2006 16:58, Fernando Nasser wrote: >> And for what? What are the technical advantages that will be obtained >> with this change? If we knew what effect wants to be obtained we could >> perhaps think together in a better way to solve it. > > Right now it is difficult to respin a release on say FC5 w/out running into > having it be versioned HIGHER than that in FC6 or in devel. If we're going > to adopt the jpackage naming scheme into our guidelines there needs to be > some thought put around this. > Of course. > We recently approved the ability to add an int after the dist tag for this > purpose, so that the release could be: > > %{?dist}. or once translated: > > 3.fc6.1 > Sounds good to me. > This keeps it lower than say 3.fc7 but allows for it to be respun w/out having > to bump the fc7 version. > Nice idea. So far so good. > How can this fit into the jpp naming scheme as it stands? Currently there is > just 'fc', no indication which Fedora release, and there are no numbers after > it. This should be addressed. > I wish so much this would be the only problem that people would be seeing. Because any, absolutely any, suffix scheme to whatever the JPP release is would work fine for JPackage as well. MMMMMM-N.N.N-NNNNjpp where suffix could perfectly be %{?dist}. We need a separator though. I think it could be proposed a second use for underscores in addition to package with underscores on well known upstream names. Underscores could also be used to clearly separate releases when the packaging is imported from upstream. Mind, today it is just JPackage and the Java packages, but who can tell that in a few years there won't be this huge meta system with it's all multi-distro package community that we (we == Fedora in this case) would like to import as effortlessly as possible? The character release separator '_' would come into play again. In any case, any other separator would do, even a '.' if special-cased when following a 'jpp' (or any other future upstream packaging community). So, all that would remain would be to make the upstream JPackage release practices a little bit more palatable for your tastes (note that I say taste, I don't think tere are technical reasons like the one you presented). I really elieve JPP folks would be agreeable on following the sae standards as Fedora for instance for cvs date tags. I forgot now, what is it 0.cvsYYYYMMDD.... ? The '0.' prefix for pre-releases is very important, as it is intended to lose for the final '1'. And the pre-release tags? We have been obeying strictly what the upstream software produced is using. This means that if they say it is 'rc2' then JPP has 0.rc2.... but if they say it is 'M4', it becomes 0.M4.... Strictly what the developers called it and the software web site refers to it as (normally it is also in the sorce tar ball name). Here comes the 1st problem: uppercase characters. We have another situation that will need discussion: several upstream packages are now using snapshots of dependencies before the official release that are being identified only by a CVS Tag. Not date, Tag! This means underscores!!! What I really would think should be fair in the case of upstream packaging communities would be to apply the Fedora standards only after the separator, i.e., to the Fedora added suffix. In any case, I believe that reasonable suggestions to improve the upstream release numbering will be welcome, they must be presented at that project list though: jpackage-discuss at zarb.org Also notice that these changes will not come overnight, as noticed in this thread before. There are releases there too, and packages for the next one on August 15 are basically ready. They are many, and it took months to get to this point. Also, there are upgrade considerations wit regards to previous JPP releases and many other things that would need to be exhaustively tested. It is a project that exists since before Fedora was even born: it had releases for RHL 8 or before if I am not mistaken. Note that is not only Fedora that imports the RPMs from JPackages. Other distributions and Java SDK providers also use it and may want to have a say as well. In summary Jesse, we have no attachment to the _Nfc bit in particular. Any suffix will do, whatever works better for Fedora. Changes in the upstream release string is what causes interoperability problems. Thanks a lot for posting a specific technical issue. It works so much better that way. Best regards, Fernando From ville.skytta at iki.fi Fri Jul 14 21:38:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 15 Jul 2006 00:38:46 +0300 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B80595.6000902@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <200607132123.17705.jkeating@redhat.com> <44B80595.6000902@redhat.com> Message-ID: <1152913126.2696.62.camel@localhost.localdomain> On Fri, 2006-07-14 at 16:59 -0400, Fernando Nasser wrote: > The '0.' prefix for pre-releases is very important, as it is intended to > lose for the final '1'. > > And the pre-release tags? We have been obeying strictly what the > upstream software produced is using. This means that if they say it is > 'rc2' then JPP has 0.rc2.... but if they say it is 'M4', it becomes > 0.M4.... Strictly what the developers called it and the software web > site refers to it as (normally it is also in the sorce tar ball name). Note that the above scheme is broken in the sense that it lacks . between the leading 0 and $prereleasestuff, possibly resulting in the need to bump the leading 0 before the final version is out. More info: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e104844825856d7c45f2f0241586985c0495966b Example: 0.YYYYMMDD > 0.beta5 may be undesirable, but with the additional ., the packager is always in control and can do eg. 0.1.YYYYMMDD < 0.2.beta5 From toshio at tiki-lounge.com Fri Jul 14 22:34:07 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 15:34:07 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B7EC7D.3040502@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <200607120833.06129.jkeating@redhat.com> <13843.192.54.193.51.1152713323.squirrel@rousalka.dyndns.org> <200607121105.26089.jkeating@redhat.com> <44B54AEE.8020104@redhat.com> <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> <1152827765.14874.21.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> <44B7EC7D.3040502@redhat.com> Message-ID: <1152916447.3010.203.camel@localhost> On Fri, 2006-07-14 at 15:11 -0400, Thomas Fitzsimmons wrote: > How about this convention for Fedora: > > Release: %{jpackage_release_number}.%{fedora_release_number} > Hi Tom, Gary, others, We're all discussing the mechanics of the Release tag here, but the first thing the Packaging Committee needs to know to be able to address this issue is what goals are valid and which are not. I've started a wiki page that expresses the issue in those terms: http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming (Feel free to add discussion points, new goals, alternate proposals, ways to modify the current proposals to make them better, etc) The summary for the goals is: 1) Is the Fedora Java group's Policy to support interleaving jpackage and Fedora packages? If so then we'll be exploring what kind of naming would make this possible. No other set of developers has said they want the headache of maintaining this so we have not had to design something that works like this. 2) Do both users and packagers need to figure out what jpackage release the Fedora release is based on and why? Does having the release information in another part of the spec file (For instance, as a provide) give you the same value? Why or why not? 3) Do you want to block upgrades from Fedora packages to JPackage packages? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Fri Jul 14 22:50:33 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 15:50:33 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44B80595.6000902@redhat.com> References: <1152642496.12430.232.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <200607132123.17705.jkeating@redhat.com> <44B80595.6000902@redhat.com> Message-ID: <1152917433.3010.217.camel@localhost> For reference, here are the package naming guidelines for Fedora: http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines On Fri, 2006-07-14 at 16:59 -0400, Fernando Nasser wrote: > Mind, today it is just JPackage and the Java packages, but who can tell > that in a few years there won't be this huge meta system with it's all > multi-distro package community that we (we == Fedora in this case) would > like to import as effortlessly as possible? The character release > separator '_' would come into play again. > This would be a big change in direction from how Fedora currently works with other repositories. We would want to define what makes another repository an upstream source (JPackage has a framework for java packages that we are using as well as the packages themselves. I think this is an important distinction. Other repositories have frameworks that conflict with what we are using and I think that is one of the big differences.) In the past, though, it has always been "mixing repos does not work." I think some of those arguments are still valid, even with jpackage. Look at the email threads I linked to in an earlier message for some of the issues Fedora Java has already run into. > In any case, any other separator would do, even a '.' if special-cased > when following a 'jpp' (or any other future upstream packaging community). > > So, all that would remain would be to make the upstream JPackage release > practices a little bit more palatable for your tastes (note that I say > taste, I don't think tere are technical reasons like the one you presented). > Do you think we make up Guidelines for fun? ;-) There are technical reasons for every guideline. Even the consistency guideline has a technical grounding. When you are taking packages from people new to packaging and having people review packages for weaknesses, more consistency makes less work and a lower barrier to entry. It can be carried too far when we value consistency so much that it prevents achieving other goals but it is a goal to strive for when A) there are no other goals B) choosing among several options that satisfy a goal. > I really elieve JPP folks would be agreeable on following the sae > standards as Fedora for instance for cvs date tags. I forgot now, what > is it 0.cvsYYYYMMDD.... ? > It's 0.1.YYYYMMDDcvs Note that there is both a zero prefix and the release at the beginning of the release. This is important as it means I can switch from a CVS snapshot to a named prerelease and back without difficulties: foo-1.0-0.1.M1 foo-1.0-0.2.20060201cvs foo-1.0-0.1.M2 foo-1.0-1 > The '0.' prefix for pre-releases is very important, as it is intended to > lose for the final '1'. > > And the pre-release tags? We have been obeying strictly what the > upstream software produced is using. This means that if they say it is > 'rc2' then JPP has 0.rc2.... but if they say it is 'M4', it becomes > 0.M4.... Strictly what the developers called it and the software web > site refers to it as (normally it is also in the sorce tar ball name). > > Here comes the 1st problem: uppercase characters. > This is not a problem when the primary release tag comes first as in the example above. > > We have another situation that will need discussion: several upstream > packages are now using snapshots of dependencies before the official > release that are being identified only by a CVS Tag. Not date, Tag! > This means underscores!!! > In the Fedora Guidelines, when you make a snapshot yourself, you always use the date. This prevents problems if upstream switches version control systems and loses their tags, changeset number, etc. If upstream is making a tarball with the tag as version then you have to choose a version that won't conflict with upstream updates and then move the alpha portion of the version after the Integer release. Here's one possible implementation: foo-1.0.tar.gz => foo-1.0-1.src.rpm foo-TODAYS_TAG.tar.gz => foo-1.0-2.TODAYS_TAG.fc5.src.rpm foo-ARTS_TAG.tar.gz => foo-1.0-3.ARTS_TAG.fc5.src.rpm This treats the snapshot as a post release according to the guidelines. It also leaves the underscore in the package. Some others might say the underscore should be converted but I'd argue that "TODAYS_TAG" is a complete entity and so the underscore is not a separator between elements of the version. > What I really would think should be fair in the case of upstream > packaging communities would be to apply the Fedora standards only after > the separator, i.e., to the Fedora added suffix. > Unfortunately, this doesn't work. The Fedora Naming standards exist to protect from problems with upgrading. The jpackage guidelines seem mostly sane, but as you've found, things like having the primary integer release number after the tags and dates from upstream can lead to problems. So to be a prefix, the upstream Naming Guidelines would have to take care of all the cornercases that the Fedora Guidelines encompass. Alternatively, the upstream naming could be encapsulated within the Fedora release: foo-1.0-4.6jpp.fc5.src.rpm foo-1.0-5.20060707svn.1jpp.fc5.src.rpm foo-1.0-6.rc5.1jpp.fc5.src.rpm where "6jpp", "20060707svn.1jpp", and "rc5.1jpp" are all jpackage names. > In any case, I believe that reasonable suggestions to improve the > upstream release numbering will be welcome, they must be presented at > that project list though: > > jpackage-discuss at zarb.org > First we have to know if interleaving with jpackage is a real goal for Fedora Java. I've written a separate email with questions about goals. > > Also notice that these changes will not come overnight, as noticed in > this thread before. There are releases there too, and packages for the > next one on August 15 are basically ready. They are many, and it took > months to get to this point. > This is only a problem for Fedora if we want to get more java packages into the distro. All new packages must meet the Fedora Guidelines. We can amend them to meet new situations, but we shoudn't break them. (We've just had problems with Mono applications because some packagers were asserting that you absolutely had to ignore certain guidelines in order to build Mono applications. Turns out, that wasn't the case and now we have to cleanup the mess.) IF interleaving is wanted and we approve a policy that uses the jpackage version in prefix with the stipulation that the jpackage version has to work in all the cornercases identified, then there may be some jpackages that have to munge the version in order to work. For instance: axion-1.0-0.M3.1jpp.src.rpm would have to be changed to axion-1.0-0.1.M3.3.fc5.src.rpm -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gbenson at redhat.com Mon Jul 17 08:41:38 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 17 Jul 2006 09:41:38 +0100 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152916447.3010.203.camel@localhost> References: <1152733661.12430.394.camel@localhost.localdomain> <1152735692.10992.29.camel@rousalka.dyndns.org> <44B56289.9000203@redhat.com> <1152738877.5959.2.camel@localhost> <1152755527.5959.60.camel@localhost> <1152773008.21931.8.camel@rousalka.dyndns.org> <1152827765.14874.21.camel@localhost.localdomain> <1152834532.4511.73.camel@rousalka.dyndns.org> <44B7EC7D.3040502@redhat.com> <1152916447.3010.203.camel@localhost> Message-ID: <20060717084135.GA3079@redhat.com> Toshio Kuratomi wrote: > I've started a wiki page that expresses the issue in those terms: > > http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming > > (Feel free to add discussion points, new goals, alternate proposals, > ways to modify the current proposals to make them better, etc) You'll have to remove the page's immutable status first ;) Cheers, Gary From laroche at redhat.com Mon Jul 17 08:56:29 2006 From: laroche at redhat.com (Florian La Roche) Date: Mon, 17 Jul 2006 10:56:29 +0200 Subject: unofficial updates for Fedora Core 4 In-Reply-To: <20060713173320.GA12246@jadzia.bu.edu> References: <20060713173320.GA12246@jadzia.bu.edu> Message-ID: <20060717085628.GA3453@dudweiler.stuttgart.redhat.com> On Thu, Jul 13, 2006 at 01:33:20PM -0400, Matthew Miller wrote: > As I'm sure everyone Core developer knows (and probably can't wait for), FC4 > is going to Legacy in a couple of weeks. Hello all, I still have a fc4 machine running along, so I have re-compiled a few packages to be really updated to their newest versions. Pushing these out as official updates probably doesn't make any sense, but maybe some people also want to use these newer packages (most from current FC-development): - bind-9.3.2 - cvs-1.11.22 - ntp-4.2.2 - openssh-4.3p2 - pychecker-0.8.17 - sendmail-8.13.7 - squid-2.5.STABLE14 I'd love to hear comments about the above packages, but also have to warn that I am probably soon migrating over to FC6 with that machine, so I might discontinue the backports any day. All packages are at http://www.jur-linux.org/rpms/fc-updates/4/ . regards, Florian La Roche From jkeating at redhat.com Mon Jul 17 12:35:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Jul 2006 08:35:25 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060717084135.GA3079@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <1152916447.3010.203.camel@localhost> <20060717084135.GA3079@redhat.com> Message-ID: <200607170835.25475.jkeating@redhat.com> On Monday 17 July 2006 04:41, Gary Benson wrote: > You'll have to remove the page's immutable status first That page should only be immutable if you don't have a wiki account and don't have a signed CLA on file so that we can add you to the EditGroup in the wiki. This prevents random spamming of our wiki, and ensures that anycontent contributed to the wiki can be reused in things such as printed documentation. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jul 17 13:00:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Jul 2006 09:00:37 -0400 Subject: Mass Rebuild Status Message-ID: <200607170900.37265.jkeating@redhat.com> Out of all the packages for FC6, the following packages have either A) not been rebuilt since FC5 or earlier, or B) have not been rebuilt since the new gcc / glibc packages went into the buildroots for gnu_hash. These will need to be built before the freeze on Wed. If you are working on some of these, please let the list know so that we don't stomp on your work. I'll be attacking some of them this afternoon after I clear out some pending package reviews. If you have a spare cycle and want to help out, please rebuild one of the packages in this list and let the list know you did it: ant autoconf cadaver cairo classpathx-jaf compat-gcc-296 cpufreq-utils cryptix cscope ctags cyrus-sasl dasher db4 desktop-file-utils eclipse eclipse-bugzilla eclipse-cdt eclipse-changelog eclipse-pydev emacs epic epiphany firefox gkrellm gnome-power-manager gnuplot hesiod imake inn iputils jakarta-commons-beanutils jakarta-commons-collections jakarta-commons-daemon jakarta-commons-digester jakarta-commons-lang jakarta-commons-logging jakarta-commons-modeler javacc java_cup kdeaccessibility kdeadmin kdebindings kdelibs kdemultimedia kdepim krb5 libaio libexif librtas libselinux libsemanage MAKEDEV mcelog microcode_ctl minicom mozilla mx4j mysql-connector-odbc ncpfs ntp openCryptoki openjade openoffice.org pam_krb5 pam_pkcs11 pciutils pcmciautils pilot-link policycoreutils postgresql psmisc PyXML radvd redhat-artwork s390utils samba stardict struts swig sysfsutils sysreport system-config-securitylevel system-switch-mail thunderbird tux vnc wsdl4j xalan-j2 xchat xen xfsprogs yelp -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jmoyer at redhat.com Mon Jul 17 13:10:38 2006 From: jmoyer at redhat.com (Jeff Moyer) Date: Mon, 17 Jul 2006 09:10:38 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> (Jesse Keating's message of "Mon, 17 Jul 2006 09:00:37 -0400") References: <200607170900.37265.jkeating@redhat.com> Message-ID: ==> Regarding Mass Rebuild Status; Jesse Keating adds: jkeating> libaio building now. -Jeff From dwalsh at redhat.com Mon Jul 17 13:29:02 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Jul 2006 09:29:02 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <44BB909E.3040607@redhat.com> libselinux,libsemanage, policycoreutils rebuilt. Jesse Keating wrote: > Out of all the packages for FC6, the following packages have either A) not > been rebuilt since FC5 or earlier, or B) have not been rebuilt since the new > gcc / glibc packages went into the buildroots for gnu_hash. > > These will need to be built before the freeze on Wed. If you are working on > some of these, please let the list know so that we don't stomp on your work. > I'll be attacking some of them this afternoon after I clear out some pending > package reviews. If you have a spare cycle and want to help out, please > rebuild one of the packages in this list and let the list know you did it: > > ant > autoconf > cadaver > cairo > classpathx-jaf > compat-gcc-296 > cpufreq-utils > cryptix > cscope > ctags > cyrus-sasl > dasher > db4 > desktop-file-utils > eclipse > eclipse-bugzilla > eclipse-cdt > eclipse-changelog > eclipse-pydev > emacs > epic > epiphany > firefox > gkrellm > gnome-power-manager > gnuplot > hesiod > imake > inn > iputils > jakarta-commons-beanutils > jakarta-commons-collections > jakarta-commons-daemon > jakarta-commons-digester > jakarta-commons-lang > jakarta-commons-logging > jakarta-commons-modeler > javacc > java_cup > kdeaccessibility > kdeadmin > kdebindings > kdelibs > kdemultimedia > kdepim > krb5 > libaio > libexif > librtas > libselinux > libsemanage > MAKEDEV > mcelog > microcode_ctl > minicom > mozilla > mx4j > mysql-connector-odbc > ncpfs > ntp > openCryptoki > openjade > openoffice.org > pam_krb5 > pam_pkcs11 > pciutils > pcmciautils > pilot-link > policycoreutils > postgresql > psmisc > PyXML > radvd > redhat-artwork > s390utils > samba > stardict > struts > swig > sysfsutils > sysreport > system-config-securitylevel > system-switch-mail > thunderbird > tux > vnc > wsdl4j > xalan-j2 > xchat > xen > xfsprogs > yelp > > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From jnovy at redhat.com Mon Jul 17 13:45:17 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 17 Jul 2006 15:45:17 +0200 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153143917.25640.51.camel@localhost.localdomain> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > Out of all the packages for FC6, the following packages have either A) not > been rebuilt since FC5 or earlier, or B) have not been rebuilt since the new > gcc / glibc packages went into the buildroots for gnu_hash. > db4 I tried to rebuild db4, but I received this as the result: BuildrootError: error building package (arch ia64), mock exited with status 10 without any logs available to look in. I briefly looked into mock sources where I see: # result/exit codes # 0 = yay! # 1 = something happened - it's bad # 30 = Yum emitted an error of some sort # 40 = some error in the pkg we're building # 10 = problem building the package # 20 = error in the chroot of some kind ... what was not of a big help to me. Does anyone know what the exit status 10 means? Thanks, Jindrich From twaugh at redhat.com Mon Jul 17 14:00:59 2006 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 17 Jul 2006 15:00:59 +0100 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153144859.3964.21.camel@cyberelk.elk> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > openjade Rebuilt. Tim. */ -------------- 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 mikeb at redhat.com Mon Jul 17 14:02:35 2006 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 17 Jul 2006 10:02:35 -0400 Subject: Mass Rebuild Status In-Reply-To: <1153143917.25640.51.camel@localhost.localdomain> References: <200607170900.37265.jkeating@redhat.com> <1153143917.25640.51.camel@localhost.localdomain> Message-ID: <1153144956.30974.6.camel@liffey.home> On Mon, 2006-07-17 at 15:45 +0200, Jindrich Novy wrote: > On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > > Out of all the packages for FC6, the following packages have either A) not > > been rebuilt since FC5 or earlier, or B) have not been rebuilt since the new > > gcc / glibc packages went into the buildroots for gnu_hash. > > > db4 > > I tried to rebuild db4, but I received this as the result: > > BuildrootError: error building package (arch ia64), mock exited with > status 10 > > without any logs available to look in. I briefly looked into mock > sources where I see: > > # result/exit codes > # 0 = yay! > # 1 = something happened - it's bad > # 30 = Yum emitted an error of some sort > # 40 = some error in the pkg we're building > # 10 = problem building the package > # 20 = error in the chroot of some kind > > ... what was not of a big help to me. > > Does anyone know what the exit status 10 means? I assume you're referring to http://brewweb.devel.redhat.com/brew/taskinfo?taskID=120730 ? You need to look at the arch-specific subtask (ia64 in this case) to find the logs: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=120733 It looks like a linking problem (in build.log, before all the Java warnings): /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o: In function `__do_global_ctors_aux': ../../gcc/config/ia64/crtend.asm:(.text+0x0): multiple definition of `__do_global_ctors_aux' /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o:../../gcc/config/ia64/crtend.asm:(.text+0x0): first defined here collect2: ld returned 1 exit status make: *** [libdb_cxx-4.3.la] Error 1 From Christian.Iseli at licr.org Mon Jul 17 14:04:17 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 17 Jul 2006 16:04:17 +0200 Subject: Mass Rebuild Status In-Reply-To: Your message of "Mon, 17 Jul 2006 15:45:17 +0200." <1153143917.25640.51.camel@localhost.localdomain> Message-ID: <200607171404.k6HE4HDL015283@ludwig-alpha.unil.ch> jnovy at redhat.com said: > # 10 = problem building the package > # 20 = error in the chroot of some kind > ... what was not of a big help to me. > Does anyone know what the exit status 10 means? Well, it says: "# 10 = problem building the package" I agree that's not much comfort... Christian From jakub at redhat.com Mon Jul 17 14:13:25 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 17 Jul 2006 10:13:25 -0400 Subject: Mass Rebuild Status In-Reply-To: <1153144956.30974.6.camel@liffey.home> References: <200607170900.37265.jkeating@redhat.com> <1153143917.25640.51.camel@localhost.localdomain> <1153144956.30974.6.camel@liffey.home> Message-ID: <20060717141325.GF32572@devserv.devel.redhat.com> On Mon, Jul 17, 2006 at 10:02:35AM -0400, Mike Bonnet wrote: > I assume you're referring to > http://brewweb.devel.redhat.com/brew/taskinfo?taskID=120730 ? You need > to look at the arch-specific subtask (ia64 in this case) to find the > logs: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=120733 > > It looks like a linking problem (in build.log, before all the Java > warnings): > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o: In function `__do_global_ctors_aux': > ../../gcc/config/ia64/crtend.asm:(.text+0x0): multiple definition of `__do_global_ctors_aux' > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o:../../gcc/config/ia64/crtend.asm:(.text+0x0): first defined here > collect2: ld returned 1 exit status > make: *** [libdb_cxx-4.3.la] Error 1 Which shows that the libtool hack db4 is using at least needs updating for newer libtool. The above is a broken attempt to build a shared library without -nostdlib and with explicit crt*.o files on the command line (so you in the end are trying to link each of the crt* object files twice). Jakub From gbenson at redhat.com Mon Jul 17 14:55:31 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 17 Jul 2006 15:55:31 +0100 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607170835.25475.jkeating@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <1152916447.3010.203.camel@localhost> <20060717084135.GA3079@redhat.com> <200607170835.25475.jkeating@redhat.com> Message-ID: <20060717145529.GC3079@redhat.com> Jesse Keating wrote: > On Monday 17 July 2006 04:41, Gary Benson wrote: > > You'll have to remove the page's immutable status first > > That page should only be immutable if you don't have a wiki account > and don't have a signed CLA on file so that we can add you to the > EditGroup in the wiki. This prevents random spamming of our wiki, > and ensures that anycontent contributed to the wiki can be reused > in things such as printed documentation. I used to be in the EditGroup. Do I actually have to physically sign something to be added or is the fact I work for Red Hat enough? Cheers, Gary From nalin at redhat.com Mon Jul 17 15:01:43 2006 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 17 Jul 2006 11:01:43 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <20060717150143.GD25278@redhat.com> On Mon, Jul 17, 2006 at 09:00:37AM -0400, Jesse Keating wrote: > These will need to be built before the freeze on Wed. If you are working on > some of these, please let the list know so that we don't stomp on your work. > I'll be attacking some of them this afternoon after I clear out some pending > package reviews. If you have a spare cycle and want to help out, please > rebuild one of the packages in this list and let the list know you did it: > > cyrus-sasl > hesiod > krb5 > MAKEDEV > pam_krb5 Rebuilt. Nalin From tgl at redhat.com Mon Jul 17 15:32:13 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 17 Jul 2006 11:32:13 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <3637.1153150333@sss.pgh.pa.us> Jesse Keating writes: > These will need to be built before the freeze on Wed. > mysql-connector-odbc > postgresql Done. regards, tom lane From davej at redhat.com Mon Jul 17 15:39:25 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 17 Jul 2006 11:39:25 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <20060717153925.GD17898@redhat.com> On Mon, Jul 17, 2006 at 09:00:37AM -0400, Jesse Keating wrote: > Out of all the packages for FC6, the following packages have either A) not > been rebuilt since FC5 or earlier, or B) have not been rebuilt since the new > gcc / glibc packages went into the buildroots for gnu_hash. > > These will need to be built before the freeze on Wed. If you are working on > some of these, please let the list know so that we don't stomp on your work. > I'll be attacking some of them this afternoon after I clear out some pending > package reviews. If you have a spare cycle and want to help out, please > rebuild one of the packages in this list and let the list know you did it: > > cpufreq-utils Last time I tried to build this, brew seemed to be barfing during the creation of the buildroot. I mailed releng, but got no reply. Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Mon Jul 17 16:35:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Jul 2006 12:35:22 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060717145529.GC3079@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> Message-ID: <200607171235.22204.jkeating@redhat.com> On Monday 17 July 2006 10:55, Gary Benson wrote: > I used to be in the EditGroup. ?Do I actually have to physically sign > something to be added or is the fact I work for Red Hat enough? You as a person need to sign the CLA. We started requiring this a short while ago so that the content could be reused. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From green at redhat.com Mon Jul 17 16:39:39 2006 From: green at redhat.com (Anthony Green) Date: Mon, 17 Jul 2006 09:39:39 -0700 Subject: Development/Libraries/Java Group? Message-ID: <1153154379.2666.24.camel@localhost.localdomain> This web page... http://fedoraproject.org/wiki/RPMGroups ...indicates that a Group value of Development/Libraries/Java is OK for Fedora. This is what the JPackage project is using. For the few packages I've migrated from JPackage to Extras, I've changed Group to simply Development/Libraries although I would have preferred Development/Libraries/Java. Is it really ok to use Development/Libraries/Java? Thanks, AG From gbenson at redhat.com Mon Jul 17 16:43:50 2006 From: gbenson at redhat.com (Gary Benson) Date: Mon, 17 Jul 2006 17:43:50 +0100 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607171235.22204.jkeating@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> <200607171235.22204.jkeating@redhat.com> Message-ID: <20060717164349.GD3079@redhat.com> Jesse Keating wrote: > On Monday 17 July 2006 10:55, Gary Benson wrote: > > I used to be in the EditGroup. ?Do I actually have to physically > > sign something to be added or is the fact I work for Red Hat > > enough? > > You as a person need to sign the CLA. We started requiring this > a short while ago so that the content could be reused. How bizarre. Red Hat has global assignments on file with groups like FSF and ASF. Can we not have a similar thing with the Fedora Foundation? Cheers, Gary From sundaram at fedoraproject.org Mon Jul 17 16:47:31 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 17 Jul 2006 22:17:31 +0530 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060717164349.GD3079@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> <200607171235.22204.jkeating@redhat.com> <20060717164349.GD3079@redhat.com> Message-ID: <44BBBF23.7090200@fedoraproject.org> Gary Benson wrote: > Jesse Keating wrote: >> On Monday 17 July 2006 10:55, Gary Benson wrote: >>> I used to be in the EditGroup. Do I actually have to physically >>> sign something to be added or is the fact I work for Red Hat >>> enough? >> You as a person need to sign the CLA. We started requiring this >> a short while ago so that the content could be reused. > > How bizarre. Red Hat has global assignments on file with groups > like FSF and ASF. Can we not have a similar thing with the > Fedora Foundation? > What Fedora Foundation? http://fedoraproject.org/wiki/Foundation Rahul From pnasrat at redhat.com Mon Jul 17 16:54:47 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Mon, 17 Jul 2006 12:54:47 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153155288.2875.10.camel@enki.eridu> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > Out of all the packages for FC6, the following packages have either A) not > librtas As previous discussed with you - I've informed upstream and they're working on. The issue here is due to glibc-kernheaders changes which impact librtas. Paul From jakub at redhat.com Mon Jul 17 17:14:27 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 17 Jul 2006 13:14:27 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <20060717171427.GH32572@devserv.devel.redhat.com> On Mon, Jul 17, 2006 at 09:00:37AM -0400, Jesse Keating wrote: > compat-gcc-296 Rebuilt. Jakub From twoerner at redhat.com Mon Jul 17 17:24:53 2006 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 17 Jul 2006 19:24:53 +0200 Subject: rpmlint: dangling-relative-symlink Message-ID: <44BBC7E5.5010205@redhat.com> Does someone know how to get rid of these output messages from rpmlint? W: openmotif22-debuginfo dangling-relative-symlink /usr/src/debug/openMotif-2.2.3/clients/uil/UilDBDef.h ./../../tools/wml/UilDBDef.h W: openmotif22-debuginfo dangling-relative-symlink /usr/src/debug/openMotif-2.2.3/clients/uil/UilLexPars.c ../../tools/wml/Uil.c W: openmotif22-debuginfo dangling-relative-symlink /usr/src/debug/openMotif-2.2.3/clients/uil/UilParser.c ./UilMain.c Thanks in advance, Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From ville.skytta at iki.fi Mon Jul 17 17:45:42 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 17 Jul 2006 20:45:42 +0300 Subject: Development/Libraries/Java Group? In-Reply-To: <1153154379.2666.24.camel@localhost.localdomain> References: <1153154379.2666.24.camel@localhost.localdomain> Message-ID: <1153158342.2662.82.camel@localhost.localdomain> On Mon, 2006-07-17 at 09:39 -0700, Anthony Green wrote: > This web page... > http://fedoraproject.org/wiki/RPMGroups > > ...indicates that a Group value of Development/Libraries/Java is OK for > Fedora. That page is misleading. It contains two lists, first of which is the list of groups currently generally considered "valid" (which can be found in every FC installation in /usr/share/doc/rpm-*/GROUPS), and the latter was added afterwards and is just a dump of all groups found in FC4 packages. There was already a related item in the packaging committee's TODO list, I've just bumped it so that clarifying this it will hopefully be discussed in this week's meeting. EasyFix, if you ask me :) From paul at city-fan.org Mon Jul 17 17:55:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 17 Jul 2006 18:55:35 +0100 Subject: rpmlint: dangling-relative-symlink In-Reply-To: <44BBC7E5.5010205@redhat.com> References: <44BBC7E5.5010205@redhat.com> Message-ID: <44BBCF17.7080309@city-fan.org> Thomas Woerner wrote: > > Does someone know how to get rid of these output messages from rpmlint? > > W: openmotif22-debuginfo dangling-relative-symlink > /usr/src/debug/openMotif-2.2.3/clients/uil/UilDBDef.h > ./../../tools/wml/UilDBDef.h > W: openmotif22-debuginfo dangling-relative-symlink > /usr/src/debug/openMotif-2.2.3/clients/uil/UilLexPars.c > ../../tools/wml/Uil.c > W: openmotif22-debuginfo dangling-relative-symlink > /usr/src/debug/openMotif-2.2.3/clients/uil/UilParser.c ./UilMain.c It's an rpm bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189928 Paul. From tibbs at math.uh.edu Mon Jul 17 18:16:49 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 17 Jul 2006 13:16:49 -0500 Subject: Development/Libraries/Java Group? In-Reply-To: <1153154379.2666.24.camel@localhost.localdomain> (Anthony Green's message of "Mon, 17 Jul 2006 09:39:39 -0700") References: <1153154379.2666.24.camel@localhost.localdomain> Message-ID: >>>>> "AG" == Anthony Green writes: AG> Is it really ok to use Development/Libraries/Java? We (ultimately the packaging committee and then the various other committees but currently everyone) need to figure out what to do here. There are many more groups used by Core than have been permitted in Extras; I personally think the Extras list is way too small but I'm not sure if Java should get its own package group. Would we have separate groups for the other languages? (There are several hundred Perl modules in Extras alone.) - J< From dbhole at redhat.com Mon Jul 17 18:28:22 2006 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 17 Jul 2006 14:28:22 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153160902.29510.18.camel@tocatta.toronto.redhat.com> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > > ant Done. Deepak From fche at redhat.com Tue Jul 18 01:22:37 2006 From: fche at redhat.com (Frank Ch. Eigler) Date: 17 Jul 2006 21:22:37 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <200607171235.22204.jkeating@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> <200607171235.22204.jkeating@redhat.com> Message-ID: Jesse Keating writes: > You as a person need to sign the CLA. We started requiring this a > short while ago so that the content could be reused. How interesting. Many corporate employees, including AFAIK those at Red Hat, rarely hold intellectual property that is not automatically signed over to the employer. Have you received competent advice that a CLA from such a person is actually worth anything? - FChE From jkeating at redhat.com Tue Jul 18 01:31:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Jul 2006 21:31:33 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152733661.12430.394.camel@localhost.localdomain> <200607171235.22204.jkeating@redhat.com> Message-ID: <200607172131.33716.jkeating@redhat.com> On Monday 17 July 2006 21:22, Frank Ch. Eigler wrote: > How interesting. ?Many corporate employees, including AFAIK those at > Red Hat, rarely hold intellectual property that is not automatically > signed over to the employer. ?Have you received competent advice that > a CLA from such a person is actually worth anything? Our legal department requested it, even from our own employees. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Jul 18 01:31:44 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 17 Jul 2006 20:31:44 -0500 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> <200607171235.22204.jkeating@redhat.com> Message-ID: <1153186304.12401.52.camel@vader.jdub.homelinux.org> On Mon, 2006-07-17 at 21:22 -0400, Frank Ch. Eigler wrote: > Jesse Keating writes: > > > You as a person need to sign the CLA. We started requiring this a > > short while ago so that the content could be reused. > > How interesting. Many corporate employees, including AFAIK those at > Red Hat, rarely hold intellectual property that is not automatically > signed over to the employer. Have you received competent advice that > a CLA from such a person is actually worth anything? That depends on state law as well. Some states do not allow this. Legalese aside, I believe it is worth doing for Red Hat employees anyway. It's important. And it also means everyone is on the same playing field when it comes to our community driven distro. josh From jnovy at redhat.com Tue Jul 18 05:57:42 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 18 Jul 2006 07:57:42 +0200 Subject: Mass Rebuild Status In-Reply-To: <20060717141325.GF32572@devserv.devel.redhat.com> References: <200607170900.37265.jkeating@redhat.com> <1153143917.25640.51.camel@localhost.localdomain> <1153144956.30974.6.camel@liffey.home> <20060717141325.GF32572@devserv.devel.redhat.com> Message-ID: <1153202262.2243.8.camel@localhost.localdomain> On Mon, 2006-07-17 at 10:13 -0400, Jakub Jelinek wrote: > On Mon, Jul 17, 2006 at 10:02:35AM -0400, Mike Bonnet wrote: > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o: In function `__do_global_ctors_aux': > > ../../gcc/config/ia64/crtend.asm:(.text+0x0): multiple definition of `__do_global_ctors_aux' > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o:../../gcc/config/ia64/crtend.asm:(.text+0x0): first defined here > > collect2: ld returned 1 exit status > > make: *** [libdb_cxx-4.3.la] Error 1 > > Which shows that the libtool hack db4 is using at least needs updating > for newer libtool. The above is a broken attempt to build a shared > library without -nostdlib and with explicit crt*.o files on the command > line (so you in the end are trying to link each of the crt* object files > twice). Caused by the recent libtool rawhide changes. I'm in touch with Karsten to decide whether to fix this on db4 or libtool side. The rawhide db4 builds just fine with FC5 libtool. Jindrich From gbenson at redhat.com Tue Jul 18 07:47:02 2006 From: gbenson at redhat.com (Gary Benson) Date: Tue, 18 Jul 2006 08:47:02 +0100 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <44BBBF23.7090200@fedoraproject.org> References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> <200607171235.22204.jkeating@redhat.com> <20060717164349.GD3079@redhat.com> <44BBBF23.7090200@fedoraproject.org> Message-ID: <20060718074700.GA3038@redhat.com> Rahul wrote: > Gary Benson wrote: > > Jesse Keating wrote: > > > On Monday 17 July 2006 10:55, Gary Benson wrote: > > > > I used to be in the EditGroup. Do I actually have to > > > > physically sign something to be added or is the fact I > > > > work for Red Hat enough? > > > > > > You as a person need to sign the CLA. We started requiring > > > this a short while ago so that the content could be reused. > > > > How bizarre. Red Hat has global assignments on file with > > groups like FSF and ASF. Can we not have a similar thing > > with the Fedora Foundation? > > What Fedora Foundation? > > http://fedoraproject.org/wiki/Foundation Yeah, I realised as I hit send :) Gary From rvokal at redhat.com Tue Jul 18 07:52:51 2006 From: rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Tue, 18 Jul 2006 09:52:51 +0200 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153209171.2983.53.camel@localhost.localdomain> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > iputils Done -- Radek Vok?l From majain at redhat.com Tue Jul 18 08:18:07 2006 From: majain at redhat.com (=?UTF-8?Q?=E0=A4=AE=E0=A4=AF=E0=A4=82=E0=A4=95_=E0=A4=9C=E0=A5=88?= =?UTF-8?Q?=E0=A4=A8?=) Date: Tue, 18 Jul 2006 13:48:07 +0530 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153210687.22305.25.camel@majain.pnq.redhat.com> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > stardict Hi, I'm trying to build stardict in brew, but it fails with following errors... -------------------------------------------- if g++ -DHAVE_CONFIG_H -I. -I. -I.. -Wall -DORBIT2=1 -pthread -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libxml2 -DDATADIR=\""/usr/share"\" -DGNOME_ICONDIR=\""/usr/share/pixmaps"\" -DSTARDICT_LOCALEDIR=\""/usr//locale"\" -DSTARDICT_DATA_DIR= \""/usr/share/stardict"\" -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -MT stardict-application-server.o -MD -MP -MF ".deps/stardict-application-server.Tpo" -c -o stardict-application-server.o stardict-application-server.cpp; \ then mv -f ".deps/stardict-application-server.Tpo" ".deps/stardict-application-server.Po"; else rm -f ".deps/stardict-application-server.Tpo"; exit 1; fi /usr/include/libintl.h:40: error: expected unqualified-id before 'const' /usr/include/libintl.h:40: error: expected `)' before 'const' /usr/include/libintl.h:40: error: expected initializer before 'const' /usr/include/libintl.h:45: error: expected unqualified-id before 'const' /usr/include/libintl.h:45: error: expected `)' before 'const' /usr/include/libintl.h:45: error: expected initializer before 'const' /usr/include/libintl.h:52: error: expected unqualified-id before 'const' /usr/include/libintl.h:52: error: expected `)' before 'const' /usr/include/libintl.h:52: error: expected initializer before 'const' /usr/include/libintl.h:83: error: expected unqualified-id before 'const' /usr/include/libintl.h:83: error: expected `)' before 'const' /usr/include/libintl.h:83: error: expected initializer before 'const' /usr/include/libintl.h:87: error: expected unqualified-id before 'const' /usr/include/libintl.h:87: error: expected `)' before 'const' /usr/include/libintl.h:87: error: expected initializer before 'const' /usr/include/libintl.h:92: error: expected unqualified-id before 'const' /usr/include/libintl.h:92: error: expected `)' before 'const' /usr/include/libintl.h:92: error: expected initializer before 'const' make[3]: *** [stardict-application-server.o] Error 1 make[3]: Leaving directory `/builddir/build/BUILD/stardict-2.4.5/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/stardict-2.4.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/stardict-2.4.5' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.64670 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.64670 (%build) -------------------------------------------- Can anyone suggest how to correct this? Thanks, Mayank From michael at knox.net.nz Wed Jul 19 09:07:42 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 19 Jul 2006 21:07:42 +1200 Subject: Mass Rebuild Status In-Reply-To: <1153210687.22305.25.camel@majain.pnq.redhat.com> References: <200607170900.37265.jkeating@redhat.com> <1153210687.22305.25.camel@majain.pnq.redhat.com> Message-ID: <44BDF65E.4090909@knox.net.nz> ???? ??? wrote: > On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: >> stardict > > Hi, > > I'm trying to build stardict in brew, but it fails with following > errors... [snip] > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.64670 (%build) > -------------------------------------------- > Can anyone suggest how to correct this? I added "BuildRequries: gettext" and rebuilt this in mock/rawhide successfully. Removing gettext from the BuildRequires reproduced the error. Michael From karsten at redhat.de Tue Jul 18 11:41:24 2006 From: karsten at redhat.de (Karsten Hopp) Date: Tue, 18 Jul 2006 13:41:24 +0200 Subject: Mass Rebuild Status In-Reply-To: <1153202262.2243.8.camel@localhost.localdomain> References: <200607170900.37265.jkeating@redhat.com> <1153143917.25640.51.camel@localhost.localdomain> <1153144956.30974.6.camel@liffey.home> <20060717141325.GF32572@devserv.devel.redhat.com> <1153202262.2243.8.camel@localhost.localdomain> Message-ID: <20060718114124.GF15048@redhat.de> On Tue, Jul 18, 2006 at 07:57:42AM +0200, Jindrich Novy wrote: > On Mon, 2006-07-17 at 10:13 -0400, Jakub Jelinek wrote: > > On Mon, Jul 17, 2006 at 10:02:35AM -0400, Mike Bonnet wrote: > > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o: In function `__do_global_ctors_aux': > > > ../../gcc/config/ia64/crtend.asm:(.text+0x0): multiple definition of `__do_global_ctors_aux' > > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o:../../gcc/config/ia64/crtend.asm:(.text+0x0): first defined here > > > collect2: ld returned 1 exit status > > > make: *** [libdb_cxx-4.3.la] Error 1 > > > > Which shows that the libtool hack db4 is using at least needs updating > > for newer libtool. The above is a broken attempt to build a shared > > library without -nostdlib and with explicit crt*.o files on the command > > line (so you in the end are trying to link each of the crt* object files > > twice). > > Caused by the recent libtool rawhide changes. I'm in touch with Karsten > to decide whether to fix this on db4 or libtool side. The rawhide db4 > builds just fine with FC5 libtool. > > Jindrich A one line change in db4.spec fixes this Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From jnovy at redhat.com Tue Jul 18 13:46:42 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 18 Jul 2006 15:46:42 +0200 Subject: Mass Rebuild Status In-Reply-To: <20060718114124.GF15048@redhat.de> References: <200607170900.37265.jkeating@redhat.com> <1153143917.25640.51.camel@localhost.localdomain> <1153144956.30974.6.camel@liffey.home> <20060717141325.GF32572@devserv.devel.redhat.com> <1153202262.2243.8.camel@localhost.localdomain> <20060718114124.GF15048@redhat.de> Message-ID: <1153230402.2247.16.camel@localhost.localdomain> On Tue, 2006-07-18 at 13:41 +0200, Karsten Hopp wrote: > On Tue, Jul 18, 2006 at 07:57:42AM +0200, Jindrich Novy wrote: > > On Mon, 2006-07-17 at 10:13 -0400, Jakub Jelinek wrote: > > > On Mon, Jul 17, 2006 at 10:02:35AM -0400, Mike Bonnet wrote: > > > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o: In function `__do_global_ctors_aux': > > > > ../../gcc/config/ia64/crtend.asm:(.text+0x0): multiple definition of `__do_global_ctors_aux' > > > > /usr/lib/gcc/ia64-redhat-linux/4.1.1/crtendS.o:../../gcc/config/ia64/crtend.asm:(.text+0x0): first defined here > > > > collect2: ld returned 1 exit status > > > > make: *** [libdb_cxx-4.3.la] Error 1 > > > > > > Which shows that the libtool hack db4 is using at least needs updating > > > for newer libtool. The above is a broken attempt to build a shared > > > library without -nostdlib and with explicit crt*.o files on the command > > > line (so you in the end are trying to link each of the crt* object files > > > twice). > > > > Caused by the recent libtool rawhide changes. I'm in touch with Karsten > > to decide whether to fix this on db4 or libtool side. The rawhide db4 > > builds just fine with FC5 libtool. > > > > Jindrich > > A one line change in db4.spec fixes this db4 is now rebuilt. Jindrich From jkeating at redhat.com Tue Jul 18 15:07:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Jul 2006 11:07:30 -0400 Subject: Rebuild Status Message-ID: <200607181107.30407.jkeating@redhat.com> We're doing a great job, just a few more remain, but I think most of these are held up by one issue or another. autoconf cairo classpathx-jaf cpufreq-utils cryptix dasher desktop-file-utils eclipse-bugzilla eclipse-cdt eclipse-changelog eclipse-pydev emacs epic epiphany firefox gkrellm gnome-power-manager gnuplot javacc java_cup kdebindings kdepim libexif librtas mozilla mx4j openCryptoki psmisc PyXML redhat-artwork samba stardict thunderbird wsdl4j xalan-j2 xchat xfsprogs yelp And for a semi-regularly updated list: http://people.redhat.com/jkeating/naglist -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jul 18 15:38:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Jul 2006 11:38:18 -0400 Subject: Rebuild Status In-Reply-To: <200607181107.30407.jkeating@redhat.com> References: <200607181107.30407.jkeating@redhat.com> Message-ID: <200607181138.18430.jkeating@redhat.com> On Tuesday 18 July 2006 11:07, Jesse Keating wrote: > stardict I picked this one off. (Thanks MJK!) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Tue Jul 18 20:23:12 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 18 Jul 2006 13:23:12 -0700 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <20060718074700.GA3038@redhat.com> References: <1152733661.12430.394.camel@localhost.localdomain> <200607170835.25475.jkeating@redhat.com> <20060717145529.GC3079@redhat.com> <200607171235.22204.jkeating@redhat.com> <20060717164349.GD3079@redhat.com> <44BBBF23.7090200@fedoraproject.org> <20060718074700.GA3038@redhat.com> Message-ID: <1153254192.3007.13.camel@localhost> On Tue, 2006-07-18 at 08:47 +0100, Gary Benson wrote: > Rahul wrote: > > Gary Benson wrote: > > > Jesse Keating wrote: > > > > On Monday 17 July 2006 10:55, Gary Benson wrote: > > > > > I used to be in the EditGroup. Do I actually have to > > > > > physically sign something to be added or is the fact I > > > > > work for Red Hat enough? > > > > > > > > You as a person need to sign the CLA. We started requiring > > > > this a short while ago so that the content could be reused. > > > > > > How bizarre. Red Hat has global assignments on file with > > > groups like FSF and ASF. Can we not have a similar thing > > > with the Fedora Foundation? > > > > What Fedora Foundation? > > > > http://fedoraproject.org/wiki/Foundation > > Yeah, I realised as I hit send :) If we could steer this back on topic, the Packaging Committee does need to know what the goals are. It doesn't matter whether that communication comes through the mailing list or the wiki. In fact, discussion here or on fedora-packaging will be beneficial as it's more conducive to questions and clarifications. Thanks, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Wed Jul 19 02:36:50 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Jul 2006 22:36:50 -0400 Subject: FC6 Test2 Freeze Slip Message-ID: <1153276610.6545.46.camel@aglarond.local> With the update to a 2.6.18-rc based kernel, Xen requires some more effort to get to working. Given that Xen is one of the big features for Fedora Core 6, trying to ship the second test release (and thus the feature freeze) without Xen seems like a less than ideal situation. Therefore, after discussion within the Fedora Board, we have decided to slip the freeze for test2 until Xen is working again with current kernels. Based on current estimates, it looks like this should hopefully be Monday, 24 July. We'll continue to provide updates as more information is available. Jeremy From skasal at redhat.com Wed Jul 19 09:57:45 2006 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 19 Jul 2006 11:57:45 +0200 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <20060719095745.GA19619@camelia.ucw.cz> Hello Jesse, On Mon, Jul 17, 2006 at 09:00:37AM -0400, Jesse Keating wrote: > autoconf please do not rebuild Autoconf. The dist CVS contains 2.60 (I was not able to make a build in dist-fc6-test without a tag), but several packages are not yet ready for it. Autoconf is a noarch package, so this should not be a problem here. Have a nice day, Stepan From jkeating at redhat.com Wed Jul 19 12:46:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Jul 2006 08:46:08 -0400 Subject: Mass Rebuild Status In-Reply-To: <20060719095745.GA19619@camelia.ucw.cz> References: <200607170900.37265.jkeating@redhat.com> <20060719095745.GA19619@camelia.ucw.cz> Message-ID: <200607190846.09028.jkeating@redhat.com> On Wednesday 19 July 2006 05:57, Stepan Kasal wrote: > please do not rebuild Autoconf. ?The dist CVS contains 2.60 (I was > not able to make a build in dist-fc6-test without a tag), but several > packages are not yet ready for it. > > Autoconf is a noarch package, so this should not be a problem here. Hrm, for some reason it is being triggered by my search which looks for packages that are either A) pulled in by FC-5, or B) not build by brew or C) are arch specific and haven't been rebuilt since the glibc/gcc changes went in for gnu-hash. From a quick look, it seems that it has not yet been built by brew, which is one of the goals of this rebuild. If you would be so kind as to back down your 2.60 changes to rebuild 2.59 we can satisfy this requirement. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Jul 19 12:57:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 07:57:09 -0500 Subject: Move dbus-qt into Fedora Core? In-Reply-To: <44B5C0F9.2000309@fedoraproject.org> References: <44B5C0F9.2000309@fedoraproject.org> Message-ID: <44BE2C25.1090007@math.unl.edu> Rahul wrote: > dbus-qt is a package in Fedora Extras that K3b (as a build time optional > dependency whicht takes advantage of hal to do things better) and > possibly other KDE applications can take advantage of. For the record, upstream dbus has removed (all) bindings from the main (core) tarball, and has subsequently dropped support for qt(3) altogether (lack of maintainer?). dbus-qt4 bindings are (will be) included in qt4-4.2.0. -- Rex From sundaram at fedoraproject.org Wed Jul 19 13:46:56 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 19 Jul 2006 19:16:56 +0530 Subject: Mozilla suite dependencies Message-ID: <44BE37D0.2060105@fedoraproject.org> Hi Mozilla suite is included in Fedora Core while Seamonkey which is the newer version is included in Fedora Extras. Mozilla suite is a older redundant code base with potential security issues in Fedora Core. The problem is that Yelp, Devhelp and possibly other packages are build against Mozilla suite and one way to resolve it is to include XULRunner and rebuild all the applications that require the Gecko engine against it or atleast rebuild all of them against Firefox and chuck out Mozilla suite. Comments? Rahul From notting at redhat.com Wed Jul 19 13:56:41 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 19 Jul 2006 09:56:41 -0400 Subject: Mozilla suite dependencies In-Reply-To: <44BE37D0.2060105@fedoraproject.org> References: <44BE37D0.2060105@fedoraproject.org> Message-ID: <20060719135641.GC2908@nostromo.devel.redhat.com> Rahul (sundaram at fedoraproject.org) said: > Mozilla suite is included in Fedora Core while Seamonkey which is the > newer version is included in Fedora Extras. Mozilla suite is a older > redundant code base with potential security issues in Fedora Core. The > problem is that Yelp, Devhelp and possibly other packages are build > against Mozilla suite and one way to resolve it is to include XULRunner > and rebuild all the applications that require the Gecko engine against > it or atleast rebuild all of them against Firefox and chuck out Mozilla > suite. Comments? XULRunner is not baked yet, AFAIK. Bill From peter at thecodergeek.com Wed Jul 19 14:46:35 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 19 Jul 2006 07:46:35 -0700 (PDT) Subject: Mozilla suite dependencies In-Reply-To: <20060719135641.GC2908@nostromo.devel.redhat.com> References: <44BE37D0.2060105@fedoraproject.org> <20060719135641.GC2908@nostromo.devel.redhat.com> Message-ID: <42073.127.0.0.1.1153320395.squirrel@www.thecodergeek.com> Bill Nottingham wrote: > XULRunner is not baked yet, AFAIK. Then is there still a reason we don't build everything Gecko-based against Firefox instead the Mozilla suite? Older Firefox builds did not provide the necessary headers as I recall, but that has been fixed as of recent, no? Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From jkeating at redhat.com Wed Jul 19 23:31:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Jul 2006 19:31:38 -0400 Subject: Broken upgrade paths Message-ID: <200607191931.38818.jkeating@redhat.com> pkg FC5 devel elinks elinks-0.11.0-2.3 elinks-0.11.1-4.1 gawk gawk-3.1.5-6.3 gawk-3.1.5-11 gnome-applet-vm gnome-applet-vm-0.0.7-2 gnome-applet-vm-0.1.0-0.rc1 lockdev lockdev-1.0.1-9.2.1 lockdev-1.0.1-10 lslk lslk-1.29-16.2.1 lslk-1.29-17 lsof lsof-4.77-1 lsof-4.78-1 procinfo procinfo-18-18.2.2 procinfo-18-19 procps procps-3.2.6-3.5 procps-3.2.7-3 psmisc psmisc-22.2-1.1 psmisc-22.2-5 readahead readahead-1.2-2 readahead-1.3-1 rsh rsh-0.17-34.1 rsh-0.17-35 sudo sudo-1.6.8p12-4.1 sudo-1.6.8p12-7 util-linux util-linux-2.13-0.20.4 util-linux-2.13-0.33 vlock vlock-1.3-22.2.1 vlock-1.3-23 words words-3.0-8.1 words-3.0-9 am-utils am-utils-6.1.3-1.2.1 am-utils-6.1.5-3 (thanks karel) (I'll do a more through query through brew tomorrow) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu Jul 20 03:44:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 19 Jul 2006 22:44:24 -0500 Subject: Broken upgrade paths In-Reply-To: <200607191931.38818.jkeating@redhat.com> References: <200607191931.38818.jkeating@redhat.com> Message-ID: <1153367064.11648.8.camel@localhost.localdomain> On Wed, 2006-07-19 at 19:31 -0400, Jesse Keating wrote: > pkg FC5 devel > > elinks elinks-0.11.0-2.3 elinks-0.11.1-4.1 > gawk gawk-3.1.5-6.3 gawk-3.1.5-11 > gnome-applet-vm gnome-applet-vm-0.0.7-2 gnome-applet-vm-0.1.0-0.rc1 > lockdev lockdev-1.0.1-9.2.1 lockdev-1.0.1-10 > lslk lslk-1.29-16.2.1 lslk-1.29-17 > lsof lsof-4.77-1 lsof-4.78-1 > procinfo procinfo-18-18.2.2 procinfo-18-19 > procps procps-3.2.6-3.5 procps-3.2.7-3 > psmisc psmisc-22.2-1.1 psmisc-22.2-5 > readahead readahead-1.2-2 readahead-1.3-1 > rsh rsh-0.17-34.1 rsh-0.17-35 > sudo sudo-1.6.8p12-4.1 sudo-1.6.8p12-7 > util-linux util-linux-2.13-0.20.4 util-linux-2.13-0.33 > vlock vlock-1.3-22.2.1 vlock-1.3-23 > words words-3.0-8.1 words-3.0-9 > am-utils am-utils-6.1.3-1.2.1 am-utils-6.1.5-3 FWIW, this is _exactly_ why you should bump Release as a whole number unless you have a really good reason not to. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Thu Jul 20 04:12:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 23:12:47 -0500 Subject: Broken upgrade paths In-Reply-To: <200607191931.38818.jkeating@redhat.com> (Jesse Keating's message of "Wed, 19 Jul 2006 19:31:38 -0400") References: <200607191931.38818.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> elinks-0.11.0-2.3 elinks-0.11.1-4.1 What am I missing? > fedora-rpmvercmp 0 11.0 2.3 0 11.1 4.1 0:11.1-4.1 is newer Is there dist tag interaction that's not being shown? - J< From tgl at redhat.com Thu Jul 20 04:51:59 2006 From: tgl at redhat.com (Tom Lane) Date: Thu, 20 Jul 2006 00:51:59 -0400 Subject: Broken upgrade paths In-Reply-To: <200607191931.38818.jkeating@redhat.com> References: <200607191931.38818.jkeating@redhat.com> Message-ID: <23577.1153371119@sss.pgh.pa.us> Jesse Keating writes: > pkg FC5 devel > elinks elinks-0.11.0-2.3 elinks-0.11.1-4.1 > gawk gawk-3.1.5-6.3 gawk-3.1.5-11 > gnome-applet-vm gnome-applet-vm-0.0.7-2 gnome-applet-vm-0.1.0-0.rc1 > lockdev lockdev-1.0.1-9.2.1 lockdev-1.0.1-10 > lslk lslk-1.29-16.2.1 lslk-1.29-17 > lsof lsof-4.77-1 lsof-4.78-1 > procinfo procinfo-18-18.2.2 procinfo-18-19 > procps procps-3.2.6-3.5 procps-3.2.7-3 > psmisc psmisc-22.2-1.1 psmisc-22.2-5 > readahead readahead-1.2-2 readahead-1.3-1 > rsh rsh-0.17-34.1 rsh-0.17-35 > sudo sudo-1.6.8p12-4.1 sudo-1.6.8p12-7 > util-linux util-linux-2.13-0.20.4 util-linux-2.13-0.33 > vlock vlock-1.3-22.2.1 vlock-1.3-23 > words words-3.0-8.1 words-3.0-9 > am-utils am-utils-6.1.3-1.2.1 am-utils-6.1.5-3 I must need to go back to RPM school, because AFAICS the devel version should be considered newer in every one of those cases. What's the problem exactly? regards, tom lane From tcallawa at redhat.com Thu Jul 20 05:00:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 20 Jul 2006 00:00:06 -0500 Subject: Broken upgrade paths In-Reply-To: <23577.1153371119@sss.pgh.pa.us> References: <200607191931.38818.jkeating@redhat.com> <23577.1153371119@sss.pgh.pa.us> Message-ID: <1153371606.11648.12.camel@localhost.localdomain> On Thu, 2006-07-20 at 00:51 -0400, Tom Lane wrote: > Jesse Keating writes: > > pkg FC5 devel > > > elinks elinks-0.11.0-2.3 elinks-0.11.1-4.1 > > gawk gawk-3.1.5-6.3 gawk-3.1.5-11 > > gnome-applet-vm gnome-applet-vm-0.0.7-2 gnome-applet-vm-0.1.0-0.rc1 > > lockdev lockdev-1.0.1-9.2.1 lockdev-1.0.1-10 > > lslk lslk-1.29-16.2.1 lslk-1.29-17 > > lsof lsof-4.77-1 lsof-4.78-1 > > procinfo procinfo-18-18.2.2 procinfo-18-19 > > procps procps-3.2.6-3.5 procps-3.2.7-3 > > psmisc psmisc-22.2-1.1 psmisc-22.2-5 > > readahead readahead-1.2-2 readahead-1.3-1 > > rsh rsh-0.17-34.1 rsh-0.17-35 > > sudo sudo-1.6.8p12-4.1 sudo-1.6.8p12-7 > > util-linux util-linux-2.13-0.20.4 util-linux-2.13-0.33 > > vlock vlock-1.3-22.2.1 vlock-1.3-23 > > words words-3.0-8.1 words-3.0-9 > > am-utils am-utils-6.1.3-1.2.1 am-utils-6.1.5-3 > > I must need to go back to RPM school, because AFAICS the devel version > should be considered newer in every one of those cases. What's the > problem exactly? RPM doesn't really treat these numbers as integers. Instead of treating that . as a decimal separator for a whole number like our brain does, it just treats it as a string. so, 18.2.2 is > 19 for rpm, because it is a longer string. (This is a drastic oversimplification, but it should serve the purpose) The best way to avoid this problem? Keep your Release field as a whole number, then rpm knows that 18 < 19. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at linux.duke.edu Thu Jul 20 05:04:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 20 Jul 2006 01:04:15 -0400 Subject: Broken upgrade paths In-Reply-To: <1153371606.11648.12.camel@localhost.localdomain> References: <200607191931.38818.jkeating@redhat.com> <23577.1153371119@sss.pgh.pa.us> <1153371606.11648.12.camel@localhost.localdomain> Message-ID: <1153371855.14939.90.camel@cutter> On Thu, 2006-07-20 at 00:00 -0500, Tom 'spot' Callaway wrote: > On Thu, 2006-07-20 at 00:51 -0400, Tom Lane wrote: > > Jesse Keating writes: > > > pkg FC5 devel > > > > > elinks elinks-0.11.0-2.3 elinks-0.11.1-4.1 > > > gawk gawk-3.1.5-6.3 gawk-3.1.5-11 > > > gnome-applet-vm gnome-applet-vm-0.0.7-2 gnome-applet-vm-0.1.0-0.rc1 > > > lockdev lockdev-1.0.1-9.2.1 lockdev-1.0.1-10 > > > lslk lslk-1.29-16.2.1 lslk-1.29-17 > > > lsof lsof-4.77-1 lsof-4.78-1 > > > procinfo procinfo-18-18.2.2 procinfo-18-19 > > > procps procps-3.2.6-3.5 procps-3.2.7-3 > > > psmisc psmisc-22.2-1.1 psmisc-22.2-5 > > > readahead readahead-1.2-2 readahead-1.3-1 > > > rsh rsh-0.17-34.1 rsh-0.17-35 > > > sudo sudo-1.6.8p12-4.1 sudo-1.6.8p12-7 > > > util-linux util-linux-2.13-0.20.4 util-linux-2.13-0.33 > > > vlock vlock-1.3-22.2.1 vlock-1.3-23 > > > words words-3.0-8.1 words-3.0-9 > > > am-utils am-utils-6.1.3-1.2.1 am-utils-6.1.5-3 > > > > I must need to go back to RPM school, because AFAICS the devel version > > should be considered newer in every one of those cases. What's the > > problem exactly? > > RPM doesn't really treat these numbers as integers. Instead of treating > that . as a decimal separator for a whole number like our brain does, it > just treats it as a string. > > so, 18.2.2 is > 19 for rpm, because it is a longer string. > > (This is a drastic oversimplification, but it should serve the purpose) > > The best way to avoid this problem? Keep your Release field as a whole > number, then rpm knows that 18 < 19. umm 18.2.2 is < 19 rpmUtils.miscutils.compareEVR(('0','1','18.2.2'),('0','1','19')) -1 rpm compares via tokens. so if you look at the string as: 18 and 2 and 2 and the other as 19 then rpm starts from left to right and compares the first token it finds that lines up. it sees 18 and 19 18 < 19 therefore 19 wins. no more comparison. EOD. -sv From tcallawa at redhat.com Thu Jul 20 05:10:15 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 20 Jul 2006 00:10:15 -0500 Subject: Broken upgrade paths In-Reply-To: <1153371855.14939.90.camel@cutter> References: <200607191931.38818.jkeating@redhat.com> <23577.1153371119@sss.pgh.pa.us> <1153371606.11648.12.camel@localhost.localdomain> <1153371855.14939.90.camel@cutter> Message-ID: <1153372215.11648.14.camel@localhost.localdomain> On Thu, 2006-07-20 at 01:04 -0400, seth vidal wrote: > no more comparison. EOD. ... and this is why I don't maintain RPM. OK, I have no idea why these packages are not cleanly upgrading. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From kzak at redhat.com Thu Jul 20 09:34:41 2006 From: kzak at redhat.com (Karel Zak) Date: Thu, 20 Jul 2006 11:34:41 +0200 Subject: Broken upgrade paths In-Reply-To: <200607191931.38818.jkeating@redhat.com> References: <200607191931.38818.jkeating@redhat.com> Message-ID: <20060720093441.GR3683@petra.dvoda.cz> Hi Jesse, it's misunderstanding. Sorry. The list show that all my packages are fine now :-) I didn't check others packages. I think write some script that compare repodata/primary.xml between distributions shouldn't be problem. I can try write it and send some results. Karel On Wed, Jul 19, 2006 at 07:31:38PM -0400, Jesse Keating wrote: > pkg FC5 devel > > elinks elinks-0.11.0-2.3 elinks-0.11.1-4.1 > gawk gawk-3.1.5-6.3 gawk-3.1.5-11 > gnome-applet-vm gnome-applet-vm-0.0.7-2 gnome-applet-vm-0.1.0-0.rc1 > lockdev lockdev-1.0.1-9.2.1 lockdev-1.0.1-10 > lslk lslk-1.29-16.2.1 lslk-1.29-17 > lsof lsof-4.77-1 lsof-4.78-1 > procinfo procinfo-18-18.2.2 procinfo-18-19 > procps procps-3.2.6-3.5 procps-3.2.7-3 > psmisc psmisc-22.2-1.1 psmisc-22.2-5 > readahead readahead-1.2-2 readahead-1.3-1 > rsh rsh-0.17-34.1 rsh-0.17-35 > sudo sudo-1.6.8p12-4.1 sudo-1.6.8p12-7 > util-linux util-linux-2.13-0.20.4 util-linux-2.13-0.33 > vlock vlock-1.3-22.2.1 vlock-1.3-23 > words words-3.0-8.1 words-3.0-9 > am-utils am-utils-6.1.3-1.2.1 am-utils-6.1.5-3 > > (thanks karel) > > (I'll do a more through query through brew tomorrow) > -- > Jesse Keating > Release Engineer: Fedora > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Karel Zak From fedora at leemhuis.info Thu Jul 20 09:48:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Jul 2006 11:48:40 +0200 Subject: Broken upgrade paths In-Reply-To: <20060720093441.GR3683@petra.dvoda.cz> References: <200607191931.38818.jkeating@redhat.com> <20060720093441.GR3683@petra.dvoda.cz> Message-ID: <44BF5178.3080802@leemhuis.info> Karel Zak schrieb: > I think write some script that compare repodata/primary.xml between > distributions shouldn't be problem. I can try write it and send some > results. There is one already that's used by Extras already. See https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00635.html for the output, the code is in cvs somewhere at http://cvs.fedora.redhat.com/viewcvs/?root=fedora (iirc). It checks both Core and Extras during each FE push. Maybe we should post the output to fedora-maintainers instead. But it would be even better if the maintainers in additional get a mail directly if one of their packages has a broken upgrade path. CU thl From kzak at redhat.com Thu Jul 20 10:34:36 2006 From: kzak at redhat.com (Karel Zak) Date: Thu, 20 Jul 2006 12:34:36 +0200 Subject: Broken upgrade paths In-Reply-To: <44BF5178.3080802@leemhuis.info> References: <200607191931.38818.jkeating@redhat.com> <20060720093441.GR3683@petra.dvoda.cz> <44BF5178.3080802@leemhuis.info> Message-ID: <20060720103436.GS3683@petra.dvoda.cz> On Thu, Jul 20, 2006 at 11:48:40AM +0200, Thorsten Leemhuis wrote: > > > Karel Zak schrieb: > > I think write some script that compare repodata/primary.xml between > > distributions shouldn't be problem. I can try write it and send some > > results. > > There is one already that's used by Extras already. See > https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00635.html > for the output, the code is in cvs somewhere at > http://cvs.fedora.redhat.com/viewcvs/?root=fedora > (iirc). It checks both Core and Extras during each FE push. Thanks. This script seems very useful. Here is output for Core: eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) Maintainers added to CC: Karel -- Karel Zak From jkeating at redhat.com Thu Jul 20 12:21:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Jul 2006 08:21:28 -0400 Subject: Broken upgrade paths In-Reply-To: <200607191931.38818.jkeating@redhat.com> References: <200607191931.38818.jkeating@redhat.com> Message-ID: <200607200821.28508.jkeating@redhat.com> On Wednesday 19 July 2006 19:31, Jesse Keating wrote: > (I'll do a more through query through brew tomorrow) *cough* I'll go drink some coffee now and um, stop posting noise. Sorry about this guys, I misread a an email and forwarded it along. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Jul 20 12:34:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Jul 2006 14:34:49 +0200 Subject: Broken upgrade paths In-Reply-To: <20060720103436.GS3683@petra.dvoda.cz> References: <200607191931.38818.jkeating@redhat.com> <20060720093441.GR3683@petra.dvoda.cz> <44BF5178.3080802@leemhuis.info> <20060720103436.GS3683@petra.dvoda.cz> Message-ID: <44BF7869.9080203@leemhuis.info> Karel Zak schrieb: > On Thu, Jul 20, 2006 at 11:48:40AM +0200, Thorsten Leemhuis wrote: >> >> Karel Zak schrieb: >>> I think write some script that compare repodata/primary.xml between >>> distributions shouldn't be problem. I can try write it and send some >>> results. >> There is one already that's used by Extras already. See >> https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00635.html >> for the output, the code is in cvs somewhere at >> http://cvs.fedora.redhat.com/viewcvs/?root=fedora >> (iirc). It checks both Core and Extras during each FE push. > > Thanks. This script seems very useful. Here is output for Core: > > eclipse-changelog: > 5: 1:2.1.0_fc-2 (FC5-updates) > 6: 1:2.1.0_fc-1 (FC6) > > system-config-bind: > 5: 0:4.0.0-42_FC5 (FC5-updates) > 6: 0:4.0.0-41_FC6 (FC6) Well, some minutes ago the script ran again -- see https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00660.html for the results. According to that list there are currently even more broken upgrade paths that need to be fixed in Core afaics: device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-13.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) CU thl From dennis at ausil.us Thu Jul 20 17:27:22 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 20 Jul 2006 12:27:22 -0500 Subject: Minimal Build roots Message-ID: <200607201227.22927.dennis@ausil.us> Hey All, With FC6 fast approaching we will soon request that everyone rebuilds there packages. Before we do so we are going to make sure that the builders are using the new FESCO approved minimal buildroot. What does this mean to you? Well your builds might break. Why? because we are not including all the packages that we used to in the buildroot. What do i do? a very good place to find out is look at Matt Domsch's build reports because he has been using the new buildroot or make sure you have the latest mock and test for yourself. Please make sure that all of your packages build fine in the new buildroot before we make the call for the mass rebuild -- Regards Dennis From ifoox at redhat.com Thu Jul 20 18:09:33 2006 From: ifoox at redhat.com (Igor Foox) Date: Thu, 20 Jul 2006 14:09:33 -0400 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <1153418973.2723.8.camel@tool.toronto.redhat.com> On Mon, 2006-07-17 at 09:00 -0400, Jesse Keating wrote: > eclipse > eclipse-bugzilla > eclipse-cdt > eclipse-changelog > eclipse-pydev These have been rebuilt. Thanks, Igor From fnasser at redhat.com Thu Jul 20 19:09:38 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 20 Jul 2006 15:09:38 -0400 Subject: Development/Libraries/Java Group? In-Reply-To: References: <1153154379.2666.24.camel@localhost.localdomain> Message-ID: <44BFD4F2.10002@redhat.com> Hi Jason, Java s not a language. I wish sometimes the language part of it had been called J# or something like that. Java is an architecture that includes distributed components and several things like that. More to the level of CORBA and, excuse me for the word, .NET. So, it is not a language like Perl or Python but a complete subsystem. Regards, Fernando Jason L Tibbitts III wrote: >>>>>> "AG" == Anthony Green writes: > > AG> Is it really ok to use Development/Libraries/Java? > > We (ultimately the packaging committee and then the various other > committees but currently everyone) need to figure out what to do here. > There are many more groups used by Core than have been permitted in > Extras; I personally think the Extras list is way too small but I'm > not sure if Java should get its own package group. Would we have > separate groups for the other languages? (There are several hundred > Perl modules in Extras alone.) > > - J< > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From fnasser at redhat.com Thu Jul 20 19:11:14 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 20 Jul 2006 15:11:14 -0400 Subject: Rebuild Status In-Reply-To: <200607181107.30407.jkeating@redhat.com> References: <200607181107.30407.jkeating@redhat.com> Message-ID: <44BFD552.10001@redhat.com> Jesse Keating wrote: > classpathx-jaf > cryptix > javacc > java_cup > mx4j > wsdl4j > xalan-j2 We've built these ones. From jkeating at redhat.com Thu Jul 20 21:10:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Jul 2006 17:10:38 -0400 Subject: Updated proposal for dealing with JPackage based packages Message-ID: <200607201710.38524.jkeating@redhat.com> After more discussion, I've added another proposal to our draft regarding JPackage based packages and their current conflict with the Fedora Packaging Guidelines. I'm continuing the discussion here as more of the interested parties are here rather than fedora-packaging. http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming is the current Draft. The proposal which I have added is the first one listed: "Removal of jpp From Release" Please review this Draft and proposal for discussion. I would like to come to an agreement ASAP as there are pending packages for review. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Thu Jul 20 23:24:49 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 20 Jul 2006 18:24:49 -0500 Subject: Development/Libraries/Java Group? In-Reply-To: <44BFD4F2.10002@redhat.com> (Fernando Nasser's message of "Thu, 20 Jul 2006 15:09:38 -0400") References: <1153154379.2666.24.camel@localhost.localdomain> <44BFD4F2.10002@redhat.com> Message-ID: >>>>> "FN" == Fernando Nasser writes: FN> Java is an architecture that includes distributed components and FN> several things like that. More to the level of CORBA and, excuse FN> me for the word, .NET. OK, well they don't have separate package groups either. FN> So, it is not a language like Perl or Python but a complete FN> subsystem. I'm sorry, I think I've taken a wrong turn at Albuquerque and wandered onto the Sun marketing list. Back to reality, it seems to me to be imminently reasonable that Java should have its own package group because there are a quantity of packages associated with it, but to argue that Java alone deserves such treatment while other languages in the same situation don't because they're not "subsystems" seems, well, odd. - J< From laroche at redhat.com Fri Jul 21 08:22:49 2006 From: laroche at redhat.com (Florian La Roche) Date: Fri, 21 Jul 2006 10:22:49 +0200 Subject: rpmlint and Obsoletes: loops Message-ID: <20060721082249.GB6531@dudweiler.stuttgart.redhat.com> One item has just come up the last days within FC-development: openssh has added to the "Obsoletes:" lines also the corresponding "Provides:" lines. End result is that this created an "Obsoletes loop" where an older openssh-askpass-gnome package obsoletes a current openssh-askpass and the current openssh-askpass package also obsoletes openssh-askpass-gnome. (In more detail this happened via the obsoletes/provides "ssh-extras".) This of course does not show up for FC-development where only the newest packages are in the tree, but it does show up if you take older repos together with FC-devel packages (which is normally not a good mixture, but that is another story). While it is most times a good idea to add the "Provides:" lines for all obsoletes as well, we should not just add them to all of them. Especially not if nobody found them missing for many years by now. Something we should keep in mind if we now look more and more at rpmlint and how it reviews rpm packages. regards, Florian La Roche From gbenson at redhat.com Fri Jul 21 09:27:44 2006 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Jul 2006 10:27:44 +0100 Subject: Development/Libraries/Java Group? In-Reply-To: <1153154379.2666.24.camel@localhost.localdomain> References: <1153154379.2666.24.camel@localhost.localdomain> Message-ID: <20060721092743.GB6363@redhat.com> Anthony Green wrote: > This web page... > http://fedoraproject.org/wiki/RPMGroups > > ...indicates that a Group value of Development/Libraries/Java is > OK for Fedora. This is what the JPackage project is using. For > the few packages I've migrated from JPackage to Extras, I've > changed Group to simply Development/Libraries although I would > have preferred Development/Libraries/Java. Is it really ok to > use Development/Libraries/Java? Language isn't really relevant for the group field: it's there to tell you what something _is_, not what it's written in. Take tomcat, for example: its group is "Networking/Daemons", putting it in the same group as httpd and zope. Having seperate "Networking/Daemons/Java", "Networking/Daemons/C" and "Networking/Daemons/Python" groups for tomcat, httpd and zope wouldn't really add anything to the user's experience. Cheers, Gary From mlichvar at redhat.com Mon Jul 17 13:34:17 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 17 Jul 2006 15:34:17 +0200 Subject: Mass Rebuild Status In-Reply-To: <200607170900.37265.jkeating@redhat.com> References: <200607170900.37265.jkeating@redhat.com> Message-ID: <20060717133417.GA14720@bordell.redhat.usu> > ntp I will take care of this. -- Miroslav Lichvar From karsten at redhat.com Wed Jul 19 10:23:11 2006 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 19 Jul 2006 12:23:11 +0200 Subject: Mass Rebuild Status In-Reply-To: <20060719095745.GA19619@camelia.ucw.cz> References: <200607170900.37265.jkeating@redhat.com> <20060719095745.GA19619@camelia.ucw.cz> Message-ID: <44BE080F.6070602@redhat.com> Stepan Kasal schrieb: > Hello Jesse, > > On Mon, Jul 17, 2006 at 09:00:37AM -0400, Jesse Keating wrote: >> autoconf > > please do not rebuild Autoconf. The dist CVS contains 2.60 (I was > not able to make a build in dist-fc6-test without a tag), but several > packages are not yet ready for it. > > Autoconf is a noarch package, so this should not be a problem here. > > Have a nice day, > Stepan I've rebuilt autoconf-2.59 anyway. Karsten From ville.skytta at iki.fi Sat Jul 22 19:03:37 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 22 Jul 2006 22:03:37 +0300 Subject: rpmlint and Obsoletes: loops In-Reply-To: <20060721082249.GB6531@dudweiler.stuttgart.redhat.com> References: <20060721082249.GB6531@dudweiler.stuttgart.redhat.com> Message-ID: <1153595017.2683.220.camel@localhost.localdomain> On Fri, 2006-07-21 at 10:22 +0200, Florian La Roche wrote: > While it is most times a good idea to add the "Provides:" > lines for all obsoletes as well, we should not just add them > to all of them. Especially not if nobody found them missing > for many years by now. Note that when using properly versioned Obsoletes/Provides [0], loops involving those are almost nonexistent. Unversioned Obsoletes/Provides is pretty rarely the right thing to do, as they match *all* versions. And of course, if the thing obsoleted is not actually provided in a compatible way by the new package but is just made obsolete by it, the provides shouldn't be added at all. [0] eg. Provides: foo = %{version}-%{release} Obsoletes: foo < $first_V-R_where_above_provides_appeared From green at redhat.com Mon Jul 24 20:37:44 2006 From: green at redhat.com (Anthony Green) Date: Mon, 24 Jul 2006 13:37:44 -0700 Subject: Development/Libraries/Java Group? In-Reply-To: <20060721092743.GB6363@redhat.com> References: <1153154379.2666.24.camel@localhost.localdomain> <20060721092743.GB6363@redhat.com> Message-ID: <1153773465.7268.139.camel@localhost.localdomain> On Fri, 2006-07-21 at 10:27 +0100, Gary Benson wrote: > Language isn't really relevant for the group field: it's there to tell > you what something _is_, not what it's written in. Take tomcat, for > example: its group is "Networking/Daemons", putting it in the same > group as httpd and zope. Having seperate "Networking/Daemons/Java", > "Networking/Daemons/C" and "Networking/Daemons/Python" groups for > tomcat, httpd and zope wouldn't really add anything to the user's > experience. This is very different from development libraries where the developer actually does care what language the library is written in. AG From green at redhat.com Mon Jul 24 20:44:25 2006 From: green at redhat.com (Anthony Green) Date: Mon, 24 Jul 2006 13:44:25 -0700 Subject: Development/Libraries/Java Group? In-Reply-To: References: <1153154379.2666.24.camel@localhost.localdomain> <44BFD4F2.10002@redhat.com> Message-ID: <1153773865.7268.145.camel@localhost.localdomain> On Thu, 2006-07-20 at 18:24 -0500, Jason L Tibbitts III wrote: > Back to reality, it seems to me to be imminently reasonable that Java > should have its own package group because there are a quantity of > packages associated with it, but to argue that Java alone deserves > such treatment while other languages in the same situation don't > because they're not "subsystems" seems, well, odd. I agree. I think we should allow for Development/Libraries/[LANGUAGE] because... - Groups are used to make browsing packages simpler - People browsing Development/Libraries are programmers - Programmers are typically looking for language specific libraries So, my proposal it to let packagers extend Development/Libraries with a /[LANGUAGE] (Perl, Python, Java, C++, Lisp, etc, but not C, which can default to Development/Libraries). AG From tibbs at math.uh.edu Tue Jul 25 00:08:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 24 Jul 2006 19:08:58 -0500 Subject: [Bug 200024] Review Request: openib In-Reply-To: <200607242133.k6OLXDN7027132@bugzilla.redhat.com> (bugzilla@redhat.com's message of "Mon, 24 Jul 2006 17:33:13 -0400") References: <200607242133.k6OLXDN7027132@bugzilla.redhat.com> Message-ID: >>>>> "b" == bugzilla writes: b> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200024 OK, I can read the messages on the mailing list, but I'm not authorized to access the bug at that URL. Odd. b> The openib package conflicts with other packages in fedora extras, b> so we aren't intending to release it in core in order to avoid b> those conflicts. Packages in Extras can conflict with each other (although of course they shouldn't do so needlessly); I don't see why a few conflicts should keep something useful out. - J< From jkeating at redhat.com Tue Jul 25 00:15:52 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Jul 2006 20:15:52 -0400 Subject: [Bug 200024] Review Request: openib In-Reply-To: References: <200607242133.k6OLXDN7027132@bugzilla.redhat.com> Message-ID: <200607242015.52478.jkeating@redhat.com> On Monday 24 July 2006 20:08, Jason L Tibbitts III wrote: > OK, I can read the messages on the mailing list, but I'm not > authorized to access the bug at that URL. ?Odd. > > b> The openib package conflicts with other packages in fedora extras, > b> so we aren't intending to release it in core in order to avoid > b> those conflicts. > > Packages in Extras can conflict with each other (although of course > they shouldn't do so needlessly); I don't see why a few conflicts > should keep something useful out. This was meant to be a RHEL package review, the maintainer just used the wrong template and made a core package review. I reassigned the bug and removed the list from cc. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mharris at mharris.ca Tue Jul 25 08:27:37 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 25 Jul 2006 04:27:37 -0400 Subject: Core Packages in Violation of the Fedora Naming Guidelines In-Reply-To: <1152662171.12430.317.camel@localhost.localdomain> References: <1152642496.12430.232.camel@localhost.localdomain> <17588.10023.637464.36766@localhost.redhat.com> <1152662171.12430.317.camel@localhost.localdomain> Message-ID: <44C5D5F9.2020406@mharris.ca> Tom 'spot' Callaway wrote: >> > xorg-x11-xkbdata-1.0.1-8.xkbc0.8.0.src.rpm > > Fixed: xorg-x11-xkbdata-1.0.1-9.src.rpm > Fixed (with dist tag): xorg-x11-xkbdata-1.0.1-9.fc6.src.rpm The xorg-x11-xkbdata package originally contained X.Org's xkbdata package, version 1.0.1. However, prior to the release of FC5, after much debate and consideration, the decision was made to switch to the "xkeyboard-config" project's xkbdata, as the X.Org data was obsolete and unmaintained. Unfortunately this came late in the FC5 devel cycle, and we were unable to get a new package name included in the OS as "xkeyboard-config". Since the contents of "xorg-x11-xkbdata-1.0.1" was now actually "xkeyboard-config-0.8" and we were unable to call it that, I encoded the real package name into the Release field concisely, as it was important to know what release of xkeyboard-config was actually shipping by looking at NVR. This was only intended as an ugly hack workaround to the problem of being unable to rename the package at that time. Now, in FC6 development that restriction is no longer in place, and so the package is now called "xkeyboard-config-0.8" which obsoletes the former xorg based package. The Intel i810 driver in rawhide contains "modeset" which ajax added to indicate that this is not the standard X.Org i810 driver, but is instead the developmental 'modeset' branch that Eric Anholt is working on. It is important to us to be able to distinguish wether people are using the traditional i810 driver, or the modeset one in bug reports. Having said that, none of these workarounds are intended to be present in the final builds for FC6. By the time FC6 ships, it is intended that the 'modeset' driver will become the official i810 driver, merged into CVS head upstream, however that has not yet happened. Perhaps the release naming rules could be extended a bit, such as permitting a string to be prefixed or suffixed to indicate the branch of CVS, or some other arbitrary identifier. "1.fc6.20060503git.modeset"? An alternative would be a separate package name instead, and shipping both drivers: xorg-x11-drv-i810 and xorg-x11-drv-i810modeset, however we want people exclusively testing the modeset driver now. Some are using rawhide drivers in FC5, and mixing and matching modular X packages. When they provide their RPM package NVRs, it is obvious right now that they're using the modeset driver. We're (our team) open minded though, feedback appreciated. >> > Bad CVS naming (cvs should be at end of date, not beginning) >> > ============================================================ > > CVS falls under the snapshot rules. To handle snapshots, first identify, > is this a pre-release, or a post-release? > >>> krb5-auth-dialog-0.6.cvs20060212-3.src.rpm > > I'll assume this is a pre-release, and that 0.6 has yet to be released. > In this case, this package should be fixed as: > > Fixed: krb5-auth-dialog-0.6-0.7.20060212cvs.src.rpm > Fixed (with dist tag): krb5-auth-dialog-0.6-0.7.20060212cvs.fc6.src.rpm > > If you need to patch a pre-release or put in a new cvs checkout, you > bump the non-zero integer in the Release field, but LEAVE THE ZERO AS > ZERO. This is important. > > Unfortunately, this is a case where conforming to the guidelines will > require a one-time epoch bump in the new package, since rpm thinks that > 0.6.cvs20060212-3 is newer than 0.6. I've told some people not to do that in their packages, and ended up in a heated debate over it that I found to be not worthwhile so dropped the discussion thinking "they'll find out the hard way later". Perhaps we could have the buildsystem encode all of these "rules" into software which denies your ability to build the package unless the rules are followed. That would be a bit of a PITA for some corner cases, but save headaches in the long run from history repeating itself, and also save having to re-discuss/re-debate it every time someone else hits a problem and isn't aware of all the rules and the reason they exist. I'm all for computer software forcing humans to not have the opportunity to introduce human err into problems that have had solutions developed and documented. Documentation alone doesn't prevent humans from making errors, but computer software that sits in between and doesn't permit the errors does. ;o) Just a thought anyway... -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Tue Jul 25 10:12:01 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 25 Jul 2006 06:12:01 -0400 Subject: libutempter package will be replacing utempter soon Message-ID: <44C5EE71.4040405@mharris.ca> libutempter, an alternative to Red Hat's 'utempter' which is a fork based upon the original, will now be replacing the original. Most other distros have shipped the forked version for years as it is cleaner well maintained code which has been very heavily audited, so it makes sense for us to make the switch also. The new package will be called 'libutempter' and contain a proper -devel subpackage, so any Fedora Extras or other 3rd party repositories which link to libutempter should update their BuildRequires to use 'libutempter-devel' instead now. A backward compatible Provide will be included in the package as well, but it may be disabled temporarily to encourage people to update their packages, then re-enabled prior to FC6. Any packages which contain runtime dependencies on the 'utempter' helper utility, should contain "Requires: utempter". This will ensure that it works both with the old utempter package, and also with the new one, as we will be including a virtual provide for that. I don't suspect there are many packages out there that this will affect, but I'd appreciate a quick email from anyone who finds any, just to keep tabs on what all uses it out there in the wild. In Core, only xterm and libgnome seem to use utempter currently, and I've notified the maintainers to give them a heads-up. Thanks in advance. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From jkeating at redhat.com Tue Jul 25 15:57:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 25 Jul 2006 11:57:35 -0400 Subject: FC6 Test2 freezing at noon today (July 25) Message-ID: <200607251157.36034.jkeating@redhat.com> We will be locking dist-fc6 in about 5 minutes. -HEAD is open for building. Your active build may fail at the tag step, if so, you can do: brew tag-pkg dist-fc6-HEAD package-version-release Please let rel-eng know if you have a critical change that needs to get in after the freeze. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Wed Jul 26 11:14:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Jul 2006 13:14:53 +0200 Subject: lzo 2.02 soname change update coming up (devel only) Message-ID: <44C74EAD.6080802@hhs.nl> Hi all, Since Anvil has very little time for FE lately I've taken over some (most) of his packages. Amongst these is lzo. There has been a new major release of lzo upstream for quite a while now. Together with Ville I've been working on updating lzo to this newer release. This new release comes with a new soname thus packages using lzo will need to be rebuild. Here is a list of all packages that use lzo and if they work with the new lzo. Thanks to Ville for the list: Affected apps in FE: - dxpc: not prepared for 2.x. Upstream 3.9.0 seems to be. REMARK: This is orphaned, if noone picks it up I guess we should remove it soon. REMARK: dxpc's license is claimed to be BSD, but because the GPL'd lzo is linked in it, the shipped combo is GPL -> should be reflected in the License tag. - lzop: apparently ok with 2.x - openvpn: apparently ok with 2.x Affected apps in FE review: - mkvtoolnix: apparently ok with 2.x There are some apps in that other repo too, these will be taken care off too. lzo-2.02-1 has been commited to CVS and is ready to be build. Please check it out from CVS, build and install it locally and prepare your packages to be build against it. I will tag and build lzo-2.02-1 (for devel only) coming Sunday at circa 9u00 CET. Once build successfully. I'll send another mail to all people who received this mail that it has been build and that they can rebuild their packages against it. With some luck this will result in us not having any broken deps in the repo. People with Push and Sign rights who read this, please do not do a push coming sunday around 9u00 CET :) Regards, Hans From j.w.r.degoede at hhs.nl Wed Jul 26 11:17:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Jul 2006 13:17:32 +0200 Subject: lzo 2.02 soname change update coming up (p.s.) Message-ID: <44C74F4C.5070306@hhs.nl> Hi all, And ofcourse I forgot a vital piece of info as I always seem todo with mails like these. For lzo -> lzo2 porting notes see: http://www.oberhumer.com/opensource/lzo/lzonews.php Under the "Changes in 2.00" heading. Regards, Hans From rdieter at math.unl.edu Wed Jul 26 11:34:42 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 06:34:42 -0500 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C74EAD.6080802@hhs.nl> References: <44C74EAD.6080802@hhs.nl> Message-ID: <44C75352.5090205@math.unl.edu> Hans de Goede wrote: > Here is a list of all packages that use lzo and if they work with the > new lzo. Thanks to Ville for the list: > Affected apps in FE: > - dxpc: not prepared for 2.x. Upstream 3.9.0 seems to be. > REMARK: This is orphaned, if noone picks it up I guess we should > remove it soon. > REMARK: > dxpc's license is claimed to be BSD, but because the GPL'd lzo is > linked in it, the shipped combo is GPL -> should be reflected in the > License tag. I've updated dxpc's cvs/devel branch to fix the license and updated to 3.9.0, so should be ready to go when/if someone takes over maintainership. -- Rex From j.w.r.degoede at hhs.nl Wed Jul 26 11:59:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Jul 2006 13:59:53 +0200 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C75352.5090205@math.unl.edu> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> Message-ID: <44C75939.3000100@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: > >> Here is a list of all packages that use lzo and if they work with the >> new lzo. Thanks to Ville for the list: >> Affected apps in FE: >> - dxpc: not prepared for 2.x. Upstream 3.9.0 seems to be. >> REMARK: This is orphaned, if noone picks it up I guess we should >> remove it soon. >> REMARK: >> dxpc's license is claimed to be BSD, but because the GPL'd lzo is >> linked in it, the shipped combo is GPL -> should be reflected in the >> License tag. > > I've updated dxpc's cvs/devel branch to fix the license and updated to > 3.9.0, so should be ready to go when/if someone takes over maintainership. > Maybe someone (you or me) should tag and build this coming sunday if there is not a new maintainer then, so that atleast we don't break upgrades for people who have dxpc installed? Regards, Hans From rdieter at math.unl.edu Wed Jul 26 12:06:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 07:06:05 -0500 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C75939.3000100@hhs.nl> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> <44C75939.3000100@hhs.nl> Message-ID: <44C75AAD.2040902@math.unl.edu> Hans de Goede wrote: > > Rex Dieter wrote: >> Hans de Goede wrote: >> >>> Here is a list of all packages that use lzo and if they work with the >>> new lzo. Thanks to Ville for the list: >>> Affected apps in FE: >>> - dxpc: not prepared for 2.x. Upstream 3.9.0 seems to be. >>> REMARK: This is orphaned, if noone picks it up I guess we should >>> remove it soon. >>> REMARK: >>> dxpc's license is claimed to be BSD, but because the GPL'd lzo is >>> linked in it, the shipped combo is GPL -> should be reflected in the >>> License tag. >> I've updated dxpc's cvs/devel branch to fix the license and updated to >> 3.9.0, so should be ready to go when/if someone takes over maintainership. >> > > Maybe someone (you or me) should tag and build this coming sunday if > there is not a new maintainer then, so that atleast we don't break > upgrades for people who have dxpc installed? OK, twist my arm... (: (I'll do it) -- Rex From rdieter at math.unl.edu Wed Jul 26 12:08:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 07:08:11 -0500 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C75AAD.2040902@math.unl.edu> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> <44C75939.3000100@hhs.nl> <44C75AAD.2040902@math.unl.edu> Message-ID: <44C75B2B.8060505@math.unl.edu> Rex Dieter wrote: > Hans de Goede wrote: >> >> Rex Dieter wrote: >>> Hans de Goede wrote: >>> >>>> Here is a list of all packages that use lzo and if they work with the >>>> new lzo. Thanks to Ville for the list: >>>> Affected apps in FE: >>>> - dxpc: not prepared for 2.x. Upstream 3.9.0 seems to be. >>>> REMARK: This is orphaned, if noone picks it up I guess we should >>>> remove it soon. >>>> REMARK: >>>> dxpc's license is claimed to be BSD, but because the GPL'd lzo is >>>> linked in it, the shipped combo is GPL -> should be reflected in the >>>> License tag. >>> I've updated dxpc's cvs/devel branch to fix the license and updated to >>> 3.9.0, so should be ready to go when/if someone takes over >>> maintainership. >>> >> >> Maybe someone (you or me) should tag and build this coming sunday if >> there is not a new maintainer then, so that atleast we don't break >> upgrades for people who have dxpc installed? > > OK, twist my arm... (: (I'll do it) Well, looks like lzo2 isn't built yet, so either you go ahead and do the tag/build, or let me know when lzo2 is build/ready and I'll do it. -- Rex From j.w.r.degoede at hhs.nl Wed Jul 26 12:27:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Jul 2006 14:27:23 +0200 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C75B2B.8060505@math.unl.edu> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> <44C75939.3000100@hhs.nl> <44C75AAD.2040902@math.unl.edu> <44C75B2B.8060505@math.unl.edu> Message-ID: <44C75FAB.6080901@hhs.nl> Rex Dieter wrote: > Rex Dieter wrote: >> Hans de Goede wrote: >>> >>> Rex Dieter wrote: >>>> Hans de Goede wrote: >>>> >>>>> Here is a list of all packages that use lzo and if they work with the >>>>> new lzo. Thanks to Ville for the list: >>>>> Affected apps in FE: >>>>> - dxpc: not prepared for 2.x. Upstream 3.9.0 seems to be. >>>>> REMARK: This is orphaned, if noone picks it up I guess we should >>>>> remove it soon. >>>>> REMARK: >>>>> dxpc's license is claimed to be BSD, but because the GPL'd lzo is >>>>> linked in it, the shipped combo is GPL -> should be reflected in the >>>>> License tag. >>>> I've updated dxpc's cvs/devel branch to fix the license and updated to >>>> 3.9.0, so should be ready to go when/if someone takes over >>>> maintainership. >>>> >>> >>> Maybe someone (you or me) should tag and build this coming sunday if >>> there is not a new maintainer then, so that atleast we don't break >>> upgrades for people who have dxpc installed? >> >> OK, twist my arm... (: (I'll do it) > > Well, looks like lzo2 isn't built yet, so either you go ahead and do the > tag/build, or let me know when lzo2 is build/ready and I'll do it. > Thats correct, it said as much in my first mail its in CVS, so that people can do a local build and test their packages against this local build to rub out any wrinkles before the "massive" rebuild sunday. I'll build the new dxpc coming sunday once the new lzo has been build. Has the new dxpc already been tagged? Regards, Hans From rdieter at math.unl.edu Wed Jul 26 12:29:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 07:29:50 -0500 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C75FAB.6080901@hhs.nl> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> <44C75939.3000100@hhs.nl> <44C75AAD.2040902@math.unl.edu> <44C75B2B.8060505@math.unl.edu> <44C75FAB.6080901@hhs.nl> Message-ID: <44C7603E.8040105@math.unl.edu> Hans de Goede wrote: > I'll build the new dxpc coming sunday once the new lzo has been build. > Has the new dxpc already been tagged? Not tagged (yet). -- Rex From j.w.r.degoede at hhs.nl Wed Jul 26 14:12:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Jul 2006 16:12:38 +0200 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C7603E.8040105@math.unl.edu> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> <44C75939.3000100@hhs.nl> <44C75AAD.2040902@math.unl.edu> <44C75B2B.8060505@math.unl.edu> <44C75FAB.6080901@hhs.nl> <44C7603E.8040105@math.unl.edu> Message-ID: <44C77856.5060206@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: > >> I'll build the new dxpc coming sunday once the new lzo has been build. >> Has the new dxpc already been tagged? > > Not tagged (yet). > Okay, I'll tag and build it coming sunday then. Regards, Hans From green at redhat.com Wed Jul 26 15:01:08 2006 From: green at redhat.com (Anthony Green) Date: Wed, 26 Jul 2006 08:01:08 -0700 Subject: System Environment/Libraries vs Development/Libraries Message-ID: <1153926068.2948.21.camel@localhost.localdomain> Fedora rpm group categories include both "System Environment/Libraries" and "Development/Libraries". I've been putting new FE libraries (like liblo (C) and itext (java)) under "Development/Libraries", and only noticed "System Environment/Libraries" when reviewing a new package for somebody. Is there something that helps us decide which group a library should go under? I don't see how this distinction can be useful. AG From notting at redhat.com Wed Jul 26 15:02:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 26 Jul 2006 11:02:52 -0400 Subject: System Environment/Libraries vs Development/Libraries In-Reply-To: <1153926068.2948.21.camel@localhost.localdomain> References: <1153926068.2948.21.camel@localhost.localdomain> Message-ID: <20060726150252.GD26071@devserv.devel.redhat.com> Anthony Green (green at redhat.com) said: > Fedora rpm group categories include both "System Environment/Libraries" > and "Development/Libraries". > > I've been putting new FE libraries (like liblo (C) and itext (java)) > under "Development/Libraries", and only noticed "System > Environment/Libraries" when reviewing a new package for somebody. Is > there something that helps us decide which group a library should go > under? I don't see how this distinction can be useful. SE/Libraries -> runtime Devel/Libraries -> devel Bill From green at redhat.com Wed Jul 26 16:49:27 2006 From: green at redhat.com (Anthony Green) Date: Wed, 26 Jul 2006 09:49:27 -0700 Subject: System Environment/Libraries vs Development/Libraries In-Reply-To: <20060726150252.GD26071@devserv.devel.redhat.com> References: <1153926068.2948.21.camel@localhost.localdomain> <20060726150252.GD26071@devserv.devel.redhat.com> Message-ID: <1153932567.2948.52.camel@localhost.localdomain> On Wed, 2006-07-26 at 11:02 -0400, Bill Nottingham wrote: > SE/Libraries -> runtime > Devel/Libraries -> devel Ok. In the java world (perhaps also perl, python?, etc), there's almost never any distinction between runtime and devel libraries, but they're all marked as Devel/Libraries. Does anybody think these should change to SE/Libraries? Or maybe it just doesn't matter that much. AG From toshio at tiki-lounge.com Wed Jul 26 17:01:37 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 26 Jul 2006 10:01:37 -0700 Subject: System Environment/Libraries vs Development/Libraries In-Reply-To: <1153932567.2948.52.camel@localhost.localdomain> References: <1153926068.2948.21.camel@localhost.localdomain> <20060726150252.GD26071@devserv.devel.redhat.com> <1153932567.2948.52.camel@localhost.localdomain> Message-ID: <1153933297.3004.9.camel@localhost> On Wed, 2006-07-26 at 09:49 -0700, Anthony Green wrote: > On Wed, 2006-07-26 at 11:02 -0400, Bill Nottingham wrote: > > SE/Libraries -> runtime > > Devel/Libraries -> devel > > Ok. In the java world (perhaps also perl, python?, etc), there's almost > never any distinction between runtime and devel libraries, but they're > all marked as Devel/Libraries. Does anybody think these should change > to SE/Libraries? Or maybe it just doesn't matter that much. > Yes, they belong in SE/Libraries. No it doesn't matter much (because the Group tag is in pretty poor shape.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jul 26 17:11:48 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Jul 2006 13:11:48 -0400 Subject: System Environment/Libraries vs Development/Libraries In-Reply-To: <1153933297.3004.9.camel@localhost> References: <1153926068.2948.21.camel@localhost.localdomain> <1153932567.2948.52.camel@localhost.localdomain> <1153933297.3004.9.camel@localhost> Message-ID: <200607261311.49032.jkeating@redhat.com> On Wednesday 26 July 2006 13:01, Toshio Kuratomi wrote: > Yes, they belong in SE/Libraries. ?No it doesn't matter much (because > the Group tag is in pretty poor shape.) There aren't many places this is used. Comps is used for grouping for installer and pirut. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Wed Jul 26 17:15:29 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 26 Jul 2006 18:15:29 +0100 Subject: System Environment/Libraries vs Development/Libraries In-Reply-To: <1153933297.3004.9.camel@localhost> References: <1153926068.2948.21.camel@localhost.localdomain> <1153932567.2948.52.camel@localhost.localdomain> <1153933297.3004.9.camel@localhost> Message-ID: <200607261815.29797.jamatos@fc.up.pt> On Wednesday 26 July 2006 18:01, Toshio Kuratomi wrote: > Yes, they belong in SE/Libraries. ?No it doesn't matter much (because > the Group tag is in pretty poor shape.) Is (was) there any resolution from the packaging committee on the Group tag? In the present state they are useless and unused. This relates also with the weekly report presented by Christian on FE Package Status. I have not used comps.xml before for my packages since I never found documentation of how to it. I am not saying that there is not, I am just saying that I did not found it. > -Toshio -- Jos? Ab?lio From mattdm at mattdm.org Wed Jul 26 18:01:27 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 26 Jul 2006 14:01:27 -0400 Subject: System Environment/Libraries vs Development/Libraries In-Reply-To: <1153933297.3004.9.camel@localhost> References: <1153926068.2948.21.camel@localhost.localdomain> <20060726150252.GD26071@devserv.devel.redhat.com> <1153932567.2948.52.camel@localhost.localdomain> <1153933297.3004.9.camel@localhost> Message-ID: <20060726180127.GA3919@jadzia.bu.edu> On Wed, Jul 26, 2006 at 10:01:37AM -0700, Toshio Kuratomi wrote: > Yes, they belong in SE/Libraries. No it doesn't matter much (because > the Group tag is in pretty poor shape.) (And should be killed.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Jul 26 19:36:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Jul 2006 15:36:21 -0400 Subject: Mass build status 7/26 Message-ID: <200607261536.21347.jkeating@redhat.com> cpufreq-utils dasher epic firefox libexif librtas mozilla PyXML thunderbird are the only ones left. firefox/mozilla/thunderbird need C++ visibility help. librtas needs upstream help, Paul Nasrat is on the case. This leaves: cpufreq-utils (Davej?) dasher (J5?) epic (pvrabec?) libexif (mclasen?) PyXML (laroche?) Once we get these built, FC6 will be completely self hosted, no packages pulled in from FC5 or before. This is a pretty significant goal for us, please help to make it happen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Jul 26 19:48:16 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 26 Jul 2006 15:48:16 -0400 Subject: Mass build status 7/26 In-Reply-To: <200607261536.21347.jkeating@redhat.com> References: <200607261536.21347.jkeating@redhat.com> Message-ID: <20060726194816.GB15116@redhat.com> On Wed, Jul 26, 2006 at 03:36:21PM -0400, Jesse Keating wrote: > This leaves: > cpufreq-utils (Davej?) My previous attempts at building exposed buildsys breakage. I filed a request, but heard nothing back. (I mentioned this the last time you sent out a status on this too). I just resubmitted the job, and it passed, so it got silently fixed. Dave -- http://www.codemonkey.org.uk From j.w.r.degoede at hhs.nl Wed Jul 26 20:47:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 26 Jul 2006 22:47:11 +0200 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <20060726162215.GB16103@osiris.silug.org> References: <44C74EAD.6080802@hhs.nl> <20060726162215.GB16103@osiris.silug.org> Message-ID: <44C7D4CF.7070904@hhs.nl> Steven Pritchard wrote: > On Wed, Jul 26, 2006 at 01:14:53PM +0200, Hans de Goede wrote: >> I will tag and build lzo-2.02-1 (for devel only) coming Sunday at circa >> 9u00 CET. Once build successfully. I'll send another mail to all people >> who received this mail that it has been build and that they can rebuild >> their packages against it. With some luck this will result in us not >> having any broken deps in the repo. > > Would it maybe be a good idea to make a compat-lzo package? There are > also a few livna packages that require lzo, and I would be really > surprised if there weren't a few users linking local stuff against it. > > Steve As I already wrote in my mail coordination with that other repo is taken care off. As for user linking local stuff against it, bad luck. Remember this is only going into devel. User can expect soname changes when upgrading to a new FC release, this happens in core too. I know core provides some compat libs, but only for the most often used libs like ncurses. libstdc++ etc. Regards, Hans From caolanm at redhat.com Thu Jul 27 07:03:01 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 27 Jul 2006 08:03:01 +0100 Subject: Mass build status 7/26 In-Reply-To: <200607261536.21347.jkeating@redhat.com> References: <200607261536.21347.jkeating@redhat.com> Message-ID: <1153983783.2588.52.camel@soulcrusher.caolan.org> On Wed, 2006-07-26 at 15:36 -0400, Jesse Keating wrote: > > > firefox/mozilla/thunderbird need C++ visibility help. g++ >= 4.1.1-12 has tweaked visibility again, and I was able to reenable OOo's visibility support with that g++. Does the firefox suite still fail with this g++ rev ? C. From j.w.r.degoede at hhs.nl Sun Jul 30 18:44:17 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 30 Jul 2006 20:44:17 +0200 Subject: lzo 2.02 soname change update coming up (devel only) In-Reply-To: <44C7603E.8040105@math.unl.edu> References: <44C74EAD.6080802@hhs.nl> <44C75352.5090205@math.unl.edu> <44C75939.3000100@hhs.nl> <44C75AAD.2040902@math.unl.edu> <44C75B2B.8060505@math.unl.edu> <44C75FAB.6080901@hhs.nl> <44C7603E.8040105@math.unl.edu> Message-ID: <44CCFE01.9090808@hhs.nl> Rex Dieter wrote: > Hans de Goede wrote: > >> I'll build the new dxpc coming sunday once the new lzo has been build. >> Has the new dxpc already been tagged? > > Not tagged (yet). > > -- Rex > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I've just completed building lzo-2.02 (sorry a bit later then promised I forgot about it this morning) and I've tagged and requested a build for dxpc as promised. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jul 30 18:44:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 30 Jul 2006 20:44:36 +0200 Subject: lzo 2.02 has been build (soname change) Message-ID: <44CCFE14.6010807@hhs.nl> Hi all, As discussed/announced I've just completed building lzo-2.02 (sorry a bit later then promised I forgot about it this morning). As discussed/announced this version changes the soname so lzo dependant packages must be rebuild asap. Here is a list of all packages that use lzo and if they work with the new lzo. Thanks to Ville for the list: Affected apps in FE: - dxpc: rebuild requested by me as discussed with Rex, should be fine once rebuild - lzop: apparently ok with 2.x after a rebuild, please rebuild asap! - openvpn: apparently ok with 2.x after a rebuild, please rebuild asap! Affected apps in FE review: - mkvtoolnix: apparently ok with 2.x There are some apps in that other repo too, these will be taken care off too. Regards, Hans From dennis at ausil.us Mon Jul 31 04:04:12 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 30 Jul 2006 23:04:12 -0500 Subject: Minimal Build roots In-Reply-To: <200607201227.22927.dennis@ausil.us> References: <200607201227.22927.dennis@ausil.us> Message-ID: <200607302304.13409.dennis@ausil.us> On Thursday 20 July 2006 12:27 pm, Dennis Gilmore wrote: > Hey All, > > With FC6 fast approaching we will soon request that everyone rebuilds there > packages. Before we do so we are going to make sure that the builders are > using the new FESCO approved minimal buildroot. As a follow up, All jobs now must build in the new minimal buildroots. while not all of the machines have been upgraded all the ppc builders have been. and they are using the new build root. so you must also -- Dennis Gilmore, RHCE Proud Australian From pvrabec at redhat.com Mon Jul 31 10:10:11 2006 From: pvrabec at redhat.com (Peter Vrabec) Date: Mon, 31 Jul 2006 12:10:11 +0200 Subject: Mass build status 7/26 In-Reply-To: <200607261536.21347.jkeating@redhat.com> References: <200607261536.21347.jkeating@redhat.com> Message-ID: <20060731121011.35b2c792@wrabco.redhat.usu> epic has been build, I'm sorry for being late On Wed, 26 Jul 2006 15:36:21 -0400 Jesse Keating wrote: > cpufreq-utils > dasher > epic > firefox > libexif > librtas > mozilla > PyXML > thunderbird > > are the only ones left. > > firefox/mozilla/thunderbird need C++ visibility help. > librtas needs upstream help, Paul Nasrat is on the case. > > This leaves: > cpufreq-utils (Davej?) > dasher (J5?) > epic (pvrabec?) > libexif (mclasen?) > PyXML (laroche?) > > Once we get these built, FC6 will be completely self hosted, no > packages pulled in from FC5 or before. This is a pretty significant > goal for us, please help to make it happen. >