From pmeyer at themeyerfarm.com Fri Jun 1 23:23:53 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Fri, 01 Jun 2007 17:23:53 -0600 Subject: F7 pungi-0.3.5-1.fc7 version == Null Message-ID: <4660AA89.2040903@themeyerfarm.com> For some reason pungi is setting version to Null. See this tcpdump: HTTP GET /mirrorlist?repo=fedora-Null&arch=i386 HTTP/1.1 I have been through the code and config files and cannot spot where its coming from. Any ideas? I have added $releasever=7 to all the yum entries without any change. I have added version = "7" to the config file with no change. I have forced version = "7" at the near top of /usr/bin/pungi with no change. yum from the command line works like a charm. I have even specified /etc/yum.conf in my config to no avail. Puzzler! Thanks From pmeyer at themeyerfarm.com Fri Jun 1 23:30:24 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Fri, 01 Jun 2007 17:30:24 -0600 Subject: F7 pungi-0.3.5-1.fc7 version == Null In-Reply-To: <4660AA89.2040903@themeyerfarm.com> References: <4660AA89.2040903@themeyerfarm.com> Message-ID: <4660AC10.20705@themeyerfarm.com> Phil Meyer wrote: > > For some reason pungi is setting version to Null. > > See this tcpdump: > > HTTP GET /mirrorlist?repo=fedora-Null&arch=i386 HTTP/1.1 > > I have been through the code and config files and cannot spot where > its coming from. > > Any ideas? > > I have added $releasever=7 to all the yum entries without any change. > I have added version = "7" to the config file with no change. > I have forced version = "7" at the near top of /usr/bin/pungi with no > change. > > yum from the command line works like a charm. I have even specified > /etc/yum.conf in my config to no avail. > > Puzzler! > > Thanks > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Answering a bit of the puzzle myself: Creating a repo listing file with all variables expanded worked. Therefore, pungi is not properly expanding the $version variable for yum. pungi DOES properly expand $basearch, so this must be a little bug. Looking ... Thanks! From jkeating at redhat.com Fri Jun 1 23:42:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 19:42:45 -0400 Subject: F7 pungi-0.3.5-1.fc7 version == Null In-Reply-To: <4660AC10.20705@themeyerfarm.com> References: <4660AA89.2040903@themeyerfarm.com> <4660AC10.20705@themeyerfarm.com> Message-ID: <200706011942.49006.jkeating@redhat.com> On Friday 01 June 2007 19:30:24 Phil Meyer wrote: > Answering a bit of the puzzle myself: > > Creating a repo listing file with all variables expanded worked. > > Therefore, pungi is not properly expanding the $version variable for yum. > > pungi DOES properly expand $basearch, so this must be a little bug. ? > Looking ... $version comes from fedora-release. But I'm thinking that this is a bad idea to rely upon variable expansion in the repo files, much like mock doesn't. Something to look at next week. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From distro at getsmart.com.br Tue Jun 5 14:48:13 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Tue, 05 Jun 2007 11:48:13 -0300 Subject: Customizing Fedora 7 with revisor Message-ID: <466577AD.3090205@getsmart.com.br> Hi all, I'm new to this list! I'm having problems with revisor tool. It runs until the linking release notes an then stop work. The log did not show anything and only half of the packages goes to the temp iso dir. Doesn any body could help me with it, or tell me where should I look for more information! Thanks everybody! From jgranado at redhat.com Tue Jun 5 16:08:26 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 05 Jun 2007 18:08:26 +0200 Subject: Customizing Fedora 7 with revisor In-Reply-To: <466577AD.3090205@getsmart.com.br> References: <466577AD.3090205@getsmart.com.br> Message-ID: <46658A7A.2030606@redhat.com> Francisco Andr? wrote: > Hi all, I'm new to this list! > > I'm having problems with revisor tool. It runs until the linking > release notes an then stop work. The log did not show anything and > only half of the packages goes to the temp iso dir. > > Doesn any body could help me with it, or tell me where should I look > for more information! > > Thanks everybody! > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Hey Francisco Andr?: To tell you the truth I haven't looked at revisor for a long time, but it has its own discussion list where you might be able to find help "revisor-devel at fedoraunity.org". Another option would be to use pungi directly to make your distro. Its command line based but I have found it very easy to use :) Regards -- Joel Andres Granados From jgranado at redhat.com Tue Jun 5 17:27:16 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 05 Jun 2007 19:27:16 +0200 Subject: Pungis work directory. In-Reply-To: <464B3DEC.1090200@redhat.com> References: <461F86F4.5000903@redhat.com> <200705151418.32588.jkeating@redhat.com> <464AC224.4040600@redhat.com> <464B3DEC.1090200@redhat.com> Message-ID: <46659CF4.4040905@redhat.com> > > I tested to see what would happen with each if the options (-G -B -P > -S -I) and I found out that on G,B and I tracedback, in the other > options it didn't. When I tested again (I don't know why I tested two > times), I found that the tracebacks where different in G, B and I. So > basically the trace backs depend on the state of the directory. If > the directory is in one state the traceback happens in one line, if it > is in another state it has the possibility of occurring in another. > So I thought that the best way to fix it would be to check for the > existence of the directory in every directory creation, so I looked > for every occurrence of "os.makedirs": > > /usr/lib/python2.5/site-packages/pypungi/gather.py:64: > os.makedirs(logdir) > /usr/lib/python2.5/site-packages/pypungi/gather.py:275: > os.makedirs(pkgdir) > /usr/lib/python2.5/site-packages/pypungi/gather.py:342: > os.makedirs(pkgdir) > /usr/lib/python2.5/site-packages/pypungi/pungi.py:45: > os.makedirs(self.workdir) > /usr/lib/python2.5/site-packages/pypungi/pungi.py:165: > os.makedirs(docsdir) > /usr/lib/python2.5/site-packages/pypungi/pungi.py:263: > os.makedirs("%s-disc%d/SRPMS" % (timber.dist_dir, i)) > /usr/lib/python2.5/site-packages/pypungi/pungi.py:293: > os.makedirs('%s-disc1' % self.topdir) > /usr/lib/python2.5/site-packages/pypungi/pungi.py:320: > os.makedirs(self.isodir) > /usr/bin/pungi:90: os.makedirs(destdir) > /usr/bin/pungi:99: os.makedirs(cachedir) > Actually more lines must be changed. All the shutils lines that create a directory in one way or another have the potential to traceback with the "directory already exists" message. > I just don't like it... IMO its just not right to check for the > existence of the directory in every line!!! > > So I take what I said in my last post back, and am sticking with the > "create a new root directory for each execution" solution. I changed > it a little. Instead of using time.time(), I used time.localtime()'s > elements. So now the directory would be something like > "/srv/pungi/Fedora/2007-5-16-1430/..." IMO it looks much better than > what time.time() spits out. Considering the state of pungi in which it is separated by stages this ^^^^^ solution is not really very useful :(. An option in which the user selects the name of the tree he wants to use is needed (not pretty). Came up with another solution that until now has pretty much solved the problem and has not broken pungi (in my tests). The solutions simply clears any directory that pungi is going to create. So for each line in which a directory is created I added a line to erase it. The diff is attached. Regards. -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffD URL: From distro at getsmart.com.br Tue Jun 5 17:39:05 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Tue, 05 Jun 2007 14:39:05 -0300 Subject: Customizing Fedora 7 with revisor In-Reply-To: <46658A7A.2030606@redhat.com> References: <466577AD.3090205@getsmart.com.br> <46658A7A.2030606@redhat.com> Message-ID: <46659FB9.7050801@getsmart.com.br> Joel Andres Granados wrote: > Francisco Andr? wrote: >> Hi all, I'm new to this list! >> >> I'm having problems with revisor tool. It runs until the linking >> release notes an then stop work. The log did not show anything and >> only half of the packages goes to the temp iso dir. >> >> Doesn any body could help me with it, or tell me where should I look >> for more information! >> >> Thanks everybody! >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > Hey Francisco Andr?: > To tell you the truth I haven't looked at revisor for a long time, but > it has its own discussion list where you might be able to find help > "revisor-devel at fedoraunity.org". Another option would be to use > pungi directly to make your distro. Its command line based but I have > found it very easy to use :) > > Regards > Thank for you attention, now Ie found the pungi docs that I need and I've already started to use pungi in the command line. Anyway I will subscribe to the revisor list. Thanks! From distro at getsmart.com.br Tue Jun 5 18:47:39 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Tue, 05 Jun 2007 15:47:39 -0300 Subject: Customizing Fedora 7 with revisor In-Reply-To: <46658A7A.2030606@redhat.com> References: <466577AD.3090205@getsmart.com.br> <46658A7A.2030606@redhat.com> Message-ID: <4665AFCB.60105@getsmart.com.br> Hi again, I'm using pungi in command line and after some problems with missing python libs I can run all the steps of pungi until when I try to generate the iso image the erros is the following [root at ccblinux conf.d]# pungi -I -c pungi-ccb.conf No handlers could be found for logger "pypungi.pungi" Traceback (most recent call last): File "/usr/bin/pungi", line 187, in main() File "/usr/bin/pungi", line 126, in main mypungi.doCreateIsos() File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 432, in doCreateIsos self._doRunCommand(mkisofs + extraargs) File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 77, in _doRunCommand raise OSError, "Got an error from %s" % command[0] OSError: Got an error from /usr/bin/mkisofs I've found on the net that it maybe related to the label of the disc that can't bo more than 32 chars long, I've tried to get the pungi.py source code on the page and run but the problem persists. Does anyone knows what is this problem related?? Thanks Joel Andres Granados wrote: > Francisco Andr? wrote: >> Hi all, I'm new to this list! >> >> I'm having problems with revisor tool. It runs until the linking >> release notes an then stop work. The log did not show anything and >> only half of the packages goes to the temp iso dir. >> >> Doesn any body could help me with it, or tell me where should I look >> for more information! >> >> Thanks everybody! >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > Hey Francisco Andr?: > To tell you the truth I haven't looked at revisor for a long time, but > it has its own discussion list where you might be able to find help > "revisor-devel at fedoraunity.org". Another option would be to use > pungi directly to make your distro. Its command line based but I have > found it very easy to use :) > > Regards > From jgranado at redhat.com Wed Jun 6 07:41:48 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Wed, 06 Jun 2007 09:41:48 +0200 Subject: Customizing Fedora 7 with revisor In-Reply-To: <4665AFCB.60105@getsmart.com.br> References: <466577AD.3090205@getsmart.com.br> <46658A7A.2030606@redhat.com> <4665AFCB.60105@getsmart.com.br> Message-ID: <4666653C.7090509@redhat.com> Francisco Andr? wrote: > Hi again, I'm using pungi in command line and after some problems with > missing python libs I can run all the steps of pungi until when I try > to generate the iso image the erros is the following > > [root at ccblinux conf.d]# pungi -I -c pungi-ccb.conf > No handlers could be found for logger "pypungi.pungi" > Traceback (most recent call last): > File "/usr/bin/pungi", line 187, in > main() > File "/usr/bin/pungi", line 126, in main > mypungi.doCreateIsos() > File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 432, > in doCreateIsos > self._doRunCommand(mkisofs + extraargs) > File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 77, in > _doRunCommand > raise OSError, "Got an error from %s" % command[0] > OSError: Got an error from /usr/bin/mkisofs > > I've found on the net that it maybe related to the label of the disc > that can't bo more than 32 chars long, I've tried to get the pungi.py > source code on the page and run but the problem persists. Does anyone > knows what is this problem related?? > > Thanks Hey Francisco Andr?: 1. What does `rpm -q pungi` return ? 2. There is a situation with the CD label in pungi. The easy solution is to use short labels for the product_name, version and arch. More specifically the number of characters of all the labels (added up) must not exceed 23 characters (methinks). 3. Send whatever the log spit out. Its usually in /srv/pungi/f7/logs/Fedora.x86_64.log Regards -- Joel Andres Granados From kanarip at kanarip.com Wed Jun 6 09:16:25 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 06 Jun 2007 11:16:25 +0200 Subject: Customizing Fedora 7 with pungi In-Reply-To: <4666653C.7090509@redhat.com> References: <466577AD.3090205@getsmart.com.br> <46658A7A.2030606@redhat.com> <4665AFCB.60105@getsmart.com.br> <4666653C.7090509@redhat.com> Message-ID: <46667B69.2070907@kanarip.com> I'm sorry but this is about pungi, not revisor, right? Kind regards, Jeroen van Meeuwen -kanarip Joel Andres Granados wrote: > Francisco Andr? wrote: >> Hi again, I'm using pungi in command line and after some problems with >> missing python libs I can run all the steps of pungi until when I try >> to generate the iso image the erros is the following >> >> [root at ccblinux conf.d]# pungi -I -c pungi-ccb.conf >> No handlers could be found for logger "pypungi.pungi" >> Traceback (most recent call last): >> File "/usr/bin/pungi", line 187, in >> main() >> File "/usr/bin/pungi", line 126, in main >> mypungi.doCreateIsos() >> File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 432, >> in doCreateIsos >> self._doRunCommand(mkisofs + extraargs) >> File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 77, in >> _doRunCommand >> raise OSError, "Got an error from %s" % command[0] >> OSError: Got an error from /usr/bin/mkisofs >> >> I've found on the net that it maybe related to the label of the disc >> that can't bo more than 32 chars long, I've tried to get the pungi.py >> source code on the page and run but the problem persists. Does anyone >> knows what is this problem related?? >> >> Thanks > Hey Francisco Andr?: > > 1. What does `rpm -q pungi` return ? > 2. There is a situation with the CD label in pungi. The easy solution > is to use short labels for the product_name, version and arch. More > specifically the number of characters of all the labels (added up) must > not exceed 23 characters (methinks). > 3. Send whatever the log spit out. Its usually in > /srv/pungi/f7/logs/Fedora.x86_64.log > > Regards > From orion at cora.nwra.com Wed Jun 6 22:23:17 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jun 2007 16:23:17 -0600 Subject: Trying to exclude kernel-PAE from spin Message-ID: <466733D5.8090809@cora.nwra.com> Various packages appear to be picking up kernel-PAE for reasons beyond me: DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 to require for kernel DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - 2.6.21-1.3194.fc7.i686 to require for kernel INFO:yum.verbose.pungi:Added kernel-PAE.i686 for vpnc.i386 INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for vpnc.i386 DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 to require for kernel-drm-nouveau DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - 2.6.21-1.3194.fc7.i686 to require for kernel-drm-nouveau INFO:yum.verbose.pungi:Added kernel-PAE.i686 for xorg-x11-drv-nouveau.i386 INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for xorg-x11-drv-nouveau.i386 DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 to require for kernel DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - 2.6.21-1.3194.fc7.i686 to require for kernel INFO:yum.verbose.pungi:Added kernel-PAE.i686 for libraw1394.i386 INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for libraw1394.i386 DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 to require for kernel DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - 2.6.21-1.3194.fc7.i686 to require for kernel INFO:yum.verbose.pungi:Added kernel-PAE.i686 for fuse.i386 INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for fuse.i386 INFO:yum.verbose.pungi:Checking deps of kernel-PAE.i686 INFO:yum.verbose.pungi:Checking deps of kernel-PAE-debug.i686 I ended up excluding them with the following in the manifest: -kernel-PAE -kernel-PAE-debug Now it's pulling in kernel-debug for some reason: DEBUG:yum.verbose.YumBase:Matched kernel-debug - 2.6.21-1.3194.fc7.i686 to require for kernel INFO:yum.verbose.pungi:Added kernel-debug.i686 for vpnc.i386 # rpm -q --requires -p releases/7/Everything/i386/os/Fedora/vpnc-0.4.0-2.fc7.i386.rpm /bin/sh /usr/bin/perl config(vpnc) = 0.4.0-2.fc7 kernel >= 2.4 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libgcrypt.so.11 libgcrypt.so.11(GCRYPT_1.2) libgpg-error.so.0 perl(IO::File) perl(strict) perl(warnings) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) why kernel-PAE or kernel-debug rather than just kernel? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jgranado at redhat.com Thu Jun 7 07:46:16 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 07 Jun 2007 09:46:16 +0200 Subject: Trying to exclude kernel-PAE from spin In-Reply-To: <466733D5.8090809@cora.nwra.com> References: <466733D5.8090809@cora.nwra.com> Message-ID: <4667B7C8.8080105@redhat.com> Orion Poplawski wrote: > Various packages appear to be picking up kernel-PAE for reasons beyond > me: > > DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 > to require for kernel > DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - > 2.6.21-1.3194.fc7.i686 to require for kernel > INFO:yum.verbose.pungi:Added kernel-PAE.i686 for vpnc.i386 > INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for vpnc.i386 > DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 > to require for kernel-drm-nouveau > DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - > 2.6.21-1.3194.fc7.i686 to require for kernel-drm-nouveau > INFO:yum.verbose.pungi:Added kernel-PAE.i686 for > xorg-x11-drv-nouveau.i386 > INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for > xorg-x11-drv-nouveau.i386 > DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 > to require for kernel > DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - > 2.6.21-1.3194.fc7.i686 to require for kernel > INFO:yum.verbose.pungi:Added kernel-PAE.i686 for libraw1394.i386 > INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for libraw1394.i386 > DEBUG:yum.verbose.YumBase:Matched kernel-PAE - 2.6.21-1.3194.fc7.i686 > to require for kernel > DEBUG:yum.verbose.YumBase:Matched kernel-PAE-debug - > 2.6.21-1.3194.fc7.i686 to require for kernel > INFO:yum.verbose.pungi:Added kernel-PAE.i686 for fuse.i386 > INFO:yum.verbose.pungi:Added kernel-PAE-debug.i686 for fuse.i386 > INFO:yum.verbose.pungi:Checking deps of kernel-PAE.i686 > INFO:yum.verbose.pungi:Checking deps of kernel-PAE-debug.i686 > > I ended up excluding them with the following in the manifest: > > -kernel-PAE > -kernel-PAE-debug > > Now it's pulling in kernel-debug for some reason: > > DEBUG:yum.verbose.YumBase:Matched kernel-debug - > 2.6.21-1.3194.fc7.i686 to require for kernel > INFO:yum.verbose.pungi:Added kernel-debug.i686 for vpnc.i386 > > # rpm -q --requires -p > releases/7/Everything/i386/os/Fedora/vpnc-0.4.0-2.fc7.i386.rpm > /bin/sh > /usr/bin/perl > config(vpnc) = 0.4.0-2.fc7 > kernel >= 2.4 > libc.so.6 > libc.so.6(GLIBC_2.0) > libc.so.6(GLIBC_2.1) > libc.so.6(GLIBC_2.1.3) > libc.so.6(GLIBC_2.3.4) > libc.so.6(GLIBC_2.4) > libgcrypt.so.11 > libgcrypt.so.11(GCRYPT_1.2) > libgpg-error.so.0 > perl(IO::File) > perl(strict) > perl(warnings) > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > rtld(GNU_HASH) > > why kernel-PAE or kernel-debug rather than just kernel? > Hey Orion: Can you post your manifest and the log file. I have no idea where the bug is, but would like to sniff it out. Regards -- Joel Andres Granados From jkeating at redhat.com Thu Jun 7 11:17:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 07:17:01 -0400 Subject: Trying to exclude kernel-PAE from spin In-Reply-To: <466733D5.8090809@cora.nwra.com> References: <466733D5.8090809@cora.nwra.com> Message-ID: <200706070717.01531.jkeating@redhat.com> On Wednesday 06 June 2007 18:23:17 Orion Poplawski wrote: > why kernel-PAE or kernel-debug rather than just kernel? Ugh. So kernel-PAE provides 'kernel', to satisfy some deps if that's the only kernel you have. In pungi land I don't know what kernel you're going to want (i586, i686, whatever) so when asked for a dep or package I bring in _all_ possible resolvers, and leave it up to install time to suss out which is the "best" resolver for that particular install. The bummer here is that it seems that kernel-debug and kernel-PAE-debug /also/ provide kernel, since these are debugging kernels that seems right, although unfortunate. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From distro at getsmart.com.br Thu Jun 7 21:17:25 2007 From: distro at getsmart.com.br (Francisco =?ISO-8859-1?Q?Andr=E9?= Barbosa Neto) Date: Thu, 07 Jun 2007 18:17:25 -0300 Subject: Customizing Fedora 7 with pungi In-Reply-To: <46667B69.2070907@kanarip.com> References: <466577AD.3090205@getsmart.com.br> <46658A7A.2030606@redhat.com> <4665AFCB.60105@getsmart.com.br> <4666653C.7090509@redhat.com> <46667B69.2070907@kanarip.com> Message-ID: <1181251045.4837.0.camel@ccblinux.getsmart.local> Yes, it's a pungi problem! Qua, 2007-06-06 ?s 11:16 +0200, Jeroen van Meeuwen escreveu: > I'm sorry but this is about pungi, not revisor, right? > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > Joel Andres Granados wrote: > > Francisco Andr? wrote: > >> Hi again, I'm using pungi in command line and after some problems with > >> missing python libs I can run all the steps of pungi until when I try > >> to generate the iso image the erros is the following > >> > >> [root at ccblinux conf.d]# pungi -I -c pungi-ccb.conf > >> No handlers could be found for logger "pypungi.pungi" > >> Traceback (most recent call last): > >> File "/usr/bin/pungi", line 187, in > >> main() > >> File "/usr/bin/pungi", line 126, in main > >> mypungi.doCreateIsos() > >> File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 432, > >> in doCreateIsos > >> self._doRunCommand(mkisofs + extraargs) > >> File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 77, in > >> _doRunCommand > >> raise OSError, "Got an error from %s" % command[0] > >> OSError: Got an error from /usr/bin/mkisofs > >> > >> I've found on the net that it maybe related to the label of the disc > >> that can't bo more than 32 chars long, I've tried to get the pungi.py > >> source code on the page and run but the problem persists. Does anyone > >> knows what is this problem related?? > >> > >> Thanks > > Hey Francisco Andr?: > > > > 1. What does `rpm -q pungi` return ? > > 2. There is a situation with the CD label in pungi. The easy solution > > is to use short labels for the product_name, version and arch. More > > specifically the number of characters of all the labels (added up) must > > not exceed 23 characters (methinks). > > 3. Send whatever the log spit out. Its usually in > > /srv/pungi/f7/logs/Fedora.x86_64.log > > > > Regards > > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jgranado at redhat.com Fri Jun 8 17:49:54 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 08 Jun 2007 19:49:54 +0200 Subject: Source file not found Message-ID: <466996C2.4010004@redhat.com> Hi list: Been trying to use pungi with the source=yes option and it fails when it begins to look for the source in the repos. 1. I tried updating my distro 2. I installed a clean f7 3. I have changed yum repos more than once. But still pungi fails when looking for sources. I believe the issue is in "pypungi/gather.py" in the downloadSRPMs function. I'm now looking at the yum code to see if it has something to do. Is anybody else experiencing this. am I missing something. Regards. -- Joel Andres Granados From jkeating at redhat.com Fri Jun 8 17:55:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 13:55:31 -0400 Subject: Source file not found In-Reply-To: <466996C2.4010004@redhat.com> References: <466996C2.4010004@redhat.com> Message-ID: <200706081355.31900.jkeating@redhat.com> On Friday 08 June 2007 13:49:54 Joel Andres Granados wrote: > Been trying to use pungi with the source=yes option and it fails when it > begins to look for the source in the repos. > 1. I tried updating my distro > 2. I installed a clean f7 > 3. I have changed yum repos more than once. > > But still pungi fails when looking for sources. > I believe the issue is in "pypungi/gather.py" in the downloadSRPMs > function. ?I'm now looking at the yum code to see if it has something to > do. > > Is anybody else experiencing this. > am I missing something. Can you attach or somehow forward the log snippit? (and your repo configs?) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 18:25:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 14:25:16 -0400 Subject: pungi logger In-Reply-To: <200705151420.29361.jkeating@redhat.com> References: <463B3F8E.2000209@redhat.com> <200705151420.29361.jkeating@redhat.com> Message-ID: <200706081425.16776.jkeating@redhat.com> On Tuesday 15 May 2007 14:20:29 Jesse Keating wrote: > On Friday 04 May 2007 10:13:34 Joel Andres Granados wrote: > > Referring to ticket #34 at > > https://hosted.fedoraproject.org/projects/pungi/ticket/34 stating that > > the logger needed a little work so that it didn't depend on the > > gather.py (or at least thats what I understood :) ?I propose either a > > new file (pungiLog.py) located in the pypungi directory or a new > > function in the "pungi" file that contains the logging stuff. ?The log > > services would be started somewhere before the line containing "# > > Actually do work." of the "pungi" file. ?The logging root would be > > called "pungi" and would be called in each file that logging is needed > > with the logging.getlogger("pungi") command. > > If "quiet" is specified in the config file the logging will be turned > > off. > > > > *Diff for the pungi file:* > > 1. Initializes the logger by calling to the new file. > > 2. specify quiet value. > > 3. ?logging function. > > * > > Diff for pungi.py file: > > *1. use the correct logger. > > * > > Diff for gather.py file:* > > change all the if statements for each logging call. > > > > Files attached... > > Comments appreciated. > > Thanks for this. I think this is the right direction. However I'm > reluctant to make such a change this late in Fedora 7 development. I'll > want to look at this once I start doing Fedora 8 changes. I just looked at this again and I don't think it'll quite work. The thing is I want logging to work if somebody just imported pypungi and started using commands. Maybe that's not possible, maybe it is. Something to look into. I think I can have a pypungi.logger module/class that has some reasonable defaults that can be overridden if the config file is used, or if say /usr/bin/pungi is envoked, but would work otherwise. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Mon Jun 11 08:00:25 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Mon, 11 Jun 2007 10:00:25 +0200 Subject: Source file not found In-Reply-To: <200706081355.31900.jkeating@redhat.com> References: <466996C2.4010004@redhat.com> <200706081355.31900.jkeating@redhat.com> Message-ID: <466D0119.2030107@redhat.com> Jesse Keating wrote: > On Friday 08 June 2007 13:49:54 Joel Andres Granados wrote: > >> Been trying to use pungi with the source=yes option and it fails when it >> begins to look for the source in the repos. >> 1. I tried updating my distro >> 2. I installed a clean f7 >> 3. I have changed yum repos more than once. >> >> But still pungi fails when looking for sources. >> I believe the issue is in "pypungi/gather.py" in the downloadSRPMs >> function. I'm now looking at the yum code to see if it has something to >> do. >> >> Is anybody else experiencing this. >> am I missing something. >> > > Can you attach or somehow forward the log snippit? (and your repo configs?) > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Attached are the log file and the config file that I used. I invoked pungi with `pungi -c /etc/pungi/f7.fedora.x86_64`. At the Command line the error output is "Error: Cannot find a source rpm for ORBit2-2.14.7-3.fc7". The minimal manifest that I use is the one that comes with the pungi package. Im also attaching the repo configs for pungi. I zipped the log file so the mailing list accepts it. Thx for the help. -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: f7-fedora.x86_64 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: yum.conf.f7.x86_64 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fedora.x86_64.log.bz2 Type: application/x-bzip Size: 23540 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 11 12:23:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 08:23:38 -0400 Subject: Source file not found In-Reply-To: <466D0119.2030107@redhat.com> References: <466996C2.4010004@redhat.com> <200706081355.31900.jkeating@redhat.com> <466D0119.2030107@redhat.com> Message-ID: <200706110823.41291.jkeating@redhat.com> On Monday 11 June 2007 04:00:25 Joel Andres Granados wrote: > [fedora-source] > name=Fedora 7 - Source > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Ever >ything/source/SRPMS/ > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-source-7 >&arch=x86_64 enabled=0 > gpgcheck=0 Change the enabled=0 to enabled=1 in the source repo. I may have typoed the repo config files. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From distro at getsmart.com.br Mon Jun 11 13:03:49 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Mon, 11 Jun 2007 10:03:49 -0300 Subject: Grub install error when the installation Finish Message-ID: <466D4835.3020202@getsmart.com.br> Hi! It's me again! I use pungi to create a custom fedora and it runs perfectly even the iso images was created ok! So I burn 2 CD and try to install in a new machine. It runs ok, load and use all the ks.cfg values and the kickstart installation was good. But when the system show the message that are installing the boot manager to the disk it stop and in the console window it shows the following error: executil.py line 81 in execWithRedirect bootloader.py lines 958, 1199 e 190 dispatch.py line 203 text.py line 605 anaconda line 955 Errno - File or directory not found I noticed that it seems that the script are looking for grub in the folder /sbin/grub but it is on the folder /usr/sbin/grub. I don't know if it's the problem, but for this time this is the maximum debug that I can get and show to you ok! Thank's for all! From jkeating at redhat.com Mon Jun 11 13:03:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 09:03:49 -0400 Subject: Grub install error when the installation Finish In-Reply-To: <466D4835.3020202@getsmart.com.br> References: <466D4835.3020202@getsmart.com.br> Message-ID: <200706110903.50155.jkeating@redhat.com> On Monday 11 June 2007 09:03:49 Francisco Andr? wrote: > I noticed that it seems that the script are looking for grub in the > folder /sbin/grub but it is on the folder /usr/sbin/grub. I don't know > if it's the problem, but for this time this is the maximum debug that I > can get and show to you ok! Make sure that grub is in your manifest. The kernel doesn't have a direct requires on it as different boot loaders can be used. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Mon Jun 11 13:13:44 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Mon, 11 Jun 2007 15:13:44 +0200 Subject: Source file not found In-Reply-To: <200706110823.41291.jkeating@redhat.com> References: <466996C2.4010004@redhat.com> <200706081355.31900.jkeating@redhat.com> <466D0119.2030107@redhat.com> <200706110823.41291.jkeating@redhat.com> Message-ID: <466D4A88.2010202@redhat.com> Jesse Keating wrote: > On Monday 11 June 2007 04:00:25 Joel Andres Granados wrote: > >> [fedora-source] >> name=Fedora 7 - Source >> #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Ever >> ything/source/SRPMS/ >> mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-source-7 >> &arch=x86_64 enabled=0 >> gpgcheck=0 >> > > Change the enabled=0 to enabled=1 in the source repo. I may have typoed the > repo config files. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Yes. This seems to fix the problem. Thx Jesse. -- Joel Andres Granados From distro at getsmart.com.br Mon Jun 11 14:25:58 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Mon, 11 Jun 2007 11:25:58 -0300 Subject: Grub install error when the installation Finish In-Reply-To: <200706110903.50155.jkeating@redhat.com> References: <466D4835.3020202@getsmart.com.br> <200706110903.50155.jkeating@redhat.com> Message-ID: <466D5B76.20602@getsmart.com.br> Jesse Keating escreveu: > On Monday 11 June 2007 09:03:49 Francisco Andr? wrote: > >> I noticed that it seems that the script are looking for grub in the >> folder /sbin/grub but it is on the folder /usr/sbin/grub. I don't know >> if it's the problem, but for this time this is the maximum debug that I >> can get and show to you ok! >> > > Make sure that grub is in your manifest. The kernel doesn't have a direct > requires on it as different boot loaders can be used. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Hi! Thanks a lot. It's my first time that I make a custom distro so I need to get this tips! The isntallation is ok for now, I need to change some packages and custom it a bit more but I think I'm on the right way! Thanks again! you tip works! From distro at getsmart.com.br Mon Jun 11 14:28:49 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Mon, 11 Jun 2007 11:28:49 -0300 Subject: Installation boot with graphical screen Message-ID: <466D5C21.8060400@getsmart.com.br> Hi ! Let me ask you some thing. It's possible to use a graphical boot when the installation cd are started?? My objective is to hide the kernel messages of probing devices, because the users that will use my distribution is very dummy and I know that if they see a message of probing error by example our technical support phones will get crazy with so many calls! Thank's! From jgranado at redhat.com Mon Jun 11 17:01:26 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Mon, 11 Jun 2007 19:01:26 +0200 Subject: pungi logger In-Reply-To: <200706081425.16776.jkeating@redhat.com> References: <463B3F8E.2000209@redhat.com> <200705151420.29361.jkeating@redhat.com> <200706081425.16776.jkeating@redhat.com> Message-ID: <466D7FE6.1030403@redhat.com> Jesse Keating wrote: > On Tuesday 15 May 2007 14:20:29 Jesse Keating wrote: > >> On Friday 04 May 2007 10:13:34 Joel Andres Granados wrote: >> >>> Referring to ticket #34 at >>> https://hosted.fedoraproject.org/projects/pungi/ticket/34 stating that >>> the logger needed a little work so that it didn't depend on the >>> gather.py (or at least thats what I understood :) I propose either a >>> new file (pungiLog.py) located in the pypungi directory or a new >>> function in the "pungi" file that contains the logging stuff. The log >>> services would be started somewhere before the line containing "# >>> Actually do work." of the "pungi" file. The logging root would be >>> called "pungi" and would be called in each file that logging is needed >>> with the logging.getlogger("pungi") command. >>> If "quiet" is specified in the config file the logging will be turned >>> off. >>> >>> *Diff for the pungi file:* >>> 1. Initializes the logger by calling to the new file. >>> 2. specify quiet value. >>> 3. logging function. >>> * >>> Diff for pungi.py file: >>> *1. use the correct logger. >>> * >>> Diff for gather.py file:* >>> change all the if statements for each logging call. >>> >>> Files attached... >>> Comments appreciated. >>> >> Thanks for this. I think this is the right direction. However I'm >> reluctant to make such a change this late in Fedora 7 development. I'll >> want to look at this once I start doing Fedora 8 changes. >> > > I just looked at this again and I don't think it'll quite work. The thing is > I want logging to work if somebody just imported pypungi and started using > commands. Maybe that's not possible, maybe it is. Something to look into. > I think I can have a pypungi.logger module/class that has some reasonable > defaults that can be overridden if the config file is used, or if > say /usr/bin/pungi is envoked, but would work otherwise. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Something like this??? The logger must still be initialized, but after that you just have to import the Plog variable from pypungi to begin. I put the logging code in the __init__.py because I wanted it to execute when "import pypungi" was called. I couldn't find a way to pass arguments to it though (within python). It would be ideal to set global variables before the import and for the function to somehow notice those globals. I would suppose it is possible but have no idea how. Look for more info on that tomorrow. For now here is my proposal :) Comments greatly appreciated :) Regards -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From rob.myers at gtri.gatech.edu Mon Jun 11 17:43:41 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 11 Jun 2007 13:43:41 -0400 Subject: mash + koji write-signed-rpm Message-ID: <1181583821.4053.9.camel@rxm-581b.stl.gtri.gatech.edu> why not have mash write a signed rpm out instead of just warning users when a package has cached signatures, but no signed rpm? lightly tested patch attached. rob. -------------- next part -------------- A non-text attachment was scrubbed... Name: mash-0.1.17-write-signed.patch Type: text/x-patch Size: 2747 bytes Desc: not available URL: From notting at redhat.com Mon Jun 11 19:11:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 15:11:33 -0400 Subject: mash + koji write-signed-rpm In-Reply-To: <1181583821.4053.9.camel@rxm-581b.stl.gtri.gatech.edu> References: <1181583821.4053.9.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <20070611191133.GA3888@nostromo.devel.redhat.com> rob myers (rob.myers at gtri.gatech.edu) said: > why not have mash write a signed rpm out instead of just warning users > when a package has cached signatures, but no signed rpm? > > lightly tested patch attached. That would require the user running mash to authenticate to koji with a fairly high level of privelege, which seemed somewhat outside of the scope of it. Bill From rob.myers at gtri.gatech.edu Mon Jun 11 19:49:48 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 11 Jun 2007 15:49:48 -0400 Subject: mash + koji write-signed-rpm In-Reply-To: <20070611191133.GA3888@nostromo.devel.redhat.com> References: <1181583821.4053.9.camel@rxm-581b.stl.gtri.gatech.edu> <20070611191133.GA3888@nostromo.devel.redhat.com> Message-ID: <1181591388.4053.50.camel@rxm-581b.stl.gtri.gatech.edu> On Mon, 2007-06-11 at 15:11 -0400, Bill Nottingham wrote: > rob myers (rob.myers at gtri.gatech.edu) said: > > why not have mash write a signed rpm out instead of just warning users > > when a package has cached signatures, but no signed rpm? > > > > lightly tested patch attached. > > That would require the user running mash to authenticate to koji > with a fairly high level of privelege, which seemed somewhat outside of > the scope of it. that makes sense. is there a more natural place for this sort of housekeeping? rob. From jgranado at redhat.com Tue Jun 12 12:25:27 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 12 Jun 2007 14:25:27 +0200 Subject: pungi logger In-Reply-To: <200706081425.16776.jkeating@redhat.com> References: <463B3F8E.2000209@redhat.com> <200705151420.29361.jkeating@redhat.com> <200706081425.16776.jkeating@redhat.com> Message-ID: <466E90B7.4010201@redhat.com> > I just looked at this again and I don't think it'll quite work. The thing is > I want logging to work if somebody just imported pypungi and started using > commands. Maybe that's not possible, maybe it is. Something to look into. > I think I can have a pypungi.logger module/class that has some reasonable > defaults that can be overridden if the config file is used, or if > say /usr/bin/pungi is envoked, but would work otherwise. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list This one can also be considered... This solution activates logging as soon as the pypungi module is imported and puts it in the __builtin__ namespace as "Plog" (I called it "Plog" instead of "log" to give it a 'pungi' feel :). This allows the user to use "Plog" from that poing on without having to do anything else. The behavior of the "Plog" can be changed by calling on the pypungi.pungiLogO object and specifying the values that need to be changed. I did a small test run and everything seems OK. Jesse: I think this is close to what you mentioned on the previous mail and can be considered for inclusion. The diff is attached. -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From Michael_E_Brown at dell.com Tue Jun 12 19:35:43 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 14:35:43 -0500 Subject: [RFC] mock release plans Message-ID: <20070612193542.GB12626@humbolt.us.dell.com> All, It has been a bit since we have done a mock release and a lot has happened. This email is to serve as a sync-point so that everybody is on the same page regarding the release. Background information: Clark has done a lot of work to get a public git repository and project page set up. All that info is here: Trac Project page: https://hosted.fedoraproject.org/projects/mock Gitweb: http://git.fedoraproject.org/?p=hosted/mock;a=summary mock git repository: git clone git://git.fedoraproject.org/git/hosted/mock mock Proposal #1: branch policy We currently have no branch policy in place, nor a branch strategy. To rectify this, Clark and I propose the following branch policy: -- Branches will be created on an as-required basis. -- as-required means that there is a consensus that we need one (as defined by current project maintainers) Corollary: -- we will not use branches as a developer communication tool. If anybody has patches that need to be merged, use one of the following methods: -- post to mailing list for import by 'git am' -- post publicly-accessible git repository that can be pulled by one fo the maintainers. Proposal #2: branch cleanup In line with the branch policy above, we want the branch list to look like this: $ git branch -r origin/HEAD origin/master -- main line of development origin/mock-0-6-branch -- for fixes to historical releases origin/mock-experimental-launcher -- experimental development for launcher-based mock. To that end, here is the current git branch list and the proposed disposition for each branch: origin/HEAD origin/master origin/mock -- TO BE REMOVED (mistake) origin/mock-0-6-branch origin/mock-0-6-jesse -- TO BE REMOVED (per policy) origin/mock-0.6.0-jesse -- TO BE REMOVED (per policy) origin/mock-0.7 -- rename to mock-experimental-launcher origin/origin -- TO BE REMOVED (mistake) The branches listed as 'mistake' above were never intended to be created, but rather were result of various parties learning how git works. :) They will be removed. The *-jesse branches will be removed in favor of communicating using separate repos, where necessary. Proposal #3: mock 0.7 release We are overdue for a release. To that end, I will tag the current master branch as 0.7 for release. I will push mock 0.7 to rawhide. After a period of time in rawhide (one week?), I will create a release for Fedora 7 to push into updates-testing/. Announcements will be sent to the lists for each of these releases. We will implement the above after signoff by Clark Williams and Jesse Keating. signed-off-by: Michael Brown -- Michael From jkeating at redhat.com Tue Jun 12 19:47:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 15:47:22 -0400 Subject: [RFC] mock release plans In-Reply-To: <20070612193542.GB12626@humbolt.us.dell.com> References: <20070612193542.GB12626@humbolt.us.dell.com> Message-ID: <200706121547.23342.jkeating@redhat.com> On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > Proposal #3: mock 0.7 release > ? ? We are overdue for a release. To that end, I will tag the current > master branch as 0.7 for release. I will push mock 0.7 to rawhide. After > a period of time in rawhide (one week?), I will create a release for > Fedora 7 to push into updates-testing/. Announcements will be sent to > the lists for each of these releases. > I'd rather not wait for a rawhide timeout to get it into updates-testing for Fedora 7/6. I've done some extensive testing and I'm satisfied with it myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 doesn't have a -testing for Extras packages so that's a bit more risky, I'd be OK with delaying that one a bit. So instead I'd propose a release to rawhide and updates-testing ASAP, give it a short time or enough good feedback before releasing to Extras 6 and stable updates 7. > We will implement the above after signoff by Clark Williams and Jesse > Keating. I sign off on the policy, and apologize for the duplicate -jesse branches. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Tue Jun 12 20:09:19 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 12 Jun 2007 15:09:19 -0500 Subject: [RFC] mock release plans In-Reply-To: <200706121547.23342.jkeating@redhat.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> Message-ID: <466EFD6F.7090309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: >> Proposal #3: mock 0.7 release >> We are overdue for a release. To that end, I will tag the current >> master branch as 0.7 for release. I will push mock 0.7 to rawhide. After >> a period of time in rawhide (one week?), I will create a release for >> Fedora 7 to push into updates-testing/. Announcements will be sent to >> the lists for each of these releases. >> > > I'd rather not wait for a rawhide timeout to get it into updates-testing for > Fedora 7/6. I've done some extensive testing and I'm satisfied with it > myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 > doesn't have a -testing for Extras packages so that's a bit more risky, I'd > be OK with delaying that one a bit. So instead I'd propose a release to > rawhide and updates-testing ASAP, give it a short time or enough good > feedback before releasing to Extras 6 and stable updates 7. > I agree that we need to get this one to updates-testing as soon as possible (entirely because we've gone too long without pushing bugfixes). I think our normal mode should be to push to rawhide, wait a bit for the screaming to die down (maybe fix a few bugs), then push to updates-testing. Is that the intended flow of events? >> We will implement the above after signoff by Clark Williams and Jesse >> Keating. > > I sign off on the policy, and apologize for the duplicate -jesse branches. > > I sign off as well. Not a problem about the branches; we just realized after talking that we needed a policy on how it should be done and it seemed like we'd be "in a maze of twisty branches, all alike" if we didn't set a policy. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGbv1vHyuj/+TTEp0RAhwKAJ9edgV9tMVsEF/RBiBuV1MUrq71eQCeJAQi tGggP0iEnNAy+ITzXaILQC0= =XyUK -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Tue Jun 12 20:14:19 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 15:14:19 -0500 Subject: [RFC] mock release plans In-Reply-To: <466EFD6F.7090309@redhat.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> <466EFD6F.7090309@redhat.com> Message-ID: <20070612201419.GD12626@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 03:09:19PM -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesse Keating wrote: > > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > >> Proposal #3: mock 0.7 release > >> We are overdue for a release. To that end, I will tag the current > >> master branch as 0.7 for release. I will push mock 0.7 to rawhide. After > >> a period of time in rawhide (one week?), I will create a release for > >> Fedora 7 to push into updates-testing/. Announcements will be sent to > >> the lists for each of these releases. > >> > > > > I'd rather not wait for a rawhide timeout to get it into updates-testing for > > Fedora 7/6. I've done some extensive testing and I'm satisfied with it > > myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 > > doesn't have a -testing for Extras packages so that's a bit more risky, I'd > > be OK with delaying that one a bit. So instead I'd propose a release to > > rawhide and updates-testing ASAP, give it a short time or enough good > > feedback before releasing to Extras 6 and stable updates 7. > > > > I agree that we need to get this one to updates-testing as soon as > possible (entirely because we've gone too long without pushing bugfixes). ack. Will tag release today and push to rawhide/F7. I havent done a bhodi build yet, so wish me luck. :P > > I think our normal mode should be to push to rawhide, wait a bit for the > screaming to die down (maybe fix a few bugs), then push to > updates-testing. Is that the intended flow of events? Yes, that feels right to me. > >> We will implement the above after signoff by Clark Williams and Jesse > >> Keating. > > > > I sign off on the policy, and apologize for the duplicate -jesse branches. > > > > > > I sign off as well. Will send more notes as I work through the release. -- Michael From msteinmann at vesbridge.com Tue Jun 12 21:01:56 2007 From: msteinmann at vesbridge.com (Martin Steinmann) Date: Tue, 12 Jun 2007 17:01:56 -0400 Subject: pungi used to create CD that includes a kickstart file Message-ID: Using pungi on F7 I would like to create a CD that includes a kickstart file to be used during installation of a system using this CD. Is there a way to tell pungi to put a ks.cfg file into the root of the CD and modify isolinux.cfg? Thanks --martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael_E_Brown at dell.com Tue Jun 12 21:22:32 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 16:22:32 -0500 Subject: [RFC] mock release plans In-Reply-To: <200706121547.23342.jkeating@redhat.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> Message-ID: <20070612212232.GA8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 03:47:22PM -0400, Jesse Keating wrote: > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > > We will implement the above after signoff by Clark Williams and Jesse > > Keating. > > I sign off on the policy, and apologize for the duplicate -jesse branches. Jesse, Need help implementing the git branch cleanup. It appears that there is no way to delete a branch on a server from a client repo. Can you delete the following branches from within the master git repo? mock -- TO BE REMOVED (mistake) mock-0-6-jesse -- TO BE REMOVED (per policy) mock-0.6.0-jesse -- TO BE REMOVED (per policy) origin -- TO BE REMOVED (mistake) (probably need to be careful deleting that one. /refs/heads/orgin is probably how you are supposed to do it.) Additionally, we need to rename this branch: origin/mock-0.7 -- rename to mock-experimental-launcher I'm not sure exactly how to accomplish that. -- Michael From Michael_E_Brown at dell.com Tue Jun 12 21:25:51 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 16:25:51 -0500 Subject: [RFC] mock release plans In-Reply-To: <200706121547.23342.jkeating@redhat.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> Message-ID: <20070612212550.GB8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 03:47:22PM -0400, Jesse Keating wrote: > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > > Proposal #3: mock 0.7 release > > ? ? We are overdue for a release. To that end, I will tag the current > > master branch as 0.7 for release. I will push mock 0.7 to rawhide. After > > a period of time in rawhide (one week?), I will create a release for > > Fedora 7 to push into updates-testing/. Announcements will be sent to > > the lists for each of these releases. > > > > I'd rather not wait for a rawhide timeout to get it into updates-testing for > Fedora 7/6. I've done some extensive testing and I'm satisfied with it > myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 > doesn't have a -testing for Extras packages so that's a bit more risky, I'd > be OK with delaying that one a bit. So instead I'd propose a release to > rawhide and updates-testing ASAP, give it a short time or enough good > feedback before releasing to Extras 6 and stable updates 7. Current status: -devel: - spec/sources imported and checked into CVS - Koji build complete for -devel. F-7: - spec/sources imported and checked into CVS - Koji build in progress for F-7. - Currently scrutinizing the bodhi wiki page to figure out how to push to updates-testing/. -- Michael From pmeyer at themeyerfarm.com Tue Jun 12 21:26:55 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Tue, 12 Jun 2007 15:26:55 -0600 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: References: Message-ID: <466F0F9F.7020309@themeyerfarm.com> Martin Steinmann wrote: > > Using pungi on F7 I would like to create a CD that includes a > kickstart file to be used during installation of a system using this CD. > > > > Is there a way to tell pungi to put a ks.cfg file into the root of the > CD and modify isolinux.cfg? > > > > Thanks > > --martin > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Good question, and one that I solved by adding a special package and directory to the release-notes stuff. here are the lines from my pungi.conf file: ... relnotedirre = images stylesheet-images ks relnotepkgs = fjks fedora-release fedora-release-notes ... I make a package which contains a directory: /ks which contains all of my kickstart files. One version of pungi required me to add these lines into /usr/bin/pungi. :( The idea is that pungi will add the fjks package to the base cdimage. and copy the /ks directory to the root of the CD/DVD. That part works. You can now add: ks=cdrom:/ks/myks.cfg to the boot paramaters for an install. The release notes ARE NOT copied into the root directory of the initrd.img :( So I have to process that separately for my thumb drive installs. It goes like this: partition the thumb drive with two partitions, the first being 13MB and the second the remainder of the drive. Tag the first partition as bootable. # mkfs -t vfat -n "images" /dev/sd?2 # mount /dev/sd?2 /mnt # cp /srv/pungi/F7Developer/7/Custom/i386/iso/F-7-i386-DVD.iso /mnt # umount /mnt # dd if=/srv/pungi/F7Developer/7/Custom/i386/os/images/diskboot.img of=/dev/sd?1 ... # Now lets put our kickstart files into the initrd.img mount /dev/?1 /mnt rm -fr /tmp/img mkdir /tmp/img cd /tmp/img gunzip -dc /mnt/initrd.img | cpio -icvdmu # Copy kickstart files # adjust below as needed (not everyone uses .ks extension) mkdir ks cp ${KS}/*.ks ks cp ${KS}/home* ks find . |cpio --quiet -c -o |gzip -9 > ../initrd.img cp ../initrd.img /mnt cd # rm -fr /tmp/img umount /mnt ... Hope that is somewhat readable. The trick is the arguments to cpio. It would be AWSOME if the process that builds the initrd.img would put the release-notes there the same way, but they are never seen, so are not needed. From Michael_E_Brown at dell.com Tue Jun 12 21:37:31 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 16:37:31 -0500 Subject: [RFC] mock release plans In-Reply-To: <20070612212550.GB8637@humbolt.us.dell.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> <20070612212550.GB8637@humbolt.us.dell.com> Message-ID: <20070612213730.GC8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 04:25:51PM -0500, Michael E Brown wrote: > On Tue, Jun 12, 2007 at 03:47:22PM -0400, Jesse Keating wrote: > > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > > > Proposal #3: mock 0.7 release > > > ? ? We are overdue for a release. To that end, I will tag the current > > > master branch as 0.7 for release. I will push mock 0.7 to rawhide. After > > > a period of time in rawhide (one week?), I will create a release for > > > Fedora 7 to push into updates-testing/. Announcements will be sent to > > > the lists for each of these releases. > > > > > > > I'd rather not wait for a rawhide timeout to get it into updates-testing for > > Fedora 7/6. I've done some extensive testing and I'm satisfied with it > > myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 > > doesn't have a -testing for Extras packages so that's a bit more risky, I'd > > be OK with delaying that one a bit. So instead I'd propose a release to > > rawhide and updates-testing ASAP, give it a short time or enough good > > feedback before releasing to Extras 6 and stable updates 7. > > Current status: > -devel: > - spec/sources imported and checked into CVS > - Koji build complete for -devel. > > F-7: > - spec/sources imported and checked into CVS > - Koji build in progress for F-7. > - Currently scrutinizing the bodhi wiki page to figure out how to > push to updates-testing/. - Koji build now complete - New update created in Bodhi for mock - Currently 'pending' for updates-testing. -- Michael From jwboyer at jdub.homelinux.org Tue Jun 12 21:39:31 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 12 Jun 2007 16:39:31 -0500 Subject: [RFC] mock release plans In-Reply-To: <20070612212232.GA8637@humbolt.us.dell.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> <20070612212232.GA8637@humbolt.us.dell.com> Message-ID: <1181684371.17463.44.camel@vader.jdub.homelinux.org> On Tue, 2007-06-12 at 16:22 -0500, Michael E Brown wrote: > On Tue, Jun 12, 2007 at 03:47:22PM -0400, Jesse Keating wrote: > > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > > > We will implement the above after signoff by Clark Williams and Jesse > > > Keating. > > > > I sign off on the policy, and apologize for the duplicate -jesse branches. > > Jesse, > Need help implementing the git branch cleanup. It appears that there > is no way to delete a branch on a server from a client repo. > > Can you delete the following branches from within the master git > repo? > > mock -- TO BE REMOVED (mistake) > mock-0-6-jesse -- TO BE REMOVED (per policy) > mock-0.6.0-jesse -- TO BE REMOVED (per policy) > origin -- TO BE REMOVED (mistake) (probably need to be > careful deleting that one. /refs/heads/orgin is > probably how you are supposed to do it.) Do you really need to delete that one? Origin is a very common HEAD for git to have. > Additionally, we need to rename this branch: > > origin/mock-0.7 -- rename to mock-experimental-launcher git branch mock-experimental-launcher mock-0.7 git branch -D mock-0.7 josh From Michael_E_Brown at dell.com Tue Jun 12 21:50:05 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 16:50:05 -0500 Subject: [RFC] mock release plans In-Reply-To: <1181684371.17463.44.camel@vader.jdub.homelinux.org> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> <20070612212232.GA8637@humbolt.us.dell.com> <1181684371.17463.44.camel@vader.jdub.homelinux.org> Message-ID: <20070612215004.GD8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 04:39:31PM -0500, Josh Boyer wrote: > On Tue, 2007-06-12 at 16:22 -0500, Michael E Brown wrote: > > On Tue, Jun 12, 2007 at 03:47:22PM -0400, Jesse Keating wrote: > > > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > > > > We will implement the above after signoff by Clark Williams and Jesse > > > > Keating. > > > > > > I sign off on the policy, and apologize for the duplicate -jesse branches. > > > > Jesse, > > Need help implementing the git branch cleanup. It appears that there > > is no way to delete a branch on a server from a client repo. > > > > Can you delete the following branches from within the master git > > repo? > > > > mock -- TO BE REMOVED (mistake) > > mock-0-6-jesse -- TO BE REMOVED (per policy) > > mock-0.6.0-jesse -- TO BE REMOVED (per policy) > > origin -- TO BE REMOVED (mistake) (probably need to be > > careful deleting that one. /refs/heads/orgin is > > probably how you are supposed to do it.) > > Do you really need to delete that one? Origin is a very common HEAD for > git to have. Yes, but this is origin/origin. ie. a mistake. I stripped off the origin/ path from the list above. (None of my other projects have a origin/origin branch, but I could still be mistaken) > > > Additionally, we need to rename this branch: > > > > origin/mock-0.7 -- rename to mock-experimental-launcher > > git branch mock-experimental-launcher mock-0.7 > git branch -D mock-0.7 Ok, cool. thanks. Jesse, can you run the renames above as suggested by Josh. -- Michael From msteinmann at vesbridge.com Wed Jun 13 01:09:14 2007 From: msteinmann at vesbridge.com (Martin Steinmann) Date: Tue, 12 Jun 2007 21:09:14 -0400 Subject: pungi used to create CD that includes a kickstart file References: <466F0F9F.7020309@themeyerfarm.com> Message-ID: > > > >-----Original Message----- >From: fedora-buildsys-list-bounces at redhat.com on behalf of Phil Meyer >Sent: Tue 6/12/2007 5:26 PM >To: Discussion of Fedora build system >Subject: Re: pungi used to create CD that includes a kickstart file > >Martin Steinmann wrote: >> >> Using pungi on F7 I would like to create a CD that includes a >> kickstart file to be used during installation of a system using this CD. >> .> .> .> Is there a way to tell pungi to put a ks.cfg file into the root of the >> CD and modify isolinux.cfg? >> >> >> >> Thanks >> >> --martin >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list> > >Good question, and one that I solved by adding a special package and >directory to the release-notes stuff. > >here are the lines from my pungi.conf file: > >... >relnotedirre = images stylesheet-images ks >relnotepkgs = fjks fedora-release fedora-release-notes >.... > >I make a package which contains a directory: /ks >which contains all of my kickstart files. > >One version of pungi required me to add these lines into /usr/bin/pungi. :( > >The idea is that pungi will add the fjks package to the base cdimage. >and copy the /ks directory to the root of the CD/DVD. > >That part works. > >You can now add: ks=cdrom:/ks/myks.cfg >to the boot paramaters for an install. > >The release notes ARE NOT copied into the root directory of the >initrd.img :( > >So I have to process that separately for my thumb drive installs. > >It goes like this: > >partition the thumb drive with two partitions, the first being 13MB and >the second the remainder of the drive. Tag the first partition as bootable. > ># mkfs -t vfat -n "images" /dev/sd?2 > ># mount /dev/sd?2 /mnt > ># cp /srv/pungi/F7Developer/7/Custom/i386/iso/F-7-i386-DVD.iso /mnt > ># umount /mnt > ># dd if=/srv/pungi/F7Developer/7/Custom/i386/os/images/diskboot.img >of=/dev/sd?1 > >... ># Now lets put our kickstart files into the initrd.img > >mount /dev/?1 /mnt > >rm -fr /tmp/img >mkdir /tmp/img >cd /tmp/img >gunzip -dc /mnt/initrd.img | cpio -icvdmu ># Copy kickstart files ># adjust below as needed (not everyone uses .ks extension) >mkdir ks >cp ${KS}/*.ks ks >cp ${KS}/home* ks >find . |cpio --quiet -c -o |gzip -9 > ../initrd.img >cp ../initrd.img /mnt >cd ># rm -fr /tmp/img >umount /mnt >... > >Hope that is somewhat readable. >The trick is the arguments to cpio. > >It would be AWSOME if the process that builds the initrd.img would put >the release-notes there the same way, but they are never seen, so are >not needed. > It looks like I am trying to do something pungi does not yet support :(. We are using pungi to build a custom distribution for an appliance, which is what was advertised in the F7 release announcement. Appliances by definition install automatically so that the install is reproducible every time - i.e. we need a kickstart file on the CD. I don't quite understand why you had to tweak the release note mechanism or even change the initrd.img file. All I would need is a %post section in the manifest file that would allow me to copy the kickstart file into the tree before genisoimage is run. In addition, I need to modify the isolinux.cfg file to add the kickstart kernel parameter. The rest is then done by Anaconda during stage 2. Has anyone looked at this already? Or is anyone interested in helping to patch pungi to do this? --martin >-- >Fedora-buildsys-list mailing list >Fedora-buildsys-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken at bitsko.slc.ut.us Wed Jun 13 01:19:16 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Tue, 12 Jun 2007 20:19:16 -0500 Subject: [PATCH 0/3] mock cvs 2007-03: cross-compiling Message-ID: The first patch that follows adds cross-compilation support based on the model of a "target filesystem" containing target libraries and headers and a "cross filesystem" (or cross root) containing cross-compilers for the target. Examples of a mock cfg that uses this is in the third patch. The second patch adds SUBDIRS to the Make 'distclean' targets. This patch can be applied independently of the other two. The third patch is a 'contrib' of DENX ELDK 4.0 and 4.1 support as an example and is what I used to test the first patch. == What these are == I've been working with Wind River Linux, MontaVista, TimeSys, FreeScale LTIB, and DENX ELDK. Most contain their own implementation of 'rpmbuild' (like tsrpm and mvlrpm) and most can also be used with 'rpmbuild' with appropriate macros. In all cases the pattern is to have a "target filesystem" (I use /target in the mock chroot) with target libraries and headers and set CPPFLAGS, LDFLAGS, and others appropriately, and a "cross filesystem" or "cross root" (I use /cross in the chroot) where the host cross-compilers get installed, added to PATH, and supplied through CC and CXX. There are occasional gotchas with host includes, libraries, libtool, and pkg-config. The mock root (-r) config specifies the host build config and a new option --toolkit gives the toolkit to build with, which corresponds to a new mock configuration file with the target and cross filesystem info and any special build options. The goal is for toolkit configs to be reused with several chroots and different toolkits to be used to build for different cross distributions. I used DENX ELDK to initially develop these patches because anyone can download that toolkit without registration or evaluation license to work with the patches. These mock patches require a patch to yum to support installing an architecture unrelated to the host (the target yum conf specifies the arch of the target fs). The yum patch is to yum 2.4.3 from CentOS4 since our build system is RHEL4. https://lists.dulug.duke.edu/pipermail/yum-devel/2007-June/003849.html I haven't had a chance to update these patches to current CVS, I'm posting them now in case they're useful with the current interest in cross-compiling on fedora-devel. -- Ken From Michael_E_Brown at dell.com Wed Jun 13 02:29:55 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 21:29:55 -0500 Subject: EPEL configs merged Message-ID: <20070613022954.GF8637@humbolt.us.dell.com> All, I have merged the EPEL configs into the main git repository. These are the configs posted to the EPEL devel list a few weeks ago. They will be part of the 0.7.1 release when it comes. -- Michael From Michael_E_Brown at dell.com Wed Jun 13 02:33:17 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 21:33:17 -0500 Subject: [PATCH 0/3] mock cvs 2007-03: cross-compiling In-Reply-To: References: Message-ID: <20070613023316.GG8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 08:19:16PM -0500, Ken MacLeod wrote: > The first patch that follows adds cross-compilation support based on > the model of a "target filesystem" containing target libraries and > headers and a "cross filesystem" (or cross root) containing > cross-compilers for the target. Examples of a mock cfg that uses this > is in the third patch. > > The second patch adds SUBDIRS to the Make 'distclean' targets. This > patch can be applied independently of the other two. Sounds reasonable. > The third patch is a 'contrib' of DENX ELDK 4.0 and 4.1 support as an > example and is what I used to test the first patch. Apparently cross-compiling is in fashion nowadays. Clark is working on something similar inside Red Hat. I suppose we need to see the patches, but I think Clark would be most qualified to comment. I dont see why we couldnt merge this in, as long as it is reasonable. -- Michael From ken at bitsko.slc.ut.us Wed Jun 13 02:15:26 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Tue, 12 Jun 2007 21:15:26 -0500 Subject: [PATCH 2/3] mock cvs 2007-03: add SUBDIRS to distclean Message-ID: Adds SUBDIRS to the make 'distclean' target and 'distclean' to the sub-directory Makefiles. --- Makefile | 3 ++- docs/Makefile | 2 ++ etc/Makefile | 2 ++ src/Makefile | 2 ++ 4 files changed, 8 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index f3e7214..0dd1094 100644 --- a/Makefile +++ b/Makefile @@ -13,7 +13,8 @@ clean: distclean: clean rm -rf dist build - rm *.tar.gz + rm -f *.tar.gz + for d in $(SUBDIRS); do make -C $$d distclean ; done subdirs: for d in $(SUBDIRS); do make -C $$d; [ $$? = 0 ] || exit 1 ; done diff --git a/docs/Makefile b/docs/Makefile index 515cddb..0ebb642 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -4,6 +4,8 @@ all: clean: rm -f *.pyc *.pyo *~ +distclean: clean + install: mkdir -p $(DESTDIR)/usr/share/man/man1 install -m 644 mock.1 $(DESTDIR)/usr/share/man/man1/mock.1 diff --git a/etc/Makefile b/etc/Makefile index f395a1f..5f83ff0 100644 --- a/etc/Makefile +++ b/etc/Makefile @@ -4,6 +4,8 @@ all: clean: rm -f *.bak *~ +distclean: clean + install: mkdir -p $(DESTDIR)/etc/mock/ for item in *.cfg; do \ diff --git a/src/Makefile b/src/Makefile index 8e62ea7..14b30e1 100644 --- a/src/Makefile +++ b/src/Makefile @@ -25,6 +25,8 @@ clean: rm -f $(EXECUTABLE) rm -f *~ *.bak *.o *.so +distclean: clean + install: $(MKDIR) -p $(DESTDIR)/$(SBINDIR) $(DESTDIR)/$(LIBDIR) $(INSTALL) -m 4750 $(EXECUTABLE) $(DESTDIR)/$(SBINDIR)/$(EXECUTABLE) From ken at bitsko.slc.ut.us Wed Jun 13 02:15:13 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Tue, 12 Jun 2007 21:15:13 -0500 Subject: [PATCH 1/3] mock cvs 2007-03: cross-compile support Message-ID: This patch adds support for building RPMs for cross-compile targets. It adds an option '--toolkit' to specify a cross-development toolkit (and version) config for toolkits like DENX ELDK, TimeSys, MontaVista, or Wind River. The chroot (-r) configuration needs to supply the 'target_arch' and cross-distribution-provided host tools yum archive (those packages that normally install in the host system). [These should move over to the --toolkit config to allow unmodified host mock cfgs.] The --toolkit configuration file supplies the following variables [to be added to a doc somewhere]: base_arch (ppc, arm, mips) for the given 'target_arch' (eg. ppc_74xx, ppc_85xx) macros additional rpmbuild macros tk_rpmmacros points to where to put macros if the toolkit needs that (ELDK) tk_env set in the environment before calling rpmbuild (or the toolkit's equivalent) to set PATH, CROSS_COMPILE, etc. tk_fixup_cmd yum command (RPM to install) in the host (/) chroot after all else to fix things up for cross-building [should go away when everyone clean-builds, right?] tk_cross_chroot_setup_cmd 'buildsys-build' to install for the /cross root (complete yum command) tk_cross_yum.conf yum.conf for the /cross root tk_target_chroot_chroot_cmd 'buildsys-build' to install for the /target root (complete yum command) tk_target_yum.conf yum.conf for the /target root --- mock.py | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++----------- 1 files changed, 87 insertions(+), 19 deletions(-) diff --git a/mock.py b/mock.py index fc1b6aa..f072d78 100644 --- a/mock.py +++ b/mock.py @@ -246,15 +246,29 @@ class Root: self._prep_install() self.yum(cmd) + + cross_cmd = cmd + for cross_fs in ('cross', 'target'): + if self.config.has_key('tk_' + cross_fs + '_yum.conf'): + if cmd[0:7] == 'install': + cross_cmd = self.config['tk_' + cross_fs + '_chroot_setup_cmd'] + self.yum(cross_cmd, cross_fs) + + if self.config.has_key('tk_fixup_cmd') and cmd[0:7] == 'install': + self.yum(self.config['tk_fixup_cmd']) + self._prep_build() if create_cache: self.pack() - def yum(self, cmd): + def yum(self, cmd, crossdir=None): """use yum to install packages/package groups into the chroot""" # mock-helper yum --installroot=rootdir cmd - basecmd = '%s --installroot %s' % (self.config['yum'], self.rootdir) + yumrootdir = self.rootdir + if crossdir is not None: + yumrootdir = os.path.join(yumrootdir, crossdir) + basecmd = '%s --installroot %s' % (self.config['yum'], yumrootdir) self._mount() # check it again command = '%s %s' % (basecmd, cmd) @@ -282,8 +296,9 @@ class Root: shutil.copy2(srpm, dest) rootdest = os.path.join(self.builddir, 'originals', srpmfn) - cmd = "%s -c 'rpm -Uvh --nodeps %s' %s" % (self.config['runuser'], - rootdest, self.config['chrootuser']) + cmd = "%s -c '%s rpm -Uvh --nodeps %s' %s" \ + % (self.config['runuser'], self.config['tk_env'], + rootdest, self.config['chrootuser']) (retval, output) = self.do_chroot(cmd) if retval != 0: @@ -303,8 +318,10 @@ class Root: chrootspec = spec.replace(self.rootdir, '') # get rid of rootdir prefix # grab the .spec file from the specdir # run rpmbuild -bs --nodeps specfile - cmd = "%s -c 'rpmbuild -bs --target %s --nodeps %s' %s" % (self.config['runuser'], - self.target_arch, chrootspec, self.config['chrootuser']) + cmd = "%s -c '%s rpmbuild -bs %s --nodeps %s' %s" \ + % (self.config['runuser'], self.config['tk_env'], + self.config['tk_target_option'], chrootspec, + self.config['chrootuser']) (retval, output) = self.do_chroot(cmd) if retval != 0: @@ -355,9 +372,10 @@ class Root: srpmfn = os.path.basename(srpm_in) # run with --nodeps b/c of the check above we know we have our build # deps satisfied. - cmd = "cd /;%s -c 'rpmbuild --rebuild --target %s --nodeps %s' %s" % ( - self.config['runuser'], self.target_arch, srpm_in, - self.config['chrootuser']) + cmd = "cd /;%s -c '%s rpmbuild --rebuild %s --nodeps %s' %s" \ + % (self.config['runuser'], self.config['tk_env'], + self.config['tk_target_option'], srpm_in, + self.config['chrootuser']) self.state("build") @@ -566,6 +584,17 @@ class Root: return rpmUtils.miscutils.unique(reqlist) + def write_yum_conf(self, yum_conf, crossdir=''): + if os.path.exists( os.path.join(self.rootdir, crossdir, 'etc', 'yum.conf')): + yum_conf_path = os.path.join('/', crossdir, 'etc', 'yum.conf') + cmd = "chown %s.%s %s" % (self.config['chrootuid'], + self.config['chrootgid'], yum_conf_path) + self.do_chroot(cmd, fatal = True) + yumconf = os.path.join(self.rootdir, crossdir, 'etc', 'yum.conf') + yumconf_fo = open(yumconf, 'w') + yumconf_content = yum_conf + yumconf_fo.write(yumconf_content) + def _prep_install(self): """prep chroot for installation""" # make chroot dir @@ -581,6 +610,12 @@ class Root: os.path.join(self.rootdir, 'var/lock/rpm'), os.path.join(self.rootdir, 'etc/yum.repos.d')]: self._ensure_dir(item) + if self.config.has_key('tk_cross_yum.conf'): + self._ensure_dir(os.path.join(self.rootdir, 'cross/etc')) + self._ensure_dir(os.path.join(self.rootdir, 'cross/var/lock/rpm')) + if self.config.has_key('tk_target_yum.conf'): + self._ensure_dir(os.path.join(self.rootdir, 'target/etc')) + self._ensure_dir(os.path.join(self.rootdir, 'target/var/lock/rpm')) self._mount() @@ -623,15 +658,12 @@ class Root: fo.close() # write in yum.conf into chroot - if os.path.exists( os.path.join(self.rootdir, 'etc', 'yum.conf')): - cmd = "chown %s.%s /etc/yum.conf" % (self.config['chrootuid'], - self.config['chrootgid']) - self.do_chroot(cmd, fatal = True) - yumconf = os.path.join(self.rootdir, 'etc', 'yum.conf') - yumconf_fo = open(yumconf, 'w') - yumconf_content = self.config['yum.conf'] - yumconf_fo.write(yumconf_content) - + self.write_yum_conf(self.config['yum.conf']) + if self.config.has_key('tk_cross_yum.conf'): + self.write_yum_conf(self.config['tk_cross_yum.conf'], 'cross') + if self.config.has_key('tk_target_yum.conf'): + self.write_yum_conf(self.config['tk_target_yum.conf'], 'target') + # files in /etc that need doing filedict = self.config['files'] for key in filedict: @@ -703,7 +735,8 @@ class Root: self.do_chroot(cmd, fatal = True) # rpmmacros default - macrofile_out = '%s%s/.rpmmacros' % (self.rootdir, self.homedir) + macrofile_out = '%s%s/%s' % (self.rootdir, self.homedir, + self.config['tk_rpmmacros']) if not os.path.exists(macrofile_out): rpmmacros = open(macrofile_out, 'w') rpmmacros.write(self.config['macros']) @@ -740,6 +773,8 @@ def command_parse(): help="do not clean chroot before building", default=True) parser.add_option("--arch", action ="store", dest="arch", default=None, help="target build arch") + parser.add_option("--toolkit", action ="store", dest="toolkit", + default=None, help="cross-development toolkit config file name") parser.add_option("--debug", action ="store_true", dest="debug", default=False, help="Output copious debugging information") parser.add_option("--resultdir", action="store", type="string", @@ -778,6 +813,7 @@ def setup_default_config_opts(config_opts): config_opts['debug'] = False config_opts['quiet'] = False config_opts['target_arch'] = 'i386' + config_opts['toolkit'] = None config_opts['files'] = {} config_opts['yum.conf'] = '' config_opts['macros'] = """ @@ -790,6 +826,13 @@ def setup_default_config_opts(config_opts): config_opts['files']['/etc/resolv.conf'] = "nameserver 192.168.1.1\n" config_opts['files']['/etc/hosts'] = "127.0.0.1 localhost localhost.localdomain\n" + # cross-development config options, default is native + config_opts['tk_env'] = '' + config_opts['tk_rpmmacros'] = '.rpmmacros' + # --target is late-bound in main() to allow command line or config + # override + # config_opts['tk_target_option'] = '--target %s' % config_opts['target_arch'] + # caching-related config options config_opts['rebuild_cache'] = False config_opts['use_cache'] = False @@ -821,6 +864,22 @@ def set_config_opts_per_cmdline(config_opts, options): if options.uniqueext: config_opts['unique-ext'] = options.uniqueext + if options.toolkit: + config_opts['toolkit'] = options.toolkit + +def toolkit(config_path, config_opts, toolkit): + # read in toolkit config file by toolkit name + if toolkit.endswith('.cfg'): + cfg = '%s/%s' % (config_path, toolkit) + else: + cfg = '%s/%s.cfg' % (config_path, toolkit) + + if os.path.exists(cfg): + execfile(cfg) + else: + error("Could not find config file %s for toolkit %s" % (cfg, toolkit)) + sys.exit(1) + def do_clean(config_opts, init=0): my = None try: @@ -946,7 +1005,16 @@ def main(): # cmdline options override config options set_config_opts_per_cmdline(config_opts, options) + + if config_opts['toolkit'] is not None: + toolkit(config_path, config_opts, config_opts['toolkit']) + # cmdline options override toolkit config options too + set_config_opts_per_cmdline(config_opts, options) + + if not config_opts.has_key('tk_target_option'): + config_opts['tk_target_option'] = '--target %s' % config_opts['target_arch'] + # do whatever we're here to do if args[0] == 'clean': # unset a --no-clean From ken at bitsko.slc.ut.us Wed Jun 13 02:15:48 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Tue, 12 Jun 2007 21:15:48 -0500 Subject: [PATCH 3/3] mock cvs 2007-03: contrib DENX ELDK cross configs Message-ID: Adds configuration files and buildsys-build packages for using the DENX Embedded Linux Development Kit (ELDK) 4.0 and 4.1 on top of another base or core distribution like RHEL4. It should work with any ELDK target architecture with little changes. This patch is based on a Freescale PPC target. Includes scripts to build Yum repos for ELDK and a Makefile that runs through a complete bootstrap build process building buildsys-build for the cross root and target root. Requires the distclean and cross patches. --- Makefile | 2 contrib/Makefile | 14 ++ contrib/eldk/Makefile | 99 +++++++++++++++++ .../eldk/buildsys-build-eldk-4.0-ppc-cross.spec | 68 +++++++++++++ contrib/eldk/buildsys-build-eldk-4.0-ppc.spec | 115 +++++++++++++++++++ .../eldk/buildsys-build-eldk-4.1-ppc-cross.spec | 69 +++++++++++++ .../eldk/buildsys-build-eldk-4.1-ppc-fixup.spec | 19 ++++ contrib/eldk/buildsys-build-eldk-4.1-ppc.spec | 119 ++++++++++++++++++++ contrib/eldk/mk-eldk-4.0-ppc-repo.sh | 18 +++ contrib/eldk/mk-eldk-4.1-ppc-repo.sh | 19 +++ etc/eldk-4.0.cfg | 62 ++++++++++ etc/eldk-4.1.cfg | 72 ++++++++++++ 12 files changed, 675 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 0dd1094..aa58a6b 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -SUBDIRS = etc src docs +SUBDIRS = etc src docs contrib PKGNAME = mock VERSION=$(shell awk '/Version:/ { print $$2 }' ${PKGNAME}.spec) diff --git a/contrib/Makefile b/contrib/Makefile new file mode 100644 index 0000000..b0394f2 --- /dev/null +++ b/contrib/Makefile @@ -0,0 +1,14 @@ +SUBDIRS = eldk + +all: + for d in $(SUBDIRS); do make -C $$d all ; done + +clean: + $(RM) *~ + for d in $(SUBDIRS); do make -C $$d clean ; done + +distclean: clean + for d in $(SUBDIRS); do make -C $$d distclean ; done + +install: + for d in $(SUBDIRS); do make -C $$d install ; done diff --git a/contrib/eldk/Makefile b/contrib/eldk/Makefile new file mode 100644 index 0000000..d3558e9 --- /dev/null +++ b/contrib/eldk/Makefile @@ -0,0 +1,99 @@ +MOCKCFG=centos-4-i386 +MOCKROOT=/var/lib/mock/${MOCKCFG} +MOCKTARGCFG=centos-4-i386-eldk +MOCKTARGROOT=/var/lib/mock/${MOCKTARGCFG} + +TOOLKIT_VERSIONS= 4.0 4.1 + +TIME=/usr/bin/time +SUDO=sudo + +CROSSREPO=$(HOME)/local-repo/$(MOCKCFG) + +all: + echo "Nothing to do" + +clean: + rm -f *~ + +install: + echo "Nothing to do" + +distclean: clean + $(RM) -r buildsys $(CROSSREPO)/eldk-4.?-* SRPMS + $(SUDO) rm -rf buildsys-root + +SRPMS/buildsys-build-eldk-4.1-ppc-fixup-1.00-1.src.rpm: buildsys-build-eldk-4.1-ppc-fixup.spec + rm -rf buildsys + mkdir buildsys + mkdir -p SRPMS + rpmbuild --define "_sourcedir $(PWD)" \ + --define "_builddir $(PWD)/buildsys" \ + --define "_srcrpmdir $(PWD)/SRPMS" \ + -bs $< + +$(CROSSREPO)/%/host/repodata/filelists.xml.gz: SRPMS/buildsys-build-eldk-4.1-ppc-fixup-1.00-1.src.rpm + $(TIME) mock --autocache -r ${MOCKCFG} `pwd`/$< + mkdir -p `dirname $$(dirname $@)` + mv ${MOCKROOT}-${USER}/result/*noarch.rpm `dirname $$(dirname $@)` + createrepo `dirname $$(dirname $@)` + +fixup-rpm: $(CROSSREPO)/eldk-4.1-ppc/host/repodata/filelists.xml.gz + +SRPMS/buildsys-build-%-cross-0.5-1.src.rpm: buildsys-build-%-cross.spec + rm -rf buildsys + mkdir buildsys + mkdir -p SRPMS + rpmbuild --define "_sourcedir $(PWD)" \ + --define "_builddir $(PWD)/buildsys" \ + --define "_srcrpmdir $(PWD)/SRPMS" \ + -bs $< + +$(CROSSREPO)/%/cross/repodata/filelists.xml.gz: SRPMS/buildsys-build-%-cross-0.5-1.src.rpm + $(TIME) mock --autocache -r ${MOCKCFG} `pwd`/$< + mkdir -p `dirname $$(dirname $@)` + mv ${MOCKROOT}-${USER}/result/*noarch.rpm `dirname $$(dirname $@)` + createrepo `dirname $$(dirname $@)` + +buildsys-%-cross-check: $(CROSSREPO)/%/cross/repodata/filelists.xml.gz + $(SUDO) rm -rf buildsys-root + mkdir -p buildsys-root/var/lock/rpm + perl -ne 'if (($$in = /tk_cross_yum.conf/../^"""/) && ($$in > 1 && $$in !~ /E0/)) { s/%.root_base.s/$(MOCKCFG)/g; ($$a,$$b,$$c)=split(/-/,"$*"); s/%.toolkit.s/$$a-$$b/g; s/%.base_arch.s/$$c/g; print }' \ + buildsys-root/check.yum + $(TIME) $(SUDO) yum --installroot=`pwd`/buildsys-root \ + -c buildsys-root/check.yum \ + install buildsys-build-$*-cross + +buildsys-cross-check: buildsys-eldk-4.0-ppc-cross-check buildsys-eldk-4.1-ppc-cross-check + +SRPMS/buildsys-build-%-0.5-1.src.rpm: buildsys-build-%.spec + rm -rf buildsys + mkdir buildsys + mkdir -p SRPMS + rpmbuild --define "_sourcedir $(PWD)" \ + --define "_builddir $(PWD)/buildsys" \ + --define "_srcrpmdir $(PWD)/SRPMS" \ + -bs $< + +$(CROSSREPO)/%/ppc_85xx/repodata/filelists.xml.gz: SRPMS/buildsys-build-%-0.5-1.src.rpm + BUILDSYS_BOOT=true \ + $(TIME) mock -r ${MOCKTARGCFG} \ + --toolkit=`echo $@ | egrep --only-matching 'eldk-[0-9.]*'` \ + `pwd`/$< + $(RM) -r `dirname $$(dirname $@)` + mkdir `dirname $$(dirname $@)` + mv ${MOCKTARGROOT}-${USER}/result/*.[pn]*.rpm `dirname $$(dirname $@)` + createrepo `dirname $$(dirname $@)` + +buildsys-%-check: $(CROSSREPO)/%/ppc_85xx/repodata/filelists.xml.gz + $(SUDO) rm -rf buildsys-root + mkdir -p buildsys-root/var/lock/rpm + perl -ne 'if (($$in = /tk_target_yum.conf/../^"""/) && ($$in > 1 && $$in !~ /E0/)) { s/%.root_base.s/$(MOCKCFG)/g; ($$a,$$b,$$c)=split(/-/,"$*"); s/%.toolkit.s/$$a-$$b/g; s/%.base_arch.s/$$c/g; s/%.target_arch.s/ppc_85xx/g; print }' \ + buildsys-root/check.yum + $(TIME) $(SUDO) yum --installroot=`pwd`/buildsys-root \ + -c buildsys-root/check.yum \ + install buildsys-build-`basename $*`\* + +buildsys-target-check: buildsys-eldk-4.0-ppc-check buildsys-eldk-4.1-ppc-check + +buildsys-check: buildsys-cross-check buildsys-target-check diff --git a/contrib/eldk/buildsys-build-eldk-4.0-ppc-cross.spec b/contrib/eldk/buildsys-build-eldk-4.0-ppc-cross.spec new file mode 100644 index 0000000..33d43da --- /dev/null +++ b/contrib/eldk/buildsys-build-eldk-4.0-ppc-cross.spec @@ -0,0 +1,68 @@ +Summary: The base set of packages for a mock chroot ELDK cross +Name: buildsys-build-eldk-4.0-ppc-cross +Version: 0.5 +Release: 1%{?dist} +License: GPL +Group: Development/Build Tools +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root +BuildArch: noarch + +# packages that populate a buildsys chroot +Requires: rpm +Requires: texinfo +Requires: gdb-ppc +Requires: make-doc +Requires: mkimage +Requires: mtd_utils +Requires: mkcramfs +Requires: rpm-build +Requires: crosstool-powerpc-devel +Requires: make-ppc +Requires: ldd-ppc +Requires: genext2fs + +# host provides +Provides: /bin/bash +Provides: tetex +Provides: bash +Provides: perl(Getopt::Long) +Provides: /bin/sh +Provides: perl == 5.006001 +Provides: /usr/bin/perl +Provides: perl(File::Basename) +Provides: perl(strict) + +%description +The base set of packages for a mock chroot + +%build +%install +rm -rf $RPM_BUILD_ROOT + +mkdir -p $RPM_BUILD_ROOT/usr/bin +mkdir -p $RPM_BUILD_ROOT/bin + +ln -s rpm $RPM_BUILD_ROOT/bin/ppc-linux-rpm +ln -s rpmbuild $RPM_BUILD_ROOT/usr/bin/ppc-linux-rpmbuild + +for target_arch in ppc_6xx ppc_74xx ppc_85xx ppc_8xx; do + + for link in addr2line ar as c++ c++filt cpp g++ gcc gdb ld ldd \ + make nm objcopy objdump ranlib readelf run size strings strip; \ + do + ln -s ppc-linux-$link $RPM_BUILD_ROOT/usr/bin/${target_arch}-$link + done + + ln -s rpm $RPM_BUILD_ROOT/bin/${target_arch}-rpm + ln -s ../target $RPM_BUILD_ROOT/$target_arch +done + +%clean +rm -rf $RPM_BUILD_ROOT + +%files +%defattr(-,root,root,-) +%doc +/usr/bin/* +/bin/* +/ppc* diff --git a/contrib/eldk/buildsys-build-eldk-4.0-ppc.spec b/contrib/eldk/buildsys-build-eldk-4.0-ppc.spec new file mode 100644 index 0000000..83c6431 --- /dev/null +++ b/contrib/eldk/buildsys-build-eldk-4.0-ppc.spec @@ -0,0 +1,115 @@ +Summary: The base set of packages for a mock chroot denx target +Name: buildsys-build-eldk-4.0-ppc +Version: 0.5 +Release: 1%{?dist} +License: GPL +Source0: linux-2.6.15.tar.bz2 +Group: Development/Build Tools +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root +BuildArch: noarch + +# generic build packages that populate a buildsys chroot +Requires: bash-ppc_85xx +#Requires: buildsys-macros +Requires: bzip2-ppc_85xx +Requires: coreutils-ppc_85xx +Requires: cpio-ppc_85xx +Requires: diffutils-ppc_85xx +#Requires: fedora-release +Requires: gcc-ppc_85xx +Requires: gcc-c++-ppc_85xx +Requires: gzip-ppc_85xx +Requires: make-ppc_85xx +Requires: patch-ppc_85xx +#Requires: perl +Requires: rpm-build-ppc_85xx +#Requires: redhat-rpm-config +Requires: sed-ppc_85xx +Requires: tar-ppc_85xx +#Requires: unzip +#Requires: which + +# ELDK-specific requires +Requires: crosstool-targetcomponents-ppc_85xx +Requires: kernel-headers + +# broken dependencies in ELDK due to Fedora-repackaging without +# removing dependent content + +Provides: automake-ppc_85xx == 1.4 +Provides: beecrypt-devel-ppc_85xx +Provides: dev-ppc_85xx +Provides: elfutils-devel-ppc_85xx +Provides: /etc/redhat-release +Provides: ethtool-ppc_85xx == 1.8-2 +Provides: fileutils-ppc_85xx +Provides: glibc-devel-ppc_85xx == 2.2.90-12 +Provides: hwdata-ppc_85xx +Provides: info-ppc_85xx +Provides: kernel-ppc_85xx == 2.6 +Provides: libgcc-ppc_85xx == 4.0.0-1 +Provides: libstdc++-devel-ppc_85xx == 4.0.0 +Provides: libstdc++-ppc_85xx == 4.0.0 +Provides: libtool-libs-ppc_85xx == 1.5.16.multilib2-2_1 +Provides: mount-ppc_85xx == 2.11l +Provides: nroff-i18n-ppc_85xx +Provides: /opt/eldk/build/ppc-2006-01-11/work/ppc_85xx/etc/pam.d/system-auth +Provides: perl(Carp) +Provides: perl(constant) +Provides: perl(Cwd) +Provides: perl(Data::Dumper) +Provides: perl(DynaLoader) +Provides: perl(Errno) +Provides: perl(Exporter) +Provides: perl(File::Basename) +Provides: perl(File::Compare) +Provides: perl(File::Copy) +Provides: perl(File::Find) +Provides: perl(File::Spec) +Provides: perl(File::stat) +Provides: perl(Getopt::Long) +Provides: perl(getopts.pl) +Provides: perl(Getopt::Std) +Provides: perl(integer) +Provides: perl(IO::File) +Provides: perl(Net::SMTP) +Provides: perl(POSIX) +Provides: perl-ppc_85xx == 5.006001 +Provides: perl-ppc_85xx == 5.6.1 +Provides: perl(Socket) +Provides: perl(strict) +Provides: perl(Term::ReadLine) +Provides: perl(Text::ParseWords) +Provides: perl(vars) +Provides: /sbin/chkconfig +Provides: /sbin/install-info +Provides: /sbin/nash +Provides: /sbin/runuser +Provides: sh-utils-ppc_85xx +Provides: textutils-ppc_85xx +Provides: /usr/bin/perl +Provides: /usr/sbin/groupadd +Provides: /usr/sbin/useradd + +%description +The base set of packages for a mock chroot + +%prep + +%build + +%install +rm -rf $RPM_BUILD_ROOT + +mkdir -p $RPM_BUILD_ROOT +cd $RPM_BUILD_ROOT +tar xjf %{SOURCE0} + +%clean +rm -rf $RPM_BUILD_ROOT + +%files +%defattr(-,root,root,-) +%doc +/usr/src/linux-2.6.15 +/usr/src/linux diff --git a/contrib/eldk/buildsys-build-eldk-4.1-ppc-cross.spec b/contrib/eldk/buildsys-build-eldk-4.1-ppc-cross.spec new file mode 100644 index 0000000..44f35ef --- /dev/null +++ b/contrib/eldk/buildsys-build-eldk-4.1-ppc-cross.spec @@ -0,0 +1,69 @@ +Summary: The base set of packages for a mock chroot ELDK cross +Name: buildsys-build-eldk-4.1-ppc-cross +Version: 0.5 +Release: 1%{?dist} +License: GPL +Group: Development/Build Tools +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root +BuildArch: noarch + +# packages that populate a buildsys chroot +Requires: crosstool-powerpc-devel +Requires: gdb-ppc +Requires: genext2fs +Requires: ldd-ppc +Requires: make-doc +Requires: make-ppc +Requires: mkcramfs +Requires: mkimage +Requires: mtd_utils +Requires: popt +Requires: rpm +Requires: rpm-build +Requires: texinfo + +# host provides +Provides: /bin/bash +Provides: tetex +Provides: bash +Provides: perl(Getopt::Long) +Provides: /bin/sh +Provides: perl == 5.006001 +Provides: /usr/bin/perl +Provides: perl(File::Basename) +Provides: perl(strict) + +%description +The base set of packages for a mock chroot + +%build +%install +rm -rf $RPM_BUILD_ROOT + +mkdir -p $RPM_BUILD_ROOT/usr/bin +mkdir -p $RPM_BUILD_ROOT/bin + +ln -s rpm $RPM_BUILD_ROOT/bin/ppc-linux-rpm +ln -s rpmbuild $RPM_BUILD_ROOT/usr/bin/ppc-linux-rpmbuild + +for target_arch in ppc_6xx ppc_74xx ppc_85xx ppc_8xx; do + + for link in addr2line ar as c++ c++filt cpp g++ gcc gdb ld ldd \ + make nm objcopy objdump ranlib readelf run size strings strip; \ + do + ln -s ppc-linux-$link $RPM_BUILD_ROOT/usr/bin/${target_arch}-$link + done + + ln -s rpm $RPM_BUILD_ROOT/bin/${target_arch}-rpm + ln -s ../target $RPM_BUILD_ROOT/$target_arch +done + +%clean +rm -rf $RPM_BUILD_ROOT + +%files +%defattr(-,root,root,-) +%doc +/usr/bin/* +/bin/* +/ppc* diff --git a/contrib/eldk/buildsys-build-eldk-4.1-ppc-fixup.spec b/contrib/eldk/buildsys-build-eldk-4.1-ppc-fixup.spec new file mode 100644 index 0000000..3b07b14 --- /dev/null +++ b/contrib/eldk/buildsys-build-eldk-4.1-ppc-fixup.spec @@ -0,0 +1,19 @@ +Summary: DENX ELDK 4.1 host chroot setup RPM +Name: buildsys-build-eldk-4.1-ppc-fixup +Version: 1.00 +Release: 1 +License: GPL +Group: Development/Build Tools +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root +BuildArch: noarch + +%description +Chroot finalization for cross compiling using the DENX ELDK 4.1 +toolkit. + +%post +cd /usr/src +ln -s linux-* linux + +%files +%defattr(-,root,root,-) diff --git a/contrib/eldk/buildsys-build-eldk-4.1-ppc.spec b/contrib/eldk/buildsys-build-eldk-4.1-ppc.spec new file mode 100644 index 0000000..d0fee0f --- /dev/null +++ b/contrib/eldk/buildsys-build-eldk-4.1-ppc.spec @@ -0,0 +1,119 @@ +Summary: The base set of packages for a mock chroot denx target +Name: buildsys-build-eldk-4.1-ppc +Version: 0.5 +Release: 1%{?dist} +License: GPL +Group: Development/Build Tools +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root +BuildArch: noarch + +# generic build packages that populate a buildsys chroot +Requires: bash-ppc_85xx +#Requires: buildsys-macros +Requires: bzip2-ppc_85xx +Requires: coreutils-ppc_85xx +Requires: cpio-ppc_85xx +Requires: diffutils-ppc_85xx +#Requires: fedora-release +Requires: gcc-ppc_85xx +Requires: gcc-c++-ppc_85xx +Requires: gzip-ppc_85xx +Requires: make-ppc_85xx +Requires: patch-ppc_85xx +#Requires: perl +Requires: rpm-build-ppc_85xx +#Requires: redhat-rpm-config +Requires: sed-ppc_85xx +Requires: tar-ppc_85xx +#Requires: unzip +#Requires: which + +# ELDK-specific requires +Requires: crosstool-targetcomponents-ppc_85xx +Requires: kernel-headers + +# broken dependencies in ELDK due to Fedora-repackaging without +# removing dependent content + +# in 4.1, it looks like dependent packages may be requiring -ppc_85xx +# or -ppc_4xx versions of the noarch packages + +Provides: perl-ppc_4xx +Provides: autoconf-ppc_85xx == 2.50 +Provides: automake-ppc_85xx == 1.4 +Provides: beecrypt-devel-ppc_85xx +Provides: dev-ppc_85xx +Provides: elfutils-devel-ppc_85xx +Provides: /etc/redhat-release +Provides: ethtool-ppc_85xx == 1.8-2 +Provides: fileutils-ppc_85xx +Provides: glibc-devel-ppc_85xx == 2.2.90-12 +Provides: hwdata-ppc_85xx +Provides: info-ppc_85xx +Provides: kernel-headers-ppc_85xx +Provides: kernel-ppc_85xx == 2.6 +Provides: libgcc-ppc_85xx == 4.0.0-4 +Provides: libstdc++-devel-ppc_85xx == 4.0.0 +Provides: libstdc++-ppc_85xx == 4.0.0 +Provides: libtool-libs-ppc_85xx == 1.5.16.multilib2-2_2 +Provides: mount-ppc_85xx == 2.11l +Provides: nroff-i18n-ppc_85xx +Provides: /opt/eldk/build/ppc-2006-01-11/work/ppc_85xx/etc/pam.d/system-auth +Provides: perl(Carp) +Provides: perl(constant) +Provides: perl(Cwd) +Provides: perl(Data::Dumper) +Provides: perl(DynaLoader) +Provides: perl(Errno) +Provides: perl(Exporter) +Provides: perl(File::Basename) +Provides: perl(File::Compare) +Provides: perl(File::Copy) +Provides: perl(File::Find) +Provides: perl(File::Spec) +Provides: perl(File::stat) +Provides: perl(Getopt::Long) +Provides: perl(getopts.pl) +Provides: perl(Getopt::Std) +Provides: perl(integer) +Provides: perl(IO::File) +Provides: perl(Net::SMTP) +Provides: perl(POSIX) +Provides: perl-ppc_85xx == 5.006001 +Provides: perl-ppc_85xx == 5.6.1 +Provides: perl(Socket) +Provides: perl(strict) +Provides: perl(Term::ReadLine) +Provides: perl(Text::ParseWords) +Provides: perl(vars) +Provides: /sbin/chkconfig +Provides: /sbin/install-info +Provides: /sbin/nash +Provides: /sbin/runuser +Provides: sh-utils-ppc_85xx +Provides: textutils-ppc_85xx +Provides: /usr/bin/perl +Provides: /usr/bin/python +Provides: /usr/sbin/groupadd +Provides: /usr/sbin/useradd + +%description +The base set of packages for a mock chroot + +%prep + +%build + +%install + +mkdir -p $RPM_BUILD_ROOT/usr/include +for ii in asm mtd linux; do + ln -s ../src/linux/include/$ii $RPM_BUILD_ROOT/usr/include +done + +%clean + +%files +%defattr(-,root,root,-) +%doc +/usr/include/* diff --git a/contrib/eldk/mk-eldk-4.0-ppc-repo.sh b/contrib/eldk/mk-eldk-4.0-ppc-repo.sh new file mode 100644 index 0000000..78ed4f4 --- /dev/null +++ b/contrib/eldk/mk-eldk-4.0-ppc-repo.sh @@ -0,0 +1,18 @@ +set -ex + +ISOTOP=/net/192.168.1.17/../../misc/ppc-denx +YUMTOP=$HOME/repo/eldk-4.0-ppc + +rm -rf $YUMTOP + +function mkrepo() { + mkdir -p $2 + cp -as $1/*.rpm $2 + createrepo $2 +} + +mkrepo $ISOTOP/RPMS $YUMTOP/host + +for target_arch in ppc_6xx ppc_74xx ppc_85xx ppc_8xx; do + mkrepo $ISOTOP/$target_arch/RPMS $YUMTOP/$target_arch +done diff --git a/contrib/eldk/mk-eldk-4.1-ppc-repo.sh b/contrib/eldk/mk-eldk-4.1-ppc-repo.sh new file mode 100644 index 0000000..693250e --- /dev/null +++ b/contrib/eldk/mk-eldk-4.1-ppc-repo.sh @@ -0,0 +1,19 @@ +set -ex + +ISOTOP=/net/192.168.1.17/../../misc/eldk-4.1-ppc +YUMTOP=$HOME/repo/eldk-4.1-ppc + +rm -rf $YUMTOP + +function mkrepo() { + mkdir -p $2 + cp -as $1/*.rpm $2 + createrepo $2 +} + +mkrepo $ISOTOP/RPMS $YUMTOP/host +mkrepo $ISOTOP/common/RPMS/noarch $YUMTOP/noarch + +for target_arch in ppc_6xx ppc_74xx ppc_85xx ppc_8xx; do + mkrepo $ISOTOP/$target_arch/RPMS $YUMTOP/$target_arch +done diff --git a/etc/eldk-4.0.cfg b/etc/eldk-4.0.cfg new file mode 100644 index 0000000..eedbc7b --- /dev/null +++ b/etc/eldk-4.0.cfg @@ -0,0 +1,62 @@ +#!/usr/bin/python -tt + +if config_opts['target_arch'][0:3] == 'ppc': + config_opts['base_arch'] = 'ppc' +elif config_opts['target_arch'][0:3] == 'arm': + config_opts['base_arch'] = 'arm' +elif config_opts['target_arch'][0:4] == 'mips': + config_opts['base_arch'] = 'mips' + +config_opts['macros'] = """ +%%_topdir %s/build +%%_tmppath /tmp +%%_rpmfilename %%%%{NAME}-%%%%{VERSION}-%%%%{RELEASE}.%%%%{ARCH}.rpm +""" % config_opts['chroothome'] +config_opts['tk_env'] = 'PATH=/cross/usr/bin:/cross/bin:$PATH CROSS_COMPILE=%s-' % config_opts['target_arch'] +config_opts['tk_target_option'] = '' +config_opts['tk_rpmmacros'] = '.eldk_rpmmacros' +config_opts['tk_cross_chroot_setup_cmd'] = 'install buildsys-build-%(toolkit)s-%(base_arch)s-cross' \ + % config_opts +config_opts['tk_cross_yum.conf'] = """ +[main] +cachdir=/var/cache/yum +debuglevel=1 +logfile=/var/log/yum.log +reposdir=/dev/null +retries=20 +obsoletes=1 +gpgcheck=0 +assumeyes=1 + +[core] +name=core +baseurl=file:///home/ken/repo/%(toolkit)s-%(base_arch)s/host + +[local] +name=local +baseurl=file:///home/ken/local-repo/%(root_base)s/%(toolkit)s-%(base_arch)s/host +""" % config_opts + +if not os.environ.has_key('BUILDSYS_BOOT'): + config_opts['tk_target_chroot_setup_cmd'] = 'install buildsys-build-%s' % config_opts['toolkit'] + config_opts['tk_target_yum.conf'] = """ +[main] +cachdir=/var/cache/yum +debuglevel=1 +logfile=/var/log/yum.log +reposdir=/dev/null +retries=20 +obsoletes=1 +gpgcheck=0 +arch=%(base_arch)s +assumeyes=1 + +[core] +name=core +exclude=libgcc-* popt-*-1.10.1-22_1 +baseurl=file:///home/ken/repo/%(toolkit)s-%(base_arch)s/%(target_arch)s + +[local] +name=local +baseurl=file:///home/ken/local-repo/%(root_base)s/%(toolkit)s-%(base_arch)s/%(target_arch)s +""" % config_opts diff --git a/etc/eldk-4.1.cfg b/etc/eldk-4.1.cfg new file mode 100644 index 0000000..040773f --- /dev/null +++ b/etc/eldk-4.1.cfg @@ -0,0 +1,72 @@ +#!/usr/bin/python -tt + +if config_opts['target_arch'][0:3] == 'ppc': + config_opts['base_arch'] = 'ppc' +elif config_opts['target_arch'][0:3] == 'arm': + config_opts['base_arch'] = 'arm' +elif config_opts['target_arch'][0:4] == 'mips': + config_opts['base_arch'] = 'mips' + +config_opts['macros'] = """ +%%_topdir %s/build +%%_tmppath /tmp +%%_rpmfilename %%%%{NAME}-%%%%{VERSION}-%%%%{RELEASE}.%%%%{ARCH}.rpm +""" % config_opts['chroothome'] +config_opts['tk_env'] \ + = 'PATH=/cross/usr/bin:/cross/bin:$PATH CROSS_COMPILE=%s-' \ + % config_opts['target_arch'] +config_opts['tk_target_option'] = '' +config_opts['tk_rpmmacros'] = '.eldk_rpmmacros' +config_opts['tk_fixup_cmd'] \ + = 'install buildsys-build-%(toolkit)s-%(base_arch)s-fixup' % config_opts + +config_opts['tk_cross_chroot_setup_cmd'] \ + = 'install buildsys-build-%(toolkit)s-%(base_arch)s-cross' % config_opts +config_opts['tk_cross_yum.conf'] = """ +[main] +cachdir=/var/cache/yum +debuglevel=1 +logfile=/var/log/yum.log +reposdir=/dev/null +retries=20 +obsoletes=1 +gpgcheck=0 +assumeyes=1 + +[core] +name=core +baseurl=file:///home/ken/repo/%(toolkit)s-%(base_arch)s/host + +[local] +name=local +baseurl=file:///home/ken/local-repo/%(root_base)s/%(toolkit)s-%(base_arch)s/host +""" % config_opts + +if not os.environ.has_key('BUILDSYS_BOOT'): + config_opts['tk_target_chroot_setup_cmd'] \ + = 'install buildsys-build-%(toolkit)s-%(base_arch)s kernel-source' % config_opts + config_opts['tk_target_yum.conf'] = """ +[main] +cachdir=/var/cache/yum +debuglevel=1 +logfile=/var/log/yum.log +reposdir=/dev/null +retries=20 +obsoletes=1 +gpgcheck=0 +arch=%(base_arch)s +assumeyes=1 + +[core] +name=core +#exclude=libgcc-* popt-*-1.10.1-22_1 +baseurl=file:///home/ken/repo/%(toolkit)s-%(base_arch)s/%(target_arch)s + +[core-noarch] +name=core noarch +baseurl=file:///home/ken/repo/%(toolkit)s-%(base_arch)s/noarch + +[local] +name=local +baseurl=file:///home/ken/local-repo/%(root_base)s/%(toolkit)s-%(base_arch)s/%(target_arch)s +""" % config_opts From Michael_E_Brown at dell.com Wed Jun 13 03:47:57 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 22:47:57 -0500 Subject: [PATCH 2/3] mock cvs 2007-03: add SUBDIRS to distclean In-Reply-To: References: Message-ID: <20070613034756.GH8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 09:15:26PM -0500, Ken MacLeod wrote: > Adds SUBDIRS to the make 'distclean' target and 'distclean' to the > sub-directory Makefiles. Doesnt apply cleanly to current master branch. I've fixed up the rejects manually. Applied and pushed. For anything more complicated, please rebase against current master branch before sending. Thanks, Michael From Michael_E_Brown at dell.com Wed Jun 13 04:49:41 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 23:49:41 -0500 Subject: [PATCH 1/3] mock cvs 2007-03: cross-compile support In-Reply-To: References: Message-ID: <20070613044941.GI8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 09:15:13PM -0500, Ken MacLeod wrote: > This patch adds support for building RPMs for cross-compile targets. > It adds an option '--toolkit' to specify a cross-development toolkit > (and version) config for toolkits like DENX ELDK, TimeSys, MontaVista, > or Wind River. > > The chroot (-r) configuration needs to supply the 'target_arch' and > cross-distribution-provided host tools yum archive (those packages > that normally install in the host system). [These should move over to > the --toolkit config to allow unmodified host mock cfgs.] Looks like toolkit config file has same format and general layout as the normal mock config file. Why not use the normal mock config file handling? It would eliminate a small portion of the cross patches in that we no longer need another command line opt, nor processing for another config file. Your toolkit config file could easily import the base os config file of your choice and go from there adding options. You would be exploiting the fact that the config files are executable python code (which you already appear to be doing). For example: # mock -r my_cross_config ... specfile # cat /etc/mock/my_cross_config.cfg #!/usr/bin/python exec("base_config_file") # extend with new options: config_opts["my_new_opt"] = "foo" > The --toolkit configuration file supplies the following variables [to > be added to a doc somewhere]: > > base_arch (ppc, arm, mips) > for the given 'target_arch' (eg. ppc_74xx, ppc_85xx) > > macros > additional rpmbuild macros > > tk_rpmmacros > points to where to put macros if the toolkit needs that (ELDK) > > tk_env > set in the environment before calling rpmbuild (or the toolkit's > equivalent) to set PATH, CROSS_COMPILE, etc. > > tk_fixup_cmd > yum command (RPM to install) in the host (/) chroot after all else > to fix things up for cross-building [should go away when everyone > clean-builds, right?] Can you give an overview for the ignorant (ie. me) about the difference between /cross and /target? Why is /cross its own chroot-like thing? Couldnt you just say, "install this one additional cross-buildsys-rpm, which pulls in the cross-toolchain?" > > tk_cross_chroot_setup_cmd > 'buildsys-build' to install for the /cross root (complete yum > command) If you do the above, could this be eliminated? > > tk_cross_yum.conf > yum.conf for the /cross root > > tk_target_chroot_chroot_cmd > 'buildsys-build' to install for the /target root (complete yum > command) Reasonable. > > tk_target_yum.conf > yum.conf for the /target root Reasonable. > > > --- > > mock.py | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++----------- > 1 files changed, 87 insertions(+), 19 deletions(-) > > diff --git a/mock.py b/mock.py > index fc1b6aa..f072d78 100644 > --- a/mock.py > +++ b/mock.py > @@ -246,15 +246,29 @@ class Root: > > self._prep_install() > self.yum(cmd) > + > + cross_cmd = cmd > + for cross_fs in ('cross', 'target'): > + if self.config.has_key('tk_' + cross_fs + '_yum.conf'): > + if cmd[0:7] == 'install': Dont like parsing previous cmd value for this. too fragile. Just integrate this into the previous test. At the same time, cache stuff could probably go into a separate function: (cmd, cross_cmd, create_cache) = self._unpack_cache() and move the stuff slightly above this function that sets cmd into said function. > + cross_cmd = self.config['tk_' + cross_fs + '_chroot_setup_cmd'] > + self.yum(cross_cmd, cross_fs) > + > + if self.config.has_key('tk_fixup_cmd') and cmd[0:7] == 'install': > + self.yum(self.config['tk_fixup_cmd']) > self._prep_build() > > if create_cache: > self.pack() > > - def yum(self, cmd): > + def yum(self, cmd, crossdir=None): > """use yum to install packages/package groups into the chroot""" > # mock-helper yum --installroot=rootdir cmd > - basecmd = '%s --installroot %s' % (self.config['yum'], self.rootdir) > + yumrootdir = self.rootdir > + if crossdir is not None: > + yumrootdir = os.path.join(yumrootdir, crossdir) > + basecmd = '%s --installroot %s' % (self.config['yum'], yumrootdir) I dont like the implicit join in the function. I'd rather see: def yum(self, cmd, rootDirOverride=None): yumrootdir=self.rootdir if rootDirOverride is not None: yumrootdir=rootDirOverride basecmd = '%s --installroot %s' % (self.config['yum'], yumrootdir) > > self._mount() # check it again > command = '%s %s' % (basecmd, cmd) > @@ -282,8 +296,9 @@ class Root: > shutil.copy2(srpm, dest) > rootdest = os.path.join(self.builddir, 'originals', srpmfn) > > - cmd = "%s -c 'rpm -Uvh --nodeps %s' %s" % (self.config['runuser'], > - rootdest, self.config['chrootuser']) > + cmd = "%s -c '%s rpm -Uvh --nodeps %s' %s" \ > + % (self.config['runuser'], self.config['tk_env'], > + rootdest, self.config['chrootuser']) > (retval, output) = self.do_chroot(cmd) Definitely need to rebase the patch, as the line numbers skew. This doesnt seem like a specific toolkit thing, as tk_env is used for every rpm invokation. How about make it generic? "rpm_addtl_env" or some such. You can continue to set it in your override config. > > if retval != 0: > @@ -303,8 +318,10 @@ class Root: > chrootspec = spec.replace(self.rootdir, '') # get rid of rootdir prefix > # grab the .spec file from the specdir > # run rpmbuild -bs --nodeps specfile > - cmd = "%s -c 'rpmbuild -bs --target %s --nodeps %s' %s" % (self.config['runuser'], > - self.target_arch, chrootspec, self.config['chrootuser']) > + cmd = "%s -c '%s rpmbuild -bs %s --nodeps %s' %s" \ > + % (self.config['runuser'], self.config['tk_env'], > + self.config['tk_target_option'], chrootspec, > + self.config['chrootuser']) Again, generic. "rpmbuild_addtl_cmdline" > > (retval, output) = self.do_chroot(cmd) > if retval != 0: > @@ -355,9 +372,10 @@ class Root: > srpmfn = os.path.basename(srpm_in) > # run with --nodeps b/c of the check above we know we have our build > # deps satisfied. > - cmd = "cd /;%s -c 'rpmbuild --rebuild --target %s --nodeps %s' %s" % ( > - self.config['runuser'], self.target_arch, srpm_in, > - self.config['chrootuser']) > + cmd = "cd /;%s -c '%s rpmbuild --rebuild %s --nodeps %s' %s" \ > + % (self.config['runuser'], self.config['tk_env'], > + self.config['tk_target_option'], srpm_in, > + self.config['chrootuser']) Generic. > > self.state("build") > > @@ -566,6 +584,17 @@ class Root: > > return rpmUtils.miscutils.unique(reqlist) > > + def write_yum_conf(self, yum_conf, crossdir=''): > + if os.path.exists( os.path.join(self.rootdir, crossdir, 'etc', 'yum.conf')): > + yum_conf_path = os.path.join('/', crossdir, 'etc', 'yum.conf') > + cmd = "chown %s.%s %s" % (self.config['chrootuid'], > + self.config['chrootgid'], yum_conf_path) > + self.do_chroot(cmd, fatal = True) > + yumconf = os.path.join(self.rootdir, crossdir, 'etc', 'yum.conf') > + yumconf_fo = open(yumconf, 'w') > + yumconf_content = yum_conf > + yumconf_fo.write(yumconf_content) Overall, I like this function. I dont like crossdir=''. Should use same idiom I went over above. That makes this not-crossdir specific at all. > + > def _prep_install(self): > """prep chroot for installation""" > # make chroot dir > @@ -581,6 +610,12 @@ class Root: > os.path.join(self.rootdir, 'var/lock/rpm'), > os.path.join(self.rootdir, 'etc/yum.repos.d')]: > self._ensure_dir(item) > + if self.config.has_key('tk_cross_yum.conf'): > + self._ensure_dir(os.path.join(self.rootdir, 'cross/etc')) > + self._ensure_dir(os.path.join(self.rootdir, 'cross/var/lock/rpm')) > + if self.config.has_key('tk_target_yum.conf'): > + self._ensure_dir(os.path.join(self.rootdir, 'target/etc')) > + self._ensure_dir(os.path.join(self.rootdir, 'target/var/lock/rpm')) Hmm.. surely there is a way to make this generic? config_opts["addtl_root_dirs_list"] = ( ... ) or something like that. > > self._mount() > > @@ -623,15 +658,12 @@ class Root: > fo.close() > > # write in yum.conf into chroot > - if os.path.exists( os.path.join(self.rootdir, 'etc', 'yum.conf')): > - cmd = "chown %s.%s /etc/yum.conf" % (self.config['chrootuid'], > - self.config['chrootgid']) > - self.do_chroot(cmd, fatal = True) > - yumconf = os.path.join(self.rootdir, 'etc', 'yum.conf') > - yumconf_fo = open(yumconf, 'w') > - yumconf_content = self.config['yum.conf'] > - yumconf_fo.write(yumconf_content) > - > + self.write_yum_conf(self.config['yum.conf']) > + if self.config.has_key('tk_cross_yum.conf'): > + self.write_yum_conf(self.config['tk_cross_yum.conf'], 'cross') > + if self.config.has_key('tk_target_yum.conf'): > + self.write_yum_conf(self.config['tk_target_yum.conf'], 'target') How about: config file: yum_cross_conf = """ ... yum config here ... """ yum_target_conf = """ ... yum config here ... """ config_opts['additional_yum_configs'] = [ (yum_cross_conf, "cross"), (yum_target_conf, "target")] code: if self.config.has_key('additional_yum_configs'): for (yum_conf, yum_path) in self.config['additional_yum_configs']: self.write_yum_conf( yum_conf, yum_path ) > + > # files in /etc that need doing > filedict = self.config['files'] > for key in filedict: > @@ -703,7 +735,8 @@ class Root: > self.do_chroot(cmd, fatal = True) > > # rpmmacros default > - macrofile_out = '%s%s/.rpmmacros' % (self.rootdir, self.homedir) > + macrofile_out = '%s%s/%s' % (self.rootdir, self.homedir, > + self.config['tk_rpmmacros']) > if not os.path.exists(macrofile_out): > rpmmacros = open(macrofile_out, 'w') > rpmmacros.write(self.config['macros']) > @@ -740,6 +773,8 @@ def command_parse(): > help="do not clean chroot before building", default=True) > parser.add_option("--arch", action ="store", dest="arch", > default=None, help="target build arch") > + parser.add_option("--toolkit", action ="store", dest="toolkit", > + default=None, help="cross-development toolkit config file name") not needed. > parser.add_option("--debug", action ="store_true", dest="debug", > default=False, help="Output copious debugging information") > parser.add_option("--resultdir", action="store", type="string", > @@ -778,6 +813,7 @@ def setup_default_config_opts(config_opts): > config_opts['debug'] = False > config_opts['quiet'] = False > config_opts['target_arch'] = 'i386' > + config_opts['toolkit'] = None ditto > config_opts['files'] = {} > config_opts['yum.conf'] = '' > config_opts['macros'] = """ > @@ -790,6 +826,13 @@ def setup_default_config_opts(config_opts): > config_opts['files']['/etc/resolv.conf'] = "nameserver 192.168.1.1\n" > config_opts['files']['/etc/hosts'] = "127.0.0.1 localhost localhost.localdomain\n" > > + # cross-development config options, default is native > + config_opts['tk_env'] = '' > + config_opts['tk_rpmmacros'] = '.rpmmacros' start... > + # --target is late-bound in main() to allow command line or config > + # override > + # config_opts['tk_target_option'] = '--target %s' % config_opts['target_arch'] > + > # caching-related config options > config_opts['rebuild_cache'] = False > config_opts['use_cache'] = False > @@ -821,6 +864,22 @@ def set_config_opts_per_cmdline(config_opts, options): > if options.uniqueext: > config_opts['unique-ext'] = options.uniqueext > > + if options.toolkit: > + config_opts['toolkit'] = options.toolkit > + > +def toolkit(config_path, config_opts, toolkit): > + # read in toolkit config file by toolkit name > + if toolkit.endswith('.cfg'): > + cfg = '%s/%s' % (config_path, toolkit) > + else: > + cfg = '%s/%s.cfg' % (config_path, toolkit) > + > + if os.path.exists(cfg): > + execfile(cfg) > + else: > + error("Could not find config file %s for toolkit %s" % (cfg, toolkit)) > + sys.exit(1) > + > def do_clean(config_opts, init=0): > my = None > try: > @@ -946,7 +1005,16 @@ def main(): > > # cmdline options override config options > set_config_opts_per_cmdline(config_opts, options) > + > + if config_opts['toolkit'] is not None: > + toolkit(config_path, config_opts, config_opts['toolkit']) end... I think all this (start...end) code goes away if you fold the config files together. > > + # cmdline options override toolkit config options too > + set_config_opts_per_cmdline(config_opts, options) > + > + if not config_opts.has_key('tk_target_option'): > + config_opts['tk_target_option'] = '--target %s' % config_opts['target_arch'] Make more generic? Overall, I like the concept. I think we can do a lot of it in a more generic way so that the words "cross" or "target" dont appear quite so many times. I think we can support this being included if you make the suggested changes. Clark? Any additional comments? How does this fit with what you were doing? -- Michael From jgranado at redhat.com Wed Jun 13 07:16:13 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Wed, 13 Jun 2007 09:16:13 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: References: <466F0F9F.7020309@themeyerfarm.com> Message-ID: <466F99BD.5060108@redhat.com> > > > > It looks like I am trying to do something pungi does not yet support :(. > > We are using pungi to build a custom distribution for an appliance, > which is what was advertised in the F7 release announcement. > Appliances by definition install automatically so that the install is > reproducible every time - i.e. we need a kickstart file on the CD. > > I don't quite understand why you had to tweak the release note > mechanism or even change the initrd.img file. All I would need is a > %post section in the manifest file that would allow me to copy the > kickstart file into the tree before genisoimage is run. In addition, I > need to modify the isolinux.cfg file to add the kickstart kernel > parameter. The rest is then done by Anaconda during stage 2. > > Has anyone looked at this already? Or is anyone interested in helping > to patch pungi to do this? > > --martin > AFAIK pungi does not do this and it seems a very interesting feature to add. If you have any patches just post them on the list. I'm sure you'll get some feedback. Regards. -- Joel Andres Granados From jkeating at redhat.com Wed Jun 13 12:26:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 08:26:10 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: References: <466F0F9F.7020309@themeyerfarm.com> Message-ID: <200706130826.13728.jkeating@redhat.com> On Tuesday 12 June 2007 21:09:14 Martin Steinmann wrote: > I don't quite understand why you had to tweak the release note mechanism or > even change the initrd.img file. All I would need is a %post section in the > manifest file that would allow me to copy the kickstart file into the tree > before genisoimage is run. In addition, I need to modify the isolinux.cfg > file to add the kickstart kernel parameter. The rest is then done by > Anaconda during stage 2. Actually what needs to happen is the releasenotes stuff needs to be renamed to something more generic like extrafiles or whatnot. Really the methodology is it looks for a list of file regexes in a list of packages you give it that are in your tree and it extracts those files onto the root of the iso file system and install tree. This can be used for not just release notes, but for kickstart files, autorun files, whatever else you may want in the root. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Jun 13 12:58:38 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 13 Jun 2007 14:58:38 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <200706130826.13728.jkeating@redhat.com> References: <466F0F9F.7020309@themeyerfarm.com> <200706130826.13728.jkeating@redhat.com> Message-ID: <466FE9FE.3040806@kanarip.com> Jesse Keating wrote: > On Tuesday 12 June 2007 21:09:14 Martin Steinmann wrote: >> I don't quite understand why you had to tweak the release note mechanism or >> even change the initrd.img file. All I would need is a %post section in the >> manifest file that would allow me to copy the kickstart file into the tree >> before genisoimage is run. In addition, I need to modify the isolinux.cfg >> file to add the kickstart kernel parameter. The rest is then done by >> Anaconda during stage 2. > > Actually what needs to happen is the releasenotes stuff needs to be renamed to > something more generic like extrafiles or whatnot. Really the methodology is > it looks for a list of file regexes in a list of packages you give it that > are in your tree and it extracts those files onto the root of the iso file > system and install tree. This can be used for not just release notes, but > for kickstart files, autorun files, whatever else you may want in the root. > We're gonna do the same thing here, except that we also want to be able to add non-RPM based files to the images, for example a complete directory tree. Is that being added to pungi as well? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Jun 13 13:10:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 09:10:45 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <466FE9FE.3040806@kanarip.com> References: <200706130826.13728.jkeating@redhat.com> <466FE9FE.3040806@kanarip.com> Message-ID: <200706130910.45953.jkeating@redhat.com> On Wednesday 13 June 2007 08:58:38 Jeroen van Meeuwen wrote: > We're gonna do the same thing here, except that we also want to be able > to add non-RPM based files to the images, for example a complete > directory tree. Is that being added to pungi as well? What's stopping you from packaging up the directory tree in rpm? There are two regex variables, one that is for files themselves and one that is for whole directories to bring in. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmeyer at themeyerfarm.com Wed Jun 13 15:16:28 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Wed, 13 Jun 2007 09:16:28 -0600 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <200706130910.45953.jkeating@redhat.com> References: <200706130826.13728.jkeating@redhat.com> <466FE9FE.3040806@kanarip.com> <200706130910.45953.jkeating@redhat.com> Message-ID: <46700A4C.3010208@themeyerfarm.com> Jesse Keating wrote: > On Wednesday 13 June 2007 08:58:38 Jeroen van Meeuwen wrote: > >> We're gonna do the same thing here, except that we also want to be able >> to add non-RPM based files to the images, for example a complete >> directory tree. Is that being added to pungi as well? >> > > What's stopping you from packaging up the directory tree in rpm? There are > two regex variables, one that is for files themselves and one that is for > whole directories to bring in. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Right. That is what I did. Create an rpm with a directory of stuff I need, and specify that rpm as a release notes, and then specify my directory to be copied to the root. From mikem at redhat.com Wed Jun 13 15:38:38 2007 From: mikem at redhat.com (Mike McLean) Date: Wed, 13 Jun 2007 11:38:38 -0400 Subject: mash + koji write-signed-rpm In-Reply-To: <20070611191133.GA3888@nostromo.devel.redhat.com> References: <1181583821.4053.9.camel@rxm-581b.stl.gtri.gatech.edu> <20070611191133.GA3888@nostromo.devel.redhat.com> Message-ID: <46700F7E.9070103@redhat.com> Bill Nottingham wrote: > That would require the user running mash to authenticate to koji > with a fairly high level of privelege, which seemed somewhat outside of > the scope of it. Another option is for mash to create a local signed copy by splicing the signature header itself. koji.splice_rpm_sighdr is the call the server uses. From Michael_E_Brown at dell.com Wed Jun 13 15:42:12 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 13 Jun 2007 10:42:12 -0500 Subject: [RFC] mock release plans In-Reply-To: <20070612213730.GC8637@humbolt.us.dell.com> References: <20070612193542.GB12626@humbolt.us.dell.com> <200706121547.23342.jkeating@redhat.com> <20070612212550.GB8637@humbolt.us.dell.com> <20070612213730.GC8637@humbolt.us.dell.com> Message-ID: <20070613154211.GK8637@humbolt.us.dell.com> On Tue, Jun 12, 2007 at 04:37:31PM -0500, Michael E Brown wrote: > On Tue, Jun 12, 2007 at 04:25:51PM -0500, Michael E Brown wrote: > > On Tue, Jun 12, 2007 at 03:47:22PM -0400, Jesse Keating wrote: > > > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: > > > > Proposal #3: mock 0.7 release > > > > ? ? We are overdue for a release. To that end, I will tag the current > > > > master branch as 0.7 for release. I will push mock 0.7 to rawhide. After > > > > a period of time in rawhide (one week?), I will create a release for > > > > Fedora 7 to push into updates-testing/. Announcements will be sent to > > > > the lists for each of these releases. > > > > > > > > > > I'd rather not wait for a rawhide timeout to get it into updates-testing for > > > Fedora 7/6. I've done some extensive testing and I'm satisfied with it > > > myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 > > > doesn't have a -testing for Extras packages so that's a bit more risky, I'd > > > be OK with delaying that one a bit. So instead I'd propose a release to > > > rawhide and updates-testing ASAP, give it a short time or enough good > > > feedback before releasing to Extras 6 and stable updates 7. > > > > Current status: > > -devel: > > - spec/sources imported and checked into CVS > > - Koji build complete for -devel. > > > > F-7: > > - spec/sources imported and checked into CVS > > - Koji build in progress for F-7. > > - Currently scrutinizing the bodhi wiki page to figure out how to > > push to updates-testing/. > > - Koji build now complete > - New update created in Bodhi for mock > - Currently 'pending' for updates-testing. There seems to be a bug 0.7.0. So, I've revoked the F7 update. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242880 Clark, I believe, has a fix for this issue. I'll wait until clark has submitted his fix to master, then I will package and push 0.7.1 to both rawhide and F-7. -- Michael From jgranado at redhat.com Wed Jun 13 16:22:33 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Wed, 13 Jun 2007 18:22:33 +0200 Subject: [PATCH][PUNGI] Irregularities with the stage selection Message-ID: <467019C9.2050507@redhat.com> Hi list: Pungi has a really cool characteristic that allows the user to specify the stage that he/she wants to execute. The stages are: Gather(-G), Buildinstall(-B), Package Order(-P), Splittree (-S) and createisos (-I). It is also implemented in a way that it creates the possibility for the user to specify non continuous stages (ex. pungi -G -I). This can make pungi behave in an unwanted way. To avoid this situation there is a patch attached that defines a range instead of individual stages. In other words if the user specifies `pungi -G -I` pungi will execute -G -B -P -S and -I. Moreover if the user specifies `pungi -G` only the gathering stage will be executed. Another situation with the stages is that pungi does not verify if the stage that the user is specifying can be executed. So the user might execute the -I stage without having executed the -G stage (to say something stupid). IMO a function that at least checks if the directories that are needed are where they are suppose to be can be considered. Just a thought :) Comments greatly appreciated :) Regards. -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From ken at bitsko.slc.ut.us Wed Jun 13 16:40:42 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Wed, 13 Jun 2007 11:40:42 -0500 Subject: [PATCH 1/3] mock cvs 2007-03: cross-compile support In-Reply-To: <20070613044941.GI8637@humbolt.us.dell.com> (Michael E. Brown's message of "Tue\, 12 Jun 2007 23\:49\:41 -0500") References: <20070613044941.GI8637@humbolt.us.dell.com> Message-ID: Thanks for the excellent review, I'll rebase and implement the changes in my next coding session. Michael E Brown writes: > On Tue, Jun 12, 2007 at 09:15:13PM -0500, Ken MacLeod wrote: > Can you give an overview for the ignorant (ie. me) about the > difference between /cross and /target? Why is /cross its own > chroot-like thing? Couldnt you just say, "install this one > additional cross-buildsys-rpm, which pulls in the cross-toolchain?" I agree that that's the way it should work. You've got it right that the /cross tools are essentially part of the host environment, so the difference to /target is that target is the chroot for holding the target libraries and headers. Most cross-development toolkits assume their cross-tools install into a dedicated root and they don't do any renaming so they'd be replacing the equivalent host tools. A few do install themselves cleanly into /opt so I'll be able to test those without a cross root. RTEMS is built to install with RPM directly into the host filesystem under /opt, where MontaVista cross RPMs install under /opt but (I think) aren't set up to be in the host RPM db. When there's a good reference example for installing into the host filesystem (maybe RTEMS or MV) we can provide guidance for other distributions. -- Ken From Michael_E_Brown at dell.com Wed Jun 13 16:54:22 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 13 Jun 2007 11:54:22 -0500 Subject: [PATCH 1/3] mock cvs 2007-03: cross-compile support In-Reply-To: References: <20070613044941.GI8637@humbolt.us.dell.com> Message-ID: <20070613165422.GO8637@humbolt.us.dell.com> On Wed, Jun 13, 2007 at 11:40:42AM -0500, Ken MacLeod wrote: > Thanks for the excellent review, I'll rebase and implement the changes > in my next coding session. > > Michael E Brown writes: > > > On Tue, Jun 12, 2007 at 09:15:13PM -0500, Ken MacLeod wrote: > > > Can you give an overview for the ignorant (ie. me) about the > > difference between /cross and /target? Why is /cross its own > > chroot-like thing? Couldnt you just say, "install this one > > additional cross-buildsys-rpm, which pulls in the cross-toolchain?" > > I agree that that's the way it should work. You've got it right that > the /cross tools are essentially part of the host environment, so the > difference to /target is that target is the chroot for holding the > target libraries and headers. > > Most cross-development toolkits assume their cross-tools install into > a dedicated root and they don't do any renaming so they'd be replacing > the equivalent host tools. A few do install themselves cleanly into > /opt so I'll be able to test those without a cross root. RTEMS is > built to install with RPM directly into the host filesystem under > /opt, where MontaVista cross RPMs install under /opt but (I think) > aren't set up to be in the host RPM db. > > When there's a good reference example for installing into the host > filesystem (maybe RTEMS or MV) we can provide guidance for other > distributions. Ok, thanks. Sounds reasonable to add, as long as we document that the correct way to do it is /opt, but we are providing /cross as a backwards-compatible method while people migrate over. If you address my code review comments, and I get a consensus from Clark, these patches can go in. There was a comment last night on IRC that the patches dont apply cleanly and that maybe you missed sending a patch set or something. Please base off latest git tree, master branch when resending. You used git-format-patch to send it, which is good. Please continue to do that. -- Michael From vince.skahan at boeing.com Wed Jun 13 23:31:21 2007 From: vince.skahan at boeing.com (Skahan, Vince) Date: Wed, 13 Jun 2007 16:31:21 -0700 Subject: pungi newbie comments Message-ID: <448F0AE69241D84D8775D07C6FAB5D8E060E1FBD@XCH-NW-4V2.nw.nos.boeing.com> Let me just start with 'Wow' :-) After a few false starts figuring out how things were put together under the hood between yum and pungi, I successfully got a respin of a fully patched FC6+updates done in only a few hours start to finish. 'Very' cool stuff. Biggest problem I had was figuring out the admittedly (in hindsight) very few commands/edits needed to get the job done, as the docs in the wiki and other web references I could have were very cryptic at best. Some kind of a "getting started with pungi' doc with a simple, clear, concise, complete set of steps to follow sure would have helped. Is there such a document ? Any interest in me drafting what I did to start cooking up such a newbie's guide ? Lastly, is there any plan to have pungi be able to build live-cd images as well as the distro images ? I have a coworker who's fiddling around with the live-cd creator stuff in FC7 and we both thought that unifying the toolset might be worth thinking about. ------ vince.skahan at boeing.com ------ From jkeating at redhat.com Wed Jun 13 23:40:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 19:40:12 -0400 Subject: pungi newbie comments In-Reply-To: <448F0AE69241D84D8775D07C6FAB5D8E060E1FBD@XCH-NW-4V2.nw.nos.boeing.com> References: <448F0AE69241D84D8775D07C6FAB5D8E060E1FBD@XCH-NW-4V2.nw.nos.boeing.com> Message-ID: <200706131940.13029.jkeating@redhat.com> On Wednesday 13 June 2007 19:31:21 Skahan, Vince wrote: > Let me just start with 'Wow' :-) Thanks! > After a few false starts figuring out how things were put together under > the hood between yum and pungi, I successfully got a respin of a fully > patched FC6+updates done in only a few hours start to finish. ?'Very' > cool stuff. Awesome. It's even easier in Fedora 7. > Biggest problem I had was figuring out the admittedly (in hindsight) > very few commands/edits needed to get the job done, as the docs in the > wiki and other web references I could have were very cryptic at best. > Some kind of a "getting started with pungi' doc with a simple, clear, > concise, complete set of steps to follow sure would have helped. > > Is there such a document ? ? Any interest in me drafting what I did to > start cooking up such a newbie's guide ? I would certainly not turn down such a document. Please do! But if you do, basing it on Fedora 7 is best. > Lastly, is there any plan to have pungi be able to build live-cd images > as well as the distro images ? ?I have a coworker who's fiddling around > with the live-cd creator stuff in FC7 and we both thought that unifying > the toolset might be worth thinking about. There is a higher level tool called revisor that provides another frontend to pungi libraries and livecd-creator. It's even graphical. Give revisor a try on Fedora 7! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From msteinmann at vesbridge.com Thu Jun 14 02:20:19 2007 From: msteinmann at vesbridge.com (Martin Steinmann) Date: Wed, 13 Jun 2007 22:20:19 -0400 Subject: pungi used to create CD that includes a kickstart file References: <466F0F9F.7020309@themeyerfarm.com> <466F99BD.5060108@redhat.com> Message-ID: > >> >AFAIK pungi does not do this and it seems a very interesting feature to >add. If you have any patches just post them on the list. I'm sure >you'll get some feedback. >Regards. > >-- >Joel Andres Granados > The following is a simple patch to pungi that allows adding a kickstart file as well as customize the files in the isolinux directory. The patch is against pungi-0.3.7-1.fc7 Two new parameters are introduced to the pungi.conf file in the [default] section: kickstart = allows specifying a path to a kickstart file that is copied into the root of the ISO isolinuxdir = allows specifying a directory that contains files that should be copied into the isolinux directory. This can be used to add a new splash image or to modify the file isolinux.cfg to add the kickstart kernel parameter. Existing files are overwritten. The patch includes two additional fixes: 1) The error printout _doRunCommand was extended to print the whole command 2) There seems to be a bug in the composition of the mkisofs command. Quotation marks are missing around the volume ID (-V parameter) Patch 1: /usr/lib/python2.5/site-packages/pypungi/pungy.py ---------------------------------------------------------- [xxx at fc7 pypungi]$ diff pungi.py pungi.py.orig 77c77 < raise OSError, "Got an error from %s" % ' '.join(command) --- > raise OSError, "Got an error from %s" % command[0] 149,178d148 < #---Added < def doGetKickstart(self): < """Get kickstart file and put in the topdir of the tree.""" < < if self.config.get('default', 'kickstart') == "": < return < < kickstartinstall = ['/bin/cp'] < kickstartinstall.append(self.config.get('default', 'kickstart')) < kickstartinstall.append(self.topdir) < < # run the command < self._doRunCommand(kickstartinstall) < < #--Added < def doGetIsolinuxdir(self): < """Copy files in the directory indicated by isolinuxdir path into the /isolinux directory.""" < < if self.config.get('default', 'isolinuxdir') == "": < return < < # Some files in the isolinux directory are write-protected - use the force option < isolinuxpath = os.path.join(self.topdir, 'isolinux') < sourcepath = os.path.join(self.config.get('default', 'isolinuxdir'), '*') < if os.path.isdir(isolinuxpath): < os.system('ls -l ' + isolinuxpath) < os.system('cp --force ' + sourcepath + ' ' + isolinuxpath) < os.system('ls -l ' + isolinuxpath) < < 393c363 < extraargs.append('"%s %s %s Disc %s"' % (self.config.get('default', 'product_name'), --- > extraargs.append('%s %s %s Disc %s' % (self.config.get('default', 'product_name'), 456c426 < extraargs.append('"%s %s %s DVD"' % (self.config.get('default', 'product_name'), --- > extraargs.append('%s %s %s DVD' % (self.config.get('default', 'product_name'), Patch 2: /usr/bin/pungi ----------------------- [xxx at fc7 bin]$ diff pungi pungi.orig 35,37d34 < #---Added < kickstart = "" < isolinuxdir = "" 75,81d71 < #---Added < if not config.has_option('default', 'kickstart'): < config.set('default', 'kickstart', kickstart) < < if not config.has_option('default', 'isolinuxdir'): < config.set('default', 'isolinuxdir', isolinuxdir) < 127,129d116 < #---Added < mypungi.doGetKickstart() < mypungi.doGetIsolinuxdir() -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Thu Jun 14 09:08:33 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 14 Jun 2007 11:08:33 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <200706130910.45953.jkeating@redhat.com> References: <200706130826.13728.jkeating@redhat.com> <466FE9FE.3040806@kanarip.com> <200706130910.45953.jkeating@redhat.com> Message-ID: <46710591.9070809@kanarip.com> Jesse Keating wrote: > On Wednesday 13 June 2007 08:58:38 Jeroen van Meeuwen wrote: >> We're gonna do the same thing here, except that we also want to be able >> to add non-RPM based files to the images, for example a complete >> directory tree. Is that being added to pungi as well? > > What's stopping you from packaging up the directory tree in rpm? There are > two regex variables, one that is for files themselves and one that is for > whole directories to bring in. > Nothing is stopping me from packaging up anything. Although I still need to be able to add complete directory trees that are not packaged. That's why I asked if that is within pungi's roadmap or not. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Thu Jun 14 11:05:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 07:05:45 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: References: <466F99BD.5060108@redhat.com> Message-ID: <200706140705.46170.jkeating@redhat.com> On Wednesday 13 June 2007 22:20:19 Martin Steinmann wrote: > The following is a simple patch to pungi that allows adding a kickstart > file as well as customize the files in the isolinux directory. > > The patch is against pungi-0.3.7-1.fc7 > > Two new parameters are introduced to the pungi.conf file in the [default] > section: > > kickstart = allows specifying a path to a kickstart file that is > copied into the root of the ISO isolinuxdir = allows specifying a > directory that contains files that should be copied into the isolinux > directory. This can be used to add a new splash image or to modify the file > isolinux.cfg to add the kickstart kernel parameter. Existing files are > overwritten. So I actually don't want to see a bunch of different methods created for the simple task of getting files into the tree somehow. It really shouldn't matter what the files are, the same methodology should be used for all of them. KISS ya know? > The patch includes two additional fixes: > > 1) The error printout _doRunCommand was extended to print the whole command Hrm, the command is just a list, so by doing ' '.join(command) we get that list space separated just like it would be ran. Why would you change that? > 2) There seems to be a bug in the composition of the mkisofs command. > Quotation marks are missing around the volume ID (-V parameter) Since the command isn't ran in a "shell" if you will, quotes are not needed, and in fact if they are added you'll wind up with the quotes in your volume. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 14 11:06:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 07:06:56 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <46710591.9070809@kanarip.com> References: <200706130910.45953.jkeating@redhat.com> <46710591.9070809@kanarip.com> Message-ID: <200706140706.56545.jkeating@redhat.com> On Thursday 14 June 2007 05:08:33 Jeroen van Meeuwen wrote: > Nothing is stopping me from packaging up anything. Although I still need > to be able to add complete directory trees that are not packaged. That's > why I asked if that is within pungi's roadmap or not. I don't really think that it is. What I'm asking is /why/ the directory tree isn't packaged, or why can't it be packaged. What is the underlying real reason that you have to include an unpackaged tree? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Thu Jun 14 11:20:54 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 14 Jun 2007 13:20:54 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <200706140706.56545.jkeating@redhat.com> References: <200706130910.45953.jkeating@redhat.com> <46710591.9070809@kanarip.com> <200706140706.56545.jkeating@redhat.com> Message-ID: <46712496.2010605@kanarip.com> Jesse Keating wrote: > On Thursday 14 June 2007 05:08:33 Jeroen van Meeuwen wrote: >> Nothing is stopping me from packaging up anything. Although I still need >> to be able to add complete directory trees that are not packaged. That's >> why I asked if that is within pungi's roadmap or not. > > I don't really think that it is. What I'm asking is /why/ the directory tree > isn't packaged, or why can't it be packaged. What is the underlying real > reason that you have to include an unpackaged tree? > One example that comes to mind is a respin for different branch offices, having different kickstart files, although someone doing different kickstart files for different branch offices should be able to package it up. Another reason is that one may want to copy a tree (or files within that tree) from the install media to the installed system, like configuration files, home directories, etc. Another reason is that Revisor doesn't package things up. Kind regards, Jeroen van Meeuwen From jkeating at redhat.com Thu Jun 14 11:22:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 07:22:09 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <46712496.2010605@kanarip.com> References: <200706140706.56545.jkeating@redhat.com> <46712496.2010605@kanarip.com> Message-ID: <200706140722.09556.jkeating@redhat.com> On Thursday 14 June 2007 07:20:54 Jeroen van Meeuwen wrote: > One example that comes to mind is a respin for different branch offices, > having different kickstart files, although someone doing different > kickstart files for different branch offices should be able to package > it up. > > Another reason is that one may want to copy a tree (or files within that > tree) from the install media to the installed system, like configuration > files, home directories, etc. > > Another reason is that Revisor doesn't package things up. I see nothing in these reasons that prevents a package of the files from being created. I'm not saying no to the feature yet, I just need to think about it a bit and what it means to pungi. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Thu Jun 14 12:49:54 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 14 Jun 2007 07:49:54 -0500 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <200706140722.09556.jkeating@redhat.com> References: <200706140706.56545.jkeating@redhat.com> <46712496.2010605@kanarip.com> <200706140722.09556.jkeating@redhat.com> Message-ID: <1181825394.3879.5.camel@lt21223.campus.dmacc.edu> On Thu, 2007-06-14 at 07:22 -0400, Jesse Keating wrote: > On Thursday 14 June 2007 07:20:54 Jeroen van Meeuwen wrote: > > One example that comes to mind is a respin for different branch offices, > > having different kickstart files, although someone doing different > > kickstart files for different branch offices should be able to package > > it up. > > > > Another reason is that one may want to copy a tree (or files within that > > tree) from the install media to the installed system, like configuration > > files, home directories, etc. > > > > Another reason is that Revisor doesn't package things up. > > I see nothing in these reasons that prevents a package of the files from being > created. > > I'm not saying no to the feature yet, I just need to think about it a bit and > what it means to pungi. If you wanted to include some custom kickstart files on the CD so that you could do something like: linux ks=cdrom:/kickstart/officeworker.cfg or: linux ks=cdrom:/kickstart/webfarmserver.cfg In cases like this, the files can't be packaged up in some RPM. I'm sure that having unpacked files on the CD could be useful for some %pre and %post scripts as well. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jgranado at redhat.com Thu Jun 14 12:57:52 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 14 Jun 2007 14:57:52 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <1181825394.3879.5.camel@lt21223.campus.dmacc.edu> References: <200706140706.56545.jkeating@redhat.com> <46712496.2010605@kanarip.com> <200706140722.09556.jkeating@redhat.com> <1181825394.3879.5.camel@lt21223.campus.dmacc.edu> Message-ID: <46713B50.6040001@redhat.com> > > If you wanted to include some custom kickstart files on the CD so that > you could do something like: > > linux ks=cdrom:/kickstart/officeworker.cfg > > or: > > linux ks=cdrom:/kickstart/webfarmserver.cfg > > In cases like this, the files can't be packaged up in some RPM. What pungi does with the fedora-release and fedora-release-note packages is to rpm2cpio them into the tree. So what is left at the end are files not the rpms. What is being said is for the use to make a rpm with whatever files he/she wants to add and define the way to add them to the tree with the relnotefilere, relnotedirre, relnotepkgs variables (AFAIK these variables can be modified in the config file) The point is that what is being added is not an rpm but what is contained in the rpm (AFAIK). Please correct me if I'm wrong. Regards > I'm > sure that having unpacked files on the CD could be useful for some %pre > and %post scripts as well. > > Jeff > > -- Joel Andres Granados From jgranado at redhat.com Thu Jun 14 13:15:30 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 14 Jun 2007 15:15:30 +0200 Subject: pungi used to create CD that includes a kickstart file [PATCH] In-Reply-To: <200706140722.09556.jkeating@redhat.com> References: <200706140706.56545.jkeating@redhat.com> <46712496.2010605@kanarip.com> <200706140722.09556.jkeating@redhat.com> Message-ID: <46713F72.8060101@redhat.com> > > I see nothing in these reasons that prevents a package of the files from being > created. > AFAIK any directory can be packaged, so technically taking the directory I want to add, packaging it and putting it on the tree is possible. The only argument for the "add files without packaging" process is lazyness. IMHO it is sometimes easier to just tell pungi "please add this directory to the iso". Compared to the additional process of creating a package. Moreover the user might have to learn how exactly to do this, taking up more time. (not that learning how to package is a waist of time, but some people might not really need it :) > I'm not saying no to the feature yet, I just need to think about it a bit and > what it means to pungi. > What I propose is a simple (I think its simple:) patch to address this issue. Give the user the possibility to add *one* directory to the tree. This directory contains whatever and is specified in the config file as extra_dir. Patch is attached comments greatly appreciated Regards -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From jkeating at redhat.com Thu Jun 14 13:11:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 09:11:04 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <46713B50.6040001@redhat.com> References: <1181825394.3879.5.camel@lt21223.campus.dmacc.edu> <46713B50.6040001@redhat.com> Message-ID: <200706140911.08002.jkeating@redhat.com> On Thursday 14 June 2007 08:57:52 Joel Andres Granados wrote: > What pungi does with the fedora-release and fedora-release-note packages > is to rpm2cpio them into the tree. ?So what is left at the end are files > not the rpms. ?What is being said is for the use to make a rpm with > whatever files he/she wants to add and define the way to add them to the > tree with the relnotefilere, relnotedirre, relnotepkgs variables (AFAIK > these variables can be modified in the config file) > The point is that what is being added is not an rpm but what is > contained in the rpm (AFAIK). ?Please correct me if I'm wrong. That is absolutely correct. The method exploads the rpms into a temp dir and snags the files matching the regex to place them on the install tree, and thus the iso media. You could have all these things packaged as 'vendor-pack-foo' that drops things in /usr/share/doc/ for future reference or modification after the installation is done as well, so not only would you be able to get those files into the iso media, but you'd be able to have those files on the installed system for later reference, without having to go back to the media, or the install server, or playing games in %post. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 14 13:26:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 09:26:06 -0400 Subject: pungi used to create CD that includes a kickstart file [PATCH] In-Reply-To: <46713F72.8060101@redhat.com> References: <200706140722.09556.jkeating@redhat.com> <46713F72.8060101@redhat.com> Message-ID: <200706140926.06507.jkeating@redhat.com> On Thursday 14 June 2007 09:15:30 Joel Andres Granados wrote: > What I propose is a simple (I think its simple:) patch to address this > issue. ?Give the user the possibility to add *one* > directory to the tree. ?This directory contains whatever and is > specified in the config file as extra_dir. > Patch is attached > comments greatly appreciated While possibly reasonable for one directory, as soon as you make this capability, somebody is going to want multiple directories, or directories + files, or.... I guess the point I'm trying to make is that there is already a method in place to handle getting extra files/dirs into the tree, and there is even more value to having them in package form to be installed on the system as well. I really don't want to support N+ convenience methods for doing the same thing as that's code duplication and easy places for bugs to popup, and more places to have to change things in the future. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From msteinmann at vesbridge.com Thu Jun 14 13:57:38 2007 From: msteinmann at vesbridge.com (Martin Steinmann) Date: Thu, 14 Jun 2007 09:57:38 -0400 Subject: pungi used to create CD that includes a kickstart file [PATCH] References: <200706140722.09556.jkeating@redhat.com><46713F72.8060101@redhat.com> <200706140926.06507.jkeating@redhat.com> Message-ID: > > >On Thursday 14 June 2007 09:15:30 Joel Andres Granados wrote: >> What I propose is a simple (I think its simple:) patch to address this >> issue. Give the user the possibility to add *one* >> directory to the tree. This directory contains whatever and is >> specified in the config file as extra_dir. >> Patch is attached >> comments greatly appreciated > >While possibly reasonable for one directory, as soon as you make this >capability, somebody is going to want multiple directories, or directories + >files, or.... > >I guess the point I'm trying to make is that there is already a method in >place to handle getting extra files/dirs into the tree, and there is even >more value to having them in package form to be installed on the system as >well. I really don't want to support N+ convenience methods for doing the >same thing as that's code duplication and easy places for bugs to popup, and >more places to have to change things in the future. > Having everyting packaged is a very nice and pure approach, but IMHO it might not be user friendly enough for people to create appliances. To package everything requires a different skill set. Consider this: In order to have Anaconda start with a kickstart file, the file isolinux.cfg needs to be modified (add the kickstart kernel parameter, change the splash screen). In order to package this, I would have to go through these steps (I think): - Find the RPM package that provides isolinux.cfg (I haven't found it yet) - Patch the source and create a new custom package - Substitute the original package with the new one in the comps file, so that the original one does not get loaded as a mandatory package - Maintain that custom package going forward (It needs a different name so that yum update does not load the original one back, but that could mess up other packages that depend on it - don't know yet) The alternative seems much easier: Copy the altered isolinux.cfg file into the tree after buildinstall. Although I do agree that packaging all this is the cleaner approach. To create an appliance pungi needs to offer the ability to customize the stage 1 installation process. The stage 2 installation process can then be customized using a regular kickstart file. Althoigh I haven't yet gotten to customizing the stage2 graphics and might run into other issues there. My five cents :) --martin >-- >Jesse Keating >Release Engineer: Fedora > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Thu Jun 14 14:31:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 10:31:35 -0400 Subject: pungi used to create CD that includes a kickstart file [PATCH] In-Reply-To: References: <200706140926.06507.jkeating@redhat.com> Message-ID: <200706141031.38990.jkeating@redhat.com> On Thursday 14 June 2007 09:57:38 Martin Steinmann wrote: > - Find the RPM package that provides isolinux.cfg (I haven't found it yet) > - Patch the source and create a new custom package > - Substitute the original package with the new one in the comps file, so > that the original one does not get loaded as a mandatory package - Maintain > that custom package going forward (It needs a different name so that yum > update does not load the original one back, but that could mess up other > packages that depend on it - don't know yet) > > The alternative seems much easier: Copy the altered isolinux.cfg file into > the tree after buildinstall. Although I do agree that packaging all this is > the cleaner approach. > > To create an appliance pungi needs to offer the ability to customize the > stage 1 installation process. The stage 2 installation process can then be > customized using a regular kickstart file. Althoigh I haven't yet gotten to > customizing the stage2 graphics and might run into other issues there. When you're to this point, you probably just want to modify anaconda directly. Anaconda(-runtime) is what writes out the isolinux config files. You're going to be modifying a bunch of other stuff if you're going to be producing an appliance, trademark and copyright usage and all that jazz. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Thu Jun 14 14:34:43 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 14 Jun 2007 16:34:43 +0200 Subject: pungi used to create CD that includes a kickstart file [PATCH] In-Reply-To: <200706140926.06507.jkeating@redhat.com> References: <200706140722.09556.jkeating@redhat.com> <46713F72.8060101@redhat.com> <200706140926.06507.jkeating@redhat.com> Message-ID: <46715203.9020208@redhat.com> All this talk about pungi has made me realize that it might have a little bug when handling the three variables (relnotefilere, relnotedirre and relnotepkgs). If the user specifies these variables in the config file, the values specified in pungi will be ignored. This means that the release notes, images ... will be ignored. patch is attached.... -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From kanarip at kanarip.com Thu Jun 14 14:55:59 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 14 Jun 2007 16:55:59 +0200 Subject: pungi used to create CD that includes a kickstart file [PATCH] In-Reply-To: <46715203.9020208@redhat.com> References: <200706140722.09556.jkeating@redhat.com> <46713F72.8060101@redhat.com> <200706140926.06507.jkeating@redhat.com> <46715203.9020208@redhat.com> Message-ID: <467156FF.5040408@kanarip.com> Joel Andres Granados wrote: > All this talk about pungi has made me realize that it might have a > little bug when handling the three variables (relnotefilere, > relnotedirre and relnotepkgs). If the user specifies these variables in > the config file, the values specified in pungi will be ignored. This > means that the release notes, images ... will be ignored. I think though that is a good thing. The user should customize Fedora by adding configuration, but may as well want MyDistro to be composed by pungi, and thus needs some way to override the "hard-coded" values. Kind regards, Jeroen van Meeuwen -kanarip From Michael_E_Brown at dell.com Thu Jun 14 20:16:17 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 14 Jun 2007 15:16:17 -0500 Subject: dropping legacy mock configs in next release Message-ID: <20070614201616.GA26959@humbolt.us.dell.com> The next mock rpm release (0.7.2) will drop configs for RH 7.3/8/9 and Fedora Core releases < 6. These configs will remain in the git repository under etc/legacy/ for a while yet. Will probably remove them on the next major release. Going forward, policy for mock will be that we maintain mock configs for currently supported operating systems. If anybody else wishes to take over and release a 'mock-legacy-configs' RPM, please let me know, as you are welcome to it. I'm sure that there are people out there still using these configs, but I think that those continuing to use these configs can probably maintain their own local copy. -- Michael From jgranado at redhat.com Fri Jun 15 14:20:52 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 15 Jun 2007 16:20:52 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <200706140926.06507.jkeating@redhat.com> References: <200706140722.09556.jkeating@redhat.com> <46713F72.8060101@redhat.com> <200706140926.06507.jkeating@redhat.com> Message-ID: <4672A044.6060200@redhat.com> > While possibly reasonable for one directory, as soon as you make this > capability, somebody is going to want multiple directories, or directories + > files, or.... > Ok, so we give them the possibility of adding files and directories with a extras configuration variable. In pungi we can split it and that will be the list of additions to the os/ root. > I guess the point I'm trying to make is that there is already a method in > place to handle getting extra files/dirs into the tree, and there is even > more value to having them in package form to be installed on the system as > well. I really don't want to support N+ convenience methods for doing the > same thing as that's code duplication and easy places for bugs to popup, and > more places to have to change things in the future. > I'm totally with you on this one. Its just easier (less bugs, less work, as simple as possible :) to handle one way of doing stuff. But I worry about the user :(.... There are some situations where the current method is a bit cumbersome (Please correct me if I'm wrong on any of them): 1. lets say I want to put every file that is in a certain package. Intuitively I add a "/*" to the file variable. This includes, not only all the files in my package, but also includes all the files in the default packages (fedora-release fedora-release-notes) 2. Same thing happens if I specify a regular expression. If I define it correctly it will find all my files and include them, but it might also find other files from other packages that I really don't want in the spin. 3. I can also have two packages that define the same path to various files (crazy hypothetical situation), so depending on the order in which they are seen by the doGetRelnotes function one will overwrite the other :( resulting in inconsistent behavior. This, of course, is not pungis fault but as files and directories are in packages it is harder to notice a bug like this. IMHO its best to keep the process of adding the release notes as it is and have another function handle the addition of the directories/files. Instead of (getPackages->downloadPackages->Dobuildinstall->doGetRelnote->doPackageorder...) I would include a getAdditionalfiles step between doGetRelnotes and doPackageorder. Just a suggestion Regards -- Joel Andres Granados From jgranado at redhat.com Fri Jun 15 16:06:53 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 15 Jun 2007 18:06:53 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: References: Message-ID: <4672B91D.2060002@redhat.com> Martin Steinmann wrote: > > Using pungi on F7 I would like to create a CD that includes a > kickstart file to be used during installation of a system using this CD. > > > > Is there a way to tell pungi to put a ks.cfg file into the root of the > CD and modify isolinux.cfg? > > > > Thanks > > --martin > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Hi list. Wrote a little something for the people that want to add files in the current version of pungi. Its basically the process that worked for me. Comments greatly appreciated Regards -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AddingFileDirectoryToPungi URL: From Axel.Thimm at ATrpms.net Fri Jun 15 21:06:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 23:06:38 +0200 Subject: Build once, serve many Message-ID: <20070615210638.GB32080@neu.nirvana> Hi, some packages are best build for all releases once only like for example firmware, game data and other packages that you know will not change from release to release. Currently such operations are made manually and one needs to find the right person to talk to. I think it would be more consistent if koji and friends allowed one to tag a package as such. Perhaps koji's tagging is alread enought to "hardlink" a package source and binary-wise across releases? If so, please enlighten me with the mechanism details, if not, please consider this an RFE. :) -- 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 Fri Jun 15 22:10:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 15 Jun 2007 18:10:13 -0400 Subject: Build once, serve many In-Reply-To: <20070615210638.GB32080@neu.nirvana> References: <20070615210638.GB32080@neu.nirvana> Message-ID: <200706151810.16586.jkeating@redhat.com> On Friday 15 June 2007 17:06:38 Axel Thimm wrote: > Hi, > > some packages are best build for all releases once only like for > example firmware, game data and other packages that you know will not > change from release to release. > > Currently such operations are made manually and one needs to find the > right person to talk to. I think it would be more consistent if koji > and friends allowed one to tag a package as such. Perhaps koji's > tagging is alread enought to "hardlink" a package source and > binary-wise across releases? > > If so, please enlighten me with the mechanism details, if not, please > consider this an RFE. :) Tagging is essentially hardlinking. Only one copy of a build exists on the file system. If you "tag" that build with multiple tags, it'll be considered when dealing with said tags. There are some rules however about what tags can be applied. I think there are some things that will stop you from tagging a build for a tag that was originally done in a buildroot that is not associated with that tag through inheritance, IE building something in the dist-epel4 buildroot, then tagging that build with dist-f8, or dist-olpc2. If there is no inheritance link I don't think it'll allow you to tag. Also due to inheritance, say you have a package frobits that was built during dist-f7 development time and is tagged for dist-fc7. dist-f8 has never seen a build, it inherits that dist-fc7 one. dist-f9 comes along, and it inherits that build as well. If you have to do an update, you do an update on the lowest tag first, and the upper tags will inherit that /new/ build as well. Inheritance stops as soon as a given "tag" is specifically applied to a build/package. If you build for dist-fc7, then 'tag' it for dist-f8, then do another build on dist-fc7, dist-f8 won't see the "new" build in dist-fc7, it'll continue to "see" the specifically dist-f8 tagged build. It's a little confusing to write up, but once you understand how inheritance works it begins to make sense. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 16 12:11:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 16 Jun 2007 08:11:30 -0400 Subject: mock update in testing doesn't fix glibc-devel.i386 problem Message-ID: <200706160811.33437.jkeating@redhat.com> Seems the fix I made to config files either never got committed to my branch or got lost in the shuffle, but we wound up not fixing the bug and I didn't notice until now (since I was using locally modified config files). I've fixed it again in HEAD, so we should probably respin the update or just leave it in there to be picked up in the next update. Not sure, we're already messing with config files a lot, may be worth doing it now when everybody will have to re-review the config files and re-do any local modification. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From distro at getsmart.com.br Sat Jun 16 15:05:37 2007 From: distro at getsmart.com.br (=?ISO-8859-1?Q?Francisco_Andr=E9?=) Date: Sat, 16 Jun 2007 12:05:37 -0300 Subject: problems installing on sata controllers Message-ID: <4673FC41.1050801@getsmart.com.br> Hi all! I'm having some problems when I install fedora 7 using kickstart in a custom distro. 1 - It never install if the machine use a sis contrller IDE or SATA. It seems that the partitions is created but whrn anaconda try to format the partitions all partitions is removed again and the installer only gives me a reboot option! 2 - I'm need to put some custom packages on the distro. I've edited the comps-f7.xml and add the custom packages, but when the install starts anaconda complains that all the custom packages that I add was not found on the cd. I'm sure that the packages is on the Fedora directory of the CD. Thanks for you help! From Michael_E_Brown at Dell.com Sat Jun 16 15:14:20 2007 From: Michael_E_Brown at Dell.com (Michael_E_Brown at Dell.com) Date: Sat, 16 Jun 2007 10:14:20 -0500 Subject: mock update in testing doesn't fix glibc-devel.i386 problem References: <200706160811.33437.jkeating@redhat.com> Message-ID: Which packages break compilation without this fix? I'd be willing to spin 0.7.2. I've bumped the versions to 0.7.2 and pushed that. I wouldnt be able to do a fedora update until tomorrow, though. -- Michael -----Original Message----- From: fedora-buildsys-list-bounces at redhat.com on behalf of Jesse Keating Sent: Sat 6/16/2007 7:11 AM To: fedora-buildsys-list at redhat.com Subject: mock update in testing doesn't fix glibc-devel.i386 problem Seems the fix I made to config files either never got committed to my branch or got lost in the shuffle, but we wound up not fixing the bug and I didn't notice until now (since I was using locally modified config files). I've fixed it again in HEAD, so we should probably respin the update or just leave it in there to be picked up in the next update. Not sure, we're already messing with config files a lot, may be worth doing it now when everybody will have to re-review the config files and re-do any local modification. -- Jesse Keating Release Engineer: Fedora From esammons at hush.com Sat Jun 16 22:42:35 2007 From: esammons at hush.com (Earl) Date: Sat, 16 Jun 2007 18:42:35 -0400 Subject: problems installing on sata controllers Message-ID: <20070616224236.298E72281F@mailserver9.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 16 Jun 2007 11:05:37 -0400 Francisco Andr? wrote: >Hi all! I'm having some problems when I install fedora 7 using >kickstart in a custom distro. > >1 - It never install if the machine use a sis contrller IDE or >SATA. It seems that the partitions is created but whrn anaconda > try to format the partitions all partitions is removed again > and the installer only gives me a reboot option! Sonds like more of a general hardware compatibility / installation issue to me. Try flipping BIOS values for the SATA stuff... Look for somehting like "compatibility" mode or similar. >2 - I'm need to put some custom packages on the distro. I've > edited the comps-f7.xml and add the custom packages, but when > the install starts anaconda complains that all the custom > packages that I add was not found on the cd. I'm sure that > the packages is on the Fedora directory of the CD. I've not even seen F7 yet but in FC6 land, sounds like 'creatrepo' was skipped (total guess). Earl -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkZ0Y0UACgkQk7+e+4lPSm0SxACeP88x5fnPt2+7unwL6xnl0ptLWGQA nRiJrln7Up10wu78xJQ6HhXZl0mh =tz0m -----END PGP SIGNATURE----- From pochi_ken at hotmail.com Sun Jun 17 05:54:36 2007 From: pochi_ken at hotmail.com (=?iso-2022-jp?B?GyRCJF0kQSQxJHMbKEI=?=) Date: Sun, 17 Jun 2007 14:54:36 +0900 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). Message-ID: Hi, everyone. This pungi's patch is able to create easily CD/DVD that inclde update RPM packages (exclude old PRM packages automatically). Apply a patch and add line below to yum.conf.f7.i386 . #------------------------- exclude=*debuginfo* [fedorai-update]name=Fedora 7 - updatebaseurl=http://[mirror site URL]/fedora/updates/7/i386/enabled=1gpgcheck=0 #------------------------- Example of execution. #pungi -c /etc/pungi/f7-fedora.i386 We can create a DVD that use a new kernel package and update packages. And to rebuilt anaconda installer that use a new kernel. Have a nice day! Best regards. --- /usr/lib/python2.5/site-packages/pypungi/gather.py 2007-05-26 07:15:48.000000000 +0900+++ /usr/lib/python2.5/site-packages/pypungi/gather.py.new 2007-06-16 07:14:07.000000000 +0900@@ -387,3 +387,54 @@ shutil.copy2(path, local) os.link(local, os.path.join(pkgdir, os.path.basename(remote)))+++ # Add removeOldPackages 20070616 Pochi_ken + def removeOldPackages(self):+ """Cycle through the check of rpms and+ update the package objects and delete the old package objects."""++ pkgdir = os.path.join(self.config.get('default', 'destdir'),+ self.config.get('default', 'version'), + self.config.get('default', 'flavor'), + self.config.get('default', 'arch'), + self.config.get('default', 'osdir'),+ self.config.get('default', 'product_path'))+ local = sel! f.config.get('default','cachedir') + '/'+ localfiles = os.listdir(local)+ trot = yum.rpmUtils.transaction.initReadOnlyTransaction()+ rpmlst = []+ for filename in localfiles:+ rpmfile = local + filename+ try:+ hdr = yum.rpmUtils.miscutils.hdrFromPackage(trot, rpmfile)+ rpmlst.append((rpmfile, hdr))+ self.logger.info("Reading header info from %s" % rpmfile)+ except:+ self.logger.info("Could not read header info in %s" % rpmfile)+ rpmlst.sort()+ c = 0+ oldrpmlst = []+ while (c < (len(rpmlst)-1)):+ i = 1+ while (i < 5):+ cRPMpkg = yum.rpmUtils.miscutils.pkgTupleFromHeader(rpmlst[c][1])+ nRPMpkg = yum.rpmUtils.miscutils.pkgTupleFromHeader(rpmlst[c+i][1])+ if (cRPMpkg[0] == nRPMpkg[0]) and (cRPMpkg[1] == nRPMpkg[1]):+ cRPMEVR = cRPMpkg[2:]+ ! nRPMEVR = nRPMpkg[2:]+ if yum.rp! mUtils.m iscutils.compareEVR(nRPMEVR, cRPMEVR) == 1:+ oldrpmlst.append(rpmlst[c][0])+ else:+ oldrpmlst.append(rpmlst[c+i][0])+ rpmlst.pop(c+i)+ c = c-1+ i = i+1+ if ((c+i) > (len(rpmlst)-1)):+ i = 5+ c = c+1+ for filename in oldrpmlst:+ self.logger.info("Old package %s is removed." % filename)+ os.remove(filename)+ os.remove(os.path.join(pkgdir, os.path.basename(filename)))+ # END removeOldPackage--- /usr/bin/pungi 2007-05-31 01:30:29.000000000 +0900+++ /usr/bin/pungi.new 2007-06-13 22:21:15.000000000 +0900@@ -101,13 +101,17 @@ # Actually do work. if not config.get('default', 'arch') == 'source':+ mygather = pypungi.gather.Gather(config, pkglist) if opts.do_all or opts.do_gather:- mygather = pypungi.gather.Gather(config, pkglist) ! mygather.getPackageObjects() mygather.downloadPackages()- if config.getboolean('default', 'getsource'):- mygather.getSRPMList()- mygather.downloadSRPMs()++ if opts.do_all or opts.do_remove:+ mygather.removeOldPackages()++ if config.getboolean('default', 'getsource'):+ mygather.getSRPMList()+ mygather.downloadSRPMs() mypungi = pypungi.pungi.Pungi(config) @@ -153,6 +157,8 @@ help="Enable ALL stages") parser.add_option("-G", action="store_true", default=False, dest="do_gather", help="Flag to enable processing the Gather stage")+ parser.add_option("-R", action="store_true", default=False, dest="do_remove",+ help="Flag to enable processing the Remove stage") parser.add_option("-B", action="store_true", default=False, dest="do_buildinstall", help="Flag to enable processing the BuildInstall stage") par! ser.add_option("-P", action="store_true", default=False, dest=! "do_pack ageorder",@@ -164,7 +170,7 @@ (opts, args) = parser.parse_args()- if opts.do_gather or opts.do_buildinstall or opts.do_packageorder or opts.do_splittree or opts.do_createiso:+ if opts.do_gather or opts.do_remove or opts.do_buildinstall or opts.do_packageorder or opts.do_splittree or opts.do_createiso: opts.do_all = False if len(sys.argv) < 2: parser.print_help() _________________________________________________________________ Windows Vista ?????? http://search.msn.co.jp/results.aspx?q=windows+vista&FORM=MSNH&cp=65001 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sun Jun 17 13:17:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Jun 2007 09:17:08 -0400 Subject: mock update in testing doesn't fix glibc-devel.i386 problem In-Reply-To: References: <200706160811.33437.jkeating@redhat.com> Message-ID: <200706170917.11433.jkeating@redhat.com> On Saturday 16 June 2007 11:14:20 Michael_E_Brown at dell.com wrote: > Which packages break compilation without this fix? A couple I know off the top of my head is grub and syslinux. They both need to build 32bit. > I'd be willing to spin 0.7.2. I've bumped the versions to 0.7.2 and pushed > that. I wouldnt be able to do a fedora update until tomorrow, though. That's fine, I'd hope to see some more feedback on the other bugs we're fixing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 17 13:19:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Jun 2007 09:19:10 -0400 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: References: Message-ID: <200706170919.10369.jkeating@redhat.com> On Sunday 17 June 2007 01:54:36 ???? wrote: > This pungi's patc This patch is formatted terribly. I suspect hotmail did it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sun Jun 17 13:55:34 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 17 Jun 2007 15:55:34 +0200 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: References: Message-ID: <46753D56.8030909@kanarip.com> ???? wrote: > Hi, everyone. > > This pungi's patch is able to create easily CD/DVD that inclde update > RPM packages (exclude old PRM packages automatically). > Apply a patch and add line below to yum.conf.f7.i386 . > #------------------------- > exclude=*debuginfo* > > [fedorai-update] > name=Fedora 7 - update > baseurl=http://[mirror site URL]/fedora/updates/7/i386/ > enabled=1 > gpgcheck=0 > #------------------------- > > Example of execution. > #pungi -c /etc/pungi/f7-fedora.i386 > > We can create a DVD that use a new kernel package and update packages. > And to rebuilt anaconda installer that use a new kernel. > This is what Revisor does exactly. Kind regards, Jeroen van Meeuwen -kanarip From ivazqueznet at gmail.com Sun Jun 17 14:26:05 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 17 Jun 2007 10:26:05 -0400 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: <200706170919.10369.jkeating@redhat.com> References: <200706170919.10369.jkeating@redhat.com> Message-ID: <1182090365.21142.1.camel@ignacio.lan> On Sun, 2007-06-17 at 09:19 -0400, Jesse Keating wrote: > On Sunday 17 June 2007 01:54:36 ???? wrote: > > This pungi's patc > > This patch is formatted terribly. I suspect hotmail did it. Oddly enough, it looks fine in the web interface. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pochinet.org at gmail.com Sun Jun 17 15:02:18 2007 From: pochinet.org at gmail.com (pochi_ken) Date: Mon, 18 Jun 2007 00:02:18 +0900 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: <1182090365.21142.1.camel@ignacio.lan> References: <200706170919.10369.jkeating@redhat.com> <1182090365.21142.1.camel@ignacio.lan> Message-ID: <7f6dd19f0706170802u77081613pbc8309fce13c38b4@mail.gmail.com> 2007/6/17, Ignacio Vazquez-Abrams : > On Sun, 2007-06-17 at 09:19 -0400, Jesse Keating wrote: > > On Sunday 17 June 2007 01:54:36 ???? wrote: > > > This pungi's patc > > > > This patch is formatted terribly. I suspect hotmail did it. > > Oddly enough, it looks fine in the web interface. I'm sorry. I used rich text form on hotmail. Is it cause? I used text form on Gmail this time. Is this mail formatted correctly? From pochinet.org at gmail.com Sun Jun 17 15:48:00 2007 From: pochinet.org at gmail.com (pochi_ken) Date: Mon, 18 Jun 2007 00:48:00 +0900 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: <46753D56.8030909@kanarip.com> References: <46753D56.8030909@kanarip.com> Message-ID: <7f6dd19f0706170848w4dd3b8e3j2ddd656baf0b1531@mail.gmail.com> >2007/6/17, Jeroen van Meeuwen : > pochi_ken wrote: > > Hi, everyone. > > > > This pungi's patch is able to create easily CD/DVD that inclde update > > RPM packages (exclude old PRM packages automatically). > > Apply a patch and add line below to yum.conf.f7.i386 . > > #------------------------- > > exclude=*debuginfo* > > > > [fedorai-update] > > name=Fedora 7 - update > > baseurl=http://[mirror site URL]/fedora/updates/7/i386/ > > enabled=1 > > gpgcheck=0 > > #------------------------- > > > > Example of execution. > > #pungi -c /etc/pungi/f7-fedora.i386 > > > > We can create a DVD that use a new kernel package and update packages. > > And to rebuilt anaconda installer that use a new kernel. > > > > This is what Revisor does exactly. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > Yes, that's right. It is an example. I downloaded the rpm files from Fedora & Fedora Update repository. And downloaded old & new rpm packages mixed. Is this correct? I'm not fond that the old files are included. But created ISO images include the old rpm files. Therefore, the patch was made. Is this function already include on pungi? (The function that exclude the old rpm files) From kanarip at kanarip.com Sun Jun 17 16:09:27 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 17 Jun 2007 18:09:27 +0200 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: <7f6dd19f0706170848w4dd3b8e3j2ddd656baf0b1531@mail.gmail.com> References: <46753D56.8030909@kanarip.com> <7f6dd19f0706170848w4dd3b8e3j2ddd656baf0b1531@mail.gmail.com> Message-ID: <46755CB7.9010301@kanarip.com> pochi_ken wrote: > I downloaded the rpm files from Fedora & Fedora Update repository. And > downloaded old & new rpm packages mixed. Is this correct? > I'm not fond that the old files are included. But created ISO images > include the old rpm files. Therefore, the patch was made. > Is this function already include on pungi? (The function that exclude > the old rpm files) That function is in Revisor. Revisor downloads the RPMs after dependency resolving and thus excludes obsoleted versions of RPMs and they will thus not be downloaded. Kind regards, Jeroen van Meeuwen -kanarip From pochinet.org at gmail.com Sun Jun 17 16:28:17 2007 From: pochinet.org at gmail.com (pochi_ken) Date: Mon, 18 Jun 2007 01:28:17 +0900 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: <46755CB7.9010301@kanarip.com> References: <46753D56.8030909@kanarip.com> <7f6dd19f0706170848w4dd3b8e3j2ddd656baf0b1531@mail.gmail.com> <46755CB7.9010301@kanarip.com> Message-ID: <7f6dd19f0706170928u3e21f8f1qb0528343f657ff59@mail.gmail.com> 2007/6/18, Jeroen van Meeuwen : > pochi_ken wrote: > > I downloaded the rpm files from Fedora & Fedora Update repository. And > > downloaded old & new rpm packages mixed. Is this correct? > > I'm not fond that the old files are included. But created ISO images > > include the old rpm files. Therefore, the patch was made. > > Is this function already include on pungi? (The function that exclude > > the old rpm files) > > That function is in Revisor. Revisor downloads the RPMs after dependency > resolving and thus excludes obsoleted versions of RPMs and they will > thus not be downloaded. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > Thanks. I try revisor. From jkeating at redhat.com Wed Jun 20 02:26:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Jun 2007 22:26:23 -0400 Subject: [PATCH]Create CD/DVD that include update RPM packages(exclude old RPM packages). In-Reply-To: References: Message-ID: <200706192226.26700.jkeating@redhat.com> On Sunday 17 June 2007 01:54:36 ???? wrote: > This pungi's patch is able to create easily CD/DVD that inclde update RPM > packages (exclude old PRM packages automatically). Apply a patch and add > line below to yum.conf.f7.i386 . I reviewed this and I'm not happy with the way this fixes it. Instead I wanted to track down how duplicate packages are getting into the transaction set. So I did some tests and found that in depsolving I wasn't reducing the list of dep resolvers to just the newest packages. http://hg.fedoraproject.org/hg/hosted/pungi?cs=9f9a18d15637 This change set corrects that by creating a package sack for the list of resolvers, then gets the newest one out of that sack to be added to the over all transaction set. I'll be releasing an update to Fedora 7 that includes this change set. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 20 21:05:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Jun 2007 17:05:46 -0400 Subject: Fwd: Fedora 7 Test Update: pungi-0.3.7-2.fc7 Message-ID: <200706201705.49442.jkeating@redhat.com> Per earlier thread, this should fix the duplicate packages issues. If you guys could test this and let me know I'd appreciate it. ---------- Forwarded Message ---------- Subject: Fedora 7 Test Update: pungi-0.3.7-2.fc7 Date: Wednesday 20 June 2007 From: updates at fedoraproject.org To: fedora-test-list at redhat.com -------------------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2007-0579 2007-06-20 13:00:30.949566 -------------------------------------------------------------------------------- Name : pungi Product : Fedora 7 Version : 0.3.7 Release : 2.fc7 Summary : Distribution compose tool Description : A tool to create anaconda based installation trees/isos of a set of rpms. -------------------------------------------------------------------------------- Update Information: When using pungi with both Fedora 7 and Fedora 7 updates repos to respin Fedora 7 with updates pungi would pull in both the original Fedora 7 package and the Fedora 7 update package as well. This was due to how dep resolution was being done. This update fixes this bug so that only the newest version of a dep resolver will be pulled in. -------------------------------------------------------------------------------- ChangeLog: * Wed Jun 20 2007 Jesse Keating - 0.3.7-2 - Fix a bug where new and old copies of a package were being included * Wed May 30 2007 Jesse Keating - 0.3.7-1 - Handle the cdsize variable correctly - More fixes for cached download stuff - Fix default CD size storing - Update comps file with what shipped for F7 * Fri May 25 2007 Jesse Keating - 0.3.6-1 - Handle the cdsize variable correctly -------------------------------------------------------------------------------- Updated packages: 1ffb4d5a9bd955fb91fe039b245a8f9818aff159 pungi-0.3.7-2.fc7.noarch.rpm 01542aff5238389e27b0775aa9e02ad0bf26fcf4 pungi-0.3.7-2.fc7.src.rpm This update can be installed with the 'yum' update program. Use 'yum update package-name' at the command line. For more information, refer to 'Managing Software with yum,' available at http://docs.fedoraproject.org/yum/. -------------------------------------------------------------------------------- -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list ------------------------------------------------------- -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Thu Jun 21 12:33:59 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 21 Jun 2007 14:33:59 +0200 Subject: Fwd: Fedora 7 Test Update: pungi-0.3.7-2.fc7 In-Reply-To: <200706201705.49442.jkeating@redhat.com> References: <200706201705.49442.jkeating@redhat.com> Message-ID: <467A7037.3050109@redhat.com> Jesse Keating wrote: > Per earlier thread, this should fix the duplicate packages issues. If you > guys could test this and let me know I'd appreciate it. > > ---------- Forwarded Message ---------- > > Subject: Fedora 7 Test Update: pungi-0.3.7-2.fc7 > Date: Wednesday 20 June 2007 > From: updates at fedoraproject.org > To: fedora-test-list at redhat.com > > -------------------------------------------------------------------------------- > Fedora Test Update Notification > FEDORA-2007-0579 > 2007-06-20 13:00:30.949566 > -------------------------------------------------------------------------------- > > Name : pungi > Product : Fedora 7 > Version : 0.3.7 > Release : 2.fc7 > Summary : Distribution compose tool > Description : > A tool to create anaconda based installation trees/isos of a set of rpms. > > -------------------------------------------------------------------------------- > Update Information: > > When using pungi with both Fedora 7 and Fedora 7 updates repos to respin > Fedora 7 with updates pungi would pull in both the original Fedora 7 package > and the Fedora 7 update package as well. This was due to how dep resolution > was being done. This update fixes this bug so that only the newest version > of a dep resolver will be pulled in. > -------------------------------------------------------------------------------- > ChangeLog: > > * Wed Jun 20 2007 Jesse Keating - 0.3.7-2 > - Fix a bug where new and old copies of a package were being included > * Wed May 30 2007 Jesse Keating - 0.3.7-1 > - Handle the cdsize variable correctly > - More fixes for cached download stuff > - Fix default CD size storing > - Update comps file with what shipped for F7 > * Fri May 25 2007 Jesse Keating - 0.3.6-1 > - Handle the cdsize variable correctly > -------------------------------------------------------------------------------- > Updated packages: > > 1ffb4d5a9bd955fb91fe039b245a8f9818aff159 pungi-0.3.7-2.fc7.noarch.rpm > 01542aff5238389e27b0775aa9e02ad0bf26fcf4 pungi-0.3.7-2.fc7.src.rpm > > This update can be installed with the 'yum' update program. Use 'yum update > package-name' at the command line. For more information, refer to 'Managing > Software with yum,' available at http://docs.fedoraproject.org/yum/. > -------------------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list I did a hg clone http://hg.fedoraproject.org/hg/hosted/pungi and tested pungi with that code. Tested it with a minimal manifest. I checked a few packages to see which one was included in the final tree (the old one, updated one or both). For all of them I saw, only the updated ones were included in the final tree. Regards. -- Joel Andres Granados From pochi_ken at hotmail.com Thu Jun 21 13:06:19 2007 From: pochi_ken at hotmail.com (=?iso-2022-jp?B?GyRCJF0kQSQxJHMbKEI=?=) Date: Thu, 21 Jun 2007 22:06:19 +0900 Subject: Fedora 7 Test Update: pungi-0.3.7-2.fc7 Message-ID: > From: jkeating at redhat.com> To: fedora-buildsys-list at redhat.com> Date: Wed, 20 Jun 2007 17:05:46 -0400> Subject: Fwd: Fedora 7 Test Update: pungi-0.3.7-2.fc7> > Per earlier thread, this should fix the duplicate packages issues. If you > guys could test this and let me know I'd appreciate it.> > ---------- Forwarded Message ----------> > Subject: Fedora 7 Test Update: pungi-0.3.7-2.fc7> Date: Wednesday 20 June 2007> From: updates at fedoraproject.org> To: fedora-test-list at redhat.com> > --------------------------------------------------------------------------------> Fedora Test Update Notification> FEDORA-2007-0579> 2007-06-20 13:00:30.949566> --------------------------------------------------------------------------------> > Name : pungi> Product : Fedora 7> Version : 0.3.7> Release : 2.fc7> Summary : Distribution compose tool> Description :> A tool to create anaconda based installation trees/isos of a set of rpms.> > -----------------------------------------------------------! ---------------------> Update Information:> > When using pungi with both Fedora 7 and Fedora 7 updates repos to respin > Fedora 7 with updates pungi would pull in both the original Fedora 7 package > and the Fedora 7 update package as well. This was due to how dep resolution > was being done. This update fixes this bug so that only the newest version > of a dep resolver will be pulled in.> --------------------------------------------------------------------------------> ChangeLog:> > * Wed Jun 20 2007 Jesse Keating - 0.3.7-2> - Fix a bug where new and old copies of a package were being included> * Wed May 30 2007 Jesse Keating - 0.3.7-1> - Handle the cdsize variable correctly> - More fixes for cached download stuff> - Fix default CD size storing> - Update comps file with what shipped for F7> * Fri May 25 2007 Jesse Keating - 0.3.6-1> - Handle the cdsize variable correctly> ------------------------------------! --------------------------------------------> Updated packages! :> Tested it with a Everything manifest. I checked, ISO image included only the newest version. _________________________________________________________________ Windows Vista ?????? http://search.msn.co.jp/results.aspx?q=windows+vista&FORM=MSNH&cp=65001 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pepper.com Thu Jun 21 13:52:20 2007 From: steve at pepper.com (Steve Magoun) Date: Thu, 21 Jun 2007 09:52:20 -0400 Subject: pungi used to create CD that includes a kickstart file Message-ID: <048EB74D-7171-40B3-AD12-7A3901F31729@pepper.com> Hi, Given the discussion about adding kickstart files to a DVD, I thought I'd add my experience with Fedora 7. We're using pungi 0.3.5 to create a custom F7 install DVD that includes multiple kickstarts on the DVD. I've hacked pungi to add our kickstart files to the installer's boot menu. This way non-technical users can select a kickstart at install time by choosing a menu item rather than typing. We've found it quite useful, perhaps others will too. Here's what we do: 1) Package all kickstart files in a kickstart-config RPM and deploy the RPM to our repository. The RPM is setup so that kickstart files go into /kickstart: %install rm -rf $RPM_BUILD_ROOT install -d -m 0755 $RPM_BUILD_ROOT/kickstart for file in kickstart/* ; do install -p -m 0644 $file $RPM_BUILD_ROOT/kickstart done [...] %files %defattr(-,root,root,-) %dir /kickstart /kickstart/* 2) Add the kickstart-config RPM to the pungi manifest 3) Add our kickstart RPM + files to the relnote entries of pungi's config file: relnotepkgs = fedora-release fedora-release-notes kickstart-config relnotedirre = images stylesheet-images kickstart 4) Hack pungi to add our kickstart files to isolinux.cfg. Not pretty, but it gets the job done for us: -------------- next part -------------- A non-text attachment was scrubbed... Name: pungi-add-kickstart-to-boot-menu.patch Type: application/octet-stream Size: 1158 bytes Desc: not available URL: -------------- next part -------------- 5) Run pungi Thanks to Jesse + others for an excellent set of tools! Steve From Axel.Thimm at ATrpms.net Thu Jun 21 20:17:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Jun 2007 22:17:09 +0200 Subject: bodhi and security updates/updates-testing Message-ID: <20070621201709.GC27476@puariko.nirvana> Hi, I created a new update which was a security relevant update and was marked as such. bodhi offered me the possibility to push into testing or stable. I think the push into stable was offered only because it was maerked a security sensitive, so updates-testing could be shortcutted. I also know that the default policy was for security updates to bypass updates-testing entirely. Still, the system offered my to go testing or stable, and I chose testing. The update later was simply saying that a request was made to move it, but not whereto. A while later the package made it into stable. I'm not saying to change the policy, just noting a discrepancy in the application's workflow. Thanks! -- 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 katzj at redhat.com Thu Jun 21 20:18:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 21 Jun 2007 16:18:35 -0400 Subject: Integrating deltarpm creation Message-ID: <1182457115.9023.23.camel@aglarond.local> One of the things that we're looking at for Fedora 8 is how to integrate deltarpms and the presto yum plugin so that we can reduce the amount that our users have to download. To make this happen, though, is going to require some work on the side of the build system and compose tools so that we can generate these without any real problems. Based on the discussion Jesse and I were having driving home yesterday, we came to the following as a proposal. (Note: any errors here are probably mine since I transcribed it a while after the conversation). The first thing is that it makes the most sense for the deltas to be created and stored by koji rather than as a secondary process. This adds the advantage that they're stored consistently with the packages and also can be cached rather than recreated every time. It feels somewhat analagous to me to the current situation with signing. To handle the case of deltas for updates, we can have a step either happen pre-mash or early in mash to call out to koji to create deltas. We'll want to be creating the delta for dist-fX-GA -> the update as well as the latest package in dist-FX-updates and including them. We then just need to generate the delta metadata and do modifyrepo much like we'll be doing for the updateinfo. Updates-testing can basically work identically to updates. Generating deltas for rawhide is a little trickier. The idea we got to was that we'd change dist-rawhide to not inherit and instead be tagging packages with it. Then, for the packages we tag, we can also generate a delta from the last dist-rawhide version to the new version. Then mash can pull off of the dist-rawhide tag (like now) and use deltas much like the update case What do people think? Entirely crazy? Just a little bit crazy? Has holes big enough to drive a truck through? Jeremy From jkeating at redhat.com Thu Jun 21 20:23:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Jun 2007 16:23:50 -0400 Subject: bodhi and security updates/updates-testing In-Reply-To: <20070621201709.GC27476@puariko.nirvana> References: <20070621201709.GC27476@puariko.nirvana> Message-ID: <200706211623.51218.jkeating@redhat.com> On Thursday 21 June 2007 16:17:09 Axel Thimm wrote: > Hi, > > I created a new update which was a security relevant update and was > marked as such. bodhi offered me the possibility to push into testing > or stable. I think the push into stable was offered only because it > was maerked a security sensitive, so updates-testing could be > shortcutted. I also know that the default policy was for security > updates to bypass updates-testing entirely. > > Still, the system offered my to go testing or stable, and I chose > testing. The update later was simply saying that a request was made to > move it, but not whereto. A while later the package made it into > stable. > > I'm not saying to change the policy, just noting a discrepancy in > the application's workflow. Thanks! Axel, can you file a ticket in bodhi's trac? That may be a bug. https://hosted.fedoraproject.org/projects/bodhi -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Thu Jun 21 20:39:32 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 21 Jun 2007 16:39:32 -0400 (EDT) Subject: Integrating deltarpm creation In-Reply-To: <1182457115.9023.23.camel@aglarond.local> References: <1182457115.9023.23.camel@aglarond.local> Message-ID: On Thu, 21 Jun 2007, Jeremy Katz wrote: > What do people think? Entirely crazy? Just a little bit crazy? Has > holes big enough to drive a truck through? We discussed this on the Red Hat Network team, like, 4 years ago. Our conclusion was that it was too crazy. I still regret that decision. Get deltarpm started, and when it breaks (and it will, horribly) fix it. We've needed it for a very long time. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From notting at redhat.com Thu Jun 21 21:12:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Jun 2007 17:12:11 -0400 Subject: Integrating deltarpm creation In-Reply-To: <1182457115.9023.23.camel@aglarond.local> References: <1182457115.9023.23.camel@aglarond.local> Message-ID: <20070621211211.GA4198@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > Generating deltas for rawhide is a little trickier. The idea we got to > was that we'd change dist-rawhide to not inherit and instead be tagging > packages with it. This sounds ridiculously painful, if we're not doing this automatically. Bill From jkeating at redhat.com Thu Jun 21 21:16:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Jun 2007 17:16:13 -0400 Subject: Integrating deltarpm creation In-Reply-To: <20070621211211.GA4198@nostromo.devel.redhat.com> References: <1182457115.9023.23.camel@aglarond.local> <20070621211211.GA4198@nostromo.devel.redhat.com> Message-ID: <200706211716.16701.jkeating@redhat.com> On Thursday 21 June 2007 17:12:11 Bill Nottingham wrote: > This sounds ridiculously painful, if we're not doing this automatically. Oh no, it'll be automatic. The idea is that at the start of the 'push rawhide' script a quick call to say 'koji clone-tag dist-rawhide' would quickly go through and tag all the newest builds of with dist-rawhide, that aren't already tagged. This actually has some other benefits in that we can tell what has or hasn't been shipped in rawhide for garbage collection purposes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Thu Jun 21 21:40:55 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 21 Jun 2007 16:40:55 -0500 Subject: mock update in testing doesn't fix glibc-devel.i386 problem In-Reply-To: <200706170917.11433.jkeating@redhat.com> References: <200706160811.33437.jkeating@redhat.com> <200706170917.11433.jkeating@redhat.com> Message-ID: <20070621214055.GD31152@humbolt.us.dell.com> On Sun, Jun 17, 2007 at 09:17:08AM -0400, Jesse Keating wrote: > On Saturday 16 June 2007 11:14:20 Michael_E_Brown at dell.com wrote: > > Which packages break compilation without this fix? > > A couple I know off the top of my head is grub and syslinux. They both need > to build 32bit. > > > I'd be willing to spin 0.7.2. I've bumped the versions to 0.7.2 and pushed > > that. I wouldnt be able to do a fedora update until tomorrow, though. > > That's fine, I'd hope to see some more feedback on the other bugs we're > fixing. - I promoted 0.7.1 to F-7 updates-stable based on it being there a week with no screaming. - I've pushed 0.7.2 to rawhide. - I've created a a updates-testing release for 0.7.2 for F-7 Todo: - Update FC-6 to 0.7.2. Will do this probably tomorrow if nobody screams. - Update EPEL 4/5 to 0.7.2. Will do with FC-6 update. -- Michael From Axel.Thimm at ATrpms.net Thu Jun 21 22:21:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 00:21:58 +0200 Subject: bodhi and security updates/updates-testing In-Reply-To: <200706211623.51218.jkeating@redhat.com> References: <20070621201709.GC27476@puariko.nirvana> <200706211623.51218.jkeating@redhat.com> Message-ID: <20070621222158.GA7596@puariko.nirvana> On Thu, Jun 21, 2007 at 04:23:50PM -0400, Jesse Keating wrote: > On Thursday 21 June 2007 16:17:09 Axel Thimm wrote: > > Hi, > > > > I created a new update which was a security relevant update and was > > marked as such. bodhi offered me the possibility to push into testing > > or stable. I think the push into stable was offered only because it > > was maerked a security sensitive, so updates-testing could be > > shortcutted. I also know that the default policy was for security > > updates to bypass updates-testing entirely. > > > > Still, the system offered my to go testing or stable, and I chose > > testing. The update later was simply saying that a request was made to > > move it, but not whereto. A while later the package made it into > > stable. > > > > I'm not saying to change the policy, just noting a discrepancy in > > the application's workflow. Thanks! > > Axel, can you file a ticket in bodhi's trac? That may be a bug. > https://hosted.fedoraproject.org/projects/bodhi I tried to, but | TICKET_CREATE privileges are required to perform this operation And trac munges the back operation in the browser. Looks like the login timeouts are insanely short and trac has no recovery mechanism for that. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 22 00:33:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Jun 2007 20:33:16 -0400 Subject: bodhi and security updates/updates-testing In-Reply-To: <20070621222158.GA7596@puariko.nirvana> References: <20070621201709.GC27476@puariko.nirvana> <200706211623.51218.jkeating@redhat.com> <20070621222158.GA7596@puariko.nirvana> Message-ID: <200706212033.19826.jkeating@redhat.com> On Thursday 21 June 2007 18:21:58 Axel Thimm wrote: > And trac munges the back operation in the browser. > > Looks like the login timeouts are insanely short and trac has no > recovery mechanism for that. That's... odd. how long does it take you to enter the ticket? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jun 22 07:11:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 09:11:06 +0200 Subject: bodhi and security updates/updates-testing In-Reply-To: <200706212033.19826.jkeating@redhat.com> References: <20070621201709.GC27476@puariko.nirvana> <200706211623.51218.jkeating@redhat.com> <20070621222158.GA7596@puariko.nirvana> <200706212033.19826.jkeating@redhat.com> Message-ID: <20070622071106.GB27818@puariko.nirvana> On Thu, Jun 21, 2007 at 08:33:16PM -0400, Jesse Keating wrote: > On Thursday 21 June 2007 18:21:58 Axel Thimm wrote: > > And trac munges the back operation in the browser. > > > > Looks like the login timeouts are insanely short and trac has no > > recovery mechanism for that. > > That's... odd. how long does it take you to enter the ticket? I typed in the ticket, then checked back with the email whether there was anything else I forgot to write and when returning to the browser I modified some text and pressed on Preview. Then Boom, no TRAC_CREATE permissions and my ticket submission couldn't be recovered by going back (nice wiping that tracs makes ...). Maybe I'm an infinitesimally slow typer. All in all the issue is not how fast can a ticket submitter type, but whether there are proper recovery mechanisms for reauthetication and whether the reauthetication intervall isn't paranoically short (we don't have any reauthetication timeouts with bugzilla.redhat.com, and that works well there). I've seen similar with mirrormanager, but there the session recovers and continues smoothly after the reauthetication, while trac didn't even try to reauthenticate and ate my data. Don't ask me to file that somewhere that will time out again ... ;) -- 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 opensource at till.name Fri Jun 22 12:37:37 2007 From: opensource at till.name (Till Maas) Date: Fri, 22 Jun 2007 14:37:37 +0200 Subject: bodhi and security updates/updates-testing In-Reply-To: <20070621222158.GA7596@puariko.nirvana> References: <20070621201709.GC27476@puariko.nirvana> <200706211623.51218.jkeating@redhat.com> <20070621222158.GA7596@puariko.nirvana> Message-ID: <200706221437.42090.opensource@till.name> On Fr Juni 22 2007, Axel Thimm wrote: > Looks like the login timeouts are insanely short and trac has no > recovery mechanism for that. I experienced some problems login in to hosted.fedoraprojects and bodhi or koji around the same time, maybe this was the cause. Iirc, the login on hosted.fedora... is http-based, so it should only time out, when you close your browser. Regards, Till From jkeating at redhat.com Fri Jun 22 13:47:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 09:47:02 -0400 Subject: bodhi and security updates/updates-testing In-Reply-To: <20070622071106.GB27818@puariko.nirvana> References: <20070621201709.GC27476@puariko.nirvana> <200706212033.19826.jkeating@redhat.com> <20070622071106.GB27818@puariko.nirvana> Message-ID: <200706220947.06077.jkeating@redhat.com> On Friday 22 June 2007 03:11:06 Axel Thimm wrote: > Don't ask me to file that somewhere that will time out again ... You mean like Trac's upstream? (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jun 22 14:14:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 16:14:36 +0200 Subject: bodhi and security updates/updates-testing In-Reply-To: <200706220947.06077.jkeating@redhat.com> References: <20070621201709.GC27476@puariko.nirvana> <200706212033.19826.jkeating@redhat.com> <20070622071106.GB27818@puariko.nirvana> <200706220947.06077.jkeating@redhat.com> Message-ID: <20070622141436.GG3087@puariko.nirvana> On Fri, Jun 22, 2007 at 09:47:02AM -0400, Jesse Keating wrote: > On Friday 22 June 2007 03:11:06 Axel Thimm wrote: > > Don't ask me to file that somewhere that will time out again ... > > You mean like Trac's upstream? (: I know that trac upstream doesn't time out login sessions, at least not by default, as I've set up quite a lot of trac instances by now. And any transparent authentication proxy set in front of it should be ... transparent. ;) -- 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 Fri Jun 22 14:14:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 10:14:05 -0400 Subject: bodhi and security updates/updates-testing In-Reply-To: <20070622141436.GG3087@puariko.nirvana> References: <20070621201709.GC27476@puariko.nirvana> <200706220947.06077.jkeating@redhat.com> <20070622141436.GG3087@puariko.nirvana> Message-ID: <200706221014.05306.jkeating@redhat.com> On Friday 22 June 2007 10:14:36 Axel Thimm wrote: > I know that trac upstream doesn't time out login sessions, at least > not by default, as I've set up quite a lot of trac instances by > now. And any transparent authentication proxy set in front of it > should be ... transparent. Hrm, would you like to lend me a hand then? We're just using http auth to a postgres server. Find me on IRC at your convenience and we'll go over http configs? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rob.myers at gtri.gatech.edu Fri Jun 22 15:39:11 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Fri, 22 Jun 2007 11:39:11 -0400 Subject: Integrating deltarpm creation In-Reply-To: <200706211716.16701.jkeating@redhat.com> References: <1182457115.9023.23.camel@aglarond.local> <20070621211211.GA4198@nostromo.devel.redhat.com> <200706211716.16701.jkeating@redhat.com> Message-ID: <1182526751.4065.59.camel@rxm-581b.stl.gtri.gatech.edu> On Thu, 2007-06-21 at 17:16 -0400, Jesse Keating wrote: > On Thursday 21 June 2007 17:12:11 Bill Nottingham wrote: > > This sounds ridiculously painful, if we're not doing this automatically. > > Oh no, it'll be automatic. The idea is that at the start of the 'push > rawhide' script a quick call to say 'koji clone-tag dist-rawhide' > would quickly go through and tag all the newest builds of with > dist-rawhide, that aren't already tagged. +1 for the clone-tag functionality. rob. From Axel.Thimm at ATrpms.net Fri Jun 22 17:14:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 19:14:16 +0200 Subject: bodhi and security updates/updates-testing In-Reply-To: <200706221014.05306.jkeating@redhat.com> References: <20070621201709.GC27476@puariko.nirvana> <200706220947.06077.jkeating@redhat.com> <20070622141436.GG3087@puariko.nirvana> <200706221014.05306.jkeating@redhat.com> Message-ID: <20070622171416.GK3087@puariko.nirvana> On Fri, Jun 22, 2007 at 10:14:05AM -0400, Jesse Keating wrote: > On Friday 22 June 2007 10:14:36 Axel Thimm wrote: > > I know that trac upstream doesn't time out login sessions, at least > > not by default, as I've set up quite a lot of trac instances by > > now. And any transparent authentication proxy set in front of it > > should be ... transparent. > > Hrm, would you like to lend me a hand then? We're just using http auth to a > postgres server. Find me on IRC at your convenience and we'll go over http > configs? We could do that, but I just verified Till's assumption that there is no timeout in fp.o's trac, but something else was amiss soem hours ago that logged us all out: I kept a session in bodhi's ticketing system idle for more than two hours and the session was still functional. Of course, perhaps there really was a timeout problem and someone already fixed it by now. The remaining question would be what happened this morning that logged out Till and me. Perhaps the logs of the machine indicate something, maybe someone performing upgrades and/or rebooting the system. -- 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 Fri Jun 22 17:32:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 13:32:21 -0400 Subject: bodhi and security updates/updates-testing In-Reply-To: <20070622171416.GK3087@puariko.nirvana> References: <20070621201709.GC27476@puariko.nirvana> <200706221014.05306.jkeating@redhat.com> <20070622171416.GK3087@puariko.nirvana> Message-ID: <200706221332.21670.jkeating@redhat.com> On Friday 22 June 2007 13:14:16 Axel Thimm wrote: > Of course, perhaps there really was a timeout problem and someone > already fixed it by now. I haven't touched any configs. > The remaining question would be what happened this morning that logged > out Till and me. Perhaps the logs of the machine indicate something, > maybe someone performing upgrades and/or rebooting the system. Not on hosted.fp.o itself. Maybe the xen host... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikem at redhat.com Fri Jun 22 20:00:23 2007 From: mikem at redhat.com (Mike McLean) Date: Fri, 22 Jun 2007 16:00:23 -0400 Subject: Integrating deltarpm creation In-Reply-To: <1182457115.9023.23.camel@aglarond.local> References: <1182457115.9023.23.camel@aglarond.local> Message-ID: <467C2A57.1040507@redhat.com> Jeremy Katz wrote: > The first thing is that it makes the most sense for the deltas to be > created and stored by koji rather than as a secondary process. This > adds the advantage that they're stored consistently with the packages > and also can be cached rather than recreated every time. It feels > somewhat analagous to me to the current situation with signing. While I see the semi-parallel with signatures, I'd rather not rush into adding this to koji. I'd like to have a better understanding of how these deltas need to be managed. Do we anticipate Koji actually having a use for the deltas, or would it just be storing them for other tools? Can deltarpms be signed independently of the rpms it compares? If so, we may need to think about tracking these signatures. How should we deal with the delta/signature interaction? Is there a quick way to read the target's signature info from the delta (applydelta -i doesn't seem to report it)? Each rpm in koji can have multiple signatures, and we would presumably care which signature will be used for the target rpm in the delta. This leads me to wonder about naming schemes and api needs. With signatures, the cached files are tiny, there are unlikely to be more than a handful of them per rpm, and it is clearly reasonable to keep them for as long as the rpm is kept. Even deltas for trivial cases seem to be much larger than a cached signature header, and one can imagine accumulating a large number of deltas for an rpm. So the question is, how long should deltas be kept, and what should trigger their removal? From katzj at redhat.com Fri Jun 22 20:32:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 22 Jun 2007 16:32:48 -0400 Subject: Integrating deltarpm creation In-Reply-To: <467C2A57.1040507@redhat.com> References: <1182457115.9023.23.camel@aglarond.local> <467C2A57.1040507@redhat.com> Message-ID: <1182544368.2720.19.camel@aglarond.local> On Fri, 2007-06-22 at 16:00 -0400, Mike McLean wrote: > Jeremy Katz wrote: > > The first thing is that it makes the most sense for the deltas to be > > created and stored by koji rather than as a secondary process. This > > adds the advantage that they're stored consistently with the packages > > and also can be cached rather than recreated every time. It feels > > somewhat analagous to me to the current situation with signing. > > While I see the semi-parallel with signatures, I'd rather not rush into > adding this to koji. I'd like to have a better understanding of how > these deltas need to be managed. Fair enough... > Do we anticipate Koji actually having a use for the deltas, or would it > just be storing them for other tools? I suspect largely storage. Since we recreate build roots every time, the deltas aren't ever going to matter on the building packages side. So the main advantage of doing it in koji is consistent storage and retrieval. > Can deltarpms be signed independently of the rpms it compares? If so, we > may need to think about tracking these signatures. The deltas aren't independently signed. The way that the deltas work is that they take the bits off of the filesystem + the deltarpm itself to recreate the original RPM. You then have the original package, and you verify it (including signature). > How should we deal with the delta/signature interaction? Is there a > quick way to read the target's signature info from the delta (applydelta > -i doesn't seem to report it)? Each rpm in koji can have multiple > signatures, and we would presumably care which signature will be used > for the target rpm in the delta. This leads me to wonder about naming > schemes and api needs. Yeah, given this we probably are going to want to be able to have multiple deltas taking into account the signatures. Although that just makes me cringe a little in pain... > With signatures, the cached files are tiny, there are unlikely to be > more than a handful of them per rpm, and it is clearly reasonable to > keep them for as long as the rpm is kept. Even deltas for trivial cases > seem to be much larger than a cached signature header, and one can > imagine accumulating a large number of deltas for an rpm. So the > question is, how long should deltas be kept, and what should trigger > their removal? Removal should be triggered the same way as removal of the package -- I don't think you'll want to do separate garbage collection there. And yes, larger than the signature. But I don't see any way around that. Generating them on-demand is going to be worse from the point of view of regenerating the same bits over and over. We've got to keep the generated ones somewhere. Keeping them outside of the buildsystem means we have another data base, another file store, etc. Jeremy From paul at city-fan.org Mon Jun 25 15:18:27 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 25 Jun 2007 16:18:27 +0100 Subject: Known mock/yum problem? Message-ID: <467FDCC3.9050201@city-fan.org> Came across an oddity today and I'm not sure if it's mock or yum that's the problem. I'm running with these updates from updates-testing (on an FC7 host): mock-0.7.2-1.fc7 yum-3.2.1-1.fc7 My rawhide mock config points to a single baseurl for the fedora repo, and goes through a local squid proxy. I'm also using autocache. From time to time packages cannot be retrieved over the network, perhaps due to the mirror being in mid-sync, or maybe transient network issues. Sometimes this results in one or more (but not all) packages not being available to populate a buildroot when running mock. When this happens, mock is not terminating the build during the setup phase, and allows it to continue to the build phase. I noticed this problem because it often results in a failed build due to to some important missing buildreq. More worrying though is the possibility that a missing buildreq package may be needed only to enhance the functionality of the package being built. In such cases the overall build may succeed but produce a package with reduced functionality, and be different from the same package rebuilt by someone else on their own system. So is this yum not returning a proper exit code, or mock ignoring it? I'm not sure. Is this a known issue? I couldn't see anything that looked like this in bugzilla. Paul. From skvidal at linux.duke.edu Mon Jun 25 15:22:16 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 25 Jun 2007 11:22:16 -0400 Subject: Known mock/yum problem? In-Reply-To: <467FDCC3.9050201@city-fan.org> References: <467FDCC3.9050201@city-fan.org> Message-ID: <1182784936.13477.20.camel@hodge> On Mon, 2007-06-25 at 16:18 +0100, Paul Howarth wrote: > Came across an oddity today and I'm not sure if it's mock or yum that's > the problem. > > I'm running with these updates from updates-testing (on an FC7 host): > mock-0.7.2-1.fc7 > yum-3.2.1-1.fc7 > > My rawhide mock config points to a single baseurl for the fedora repo, > and goes through a local squid proxy. I'm also using autocache. > > From time to time packages cannot be retrieved over the network, > perhaps due to the mirror being in mid-sync, or maybe transient network > issues. > Try this as a good test: Make a package with a BuildRequires: something-that-doesn't-exist If the build doesn't bail, then we have a problem, if it does bail, then we're fine. Can you test that and let me know? -sv From paul at city-fan.org Mon Jun 25 16:06:11 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 25 Jun 2007 17:06:11 +0100 Subject: Known mock/yum problem? In-Reply-To: <1182784936.13477.20.camel@hodge> References: <467FDCC3.9050201@city-fan.org> <1182784936.13477.20.camel@hodge> Message-ID: <467FE7F3.7070807@city-fan.org> seth vidal wrote: > On Mon, 2007-06-25 at 16:18 +0100, Paul Howarth wrote: >> Came across an oddity today and I'm not sure if it's mock or yum that's >> the problem. >> >> I'm running with these updates from updates-testing (on an FC7 host): >> mock-0.7.2-1.fc7 >> yum-3.2.1-1.fc7 >> >> My rawhide mock config points to a single baseurl for the fedora repo, >> and goes through a local squid proxy. I'm also using autocache. >> >> From time to time packages cannot be retrieved over the network, >> perhaps due to the mirror being in mid-sync, or maybe transient network >> issues. >> > > Try this as a good test: Make a package with a BuildRequires: > something-that-doesn't-exist > > If the build doesn't bail, then we have a problem, if it does bail, then > we're fine. > > > Can you test that and let me know? OK, tried this: * Got a simple perl module package and added a buildreq of perl(No::Such::Module) to it. * Tried building it: mock failed as I'd have expected ("No Package Found for perl(No::Such::Module)") To more accurately mimic the issue I was seeing, I then: * Created a dummy perl-No-Such-Module package that provided perl(No::Such::Module) * Added that package to a local repo that's in my mock config * After running createrepo to update the metadata, I then deleted the actual RPM from the repo * Tried building the original perl module package This reproduced what I was seeing; the dependency seemingly being available from the metadata was sufficient for mock to proceed to the build phase. The consequences aren't as bad as I'd thought though, as yum doesn't seem to have installed *any* of the buildreqs in the setup phase, which would cause most package builds to fail. Paul. From jgranado at redhat.com Tue Jun 26 14:25:47 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 26 Jun 2007 16:25:47 +0200 Subject: Adding file / directory to pungi scripts. Message-ID: <468121EB.4010107@redhat.com> Hi list: Been working on a script that adds files and directories to the pungi tree. It does this by using an rpm package (the current way of doing it in pungi). I just think this might make somebodies life much easier :) Source is attached This is how it is used: Options: -h, --help show this help message and exit -s SOURCES, --source=SOURCES This script takes local files and directories. --source=/path/to/dir. --pungi-conf=PUNGICONF Pungi configuration file that will be modified. --yum-conf=YUMCONF Yum configuration file that will be modified. --name=PKGNAME It specifies the name of the package. --version=PKGVER Package Version. --release=PKGREL Package Release. -a ARCH, --arch=ARCH Package Architecture. noarch is recomended. -r REPONAME, --repo=REPONAME The repository name. It will be located in the pungi workdir. --revert Is used to undo the changes that this scripts does to the yum config file and the pungi config file. Any comment is greatly appreciated. Regards -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: addFilesToPungi URL: From Michael_E_Brown at dell.com Tue Jun 26 22:27:46 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 26 Jun 2007 17:27:46 -0500 Subject: mock 0.7.2 push to F7 updates Message-ID: <20070626222746.GD21250@humbolt.us.dell.com> After a week in updates-testing with no comments (for 0.7.2, add another week for 0.7.1), I have pushed 0.7.2 into updates/ for F7. This completes this round of upgrades, as 0.7.2 is now pushed into EPEL-4, EPEL-5, FC6, F7, and Fedora-Devel. -- Michael From sheltren at cs.ucsb.edu Wed Jun 27 00:08:39 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 26 Jun 2007 20:08:39 -0400 Subject: mock 0.7.2 push to F7 updates In-Reply-To: <20070626222746.GD21250@humbolt.us.dell.com> References: <20070626222746.GD21250@humbolt.us.dell.com> Message-ID: <19245587-9AE3-4639-AEDB-75617DBE7888@cs.ucsb.edu> On Jun 26, 2007, at 6:27 PM, Michael E Brown wrote: > After a week in updates-testing with no comments (for 0.7.2, add > another > week for 0.7.1), I have pushed 0.7.2 into updates/ for F7. > > This completes this round of upgrades, as 0.7.2 is now pushed into > EPEL-4, EPEL-5, FC6, F7, and Fedora-Devel. Sounds like a full time job! :) Thanks for the updates. -Jeff From ob.system at gmail.com Thu Jun 28 22:33:59 2007 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Thu, 28 Jun 2007 17:33:59 -0500 Subject: Koji and SVN Message-ID: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> Hi List I have two questions Koji can support SVN at the moment? why not? Oscar Palma Linux Mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Jun 30 18:48:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Jun 2007 14:48:18 -0400 Subject: Koji and SVN In-Reply-To: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> Message-ID: <200706301448.24864.jkeating@redhat.com> On Thursday 28 June 2007 18:33:59 Oscar Victorio Calixto Bacho wrote: > Hi List > > I have two questions > > Koji can support SVN at the moment? Not currently. > why not? The source control mechanism used by the Fedora project for it's packages is currently CVS. It also looks like that any move away from CVS would be toward a distributed SCM such as git or hg due to the things a distributed SCM offers over CVS/SVN. However patches to Koji that enable svn support won't be turned away, provided they're good (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: