1:42 p.m.
In just a few minutes, I will begin the scripted rebuild of every Fedora
package in rawhide (dist-f11). See
https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild for details.
Most importantly, if you as a maintainer wish to build your own package
for this rebuild instead of having the script do it, follow
https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild#How_do_I_opt_out_of...
The script will be doing things one package at a time, so even though
the script will be starting in a few minutes (and it'll be working
alphanumerically in descending order), you still have a window to
opt-out of the build before the script gets to your package.
I will be announcing the progress of the rebuilds over the next few
days. It is important to note that the results of the rebuilds will not
be showing up in rawhide (and koji buildroots) immediately. Instead
they will be contained on the side until the script is finished building
things, and they will be tagged into rawhide (dist-f11) en masse.
If your build was started after 2009-02-23 18:31:07 UTC, the script will
not touch your package, as that is after all the proper parts were in
place for this rebuild.
Let the games begin!
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
3:02 p.m.
On Mon, 2009-02-23 at 11:42 -0800, Jesse Keating wrote:
It is important to note that the results of the rebuilds will not
be showing up in rawhide (and koji buildroots) immediately. Instead
they will be contained on the side until the script is finished building
things, and they will be tagged into rawhide (dist-f11) en masse.
The best made plans...
Turns out there was an error in my script and the first few packages
rebuilt did actually make it into dist-f11. I have corrected the script
and the rest of the builds are headed toward dist-f11-rebuild. Sorry
for any confusion this causes.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
5:12 a.m.
On Monday 23 February 2009 22:02:54 Jesse Keating wrote:
On Mon, 2009-02-23 at 11:42 -0800, Jesse Keating wrote:
> It is important to note that the results of the rebuilds will not
> be showing up in rawhide (and koji buildroots) immediately. Instead
> they will be contained on the side until the script is finished building
> things, and they will be tagged into rawhide (dist-f11) en masse.
The best made plans...
Turns out there was an error in my script and the first few packages
rebuilt did actually make it into dist-f11. I have corrected the script
and the rest of the builds are headed toward dist-f11-rebuild. Sorry
for any confusion this causes.
What about builds that are not tagued correctly? Does somebody need to retag
the packages? Will it be done automatically?
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
11:15 a.m.
On Tue, 2009-02-24 at 12:12 +0100, Laurent Rineau wrote:
What about builds that are not tagued correctly? Does somebody need
to retag
the packages? Will it be done automatically?
Pardon? A few of the first builds got into dist-f11, which is the
eventual target for all of these builds. The fact that they got there
early is no real issue, as they aren't causing broken deps during the
builds. They can be left as is.
The items in dist-f11-rebuild will be tagged over intelligently once the
rebuilds are done.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:26 a.m.
Aloas,
On Mo Februar 23 2009, Jesse Keating wrote:
In just a few minutes, I will begin the scripted rebuild of every
Fedora
package in rawhide (dist-f11). See
https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild for details.
the rebuild of one of my packages failed, can I now just debug it and start a
new build when I got it to build? Strangely it did not fail in the gcc 4.4
test mass rebuild or the recent rebuild by Matt Domsch.
Regards,
Till
3:35 a.m.
On Mo Februar 23 2009, Jesse Keating wrote:
> In just a few minutes, I will begin the scripted rebuild of every Fedora
> package in rawhide (dist-f11). See
> https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild for details.
the rebuild of one of my packages failed, can I now just debug it and start a
new build when I got it to build? Strangely it did not fail in the gcc 4.4
test mass rebuild or the recent rebuild by Matt Domsch.
The rebuild of one of my packages (botan) also failed, but with this
error in the root.log:
...
DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:256: rpmlib(FileDigests) is needed by popt-1.13-5.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by bash-4.0-0.5.rc1.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by
ethtool-6-3.20090115git.fc11.ppc
DEBUG util.py:256: (1, ['Please report this error in bugzilla'])
...
Seems like something more general is not working, maybe its build
requirements need to be rebuilt first?
--
Thomas Moschny <thomas.moschny(a)gmail.com>
4:06 a.m.
Thomas Moschny wrote, at 02/24/2009 06:35 PM +9:00:
> On Mo Februar 23 2009, Jesse Keating wrote:
>> In just a few minutes, I will begin the scripted rebuild of every Fedora
>> package in rawhide (dist-f11). See
>> https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild for details.
> the rebuild of one of my packages failed, can I now just debug it and start a
> new build when I got it to build? Strangely it did not fail in the gcc 4.4
> test mass rebuild or the recent rebuild by Matt Domsch.
The rebuild of one of my packages (botan) also failed, but with this
error in the root.log:
...
DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:256: rpmlib(FileDigests) is needed by popt-1.13-5.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by bash-4.0-0.5.rc1.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by
ethtool-6-3.20090115git.fc11.ppc
DEBUG util.py:256: (1, ['Please report this error in bugzilla'])
...
Seems like something more general is not working, maybe its build
requirements need to be rebuilt first?
Seems good now:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1155486
Mamoru
11:17 a.m.
On Tue, 2009-02-24 at 10:35 +0100, Thomas Moschny wrote:
The rebuild of one of my packages (botan) also failed, but with this
error in the root.log:
...
DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:256: rpmlib(FileDigests) is needed by
popt-1.13-5.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by
bash-4.0-0.5.rc1.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by
ethtool-6-3.20090115git.fc11.ppc
DEBUG util.py:256: (1, ['Please report this error in bugzilla'])
...
Seems like something more general is not working, maybe its build
requirements need to be rebuilt first?
There was a short lived config error on one of the new builders we
brought online last night. I do believe I've resubmitted all the tasks
that failed for these reasons.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:32 p.m.
Jesse Keating wrote:
On Tue, 2009-02-24 at 10:35 +0100, Thomas Moschny wrote:
> The rebuild of one of my packages (botan) also failed, but with this
> error in the root.log:
>
> ...
> DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
> DEBUG util.py:256: rpmlib(FileDigests) is needed by
> popt-1.13-5.fc11.ppc
> DEBUG util.py:256: rpmlib(FileDigests) is needed by
> bash-4.0-0.5.rc1.fc11.ppc
> DEBUG util.py:256: rpmlib(FileDigests) is needed by
> ethtool-6-3.20090115git.fc11.ppc
> DEBUG util.py:256: (1, ['Please report this error in bugzilla'])
> ...
>
> Seems like something more general is not working, maybe its build
> requirements need to be rebuilt first?
There was a short lived config error on one of the new builders we
brought online last night. I do believe I've resubmitted all the tasks
that failed for these reasons.
Can you say what it is? I'm seeing this on my centos 5.2 mock host.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
6:20 p.m.
On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
Can you say what it is? I'm seeing this on my centos 5.2 mock
host.
The rpm version on the host has to be able to support the larger file
checksums. We have a special rpm built for our EL5 builders that
provides this. I don't know if that rpm build is hosted anywhere out in
the open, I do believe Mitr built it for us.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:43 p.m.
Jesse Keating <jkeating(a)redhat.com> writes:
On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
The rpm version on the host has to be able to support the larger
file
checksums. We have a special rpm built for our EL5 builders that
provides this. I don't know if that rpm build is hosted anywhere out in
the open, I do believe Mitr built it for us.
It's going to be quite a large problem if people can no longer use mock
on an older system to test rawhide builds. What is the plan to address
this?
regards, tom lane
7:16 p.m.
Tom Lane píše v Út 24. 02. 2009 v 19:43 -0500:
Jesse Keating <jkeating(a)redhat.com> writes:
> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
> The rpm version on the host has to be able to support the larger file
> checksums. We have a special rpm built for our EL5 builders that
> provides this. I don't know if that rpm build is hosted anywhere out in
> the open, I do believe Mitr built it for us.
It's going to be quite a large problem if people can no longer use mock
on an older system to test rawhide builds. What is the plan to address
this?
An updated rpm was already submitted as an update to Fedora 10. The
feature won't be backported to older rpm versions.
(You can use the rpm I prepared for the koji builders, at
http://people.redhat.com/mitr/sha256-rpm , but there are some
incompatible behavior changes and using this packae will break some
dependencies because rpm-libs sonames have changed.)
Mirek
10:40 a.m.
Miloslav Trmač wrote:
Tom Lane píše v Út 24. 02. 2009 v 19:43 -0500:
> Jesse Keating <jkeating(a)redhat.com> writes:
>> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>>> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
>> The rpm version on the host has to be able to support the larger file
>> checksums. We have a special rpm built for our EL5 builders that
>> provides this. I don't know if that rpm build is hosted anywhere out in
>> the open, I do believe Mitr built it for us.
> It's going to be quite a large problem if people can no longer use mock
> on an older system to test rawhide builds. What is the plan to address
> this?
An updated rpm was already submitted as an update to Fedora 10. The
feature won't be backported to older rpm versions.
So it's safe to say that mock builds for Rawhide are forever broken on F-9?
That's unfortunate.
--Wart
7:22 p.m.
On Tue, 2009-02-24 at 19:43 -0500, Tom Lane wrote:
Jesse Keating <jkeating(a)redhat.com> writes:
> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
> The rpm version on the host has to be able to support the larger file
> checksums. We have a special rpm built for our EL5 builders that
> provides this. I don't know if that rpm build is hosted anywhere out in
> the open, I do believe Mitr built it for us.
It's going to be quite a large problem if people can no longer use mock
on an older system to test rawhide builds. What is the plan to address
this?
regards, tom lane
You could try to convince Red Hat Product Management into back porting
the necessary rpm bits into RHEL5's rpm. I'm told that the changes
aren't exactly contained for backporting without risk. However we can't
let that hold back Fedora development, or else we'd never be able to
change anything.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:18 a.m.
On Tue, 24 Feb 2009, Tom Lane wrote:
Jesse Keating <jkeating(a)redhat.com> writes:
> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
> The rpm version on the host has to be able to support the larger file
> checksums. We have a special rpm built for our EL5 builders that
> provides this. I don't know if that rpm build is hosted anywhere out in
> the open, I do believe Mitr built it for us.
It's going to be quite a large problem if people can no longer use mock
on an older system to test rawhide builds. What is the plan to address
this?
The strong file hashes are just the first messenger that got through, and
the message it brings is that it's time for people to wake up from the
sleep of last hundred, err, ten years and realize that rpm can and does
change. And yes it means older rpm versions can't always install packages
built by a newer rpm.
- Panu -
9:46 a.m.
>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
PM> The strong file hashes are just the first messenger that got
PM> through, and the message it brings is that it's time for people to
PM> wake up from the sleep of last hundred, err, ten years and realize
PM> that rpm can and does change.
I think we realize this. rpm change is generally a good thing.
However, it would still be nice to have some way to do this. I
recognize that it may not be completely safe to push rpm updates to
supported Fedora releases, but it would be nice to have some basic
ideas of how we might go about getting a newer rpm onto, say, an F-9
box assuming that we're willing to deal with any weirdness that
results.
I will eventually get my builders updated to F-10 but for now it would
be really nice to still be able to review packages properly. I'm
willing to do the hacking. Is it possibly as simple as just
rebuilding the F-10 version of rpm?
- J<
10:44 a.m.
On Wed, Feb 25, 2009 at 09:46:27AM -0600, Jason L Tibbitts III wrote:
>>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
PM> The strong file hashes are just the first messenger that got
PM> through, and the message it brings is that it's time for people to
PM> wake up from the sleep of last hundred, err, ten years and realize
PM> that rpm can and does change.
I think we realize this. rpm change is generally a good thing.
However, it would still be nice to have some way to do this. I
recognize that it may not be completely safe to push rpm updates to
supported Fedora releases, but it would be nice to have some basic
ideas of how we might go about getting a newer rpm onto, say, an F-9
box assuming that we're willing to deal with any weirdness that
results.
How about just having a parallel installable new RPM build for existing
distros. So mock would explicitly use the rpm-4.6 for creating build
roots, but the host system can continue using its existing RPM version
without risk to its operation
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:46 a.m.
On Wed, 2009-02-25 at 16:44 +0000, Daniel P. Berrange wrote:
How about just having a parallel installable new RPM build for
existing
distros. So mock would explicitly use the rpm-4.6 for creating build
roots, but the host system can continue using its existing RPM version
without risk to its operation
Use mock to create an F10 chroot. Chroot yourself into it, use mock to
build rawhide contents.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:51 a.m.
Hi, sorry if this is asked before:
2 of my packages failed the mass rebuild:
---------bouncycastle-mail-------------
http://koji.fedoraproject.org/koji/getfile?taskID=1152827&name=root.log
DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:256: rpmlib(FileDigests) is needed by popt-1.13-5.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by bash-4.0-0.5.rc1.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by
ethtool-6-3.20090115git.fc11.ppc
--------------- libzzub-------------------
http://koji.fedoraproject.org/koji/getfile?taskID=1177904&name=build.log
src/libzzub/filereader.h: In member function 'bool
FileWriter::create(const char*)':
src/libzzub/filereader.h:159: error: 'fopen' was not declared in this scope
--------------------------------------------
So, what is my responsibility if my package fails the mass rebuild? I
tried to read everything in the devel ML but I couldn't find anything
related. Maybe I missed it.
Thanks,
Orcan
10:29 a.m.
On Thu, Feb 26, 2009 at 10:51 AM, Orcan Ogetbil <oget.fedora(a)gmail.com> wrote:
So, what is my responsibility if my package fails the mass rebuild? I
tried to read everything in the devel ML but I couldn't find anything
related. Maybe I missed it.
Fix the problem by #include-ing the appropriate headers, file a bug
report upstream, and when you include the patch in the spec file, note
the bug report, e.g.:
# upstream bug: http://upstream/path/bugnumber
PatchN: %{name}-x.y-gcc44.patch
Regards,
--
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim(a)cs.indiana.edu
Fedora • salimma(a)fedoraproject.org
MacPorts • hircus(a)macports.org
10:42 a.m.
On Thu, Feb 26, 2009 at 11:29 AM, Michel Salim wrote:
On Thu, Feb 26, 2009 at 10:51 AM, Orcan Ogetbil wrote:
>
> So, what is my responsibility if my package fails the mass rebuild? I
> tried to read everything in the devel ML but I couldn't find anything
> related. Maybe I missed it.
>
Fix the problem by #include-ing the appropriate headers, file a bug
report upstream, and when you include the patch in the spec file, note
the bug report, e.g.:
# upstream bug: http://upstream/path/bugnumber
PatchN: %{name}-x.y-gcc44.patch
Regards,
Yes, that's the usual way. But I don't want to do that. This package
was orphaned when I took it over 2 days ago. I took it because I
wanted to update it to the newest version. But the upstream renamed
their software name in their last release. Therefore I will need to
submit a new Review Request and obsolete the old package. So I really
don't want to deal with the old package with the old name now.
And how about the bouncycastle-mail problem? I don't think that one is
packaging related.
Orcan
10:50 a.m.
On Thu, Feb 26, 2009 at 11:42 AM, Orcan Ogetbil <oget.fedora(a)gmail.com> wrote:
On Thu, Feb 26, 2009 at 11:29 AM, Michel Salim wrote:
> On Thu, Feb 26, 2009 at 10:51 AM, Orcan Ogetbil wrote:
>>
>> So, what is my responsibility if my package fails the mass rebuild? I
>> tried to read everything in the devel ML but I couldn't find anything
>> related. Maybe I missed it.
>>
> Fix the problem by #include-ing the appropriate headers, file a bug
> report upstream, and when you include the patch in the spec file, note
> the bug report, e.g.:
>
> # upstream bug: http://upstream/path/bugnumber
> PatchN: %{name}-x.y-gcc44.patch
>
>
> Regards,
Yes, that's the usual way. But I don't want to do that. This package
was orphaned when I took it over 2 days ago. I took it because I
wanted to update it to the newest version. But the upstream renamed
their software name in their last release. Therefore I will need to
submit a new Review Request and obsolete the old package. So I really
don't want to deal with the old package with the old name now.
The new version is likely to suffer from the same problem anyway. If
it's mostly a rename, then the review will be quite perfunctory -- if
you can get it done quick, you might as well get the new one reviewed,
built for Rawhide, and then ask release engineering to block the old
package from Rawhide -- see this:
http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
HTH,
--
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim(a)cs.indiana.edu
Fedora • salimma(a)fedoraproject.org
MacPorts • hircus(a)macports.org
10:38 a.m.
On Thu, 2009-02-26 at 10:51 -0500, Orcan Ogetbil wrote:
---------bouncycastle-mail-------------
http://koji.fedoraproject.org/koji/getfile?taskID=1152827&name=root.log
DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:256: rpmlib(FileDigests) is needed by popt-1.13-5.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by bash-4.0-0.5.rc1.fc11.ppc
DEBUG util.py:256: rpmlib(FileDigests) is needed by
ethtool-6-3.20090115git.fc11.ppc
This was a buildsystem error, I've resubmitted the build.
--------------- libzzub-------------------
http://koji.fedoraproject.org/koji/getfile?taskID=1177904&name=build.log
src/libzzub/filereader.h: In member function 'bool
FileWriter::create(const char*)':
src/libzzub/filereader.h:159: error: 'fopen' was not declared in this scope
This is a package error, you'll need to fix it and submit your own
build.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:48 a.m.
On Wed, 2009-02-25 at 16:44 +0000, Daniel P. Berrange wrote:
On Wed, Feb 25, 2009 at 09:46:27AM -0600, Jason L Tibbitts III
wrote:
> >>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
>
> PM> The strong file hashes are just the first messenger that got
> PM> through, and the message it brings is that it's time for people to
> PM> wake up from the sleep of last hundred, err, ten years and realize
> PM> that rpm can and does change.
>
> I think we realize this. rpm change is generally a good thing.
> However, it would still be nice to have some way to do this. I
> recognize that it may not be completely safe to push rpm updates to
> supported Fedora releases, but it would be nice to have some basic
> ideas of how we might go about getting a newer rpm onto, say, an F-9
> box assuming that we're willing to deal with any weirdness that
> results.
How about just having a parallel installable new RPM build for existing
distros. So mock would explicitly use the rpm-4.6 for creating build
roots, but the host system can continue using its existing RPM version
without risk to its operation
Parallel installable rpm would be extremely difficult considering that
mock uses yum and yum uses rpm through rpm-python.
-sv
9:31 a.m.
Panu Matilainen wrote:
On Tue, 24 Feb 2009, Tom Lane wrote:
> Jesse Keating <jkeating(a)redhat.com> writes:
>> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>>> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
>
>> The rpm version on the host has to be able to support the larger file
>> checksums. We have a special rpm built for our EL5 builders that
>> provides this. I don't know if that rpm build is hosted anywhere out in
>> the open, I do believe Mitr built it for us.
>
> It's going to be quite a large problem if people can no longer use mock
> on an older system to test rawhide builds. What is the plan to address
> this?
The strong file hashes are just the first messenger that got through,
and the message it brings is that it's time for people to wake up from
the sleep of last hundred, err, ten years and realize that rpm can and
does change. And yes it means older rpm versions can't always install
packages built by a newer rpm.
In the future can we make it policy that before any new,
non-backwards-compatible rpm features are turned on in the build system,
that all actively-supported distros have an rpm that supports those
features available in the stable repos for a reasonable period of time?
Not being able to install packages coming out of Koji has a very
negative effect on development, testing, package review, etc. We also
want to avoid the situation of people running actively-supported distros
being permanently locked-out of the ability to update or upgrade, if for
example the rpm in the repos was built using a feature that the previous
version of rpm did not support.
rpm is a critical (maybe *the* critical) piece of our
installation/upgrade infrastructure, we need to be more careful with
compatibility.
10:12 a.m.
On Thu, 26 Feb 2009, Mike Bonnet wrote:
Panu Matilainen wrote:
> On Tue, 24 Feb 2009, Tom Lane wrote:
>
>> Jesse Keating <jkeating(a)redhat.com> writes:
>>> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>>>> Can you say what it is? I'm seeing this on my centos 5.2 mock host.
>>
>>> The rpm version on the host has to be able to support the larger file
>>> checksums. We have a special rpm built for our EL5 builders that
>>> provides this. I don't know if that rpm build is hosted anywhere out in
>>> the open, I do believe Mitr built it for us.
>>
>> It's going to be quite a large problem if people can no longer use mock
>> on an older system to test rawhide builds. What is the plan to address
>> this?
>
> The strong file hashes are just the first messenger that got through,
> and the message it brings is that it's time for people to wake up from
> the sleep of last hundred, err, ten years and realize that rpm can and
> does change. And yes it means older rpm versions can't always install
> packages built by a newer rpm.
In the future can we make it policy that before any new,
non-backwards-compatible rpm features are turned on in the build system,
that all actively-supported distros have an rpm that supports those
features available in the stable repos for a reasonable period of time?
What does "actively supported" mean here? By gods I hope you're not
including RHEL here. If that's the case the rpm team might as well take a
very long vacation...
That rpm 4.6.0-rc and 4.6.0 final had an incompatibility wrt the strong
hashes was most unfortunate (and so was the timing of mass-rebuilds
starting before the update fixing that was got deployed), I sure hope such
a thing wont happen again.
Not being able to install packages coming out of Koji has a very
negative effect on development, testing, package review, etc. We also
want to avoid the situation of people running actively-supported distros
being permanently locked-out of the ability to update or upgrade, if for
example the rpm in the repos was built using a feature that the previous
version of rpm did not support.
Obviously rpm needs itself needs to be upgradable to next version, no
matter how painful it may be.
rpm is a critical (maybe *the* critical) piece of our
installation/upgrade infrastructure, we need to be more careful with
compatibility.
We take compatibility dead seriously, but there are very real limits to
what can be done compatibly and what can be be reasonably backported, if
possible at all. The strong hash support might be within possibilities but
already in rpm 4.6.0 the large package support is something that is
*impossible* to backport due to the required API/ABI changes.
- Panu -
10:25 a.m.
Panu Matilainen wrote:
We take compatibility dead seriously, but there are very real limits
to
what can be done compatibly and what can be be reasonably backported, if
possible at all. The strong hash support might be within possibilities but
already in rpm 4.6.0 the large package support is something that is
*impossible* to backport due to the required API/ABI changes.
Can't you lie about the size, reporting it as MAX_UINT or something like
that if the old API is used? That's how Window$ did large file support.
Kevin Kofler
10:31 a.m.
On Thursday 26 February 2009 16:12:27 Panu Matilainen wrote:
We take compatibility dead seriously, but there are very real limits
to
what can be done compatibly and what can be be reasonably backported, if
possible at all. The strong hash support might be within possibilities but
already in rpm 4.6.0 the large package support is something that is
*impossible* to backport due to the required API/ABI changes.
Isn't there a) a version number in the header, and b) the possibility of one of
those rpmlib(Foo) == 111 requires being added? At least one source rpm I
grabbed to look at fails to install on an older system, but there's no warning
at all before you get these checksum errors.
Better to fail with a warning that some new feature is required?
10:38 a.m.
On Thu, 26 Feb 2009, Bill Crawford wrote:
On Thursday 26 February 2009 16:12:27 Panu Matilainen wrote:
> We take compatibility dead seriously, but there are very real limits to
> what can be done compatibly and what can be be reasonably backported, if
> possible at all. The strong hash support might be within possibilities but
> already in rpm 4.6.0 the large package support is something that is
> *impossible* to backport due to the required API/ABI changes.
Isn't there a) a version number in the header, and b) the possibility of one of
those rpmlib(Foo) == 111 requires being added? At least one source rpm I
grabbed to look at fails to install on an older system, but there's no warning
at all before you get these checksum errors.
Better to fail with a warning that some new feature is required?
There is a rpmlib() dependency on the strong hash support, but the
rpmlib() dependency mechanism is a bit backwards which prevents the it
from working in this particular case (from 4.6.0-rc to 4.6.0-final) :-/
- Panu -
10:56 a.m.
Panu Matilainen wrote:
On Thu, 26 Feb 2009, Mike Bonnet wrote:
> Panu Matilainen wrote:
>> On Tue, 24 Feb 2009, Tom Lane wrote:
>>
>>> Jesse Keating <jkeating(a)redhat.com> writes:
>>>> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>>>>> Can you say what it is? I'm seeing this on my centos 5.2 mock
host.
>>>
>>>> The rpm version on the host has to be able to support the larger file
>>>> checksums. We have a special rpm built for our EL5 builders that
>>>> provides this. I don't know if that rpm build is hosted anywhere
>>>> out in
>>>> the open, I do believe Mitr built it for us.
>>>
>>> It's going to be quite a large problem if people can no longer use mock
>>> on an older system to test rawhide builds. What is the plan to address
>>> this?
>>
>> The strong file hashes are just the first messenger that got through,
>> and the message it brings is that it's time for people to wake up from
>> the sleep of last hundred, err, ten years and realize that rpm can and
>> does change. And yes it means older rpm versions can't always install
>> packages built by a newer rpm.
>
> In the future can we make it policy that before any new,
> non-backwards-compatible rpm features are turned on in the build system,
> that all actively-supported distros have an rpm that supports those
> features available in the stable repos for a reasonable period of time?
What does "actively supported" mean here? By gods I hope you're not
including RHEL here. If that's the case the rpm team might as well take
a very long vacation...
No, in this case I mean F9, F10, rawhide. It's unfortunate that rawhide
packages are no longer installable on F9, and were not installable for a
while on F10. This negatively affects developers, testers, etc.
That rpm 4.6.0-rc and 4.6.0 final had an incompatibility wrt the
strong
hashes was most unfortunate (and so was the timing of mass-rebuilds
starting before the update fixing that was got deployed), I sure hope
such a thing wont happen again.
I understand things got rushed because of the timing of the mass
rebuild, which got rushed because of the timing of the feature freeze.
I'm not trying to lay blame on anyone, just pointing out that we need to
think about the process of rolling out new, incompatible features when
they affect the installation/upgrade path, be they rpm, yum, anaconda, etc.
> Not being able to install packages coming out of Koji has a very
> negative effect on development, testing, package review, etc. We also
> want to avoid the situation of people running actively-supported distros
> being permanently locked-out of the ability to update or upgrade, if for
> example the rpm in the repos was built using a feature that the previous
> version of rpm did not support.
Obviously rpm needs itself needs to be upgradable to next version, no
matter how painful it may be.
Agreed.
> rpm is a critical (maybe *the* critical) piece of our
> installation/upgrade infrastructure, we need to be more careful with
> compatibility.
We take compatibility dead seriously, but there are very real limits to
what can be done compatibly and what can be be reasonably backported, if
possible at all. The strong hash support might be within possibilities
but already in rpm 4.6.0 the large package support is something that is
*impossible* to backport due to the required API/ABI changes.
I don't know anything about large package support. Is this something
that will affect the package installation in Fedora?
11:25 a.m.
Mike Bonnet wrote:
Panu Matilainen wrote:
> On Thu, 26 Feb 2009, Mike Bonnet wrote:
>
>
>> Panu Matilainen wrote:
>>
>>> On Tue, 24 Feb 2009, Tom Lane wrote:
>>>
>>>
>>>> Jesse Keating <jkeating(a)redhat.com> writes:
>>>>
>>>>> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>>>>>
>>>>>> Can you say what it is? I'm seeing this on my centos 5.2
mock host.
>>>>>>
>>>>> The rpm version on the host has to be able to support the larger
file
>>>>> checksums. We have a special rpm built for our EL5 builders that
>>>>> provides this. I don't know if that rpm build is hosted
anywhere
>>>>> out in
>>>>> the open, I do believe Mitr built it for us.
>>>>>
>>>> It's going to be quite a large problem if people can no longer use
mock
>>>> on an older system to test rawhide builds. What is the plan to address
>>>> this?
>>>>
>>> The strong file hashes are just the first messenger that got through,
>>> and the message it brings is that it's time for people to wake up from
>>> the sleep of last hundred, err, ten years and realize that rpm can and
>>> does change. And yes it means older rpm versions can't always install
>>> packages built by a newer rpm.
>>>
>> In the future can we make it policy that before any new,
>> non-backwards-compatible rpm features are turned on in the build system,
>> that all actively-supported distros have an rpm that supports those
>> features available in the stable repos for a reasonable period of time?
>>
> What does "actively supported" mean here? By gods I hope you're not
> including RHEL here. If that's the case the rpm team might as well take
> a very long vacation...
>
No, in this case I mean F9, F10, rawhide. It's unfortunate that rawhide
packages are no longer installable on F9, and were not installable for a
while on F10. This negatively affects developers, testers, etc.
> That rpm 4.6.0-rc and 4.6.0 final had an incompatibility wrt the strong
> hashes was most unfortunate (and so was the timing of mass-rebuilds
> starting before the update fixing that was got deployed), I sure hope
> such a thing wont happen again.
>
I understand things got rushed because of the timing of the mass
rebuild, which got rushed because of the timing of the feature freeze.
I'm not trying to lay blame on anyone, just pointing out that we need to
think about the process of rolling out new, incompatible features when
they affect the installation/upgrade path, be they rpm, yum, anaconda, etc.
There's my next question. Will an upgrade from 10 to 11, whether by
anaconda or yum, be possible?
>> Not being able to install packages coming out of Koji has a
very
>> negative effect on development, testing, package review, etc. We also
>> want to avoid the situation of people running actively-supported distros
>> being permanently locked-out of the ability to update or upgrade, if for
>> example the rpm in the repos was built using a feature that the previous
>> version of rpm did not support.
>>
> Obviously rpm needs itself needs to be upgradable to next version, no
> matter how painful it may be.
>
Agreed.
>> rpm is a critical (maybe *the* critical) piece of our
>> installation/upgrade infrastructure, we need to be more careful with
>> compatibility.
>>
> We take compatibility dead seriously, but there are very real limits to
> what can be done compatibly and what can be be reasonably backported, if
> possible at all. The strong hash support might be within possibilities
> but already in rpm 4.6.0 the large package support is something that is
> *impossible* to backport due to the required API/ABI changes.
>
I don't know anything about large package support. Is this something
that will affect the package installation in Fedora?
--
in your fear, speak only peace
in your fear, seek only love
-d. bowie
4:09 p.m.
Mike Bonnet wrote:
No, in this case I mean F9, F10, rawhide. It's unfortunate that
rawhide
packages are no longer installable on F9, and were not installable for a
while on F10. This negatively affects developers, testers, etc.
Installing Rawhide packages on F10 and even more so F9 has never been
supported, there were always dependency issues and the like. The mock issue
is the bigger one.
Kevin Kofler
4:26 p.m.
Kevin Kofler wrote:
Mike Bonnet wrote:
> No, in this case I mean F9, F10, rawhide. It's unfortunate that rawhide
> packages are no longer installable on F9, and were not installable for a
> while on F10. This negatively affects developers, testers, etc.
Installing Rawhide packages on F10 and even more so F9 has never been
supported, there were always dependency issues and the like. The mock issue
is the bigger one.
I meant installing using mock, in a chroot. I understand that we don't
support installing F10+ packages on a F9 host.
12:02 p.m.
On Thursday 26 February 2009 10:12:27 am Panu Matilainen wrote:
On Thu, 26 Feb 2009, Mike Bonnet wrote:
We take compatibility dead seriously, but there are very real limits to
what can be done compatibly and what can be be reasonably backported, if
possible at all. The strong hash support might be within possibilities but
already in rpm 4.6.0 the large package support is something that is
*impossible* to backport due to the required API/ABI changes.
What is Large package
support? koji has a limit of 2gb per rpm/srpm anything
bigger will cause build failures.
perhaps we need to have regular (i.e. start of development cycle) meeting with
koji and rpm devs. that way koji support for new rpm features can be planned
out and tested well in advance.
Dennis
4:58 a.m.
2009/2/24 Jesse Keating <jkeating(a)redhat.com>:
On Tue, 2009-02-24 at 10:35 +0100, Thomas Moschny wrote:
> The rebuild of one of my packages (botan) also failed, but with this
> error in the root.log:
>
> ...
> DEBUG util.py:256: ERROR with rpm_check_debug vs depsolve:
> DEBUG util.py:256: rpmlib(FileDigests) is needed by
> popt-1.13-5.fc11.ppc
> DEBUG util.py:256: rpmlib(FileDigests) is needed by
> bash-4.0-0.5.rc1.fc11.ppc
> DEBUG util.py:256: rpmlib(FileDigests) is needed by
> ethtool-6-3.20090115git.fc11.ppc
> DEBUG util.py:256: (1, ['Please report this error in bugzilla'])
> ...
>
> Seems like something more general is not working, maybe its build
> requirements need to be rebuilt first?
There was a short lived config error on one of the new builders we
brought online last night. I do believe I've resubmitted all the tasks
that failed for these reasons.
The botan package nevertheless showed up on the failed builds page. So
I resubmitted it myself, even twice [1] (bumping the release), but it
still shows up there, why's that?
[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=91538
--
Thomas Moschny <thomas.moschny(a)gmail.com>
9:59 a.m.
On Fri, 2009-02-27 at 11:58 +0100, Thomas Moschny wrote:
The botan package nevertheless showed up on the failed builds page. So
I resubmitted it myself, even twice [1] (bumping the release), but it
still shows up there, why's that?
[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=91538
Because the script didn't get automated yet and I didn't run it in my
sleep (: I just updated the failure list and now botan doesn't show up.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:49 a.m.
On Tuesday 24 February 2009 10:26:28 Till Maas wrote:
Aloas,
On Mo Februar 23 2009, Jesse Keating wrote:
> In just a few minutes, I will begin the scripted rebuild of every Fedora
> package in rawhide (dist-f11). See
> https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild for details.
the rebuild of one of my packages failed, can I now just debug it and start
a new build when I got it to build? Strangely it did not fail in the gcc
4.4 test mass rebuild or the recent rebuild by Matt Domsch.
Regards,
Till
Hi,
I have the same problem. One of my packages failed build because of gcc-4.4,
but it didn't fail for gcc 4.4 rebuild.
note: apcupsd is little bit different/odd, it uses .c files with c++ source (and
c++ compiler).
I'm going to fix this in cvs and build it. I've read something about that
rebuild script doesn't rebuild the package if it finds build newer than some
date.
Michal
11:16 a.m.
On Tue, 2009-02-24 at 10:26 +0100, Till Maas wrote:
the rebuild of one of my packages failed, can I now just debug it and start a
new build when I got it to build? Strangely it did not fail in the gcc 4.4
test mass rebuild or the recent rebuild by Matt Domsch.
Yes, if the script has hit your build and failed (and there was no
resubmitted task) you are free to debug/build at will. The script I'll
be running later this week to find things still needing to be built will
discover your package having been built.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5570
days inactive
5574
days old
37 comments
21 participants
participants (21)
-
Bill Crawford -
Daniel P. Berrange -
Dennis Gilmore -
Jason L Tibbitts III -
Jesse Keating -
Jon Ciesla -
Kevin Kofler -
Laurent Rineau -
Mamoru Tasaka -
Michael Thomas -
Michal Hlavinka -
Michel Salim -
Mike Bonnet -
Miloslav Trmač -
Orcan Ogetbil -
Orion Poplawski -
Panu Matilainen -
Seth Vidal -
Thomas Moschny -
Till Maas -
Tom Lane