[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: