From Axel.Thimm at ATrpms.net Mon Aug 6 10:08:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 12:08:15 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 Message-ID: <20070806100815.GB18009@puariko.nirvana> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250819#c1 mediawiki resists my attempts to build it in various ways. The current one is that building (or trying to build) under F7 automatically elevates the package to mediawiki-1.9.3-34.fc8, e.g. an F8 package. What is wrong? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 12:03:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 08:03:29 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806100815.GB18009@puariko.nirvana> References: <20070806100815.GB18009@puariko.nirvana> Message-ID: <20070806080329.369b69f9@ender> On Mon, 6 Aug 2007 12:08:15 +0200 Axel Thimm wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250819#c1 > > mediawiki resists my attempts to build it in various ways. The current > one is that building (or trying to build) under F7 automatically > elevates the package to mediawiki-1.9.3-34.fc8, e.g. an F8 > package. What is wrong? The last attempt shows: cvs checkout: warning: cannot open /cvs/pkgs/CVSROOT/val-tags read/write: Permission denied (not sure if this is a bad thing yet) Downloading mediawiki-1.9.3.tar.gz... error: File /tmp/koji/tasks/89910/cvs/rpms/mediawiki/devel/mediawiki-1.10.0.tar.gz: No such file or directory Looks like maybe the sources file wasn't tagged with the right cvs tag. http://koji.fedoraproject.org/koji/getfile?taskID=89910&name=srpm.log This task is the one you're probably concerned with: http://koji.fedoraproject.org/koji/getfile?taskID=89866&name=srpm.log I'm not entirely certain how that produced a .fc8 srpm at the end of it, looking into it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 12:06:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 08:06:20 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806080329.369b69f9@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806080329.369b69f9@ender> Message-ID: <20070806080620.39d29ffb@ender> On Mon, 6 Aug 2007 08:03:29 -0400 Jesse Keating wrote: > This task is the one you're probably concerned with: > http://koji.fedoraproject.org/koji/getfile?taskID=89866&name=srpm.log > > I'm not entirely certain how that produced a .fc8 srpm at the end of > it, looking into it. Bingo. mediawiki-1_9_3-34_fc7:devel:athimm:1172147229 You previously tagged this source as 1.9.3-34 when on the devel/ branch, presumably before the branching happened for F-7. Since the CVS tag you asked for lives in devel, koji gets a little confused when making the srpm for you. You'll most likely need to bump/tag on F-7 then you can build and it will get the proper .fc7 tag to it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 12:18:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 14:18:36 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806080620.39d29ffb@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806080329.369b69f9@ender> <20070806080620.39d29ffb@ender> Message-ID: <20070806121836.GH18009@puariko.nirvana> On Mon, Aug 06, 2007 at 08:06:20AM -0400, Jesse Keating wrote: > On Mon, 6 Aug 2007 08:03:29 -0400 > Jesse Keating wrote: > > > This task is the one you're probably concerned with: > > http://koji.fedoraproject.org/koji/getfile?taskID=89866&name=srpm.log > > > > I'm not entirely certain how that produced a .fc8 srpm at the end of > > it, looking into it. > > Bingo. > > mediawiki-1_9_3-34_fc7:devel:athimm:1172147229 > > You previously tagged this source as 1.9.3-34 when on the devel/ > branch, presumably before the branching happened for F-7. Since the > CVS tag you asked for lives ^^^^^ Typo? > in devel, koji gets a little confused when making the srpm for you. > You'll most likely need to bump/tag on F-7 then you can build and it > will get the proper .fc7 tag to it. Hm, this sounds more like a bug that should be fixed in koji. Wouldn't that apply to any kind of branching CVS, e.g. koji inherits bad tags to branches? This bug only surfaces if the tagsing and building is intermitted by the branch, but consider adding new archs to Fedora, it will hit all packages (as the build for the new arch will be after the branching, unless new archs are limited to devel). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 12:25:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 08:25:20 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806121836.GH18009@puariko.nirvana> References: <20070806100815.GB18009@puariko.nirvana> <20070806080329.369b69f9@ender> <20070806080620.39d29ffb@ender> <20070806121836.GH18009@puariko.nirvana> Message-ID: <20070806082520.39f995c2@ender> On Mon, 6 Aug 2007 14:18:36 +0200 Axel Thimm wrote: > Typo? Not exactly. Expression mismatch. The tag was /applied/ on the devel/ branch, so when cvs is asked for that tag, it tries to pull it from devel/ and bad things happen. > > in devel, koji gets a little confused when making the srpm for you. > > You'll most likely need to bump/tag on F-7 then you can build and it > > will get the proper .fc7 tag to it. > > Hm, this sounds more like a bug that should be fixed in koji. Wouldn't > that apply to any kind of branching CVS, e.g. koji inherits bad tags > to branches? This bug only surfaces if the tagsing and building is > intermitted by the branch, but consider adding new archs to Fedora, it > will hit all packages (as the build for the new arch will be after the > branching, unless new archs are limited to devel). I'm not entirely sure how this is going to be handled. It probably does need looking into, something deep in the cvs "branching" scripts we use. My cvs-fu isn't nearly that strong :( -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 12:35:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 14:35:33 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806082520.39f995c2@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806080329.369b69f9@ender> <20070806080620.39d29ffb@ender> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> Message-ID: <20070806123533.GI18009@puariko.nirvana> On Mon, Aug 06, 2007 at 08:25:20AM -0400, Jesse Keating wrote: > On Mon, 6 Aug 2007 14:18:36 +0200 > Axel Thimm wrote: > > > You previously tagged this source as 1.9.3-34 when on the devel/ > > branch, presumably before the branching happened for F-7. Since the > > CVS tag you asked for lives ^^^^^ > > Typo? > > Not exactly. Expression mismatch. The tag was /applied/ on the devel/ > branch, so when cvs is asked for that tag, it tries to pull it from > devel/ and bad things happen. I was referring to "lives" > > > in devel, koji gets a little confused when making the srpm for you. > > > You'll most likely need to bump/tag on F-7 then you can build and it > > > will get the proper .fc7 tag to it. > > > > Hm, this sounds more like a bug that should be fixed in koji. Wouldn't > > that apply to any kind of branching CVS, e.g. koji inherits bad tags > > to branches? This bug only surfaces if the tagsing and building is > > intermitted by the branch, but consider adding new archs to Fedora, it > > will hit all packages (as the build for the new arch will be after the > > branching, unless new archs are limited to devel). > > I'm not entirely sure how this is going to be handled. It probably > does need looking into, something deep in the cvs "branching" scripts > we use. My cvs-fu isn't nearly that strong :( OK, so for now bump-and-go and worry about mass issues only once they arrive? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 12:37:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 08:37:45 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806123533.GI18009@puariko.nirvana> References: <20070806100815.GB18009@puariko.nirvana> <20070806080329.369b69f9@ender> <20070806080620.39d29ffb@ender> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <20070806123533.GI18009@puariko.nirvana> Message-ID: <20070806083745.203a15bd@ender> On Mon, 6 Aug 2007 14:35:33 +0200 Axel Thimm wrote: > > > CVS tag you asked for lives > ^^^^^ > > > Typo? > > > > Not exactly. Expression mismatch. The tag was /applied/ on the > > devel/ branch, so when cvs is asked for that tag, it tries to pull > > it from devel/ and bad things happen. > > I was referring to "lives" I know. I used the term 'lives' to indicate that the reference to that tag exists on the devel/ branch, IE it "lives" there, that's it's home. > > > > > in devel, koji gets a little confused when making the srpm for > > > > you. You'll most likely need to bump/tag on F-7 then you can > > > > build and it will get the proper .fc7 tag to it. > > > > > > Hm, this sounds more like a bug that should be fixed in koji. > > > Wouldn't that apply to any kind of branching CVS, e.g. koji > > > inherits bad tags to branches? This bug only surfaces if the > > > tagsing and building is intermitted by the branch, but consider > > > adding new archs to Fedora, it will hit all packages (as the > > > build for the new arch will be after the branching, unless new > > > archs are limited to devel). > > > > I'm not entirely sure how this is going to be handled. It probably > > does need looking into, something deep in the cvs "branching" > > scripts we use. My cvs-fu isn't nearly that strong :( > > OK, so for now bump-and-go and worry about mass issues only once they > arrive? Feel free to examine the branching tools and cvs layout to try to make it better. I'm just saying that I can't right now. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 12:47:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 14:47:07 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806083745.203a15bd@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806080329.369b69f9@ender> <20070806080620.39d29ffb@ender> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <20070806123533.GI18009@puariko.nirvana> <20070806083745.203a15bd@ender> Message-ID: <20070806124707.GJ18009@puariko.nirvana> On Mon, Aug 06, 2007 at 08:37:45AM -0400, Jesse Keating wrote: > On Mon, 6 Aug 2007 14:35:33 +0200 > Axel Thimm wrote: > > > > > CVS tag you asked for lives > > ^^^^^ > > > > Typo? > > > > > > Not exactly. Expression mismatch. The tag was /applied/ on the > > > devel/ branch, so when cvs is asked for that tag, it tries to pull > > > it from devel/ and bad things happen. > > > > I was referring to "lives" > > I know. I used the term 'lives' to indicate that the reference to that > tag exists on the devel/ branch, IE it "lives" there, that's it's home. OK, sorry, my bad reading - I thought you referred to http://lives.sourceforge.net/ > > OK, so for now bump-and-go and worry about mass issues only once they > > arrive? > > Feel free to examine the branching tools and cvs layout to try to make > it better. I'm just saying that I can't right now. Examine branching tools under CVS? I closed with CVS half a decade ago after it tortured me for quite longer than a decade ;) (me is eagerly watching the discussion about koji/svn hoping there will be an scm-abstraction in koji soon to allow for hg/git) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Aug 6 12:51:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 6 Aug 2007 07:51:00 -0500 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806082520.39f995c2@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> Message-ID: <200708060751.01486.dennis@ausil.us> Once upon a time Monday 06 August 2007, Jesse Keating wrote: > On Mon, 6 Aug 2007 14:18:36 +0200 > > Axel Thimm wrote: > > Typo? > > Not exactly. Expression mismatch. The tag was /applied/ on the devel/ > branch, so when cvs is asked for that tag, it tries to pull it from > devel/ and bad things happen. > > > > in devel, koji gets a little confused when making the srpm for you. > > > You'll most likely need to bump/tag on F-7 then you can build and it > > > will get the proper .fc7 tag to it. > > > > Hm, this sounds more like a bug that should be fixed in koji. Wouldn't > > that apply to any kind of branching CVS, e.g. koji inherits bad tags > > to branches? This bug only surfaces if the tagsing and building is > > intermitted by the branch, but consider adding new archs to Fedora, it > > will hit all packages (as the build for the new arch will be after the > > branching, unless new archs are limited to devel). > > I'm not entirely sure how this is going to be handled. It probably > does need looking into, something deep in the cvs "branching" scripts > we use. My cvs-fu isn't nearly that strong :( probably need to call make tag after creating the branch. Dennis From Axel.Thimm at ATrpms.net Mon Aug 6 13:00:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 15:00:05 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <200708060751.01486.dennis@ausil.us> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> Message-ID: <20070806130005.GM18009@puariko.nirvana> On Mon, Aug 06, 2007 at 07:51:00AM -0500, Dennis Gilmore wrote: > Once upon a time Monday 06 August 2007, Jesse Keating wrote: > > On Mon, 6 Aug 2007 14:18:36 +0200 > > > > Axel Thimm wrote: > > > Typo? > > > > Not exactly. Expression mismatch. The tag was /applied/ on the devel/ > > branch, so when cvs is asked for that tag, it tries to pull it from > > devel/ and bad things happen. > > > > > > in devel, koji gets a little confused when making the srpm for you. > > > > You'll most likely need to bump/tag on F-7 then you can build and it > > > > will get the proper .fc7 tag to it. > > > > > > Hm, this sounds more like a bug that should be fixed in koji. Wouldn't > > > that apply to any kind of branching CVS, e.g. koji inherits bad tags > > > to branches? This bug only surfaces if the tagsing and building is > > > intermitted by the branch, but consider adding new archs to Fedora, it > > > will hit all packages (as the build for the new arch will be after the > > > branching, unless new archs are limited to devel). > > > > I'm not entirely sure how this is going to be handled. It probably > > does need looking into, something deep in the cvs "branching" scripts > > we use. My cvs-fu isn't nearly that strong :( > > probably need to call make tag after creating the branch. The problem was that make tag has been created before the branch, but the make build afterwards. It is also not possible to rerun make tag. For this case of for branching F8 this affects only a couple packages that were in a pending state, but for adding a new arch this will affect all packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikeb at redhat.com Mon Aug 6 14:39:08 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 06 Aug 2007 10:39:08 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806130005.GM18009@puariko.nirvana> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> <20070806130005.GM18009@puariko.nirvana> Message-ID: <1186411148.28026.15.camel@burren.boston.redhat.com> On Mon, 2007-08-06 at 15:00 +0200, Axel Thimm wrote: > On Mon, Aug 06, 2007 at 07:51:00AM -0500, Dennis Gilmore wrote: > > Once upon a time Monday 06 August 2007, Jesse Keating wrote: > > > On Mon, 6 Aug 2007 14:18:36 +0200 > > > > > > Axel Thimm wrote: > > > > Typo? > > > > > > Not exactly. Expression mismatch. The tag was /applied/ on the devel/ > > > branch, so when cvs is asked for that tag, it tries to pull it from > > > devel/ and bad things happen. > > > > > > > > in devel, koji gets a little confused when making the srpm for you. > > > > > You'll most likely need to bump/tag on F-7 then you can build and it > > > > > will get the proper .fc7 tag to it. > > > > > > > > Hm, this sounds more like a bug that should be fixed in koji. Wouldn't > > > > that apply to any kind of branching CVS, e.g. koji inherits bad tags > > > > to branches? This bug only surfaces if the tagsing and building is > > > > intermitted by the branch, but consider adding new archs to Fedora, it > > > > will hit all packages (as the build for the new arch will be after the > > > > branching, unless new archs are limited to devel). > > > > > > I'm not entirely sure how this is going to be handled. It probably > > > does need looking into, something deep in the cvs "branching" scripts > > > we use. My cvs-fu isn't nearly that strong :( > > > > probably need to call make tag after creating the branch. > > The problem was that make tag has been created before the branch, but > the make build afterwards. It is also not possible to rerun make tag. The problem here is actually that the tag created on devel/ didn't include a "branch" file (that file doesn't get created until the branch-creation scripts are run). In the absence of a "branch" file, Makefile.common assumes you're on devel/ and expands the %dist tag to the values defined for devel in common/branches (currently .fc8). Basically, tagging before the branch point and building after it is not supported. After the branch point, any builds need to bump the revision and run "make tag" before they can build. From Axel.Thimm at ATrpms.net Mon Aug 6 14:49:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 16:49:13 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <1186411148.28026.15.camel@burren.boston.redhat.com> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> <20070806130005.GM18009@puariko.nirvana> <1186411148.28026.15.camel@burren.boston.redhat.com> Message-ID: <20070806144913.GB15391@puariko.nirvana> On Mon, Aug 06, 2007 at 10:39:08AM -0400, Mike Bonnet wrote: > On Mon, 2007-08-06 at 15:00 +0200, Axel Thimm wrote: > > On Mon, Aug 06, 2007 at 07:51:00AM -0500, Dennis Gilmore wrote: > > > Once upon a time Monday 06 August 2007, Jesse Keating wrote: > > > > On Mon, 6 Aug 2007 14:18:36 +0200 > > > > > > > > Axel Thimm wrote: > > > > > Typo? > > > > > > > > Not exactly. Expression mismatch. The tag was /applied/ on the devel/ > > > > branch, so when cvs is asked for that tag, it tries to pull it from > > > > devel/ and bad things happen. > > > > > > > > > > in devel, koji gets a little confused when making the srpm for you. > > > > > > You'll most likely need to bump/tag on F-7 then you can build and it > > > > > > will get the proper .fc7 tag to it. > > > > > > > > > > Hm, this sounds more like a bug that should be fixed in koji. Wouldn't > > > > > that apply to any kind of branching CVS, e.g. koji inherits bad tags > > > > > to branches? This bug only surfaces if the tagsing and building is > > > > > intermitted by the branch, but consider adding new archs to Fedora, it > > > > > will hit all packages (as the build for the new arch will be after the > > > > > branching, unless new archs are limited to devel). > > > > > > > > I'm not entirely sure how this is going to be handled. It probably > > > > does need looking into, something deep in the cvs "branching" scripts > > > > we use. My cvs-fu isn't nearly that strong :( > > > > > > probably need to call make tag after creating the branch. > > > > The problem was that make tag has been created before the branch, but > > the make build afterwards. It is also not possible to rerun make tag. > > The problem here is actually that the tag created on devel/ didn't > include a "branch" file (that file doesn't get created until the > branch-creation scripts are run). In the absence of a "branch" file, > Makefile.common assumes you're on devel/ and expands the %dist tag to > the values defined for devel in common/branches (currently .fc8). > > Basically, tagging before the branch point and building after it is not > supported. After the branch point, any builds need to bump the revision > and run "make tag" before they can build. OK, we got that far, but how will you support a new arch in the tree? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 14:54:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 10:54:53 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806144913.GB15391@puariko.nirvana> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> <20070806130005.GM18009@puariko.nirvana> <1186411148.28026.15.camel@burren.boston.redhat.com> <20070806144913.GB15391@puariko.nirvana> Message-ID: <20070806105453.7514fd11@ender> On Mon, 6 Aug 2007 16:49:13 +0200 Axel Thimm wrote: > OK, we got that far, but how will you support a new arch in the tree? Usually we rebuild the package to pick up the arch. In the secondary arch world it might not be a bad thing to have them start at devel and do all the work necessary there to target the next release as the first release that supports $arch. There will be lots of changes needed to packages to build for a new arch anyway and those changes might not be wanted on a released branch. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 15:06:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 17:06:25 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806105453.7514fd11@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> <20070806130005.GM18009@puariko.nirvana> <1186411148.28026.15.camel@burren.boston.redhat.com> <20070806144913.GB15391@puariko.nirvana> <20070806105453.7514fd11@ender> Message-ID: <20070806150625.GC15391@puariko.nirvana> On Mon, Aug 06, 2007 at 10:54:53AM -0400, Jesse Keating wrote: > On Mon, 6 Aug 2007 16:49:13 +0200 > Axel Thimm wrote: > > > OK, we got that far, but how will you support a new arch in the tree? > > Usually we rebuild the package to pick up the arch. Which is something one can only do in a devel cycle, e.g. with the current setup there will never be new archs for released Fedora cuts. It's just something to think about whether this is wanted at all - with the current Fedora release cycles it doesn't hurt to add a new arch to devel only. But if koji is used for RHEL or other longer-cycle products not being able to add an arch for a released product (or having to rebuild everything for all other arches as well due to artificial release bumps) could become an issue. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 15:22:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 11:22:02 -0400 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806150625.GC15391@puariko.nirvana> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> <20070806130005.GM18009@puariko.nirvana> <1186411148.28026.15.camel@burren.boston.redhat.com> <20070806144913.GB15391@puariko.nirvana> <20070806105453.7514fd11@ender> <20070806150625.GC15391@puariko.nirvana> Message-ID: <20070806112202.1fe3e73d@ender> On Mon, 6 Aug 2007 17:06:25 +0200 Axel Thimm wrote: > It's just something to think about whether this is wanted at all - > with the current Fedora release cycles it doesn't hurt to add a new > arch to devel only. But if koji is used for RHEL or other longer-cycle > products not being able to add an arch for a released product (or > having to rebuild everything for all other arches as well due to > artificial release bumps) could become an issue. In RHEL at least we'd want to rebuild the package anyway. You can't come along 4 months or 2 years later to request that another arch be done of that build, unless you can generate a repodata set that matched the original repodata set and all the original used packages to build your package 4 months or 2 years ago. Buildroot content changes over time and you don't want 3 of your arches using one set of build tools and your new arch using potentially vastly different ones. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 20:15:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 22:15:17 +0200 Subject: Security issue: Can't build mediawiki - F7 thinks it's F8 In-Reply-To: <20070806112202.1fe3e73d@ender> References: <20070806100815.GB18009@puariko.nirvana> <20070806121836.GH18009@puariko.nirvana> <20070806082520.39f995c2@ender> <200708060751.01486.dennis@ausil.us> <20070806130005.GM18009@puariko.nirvana> <1186411148.28026.15.camel@burren.boston.redhat.com> <20070806144913.GB15391@puariko.nirvana> <20070806105453.7514fd11@ender> <20070806150625.GC15391@puariko.nirvana> <20070806112202.1fe3e73d@ender> Message-ID: <20070806201517.GB23470@puariko.nirvana> On Mon, Aug 06, 2007 at 11:22:02AM -0400, Jesse Keating wrote: > On Mon, 6 Aug 2007 17:06:25 +0200 > Axel Thimm wrote: > > > It's just something to think about whether this is wanted at all - > > with the current Fedora release cycles it doesn't hurt to add a new > > arch to devel only. But if koji is used for RHEL or other longer-cycle > > products not being able to add an arch for a released product (or > > having to rebuild everything for all other arches as well due to > > artificial release bumps) could become an issue. > > In RHEL at least we'd want to rebuild the package anyway. You can't > come along 4 months or 2 years later to request that another arch be > done of that build, unless you can generate a repodata set that matched > the original repodata set and all the original used packages to build > your package 4 months or 2 years ago. Buildroot content changes over > time and you don't want 3 of your arches using one set of build tools > and your new arch using potentially vastly different ones. RHEL is quite different and already equipped to do builds in fixed environments like for customer requested RHEL X update Y states. Furthermore RHEL is not update happy, certainly not in comparison to Fedora, so 4 months or 2 years usually still means the same API/ABI (short of the kernel, of course). But I was told in the interim that the pain of the past of adding archs to released RHELs hardened the RHEL engineering teem enough to fence off any such future requests. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmeyer at themeyerfarm.com Fri Aug 10 18:22:48 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Fri, 10 Aug 2007 12:22:48 -0600 Subject: pungi on i386 to build x86_64? Message-ID: <46BCACF8.8050500@themeyerfarm.com> The are some comments in the generic pungi.conf that indicate that a i386 based Fedora can only roll releases for i386. For this question please assume that no sources are being recompiled or gathered for the release. Is this still correct? What happens, is that the .discinfo fails to be created. Here is the python error: Traceback (most recent call last): File "/usr/bin/pungi", line 187, in main() File "/usr/bin/pungi", line 125, in main mypungi.doCreateSplitrepo() File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 278, in doCreateSplitrepo discinfo = open(os.path.join(self.topdir, '.discinfo'), 'r').readlines() IOError: [Errno 2] No such file or directory: '/srv/pungi/RHEL5_x86_64/5/Custom/x86_64/os/.discinfo' I have seen previous questions related to rolling RHE releases from F7, but is it that or the arch issue? Thanks! From jkeating at redhat.com Fri Aug 10 19:27:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Aug 2007 15:27:36 -0400 Subject: pungi on i386 to build x86_64? In-Reply-To: <46BCACF8.8050500@themeyerfarm.com> References: <46BCACF8.8050500@themeyerfarm.com> Message-ID: <20070810152736.6663222a@ender> On Fri, 10 Aug 2007 12:22:48 -0600 Phil Meyer wrote: > The are some comments in the generic pungi.conf that indicate that a > i386 based Fedora can only roll releases for i386. > > For this question please assume that no sources are being recompiled > or gathered for the release. > > Is this still correct? Yes. In order to run buildinstall, anaconda needs to be on the arch you're composing for to deal with the kernel modules and such. You can fake out i386 by doing 'setarch i386' on an x86_64 system, but not the other way around, and not on ppc on anything but ppc(64). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From prarit at redhat.com Tue Aug 14 23:53:55 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Tue, 14 Aug 2007 19:53:55 -0400 Subject: How F8T1 was bootstrapped for ia64 ... Message-ID: <46C24093.7090802@redhat.com> Some rough notes describing the process to bootstrap F8T1 for ia64. Prolly useful for anyone else trying to bootstrap. 1. In this release I used thetango and mockbuilder to bootstrap the entire Fedora tree. There were four critical issues to overcome: a) Generating the initial set of RPMS in /etc/thetango/built. This required the setting up of a Debian based environment to get some initial packages built. See Debian note at bottom. b) Initial perl packages A lot of the perl-* packages are NOARCH and they can be directly "ported" from the primary arches (TODO: Can all noarch packages be ported over? Why or why not?) c) mock errors - "Could not find useradd in chroot, maybe the install failed?" probably caused by missing/inadequate version of rpmdevtools - make sure you are using the right version of buildgroups. AFAICT, you must use the version of buildgroups that corresponds to the version of rpmdevtools and mock you are using. For example, if you are using F6's mock & rpmdevtools you must use F6's buildgroups d) mock building errors The big issue is the versions of rpm, redhat-rpm-config, and rpmdevtools. As we build the OS, new versions of these packages are available and can conflict with the existing packages that are being used to do the mock compose. I had to run the build in the following order: First: run through with mockbuilder's rpm-slave. Second: run through with mockbuilder's mock-slave -- eventually errors are generated because of mis-matched rpm, redhat-rpm-config, and rpmdevtools. At this point I removed the three rpms and prevented them from building. Third: run through with mockbuilder's mock-slave again. (TODO: Is it sufficient to just remove rpm, redhat-rpm-config, and rpmdevtools from the repo? Can they be excluded in yum?) 2. Using pungi to build a) After configuring pungi correctly I hit three errors that required action - gcc did not build, - glibc did not build, - booty was broken, and - anaconda was broken. GCC and GLIBC were taken from the F-7 distro. I entered in bugs (which jakub has resolved) and hopefully these will be available from F8T2 on. booty had to be downversioned to booty-0.85.1 . I had to modify anaconda with the following patch (warning, cut-and-paste): Index: anaconda/scripts/upd-instroot diff -u anaconda/scripts/upd-instroot:1.565 anaconda/scripts/upd-instroot:1.566 --- anaconda/scripts/upd-instroot:1.565 Mon Aug 6 14:49:10 2007 +++ anaconda/scripts/upd-instroot Wed Aug 8 11:14:48 2007 @@ -433,6 +433,7 @@ sbin/busybox.anaconda sbin/clock sbin/debugfs +sbin/dosfslabel sbin/e2fsck sbin/e2fsadm sbin/e2label ------------------------------------------------------------------------------- Debian -- HOW TO BOOTSTRAP! 1. Download debootstrap source rpm, installed sources and manually built using make install. 2. made a debian dir. 3. debootstrap --arch ia64 etch debian http://http.us.debian.org/debian etch is the release name, it may change. 4. cp /etc/resolv.conf debian/etc cp /etc/hosts debian//etc 5. chroot debian /usr/bin/env -i HOME=/root TERM=$TERM PS1='\u:\w\$' PATH=/bin:/ usr/bin:/sbin:/usr/sbin /bin/bash --login 6. In the debian root, apt-get install downloads and installs a package. 7. In the debian root, apt-get -d install downloads and doesn't install a package. The download is in /var/cache/apt/archives. 8. apt-get install alien rpm 9. Use alien to create an rpm from the deb package 10. Useful links http://www.underhanded.org/papers/debian-conversion/remotedeb.html#debootstrap http://www.gelato.unsw.edu.au/IA64wiki/debootstrap http://mirrors.kernel.org/debian/pool/main/ From pmeyer at themeyerfarm.com Wed Aug 15 21:00:03 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Wed, 15 Aug 2007 15:00:03 -0600 Subject: remaking an initrd.img for diskboot.img and pxeboot Message-ID: <46C36953.4050909@themeyerfarm.com> For odd reasons, I am attempting to add a driver to an initrd.img. Using the exact same kernel as on the original media, I have built a driver module. I have extracted pxeboot/initrd.img into: /tmp/img/original I have extracted the /tmp/img/original/modules/modules.cgz file into: /tmp/img/moddir I have added the properly built modules into: /tmp/img/moddir/2.6.18-8.el5/x86_64 I have manually edited: /tmp/img/original/modules/modules.dep I rebuilt the initrd.img using these steps: # cd /tmp/img/moddir # find 2.6.18-8.el5 -depth -print | cpio --quiet -H crc -o | gzip -9 > /tmp/modules.cgz # cd /tmp/img/original # cp /tmp/modules.cgz modules/ # find . | cpio --quiet -c -o | gzip -9 > ../initrd.img I then copied the initrd.img to the proper PXE/TFTP directory, and tested a boot to it. It starts an install with no obvious errors, but the modules won't load. What did I miss? I am doing it remote with no access to F3 or F4 I will attempt to get over to the system and try from there to provide additional info, but I was hoping someone could spot an idiot mistake in my steps. Thanks for any help. From prarit at redhat.com Thu Aug 16 14:54:00 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 16 Aug 2007 10:54:00 -0400 Subject: remaking an initrd.img for diskboot.img and pxeboot In-Reply-To: <46C36953.4050909@themeyerfarm.com> References: <46C36953.4050909@themeyerfarm.com> Message-ID: <46C46508.3000202@redhat.com> Phil Meyer wrote: > > For odd reasons, I am attempting to add a driver to an initrd.img. > > Using the exact same kernel as on the original media, I have built a > driver module. > Hey Phil, *Everytime* I've tried taking a shortcut and hacked the initrd.img I've hit some other issue that makes it not work. :/ Can I make a suggestion? Your best bet is to modify the kernel source rpm with your changes, rebuild the kernel, and then rebuild the distro using jkeating's pungi. Yes, this takes longer than trying to hack the initrd.img, but in the long run you'll realize the "rebuild-kernel-rebuild-os" is much easier to do. :) P. From asdas at redhat.com Fri Aug 17 05:43:06 2007 From: asdas at redhat.com (ashok shankar das) Date: Fri, 17 Aug 2007 11:13:06 +0530 Subject: remaking an initrd.img for diskboot.img and pxeboot In-Reply-To: <46C46508.3000202@redhat.com> References: <46C36953.4050909@themeyerfarm.com> <46C46508.3000202@redhat.com> Message-ID: <46C5356A.5080600@redhat.com> Prarit Bhargava wrote: > > > Phil Meyer wrote: > >> >> For odd reasons, I am attempting to add a driver to an initrd.img. >> >> Using the exact same kernel as on the original media, I have built a >> driver module. >> > > Hey Phil, > > *Everytime* I've tried taking a shortcut and hacked the initrd.img > I've hit some other issue that makes it not work. :/ > > Can I make a suggestion? Your best bet is to modify the kernel source > rpm with your changes, rebuild the kernel, and then rebuild the distro > using jkeating's pungi. This is not a good way of doing. better use *mkinitrd* it works for me. even hacking initrd works for me. > Yes, this takes longer than trying to hack the initrd.img, but in the > long run you'll realize the "rebuild-kernel-rebuild-os" is much easier > to do. :) > > P. > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From jos at xos.nl Sat Aug 25 20:09:59 2007 From: jos at xos.nl (Jos Vos) Date: Sat, 25 Aug 2007 22:09:59 +0200 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <469BD849.3030309@kanarip.com>; from kanarip@kanarip.com on Mon, Jul 16, 2007 at 10:42:49PM +0200 References: <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> <469BD849.3030309@kanarip.com> Message-ID: <20070825220959.A20769@xos037.xos.nl> On Mon, Jul 16, 2007 at 10:42:49PM +0200, Jeroen van Meeuwen wrote: > William F. Acker WB2FLW +1-303-722-7209 wrote: > > > I wonder if this is better fixed in Anaconda. I'm aware of the > > policy against updating Anaconda once a general release happens, > > although an updated Anaconda did appear in FC6 testing, but was never > > pushed to updates. Now that we're being encouraged to spin our own > > releases, it seems to me that the policy should be revisited. > > If I understand correctly the fix is in anaconda's development release. What version and/or what is the fix? I see the same problem in RHEL 5.1, where the new yum and pkgorder won't work together, with the same symptoms as discussed in this thread. FWIW: in RHEL 5.1 there is another pkgorder problem that was already fixed in F7: - self.repos.populateSack(with='filelists') + self.repos.populateSack('enabled', 'filelists') -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From kanarip at kanarip.com Sat Aug 25 21:15:28 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 25 Aug 2007 23:15:28 +0200 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070825220959.A20769@xos037.xos.nl> References: <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> <469BD849.3030309@kanarip.com> <20070825220959.A20769@xos037.xos.nl> Message-ID: <46D09BF0.1010306@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jos Vos wrote: > On Mon, Jul 16, 2007 at 10:42:49PM +0200, Jeroen van Meeuwen wrote: > >> William F. Acker WB2FLW +1-303-722-7209 wrote: >> >>> I wonder if this is better fixed in Anaconda. I'm aware of the >>> policy against updating Anaconda once a general release happens, >>> although an updated Anaconda did appear in FC6 testing, but was never >>> pushed to updates. Now that we're being encouraged to spin our own >>> releases, it seems to me that the policy should be revisited. >> If I understand correctly the fix is in anaconda's development release. > > What version and/or what is the fix? > > I see the same problem in RHEL 5.1, where the new yum and pkgorder > won't work together, with the same symptoms as discussed in this thread. > > FWIW: in RHEL 5.1 there is another pkgorder problem that was already > fixed in F7: > > - self.repos.populateSack(with='filelists') > + self.repos.populateSack('enabled', 'filelists') > The key item here may be yum. We've seen similar issues before. The system's yum version doesn't seem to matter, but the one pulled into the tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG0JvwKN6f2pNCvwgRAjEBAKCDgVvHZF3gD9bG1xbP5GPDlBgzBACgr0mb nOtTJ+RNUiVsZJ6Ub7cuIVU= =sSrt -----END PGP SIGNATURE----- From jos at xos.nl Sat Aug 25 21:55:02 2007 From: jos at xos.nl (Jos Vos) Date: Sat, 25 Aug 2007 23:55:02 +0200 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <46D09BF0.1010306@kanarip.com>; from kanarip@kanarip.com on Sat, Aug 25, 2007 at 11:15:28PM +0200 References: <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> <469BD849.3030309@kanarip.com> <20070825220959.A20769@xos037.xos.nl> <46D09BF0.1010306@kanarip.com> Message-ID: <20070825235502.A21647@xos037.xos.nl> Hi Jeroen, On Sat, Aug 25, 2007 at 11:15:28PM +0200, Jeroen van Meeuwen wrote: > The key item here may be yum. We've seen similar issues before. The > system's yum version doesn't seem to matter, but the one pulled into the > tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't. Correct, but I saw in this thread Jesse saying that the problem was identified and you mentioned that the fix should be in anaconda's development version. Anyway, I seem to have solved it at least for my RHEL environment given Jesse's hint for creating a headers directory: in my pkgorder I now added at the end of setup(): os.mkdir(os.path.join(cachedir, 'anaconda', 'headers'), 0755) which seems to solve the problem. I don't see anything fixing the problem in anaconda-11.3.0.19 (devel), but maybe that's because in the meantime yum is fixed (or better: behaving differently, as I don't know the yum API well enough to say that yum was wrong). I want to stick to yum 3.2.1, as long as this the proposed version for RHEL 5.1 Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From kanarip at kanarip.com Sat Aug 25 22:05:03 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 26 Aug 2007 00:05:03 +0200 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070825235502.A21647@xos037.xos.nl> References: <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> <469BD849.3030309@kanarip.com> <20070825220959.A20769@xos037.xos.nl> <46D09BF0.1010306@kanarip.com> <20070825235502.A21647@xos037.xos.nl> Message-ID: <46D0A78F.8010408@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jos Vos wrote: > Hi Jeroen, > > On Sat, Aug 25, 2007 at 11:15:28PM +0200, Jeroen van Meeuwen wrote: > >> The key item here may be yum. We've seen similar issues before. The >> system's yum version doesn't seem to matter, but the one pulled into the >> tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't. > > Correct, but I saw in this thread Jesse saying that the problem was > identified and you mentioned that the fix should be in anaconda's > development version. > > Anyway, I seem to have solved it at least for my RHEL environment > given Jesse's hint for creating a headers directory: in my pkgorder > I now added at the end of setup(): > > os.mkdir(os.path.join(cachedir, 'anaconda', 'headers'), 0755) > > which seems to solve the problem. > > I don't see anything fixing the problem in anaconda-11.3.0.19 (devel), > but maybe that's because in the meantime yum is fixed (or better: > behaving differently, as I don't know the yum API well enough to say > that yum was wrong). I want to stick to yum 3.2.1, as long as this > the proposed version for RHEL 5.1 > > Cheers, > The problem was with yum not creating the headers/ directory anymore in yum-3.2.1, and although Seth tried to fix that in yum-3.2.2, it didn't do the trick. But yeah, if you create the directory at some point manually, it should fix stuff. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG0KePKN6f2pNCvwgRAvmJAJ9A455vArBE/ITtKNrQ7++MJXOUigCeI9aO VMam+2dkdCxBDqp9hPp5qvo= =F4Ka -----END PGP SIGNATURE----- From markmc at redhat.com Fri Aug 31 16:00:20 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:00:20 +0100 Subject: [patch 0/4] Some miscellanous pungi patches Message-ID: <20070831155221.672428000@redhat.com>> Hi, What follows are a few miscellanous patches for pungi. There's nothing major here. The one I'm most interested in is the third patch which adds new API to make it easier for other programs to use pypungi.gather. Cheers, Mark. -- From markmc at redhat.com Fri Aug 31 16:00:46 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:00:46 +0100 Subject: [patch 1/4] Remove Python 2.5 usage References: <20070831155221.672428000@redhat.com>> Message-ID: <20070831155430.074450000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: pungi-work-with-older-python.patch URL: From markmc at redhat.com Fri Aug 31 16:00:56 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:00:56 +0100 Subject: [patch 2/4] Fix local repository handling References: <20070831155221.672428000@redhat.com>> Message-ID: <20070831155430.128323000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: pungi-fix-local-file-handling.patch URL: From markmc at redhat.com Fri Aug 31 16:01:05 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:01:05 +0100 Subject: [patch 3/4] Re-factor package download code References: <20070831155221.672428000@redhat.com>> Message-ID: <20070831155430.184168000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: pungi-refactor-package-download.patch URL: From markmc at redhat.com Fri Aug 31 16:01:14 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:01:14 +0100 Subject: [patch 4/4] Add a Config class References: <20070831155221.672428000@redhat.com>> Message-ID: <20070831155430.236623000@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: pungi-add-config-object.patch URL: From markmc at redhat.com Fri Aug 31 16:04:57 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:04:57 +0100 Subject: [patch 0/4] Some miscellanous pungi patches In-Reply-To: <20070831155221.672428000@redhat.com>> References: <20070831155221.672428000@redhat.com>> Message-ID: <1188576297.9202.5.camel@blaa> Hey, Oh, yes, I forgot to say ... pungi/share/comps-cleanup.xml seems to be missing from the repo and the 1.0.2 doesn't seem to have been pushed to the repo either? Cheers, Mark. From a.badger at gmail.com Fri Aug 31 16:24:17 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 31 Aug 2007 09:24:17 -0700 Subject: [patch 1/4] Remove Python 2.5 usage In-Reply-To: <20070831155221.672428000@redhat.com>> References: <20070831155221.672428000@redhat.com>> Message-ID: <46D840B1.5090109@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > An empty list of base classes wasn't allowed before Python 2.5 so > remove it since it seems to be the only Python 2.5 feature being > used. What version of python are you taking as your minimum? If it's python2.2 then you'd be better off inheriting from object. Inheriting from object makes this a new-style class which has some features and behaviors that can make it superior to old-style classes. Revised patch: Index: pungi/pypungi/__init__.py =================================================================== - --- pungi.orig/pypungi/__init__.py +++ pungi/pypungi/__init__.py @@ -16,7 +16,7 @@ import logging import os import subprocess - -class PungiBase(): +class PungiBase(object): """The base Pungi class. Set up config items and logging here""" def __init__(self, config): -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG2ECxX6yAic2E7kgRAsNfAJwJXRMOdu6HjYzqjGxPO6xXxMNVVgCfd8L0 c/wgEOGTft0e9/CuNbGmu0Q= =JVoi -----END PGP SIGNATURE----- From markmc at redhat.com Fri Aug 31 16:34:45 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 31 Aug 2007 17:34:45 +0100 Subject: [patch 1/4] Remove Python 2.5 usage In-Reply-To: <46D840B1.5090109@gmail.com> References: <20070831155221.672428000@redhat.com> > <46D840B1.5090109@gmail.com> Message-ID: <1188578085.9202.6.camel@blaa> On Fri, 2007-08-31 at 09:24 -0700, Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > An empty list of base classes wasn't allowed before Python 2.5 so > > remove it since it seems to be the only Python 2.5 feature being > > used. > > What version of python are you taking as your minimum? If it's > python2.2 then you'd be better off inheriting from object. Inheriting > from object makes this a new-style class which has some features and > behaviors that can make it superior to old-style classes. Yep, good point. Cheers, Mark. From jkeating at redhat.com Fri Aug 31 23:23:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 31 Aug 2007 19:23:41 -0400 Subject: [patch 1/4] Remove Python 2.5 usage In-Reply-To: <20070831155430.074450000@redhat.com> References: <20070831155221.672428000@redhat.com> <20070831155430.074450000@redhat.com> Message-ID: <20070831192341.1ce7a32d@ender> On Fri, 31 Aug 2007 17:00:46 +0100 Mark McLoughlin wrote: > An empty list of base classes wasn't allowed before Python 2.5 so > remove it since it seems to be the only Python 2.5 feature being > used. So here is where I get a little curious. Much of the rest of pungi relies upon specific APIs in things like yum, createrepo, anaconda, pykickstart, etc.. Much of the requirements are on versions only available on platforms that have python2.5. As such, making the tip of pungi run on something other than python2.5 just seems bound to fail to me. You /really/ don't want to be composing one release from another. If you're going to compose FC6, you need to use the FC6 version of pungi to do it. Mock can help. The rest of the changes look fine and I'll add them shortly. Curious what you're attempting to do with pungi on a < python2.5 platform... I'm certainly not thinking about backwards compat when developing future versions of pungi to compose future versions of Fedora... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: