On 08/07/2013 10:56 AM, Marcela Mašláňová wrote:
On 08/07/2013 03:01 AM, Dennis Gilmore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Tue, 06 Aug 2013 13:39:31 -0700
> Adam Williamson <awilliam(a)redhat.com> wrote:
>> On Thu, 2013-06-13 at 11:10 -0600, Kevin Fenzi wrote:
>>> On Thu, 13 Jun 2013 13:23:51 +0000 (UTC)
>>> Petr Pisar <ppisar(a)redhat.com> wrote:
>>>> On 2013-06-12, Kevin Fenzi <kevin(a)scrye.com> wrote:
>>>>> So, there's nothing preventing the side tag and rebuild anytime
>>>>> now right? 5.18.0 is out, so we could start that work in
>>>> Currently 5.18.0 does not pass one test when running in mock and
>>>> koji. (It's because of the terminal usage in tested perl
>>>> debugger.) We think we could have solved this issue in a few days.
>>>> Could you explain how the side tag inheritance works? It inherits
>>>> everything from rawhide, even builds made after the side tag
>>>> except packages whose builds have been already made in the side
>>>> tag. Am I right? That means we still get fresh third-party
>>>> dependencies from rawhide.
>>> yes. However, there's are several downsides:
>>> - Each side tag adds newrepo tasks which increases load a lot.
>>> - If you rebuild perl-foo-1.0-1 in the side tag against the new
>>> perl, then the maintainer has to fix something in rawhide, they
>>> would build perl-foo-1.0-2 in rawhide and when the side tag was
>>> merged back over either everyone would get the older one with the
>>> bug, or the newer one against the old perl. So, it's really
>>> important to not take a long time using a side tag to avoid this
>>> problem as much as possible.
>> Seems like this one came true in practice. It seems like a 5.18
>> rebuild run was done in a side tag and then merged back into Rawhide.
>> Unfortunately, quite a lot of the 5.18 rebuilds seem to have been done
>> prior to the general F20 mass rebuild - so the mass rebuild won out,
>> and effectively squelched the perl rebuild.
> The f20-perl tag was merged back before the mass rebuild was started.
> so everything in the mass rebuild was built against the new perl.
> however because the perl rebuild was at a week there was quite a few
> packages rebuilt against the old perl. we need to work out how to build
> perl quicker. your analysis is not really correct.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> -----END PGP SIGNATURE-----
If someone knows about a tool, which can give build order faster than
Petr's tool, then it would help ;-)
I've been working on improving one of Seth's last scripts call
buildorder that he wrote to order a set or SRPMS.
The current version is far from complete and/or bugfree yet, but i've
attached the current version to this email.
It's really simple: You give it a set of srpms and it spits out the
buildorder for it as precisely as it can get it.
The improvements i made was to get rid of the topology sort module he
had been using and replaced it with my own implementation which also
automatically breaks build loops at spots that are likely to be most
beneficial to be broken. It does grouping as well, just like Seth's
original version, but the actual group output is commented out at the
moment as i'm using it for sequentially rebuilding things, not in
parallel, so groups don't matter for my use case. If you want groups
simply remove the comment from the
# print "Group %d (%d reqs)" % (group, minreqs)
It also fixes an issue with the global macro definitions which didn't
I've also added the manual provides specified in the specfiles, that
gave a bit better dependency completion.
Last (and least) there is some commented out code it in where you can
potentially use this code to also find the full buildchain for a
specific package, basically allowing you to specify 1 or a few srpms
you'd like to build and the script would spit out a list of all srpms
you'll need to build for those packages in the necessary order.
Just like Seth's script it has a few obviously problems as for really
correct build ordering you need to flip-flop between srpms/specfiles and
binary rpms, but that will need a bit of a different approach. As it
stands right now some of the dependencies it can't detect and resolve
are build time generated ones, which might a showstopper for some uses
I've tested the version i have here with several complete past Fedora
trees, for texlive and KDE rebuilds and updates and for all the cases
the output look pretty sane.
Hope this helps,
Thanks & regards, Phil
Philipp Knirsch | Tel.: +49-711-96437-470
Manager Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com>
Wankelstrasse 5 | Web: http://www.redhat.com/
D-70563 Stuttgart, Germany