Deltarpm seems to be unable to generate correct rpms for deltarpms generated from noarch rpms. The uncompressed payload is correct, but the compressed xz payload is different.
To test, using Rawhide's deltarpm, try running "applydeltarpm -r anjuta-doc-2.27.3.0-3.fc12.noarch.rpm anjuta-doc-2.27.3.0-3.fc12_2.27.92.0-1.fc12.noarch.drpm test.rpm". You should end up with an md5 mismatch. If you rpm2cpio test.rpm, you'll find that the uncompressed cpio archive is identical to that of anjuta-doc-2.27.92.0-1.fc12.noarch.rpm.
As I understand it, noarch rpms are generated on PPC builders.
I suspect this problem is because of one of two reasons: 1. The version of xz on the PPC builders is a different version than that on the other builders? 2. xz generates different compressed files when run on different architectures
If it is #2, this is a major problem (at least for yum-presto) because the whole purpose of deltarpm is to regenerate the original (compressed) rpm, given an older version and a deltarpm. If we can't do that, the regenerated package won't pass the signature check and will be re-downloaded in full.
I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal).
Jonathan
On Sun, 2009-09-13 at 19:43 +0300, Jonathan Dieter wrote:
Deltarpm seems to be unable to generate correct rpms for deltarpms generated from noarch rpms. The uncompressed payload is correct, but the compressed xz payload is different.
To test, using Rawhide's deltarpm, try running "applydeltarpm -r anjuta-doc-2.27.3.0-3.fc12.noarch.rpm anjuta-doc-2.27.3.0-3.fc12_2.27.92.0-1.fc12.noarch.drpm test.rpm". You should end up with an md5 mismatch. If you rpm2cpio test.rpm, you'll find that the uncompressed cpio archive is identical to that of anjuta-doc-2.27.92.0-1.fc12.noarch.rpm.
As I understand it, noarch rpms are generated on PPC builders.
I suspect this problem is because of one of two reasons:
- The version of xz on the PPC builders is a different version than
that on the other builders? 2. xz generates different compressed files when run on different architectures
If it is #2, this is a major problem (at least for yum-presto) because the whole purpose of deltarpm is to regenerate the original (compressed) rpm, given an older version and a deltarpm. If we can't do that, the regenerated package won't pass the signature check and will be re-downloaded in full.
I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal).
It doesn't. [airlied@pegasus ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@pegasus ~]$ xz -z -c lm93_busted.o | md5sum 86dbb83fea5f4e2f77396b3f491a0cc1 -
[airlied@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 -
thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both.
Dave.
Jonathan
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Sep 14, 2009 at 1:35 PM, Dave Airlie airlied@redhat.com wrote:
On Sun, 2009-09-13 at 19:43 +0300, Jonathan Dieter wrote:
Deltarpm seems to be unable to generate correct rpms for deltarpms generated from noarch rpms. The uncompressed payload is correct, but the compressed xz payload is different.
To test, using Rawhide's deltarpm, try running "applydeltarpm -r anjuta-doc-2.27.3.0-3.fc12.noarch.rpm anjuta-doc-2.27.3.0-3.fc12_2.27.92.0-1.fc12.noarch.drpm test.rpm". You should end up with an md5 mismatch. If you rpm2cpio test.rpm, you'll find that the uncompressed cpio archive is identical to that of anjuta-doc-2.27.92.0-1.fc12.noarch.rpm.
As I understand it, noarch rpms are generated on PPC builders.
I suspect this problem is because of one of two reasons:
- The version of xz on the PPC builders is a different version than
that on the other builders? 2. xz generates different compressed files when run on different architectures
If it is #2, this is a major problem (at least for yum-presto) because the whole purpose of deltarpm is to regenerate the original (compressed) rpm, given an older version and a deltarpm. If we can't do that, the regenerated package won't pass the signature check and will be re-downloaded in full.
I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal).
It doesn't. [airlied@pegasus ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@pegasus ~]$ xz -z -c lm93_busted.o | md5sum 86dbb83fea5f4e2f77396b3f491a0cc1 -
[airlied@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 -
thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both.
Dave.
That really really sucks. Thanks for checking it for me.
Jonathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dave Airlie wrote:
On Sun, 2009-09-13 at 19:43 +0300, Jonathan Dieter wrote:
Deltarpm seems to be unable to generate correct rpms for
deltarpms
generated from noarch rpms. The uncompressed payload is
correct, but
the compressed xz payload is different.
To test, using Rawhide's deltarpm, try running "applydeltarpm
- -r
anjuta-doc-2.27.3.0-3.fc12.noarch.rpm anjuta-doc-2.27.3.0-3.fc12_2.27.92.0-1.fc12.noarch.drpm
test.rpm". You
should end up with an md5 mismatch. If you rpm2cpio
test.rpm, you'll
find that the uncompressed cpio archive is identical to that
of
anjuta-doc-2.27.92.0-1.fc12.noarch.rpm.
As I understand it, noarch rpms are generated on PPC
builders.
I suspect this problem is because of one of two reasons:
- The version of xz on the PPC builders is a different
version than
that on the other builders? 2. xz generates different compressed files when run on
different
architectures
If it is #2, this is a major problem (at least for yum-
presto) because
the whole purpose of deltarpm is to regenerate the original
(compressed)
rpm, given an older version and a deltarpm. If we can't do
that, the
regenerated package won't pass the signature check and will
be
re-downloaded in full.
I have access to i586 and x86_64 systems, but no PPC systems.
Could
someone either give me access to a PPC system or verify
themselves
whether xz generates different files on different
architectures (all
other things being equal).
It doesn't. [airlied@pegasus ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@pegasus ~]$ xz -z -c lm93_busted.o | md5sum 86dbb83fea5f4e2f77396b3f491a0cc1 -
[airlied@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 -
thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both.
Dave.
Jonathan
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
When I was playing around with xz after it came out, it detects the processor and memory available to it and defaults to a different compression quality based on that. Maybe if the compression quality and memory usage is set in the command line, you'd get the same output.
boeckb@bronto-burt % md5sum eeepc.pdf efbb35dcb6903fa4a8be91a717ae5c97 eeepc.pdf boeckb@bronto-burt % xz -c -f eeepc.pdf | md5sum b7d67d9b8b6a3ac00d9fcfab67ebd93b - boeckb@bronto-burt % xz -c -f -5 eeepc.pdf | md5sum 56a269074d015f6d46051a5ecf8d32da -
[data@cledwyn ~]$ xz -c -f eeepc.pdf | md5sum 5120f453bf577d58e3e94786e7bc5df1 - [data@cledwyn ~]$ xz -c -f -5 eeepc.pdf | md5sum 56a269074d015f6d46051a5ecf8d32da -
bronto-burt 3.0GHz x86_64 4GB RAM cledwyn 667MHz i686 192MB RAM
xz-4.999.8-0.8.beta.20090817git.fc11 for both
- --Ben
Ben Boeckel MathStuf@gmail.com writes:
When I was playing around with xz after it came out, it detects the processor and memory available to it and defaults to a different compression quality based on that. Maybe if the compression quality and memory usage is set in the command line, you'd get the same output.
By default xz sets its memory limit to 40% of the physical memory, but limits above about 90Mb don't change the output any more, and it's still different between x86 and ppc.
Andreas.
On Mon, 2009-09-14 at 09:25 -0400, Ben Boeckel wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dave Airlie wrote:
<snip>
[airlied@pegasus ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@pegasus ~]$ xz -z -c lm93_busted.o | md5sum 86dbb83fea5f4e2f77396b3f491a0cc1 -
[airlied@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airlied@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 -
thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both.
Dave.
When I was playing around with xz after it came out, it detects the processor and memory available to it and defaults to a different compression quality based on that. Maybe if the compression quality and memory usage is set in the command line, you'd get the same output.
boeckb@bronto-burt % md5sum eeepc.pdf efbb35dcb6903fa4a8be91a717ae5c97 eeepc.pdf boeckb@bronto-burt % xz -c -f eeepc.pdf | md5sum b7d67d9b8b6a3ac00d9fcfab67ebd93b - boeckb@bronto-burt % xz -c -f -5 eeepc.pdf | md5sum 56a269074d015f6d46051a5ecf8d32da -
[data@cledwyn ~]$ xz -c -f eeepc.pdf | md5sum 5120f453bf577d58e3e94786e7bc5df1 - [data@cledwyn ~]$ xz -c -f -5 eeepc.pdf | md5sum 56a269074d015f6d46051a5ecf8d32da -
bronto-burt 3.0GHz x86_64 4GB RAM cledwyn 667MHz i686 192MB RAM
xz-4.999.8-0.8.beta.20090817git.fc11 for both
- --Ben
Dave, if you're still around, do you mind running a check on both your machines using "xz -c -z -7"? IIRC, we do force the compression level in both rpm and deltarpm to be 7.
Thanks,
Jonathan
On Sun, 13 Sep 2009 19:43:44 +0300 Jonathan Dieter jdieter@gmail.com wrote:
...snip...
I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal).
Feel free to use my ppc32 test machine for any tests you need:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
Jonathan
kevin
On Mon, 2009-09-14 at 09:22 -0600, Kevin Fenzi wrote:
On Sun, 13 Sep 2009 19:43:44 +0300 Jonathan Dieter jdieter@gmail.com wrote:
...snip...
I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal).
Feel free to use my ppc32 test machine for any tests you need:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
Thanks, that's exactly what I'm looking for!!
Jonathan
Jonathan Dieter jdieter@gmail.com writes:
- xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian.
Andreas.
On Mon, 2009-09-14 at 18:15 +0200, Andreas Schwab wrote:
Jonathan Dieter jdieter@gmail.com writes:
- xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian.
Just looked at the code. How difficult would it be to change it so it uses the same hash function (or at least with the same result)?
Jonathan
Andreas Schwab (schwab@redhat.com) said:
- xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian.
Not having looked at the algorithm... *why*? Is it really that big of a difference?
Bill
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian.
Not having looked at the algorithm... *why*? Is it really that big of a difference?
rz/sz is a very old application. In the days of 6MHz CPUs it mattered. After that, "backwards compatibility" took precedence over portability.
On Mon, 2009-09-14 at 12:30 -0400, Bill Nottingham wrote:
Andreas Schwab (schwab@redhat.com) said:
- xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian.
Not having looked at the algorithm... *why*? Is it really that big of a difference?
I've been talking to the xz developer on IRC, and he says it's really not a huge difference. He sounds amenable to changing big-endian compression so it uses the little-endian CRC32 table.
He said you'd need a new single-dimension CRC32 table that would only be used when doing the big-endian build.
To be honest, though, this is all way over my head.
Jonathan
On Mon, 2009-09-14 at 12:30 -0400, Bill Nottingham wrote:
Andreas Schwab (schwab@redhat.com) said:
- xz generates different compressed files when run on different
architectures
The problem is that the encoder uses different hash functions depending on the endianess. The hash functions are defined in liblzma/lz/lz_encoder_hash.h, and are based on the values in lzma_crc32_table[0]. This table is different between big end little endian.
Not having looked at the algorithm... *why*? Is it really that big of a difference?
Ok, I've just had a conversation on IRC with Lasse Collin, the maintainer of xz. He's now planning on changing xz so it will produce the same output independent of endianess. He hasn't committed to any timeframe, though.
He did bring up some other very good points, though. Xz's compression output hasn't been set in sand, much less stone. The file format will stay the same, but the same command-line options may result in different compressed files.
We will probably need to have some kind of freeze for xz during a release (or at the very least, a test case added to the build process that fails when a generated xz file doesn't match a precreated one). Alternatives include a mass rebuild whenever xz's compression format changes and/or removing all deltarpms when xz's compression format changes.
Another alternative would be for rpm to have a private copy of the xz-lib code that stays fairly static. Not sure how that would go down.
So, to summarize, architecture-specific deltarpms are working perfectly in rawhide right now, and, if you're running a PPC machine, all deltarpms are working perfectly. Otherwise, noarch deltarpms will build into an incorrect rpm, and yum-presto will proceed to redownload the full rpm.
Jonathan
On Mon, 14 Sep 2009, Jonathan Dieter wrote:
Another alternative would be for rpm to have a private copy of the xz-lib code that stays fairly static. Not sure how that would go down.
Let us never speak of that again. Thanks.
So, to summarize, architecture-specific deltarpms are working perfectly in rawhide right now, and, if you're running a PPC machine, all deltarpms are working perfectly. Otherwise, noarch deltarpms will build into an incorrect rpm, and yum-presto will proceed to redownload the full rpm.
Boy, I'm so glad we decided to jump onto the xz ship.
-sv
On Mon, Sep 14, 2009 at 1:28 PM, Seth Vidal skvidal@fedoraproject.org wrote:
Boy, I'm so glad we decided to jump onto the xz ship.
I take it it's too late to back out and stick to bzip2 until the situation stabilizes? I take it whatever solution ends up in F-12 is likely to be the one used by RHEL 6 when it comes out next spring.
Between using more space on a distribution that's smaller than Fedora anyway, and having a rather uncertain compression tool...
On Tue, 2009-09-15 at 01:27 -0400, Michel Alexandre Salim wrote:
On Mon, Sep 14, 2009 at 1:28 PM, Seth Vidal skvidal@fedoraproject.org wrote:
Boy, I'm so glad we decided to jump onto the xz ship.
I take it it's too late to back out and stick to bzip2 until the situation stabilizes? I take it whatever solution ends up in F-12 is likely to be the one used by RHEL 6 when it comes out next spring.
Between using more space on a distribution that's smaller than Fedora anyway, and having a rather uncertain compression tool...
It's only 'uncertain' in the sense that it's not committed to always producing the same archive in future versions or on different architectures. As has been pointed out, this only has any relevance when it comes to delta RPMs, which are hardly a vital case (it's not catastrophic if they don't work). There's no suggestion that the tool is 'uncertain' in any more important sense (i.e. it doesn't actually compress / decompress properly). It isn't.
On Tue, Sep 15, 2009 at 10:38:32AM -0700, Adam Williamson wrote:
On Tue, 2009-09-15 at 01:27 -0400, Michel Alexandre Salim wrote:
On Mon, Sep 14, 2009 at 1:28 PM, Seth Vidal skvidal@fedoraproject.org wrote:
Boy, I'm so glad we decided to jump onto the xz ship.
I take it it's too late to back out and stick to bzip2 until the situation stabilizes? I take it whatever solution ends up in F-12 is likely to be the one used by RHEL 6 when it comes out next spring.
Between using more space on a distribution that's smaller than Fedora anyway, and having a rather uncertain compression tool...
It's only 'uncertain' in the sense that it's not committed to always producing the same archive in future versions or on different architectures. As has been pointed out, this only has any relevance when
Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway.
josh
Josh Boyer (jwboyer@gmail.com) said:
Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway.
I'm not sure how 'simple' that is in the koji configuration.
Bill
On Tue, Sep 15, 2009 at 01:56:55PM -0400, Bill Nottingham wrote:
Josh Boyer (jwboyer@gmail.com) said:
Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway.
I'm not sure how 'simple' that is in the koji configuration.
It will have to be done anyway, yes?
josh
On Mon, 2009-09-14 at 20:25 +0300, Jonathan Dieter wrote:
Ok, I've just had a conversation on IRC with Lasse Collin, the maintainer of xz. He's now planning on changing xz so it will produce the same output independent of endianess. He hasn't committed to any timeframe, though.
<snip>
Sorry, forgot to mention, another option would be to sign the *uncompressed* data in an rpm, so if the compressed data was different, it wouldn't matter.
This would be a lot easier from the maintenance side of things, but I'm not sure how feasible this big of a change in rpm would be.
Jonathan
On Mon, Sep 14, 2009 at 20:29:11 +0300, Jonathan Dieter jdieter@gmail.com wrote:
Sorry, forgot to mention, another option would be to sign the *uncompressed* data in an rpm, so if the compressed data was different, it wouldn't matter.
Uncompressing hostile data isn't always a good idea. It is preferable to sign the compressed data when that is what you are handing out.
On Mon, 2009-09-14 at 20:29 +0300, Jonathan Dieter wrote:
On Mon, 2009-09-14 at 20:25 +0300, Jonathan Dieter wrote:
Ok, I've just had a conversation on IRC with Lasse Collin, the maintainer of xz. He's now planning on changing xz so it will produce the same output independent of endianess. He hasn't committed to any timeframe, though.
<snip>
Sorry, forgot to mention, another option would be to sign the *uncompressed* data in an rpm, so if the compressed data was different, it wouldn't matter.
This would be a lot easier from the maintenance side of things, but I'm not sure how feasible this big of a change in rpm would be.
That doesn't work, before yum checks the signatures it checks the createrepo checksum ... which is a sha256 (or whatever) of the entire rpm¹. So deltarpm must produce exactly the same bits.
¹ Asking someone to change this to be the headers plus uncompressed data is likely to be unhealthy for you.
On Mon, 2009-09-14 at 15:43 -0400, James Antill wrote:
On Mon, 2009-09-14 at 20:29 +0300, Jonathan Dieter wrote:
On Mon, 2009-09-14 at 20:25 +0300, Jonathan Dieter wrote:
Ok, I've just had a conversation on IRC with Lasse Collin, the maintainer of xz. He's now planning on changing xz so it will produce the same output independent of endianess. He hasn't committed to any timeframe, though.
<snip>
Sorry, forgot to mention, another option would be to sign the *uncompressed* data in an rpm, so if the compressed data was different, it wouldn't matter.
This would be a lot easier from the maintenance side of things, but I'm not sure how feasible this big of a change in rpm would be.
That doesn't work, before yum checks the signatures it checks the createrepo checksum ... which is a sha256 (or whatever) of the entire rpm¹. So deltarpm must produce exactly the same bits.
¹ Asking someone to change this to be the headers plus uncompressed data is likely to be unhealthy for you.
So I'll just keep my mouth shut and not bring this suggestion up again. :) Along with the other one that I'm never supposed to speak of again.
Jonathan
Jonathan Dieter (jdieter@gmail.com) said:
He did bring up some other very good points, though. Xz's compression output hasn't been set in sand, much less stone. The file format will stay the same, but the same command-line options may result in different compressed files.
... in what way does he mean this? Obviously passing -1 ... -9 causes different output, much like it does in gzip/bzip2/etc.
Bill
On Mon, 2009-09-14 at 13:39 -0400, Bill Nottingham wrote:
Jonathan Dieter (jdieter@gmail.com) said:
He did bring up some other very good points, though. Xz's compression output hasn't been set in sand, much less stone. The file format will stay the same, but the same command-line options may result in different compressed files.
... in what way does he mean this? Obviously passing -1 ... -9 causes different output, much like it does in gzip/bzip2/etc.
He means that the file generated using -5 in the future may be different than the file generated using -5 now.
Jonathan
Jonathan Dieter (jdieter@gmail.com) said:
... in what way does he mean this? Obviously passing -1 ... -9 causes different output, much like it does in gzip/bzip2/etc.
He means that the file generated using -5 in the future may be different than the file generated using -5 now.
As long as that file is decompressible by older versions, then it's only a deltarpm issue.
Bill
On Mon, 2009-09-14 at 14:34 -0400, Bill Nottingham wrote:
Jonathan Dieter (jdieter@gmail.com) said:
... in what way does he mean this? Obviously passing -1 ... -9 causes different output, much like it does in gzip/bzip2/etc.
He means that the file generated using -5 in the future may be different than the file generated using -5 now.
As long as that file is decompressible by older versions, then it's only a deltarpm issue.
That's correct. All of this only affects deltarpm. Sorry if I wasn't clear on that.
Jonathan
Jonathan Dieter wrote:
So, to summarize, architecture-specific deltarpms are working perfectly in rawhide right now, and, if you're running a PPC machine, all deltarpms are working perfectly.
I don't know at what stage the deltarpms are being generated, but in Koji, noarch builds can be on any arch, there's no way to predict what arch Koji will be running them on.
Kevin Kofler
On Mon, 2009-09-14 at 22:25 +0200, Kevin Kofler wrote:
Jonathan Dieter wrote:
So, to summarize, architecture-specific deltarpms are working perfectly in rawhide right now, and, if you're running a PPC machine, all deltarpms are working perfectly.
I don't know at what stage the deltarpms are being generated, but in Koji, noarch builds can be on any arch, there's no way to predict what arch Koji will be running them on.
Sorry, my understanding was that they were all being generated on the PPC builders. Perhaps it's just that they're more likely to be built on those builders.
Jonathan
-
Adam Williamson -
Andreas Schwab -
Ben Boeckel -
Bill Nottingham -
Bruno Wolff III -
David Airlie -
James Antill -
John Reiser -
Jonathan Dieter -
Josh Boyer -
Kevin Fenzi -
Kevin Kofler -
Michel Alexandre Salim -
Ralf Ertzinger -
Seth Vidal