Re: more binnmus to improve the state of armhf testing
Julien Cristau wrote:
hdf5 and friends will migrate soonish.
That wasn't the impression I got when looking at the list of blockers
for the transition bug, looking at the transition status page and asking
on irc.
vlc's already in sync.
It wasn't when I started putting the list together (I ran build tests on
everything before submitting with the result it was a while between
starting writing the main and finishing it), I thought I re-checked
things before sending but I must have missed this one. Sorry.
>transfig, libgtk2-perl and audacious-* need their bugs fixed.
I did try to put pressure on these failures in unstable.
For transfig according to the maintainer the bug doesn't seem to be
reproducable outside the buildd environment despite being reproducable
though multiple retries on the buildds of the affected architectures.
For audacious I asked the sparc porters for some basic tests to check if
the issue was reproducable and if so collect the material needed for a
bug but i'd given up on getting a response when I sent the binnmu
request (I did get a response AFTER I sent the binnmu request :/).
For libgtk2-perl I tried to reproduce the issue in qemu and the package
built fine for me. I then sent a mail to the mipsel buildd admins asking
if they could requeue to see if it was a flike but didn't get a response.
Adam D. Barratt wrote:
>Indeed. While it's great that you're trying to help improve the state
>of the armhf port in testing, this request is a little confusing.
Sorry if I have been impatient and/or overzelous in trying to get armhf
testing into shape.
I've been tracking the issues I run into as I go through the uninstable
packages list looking for the root causes at
http://wiki.debian.org/ArmHardFloatTodo
Probablly best to let things sit for a while now and see how good/bad
the situation is after the packages i've identified as waiting for
testing migration delay have done so.
>I'm also not sure why these packages are so important. "
All of the packages I listed were directly or indirectly making other
packages uninstable (note: I am counting arch all packages here, while
britney does ignore them afaict this is regarded as a hack, not as a
statement that arch all packages are unimportant). Sometimes it takes
following quite a long trail to find the route cause of an
uninstability. For example python-expeyes depends on python-pygrace.
python-pygrace depends on grace. Grace isn't migrating to testing
because of a dependency on netcdf and netcdf wasn't migrating to testing
because it's caught up in the hdf transition.
>For future reference, one needs to be very careful when requesting /
>scheduling binNMUs in suites other than unstable / experimental.
>wanna-build's "installed version" field lists the source version, and
>the fields indicating that binNMUs have been scheduled don't propagate
>across suites. As noted above, this can lead to situations such as
>scheduling +b1 in testing when that version is already in the archive
>(or has been at a previous point).
Thanks for the info
Does this mean that such requests should always be made against
a specific version so that they fail if the situation changes between
preparing the request and someone actioning it?
What is the best way to check what binnmu versions have previously
been in the archive? snapshot.debian.org?
Reply to: