1:30 p.m.
F-13 builds requiring libtool are now failing with
DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems
DEBUG util.py:256: --> Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: You could try using --skip-broken to work around the problem
apparently as a result of the fact that gcc was updated to 4.4.4 over
the weekend. Could we have a fix for this ASAP, please? And why
weren't there loud bleats from broken-dependencies checking?
regards, tom lane
1:38 p.m.
Tom Lane wrote, at 05/04/2010 03:30 AM +9:00:
F-13 builds requiring libtool are now failing with
DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems
DEBUG util.py:256: --> Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: You could try using --skip-broken to work around the problem
apparently as a result of the fact that gcc was updated to 4.4.4 over
the weekend. Could we have a fix for this ASAP, please? And why
weren't there loud bleats from broken-dependencies checking?
regards, tom lane
$ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate [still
active]
Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override
The dependency was broken only for this 2 hours (perhaps to rebuild libtool for gcc
4.4.4).
Now:
$ koji latest-pkg dist-f13-build gcc libtool
Build Tag Built by
---------------------------------------- -------------------- ----------------
gcc-4.4.3-18.fc13 dist-f13 jakub
libtool-2.2.6-18.fc13 dist-f13 jakub
Once newrepo is created, dependency will be recovered again.
Regards,
Mamoru
2:35 p.m.
Mamoru Tasaka <mtasaka(a)ioa.s.u-tokyo.ac.jp> writes:
$ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate [still
active]
Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override
The dependency was broken only for this 2 hours (perhaps to rebuild
libtool for gcc 4.4.4).
...
Once newrepo is created, dependency will be recovered again.
BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot.
There is no newrepo task running for F-13, and no evidence that one has
been launched recently. Perhaps an untag event fails to force a repo
rebuild? If so seems like a bug.
regards, tom lane
3:17 p.m.
On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote:
Mamoru Tasaka <mtasaka(a)ioa.s.u-tokyo.ac.jp> writes:
> $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
> Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate
[still active]
> Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
> Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override
> The dependency was broken only for this 2 hours (perhaps to rebuild libtool for gcc
4.4.4).
> ...
> Once newrepo is created, dependency will be recovered again.
BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot.
There is no newrepo task running for F-13, and no evidence that one has
been launched recently. Perhaps an untag event fails to force a repo
rebuild? If so seems like a bug.
So what is
http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992
then?
Jakub
3:28 p.m.
Jakub Jelinek <jakub(a)redhat.com> writes:
On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote:
> BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot.
> There is no newrepo task running for F-13, and no evidence that one has
> been launched recently. Perhaps an untag event fails to force a repo
> rebuild? If so seems like a bug.
So what is
http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992
then?
Something that launched right about the same time I complained,
evidently ;-)
regards, tom lane
3:31 p.m.
Jakub Jelinek wrote, at 05/04/2010 05:17 AM +9:00:
On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote:
> Mamoru Tasaka<mtasaka(a)ioa.s.u-tokyo.ac.jp> writes:
>> $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13
>> Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate
[still active]
>> Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override
>> Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override
>
>> The dependency was broken only for this 2 hours (perhaps to rebuild libtool for
gcc 4.4.4).
>> ...
>> Once newrepo is created, dependency will be recovered again.
>
> BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot.
> There is no newrepo task running for F-13, and no evidence that one has
> been launched recently. Perhaps an untag event fails to force a repo
> rebuild? If so seems like a bug.
So what is
http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992
then?
Jakub
Well, it seems usually koji runs 3 newrepo tasks at the same time, but
two of them were hanging for 9 hours (for dist-rawhide and dist-rawhide)
so newrepo tasks were rolling very slowly (I noticed this because
I submitted one chain-build for dist-rawhide but it failed because wait-repo
failed).
I requested to cancel hanging 2 newrepo tasks and they were cancelled.
Now newrepo tasks seem to be going well and new F-13 build already appeared as
Jakub said above.
Mamoru
1:42 p.m.
Am Montag, den 03.05.2010, 14:30 -0400 schrieb Tom Lane:
F-13 builds requiring libtool are now failing with
DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems
DEBUG util.py:256: --> Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: You could try using --skip-broken to work around the problem
apparently as a result of the fact that gcc was updated to 4.4.4 over
the weekend. Could we have a fix for this ASAP, please? And why
weren't there loud bleats from broken-dependencies checking?
The fix seems to be on its way 'later on:
https://fedorahosted.org/rel-eng/ticket/3685#comment:5
1:45 p.m.
On Mon, May 03, 2010 at 02:30:54PM -0400, Tom Lane wrote:
F-13 builds requiring libtool are now failing with
DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems
DEBUG util.py:256: --> Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package
libtool-2.2.6-18.fc13.x86_64 (build)
DEBUG util.py:256: You could try using --skip-broken to work around the problem
apparently as a result of the fact that gcc was updated to 4.4.4 over
the weekend. Could we have a fix for this ASAP, please? And why
weren't there loud bleats from broken-dependencies checking?
gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override
so that new libtool could be built. Likely you tried to built during
that short window or NewRepo has been too slow after it has been untagged
from dist-f13-override already.
Jakub
1:54 p.m.
Jakub Jelinek <jakub(a)redhat.com> writes:
gcc-4.4.4-1.fc13 has just been tagged temporarily into
dist-f13-override
so that new libtool could be built. Likely you tried to built during
that short window or NewRepo has been too slow after it has been untagged
from dist-f13-override already.
I see. It seems like this indicates a rather fundamental shortcoming in
the -override tagging mechanism. If random other builds that happen to
be submitted at the wrong time will see the overridden packages, what
happens to reproducibility? Can't we either fix it so that only the
specific desired builds see the override, or just prevent unrelated
builds from happening during the window? This is surely not going to
be the last undesired failure if things stay like this.
regards, tom lane
4:23 p.m.
On Mon, 2010-05-03 at 14:54 -0400, Tom Lane wrote:
Jakub Jelinek <jakub(a)redhat.com> writes:
> gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override
> so that new libtool could be built. Likely you tried to built during
> that short window or NewRepo has been too slow after it has been untagged
> from dist-f13-override already.
I see. It seems like this indicates a rather fundamental shortcoming in
the -override tagging mechanism. If random other builds that happen to
be submitted at the wrong time will see the overridden packages, what
happens to reproducibility? Can't we either fix it so that only the
specific desired builds see the override, or just prevent unrelated
builds from happening during the window? This is surely not going to
be the last undesired failure if things stay like this.
regards, tom lane
I welcome suggestions. Your first suggestion would require entirely new
buildroot tags produced for each -override. New buildroots have a
significant cost in spin up, upwards to an hour or more for the first
repo generation. Do you really want to introduce an hour+ delay in your
build every time you need an override, not to mention the vastly
increased load on our backend filesystem?
The second suggestion would put significant blocks in our build windows,
since we get override requests on a daily basis. If only one could be
done at a time, and we had to wait until the build was finished before
moving on, we'd have a serious backlog and almost never have a window
for doing builds without any override tags in play.
We take a measured risk with our current system, because that's the best
balance we can strike right now.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5131
days inactive
5131
days old
10 comments
5 participants
participants (5)
-
Jakub Jelinek -
Jesse Keating -
Mamoru Tasaka -
Thomas Spura -
Tom Lane