Which RPM does mergerepo prefer?
Hi, I have attached an external repo to a build tag (Just trying out some hand-built RPMs). Now, if an RPM is present *both* in the build tag as well as the external repo, which one does mergerepos pick? Is the decision based on version comparison (the greater version wins), or does the one in the build tag always get preference over the external repo (irrespective of the version)? If it is the latter, how do I tell mergerepos to prefer external repo over the build tag? (or atleast use version comparisons rather than preferring build tag) Jitesh -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Which RPM does mergerepo prefer?
Jitesh Shah wrote: Hi, I have attached an external repo to a build tag (Just trying out some hand-built RPMs). Now, if an RPM is present *both* in the build tag as well as the external repo, which one does mergerepos pick? It picks the rpm in the build tag (the local rpm). Is the decision based on version comparison (the greater version wins), or does the one in the build tag always get preference over the external repo (irrespective of the version)? The one in the build tag always wins. This is consistent with normal Koji tag inheritance, which is a depth-first, first-match-wins search. Koji never compares NVRs. If it is the latter, how do I tell mergerepos to prefer external repo over the build tag? (or atleast use version comparisons rather than preferring build tag) If you want to use the version from the external repo, untag any builds of that package from the local tag and let the external repo version be picked up as the first match. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
mock and sha256 rpms
If you use mock for building, then you may be in the position of having the main system rpm use sha256 checksums (e.g. on F11) but create chroots that contain an older rpm that does not. If you create a source rpm using the newer rpm and pass it to mock to build in a chroot with an older rpm, you will get an error like the following: DEBUG util.py:256: error: unpacking of archive failed on file /builddir/build/SOURCES/INIT.2008-02-02.tgz;4a1e5c21: cpio: MD5 sum mismatch DEBUG util.py:319: Child returncode was: 1 I think the simplest way to work around this is to have mock pass --nomd5 to rpm when installing the srpm in the chroot. Of course, this is dropping an integrity check, so could possibly add a check outside the chroot to verify this data. Granted, I'm not sure what the best way to do that is. Thoughts? Concerns? -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock and sha256 rpms
On Thu, 28 May 2009, Mike McLean wrote: If you use mock for building, then you may be in the position of having the main system rpm use sha256 checksums (e.g. on F11) but create chroots that contain an older rpm that does not. If you create a source rpm using the newer rpm and pass it to mock to build in a chroot with an older rpm, you will get an error like the following: DEBUG util.py:256: error: unpacking of archive failed on file /builddir/build/SOURCES/INIT.2008-02-02.tgz;4a1e5c21: cpio: MD5 sum mismatch DEBUG util.py:319: Child returncode was: 1 I think the simplest way to work around this is to have mock pass --nomd5 to rpm when installing the srpm in the chroot. Of course, this is dropping an integrity check, so could possibly add a check outside the chroot to verify this data. Granted, I'm not sure what the best way to do that is. Thoughts? Concerns? disable sha256 checksums? %_source_filedigest_algorithm 8 %_binary_filedigest_algorithm 8 -sv -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock and sha256 rpms
On Thursday 28 May 2009 10:49:57 am Mike McLean wrote: If you use mock for building, then you may be in the position of having the main system rpm use sha256 checksums (e.g. on F11) but create chroots that contain an older rpm that does not. If you create a source rpm using the newer rpm and pass it to mock to build in a chroot with an older rpm, you will get an error like the following: DEBUG util.py:256: error: unpacking of archive failed on file /builddir/build/SOURCES/INIT.2008-02-02.tgz;4a1e5c21: cpio: MD5 sum mismatch DEBUG util.py:319: Child returncode was: 1 I think the simplest way to work around this is to have mock pass --nomd5 to rpm when installing the srpm in the chroot. Of course, this is dropping an integrity check, so could possibly add a check outside the chroot to verify this data. Granted, I'm not sure what the best way to do that is. Thoughts? Concerns? -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Makefile.common has # to make srpms on F-11 and newer for older releases use old hashes # F-10's rpm supports both styles F-9 is the only current release # outside of rhel that needs old hasnes ifeq ($(DISTVAR),rhel) RPM_DEFINES := $(RPM_DEFINES) \ --define _source_filedigest_algorithm md5 \ --define _binary_filedigest_algorithm md5 endif ifeq ($(DISTVAL),9) RPM_DEFINES := $(RPM_DEFINES) \ --define _source_filedigest_algorithm md5 \ --define _binary_filedigest_algorithm md5 endif this will allow you to create useable srpms with make srpm for scratch building Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Makefile.common problem
This ticket was filed in infrastructure's trac. I've been told this is
actually where it should go::
https://fedorahosted.org/fedora-infrastructure/ticket/1412
Makefile.common currently causes build failures when doing make local
with a package containing a noarch subpackage.
The problem is on line 38: LOCALARCH := $(if $(shell grep -i
'^BuildArch:.*noarch' $(SPECFILE)), noarch, $(shell uname -m))
First, it cannot grep noarch in this way now, second, there should be
$(shell rpm --eval %{_arch}) instead of $(shell uname -m).
As discussed on #fedora-devel with Toshio and Adam Jackson, this should
be now probably changed to plain: LOCALARCH := $(shell rpm --eval %{_arch})
For noarch only packages this means they'll be built in a $arch
directory, but that's not an issue IMHO.
...it would be nice to fix this soon, I indeed spent some time looking
around what happens to find out why my noarch subpackages fail locally
and build fine in Koji -- would like to spare this time for others;)
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Makefile.common problem
Toshio Kuratomi (a.bad...@gmail.com) said:
As discussed on #fedora-devel with Toshio and Adam Jackson, this should
be now probably changed to plain: LOCALARCH := $(shell rpm --eval
%{_arch})
For noarch only packages this means they'll be built in a $arch
directory, but that's not an issue IMHO.
...it would be nice to fix this soon, I indeed spent some time looking
around what happens to find out why my noarch subpackages fail locally
and build fine in Koji -- would like to spare this time for others;)
Seems reasonable - applied.
Bill
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
