Quick question for mock users
by Clark Williams
-----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-----
17 years, 2 months
pungi error
by Stephanos Manos
Hi
First sorry if posting in the wrong list.
Trying to respond to the QA call for test 1 i followed the instructions
posted to build using pungi inside mock (i am currently ruuning FC6)
using a locally mirrored repo.
When the building process finished with the ok message i did a sha1sum
check on the output with sha1sum -c SHA1SUM and all except the rescue
cd fail.
[root@ghost iso]# cat SHA1SUM
0cb6c915cd932fb3d096a15110d746b1267295e8 FD-6.90-i386-disc1.iso
e0c1b387eb0755726698e6da4e1a1bf5858fbd5a FD-6.90-i386-disc2.iso
2f2f18d366f62812746f9d779e7b4efa77c6fde6 FD-6.90-i386-disc3.iso
99d2733ed1ee1da6c0d78541b2672418d374fb63 FD-6.90-i386-DVD.iso
c2c4434fbf976f7a8f4673903d5e74ea9e79e040 FD-6.90-i386-rescuecd.iso
[root@ghost iso]# sha1sum *.iso
65e3ed52628e3f20cd0eb364f28e864f3afa445e FD-6.90-i386-disc1.iso
dbf3fa3f6cd09025ae89c45ed760bd77c21973d5 FD-6.90-i386-disc2.iso
87da6d5d6a20c1f10ad82b9702952f2240054657 FD-6.90-i386-disc3.iso
b66c7d8826aa52c1a3c5efab53c1f174cb230446 FD-6.90-i386-DVD.iso
c2c4434fbf976f7a8f4673903d5e74ea9e79e040 FD-6.90-i386-rescuecd.iso
inside mock
Executing /usr/sbin/mock-helper
chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser -
root -c "cd /srv/pungi/f7-test1/6.90/Desktop/i386/iso ; /usr/bin/sha1sum
*.iso"
b66c7d8826aa52c1a3c5efab53c1f174cb230446 FD-6.90-i386-DVD.iso
65e3ed52628e3f20cd0eb364f28e864f3afa445e FD-6.90-i386-disc1.iso
dbf3fa3f6cd09025ae89c45ed760bd77c21973d5 FD-6.90-i386-disc2.iso
87da6d5d6a20c1f10ad82b9702952f2240054657 FD-6.90-i386-disc3.iso
c2c4434fbf976f7a8f4673903d5e74ea9e79e040 FD-6.90-i386-rescuecd.iso
regardless the error output when booting with the dvd disk and running
the media check option it passes.
due to time restrictions and missing a spare HD to install i haven't
tested more thoroughly
is it a known problem/regression of pungi or a problem on my side?
should i open a BZ ticket?
Stephanos Manos
17 years, 2 months
Re: pungi ignores a lot of RPMs when building CD image
by Earl
-----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
<mythtv.bohmer(a)gmail.com> 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: <os-dir>/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 <mythtv.bohmer(a)gmail.com>:
>> 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 <jkeating(a)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
>> >
>> >
>>
>
>--
>Fedora-buildsys-list mailing list
>Fedora-buildsys-list(a)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-----
17 years, 2 months
Re: pungi ignores a lot of RPMs when building CD image
by Jeroen Janssen
On 2/1/07, Paul Nasrat <pnasrat(a)redhat.com> 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
17 years, 2 months
