2:32 a.m.
Hello,
I recently started getting errors like:
17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open
(arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The
following noarch package built differently on different architectures:
rudiments-doc-1.0.1-1.fc26.noarch.rpm
rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
...when doing koji builds. Eg:
koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm
It's odd because the rpm in question is just docs. Nothing is built
per-se, some static files are just installed. I'd expect it to be the
same on all platforms.
It seems that it always fails when building for arm. I don't have an
arm platform available to test on though. Is there any way to get more
information about what's different about the rpm on the different platforms?
Thanks!
David Muse
david.muse(a)firstworks.com
2:49 a.m.
On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote:
Hello,
I recently started getting errors like:
17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open
(arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The
following noarch package built differently on different architectures:
rudiments-doc-1.0.1-1.fc26.noarch.rpm
rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
...when doing koji builds. Eg:
koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm
It's odd because the rpm in question is just docs. Nothing is built
per-se, some static files are just installed. I'd expect it to be the
same on all platforms.
It seems that it always fails when building for arm. I don't have an
arm platform available to test on though. Is there any way to get more
information about what's different about the rpm on the different platforms?
You can submit a separate scratch build for each target arch, then
download the built rpms and compare them all.
rudiments does something to generate its HTML documentation. It doesn't
use Doxygen, but whatever it does to the files may lead to different results
depending on what arch the build machine is.
10:12 a.m.
On 12/24/2016 3:49 AM, Michael Schwendt wrote:
On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote:
> Hello,
>
> I recently started getting errors like:
>
> 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open
> (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The
> following noarch package built differently on different architectures:
> rudiments-doc-1.0.1-1.fc26.noarch.rpm
> rpmdiff output was:
> error: cannot open Packages index using db5 - Permission denied (13)
> error: cannot open Packages database in /var/lib/rpm
> error: cannot open Packages database in /var/lib/rpm
>
> ...when doing koji builds. Eg:
>
> koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm
>
> It's odd because the rpm in question is just docs. Nothing is built
> per-se, some static files are just installed. I'd expect it to be the
> same on all platforms.
>
> It seems that it always fails when building for arm. I don't have an
> arm platform available to test on though. Is there any way to get more
> information about what's different about the rpm on the different platforms?
You can submit a separate scratch build for each target arch, then
download the built rpms and compare them all.
rudiments does something to generate its HTML documentation. It doesn't
use Doxygen, but whatever it does to the files may lead to different results
depending on what arch the build machine is.
I tried building for i686 and x86_64 and the noarch RPM did in fact turn
out different for each platform:
$ md5sum */*
ed58927ce25fa51e3f5e16d81cc195fa
i686/rudiments-doc-1.0.1-1.fc26.noarch.rpm
0789684c36ddcaadc4ee5216cfe7037e
x86_64/rudiments-doc-1.0.1-1.fc26.noarch.rpm
I tried installing them into separate roots using rpm --root and then
removing the var directories that rpm creates for its database. After
that, a diff -urN of the roots showed no differences. So, the files
that are installed by both RPMs appear to be identical.
However, a vbindiff of the two rpms shows plenty of differences. At
first there are really sparse, like maybe individual numbers are
different, but then there are some notable differences include the name
of the build machine, and what appear to be build options like: -O2 -g
-pipe ... -m64 -mtune=generic.cpio.xz.2.x86_64-redhat-linux-gnu, and
then the compressed data is all very different.
I would expect the name of the build machine and build options to be
very different between systems of different architectures. And I'd
think that the different strings would throw off the compressed data
further on in the file.
Am I doing something wrong that causes this info to be included in the
noarch RPM?
I tried fiddling with some parameters in my spec file. Eg. I don't have
any patches to apply, so I removed the -p1 from the %autosetup, and I
removed the Requires from the doc package, but those changes didn't make
any difference.
Is that info supposed to be included, and maybe there's just a bug in
the code that compares noarch rpms? Or something else? Can I safely
ignore the error?
2:06 p.m.
On 12/24/2016 11:12 AM, David Muse wrote:
On 12/24/2016 3:49 AM, Michael Schwendt wrote:
> On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote:
>
>> Hello,
>>
>> I recently started getting errors like:
>>
>> 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open
>> (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The
>> following noarch package built differently on different architectures:
>> rudiments-doc-1.0.1-1.fc26.noarch.rpm
>> rpmdiff output was:
>> error: cannot open Packages index using db5 - Permission denied (13)
>> error: cannot open Packages database in /var/lib/rpm
>> error: cannot open Packages database in /var/lib/rpm
>>
>> ...when doing koji builds. Eg:
>>
>> koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm
>>
>> It's odd because the rpm in question is just docs. Nothing is built
>> per-se, some static files are just installed. I'd expect it to be the
>> same on all platforms.
>>
>> It seems that it always fails when building for arm. I don't have an
>> arm platform available to test on though. Is there any way to get more
>> information about what's different about the rpm on the different
>> platforms?
>
> You can submit a separate scratch build for each target arch, then
> download the built rpms and compare them all.
>
> rudiments does something to generate its HTML documentation. It doesn't
> use Doxygen, but whatever it does to the files may lead to different
> results
> depending on what arch the build machine is.
I tried building for i686 and x86_64 and the noarch RPM did in fact turn
out different for each platform:
$ md5sum */*
ed58927ce25fa51e3f5e16d81cc195fa
i686/rudiments-doc-1.0.1-1.fc26.noarch.rpm
0789684c36ddcaadc4ee5216cfe7037e
x86_64/rudiments-doc-1.0.1-1.fc26.noarch.rpm
I tried installing them into separate roots using rpm --root and then
removing the var directories that rpm creates for its database. After
that, a diff -urN of the roots showed no differences. So, the files
that are installed by both RPMs appear to be identical.
However, a vbindiff of the two rpms shows plenty of differences. At
first there are really sparse, like maybe individual numbers are
different, but then there are some notable differences include the name
of the build machine, and what appear to be build options like: -O2 -g
-pipe ... -m64 -mtune=generic.cpio.xz.2.x86_64-redhat-linux-gnu, and
then the compressed data is all very different.
I would expect the name of the build machine and build options to be
very different between systems of different architectures. And I'd
think that the different strings would throw off the compressed data
further on in the file.
Am I doing something wrong that causes this info to be included in the
noarch RPM?
I tried fiddling with some parameters in my spec file. Eg. I don't have
any patches to apply, so I removed the -p1 from the %autosetup, and I
removed the Requires from the doc package, but those changes didn't make
any difference.
Is that info supposed to be included, and maybe there's just a bug in
the code that compares noarch rpms? Or something else? Can I safely
ignore the error?
Oh, I just realized that there's an rpmdiff tool. Well, I tried that,
and the only difference it shows is the timestamp for each file, which I
would expect to be different. An rpmdiff -iT of the two noarch rpms
returns nothing.
Strange.
2:19 p.m.
On 12/24/2016 3:06 PM, David Muse wrote:
On 12/24/2016 11:12 AM, David Muse wrote:
> On 12/24/2016 3:49 AM, Michael Schwendt wrote:
>> On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote:
>>
>>> Hello,
>>>
>>> I recently started getting errors like:
>>>
>>> 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open
>>> (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The
>>> following noarch package built differently on different architectures:
>>> rudiments-doc-1.0.1-1.fc26.noarch.rpm
>>> rpmdiff output was:
>>> error: cannot open Packages index using db5 - Permission denied (13)
>>> error: cannot open Packages database in /var/lib/rpm
>>> error: cannot open Packages database in /var/lib/rpm
>>>
>>> ...when doing koji builds. Eg:
>>>
>>> koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm
>>>
>>> It's odd because the rpm in question is just docs. Nothing is built
>>> per-se, some static files are just installed. I'd expect it to be the
>>> same on all platforms.
>>>
>>> It seems that it always fails when building for arm. I don't have an
>>> arm platform available to test on though. Is there any way to get more
>>> information about what's different about the rpm on the different
>>> platforms?
>>
>> You can submit a separate scratch build for each target arch, then
>> download the built rpms and compare them all.
>>
>> rudiments does something to generate its HTML documentation. It doesn't
>> use Doxygen, but whatever it does to the files may lead to different
>> results
>> depending on what arch the build machine is.
>
> I tried building for i686 and x86_64 and the noarch RPM did in fact turn
> out different for each platform:
>
> $ md5sum */*
> ed58927ce25fa51e3f5e16d81cc195fa
> i686/rudiments-doc-1.0.1-1.fc26.noarch.rpm
> 0789684c36ddcaadc4ee5216cfe7037e
> x86_64/rudiments-doc-1.0.1-1.fc26.noarch.rpm
>
> I tried installing them into separate roots using rpm --root and then
> removing the var directories that rpm creates for its database. After
> that, a diff -urN of the roots showed no differences. So, the files
> that are installed by both RPMs appear to be identical.
>
> However, a vbindiff of the two rpms shows plenty of differences. At
> first there are really sparse, like maybe individual numbers are
> different, but then there are some notable differences include the name
> of the build machine, and what appear to be build options like: -O2 -g
> -pipe ... -m64 -mtune=generic.cpio.xz.2.x86_64-redhat-linux-gnu, and
> then the compressed data is all very different.
>
> I would expect the name of the build machine and build options to be
> very different between systems of different architectures. And I'd
> think that the different strings would throw off the compressed data
> further on in the file.
>
> Am I doing something wrong that causes this info to be included in the
> noarch RPM?
>
> I tried fiddling with some parameters in my spec file. Eg. I don't have
> any patches to apply, so I removed the -p1 from the %autosetup, and I
> removed the Requires from the doc package, but those changes didn't make
> any difference.
>
> Is that info supposed to be included, and maybe there's just a bug in
> the code that compares noarch rpms? Or something else? Can I safely
> ignore the error?
Oh, I just realized that there's an rpmdiff tool. Well, I tried that,
and the only difference it shows is the timestamp for each file, which I
would expect to be different. An rpmdiff -iT of the two noarch rpms
returns nothing.
Strange.
Ha! Today the build succeeds with no errors. I guess something was
wrong with koji.
5:41 a.m.
On Sat, 24 Dec 2016 15:06:03 -0500, David Muse wrote:
Oh, I just realized that there's an rpmdiff tool.
Mentioned in your original mail. ;-)
Well, I tried that,
and the only difference it shows is the timestamp for each file, which I
would expect to be different. An rpmdiff -iT of the two noarch rpms
returns nothing.
That's "Architecture independent files":
https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Timestamps
8:33 p.m.
On 12/25/2016 6:41 AM, Michael Schwendt wrote:
On Sat, 24 Dec 2016 15:06:03 -0500, David Muse wrote:
> Oh, I just realized that there's an rpmdiff tool.
Mentioned in your original mail. ;-)
> Well, I tried that,
> and the only difference it shows is the timestamp for each file, which I
> would expect to be different. An rpmdiff -iT of the two noarch rpms
> returns nothing.
That's "Architecture independent files":
https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Timestamps
I eventually figured it out. The doc package had a Requires for the
main package, which is arch-specific.
At one point, I had commented out the Requires to see if that would fix
the problem, but I must have forgotten to regenerate the SRPM before
doing the next all-platforms build, and then not forgotten to regenerate
it before doing the platform-specific builds that I rpmdiff'ed. Or
something... Whatever I did wrong, the dependency on an arch-specific
package turned out to be the main problem.
I guess noarch packages shouldn't have any arch-specific dependencies.
Is that correct?
Dave
david.muse(a)firstworks.com
2:59 a.m.
On Sun, 25 Dec 2016 21:33:52 -0500, David Muse wrote:
I guess noarch packages shouldn't have any arch-specific
dependencies.
Is that correct?
Yes.
Noarch packages may be built on any machine of any arch, they may be
copied to any repository for any arch, and they are supposed to be usable
with any arch. Unless "ExcludeArch" is set.
6:09 p.m.
On Mon, Dec 26, 2016 at 09:59:54AM +0100, Michael Schwendt wrote:
On Sun, 25 Dec 2016 21:33:52 -0500, David Muse wrote:
> I guess noarch packages shouldn't have any arch-specific dependencies.
> Is that correct?
Yes.
Umm really? Can you explain exactly what's wrong with this?
I think the answer should be _no_ (ie. it's fine for noarch packages
to have arch-ful Requires). Of course the dependencies must be
available otherwise the noarch package cannot be installed.
A typical example would be a -doc subpackage (noarch, built once and
can be copied across architectures) documenting a C library (arch-ful,
and built on each architecture).
Unless you're talking about something different ...
Rich.
Noarch packages may be built on any machine of any arch, they may be
copied to any repository for any arch, and they are supposed to be usable
with any arch. Unless "ExcludeArch" is set.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
6:24 p.m.
On Fri, Dec 30, 2016 at 12:09:24AM +0000, Richard W.M. Jones wrote:
On Mon, Dec 26, 2016 at 09:59:54AM +0100, Michael Schwendt wrote:
> On Sun, 25 Dec 2016 21:33:52 -0500, David Muse wrote:
>
> > I guess noarch packages shouldn't have any arch-specific dependencies.
> > Is that correct?
>
> Yes.
Umm really? Can you explain exactly what's wrong with this?
I think the answer should be _no_ (ie. it's fine for noarch packages
to have arch-ful Requires). Of course the dependencies must be
available otherwise the noarch package cannot be installed.
OK, maybe you're talking about having %{_isa} in the spec file, ie:
%package doc
...
BuildArch: noarch
Requires: %{name}%{?_isa} = %{version}-%{release}
? That would make the dependency include "(x86-64)" (or whatever
arch the noarch package built on) and that would be wrong.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
5:14 a.m.
On Fri, 30 Dec 2016 00:24:03 +0000, Richard W.M. Jones wrote:
OK, maybe you're talking about having %{_isa} in the spec file,
ie:
%package doc
...
BuildArch: noarch
Requires: %{name}%{?_isa} = %{version}-%{release}
? That would make the dependency include "(x86-64)" (or whatever
arch the noarch package built on) and that would be wrong.
Which is an arch-specific dependency as mentioned in the guidelines
(in the base Requires section).
5:13 a.m.
On Fri, 30 Dec 2016 00:09:24 +0000, Richard W.M. Jones wrote:
On Mon, Dec 26, 2016 at 09:59:54AM +0100, Michael Schwendt wrote:
> On Sun, 25 Dec 2016 21:33:52 -0500, David Muse wrote:
>
> > I guess noarch packages shouldn't have any arch-specific dependencies.
> > Is that correct?
>
> Yes.
Umm really?
Of course.
Can you explain exactly what's wrong with this?
I think the answer should be _no_ (ie. it's fine for noarch packages
to have arch-ful Requires). Of course the dependencies must be
available otherwise the noarch package cannot be installed.
How would you define an "arch-specific dependency" in a noarch package?
Or to use you wording, how would you define an "arch-ful Requires" in
a noarch build?
If not doing it via %_isa, there would be only work-arounds, such as
including an arch identifier in the package name of a dependency and building
that dependency only for specific target architectures.
2671
days inactive
2677
days old
11 comments
3 participants
participants (3)
-
David Muse -
Michael Schwendt -
Richard W.M. Jones