From arohner at gmail.com Wed Mar 5 20:11:23 2008 From: arohner at gmail.com (Allen Rohner) Date: Wed, 5 Mar 2008 14:11:23 -0600 Subject: pungi doesn't run Message-ID: <480038420803051211o7e8327a4n5188443195fe0059@mail.gmail.com> I'm trying to build an unattended F8 install CD using pungi. I'm on F8, running the pungi rpm (pungi-1.1.10-1.fc8). I always get the following error: Pungi.Gather:INFO: Finished downloading packages. Pungi.Gather:WARNING: No group data found for rawhide-source Pungi.Gather:INFO: Running /usr/bin/xsltproc --novalid -o /root/work/i386/Fedora-20080305-comps.xml /usr/share/pungi/comps-cleanup.xsl/root/work/i386/Fedora- 20080305-comps.xml Pungi.Pungi:INFO: Running /usr/bin/createrepo --quiet --database --groupfile /root/work/i386/Fedora-20080305-comps.xml /root/20080305/i386/os Pungi.Pungi:INFO: Running /usr/bin/repoview --quiet --title Fedora 20080305 - i386 /root/20080305/i386/os Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/buildinstall --product Fedora --version 20080305 --release Fedora 20080305 --prodpath Packages --bugurl http://bugzilla.redhat.com /root/20080305/i386/os Traceback (most recent call last): File "/usr/bin/pungi", line 178, in main() File "/usr/bin/pungi", line 91, in main mypungi.doCreateSplitrepo() File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 299, in doCreateSplitrepo discinfo = open(os.path.join(self.topdir, '.discinfo'), 'r').readlines() IOError: [Errno 2] No such file or directory: '/root/20080305/i386/os/.discinfo' Some googling found the post where it was mentioned that i386 can't build x86_64, but I'm on i386 trying to build for i386. My uname is: [root at arohner-fc8-vm ~]# uname -a Linux arohner-fc8-vm 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux Running "setarch i386 pungi -c fc8-ks.cfg" did not help either. My kickstart file is: repo --name=fedora --mirrorlist= http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=$basearch repo --name=fedora-source --mirrorlist= http://mirrors.fedoraproject.org/mirrorlist?repo=feodra-8-source&arch=$basearch %packages @base x86info postgresql-server python-sqlalchemy ruby ruby-irb rubygem-rails mod_python %end Running with the rawhide repository gives the exact same error. Thanks for your help Allen Rohner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Mar 5 20:41:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 05 Mar 2008 15:41:35 -0500 Subject: pungi doesn't run In-Reply-To: <480038420803051211o7e8327a4n5188443195fe0059@mail.gmail.com> References: <480038420803051211o7e8327a4n5188443195fe0059@mail.gmail.com> Message-ID: <1204749695.4693.3.camel@localhost.localdomain> On Wed, 2008-03-05 at 14:11 -0600, Allen Rohner wrote: > %packages > @base > x86info > postgresql-server > python-sqlalchemy > ruby > ruby-irb > rubygem-rails > mod_python > %end > > Running with the rawhide repository gives the exact same error. This is a very small package set, you need at least a kernel, the anaconda packages and a few other things. See the 'compose needs' section on the shipped kickstart file. Right now, pungi doesn't separate the "things we need to compose" from "things we want in the compose" so you need to add those things into the manifest. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From arohner at gmail.com Thu Mar 6 00:13:28 2008 From: arohner at gmail.com (Allen Rohner) Date: Wed, 5 Mar 2008 18:13:28 -0600 Subject: pungi doesn't run Message-ID: <480038420803051613t498b0b54i2db92f7489d07fb0@mail.gmail.com> On Wed, 2008-03-05 at 14:11 -0600, Allen Rohner wrote: >> %packages >> @base >> x86info >> postgresql-server >> python-sqlalchemy >> ruby >> ruby-irb >> rubygem-rails >> mod_python >> %end >> >> Running with the rawhide repository gives the exact same error. >This is a very small package set, you need at least a kernel, the >anaconda packages and a few other things. See the 'compose needs' >section on the shipped kickstart file. >Right now, pungi doesn't separate the "things we need to compose" from >"things we want in the compose" so you need to add those things into the > manifest. Thanks for the help. I'm able to get farther now. It doesn't really make sense to me why the list is the way it is. Is that truly the minimal set of packages? Why do we need iscsi-initiator-utils and vncserver to build a working ISO? This process would be significantly easier if the (true) minimum set of packages was documented somewhere, or even better, if pungi warned that you are missing packages X,Y,Z necessary to get a working build. I would offer to make a patch, but I don't know what the set is. Allen Rohner From jkeating at redhat.com Thu Mar 6 01:49:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 05 Mar 2008 20:49:46 -0500 Subject: pungi doesn't run In-Reply-To: <480038420803051613t498b0b54i2db92f7489d07fb0@mail.gmail.com> References: <480038420803051613t498b0b54i2db92f7489d07fb0@mail.gmail.com> Message-ID: <1204768186.4693.8.camel@localhost.localdomain> On Wed, 2008-03-05 at 18:13 -0600, Allen Rohner wrote: > Thanks for the help. I'm able to get farther now. It doesn't really > make sense to me why the list is the way it is. Is that truly the > minimal set of packages? Why do we need iscsi-initiator-utils and > vncserver to build a working ISO? This process would be significantly > easier if the (true) minimum set of packages was documented somewhere, > or even better, if pungi warned that you are missing packages X,Y,Z > necessary to get a working build. I would offer to make a patch, but I > don't know what the set is. That depends on if you want to install to iscsi, or support vnc installs. Again, because pungi doesn't split out what you need to compose the install media vs what you have as install choices on the media, the media can get a bit bloaty. I just haven't come up with a good way of expressing one vs the other. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Thu Mar 6 02:05:48 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Mar 2008 21:05:48 -0500 Subject: pungi doesn't run In-Reply-To: <1204768186.4693.8.camel@localhost.localdomain> References: <480038420803051613t498b0b54i2db92f7489d07fb0@mail.gmail.com> <1204768186.4693.8.camel@localhost.localdomain> Message-ID: <1204769148.10593.1.camel@aglarond.local> On Wed, 2008-03-05 at 20:49 -0500, Jesse Keating wrote: > On Wed, 2008-03-05 at 18:13 -0600, Allen Rohner wrote: > > Thanks for the help. I'm able to get farther now. It doesn't really > > make sense to me why the list is the way it is. Is that truly the > > minimal set of packages? Why do we need iscsi-initiator-utils and > > vncserver to build a working ISO? This process would be significantly > > easier if the (true) minimum set of packages was documented somewhere, > > or even better, if pungi warned that you are missing packages X,Y,Z > > necessary to get a working build. I would offer to make a patch, but I > > don't know what the set is. > > That depends on if you want to install to iscsi, or support vnc > installs. Again, because pungi doesn't split out what you need to > compose the install media vs what you have as install choices on the > media, the media can get a bit bloaty. I just haven't come up with a > good way of expressing one vs the other. One way might be to use the support that now exists in buildinstall to point at a repository. Then you could be running buildinstall against the repository you're pulling from and then your pungi'd tree would just have the packages you care about Jeremy From jkeating at j2solutions.net Thu Mar 6 02:39:46 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 05 Mar 2008 21:39:46 -0500 Subject: pungi doesn't run In-Reply-To: <1204769148.10593.1.camel@aglarond.local> References: <480038420803051613t498b0b54i2db92f7489d07fb0@mail.gmail.com> <1204768186.4693.8.camel@localhost.localdomain> <1204769148.10593.1.camel@aglarond.local> Message-ID: <1204771186.4693.15.camel@localhost.localdomain> On Wed, 2008-03-05 at 21:05 -0500, Jeremy Katz wrote: > > One way might be to use the support that now exists in buildinstall to > point at a repository. Then you could be running buildinstall against > the repository you're pulling from and then your pungi'd tree would just > have the packages you care about > Yes, that definitely needs some testing. I'm thinking post-f9 though. -- Jesse Keating RHCE (jkeating.livejournal.com) Fedora Project (fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Wed Mar 12 03:35:32 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 12 Mar 2008 09:05:32 +0530 Subject: 'make commit' in Makefile.common Message-ID: <3170f42f0803112035n1a6f7cedn6fab79c34ceb75f1@mail.gmail.com> There was a discussion on fedora-devel-list, where some of us agreed on having a 'commit' target in Makefile.common: https://www.redhat.com/archives/fedora-devel-list/2008-March/msg00896.html Here is the patch: http://rishi.fedorapeople.org/make-commit.patch to implement that. Comments? Happy hacking, Debarshi -- "From what we get, we can make a living; what we give, however, makes a life." -- Arthur Ashe From smooge at gmail.com Thu Mar 13 17:11:33 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 13 Mar 2008 11:11:33 -0600 Subject: mock 0.9 backport to F7/F8 -- Feb 1 In-Reply-To: References: Message-ID: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> On Fri, Jan 4, 2008 at 4:49 PM, wrote: > All mock users, > > The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. > > The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. > > The *only* difference between 0.8. and 0.9. at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. > Do any changes, fixes, etc need to be done for EPEL since they are basically F-3/F-6? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Thu Mar 13 18:04:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Mar 2008 14:04:21 -0400 Subject: mock 0.9 backport to F7/F8 -- Feb 1 In-Reply-To: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> References: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> Message-ID: <1205431461.10956.12.camel@localhost.localdomain> On Thu, 2008-03-13 at 11:11 -0600, Stephen John Smoogen wrote: > Do any changes, fixes, etc need to be done for EPEL since they are > basically F-3/F-6? We've been using 0.9.5 on the koji builders for a while now, with great success. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From Michael_E_Brown at dell.com Thu Mar 13 18:33:32 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 13 Mar 2008 13:33:32 -0500 Subject: mock 0.9 backport to F7/F8 -- Feb 1 In-Reply-To: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> References: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> Message-ID: <20080313183332.GC9067@humbolt.us.dell.com> On Thu, Mar 13, 2008 at 11:11:33AM -0600, Stephen John Smoogen wrote: > On Fri, Jan 4, 2008 at 4:49 PM, wrote: > > All mock users, > > > > The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. > > > > The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. > > > > The *only* difference between 0.8. and 0.9. at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. > > > > Do any changes, fixes, etc need to be done for EPEL since they are > basically F-3/F-6? We need to pull mock from EPEL 4, I havent put in the request for that yet. I am pretty sure that clark put in the update for epel5 to migrate it to the latest as well (since that is what is being used on the fedora build systems.) Clark? -- Michael From williams at redhat.com Thu Mar 13 19:24:50 2008 From: williams at redhat.com (Clark Williams) Date: Thu, 13 Mar 2008 14:24:50 -0500 Subject: mock 0.9 backport to F7/F8 -- Feb 1 In-Reply-To: <20080313183332.GC9067@humbolt.us.dell.com> References: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> <20080313183332.GC9067@humbolt.us.dell.com> Message-ID: <47D97F82.4070704@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Thu, Mar 13, 2008 at 11:11:33AM -0600, Stephen John Smoogen wrote: >> On Fri, Jan 4, 2008 at 4:49 PM, wrote: >>> All mock users, >>> >>> The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. >>> >>> The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. >>> >>> The *only* difference between 0.8. and 0.9. at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. >>> >> Do any changes, fixes, etc need to be done for EPEL since they are >> basically F-3/F-6? > > We need to pull mock from EPEL 4, I havent put in the request for that > yet. > > I am pretty sure that clark put in the update for epel5 to migrate it to > the latest as well (since that is what is being used on the fedora build > systems.) Clark? > -- > Michael > The only requests I see in bodhi are the f7/f8 ones; same in koji. I did not build or push E-4 or E-5. Sounds like we (we == I) need to do so? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfZf4IACgkQHyuj/+TTEp1SCgCg1zOFuCnvp/GABrp3DU8W7nuN FTUAn1ZidwAQMQt8WK1Fc+/9f9jRK4Qa =2Vbl -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Thu Mar 13 20:06:34 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 13 Mar 2008 15:06:34 -0500 Subject: mock 0.9 backport to F7/F8 -- Feb 1 In-Reply-To: <47D97F82.4070704@redhat.com> References: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> <20080313183332.GC9067@humbolt.us.dell.com> <47D97F82.4070704@redhat.com> Message-ID: <20080313200634.GD9067@humbolt.us.dell.com> On Thu, Mar 13, 2008 at 02:24:50PM -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael E Brown wrote: > > On Thu, Mar 13, 2008 at 11:11:33AM -0600, Stephen John Smoogen wrote: > >> On Fri, Jan 4, 2008 at 4:49 PM, wrote: > >>> All mock users, > >>> > >>> The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. > >>> > >>> The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. > >>> > >>> The *only* difference between 0.8. and 0.9. at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. > >>> > >> Do any changes, fixes, etc need to be done for EPEL since they are > >> basically F-3/F-6? > > > > We need to pull mock from EPEL 4, I havent put in the request for that > > yet. > > > > I am pretty sure that clark put in the update for epel5 to migrate it to > > the latest as well (since that is what is being used on the fedora build > > systems.) Clark? > > -- > > Michael > > > > The only requests I see in bodhi are the f7/f8 ones; same in koji. I did not build or > push E-4 or E-5. > > Sounds like we (we == I) need to do so? EPEL 5 doesnt use bhodi/koji, it uses plague. If you can push it, that would be great. If not, I still have the required client stuff installed to do an EPEL 5 push. -- Michael From williams at redhat.com Thu Mar 13 21:43:14 2008 From: williams at redhat.com (Clark Williams) Date: Thu, 13 Mar 2008 16:43:14 -0500 Subject: mock 0.9 backport to F7/F8 -- Feb 1 In-Reply-To: <20080313200634.GD9067@humbolt.us.dell.com> References: <80d7e4090803131011s54617474y98fc20cba323ba3@mail.gmail.com> <20080313183332.GC9067@humbolt.us.dell.com> <47D97F82.4070704@redhat.com> <20080313200634.GD9067@humbolt.us.dell.com> Message-ID: <47D99FF2.9020605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Thu, Mar 13, 2008 at 02:24:50PM -0500, Clark Williams wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Michael E Brown wrote: >>> On Thu, Mar 13, 2008 at 11:11:33AM -0600, Stephen John Smoogen wrote: >>>> On Fri, Jan 4, 2008 at 4:49 PM, wrote: >>>>> All mock users, >>>>> >>>>> The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. >>>>> >>>>> The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. >>>>> >>>>> The *only* difference between 0.8. and 0.9. at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. >>>>> >>>> Do any changes, fixes, etc need to be done for EPEL since they are >>>> basically F-3/F-6? >>> We need to pull mock from EPEL 4, I havent put in the request for that >>> yet. >>> >>> I am pretty sure that clark put in the update for epel5 to migrate it to >>> the latest as well (since that is what is being used on the fedora build >>> systems.) Clark? >>> -- >>> Michael >>> >> The only requests I see in bodhi are the f7/f8 ones; same in koji. I did not build or >> push E-4 or E-5. >> >> Sounds like we (we == I) need to do so? > > EPEL 5 doesnt use bhodi/koji, it uses plague. If you can push it, that > would be great. If not, I still have the required client stuff installed > to do an EPEL 5 push. > -- > Michael > Ugh, when we went to koji, I dropped that stuff like, well, the plague. If you still have it, please do a EPEL 5 push. I'll see about getting plague-client and whatever it needs back on my box so I can do them too. Sorry I dropped the ball on EPEL. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfZn/IACgkQHyuj/+TTEp1bAQCffYG2wTtXG7YVN9GAkp5xiWFo jY8AoNnwuRsbrTTJFYsyOr92M9X/J+YB =J+CJ -----END PGP SIGNATURE----- From mikeb at redhat.com Fri Mar 14 23:33:32 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Fri, 14 Mar 2008 19:33:32 -0400 Subject: Koji "hidden" packages proposal Message-ID: <1205537612.4505.5.camel@localhost.localdomain> I've written up a brief proposal about how "hidden" packages may be supported in Koji. The objective of this is to enable building EPEL packages in Koji. I wrote this up fairly quickly, and I'm sure I haven't thought through all the issues, but I wanted to get the ball rolling. Let me know if you have any questions/comments/ideas/issues relating to this proposal. http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html Thanks, Mike From dennis at ausil.us Sat Mar 15 00:55:37 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 14 Mar 2008 19:55:37 -0500 Subject: Koji "hidden" packages proposal In-Reply-To: <1205537612.4505.5.camel@localhost.localdomain> References: <1205537612.4505.5.camel@localhost.localdomain> Message-ID: <200803141955.46057.dennis@ausil.us> On Friday 14 March 2008, Mike Bonnet wrote: > I've written up a brief proposal about how "hidden" packages may be > supported in Koji. The objective of this is to enable building EPEL > packages in Koji. I wrote this up fairly quickly, and I'm sure I > haven't thought through all the issues, but I wanted to get the ball > rolling. Let me know if you have any questions/comments/ideas/issues > relating to this proposal. > > http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html > > Thanks, > Mike the tree will have to be nothing like /mnt/koji/packages instead it will have to be like http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use rsync and repo mirroring tools to sync the content and keep trees in sync. ill leave it up to Seth to explain more but hit micro repository option he is working on would allow us to pull the existing repodata intothe new repodata. We really only need to have a command that can suck the repodata into the database. so we know about the packages. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From smooge at gmail.com Sat Mar 15 01:17:33 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 14 Mar 2008 19:17:33 -0600 Subject: Koji "hidden" packages proposal In-Reply-To: <200803141955.46057.dennis@ausil.us> References: <1205537612.4505.5.camel@localhost.localdomain> <200803141955.46057.dennis@ausil.us> Message-ID: <80d7e4090803141817i36987968o288315af4a76abcf@mail.gmail.com> On Fri, Mar 14, 2008 at 6:55 PM, Dennis Gilmore wrote: > On Friday 14 March 2008, Mike Bonnet wrote: > > I've written up a brief proposal about how "hidden" packages may be > > supported in Koji. The objective of this is to enable building EPEL > > packages in Koji. I wrote this up fairly quickly, and I'm sure I > > haven't thought through all the issues, but I wanted to get the ball > > rolling. Let me know if you have any questions/comments/ideas/issues > > relating to this proposal. > > > > http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html > > > > Thanks, > > Mike > the tree will have to be nothing like /mnt/koji/packages > > instead it will have to be like > http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use > rsync and repo mirroring tools to sync the content and keep trees in sync. > ill leave it up to Seth to explain more but hit micro repository option he is > working on would allow us to pull the existing repodata intothe new repodata. > > We really only need to have a command that can suck the repodata into the > database. so we know about the packages. > Another big issue will be that EL is split in so many 'interesting' ways. You need to be able to either have the build system know of every seperate channels from RHN for each variation EL-3,4,5 or have RHN somehow give a conglomerate channel to you of all the packages in one big bucket. The code from DAG's mrepo sort of does this but would need some work on getting it to play nicely -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mikeb at redhat.com Sat Mar 15 23:10:21 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Sat, 15 Mar 2008 19:10:21 -0400 Subject: Koji "hidden" packages proposal In-Reply-To: <200803141955.46057.dennis@ausil.us> References: <1205537612.4505.5.camel@localhost.localdomain> <200803141955.46057.dennis@ausil.us> Message-ID: <1205622621.30584.4.camel@localhost.localdomain> On Fri, 2008-03-14 at 19:55 -0500, Dennis Gilmore wrote: > On Friday 14 March 2008, Mike Bonnet wrote: > > I've written up a brief proposal about how "hidden" packages may be > > supported in Koji. The objective of this is to enable building EPEL > > packages in Koji. I wrote this up fairly quickly, and I'm sure I > > haven't thought through all the issues, but I wanted to get the ball > > rolling. Let me know if you have any questions/comments/ideas/issues > > relating to this proposal. > > > > http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html > > > > Thanks, > > Mike > the tree will have to be nothing like /mnt/koji/packages > > instead it will have to be like > http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use > rsync and repo mirroring tools to sync the content and keep trees in sync. > ill leave it up to Seth to explain more but hit micro repository option he is > working on would allow us to pull the existing repodata intothe new repodata. I'm not really sure what you're talking about. *No one* will be mirroring the hidden packages in the case we're talking about (building EPEL in Koji), these will be RHEL binaries, and only available to the builders. > We really only need to have a command that can suck the repodata into the > database. so we know about the packages. We have a command that can suck data about packages in to the database. It's "koji import". The proposal is designed to work within the framework of that we already have in Koji, to try to minimize the number of changes and thus the time it'll take to implement. The micro repository option Seth has talked about sounds interesting, but it doesn't really help with the issue of making packages available to Koji builders without making them available to the world. From mikeb at redhat.com Sat Mar 15 23:13:03 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Sat, 15 Mar 2008 19:13:03 -0400 Subject: Koji "hidden" packages proposal In-Reply-To: <80d7e4090803141817i36987968o288315af4a76abcf@mail.gmail.com> References: <1205537612.4505.5.camel@localhost.localdomain> <200803141955.46057.dennis@ausil.us> <80d7e4090803141817i36987968o288315af4a76abcf@mail.gmail.com> Message-ID: <1205622783.30584.8.camel@localhost.localdomain> On Fri, 2008-03-14 at 19:17 -0600, Stephen John Smoogen wrote: > On Fri, Mar 14, 2008 at 6:55 PM, Dennis Gilmore wrote: > > On Friday 14 March 2008, Mike Bonnet wrote: > > > I've written up a brief proposal about how "hidden" packages may be > > > supported in Koji. The objective of this is to enable building EPEL > > > packages in Koji. I wrote this up fairly quickly, and I'm sure I > > > haven't thought through all the issues, but I wanted to get the ball > > > rolling. Let me know if you have any questions/comments/ideas/issues > > > relating to this proposal. > > > > > > http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html > > > > > > Thanks, > > > Mike > > the tree will have to be nothing like /mnt/koji/packages > > > > instead it will have to be like > > http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use > > rsync and repo mirroring tools to sync the content and keep trees in sync. > > ill leave it up to Seth to explain more but hit micro repository option he is > > working on would allow us to pull the existing repodata intothe new repodata. > > > > We really only need to have a command that can suck the repodata into the > > database. so we know about the packages. > > > > Another big issue will be that EL is split in so many 'interesting' > ways. You need to be able to either have the build system know of > every seperate channels from RHN for each variation EL-3,4,5 or have > RHN somehow give a conglomerate channel to you of all the packages in > one big bucket. The code from DAG's mrepo sort of does this but would > need some work on getting it to play nicely We're not going to be pulling packages straight from RHN, we'll be manually importing the packages. The proposal allows for multiple alternate directory trees, so it will be possible to have a tree to which we import the RHEL-4 binaries, a tree for RHEL-5 binaries, etc. When a new RHEL update is released, it'll be up to an admin to download the new packages and import them into the proper tree. From dennis at ausil.us Sun Mar 16 02:58:54 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 15 Mar 2008 21:58:54 -0500 Subject: Koji "hidden" packages proposal In-Reply-To: <1205622621.30584.4.camel@localhost.localdomain> References: <1205537612.4505.5.camel@localhost.localdomain> <200803141955.46057.dennis@ausil.us> <1205622621.30584.4.camel@localhost.localdomain> Message-ID: <200803152159.01327.dennis@ausil.us> On Saturday 15 March 2008, Mike Bonnet wrote: > On Fri, 2008-03-14 at 19:55 -0500, Dennis Gilmore wrote: > > On Friday 14 March 2008, Mike Bonnet wrote: > > > I've written up a brief proposal about how "hidden" packages may be > > > supported in Koji. The objective of this is to enable building EPEL > > > packages in Koji. I wrote this up fairly quickly, and I'm sure I > > > haven't thought through all the issues, but I wanted to get the ball > > > rolling. Let me know if you have any questions/comments/ideas/issues > > > relating to this proposal. > > > > > > http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html > > > > > > Thanks, > > > Mike > > > > the tree will have to be nothing like /mnt/koji/packages > > > > instead it will have to be like > > http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use > > rsync and repo mirroring tools to sync the content and keep trees in > > sync. ill leave it up to Seth to explain more but hit micro repository > > option he is working on would allow us to pull the existing repodata > > intothe new repodata. > > I'm not really sure what you're talking about. *No one* will be > mirroring the hidden packages in the case we're talking about (building > EPEL in Koji), these will be RHEL binaries, and only available to the > builders. What im talking about was the proposal put forward when we had the buildsys meeting the proposal that we all said sounded like the way to move forward. This is not that proposal. importing packages is the one thing that hurts koji from getting wider use outside of fedora. Some people will import the data. Most do not want to. Fedora will be mirroring RHEL content from RHN, people outside of fedora will be mirroring fedora and building on top of that. > > We really only need to have a command that can suck the repodata into the > > database. so we know about the packages. > > We have a command that can suck data about packages in to the database. > It's "koji import". The proposal is designed to work within the > framework of that we already have in Koji, to try to minimize the number > of changes and thus the time it'll take to implement. sure koji import --repodata --url=:///path/to/repodata > The micro repository option Seth has talked about sounds interesting, > but it doesn't really help with the issue of making packages available > to Koji builders without making them available to the world. sure it does, we have an internal only tree thats on the phx internal network and not available outside of phx, just as we do now. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Mon Mar 17 14:13:04 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Mar 2008 10:13:04 -0400 Subject: Koji "hidden" packages proposal In-Reply-To: <200803152159.01327.dennis@ausil.us> References: <1205537612.4505.5.camel@localhost.localdomain> <200803141955.46057.dennis@ausil.us> <1205622621.30584.4.camel@localhost.localdomain> <200803152159.01327.dennis@ausil.us> Message-ID: <1205763184.30540.18.camel@cutter> On Sat, 2008-03-15 at 21:58 -0500, Dennis Gilmore wrote: > What im talking about was the proposal put forward when we had the buildsys > meeting the proposal that we all said sounded like the way to move forward. > This is not that proposal. importing packages is the one thing that hurts > koji from getting wider use outside of fedora. Some people will import the > data. Most do not want to. Fedora will be mirroring RHEL content from RHN, > people outside of fedora will be mirroring fedora and building on top of > that. > I'm not sure I see the problem here, necessarily. okay here's how I see what Mike's proposal does and then what we eventually want to do: Mike's Proposal: - gives us a way of building from the reposync'd rhel-trees that we now have on puppet1 w/o distributing these pkgs out to the world. Yay - gives us a way of building epel in koji so we can finally disable plague, also yay. The eventual future: - have a way of koji to build from an arbitrary set of remote repos by: 1. syncing down the repodata from those remote repos and 'faking' an import 2. creating its own local repo out of the remote repos (or micro-repos) for external use. There's nothing mutually exclusive about these two items and, afaict, there's no requirement that they be done at the same time, either. I guess in short: - Dennis: I think your suggestion is one we should do but we do not require it immediately. - Mike: The proposal sounds round enough to me. We've already got all of the production repos(no betas) in rhn for rhel4 and 5 for i386, x86_64 and ppc* synced over on puppet1. They resync every night. Is there anything else you need that I missed? -sv From mikem at redhat.com Mon Mar 17 16:11:22 2008 From: mikem at redhat.com (Mike McLean) Date: Mon, 17 Mar 2008 12:11:22 -0400 Subject: Koji "hidden" packages proposal In-Reply-To: <200803152159.01327.dennis@ausil.us> References: <1205537612.4505.5.camel@localhost.localdomain> <200803141955.46057.dennis@ausil.us> <1205622621.30584.4.camel@localhost.localdomain> <200803152159.01327.dennis@ausil.us> Message-ID: <47DE982A.5050408@redhat.com> Dennis Gilmore wrote: > What im talking about was the proposal put forward when we had the buildsys > meeting the proposal that we all said sounded like the way to move forward. > This is not that proposal. importing packages is the one thing that hurts > koji from getting wider use outside of fedora. Some people will import the > data. Most do not want to. Fedora will be mirroring RHEL content from RHN, > people outside of fedora will be mirroring fedora and building on top of > that. All that was really concluded at the meeting was that Mike and/or I would create a proposal. As I said in that meeting there are basically two approaches: import and hide or find a sane way to use external repos. Mike's proposal is the former. From smooge at gmail.com Thu Mar 20 22:08:12 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 20 Mar 2008 16:08:12 -0600 Subject: Koji "hidden" packages proposal In-Reply-To: <1205537612.4505.5.camel@localhost.localdomain> References: <1205537612.4505.5.camel@localhost.localdomain> Message-ID: <80d7e4090803201508o14360250rf050bf241f8662d2@mail.gmail.com> On Fri, Mar 14, 2008 at 5:33 PM, Mike Bonnet wrote: > I've written up a brief proposal about how "hidden" packages may be > supported in Koji. The objective of this is to enable building EPEL > packages in Koji. I wrote this up fairly quickly, and I'm sure I > haven't thought through all the issues, but I wanted to get the ball > rolling. Let me know if you have any questions/comments/ideas/issues > relating to this proposal. > > http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html > > Thanks, > Mike What can I do to help on this? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"