4:52 a.m.
As http://fedoraproject.org/wiki/Features/RPM4.10 got accepted in
yesterday's FESCo meeting, here come the bits.
For details see http://rpm.org/wiki/Releases/4.10.0, but the bottom line
is that for business-as-usual operations you shouldn't really notice
much anything at all. Well, apart from cleanup-erasure progress being
visible if you use rpm cli instead of yum to upgrade packages.
Just watch out for anomalies and report them ... as usual.
As there's a soname bump involved, the following packages will need a
rebuild. It should be just a straightforward bump+rebuild for all these.
If a build that succeeds with rpm-4.9.x fails with rpm-4.10.x then its
likely a bug in rpm (or then the software is playing with some very dark
corners of librpm):
abrt-team abrt
abrt-team libreport
anaconda-maint anaconda
athimm apt
ensc libextractor
fche systemtap
ivaxer opensips
jcollie asterisk
jdieter deltarpm
jsafrane net-snmp
kklic libsolv
lkundrak ovaldi
mlichvar rpmreaper
mmaslano perl-RPM2
mprivozn libvirt-snmp
peter openser
ppisar perl-RPM-VersionCompare
pvrabec openscap
pvrabec sectool
rhughes PackageKit
rhughes zif
rmeggins 389-ds-base
rohara foghorn
sharkcz openhpi-subagent
- Panu -
6:08 a.m.
On 03/20/2012 11:52 AM, Panu Matilainen wrote:
As http://fedoraproject.org/wiki/Features/RPM4.10 got accepted in
yesterday's FESCo meeting, here come the bits.
For details see http://rpm.org/wiki/Releases/4.10.0, but the bottom line
is that for business-as-usual operations you shouldn't really notice
much anything at all. Well, apart from cleanup-erasure progress being
visible if you use rpm cli instead of yum to upgrade packages.
Just watch out for anomalies and report them ... as usual.
So... first hickup that broke koji: the buildroot now requires deltarpm
which needs rebuilding due to to the soname bump before we can proceed.
I dont recall this being an issue before but I guess that's called
progress :)
I've untagged the alpha from rawhide until we get that sorted out.
- Panu -
6:49 a.m.
On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote:
So... first hickup that broke koji: the buildroot now requires
deltarpm
which needs rebuilding due to to the soname bump before we can proceed.
I dont recall this being an issue before but I guess that's called
progress :)
Why does the buildroot require deltarpm? Are deltarpms now being
generated during builds instead of at compose time?
Jonathan
9:15 a.m.
On 03/20/2012 01:49 PM, Jonathan Dieter wrote:
On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote:
> So... first hickup that broke koji: the buildroot now requires deltarpm
> which needs rebuilding due to to the soname bump before we can proceed.
> I dont recall this being an issue before but I guess that's called
> progress :)
Why does the buildroot require deltarpm? Are deltarpms now being
generated during builds instead of at compose time?
No clue. It appears to get dragged in via 'yum groupinstall srpm-build'
and it means chain-build doesn't work either.
- Panu -
10:10 a.m.
On Tue, 2012-03-20 at 16:15 +0200, Panu Matilainen wrote:
On 03/20/2012 01:49 PM, Jonathan Dieter wrote:
> On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote:
>> So... first hickup that broke koji: the buildroot now requires deltarpm
>> which needs rebuilding due to to the soname bump before we can proceed.
>> I dont recall this being an issue before but I guess that's called
>> progress :)
>
> Why does the buildroot require deltarpm? Are deltarpms now being
> generated during builds instead of at compose time?
No clue. It appears to get dragged in via 'yum groupinstall srpm-build'
and it means chain-build doesn't work either.
Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately
I don't have a Rawhide tree here to test), fedpkg is in the srpm-build
group, and it requires pyrpkg which requires mock which requires
createrepo which requires deltarpm.
I don't know how easily we can clean up these dependencies. Do we need
mock in the buildroot? If not, is it possible to split pyrpkg's mock
functionality into a subpackage?
Jonathan
10:35 a.m.
On 03/20/2012 05:10 PM, Jonathan Dieter wrote:
On Tue, 2012-03-20 at 16:15 +0200, Panu Matilainen wrote:
> On 03/20/2012 01:49 PM, Jonathan Dieter wrote:
>> On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote:
>>> So... first hickup that broke koji: the buildroot now requires deltarpm
>>> which needs rebuilding due to to the soname bump before we can proceed.
>>> I dont recall this being an issue before but I guess that's called
>>> progress :)
>>
>> Why does the buildroot require deltarpm? Are deltarpms now being
>> generated during builds instead of at compose time?
>
> No clue. It appears to get dragged in via 'yum groupinstall srpm-build'
> and it means chain-build doesn't work either.
Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately
I don't have a Rawhide tree here to test), fedpkg is in the srpm-build
group, and it requires pyrpkg which requires mock which requires
createrepo which requires deltarpm.
Urks, that's quite a tangle. Thanks for hunting it down.
I don't know how easily we can clean up these dependencies. Do
we need
mock in the buildroot? If not, is it possible to split pyrpkg's mock
functionality into a subpackage?
We'll need somebody more familiar with the buildsys than me to answer
that... For now it would suffice to be able to axe the deltarpm
dependency out temporarily to allow it to be rebuilt, one way or the other.
- Panu -
12:37 p.m.
On 3/20/12 8:10 AM, Jonathan Dieter wrote:
Ok, in F16 (and I'm assuming this is also true in Rawhide;
unfortunately
I don't have a Rawhide tree here to test), fedpkg is in the srpm-build
group, and it requires pyrpkg which requires mock which requires
createrepo which requires deltarpm.
I don't know how easily we can clean up these dependencies. Do we need
mock in the buildroot? If not, is it possible to split pyrpkg's mock
functionality into a subpackage?
We're working on a 'fedpkg-simple' which just provides the functionality
needed to construct the srpm and nothing else, which will greatly reduce
the deps pulled in. I'm not sure what the ETA is on this.
Dennis?
--
Jesse Keating
Fedora -- Freedom² is a feature!
4:04 a.m.
On 03/20/2012 07:37 PM, Jesse Keating wrote:
On 3/20/12 8:10 AM, Jonathan Dieter wrote:
> Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately
> I don't have a Rawhide tree here to test), fedpkg is in the srpm-build
> group, and it requires pyrpkg which requires mock which requires
> createrepo which requires deltarpm.
>
> I don't know how easily we can clean up these dependencies. Do we need
> mock in the buildroot? If not, is it possible to split pyrpkg's mock
> functionality into a subpackage?
We're working on a 'fedpkg-simple' which just provides the functionality
needed to construct the srpm and nothing else, which will greatly reduce
the deps pulled in. I'm not sure what the ETA is on this.
Sounds good, but doesn't help me get the new rpm in right now. I'm
starting to consider going dirty and just adding fake library provides
for one build of rpm to get deltarpm "bootstrapped", as I assume
createrepo (and thus deltarpm) doesn't actually get invoked in the srpm
creation phase, right?
- Panu -
6:03 a.m.
On Wed, 2012-03-21 at 11:04 +0200, Panu Matilainen wrote:
I'm starting to consider going dirty and just adding fake library
provides
for one build of rpm to get deltarpm "bootstrapped", as I assume
createrepo (and thus deltarpm) doesn't actually get invoked in the srpm
creation phase, right?
That sounds right to me.
Jonathan
6:28 a.m.
On 03/21/2012 01:03 PM, Jonathan Dieter wrote:
On Wed, 2012-03-21 at 11:04 +0200, Panu Matilainen wrote:
> I'm starting to consider going dirty and just adding fake library provides
> for one build of rpm to get deltarpm "bootstrapped", as I assume
> createrepo (and thus deltarpm) doesn't actually get invoked in the srpm
> creation phase, right?
That sounds right to me.
That did allow it to get past the srpm creation step but there's
something very wrong with the resulting src.rpm. Whether that's some
strange rpm bug that only occurs inside mock/koji or a side-effect of
something getting unhappy about the faked provides... so tagged out once
again while I investigate.
If you're seeing bizarre intermittent build failures on koji today, it's
probably my fault. Apologies for the inconvenience :-/
- Panu -
12:51 p.m.
On 3/21/12 2:04 AM, Panu Matilainen wrote:
as I assume createrepo (and thus deltarpm) doesn't actually get
invoked
in the srpm creation phase, right?
That's correct. fedpkg is used to do the "fedpkg sources" call which
downloads the tarball from lookaside. After that it is out of the
picture, we rely on pure rpmbuild to build up the srpm.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
2:18 p.m.
On 03/21/2012 07:51 PM, Jesse Keating wrote:
On 3/21/12 2:04 AM, Panu Matilainen wrote:
> as I assume createrepo (and thus deltarpm) doesn't actually get invoked
> in the srpm creation phase, right?
That's correct. fedpkg is used to do the "fedpkg sources" call which
downloads the tarball from lookaside. After that it is out of the
picture, we rely on pure rpmbuild to build up the srpm.
Ok, thanks for confirming. The fake provide hackery should allow us to
get past that hurdle for the time being, once I figure out what the heck
is going on with the initial src.rpm creation: the payload appears to
only get cpio headers and the actual content is missing. I haven't been
able to reproduce that outside of koji, which makes debugging it a tad
exotic.
If fedpkg is only used for the source retrieval in the buildroot, we
should be able to get rid of it completely: rpm 4.10 can download
missing sources (from a look-aside style place or directly from upstream
location), what's missing is a mechanism to validate checksums of the
downloaded content (and that's why it's disabled in 4.10). So unless
there are other (future) plans for fedpkg use in buildroots, perhaps we
should burn some cycles into getting the checksumming mechanism into
rpmbuild rather than a slimmer version of fedpkg.
- Panu -
4440
days inactive
4441
days old
11 comments
4 participants
participants (4)
-
Jesse Keating -
Jesse Keating -
Jonathan Dieter -
Panu Matilainen