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
Re: ActionNotAllowed: admin permission required
Jay Greguske wrote: None of your users in the users table have a usertype, and for someone to be an admin, that field must be set to 1 (the same id for admin found in the permissions table). Try setting that manually in the database and see if things work for you then. Please disregard this advice. It is incorrect. There are currently three usertypes defined in koji: NORMAL, HOST, and GROUP (values 0, 1, and 2 respectively). /None/ of them have anything to do with being an admin. Most users should have type 0 (normal). The users corresponding to build hosts should have type 1 (host) and groups should have type 2. In the normal course of operation you should never have to change these manually in the db. Being an admin in Koji means having the admin permission. This is determined by user_perms table. docs/schema.sql has an example near the end for adding an initial admin user. Once you create this first user, all other users should be created using the koji command line utility. Use 'koji help --admin |grep user' to get a list of relevant subcommands. -- 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
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? I think a better approach is to create the original SRPM with MD5 checksums in the first place if it's going to be passed to mock with a pre-F11 target. So for instance I have this in my ~/.rpmmacros for the account I create my SRPMs in: # Use MD5 hashes on non mock-built packages for cross-release # compatibility %_source_filedigest_algorithm 0 %_binary_filedigest_algorithm 0 Paul. -- 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
