From mythtv.bohmer at gmail.com Thu Feb 1 10:40:28 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Thu, 1 Feb 2007 11:40:28 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200701311311.11648.jkeating@redhat.com> References: <200701311020.58794.jkeating@redhat.com> <200701311311.11648.jkeating@redhat.com> Message-ID: Hello Jesse, Attached are the results of this command: /usr/lib/anaconda-runtime/pkgorder /home/me/cdbuildtree/results/myrelease/i386/os i386 myproduct I replaced 'myproduct' with 'Fedora'. No differences. The produced list is exactly like the list of RPM's in my os-disc1- directory. Thus, much too short... Does this give you some new ideas? Kind Regards, Remy Bohmer 2007/1/31, Jesse Keating : > On Wednesday 31 January 2007 11:58, Remy Bohmer wrote: > > What did you mean with the line: 'That and see what packageorder does > > on your tree. pypungi/pungi.py has the pkgorder command used.' ? > > Should I run some command and check its output? > > I rebuilt everything with pung, and checked its output for now... > > Use: > > /usr/lib/anaconda-runtime/pkgorder /path/to/your/os Fedora > > That will spit out a package order that is used by splittree to put your > packages on various CDs. I'd be interested to see if all the packages in > your compose make it. > > pkgorder is a python script, so you can use python debugger (pdb) to see whats > going on. > > pkgorder is also part of anaconda-runtime, so any bugs found belong to the > anaconda group, not pungi (: > > -- > Jesse Keating > Release Engineer: Fedora > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -------------- next part -------------- kernel-headers-2.6.19-1.2895.fc6.i386.rpm kernel-2.6.19.1-rt15_ref16_mainline.i686.rpm kernel-2.6.19-1.2895.fc6.i586.rpm cyrus-sasl-2.1.22-4.i386.rpm attr-2.4.32-1.1.i386.rpm xfsprogs-2.8.11-3.fc6.i386.rpm acl-2.2.39-1.1.i386.rpm gfs2-utils-0.1.7-1.fc6.i386.rpm lshw-B.02.08.01-myrelease.i686.rpm man-1.6d-2.fc6.i386.rpm reiserfs-utils-3.6.19-2.4.1.i386.rpm memtest86+-1.65-4.1.i386.rpm capover-0.9.3-myrelease.i686.rpm exim-4.63-5.fc6.i386.rpm jfsutils-1.1.10-4.1.i386.rpm ssmtp-2.61-11.1.fc6.i386.rpm grub-0.97-myrelease.i686.rpm procmail-3.22-17.1.i386.rpm hesiod-3.1.0-8.i386.rpm perl-DBI-1.52-1.fc6.i386.rpm groff-1.18.1.1-11.1.i386.rpm busybox-anaconda-1.2.0-3.i386.rpm dialog-1.0.20051107-1.2.2.i386.rpm iscsi-initiator-utils-6.2.0.747-0.0.fc6.i386.rpm sendmail-8.13.8-2.i386.rpm joe-3.4-3.i386.rpm mdadm-2.5.4-2.fc6.i386.rpm postfix-2.3.3-2.i386.rpm xfsdump-2.2.42-2.fc6.i386.rpm bzip2-1.0.3-3.i386.rpm parsexml-0.1-myrelease.i686.rpm mysql-5.0.27-1.fc6.i386.rpm myproduct-myrelease.i686.rpm From jkeating at redhat.com Thu Feb 1 12:59:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 07:59:03 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200701311311.11648.jkeating@redhat.com> Message-ID: <200702010759.06614.jkeating@redhat.com> On Thursday 01 February 2007 05:40, Remy Bohmer wrote: > Attached are the results of this command: > /usr/lib/anaconda-runtime/pkgorder > /home/me/cdbuildtree/results/myrelease/i386/os i386 myproduct > > I replaced 'myproduct' with 'Fedora'. No differences. > The produced list is exactly like the list of RPM's in my os-disc1- > directory. Thus, much too short... > > Does this give you some new ideas? It would appear that pkgorder doesn't know about the other groups you have in your comps file perhaps. pkgorder is just a python script, I'd poke at it and see how it figures out the order, and see if perhaps you need to change your group names in comps. -- 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 jeroen.janssen at gmail.com Thu Feb 1 15:17:48 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Thu, 1 Feb 2007 16:17:48 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200702010759.06614.jkeating@redhat.com> References: <200701311311.11648.jkeating@redhat.com> <200702010759.06614.jkeating@redhat.com> Message-ID: Hi, On 2/1/07, Jesse Keating wrote: > It would appear that pkgorder doesn't know about the other groups you have in > your comps file perhaps. pkgorder is just a python script, I'd poke at it > and see how it figures out the order, and see if perhaps you need to change > your group names in comps. After looking at pkgorder it seems it has a hardcoded list of groups it adds for resolving the order. Maybe a 'fallback' to add any remaining groups that were not selected yet would be a good improvement of pkgorder? (and a solution to this problem). I'll see if I can come-up with a patch to pkgorder that does this. Best regards, Jeroen Janssen From jeroen.janssen at gmail.com Thu Feb 1 16:01:07 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Thu, 1 Feb 2007 17:01:07 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <1170344535.20144.112.camel@enki.eridu> References: <200701311311.11648.jkeating@redhat.com> <200702010759.06614.jkeating@redhat.com> <1170344535.20144.112.camel@enki.eridu> Message-ID: On 2/1/07, Paul Nasrat wrote: > > After looking at pkgorder it seems it has a hardcoded list of groups > > it adds for resolving the order. > > We want to move all that group information to outside pkgorder - extra > data within the repodata would be ideal. That way people don't need to > hack the script merely reorder the data to say have a ordering for > Fedora KDE or Fedora XFCE default. > > > I'll see if I can come-up with a patch to pkgorder that does this. > > I'd rather see the order of groups and required package globs (eg > kernel*) in a metadata file. Should this ordering information then be put it in pungi's Manifest file (since pungi calls pkgorder)? And have an addition to the pkgorder commandline interface that can be used to pass a grouporder. Or do you want another solution? Best regards, Jeroen Janssen From jkeating at redhat.com Thu Feb 1 16:12:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 11:12:32 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <1170344535.20144.112.camel@enki.eridu> Message-ID: <200702011112.33265.jkeating@redhat.com> On Thursday 01 February 2007 11:01, Jeroen Janssen wrote: > Should this ordering information then be put it in pungi's Manifest > file (since pungi calls pkgorder)? And have an addition to the > pkgorder commandline interface that can be used to pass a grouporder. > Or do you want another solution? Ideally it would be with createrepo so that the repodata has the ordering, and splittree can just follow the manifest as written by createrepo. pkgorder could go away completely. -- 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 jeroen.janssen at gmail.com Thu Feb 1 16:22:30 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Thu, 1 Feb 2007 17:22:30 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200702011112.33265.jkeating@redhat.com> References: <1170344535.20144.112.camel@enki.eridu> <200702011112.33265.jkeating@redhat.com> Message-ID: On 2/1/07, Jesse Keating wrote: > On Thursday 01 February 2007 11:01, Jeroen Janssen wrote: > > Should this ordering information then be put it in pungi's Manifest > > file (since pungi calls pkgorder)? And have an addition to the > > pkgorder commandline interface that can be used to pass a grouporder. > > Or do you want another solution? > > Ideally it would be with createrepo so that the repodata has the ordering, and > splittree can just follow the manifest as written by createrepo. pkgorder > could go away completely. If I understand correctly createrepo is part of the (yum?) metadata package. So this would mean that we need to check with those authors in order to make sure this is done in an acceptable way. I have absolutely no idea how to get this kind of change organised (since it seems that several different projects are involved). Is this something that is going to be done (anyway) for F7? What can I do to help? Best regards, Jeroen Janssen From mythtv.bohmer at gmail.com Fri Feb 2 08:31:44 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Fri, 2 Feb 2007 09:31:44 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200702010759.06614.jkeating@redhat.com> References: <200701311311.11648.jkeating@redhat.com> <200702010759.06614.jkeating@redhat.com> Message-ID: Hello All, I renamed all my groups to 'core', 'base', 'base-x' and 'development-tools', and it does not make any difference... So, I believe it is not only related to the group naming in the comps file... I am going to debug this some more today. If anyone has a good idea about this, please let me know. Kind Regards, Remy 2007/2/1, Jesse Keating : > On Thursday 01 February 2007 05:40, Remy Bohmer wrote: > > Attached are the results of this command: > > /usr/lib/anaconda-runtime/pkgorder > > /home/me/cdbuildtree/results/myrelease/i386/os i386 myproduct > > > > I replaced 'myproduct' with 'Fedora'. No differences. > > The produced list is exactly like the list of RPM's in my os-disc1- > > directory. Thus, much too short... > > > > Does this give you some new ideas? > > It would appear that pkgorder doesn't know about the other groups you have in > your comps file perhaps. pkgorder is just a python script, I'd poke at it > and see how it figures out the order, and see if perhaps you need to change > your group names in comps. > > -- > Jesse Keating > Release Engineer: Fedora > > From mythtv.bohmer at gmail.com Fri Feb 2 16:36:12 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Fri, 2 Feb 2007 17:36:12 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200701311311.11648.jkeating@redhat.com> <200702010759.06614.jkeating@redhat.com> Message-ID: Hello All, I got it! but, it is very strange... ;-)) I debugged the pkgorder script and found the following: * At the routine 'processTransaction()' the complete lists of dependencies is available, then it calls the routine printMatchingPkgs() to print the packages to standard, after it has checked that they are available. * The filemask that is passed to printMatchingPkgs() through 'fpattern', is build up as follows: /Product/package*. Where Product starts with a capital, but my product_name in the pungi configuration does NOT star with a capital. So, the product-dir in the os-dir does not start with a capital. So, no dependency files can be found, leaving a os-disc1 with just a few files in it... I searched through the entire tree several times, but nowhere I have listed the productname with a capital, so this capital must be introduced by the tooling itself ! (Fedora also starts with a capital... Redhat also, and probably other distros using anaconda also?) So, to be able to build a customised CD, you must use a product_name in Pungi that starts with a capital. I have changed this in my build environment and now it works! I believe the problem is introduced by collecting the dependencies in the routine addGroups() -> ds.ResolveDeps() in the pkgorder script. For me it is going to deep in the external tooling, which I do not fully understand yet how they work. Maybe someone else recognises this phenomenon and can pick it up from here? Or if someone can give me some tips on this, I can look further into it... Kind Regards, Remy Bohmer 2007/2/2, Remy Bohmer : > Hello All, > > I renamed all my groups to 'core', 'base', 'base-x' and > 'development-tools', and it does not make any difference... So, I > believe it is not only related to the group naming in the comps > file... I am going to debug this some more today. > > If anyone has a good idea about this, please let me know. > > > Kind Regards, > > Remy > > 2007/2/1, Jesse Keating : > > On Thursday 01 February 2007 05:40, Remy Bohmer wrote: > > > Attached are the results of this command: > > > /usr/lib/anaconda-runtime/pkgorder > > > /home/me/cdbuildtree/results/myrelease/i386/os i386 myproduct > > > > > > I replaced 'myproduct' with 'Fedora'. No differences. > > > The produced list is exactly like the list of RPM's in my os-disc1- > > > directory. Thus, much too short... > > > > > > Does this give you some new ideas? > > > > It would appear that pkgorder doesn't know about the other groups you have in > > your comps file perhaps. pkgorder is just a python script, I'd poke at it > > and see how it figures out the order, and see if perhaps you need to change > > your group names in comps. > > > > -- > > Jesse Keating > > Release Engineer: Fedora > > > > > From esammons at hush.com Fri Feb 2 19:49:12 2007 From: esammons at hush.com (Earl) Date: Fri, 02 Feb 2007 14:49:12 -0500 Subject: pungi ignores a lot of RPMs when building CD image Message-ID: <20070202194913.C37E72283E@mailserver9.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remy, Excelent work! I, for one, appreciate your effort. Now that you have re-inspired me, I have a basic comps.xml question that I _think_ has already been answered here (pardon my dense-ness): In theory if you want to create a very stripped down subset of FC you could: 1. Generate a list of package %name that yield no external dependncies 2. Create "comps.xml" that only lists %name from (1) in a group called "base" 3. Do the pungi pungi ;P Is this correct? Earl On Fri, 02 Feb 2007 11:36:12 -0500 Remy Bohmer wrote: >Hello All, > >I got it! but, it is very strange... ;-)) > >I debugged the pkgorder script and found the following: >* At the routine 'processTransaction()' the complete lists of >dependencies is available, then it calls the routine >printMatchingPkgs() to print the packages to standard, after it >has >checked that they are available. >* The filemask that is passed to printMatchingPkgs() through >'fpattern', is build up as follows: /Product/package*. >Where >Product starts with a capital, but my product_name in the pungi >configuration does NOT star with a capital. So, the product-dir in >the >os-dir does not start with a capital. So, no dependency files can >be >found, leaving a os-disc1 with just a few files in it... > >I searched through the entire tree several times, but nowhere I >have >listed the productname with a capital, so this capital must be >introduced by the tooling itself ! (Fedora also starts with a >capital... Redhat also, and probably other distros using anaconda >also?) > >So, to be able to build a customised CD, you must use a >product_name >in Pungi that starts with a capital. I have changed this in my >build >environment and now it works! > >I believe the problem is introduced by collecting the dependencies >in >the routine addGroups() -> ds.ResolveDeps() in the pkgorder >script. > >For me it is going to deep in the external tooling, which I do not >fully understand yet how they work. Maybe someone else recognises >this >phenomenon and can pick it up from here? >Or if someone can give me some tips on this, I can look further >into it... > > >Kind Regards, > >Remy Bohmer > > > >2007/2/2, Remy Bohmer : >> Hello All, >> >> I renamed all my groups to 'core', 'base', 'base-x' and >> 'development-tools', and it does not make any difference... So, >I >> believe it is not only related to the group naming in the comps >> file... I am going to debug this some more today. >> >> If anyone has a good idea about this, please let me know. >> >> >> Kind Regards, >> >> Remy >> >> 2007/2/1, Jesse Keating : >> > On Thursday 01 February 2007 05:40, Remy Bohmer wrote: >> > > Attached are the results of this command: >> > > /usr/lib/anaconda-runtime/pkgorder >> > > /home/me/cdbuildtree/results/myrelease/i386/os i386 >myproduct >> > > >> > > I replaced 'myproduct' with 'Fedora'. No differences. >> > > The produced list is exactly like the list of RPM's in my os- >disc1- >> > > directory. Thus, much too short... >> > > >> > > Does this give you some new ideas? >> > >> > It would appear that pkgorder doesn't know about the other >groups you have in >> > your comps file perhaps. pkgorder is just a python script, >I'd poke at it >> > and see how it figures out the order, and see if perhaps you >need to change >> > your group names in comps. >> > >> > -- >> > Jesse Keating >> > Release Engineer: Fedora >> > >> > >> > >-- >Fedora-buildsys-list mailing list >Fedora-buildsys-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkXDlhAACgkQk7+e+4lPSm2O8QCeJENc6P4EPIp7FOovcYe9j6CbbZkA oLuWDtzc5RdQdabfbniUajwiXZ+h =40Tu -----END PGP SIGNATURE----- From stefmanos at gmail.com Fri Feb 2 20:38:12 2007 From: stefmanos at gmail.com (Stephanos Manos) Date: Fri, 02 Feb 2007 22:38:12 +0200 Subject: pungi error In-Reply-To: <200701301041.34132.jkeating@redhat.com> References: <1170139020.4164.11.camel@ghost.home-net> <200701301021.35407.jkeating@redhat.com> <200701301041.34132.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Tuesday 30 January 2007 10:21, Jesse Keating wrote: >> To be perfectly honest, I haven't actually verified that the sha1sums in >> the file actually match the isos. I just took it for granted, but perhaps >> I did something silly like insert the mediacheck checksum after I >> sha1summed the file. I'll look into this right now. > > Whoops, yep, I screwed that one up good. > > I did sha1sum at first, later added implantmd5, and forgot to implant _before_ > calculating the sha1sum. I've just committed a fix for this to pungi hg. > > Jesse With today's rawhide I'm getting the following [...] Downloading mcstrans-0.1.10-1.fc7.i386.rpm Downloading gnome-spell-1.0.7-4.fc7.i386.rpm Downloading cpio-2.6-23.fc7.i386.rpm Traceback (most recent call last): File "/usr/bin/pungi", line 167, in main() File "/usr/bin/pungi", line 101, in main mypungi.doBuildinstall() File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 51, in doBuildinstall self.config.get('default', 'bugurl'), self.topdir) File "/usr/lib/python2.5/ConfigParser.py", line 520, in get raise NoOptionError(option, section) ConfigParser.NoOptionError: No option 'bugurl' in section: 'default' Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/dev/pts Done. Stephanos P.S pungi version: pungi-0.2.2-1.fc7 From jkeating at redhat.com Fri Feb 2 21:48:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Feb 2007 16:48:58 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <20070202194913.C37E72283E@mailserver9.hushmail.com> References: <20070202194913.C37E72283E@mailserver9.hushmail.com> Message-ID: <200702021649.01255.jkeating@redhat.com> On Friday 02 February 2007 14:49, Earl wrote: > 1. Generate a list of package %name that yield no external > dependncies > 2. Create "comps.xml" that only lists %name from (1) in a group > called "base" > 3. Do the pungi pungi ;P > > Is this correct? Pretty much. I don't yet have an "official" list of absolutely requires packages, so you still need some things you might not expect, but see the minimal files in /etc/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 jkeating at redhat.com Fri Feb 2 21:50:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Feb 2007 16:50:20 -0500 Subject: pungi error In-Reply-To: References: <1170139020.4164.11.camel@ghost.home-net> <200701301041.34132.jkeating@redhat.com> Message-ID: <200702021650.20327.jkeating@redhat.com> On Friday 02 February 2007 15:38, Stephanos Manos wrote: > Jesse > > With today's rawhide I'm getting the following > > [...] > Downloading mcstrans-0.1.10-1.fc7.i386.rpm > Downloading gnome-spell-1.0.7-4.fc7.i386.rpm > Downloading cpio-2.6-23.fc7.i386.rpm > Traceback (most recent call last): > ? File "/usr/bin/pungi", line 167, in > ? ? main() > ? File "/usr/bin/pungi", line 101, in main > ? ? mypungi.doBuildinstall() > ? File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 51, in > doBuildinstall > ? ? self.config.get('default', 'bugurl'), self.topdir) > ? File "/usr/lib/python2.5/ConfigParser.py", line 520, in get > ? ? raise NoOptionError(option, section) > ConfigParser.NoOptionError: No option 'bugurl' in section: 'default' > Cleaning up... Oops. I probably forgot to define that correctly. Fill in 'bugurl = http://your.bug.url' for now. I'll make it not fill that part in some how if it is missing. -- 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 stefmanos at gmail.com Sat Feb 3 14:03:09 2007 From: stefmanos at gmail.com (Stephanos Manos) Date: Sat, 03 Feb 2007 16:03:09 +0200 Subject: pungi error In-Reply-To: <200702021650.20327.jkeating@redhat.com> References: <1170139020.4164.11.camel@ghost.home-net> <200701301041.34132.jkeating@redhat.com> <200702021650.20327.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Friday 02 February 2007 15:38, Stephanos Manos wrote: >> Jesse >> >> With today's rawhide I'm getting the following >> >> [...] >> Downloading mcstrans-0.1.10-1.fc7.i386.rpm >> Downloading gnome-spell-1.0.7-4.fc7.i386.rpm >> Downloading cpio-2.6-23.fc7.i386.rpm >> Traceback (most recent call last): >> File "/usr/bin/pungi", line 167, in >> main() >> File "/usr/bin/pungi", line 101, in main >> mypungi.doBuildinstall() >> File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 51, in >> doBuildinstall >> self.config.get('default', 'bugurl'), self.topdir) >> File "/usr/lib/python2.5/ConfigParser.py", line 520, in get >> raise NoOptionError(option, section) >> ConfigParser.NoOptionError: No option 'bugurl' in section: 'default' >> Cleaning up... > > Oops. I probably forgot to define that correctly. Fill in 'bugurl = > http://your.bug.url' for now. I'll make it not fill that part in some how if > it is missing. > > Jesse After checking bugurl = http://bugzilla.redhat.com exists in the provided by the rpm in /etc/pungi/pungi.conf but not in the other conf files and not in the files in http://people.redhat.com/jkeating/pungi-f7-test1/ that you suggest using in http://fedoraproject.org/wiki/QA/7/BuildingISOs. Made the changes but now i get a different error [...] Little endian filesystem, data block size 65536, compressed data, compressed metadata, no fragments Filesystem size 73432.29 Kbytes (71.71 Mbytes) 35.68% of uncompressed filesystem size (205834.15 Kbytes) Inode table size 101147 bytes (98.78 Kbytes) 31.20% of uncompressed inode table size (324237 bytes) Directory table size 86660 bytes (84.63 Kbytes) 46.35% of uncompressed directory table size (186978 bytes) Number of duplicate files found 83 Number of inodes 9014 Number of files 5048 Number of symbolic links 3357 Number of device nodes 0 Number of fifo nodes 0 Number of socket nodes 0 Number of directories 609 Number of uids 1 root (0) Number of gids 0 Wrote /srv/pungi/f7-test1/6.90/Desktop/i386/os/images/stage2.img (73436k) Writing .discinfo file timestamp not specified; using the current time /dev/mapper/control: matchpathcon 0020000 failed: No such file or directory Failure to communicate with kernel device-mapper driver. Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 34, in from yuminstall import YumSorter File "/usr/lib/anaconda/yuminstall.py", line 29, in from packages import recreateInitrd File "/usr/lib/anaconda/packages.py", line 19, in import iutil File "/usr/lib/anaconda/iutil.py", line 16, in import os, isys, string, stat File "/usr/lib/anaconda/isys.py", line 32, in import block File "/usr/lib/python2.5/site-packages/block/__init__.py", line 6, in from device import MultiPath, RaidDev, RaidSet, BlockDev, DeviceMaps, \ File "/usr/lib/python2.5/site-packages/block/device.py", line 190, in class MPNameCache(_IUD): File "/usr/lib/python2.5/site-packages/block/device.py", line 195, in MPNameCache for map in _dm.maps(): MemoryError /srv/pungi/f7-test1/work/Desktop/i386/docs ~ 112 blocks ~ /srv/pungi/f7-test1/work/Desktop/i386/docs ~ 4766 blocks ~ Copying release note file eula.txt Copying release note file GPL Copying release note file fedora.css Copying release note file RELEASE-NOTES-en_US.html Copying release note file README-BURNING-ISOS-en_US.txt Copying release note file RPM-GPG-KEY Copying release note file RPM-GPG-KEY-beta Copying release note file RPM-GPG-KEY-fedora-test Copying release note file RPM-GPG-KEY-fedora-rawhide Copying release note file RPM-GPG-KEY-fedora Copying release note file RPM-GPG-KEY-fedora-legacy Copying release note file RPM-GPG-KEY-rawhide Copying release note file RPM-GPG-KEY-fedora-extras Copying release note dir stylesheet-images Traceback (most recent call last): File "/usr/bin/pungi", line 167, in main() File "/usr/bin/pungi", line 104, in main mypungi.doSplittree() File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 117, in doSplittree output = timber.main() File "/usr/lib/anaconda-runtime/splittree.py", line 394, in main self.splitRPMS() File "/usr/lib/anaconda-runtime/splittree.py", line 340, in splitRPMS self.reportSizes(disc, firstpkg=firstpackage, lastpkg=lastpackage) UnboundLocalError: local variable 'firstpackage' referenced before assignment Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/dev/pts Done. Note: I'm running FC6 and building inside mock The above error is produced using either the provided comps-fc7.xml or the one in the http://people.redhat.com/jkeating/pungi-f7-test1/. If i use the comps.xml from the devel repo http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/base/ then pungi finishes it's operation and produces the iso images witch BTW still fail when checking with sha1sum Regards Stephanos Manos From jkeating at redhat.com Sat Feb 3 15:53:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 10:53:39 -0500 Subject: pungi error In-Reply-To: References: <1170139020.4164.11.camel@ghost.home-net> <200702021650.20327.jkeating@redhat.com> Message-ID: <200702031053.42764.jkeating@redhat.com> On Saturday 03 February 2007 09:03, Stephanos Manos wrote: > Note: I'm running FC6 and building inside mock How are you calling mock? Did you follow my instructions in the pungi wiki? The error you got is because pkgorder isn't able to connect to /dev/mapper for some reason. -- 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 stefmanos at gmail.com Sat Feb 3 17:04:55 2007 From: stefmanos at gmail.com (Stephanos Manos) Date: Sat, 03 Feb 2007 19:04:55 +0200 Subject: pungi error In-Reply-To: <200702031053.42764.jkeating@redhat.com> References: <1170139020.4164.11.camel@ghost.home-net> <200702021650.20327.jkeating@redhat.com> <200702031053.42764.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Saturday 03 February 2007 09:03, Stephanos Manos wrote: >> Note: I'm running FC6 and building inside mock > > How are you calling mock? Did you follow my instructions in the pungi wiki? > The error you got is because pkgorder isn't able to connect to /dev/mapper > for some reason. > > Yes using instructions from https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs/RunningPungiInMock the only thing that i change is the yum conf file with repos pointing to my local mirror Stephanos PS The output of the procedure [build at ghost ~]$ mock -r fedora-devel-i386-core init init clean prep This may take a while ending done Finished initializing root [build at ghost ~]$ /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root install pungi adding ld_preload of LD_PRELOAD=libselinux-mock.so ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: pungi noarch 0.2.2-1.fc7 extras 475 k Installing for dependencies: [...] package list Transaction Summary ============================================================================= Install 195 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 93 M warning: createrepo-0.4.4-2.fc6: Header V3 DSA signature: NOKEY, key ID 897da07a warning: pungi-0.2.2-1.fc7: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 warning: system-config-network-1.3.96-1.fc6: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 warning: /etc/yum.conf created as /etc/yum.conf.rpmnew /proc is empty (not mounted ?) /proc is empty (not mounted ?) /proc is empty (not mounted ?) /proc is empty (not mounted ?) /proc is empty (not mounted ?) Installed: pungi.noarch 0:0.2.2-1.fc7 Dependency Installed: GConf2.i386 0:2.16.0-4.fc7 ORBit2.i386 [...] package list [build at ghost ~]$ sudo cp /etc/resolv.conf /var/lib/mock/fedora-development-i386-core/root/etc/ [build at ghost ~]$ sudo /dev/MAKEDEV -d /var/lib/mock/fedora-development-i386-core/root/dev/ -m 6 loop MAKEDEV: mkdir: File exists MAKEDEV: mkdir: File exists MAKEDEV: mkdir: File exists MAKEDEV: mkdir: File exists MAKEDEV: mkdir: File exists MAKEDEV: mkdir: File exists [build at ghost ~]$ setarch i386 mock -r fedora-devel-i386-core chroot "/usr/bin/pungi -c /etc/pungi/f7-test1-desktop.i386" init ending done Non-zero return value 1 on executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "/usr/bin/pungi -c /etc/pungi/f7-test1-desktop.i386" From mythtv.bohmer at gmail.com Mon Feb 5 16:53:50 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Mon, 5 Feb 2007 17:53:50 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200701311311.11648.jkeating@redhat.com> <200702010759.06614.jkeating@redhat.com> Message-ID: Hello All, I thought I got it... But this is not true... I have now the problem reversed :-((( By changing the first letter of the product name to a capital, the result was that I have now a CD image of 331 packages, where I need 362. Before this change, I had 31 packages... The problem is still pkgorder, at the same location as mentioned below. For some reason pkgorder is really stubborn, and still mixes up the productname by changing the first letter of several packages. It does not matter where the packages come from, either from the orignal FC6-DVD , or from the FC6-Updates repo, or from my custom repo. Even if I build without my own repo, does not matter. Notice that a bug in pkgorder does not even tell anybody if it can find a package at all, it just continuous, resulting in an incomplete CD-image... So, does anyone know how the location of a package is determined in pkgorder? (I mean the relative path inside a repo, with the product name) It does NOT read it from Pungi configuration file (Tried to change it completely, no result) Tried to change the product name on the commandline of pkgorder -> no result either... So, nowhere in my tree I can find the wrong productname, and neither does any change of any product_name setting help. I really hope, someone can help me out here... I am starting to get quite desperate about these tools... :-(( Remy 2007/2/2, Remy Bohmer : > Hello All, > > I got it! but, it is very strange... ;-)) > > I debugged the pkgorder script and found the following: > * At the routine 'processTransaction()' the complete lists of > dependencies is available, then it calls the routine > printMatchingPkgs() to print the packages to standard, after it has > checked that they are available. > * The filemask that is passed to printMatchingPkgs() through > 'fpattern', is build up as follows: /Product/package*. Where > Product starts with a capital, but my product_name in the pungi > configuration does NOT star with a capital. So, the product-dir in the > os-dir does not start with a capital. So, no dependency files can be > found, leaving a os-disc1 with just a few files in it... > > I searched through the entire tree several times, but nowhere I have > listed the productname with a capital, so this capital must be > introduced by the tooling itself ! (Fedora also starts with a > capital... Redhat also, and probably other distros using anaconda > also?) > > So, to be able to build a customised CD, you must use a product_name > in Pungi that starts with a capital. I have changed this in my build > environment and now it works! > > I believe the problem is introduced by collecting the dependencies in > the routine addGroups() -> ds.ResolveDeps() in the pkgorder script. > > For me it is going to deep in the external tooling, which I do not > fully understand yet how they work. Maybe someone else recognises this > phenomenon and can pick it up from here? > Or if someone can give me some tips on this, I can look further into it... > > > Kind Regards, > > Remy Bohmer > > > > 2007/2/2, Remy Bohmer : > > Hello All, > > > > I renamed all my groups to 'core', 'base', 'base-x' and > > 'development-tools', and it does not make any difference... So, I > > believe it is not only related to the group naming in the comps > > file... I am going to debug this some more today. > > > > If anyone has a good idea about this, please let me know. > > > > > > Kind Regards, > > > > Remy > > > > 2007/2/1, Jesse Keating : > > > On Thursday 01 February 2007 05:40, Remy Bohmer wrote: > > > > Attached are the results of this command: > > > > /usr/lib/anaconda-runtime/pkgorder > > > > /home/me/cdbuildtree/results/myrelease/i386/os i386 myproduct > > > > > > > > I replaced 'myproduct' with 'Fedora'. No differences. > > > > The produced list is exactly like the list of RPM's in my os-disc1- > > > > directory. Thus, much too short... > > > > > > > > Does this give you some new ideas? > > > > > > It would appear that pkgorder doesn't know about the other groups you have in > > > your comps file perhaps. pkgorder is just a python script, I'd poke at it > > > and see how it figures out the order, and see if perhaps you need to change > > > your group names in comps. > > > > > > -- > > > Jesse Keating > > > Release Engineer: Fedora > > > > > > > > > From jkeating at redhat.com Mon Feb 5 19:11:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Feb 2007 14:11:36 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: Message-ID: <200702051411.36667.jkeating@redhat.com> On Monday 05 February 2007 11:53, Remy Bohmer wrote: > For some reason pkgorder is really stubborn, and still mixes up the > productname by changing the first letter of several packages. It does > not matter where the packages come from, either from the orignal > FC6-DVD , or from the FC6-Updates repo, or from my custom repo. Even > if I build without my own repo, does not matter. > Notice that a bug in pkgorder does not even tell anybody if it can > find a package at all, it just continuous, resulting in an incomplete > CD-image... > > So, does anyone know how the location of a package is determined in > pkgorder? (I mean the relative path inside a repo, with the product > name) > > It does NOT read it from Pungi configuration file (Tried to change it > completely, no result) > Tried to change the product name on the commandline of pkgorder -> no > result either... > > So, nowhere in my tree I can find the wrong productname, and neither > does any change of any product_name setting help. > > I really hope, someone can help me out here... I am starting to get > quite desperate about these tools... :-(( Er, Are you putting packages into different directories under os/ ? I'm pretty sure that the way pungi is designed, all your packages would (by default) go under os/Fedora/ ALL packages, regardless of what repository they come from. Are you getting multiple product dirs somehow? I'm seriously having a hard time figuring out how you're getting to this stage. -- 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 mythtv.bohmer at gmail.com Mon Feb 5 20:20:51 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Mon, 5 Feb 2007 21:20:51 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200702051411.36667.jkeating@redhat.com> References: <200702051411.36667.jkeating@redhat.com> Message-ID: Hello Jesse, What you mention is exactly what I want, except my product is not named Fedora, but something else... I will summarise the facts here below, hope this clears something up. > Are you putting packages into different directories under os/ ? No, the /os/ is an intermediate buildresult of what pungi (with anaconda) is doing. I am not modifying it in any way. My goal is to use as many standard tooling as possible, without the need for me to modify the tools. (Except if there is a need for a bugfix) So, only 1 directory with packages is there in /os/myproduct, not 2. But after building the /os directory pungi calls at some point pkgorder and this one introduces a problem while building the os-disc1/myproduct directory. I can reproduce it easily while just running pkgorder on the /os tree that is generated by pungi, as you earlier suggested. During build and debugging pkgorder, I have seen that processTransaction() searches for the relative path of a package. This path is mostly called os/Myproduct (Uppercase-M) instead of os/myproduct. (Lowercase-M) os/Myproduct (Uppercase-M) does not exist, so the package cannot be found. (the lacking 631 packages) Some packages are searched in os/myproduct (lowercase-M), and these are found correctly. (the 31 I had) Due to a bug in pkgorder this 'file-not-found' issue is not visible to the outside world. I have a patch for this, so that this it is at least visible that this happens. As a test, I have renamed the product_name to Myproduct (Uppercase-M). If I do that I end up with 631 packages in /os-disc1, lacking the 31 I had while using the lowercase M. The packages that are searched for, in the wrong directory, can come from any repo, i.e. fc6-dvd, fc6-updates, or my own custom repo, but always the same packages go wrong. > Are you getting multiple product dirs somehow? I am thus NOT getting multiple product dirs in /os-disc1. It is not a destination (/os-disc1) problem but a package gathering problem from /os. Do you have any idea how the relative-paths are resolved from the /os repository? I am certain that the cause is there somewhere, but I already spent 2 days debugging pkgorder with pdb, and it does not bring me any closer the root cause :-(( I do not understand the relation to yum/package-dictionaries etc. Notice that I have verified that dependency resolving works fine... I really hope you can help me on this... Kind Regards, Remy 2007/2/5, Jesse Keating : > On Monday 05 February 2007 11:53, Remy Bohmer wrote: > > For some reason pkgorder is really stubborn, and still mixes up the > > productname by changing the first letter of several packages. It does > > not matter where the packages come from, either from the orignal > > FC6-DVD , or from the FC6-Updates repo, or from my custom repo. Even > > if I build without my own repo, does not matter. > > Notice that a bug in pkgorder does not even tell anybody if it can > > find a package at all, it just continuous, resulting in an incomplete > > CD-image... > > > > So, does anyone know how the location of a package is determined in > > pkgorder? (I mean the relative path inside a repo, with the product > > name) > > > > It does NOT read it from Pungi configuration file (Tried to change it > > completely, no result) > > Tried to change the product name on the commandline of pkgorder -> no > > result either... > > > > So, nowhere in my tree I can find the wrong productname, and neither > > does any change of any product_name setting help. > > > > I really hope, someone can help me out here... I am starting to get > > quite desperate about these tools... :-(( > > Er, Are you putting packages into different directories under os/ ? I'm > pretty sure that the way pungi is designed, all your packages would (by > default) go under os/Fedora/ ALL packages, regardless of what repository > they come from. Are you getting multiple product dirs somehow? I'm > seriously having a hard time figuring out how you're getting to this stage. > > -- > Jesse Keating > Release Engineer: Fedora > > From williams at redhat.com Tue Feb 6 21:07:36 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 06 Feb 2007 15:07:36 -0600 Subject: Quick question for mock users Message-ID: <45C8EE18.3030600@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While working on a cross compilation project that uses mock to manage a long-term chroot, I got quite annoyed that when mock throws an error due to a failed command, I would have to go dig into the log files to find what went wrong. It occurred to me that since there's error output going out from an exception, there *shouldn't* be a problem with printing the output of the failing command on stderr. So the question to users of mock (especially the plague folks): Will adding the error output of a failed command to the stderr stream from mock cause problems to programs calling mock? Thanks, Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFyO4YHyuj/+TTEp0RAoS/AJ9qCwisXA43dMU4DGGAUdHocnOeKgCfejM4 2bCFKihmCi+LDYj8dmevVWg= =KZw0 -----END PGP SIGNATURE----- From mikem at redhat.com Tue Feb 6 23:31:56 2007 From: mikem at redhat.com (Mike McLean) Date: Tue, 06 Feb 2007 18:31:56 -0500 Subject: Quick question for mock users In-Reply-To: <45C8EE18.3030600@redhat.com> References: <45C8EE18.3030600@redhat.com> Message-ID: <45C90FEC.8010002@redhat.com> Clark Williams wrote: > Will adding the error output of a failed command to the stderr stream > from mock cause problems to programs calling mock? I don't believe it will matter to Koji. From williams at redhat.com Wed Feb 7 16:45:23 2007 From: williams at redhat.com (Clark Williams) Date: Wed, 07 Feb 2007 10:45:23 -0600 Subject: Quick question for mock users In-Reply-To: <45C90FEC.8010002@redhat.com> References: <45C8EE18.3030600@redhat.com> <45C90FEC.8010002@redhat.com> Message-ID: <45CA0223.1050907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McLean wrote: > Clark Williams wrote: >> Will adding the error output of a failed command to the stderr stream >> from mock cause problems to programs calling mock? > > I don't believe it will matter to Koji. > Works for me. Next version (0.6.11) will have this in it. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFygIjHyuj/+TTEp0RAlHaAJ4/Js8YPB8AWjIxq0LpSq3KPjujWQCgp1T8 m7myFJu2zXbcBdB6rLlHGko= =o+Me -----END PGP SIGNATURE----- From essien at wazobialinux.com Thu Feb 8 12:54:31 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Thu, 08 Feb 2007 13:54:31 +0100 Subject: w00t!!! Message-ID: <45CB1D87.9050807@wazobialinux.com> Hiya All, First off... pungi is looking fantastic so far!!! I have a set of tools that do the same thing that pungi does... (i call it fcdistroutils, and i've been using it since FC4). Lately, I've had problem after problem with it, and when posting on the anaconda-devel list, Jesse Keating suggested I look at pungi... and so far... sooo cool :) I'm currently watching pungi run buildinstall, lets see if it works for me first try (i really hope it does... it blows my fcdistroutils out of the water). Anyways, as I keep using it, I'll be sure to help out in anyway that I can. A quick idea-type-suggestive-question-kinda anyone mulling over an integrated system that combines pungi and pilgrim? (I just ran across pilgrim last week too). I used to use fcdistro to build both my Installation CD, LiveCD (based off of kadischi) and ThinClient Image(s) (based off of kadischi). It would be nice to have a nice integrated system that allows you to just edit config files, and generate either: Install CD(s) Install DVD(s?) Live CD Live DVD root image(s) Complete dd-able thin-client image(s) Oh.. and btw, pungi is already at: 'Creating Little endian 3.0 filesystem on /tmp/minstg2.img.11522, block size 65536.' this may just work yet at first try :) Thanks for the Good Work. Cheers, Essien From jkeating at redhat.com Thu Feb 8 13:14:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:14:01 -0500 Subject: w00t!!! In-Reply-To: <45CB1D87.9050807@wazobialinux.com> References: <45CB1D87.9050807@wazobialinux.com> Message-ID: <200702080814.06850.jkeating@redhat.com> On Thursday 08 February 2007 07:54, Essien Ita Essien wrote: > A quick idea-type-suggestive-question-kinda anyone mulling over an > integrated system that combines pungi and pilgrim? (I just ran across > pilgrim last week too). I used to use fcdistro to build both my > Installation CD, LiveCD (based off of kadischi) and ThinClient Image(s) > (based off of kadischi). It would be nice to have a nice integrated > system that allows you to just edit config files, and generate either: > ? ? Install CD(s) > ? ? Install DVD(s?) > ? ? Live CD > ? ? Live DVD > ? ? root image(s) > ? ? Complete dd-able thin-client image(s) yes, I do plan on integrating pilgrim with pungi somehow. I may end up helping David rewrite some of pilgrim to be more modular so that I can import it and call some of what it does rather than just execing it. Over the next couple of months is when I plan on doing this. Thanks for trying out 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 essien at wazobialinux.com Fri Feb 9 10:54:19 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Fri, 09 Feb 2007 11:54:19 +0100 Subject: w00t!!! In-Reply-To: <200702080814.06850.jkeating@redhat.com> References: <45CB1D87.9050807@wazobialinux.com> <200702080814.06850.jkeating@redhat.com> Message-ID: <45CC52DB.8000305@wazobialinux.com> Jesse Keating wrote: > On Thursday 08 February 2007 07:54, Essien Ita Essien wrote: > >> A quick idea-type-suggestive-question-kinda anyone mulling over an >> integrated system that combines pungi and pilgrim? (I just ran across >> pilgrim last week too). I used to use fcdistro to build both my >> Installation CD, LiveCD (based off of kadischi) and ThinClient Image(s) >> (based off of kadischi). It would be nice to have a nice integrated >> system that allows you to just edit config files, and generate either: >> Install CD(s) >> Install DVD(s?) >> Live CD >> Live DVD >> root image(s) >> Complete dd-able thin-client image(s) >> > > yes, I do plan on integrating pilgrim with pungi somehow. I may end up > helping David rewrite some of pilgrim to be more modular so that I can import > it and call some of what it does rather than just execing it. Over the next > couple of months is when I plan on doing this. > > Thanks for trying out pungi! (: > where's the source control for pungi hosted (i'm assuming/hoping svn? :) )? And is there public access to the tree? > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jkeating at redhat.com Fri Feb 9 13:01:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 08:01:55 -0500 Subject: w00t!!! In-Reply-To: <45CC52DB.8000305@wazobialinux.com> References: <45CB1D87.9050807@wazobialinux.com> <200702080814.06850.jkeating@redhat.com> <45CC52DB.8000305@wazobialinux.com> Message-ID: <200702090801.59324.jkeating@redhat.com> On Friday 09 February 2007 05:54, Essien Ita Essien wrote: > where's the source control for pungi hosted (i'm assuming/hoping svn? :) > )? And is there public access to the tree? Source is hosted in Mercurial. http://hg.fedoraproject.org/hg/hosted/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 essien at wazobialinux.com Mon Feb 12 11:43:51 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 12:43:51 +0100 Subject: [patch][pungi] makefile-newtargets Message-ID: <45D052F7.9070004@wazobialinux.com> Hiya, I'm attaching a small patch here, that adds some new make targets to the makefile. making it easier to modify the code and test. Not sure if this is the right place to send it to, if its not, please correct me. Cheers, Essien -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile-newtargets.patch Type: text/x-patch Size: 1397 bytes Desc: not available URL: From essien at wazobialinux.com Mon Feb 12 11:51:44 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 12:51:44 +0100 Subject: [patch][pungi] pungi-splitstages Message-ID: <45D054D0.5060600@wazobialinux.com> Hiya, This is another small patch. What it does is breakup the pungi process into different stages that can be invoked independently without going thru all the stages. the stages are: - Gather (-G) - Buildinstall (-B) - Package Order (-P) - Splittree (-S) - Iso Creation (-I) If none of this switches is specified, then the default behaviour continues (i.e, all are run one after the other), specifying *any* of the flags will cause the stage to be run. This split-up actually helps in scenarios when you change something, and know what you should be doing next, but do not want to run the whole process again. It also helps when debugging the process. A little issue though is that, I wasn't sure which stage that doGetRelnotes should fall under, so I put it under PackageOrdering stage, so each time -P is run, GetRelnotes() will also be run. Cheers, Essien From essien at wazobialinux.com Mon Feb 12 12:38:23 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 13:38:23 +0100 Subject: [pungi] flavor? and getsources Message-ID: <45D05FBF.4060303@wazobialinux.com> Hi again, What's the idea behind the 'flavor' configuration keyword in pungi (using lattest tip). On inspecition, It seems to be appended to the version number and used to create directory paths. I guess I just want to know the "why" behind it :), or more like, the domain equivalence... basically... what the heck is a flavor :) cheers, Essien From jkeating at redhat.com Mon Feb 12 15:29:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 10:29:37 -0500 Subject: [patch][pungi] pungi-splitstages In-Reply-To: <45D054D0.5060600@wazobialinux.com> References: <45D054D0.5060600@wazobialinux.com> Message-ID: <200702121029.37850.jkeating@redhat.com> On Monday 12 February 2007 06:51, Essien Ita Essien wrote: > This is another small patch. What it does is breakup the pungi process > into different stages that can be invoked independently without going > thru all the stages. the stages are: > > ? ? - Gather (-G) > ? ? - Buildinstall (-B) > ? ? - Package Order (-P) > ? ? - Splittree (-S) > ? ? - Iso Creation (-I) Hi, there is no patch attached... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 12 15:31:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 10:31:01 -0500 Subject: [pungi] flavor? and getsources In-Reply-To: <45D05FBF.4060303@wazobialinux.com> References: <45D05FBF.4060303@wazobialinux.com> Message-ID: <200702121031.02104.jkeating@redhat.com> On Monday 12 February 2007 07:38, Essien Ita Essien wrote: > What's the idea behind the 'flavor' configuration keyword in pungi > (using lattest tip). On inspecition, It seems to be appended to the > version number and used to create directory paths. I guess I just want > to know the "why" behind it :), or more like, the domain equivalence... > basically... what the heck is a flavor :) With Fedora 7, we're introducing a targetted spin idea, that is a compose of the packages for a particular target, like Desktop. In order to signify what target a given spin is for, I introduced the flavor argument, which as you noted, will append the flavor to the path. This way you can have the same topdir but with many different flavors. It is purely optional though, if no flavor is specified, it will not 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 essien at wazobialinux.com Mon Feb 12 16:08:23 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 17:08:23 +0100 Subject: [patch][pungi] pungi-splitstages In-Reply-To: <200702121029.37850.jkeating@redhat.com> References: <45D054D0.5060600@wazobialinux.com> <200702121029.37850.jkeating@redhat.com> Message-ID: <45D090F7.3050001@wazobialinux.com> Jesse Keating wrote: > On Monday 12 February 2007 06:51, Essien Ita Essien wrote: > >> This is another small patch. What it does is breakup the pungi process >> into different stages that can be invoked independently without going >> thru all the stages. the stages are: >> >> - Gather (-G) >> - Buildinstall (-B) >> - Package Order (-P) >> - Splittree (-S) >> - Iso Creation (-I) >> > > Hi, there is no patch attached... > > DOH!!! > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- A non-text attachment was scrubbed... Name: pungi-splitstages.patch Type: text/x-patch Size: 4963 bytes Desc: not available URL: From essien at wazobialinux.com Mon Feb 12 16:10:34 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 17:10:34 +0100 Subject: [pungi] flavor? and getsources In-Reply-To: <200702121031.02104.jkeating@redhat.com> References: <45D05FBF.4060303@wazobialinux.com> <200702121031.02104.jkeating@redhat.com> Message-ID: <45D0917A.5010009@wazobialinux.com> Jesse Keating wrote: > On Monday 12 February 2007 07:38, Essien Ita Essien wrote: > >> What's the idea behind the 'flavor' configuration keyword in pungi >> (using lattest tip). On inspecition, It seems to be appended to the >> version number and used to create directory paths. I guess I just want >> to know the "why" behind it :), or more like, the domain equivalence... >> basically... what the heck is a flavor :) >> > > With Fedora 7, we're introducing a targetted spin idea, that is a compose of > the packages for a particular target, like Desktop. In order to signify what > target a given spin is for, I introduced the flavor argument, which as you > noted, will append the flavor to the path. This way you can have the same > topdir but with many different flavors. It is purely optional though, if no > flavor is specified, it will not be used. > ahh... i c. thanks for the explanation... makes perfect sense. btw, if flavor is not specified, a lot of portions break, i'll investigate better and send a patch. > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From essien at wazobialinux.com Mon Feb 12 16:27:52 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 17:27:52 +0100 Subject: [patch][pungi] pungi-splitstages In-Reply-To: <45D090F7.3050001@wazobialinux.com> References: <45D054D0.5060600@wazobialinux.com> <200702121029.37850.jkeating@redhat.com> <45D090F7.3050001@wazobialinux.com> Message-ID: <45D09588.1090608@wazobialinux.com> Essien Ita Essien wrote: > Jesse Keating wrote: >> On Monday 12 February 2007 06:51, Essien Ita Essien wrote: >> >>> This is another small patch. What it does is breakup the pungi process >>> into different stages that can be invoked independently without going >>> thru all the stages. the stages are: >>> >>> - Gather (-G) >>> - Buildinstall (-B) >>> - Package Order (-P) >>> - Splittree (-S) >>> - Iso Creation (-I) >>> >> >> Hi, there is no patch attached... >> >> > DOH!!! please ignore previous patch... correct one is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: pungi-splitstages.patch Type: text/x-patch Size: 3445 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 12 16:36:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 11:36:08 -0500 Subject: [pungi] flavor? and getsources In-Reply-To: <45D0917A.5010009@wazobialinux.com> References: <45D05FBF.4060303@wazobialinux.com> <200702121031.02104.jkeating@redhat.com> <45D0917A.5010009@wazobialinux.com> Message-ID: <200702121136.09188.jkeating@redhat.com> On Monday 12 February 2007 11:10, Essien Ita Essien wrote: > btw, if flavor is not specified, a lot of portions break, i'll > investigate better and send > a patch. Really? Hrm, I thought I tested that functionality. That was my intent rather, that if flavor wasn't specified that it would be "", and thus os.path.join calls would just work. -- 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 essien at wazobialinux.com Mon Feb 12 16:51:10 2007 From: essien at wazobialinux.com (Essien Ita Essien) Date: Mon, 12 Feb 2007 17:51:10 +0100 Subject: [pungi] flavor? and getsources In-Reply-To: <200702121136.09188.jkeating@redhat.com> References: <45D05FBF.4060303@wazobialinux.com> <200702121031.02104.jkeating@redhat.com> <45D0917A.5010009@wazobialinux.com> <200702121136.09188.jkeating@redhat.com> Message-ID: <45D09AFE.7050500@wazobialinux.com> Jesse Keating wrote: > On Monday 12 February 2007 11:10, Essien Ita Essien wrote: > >> btw, if flavor is not specified, a lot of portions break, i'll >> investigate better and send >> a patch. >> > > Really? Hrm, I thought I tested that functionality. That was my intent > rather, that if flavor wasn't specified that it would be "", and thus > os.path.join calls would just work. > > please ignore, i got the result with the *wrong* patch that i sent earlier... the proper patch against mercurial tip doesn't give this problem. my bad. > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jkeating at redhat.com Mon Feb 12 21:49:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 16:49:20 -0500 Subject: [patch][pungi] makefile-newtargets In-Reply-To: <45D052F7.9070004@wazobialinux.com> References: <45D052F7.9070004@wazobialinux.com> Message-ID: <200702121649.20221.jkeating@redhat.com> On Monday 12 February 2007 06:43, Essien Ita Essien wrote: > Hiya, > > I'm attaching a small patch here, that adds some new make targets to the > makefile. making it easier to modify the code and test. > Not sure if this is the right place to send it to, if its not, please > correct me. Applied. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 12 22:48:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 17:48:14 -0500 Subject: [patch][pungi] pungi-splitstages In-Reply-To: <45D09588.1090608@wazobialinux.com> References: <45D054D0.5060600@wazobialinux.com> <45D090F7.3050001@wazobialinux.com> <45D09588.1090608@wazobialinux.com> Message-ID: <200702121748.18050.jkeating@redhat.com> On Monday 12 February 2007 11:27, Essien Ita Essien wrote: > please ignore previous patch... correct one is attached. Applied. -- 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 bugs.michael at gmx.net Sat Feb 17 11:33:31 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Feb 2007 12:33:31 +0100 Subject: The fc6 vs. fc7 buildsys issue again Message-ID: <20070217123331.9f076a19.bugs.michael@gmx.net> Does anyone understand the following build job? Copy of the page is appended below. http://buildsys.fedoraproject.org/build-status/job.psp?uid=27730 Target fc6, tag fc6, but the buildsys used fc7 in paths and created a fc7 src.rpm, but fc6 binary rpms: http://buildsys.fedoraproject.org/logs/fedora-6-extras/27730-mono-debugger-0.30-7.fc7/mono- debugger-0.30-7.fc7.src.rpm How is that possible when plague-client targets fc6? [...] 27730: mono-debugger-0.30-7.fc7 (needsign) Target: fedora-6-extras Submitter: paul all-the-johnsons co uk Source: mono-debugger-0_30-7_fc6 Started: Fri Feb 16 16:09:25 2007 Ended: Fri Feb 16 16:17:47 2007 (ran for 8 minutes) Logs: http://buildsys.fedoraproject.org/logs/fedora-6-extras/27730-mono-debugger-0.30-7.fc7/ Result: " 27730 (mono-debugger): Build on target fedora-6-extras succeeded. " x86_64: hammer2.fedora.redhat.com Status: done/done Build Time: 7 minutes i386: xenbuilder2.fedora.redhat.com Status: done/done Build Time: 8 minutes From mythtv.bohmer at gmail.com Sun Feb 18 21:37:21 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Sun, 18 Feb 2007 22:37:21 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200702051411.36667.jkeating@redhat.com> Message-ID: Hello All, To finish this thread: Due to this bug, I believe that Pungi/Anaconda is not ready yet for building a really custom installation CD, derived from Fedora 6 and custom repositories. It took me a lot of time and finally I had to give it up. I want to thank the people that helped me so far for their efforts. Unfortunately I am not going to be using it any further. Kind Regards, Remy Bohmer 2007/2/5, Remy Bohmer : > Hello Jesse, > > What you mention is exactly what I want, except my product is not > named Fedora, but something else... > I will summarise the facts here below, hope this clears something up. > > > Are you putting packages into different directories under os/ ? > No, the /os/ is an intermediate buildresult of what pungi (with > anaconda) is doing. I am not modifying it in any way. My goal is to > use as many standard tooling as possible, without the need for me to > modify the tools. (Except if there is a need for a bugfix) > > So, only 1 directory with packages is there in /os/myproduct, not 2. > > But after building the /os directory pungi calls at some point > pkgorder and this one introduces a problem while building the > os-disc1/myproduct directory. > I can reproduce it easily while just running pkgorder on the /os tree > that is generated by pungi, as you earlier suggested. > > During build and debugging pkgorder, I have seen that > processTransaction() searches for the relative path of a package. This > path is mostly called os/Myproduct (Uppercase-M) instead of > os/myproduct. (Lowercase-M) os/Myproduct (Uppercase-M) does not exist, > so the package cannot be found. (the lacking 631 packages) Some > packages are searched in os/myproduct (lowercase-M), and these are > found correctly. (the 31 I had) > Due to a bug in pkgorder this 'file-not-found' issue is not visible to > the outside world. I have a patch for this, so that this it is at > least visible that this happens. > > As a test, I have renamed the product_name to Myproduct (Uppercase-M). > If I do that I end up with 631 packages in /os-disc1, lacking the 31 I > had while using the lowercase M. > > The packages that are searched for, in the wrong directory, can come > from any repo, i.e. fc6-dvd, fc6-updates, or my own custom repo, but > always the same packages go wrong. > > > Are you getting multiple product dirs somehow? > I am thus NOT getting multiple product dirs in /os-disc1. It is not a > destination (/os-disc1) problem but a package gathering problem from > /os. > > Do you have any idea how the relative-paths are resolved from the /os > repository? > I am certain that the cause is there somewhere, but I already spent 2 > days debugging pkgorder with pdb, and it does not bring me any closer > the root cause :-(( > I do not understand the relation to yum/package-dictionaries etc. > Notice that I have verified that dependency resolving works fine... > > I really hope you can help me on this... > > > Kind Regards, > > Remy > > > > 2007/2/5, Jesse Keating : > > On Monday 05 February 2007 11:53, Remy Bohmer wrote: > > > For some reason pkgorder is really stubborn, and still mixes up the > > > productname by changing the first letter of several packages. It does > > > not matter where the packages come from, either from the orignal > > > FC6-DVD , or from the FC6-Updates repo, or from my custom repo. Even > > > if I build without my own repo, does not matter. > > > Notice that a bug in pkgorder does not even tell anybody if it can > > > find a package at all, it just continuous, resulting in an incomplete > > > CD-image... > > > > > > So, does anyone know how the location of a package is determined in > > > pkgorder? (I mean the relative path inside a repo, with the product > > > name) > > > > > > It does NOT read it from Pungi configuration file (Tried to change it > > > completely, no result) > > > Tried to change the product name on the commandline of pkgorder -> no > > > result either... > > > > > > So, nowhere in my tree I can find the wrong productname, and neither > > > does any change of any product_name setting help. > > > > > > I really hope, someone can help me out here... I am starting to get > > > quite desperate about these tools... :-(( > > > > Er, Are you putting packages into different directories under os/ ? I'm > > pretty sure that the way pungi is designed, all your packages would (by > > default) go under os/Fedora/ ALL packages, regardless of what repository > > they come from. Are you getting multiple product dirs somehow? I'm > > seriously having a hard time figuring out how you're getting to this stage. > > > > -- > > Jesse Keating > > Release Engineer: Fedora > > > > > From dennis at ausil.us Sun Feb 18 22:35:05 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 18 Feb 2007 16:35:05 -0600 Subject: The fc6 vs. fc7 buildsys issue again In-Reply-To: <20070217123331.9f076a19.bugs.michael@gmx.net> References: <20070217123331.9f076a19.bugs.michael@gmx.net> Message-ID: <200702181635.12293.dennis@ausil.us> Once upon a time Saturday 17 February 2007, Michael Schwendt wrote: > Does anyone understand the following build job? Copy of the page is > appended below. > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=27730 > > Target fc6, tag fc6, but the buildsys used fc7 in paths and created > a fc7 src.rpm, but fc6 binary rpms: > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27730-mono-debugger- >0.30-7.fc7/mono- debugger-0.30-7.fc7.src.rpm > > How is that possible when plague-client targets fc6? > > [...] > > 27730: mono-debugger-0.30-7.fc7 (needsign) > Target: fedora-6-extras > Submitter: paul all-the-johnsons co uk > Source: mono-debugger-0_30-7_fc6 > Started: Fri Feb 16 16:09:25 2007 > Ended: Fri Feb 16 16:17:47 2007 (ran for 8 minutes) > Logs: http://buildsys.fedoraproject.org/logs/fedora-6-extras/27730-mono-deb >ugger-0.30-7.fc7/ Result: " > > 27730 (mono-debugger): Build on target fedora-6-extras succeeded. > " > > > x86_64: hammer2.fedora.redhat.com Status: done/done Build Time: 7 > minutes i386: xenbuilder2.fedora.redhat.com Status: done/done Build > Time: 8 minutes I really have no clue what causes this. plague-server log shows 27730 (mono-debugger): Starting tag 'mono-debugger-0_30-7_fc6' on target 'fedora-6-extras' 27730 (mono-debugger/x86_64): https://hammer2.fedora.redhat.com:8888 - UID is 5a1ed5c1106cd3598ed723b9cac58f7172dcf1cc 27730 (mono-debugger/i386): https://xenbuilder2.fedora.redhat.com:8888 - UID is e81377a186d5809ba288ee5faf32ee2f34d65a32 27730 (mono-debugger/x86_64): Build result files - [ 'root.log', 'mono-debugger-0.30-7.fc6.src.rpm', 'mono-debugger-devel-0.30-7.fc6.x86_64.rpm', 'mockconfig.log', 'job.log', 'mono-debugger-0.30-7.fc6.x86_64.rpm', 'build.log', 'mono-debugger-debuginfo-0.30-7.fc6.x86_64.rpm' ] 27730 (mono-debugger/i386): Build result files - [ 'root.log', 'mono-debugger-debuginfo-0.30-7.fc6.i386.rpm', 'mono-debugger-0.30-7.fc6.src.rpm', 'job.log', 'mono-debugger-devel-0.30-7.fc6.i386.rpm', 'mono-debugger-0.30-7.fc6.i386.rpm', 'build.log', 'mockconfig.log' ] 27730 (mono-debugger): Job finished. the .fc7 seems to be coming from make srpm at the start of the build. that srpm gets uploaded to the builders to build . there is nothing on the server configs that defines this it comes entirely from the cvs co and Makefiles there. builders are building the correct thing. Why make srpm is doing the wrong thing i do not know. if it was genuinely a mis configuration it would show on each and every build. possibly it is a race condition in plague. there is much less chance of odd race conditions in koji as it is largely single threaded. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From esammons at hush.com Mon Feb 19 16:56:36 2007 From: esammons at hush.com (Earl) Date: Mon, 19 Feb 2007 11:56:36 -0500 Subject: Pungi: Howto build all FC6 Message-ID: <20070219165637.57E19DA84F@mailserver8.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nice that the default is to build a minimal 1 CD but now that pungi uses "Manifest" how does one go about building the entire media set for FC6 on the latest version (0.2.4-1). Thanks. Earl -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkXZ0/kACgkQk7+e+4lPSm2+BgCePe5HtqPWIiEt0d2027gqJN0VgRoA n3sq9m6QybXHnLfR6mThw8zFQu8O =1u+O -----END PGP SIGNATURE----- From jkeating at redhat.com Mon Feb 19 17:10:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 12:10:27 -0500 Subject: Pungi: Howto build all FC6 In-Reply-To: <20070219165637.57E19DA84F@mailserver8.hushmail.com> References: <20070219165637.57E19DA84F@mailserver8.hushmail.com> Message-ID: <200702191210.30448.jkeating@redhat.com> On Monday 19 February 2007 11:56, Earl wrote: > Nice that the default is to build a minimal 1 CD but now that pungi > uses "Manifest" how does one go about building the entire media set > for FC6 on the latest version (0.2.4-1). I'm not sure the devel builds of pungi will actually work to compose FC6. It uses some yum / anaconda functions not available in FC6. To compose FC6 its best to use the pungi published in Fedora Extras for FC6. -- 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 anthony.seward at ieee.org Fri Feb 23 22:52:12 2007 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Fri, 23 Feb 2007 15:52:12 -0700 Subject: troubleshooting a build failure under mock Message-ID: <1172271132.18940.55.camel@fleuret> My situation is this: my build system is running Scientific Linux 4.4 (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM when trying to compile a fortran file. The error issued is mkscrlib.f:381: internal compiler error: Illegal instruction When I set up mock 0.6.12 on my laptop running FC6 with all updates and run the same script to build the RPM, it builds just fine. The target distribution for the mock build is FC6. SELinux is disabled on the SL 4.4 box. When I run mock with '--debug', there is a lot of information, but I have no idea what to look for or how to continue to troubleshoot this. Can anyone offer any suggestions? Tony From csieh at fnal.gov Fri Feb 23 23:42:15 2007 From: csieh at fnal.gov (Connie Sieh) Date: Fri, 23 Feb 2007 17:42:15 -0600 (CST) Subject: troubleshooting a build failure under mock In-Reply-To: <1172271132.18940.55.camel@fleuret> References: <1172271132.18940.55.camel@fleuret> Message-ID: On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: > My situation is this: my build system is running Scientific Linux 4.4 > (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM > when trying to compile a fortran file. The error issued is > > mkscrlib.f:381: internal compiler error: Illegal instruction What rpm are you trying to build? > > When I set up mock 0.6.12 on my laptop running FC6 with all updates and > run the same script to build the RPM, it builds just fine. > > The target distribution for the mock build is FC6. > > SELinux is disabled on the SL 4.4 box. > > When I run mock with '--debug', there is a lot of information, but I > have no idea what to look for or how to continue to troubleshoot this. > > Can anyone offer any suggestions? > > Tony > > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -Connie Sieh From anthony.seward at ieee.org Fri Feb 23 23:43:15 2007 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Fri, 23 Feb 2007 16:43:15 -0700 Subject: troubleshooting a build failure under mock In-Reply-To: References: <1172271132.18940.55.camel@fleuret> Message-ID: <1172274195.25626.1.camel@fleuret> On Fri, 2007-02-23 at 17:42 -0600, Connie Sieh wrote: > On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: > > > My situation is this: my build system is running Scientific Linux 4.4 > > (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM > > when trying to compile a fortran file. The error issued is > > > > mkscrlib.f:381: internal compiler error: Illegal instruction > > What rpm are you trying to build? > An in-house application for work. > > > > When I set up mock 0.6.12 on my laptop running FC6 with all updates and > > run the same script to build the RPM, it builds just fine. > > > > The target distribution for the mock build is FC6. > > > > SELinux is disabled on the SL 4.4 box. > > > > When I run mock with '--debug', there is a lot of information, but I > > have no idea what to look for or how to continue to troubleshoot this. > > > > Can anyone offer any suggestions? > > > > Tony > > > > > > > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > > -Connie Sieh > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > From mail-lists at karan.org Sat Feb 24 00:13:45 2007 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 24 Feb 2007 00:13:45 +0000 Subject: troubleshooting a build failure under mock In-Reply-To: <1172274195.25626.1.camel@fleuret> References: <1172271132.18940.55.camel@fleuret> <1172274195.25626.1.camel@fleuret> Message-ID: <45DF8339.2020201@karan.org> Anthony Joseph Seward wrote: > On Fri, 2007-02-23 at 17:42 -0600, Connie Sieh wrote: >> On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: >> >>> My situation is this: my build system is running Scientific Linux 4.4 >>> (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM >>> when trying to compile a fortran file. The error issued is >>> >>> mkscrlib.f:381: internal compiler error: Illegal instruction >> What rpm are you trying to build? >> > > An in-house application for work. if you post your .src.rpm online somewhere, someone might be able to help debug the issue. -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From anthony.seward at ieee.org Sat Feb 24 00:47:37 2007 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Fri, 23 Feb 2007 17:47:37 -0700 Subject: troubleshooting a build failure under mock In-Reply-To: <45DF8339.2020201@karan.org> References: <1172271132.18940.55.camel@fleuret> <1172274195.25626.1.camel@fleuret> <45DF8339.2020201@karan.org> Message-ID: <1172278057.25626.7.camel@fleuret> On Sat, 2007-02-24 at 00:13 +0000, Karanbir Singh wrote: > Anthony Joseph Seward wrote: > > On Fri, 2007-02-23 at 17:42 -0600, Connie Sieh wrote: > >> On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: > >> > >>> My situation is this: my build system is running Scientific Linux 4.4 > >>> (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM > >>> when trying to compile a fortran file. The error issued is > >>> > >>> mkscrlib.f:381: internal compiler error: Illegal instruction > >> What rpm are you trying to build? > >> > > > > An in-house application for work. > > if you post your .src.rpm online somewhere, someone might be able to > help debug the issue. > I don't think the .src.rpm is the issue. Again, using the same version of mock, the RPM will build when mock is hosted on an FC 6 system but not when running SL 4.4. Tony From ken at bitsko.slc.ut.us Sun Feb 25 20:26:16 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: 25 Feb 2007 14:26:16 -0600 Subject: plague on fc7 with sqlite, xmlrpc problems Message-ID: <87odnihtlj.fsf@bitsko.slc.ut.us> I'm trying to get plague set up and I'm running into compatibility problems that lead me to think I'm starting in the wrong place. I picked FC7 and sqlite to start with for plague's home OS and a non-DB-server DB option. The production system will be RHEL4/5 once I'm comfortable I know how to get things running smoothly. I tried briefly with RHEL4 a few months back and didn't get this far. I started with a fresh install of FC7 (incl. python-2.5, python-sqlite2) and plague 0.4.4.1-4.fc7 RPMs. After running into some of the first issues I switched to CVS MAIN with similar results. Here's what I've done so far: * server/DBManager.py - import sqlite3 as sqlite - remove encoding="utf-8" from sqlite.connect * server/main.py * server/BuildMaster.py - sqlite hack: move dbm connection into BuildMaster so it can create one for each thread. * common/XMLRPCServerProxy.py - set self._use_datetime = 0 * common/AuthedXMLRPCServer.py - pass allow_none=False and encoding=None to SimpleXMLRPCServer.SimpleXMLRPCDispatcher's * builder/Config.py server/Config.py - change BaseConfig.BaseConfig.ConfigError to BaseConfig.ConfigError I have the builder and server on the same host, w/o SSL yet. With the 0.4.4.1 RPMs and some of the changes above the server was able to talk to the builder but I ran into the sqlite problem and switched to CVS at that point. CVS has the new Active/Passive builders but the default port configs don't appear to be correct for having the builder and server on the same machine, but I can't match up the config sections and field names in the server and builder configs to point them at each other correctly. At this point, the server's not seeing any builders. I tried running 'plague-client list' anyway and get an exception "local variable 'curs' referenced before assignment" which I'm pretty sure is caused by my sqlite thread hack. What OS+versions should I use to get plague up and running most quickly? Once I'm up and running in a known-working environment I'd have a better idea of what changes are right for FC7 or RHEL4/5. Thanks, -- Ken From oliver at linux-kernel.at Mon Feb 26 11:06:50 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Feb 2007 12:06:50 +0100 Subject: plague on fc7 with sqlite, xmlrpc problems In-Reply-To: <87odnihtlj.fsf@bitsko.slc.ut.us> References: <87odnihtlj.fsf@bitsko.slc.ut.us> Message-ID: <45E2BF4A.5090508@linux-kernel.at> Hi Ken! Am 2007-02-25 21:26, Ken MacLeod schrieb: [ ... ] > Here's what I've done so far: > > * server/DBManager.py > - import sqlite3 as sqlite > - remove encoding="utf-8" from sqlite.connect > > * server/main.py > * server/BuildMaster.py > - sqlite hack: move dbm connection into BuildMaster so > it can create one for each thread. > > * common/XMLRPCServerProxy.py > - set self._use_datetime = 0 Why that? > * common/AuthedXMLRPCServer.py > - pass allow_none=False and encoding=None to > SimpleXMLRPCServer.SimpleXMLRPCDispatcher's Why that? > * builder/Config.py > server/Config.py > - change BaseConfig.BaseConfig.ConfigError to > BaseConfig.ConfigError Yes. I already submitted a patch to Dan for this. > I have the builder and server on the same host, w/o SSL yet. With the > 0.4.4.1 RPMs and some of the changes above the server was able to talk > to the builder but I ran into the sqlite problem and switched to CVS > at that point. So you' running 0.5.0 now. The same as I do. Right? > CVS has the new Active/Passive builders but the default port configs > don't appear to be correct for having the builder and server on the > same machine, but I can't match up the config sections and field names > in the server and builder configs to point them at each other > correctly. At this point, the server's not seeing any builders. I > tried running 'plague-client list' anyway and get an exception "local > variable 'curs' referenced before assignment" which I'm pretty sure is > caused by my sqlite thread hack. > > What OS+versions should I use to get plague up and running most > quickly? I have plg 0.5.0. mysql 4.1.20 running on ES4. But I also have an instance running on FC6. > Once I'm up and running in a known-working environment I'd have a > better idea of what changes are right for FC7 or RHEL4/5. Example config: builder.cfg: ==================================== [General] comm_type = active builder_user = plague-builder hostname = somehost.somecompany.com server = somehost.somecompany.com debug = True max_jobs = 3 builder_cmd = /usr/bin/mock [Directories] target_configs_dir = /etc/plague/builder/targets builder_work_dir = /tmp/builder_work [SSL] use_ssl = False [Active] xmlrpc_port = 8889 fileserver_port= 8890 server.cfg: ==================================== [Database] engine = mysql [Directories] repo_dir = /repodir mock_configs_dir = /etc/mock server_work_dir = /rpmbuild target_configs_dir = /etc/plague/server/targets tmpdir = /tmp [Active Builders] xmlrpc_server_port = 8889 file_server_port = 8890 builder1 = 0 somehost2.somecompany.com builder2 = 50 somehost.somecompany.com [General] traceback_server = no hostname = somehost.somecompany.com depsolve_jobs = no Debug = True allow_reenqueue = no [SSL] server_key_and_cert = /etc/plague/server/certs/server/server_key_and_cert.pem ca_cert = /etc/plague/server/certs/ca/my_ca_ca_cert.pem [UI] log_url = http://somehost.somecompany.com/buildlogs/ guest_allowed = no port = 8887 use_ssl = yes client_ca_cert = /etc/plague/server/certs/ca/client_ca_ca_cert.pem [mysql Engine] timeout = 3 host = localhost user = root password = database = plague [CVS] use_cvs = yes [Builders] use_ssl = no [Email] success_emails = email_from = buildsys at somecompany.com admin_emails = of at redhat.at If you need help creating the ssl certificates or anything else, just mail me. :-) And don't use sqlite as database backend; It often runs into locking problems; That's why I switched to mysql. However, you do need to create the tables in the mysql database first. I have the statements ready if you need... Best, Oliver From dcbw at redhat.com Mon Feb 26 12:39:01 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 26 Feb 2007 07:39:01 -0500 Subject: plague on fc7 with sqlite, xmlrpc problems In-Reply-To: <45E2BF4A.5090508@linux-kernel.at> References: <87odnihtlj.fsf@bitsko.slc.ut.us> <45E2BF4A.5090508@linux-kernel.at> Message-ID: <1172493541.3061.2.camel@localhost.localdomain> On Mon, 2007-02-26 at 12:06 +0100, Oliver Falk wrote: > Hi Ken! > > Am 2007-02-25 21:26, Ken MacLeod schrieb: > [ ... ] > > Here's what I've done so far: > > > > * server/DBManager.py > > - import sqlite3 as sqlite > > - remove encoding="utf-8" from sqlite.connect Why these? > > * server/main.py > > * server/BuildMaster.py > > - sqlite hack: move dbm connection into BuildMaster so > > it can create one for each thread. sqlite sucks for threading, it's best to just setup a postgresql or mysql server. > > * common/XMLRPCServerProxy.py > > - set self._use_datetime = 0 > > Why that? Probably due to Python 2.5. > > * common/AuthedXMLRPCServer.py > > - pass allow_none=False and encoding=None to > > SimpleXMLRPCServer.SimpleXMLRPCDispatcher's > > Why that? > > > * builder/Config.py > > server/Config.py > > - change BaseConfig.BaseConfig.ConfigError to > > BaseConfig.ConfigError > > Yes. I already submitted a patch to Dan for this. Hmm, I thought I'd committed that. Will need to look again. > > I have the builder and server on the same host, w/o SSL yet. With the > > 0.4.4.1 RPMs and some of the changes above the server was able to talk > > to the builder but I ran into the sqlite problem and switched to CVS > > at that point. > > So you' running 0.5.0 now. The same as I do. Right? > > > CVS has the new Active/Passive builders but the default port configs > > don't appear to be correct for having the builder and server on the > > same machine, but I can't match up the config sections and field names > > in the server and builder configs to point them at each other > > correctly. At this point, the server's not seeing any builders. I > > tried running 'plague-client list' anyway and get an exception "local > > variable 'curs' referenced before assignment" which I'm pretty sure is > > caused by my sqlite thread hack. > > > > What OS+versions should I use to get plague up and running most > > quickly? > > I have plg 0.5.0. mysql 4.1.20 running on ES4. But I also have an > instance running on FC6. > > > Once I'm up and running in a known-working environment I'd have a > > better idea of what changes are right for FC7 or RHEL4/5. > > Example config: > builder.cfg: > ==================================== > [General] > comm_type = active > builder_user = plague-builder > hostname = somehost.somecompany.com > server = somehost.somecompany.com > debug = True > max_jobs = 3 > builder_cmd = /usr/bin/mock > > [Directories] > target_configs_dir = /etc/plague/builder/targets > builder_work_dir = /tmp/builder_work > > [SSL] > use_ssl = False > > [Active] > xmlrpc_port = 8889 > fileserver_port= 8890 > > > > > server.cfg: > ==================================== > [Database] > engine = mysql > > [Directories] > repo_dir = /repodir > mock_configs_dir = /etc/mock > server_work_dir = /rpmbuild > target_configs_dir = /etc/plague/server/targets > tmpdir = /tmp > > [Active Builders] > xmlrpc_server_port = 8889 > file_server_port = 8890 > builder1 = 0 somehost2.somecompany.com > builder2 = 50 somehost.somecompany.com > > [General] > traceback_server = no > hostname = somehost.somecompany.com > depsolve_jobs = no > Debug = True > allow_reenqueue = no > > [SSL] > server_key_and_cert = > /etc/plague/server/certs/server/server_key_and_cert.pem > ca_cert = /etc/plague/server/certs/ca/my_ca_ca_cert.pem > > [UI] > log_url = http://somehost.somecompany.com/buildlogs/ > guest_allowed = no > port = 8887 > use_ssl = yes > client_ca_cert = /etc/plague/server/certs/ca/client_ca_ca_cert.pem > > [mysql Engine] > timeout = 3 > host = localhost > user = root > password = > database = plague > > [CVS] > use_cvs = yes > > [Builders] > use_ssl = no > > [Email] > success_emails = > email_from = buildsys at somecompany.com > admin_emails = of at redhat.at > > > > If you need help creating the ssl certificates or anything else, just > mail me. :-) And don't use sqlite as database backend; It often runs > into locking problems; That's why I switched to mysql. However, you do > need to create the tables in the mysql database first. I have the > statements ready if you need... Yeah, using a real database is the way to go. Dan From oliver at linux-kernel.at Mon Feb 26 12:53:32 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Feb 2007 13:53:32 +0100 Subject: plague on fc7 with sqlite, xmlrpc problems In-Reply-To: <1172493541.3061.2.camel@localhost.localdomain> References: <87odnihtlj.fsf@bitsko.slc.ut.us> <45E2BF4A.5090508@linux-kernel.at> <1172493541.3061.2.camel@localhost.localdomain> Message-ID: <45E2D84C.7010809@linux-kernel.at> Am 2007-02-26 13:39, Dan Williams schrieb: > On Mon, 2007-02-26 at 12:06 +0100, Oliver Falk wrote: [ ... ] > Yeah, using a real database is the way to go. Maybe someone should also have a look at the default ports and other defaults... BUT... What's about plague? Will it live or will it die? I'm thinking about koji... :-) Best, Oliver From williams at redhat.com Mon Feb 26 15:17:47 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 26 Feb 2007 09:17:47 -0600 Subject: troubleshooting a build failure under mock In-Reply-To: <1172278057.25626.7.camel@fleuret> References: <1172271132.18940.55.camel@fleuret> <1172274195.25626.1.camel@fleuret> <45DF8339.2020201@karan.org> <1172278057.25626.7.camel@fleuret> Message-ID: <45E2FA1B.2080104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anthony Joseph Seward wrote: > On Sat, 2007-02-24 at 00:13 +0000, Karanbir Singh wrote: >> Anthony Joseph Seward wrote: >>> On Fri, 2007-02-23 at 17:42 -0600, Connie Sieh wrote: >>>> On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: >>>> >>>>> My situation is this: my build system is running Scientific Linux 4.4 >>>>> (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM >>>>> when trying to compile a fortran file. The error issued is >>>>> >>>>> mkscrlib.f:381: internal compiler error: Illegal instruction >>>> What rpm are you trying to build? >>>> >>> An in-house application for work. >> if you post your .src.rpm online somewhere, someone might be able to >> help debug the issue. >> > > I don't think the .src.rpm is the issue. > > Again, using the same version of mock, the RPM will build when mock is > hosted on an FC 6 system but not when running SL 4.4. > > Tony Hmmm. That sounds like the version of gfortran on SL4.4 has a problem. What's the version of the fortran package (gcc4-gfortran or gcc-gfortran)? Also, if you run the build by hand on SL4.4, do you still get the internal compiler error? If not, then there's something going on in the environment set up by mock. If you do, then you have a toolchain issue with gfortran and will need to take it up with your distro vendor :). Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF4vobHyuj/+TTEp0RAoNKAJ9UTS5Vsw/wuwjADz4Y7mS9KD9QRgCgtNz/ XxEqEA1x9NWD234igALf3Lg= =yMET -----END PGP SIGNATURE----- From mythtv.bohmer at gmail.com Mon Feb 26 15:25:49 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Mon, 26 Feb 2007 16:25:49 +0100 Subject: pungi ignores a lot of RPMs when building CD image -> I maybe got it Message-ID: Hello Jesse, A while I had the problem that caused Pungi/Anaconda to install a custom RPM with a case-sensitivity problem, which caused me to finally stop using Pungi to build my installation CD. But, I think I now got a clue that could have caused that problem: I found the following problem while I was using yum in a different situation: Yum always uses the default config file in /etc/yum.conf, even if there is another configuration file is specified on the commandline with the -c option. It combines both repositiories, and mixes several thinks up if there is more than repository with the same name. I have not tested it in combination with pungi, I do not have that build environment anymore that had this problem. Do you know where I should post this bug? Kind Regards, Remy From jkeating at redhat.com Mon Feb 26 15:35:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 10:35:18 -0500 Subject: pungi ignores a lot of RPMs when building CD image -> I maybe got it In-Reply-To: References: Message-ID: <200702261035.21654.jkeating@redhat.com> On Monday 26 February 2007 10:25, Remy Bohmer wrote: > I have not tested it in combination with pungi, I do not have that > build environment anymore that had this problem. > Do you know where I should post this bug? http://linux.duke.edu/projects/yum/ has a link on the left for bugzilla. Probably best to file it there and follow up with conversation on the yum lists. Good luck! -- 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 dcbw at redhat.com Mon Feb 26 16:48:38 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 26 Feb 2007 11:48:38 -0500 Subject: plague on fc7 with sqlite, xmlrpc problems In-Reply-To: <45E2D84C.7010809@linux-kernel.at> References: <87odnihtlj.fsf@bitsko.slc.ut.us> <45E2BF4A.5090508@linux-kernel.at> <1172493541.3061.2.camel@localhost.localdomain> <45E2D84C.7010809@linux-kernel.at> Message-ID: <1172508518.26442.8.camel@localhost.localdomain> On Mon, 2007-02-26 at 13:53 +0100, Oliver Falk wrote: > Am 2007-02-26 13:39, Dan Williams schrieb: > > On Mon, 2007-02-26 at 12:06 +0100, Oliver Falk wrote: > [ ... ] > > Yeah, using a real database is the way to go. > > Maybe someone should also have a look at the default ports and other > defaults... > > BUT... What's about plague? Will it live or will it die? I'm thinking > about koji... :-) I'm not entirely sure. I had thought the course of action was (a) opening up most of Brew, and (b) grafting in the bits of plague that were useful. Dan From anthony.seward at ieee.org Mon Feb 26 16:58:54 2007 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Mon, 26 Feb 2007 09:58:54 -0700 Subject: troubleshooting a build failure under mock In-Reply-To: <45E2FA1B.2080104@redhat.com> References: <1172271132.18940.55.camel@fleuret> <1172274195.25626.1.camel@fleuret> <45DF8339.2020201@karan.org> <1172278057.25626.7.camel@fleuret> <45E2FA1B.2080104@redhat.com> Message-ID: <1172509134.4391.13.camel@fleuret> On Mon, 2007-02-26 at 09:17 -0600, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anthony Joseph Seward wrote: > > On Sat, 2007-02-24 at 00:13 +0000, Karanbir Singh wrote: > >> Anthony Joseph Seward wrote: > >>> On Fri, 2007-02-23 at 17:42 -0600, Connie Sieh wrote: > >>>> On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: > >>>> > >>>>> My situation is this: my build system is running Scientific Linux 4.4 > >>>>> (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM > >>>>> when trying to compile a fortran file. The error issued is > >>>>> > >>>>> mkscrlib.f:381: internal compiler error: Illegal instruction > >>>> What rpm are you trying to build? > >>>> > >>> An in-house application for work. > >> if you post your .src.rpm online somewhere, someone might be able to > >> help debug the issue. > >> > > > > I don't think the .src.rpm is the issue. > > > > Again, using the same version of mock, the RPM will build when mock is > > hosted on an FC 6 system but not when running SL 4.4. > > > > Tony > > Hmmm. That sounds like the version of gfortran on SL4.4 has a problem. > What's the version of the fortran package (gcc4-gfortran or gcc-gfortran)? > > Also, if you run the build by hand on SL4.4, do you still get the > internal compiler error? If not, then there's something going on in the > environment set up by mock. If you do, then you have a toolchain issue > with gfortran and will need to take it up with your distro vendor :). Here are the build attempts: Target: SL 4.4 (gcc 3.4, g77) Native build: OK Mock build: FC 6 host: OK SL 4.4 host: OK Target: FC 6 (gcc 4.1, gfortran) Native build: OK Mock build: FC 6 host: OK SL 4.4 host: FAIL: internal compiler error using gfortran This leads me to believe that there is a problem with mock, but I have no idea where to look. Tony From Michael_E_Brown at dell.com Mon Feb 26 17:40:22 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 26 Feb 2007 11:40:22 -0600 Subject: troubleshooting a build failure under mock In-Reply-To: <1172509134.4391.13.camel@fleuret> References: <1172271132.18940.55.camel@fleuret> <1172274195.25626.1.camel@fleuret> <45DF8339.2020201@karan.org> <1172278057.25626.7.camel@fleuret> <45E2FA1B.2080104@redhat.com> <1172509134.4391.13.camel@fleuret> Message-ID: <20070226174021.GA16981@humbolt.us.dell.com> On Mon, Feb 26, 2007 at 09:58:54AM -0700, Anthony Joseph Seward wrote: > Here are the build attempts: > > Target: SL 4.4 > (gcc 3.4, g77) > Native build: OK > Mock build: > FC 6 host: OK > SL 4.4 host: OK > > Target: FC 6 > (gcc 4.1, gfortran) > Native build: OK > Mock build: > FC 6 host: OK > SL 4.4 host: FAIL: internal compiler error using gfortran > > This leads me to believe that there is a problem with mock, but I have > no idea where to look. I tend to doubt that it would be a mock problem. It is more likely a problem where the libc/other_random_component on SL4.4 is expecting a kernel feature that is present on SL4.4 but not FC6. I ran into something similar where (IIRC) < FC3 host could not build packages for >=FC6 target because the FC6 libc was expecting a certain kernel feature not enabled on FC3. This, afaict, is the only hole in the mock process: that we still rely on the host kernel. If the target build is relying on some kernel feature that can change from kernel to kernel, you are stuck. Something that cannot be avoided, though. You might instrument the build to get an strace of what is going on when you get the internal compiler error. -- Michael From anthony.seward at ieee.org Mon Feb 26 18:12:01 2007 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Mon, 26 Feb 2007 11:12:01 -0700 Subject: troubleshooting a build failure under mock In-Reply-To: <20070226174021.GA16981@humbolt.us.dell.com> References: <1172271132.18940.55.camel@fleuret> <1172274195.25626.1.camel@fleuret> <45DF8339.2020201@karan.org> <1172278057.25626.7.camel@fleuret> <45E2FA1B.2080104@redhat.com> <1172509134.4391.13.camel@fleuret> <20070226174021.GA16981@humbolt.us.dell.com> Message-ID: <1172513521.6391.1.camel@fleuret> On Mon, 2007-02-26 at 11:40 -0600, Michael E Brown wrote: > On Mon, Feb 26, 2007 at 09:58:54AM -0700, Anthony Joseph Seward wrote: > > Here are the build attempts: > > > > Target: SL 4.4 > > (gcc 3.4, g77) > > Native build: OK > > Mock build: > > FC 6 host: OK > > SL 4.4 host: OK > > > > Target: FC 6 > > (gcc 4.1, gfortran) > > Native build: OK > > Mock build: > > FC 6 host: OK > > SL 4.4 host: FAIL: internal compiler error using gfortran > > > > This leads me to believe that there is a problem with mock, but I have > > no idea where to look. > > I tend to doubt that it would be a mock problem. It is more likely a > problem where the libc/other_random_component on SL4.4 is expecting a > kernel feature that is present on SL4.4 but not FC6. I ran into > something similar where (IIRC) < FC3 host could not build packages for > >=FC6 target because the FC6 libc was expecting a certain kernel > feature not enabled on FC3. > > This, afaict, is the only hole in the mock process: that we still rely > on the host kernel. If the target build is relying on some kernel > feature that can change from kernel to kernel, you are stuck. > Something that cannot be avoided, though. > > You might instrument the build to get an strace of what is going on > when you get the internal compiler error. > -- > Michael > Thanks. I'll try that later this week. Tony