Bug#954654: transition: hdf5

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Gilles Filippini-2
Package: release.debian.org
Severity: normal
User: [hidden email]
Usertags: transition

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Release Team,

I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in
experimental.

Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures
aren't related to the transition:
jhdf       KO - #875584 - Not in testing
openmolcas KO - Not in testing
sra-sdk    KO - #952623 - Removal from testing on the 10/04/2020
xmds2      KO - #938925 - Not in testing
ants       KO - Multiple RC bugs - Not in testing
siconos    KO - #954497 - Removal from testing on the 29/03/2020
simpleitk  KO - #949355 - Not in testing

Ben file:

title = "hdf5";
is_affected = .depends ~ /libhdf5/ | .build-depends ~ /hdf5/;
is_good = .depends ~ /libhdf5-103-1|libhdf5-openmpi-103-1|libhdf5-mpich-103-1/;
is_bad = .depends ~ /libhdf5-103|libhdf5-openmpi-103|libhdf5-mpich-103/;

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl53SaEACgkQ7+hsbH/+
z4No4AgAnTZUxHfzT3dtR3B++dZEgOOvb1xnpf8OS3MxVFVUVyIwoWMkGVDp/kXx
sbkT8WOKXvrioLxekCmjvnojPzoFVJD8rcxj9au0fjxSb+sE6uRgVZunXOtgLlgU
+OuKkyj6niHJJgIin6QqN4hmNTGzK5gfJfv+DFF3LmmZtYHh0HZWEBkguS07TG/4
Bq+km1KqADaPlWGANf7yXBiIvzhXO12ZMpsrMg79YalB2YNoVl1treHTBRD6NO1q
KVLLFUntt2zpVtYCQW6YrkKFuWcFRPB8GjoWmstkXXIhOcFBWP466iFdTW406ZKR
4aVGHvxemx+JPpn5VzhUClHHISh1cw==
=6u+X
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Emilio Pozuelo Monfort-4
Control: tags -1 confirmed

On 22/03/2020 12:19, Gilles Filippini wrote:

> Package: release.debian.org
> Severity: normal
> User: [hidden email]
> Usertags: transition
>
> Hi Release Team,
>
> I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in
> experimental.
>
> Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures
> aren't related to the transition:
> jhdf       KO - #875584 - Not in testing
> openmolcas KO - Not in testing
> sra-sdk    KO - #952623 - Removal from testing on the 10/04/2020
> xmds2      KO - #938925 - Not in testing
> ants       KO - Multiple RC bugs - Not in testing
> siconos    KO - #954497 - Removal from testing on the 29/03/2020
> simpleitk  KO - #949355 - Not in testing

Sounds good. Go ahead.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Gilles Filippini-2
Emilio Pozuelo Monfort a écrit le 27/03/2020 à 13:29 :

> Control: tags -1 confirmed
>
> On 22/03/2020 12:19, Gilles Filippini wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: [hidden email]
>> Usertags: transition
>>
>> Hi Release Team,
>>
>> I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in
>> experimental.
>>
>> Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures
>> aren't related to the transition:
>> jhdf       KO - #875584 - Not in testing
>> openmolcas KO - Not in testing
>> sra-sdk    KO - #952623 - Removal from testing on the 10/04/2020
>> xmds2      KO - #938925 - Not in testing
>> ants       KO - Multiple RC bugs - Not in testing
>> siconos    KO - #954497 - Removal from testing on the 29/03/2020
>> simpleitk  KO - #949355 - Not in testing
>
> Sounds good. Go ahead.
Uploaded!

Thanks,

_g.


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
In reply to this post by Emilio Pozuelo Monfort-4
Some intervention for gdal on s390x may be needed, it's stuck in
Maybe-Successful state blocking the rebuild of its rdeps. The log seems
to indicate that the build was indeed successful.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Emilio Pozuelo Monfort-4
In reply to this post by Gilles Filippini-2
On 28/03/2020 10:50, Gilles Filippini wrote:

> Emilio Pozuelo Monfort a écrit le 27/03/2020 à 13:29 :
>> Control: tags -1 confirmed
>>
>> On 22/03/2020 12:19, Gilles Filippini wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: [hidden email]
>>> Usertags: transition
>>>
>>> Hi Release Team,
>>>
>>> I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in
>>> experimental.
>>>
>>> Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures
>>> aren't related to the transition:
>>> jhdf       KO - #875584 - Not in testing
>>> openmolcas KO - Not in testing
>>> sra-sdk    KO - #952623 - Removal from testing on the 10/04/2020
>>> xmds2      KO - #938925 - Not in testing
>>> ants       KO - Multiple RC bugs - Not in testing
>>> siconos    KO - #954497 - Removal from testing on the 29/03/2020
>>> simpleitk  KO - #949355 - Not in testing
>>
>> Sounds good. Go ahead.
>
> Uploaded!

hdf5 is currently blocked from migrating to testing on mpich due to #954244.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Alastair McKinstry-9
Hi,

There is a fix for #954244 in experimental but I there are other more
serious problems with mpich-3.4a4-2

Upstream quietly reset the soversion to 0 (as its an alpha package). The
code works but any users of libmpich12 break.

3.4 when released will bump the soversion (it drops some symbols).

The simplest solution for mpich is to leave the blocker so that the
dodgy package doesn't transition, until mpich 3.4 is released.

I don't have a timetable for the mpich 3.4 release, which now entangles
hdf5.

Alternatively, we can pre-empt and increment the mpich soversion (as
I've tested in experimental) and start an mpich transition.

regards

Alastair


On 06/04/2020 11:54, Emilio Pozuelo Monfort wrote:

> On 28/03/2020 10:50, Gilles Filippini wrote:
>> Emilio Pozuelo Monfort a écrit le 27/03/2020 à 13:29 :
>>> Control: tags -1 confirmed
>>>
>>> On 22/03/2020 12:19, Gilles Filippini wrote:
>>>> Package: release.debian.org
>>>> Severity: normal
>>>> User: [hidden email]
>>>> Usertags: transition
>>>>
>>>> Hi Release Team,
>>>>
>>>> I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in
>>>> experimental.
>>>>
>>>> Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures
>>>> aren't related to the transition:
>>>> jhdf       KO - #875584 - Not in testing
>>>> openmolcas KO - Not in testing
>>>> sra-sdk    KO - #952623 - Removal from testing on the 10/04/2020
>>>> xmds2      KO - #938925 - Not in testing
>>>> ants       KO - Multiple RC bugs - Not in testing
>>>> siconos    KO - #954497 - Removal from testing on the 29/03/2020
>>>> simpleitk  KO - #949355 - Not in testing
>>> Sounds good. Go ahead.
>> Uploaded!
> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>
> Cheers,
> Emilio
>
--
Alastair McKinstry, email: [hidden email], matrix: @alastair:sceal.ie, phone: 087-6847928
Green Party Councillor, Galway County Council

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
On 4/6/20 1:43 PM, Alastair McKinstry wrote:

> There is a fix for #954244 in experimental but I there are other more
> serious problems with mpich-3.4a4-2
>
> Upstream quietly reset the soversion to 0 (as its an alpha package). The
> code works but any users of libmpich12 break.
>
> 3.4 when released will bump the soversion (it drops some symbols).
>
> The simplest solution for mpich is to leave the blocker so that the
> dodgy package doesn't transition, until mpich 3.4 is released.
>
> I don't have a timetable for the mpich 3.4 release, which now entangles
> hdf5.
>
> Alternatively, we can pre-empt and increment the mpich soversion (as
> I've tested in experimental) and start an mpich transition.

Can't mpich in unstable be reverted to 3.3.3 which built successfully?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Alastair McKinstry-3

On 06/04/2020 12:53, Sebastiaan Couwenberg wrote:
> On 4/6/20 1:43 PM, Alastair McKinstry wrote:
>> There is a fix for #954244 in experimental but I there are other more
>> serious problems with mpich-3.4a4-2
>>
> Can't mpich in unstable be reverted to 3.3.3 which built successfully?
Yes, it could. I'm requesting a ROM from unstable, then revert with a
3.3.2 upload.
> Kind Regards,
>
> Bas
>
--
Alastair McKinstry, <[hidden email]>, <[hidden email]>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
In reply to this post by Emilio Pozuelo Monfort-4
On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
> hdf5 is currently blocked from migrating to testing on mpich due to #954244.

mpich migrated to testing. hdf5 will need some help to migrate, not all
bad rdeps will be autoremoved eventually.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Emilio Pozuelo Monfort-4
On 09/04/2020 06:17, Sebastiaan Couwenberg wrote:
> On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
>> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>
> mpich migrated to testing. hdf5 will need some help to migrate, not all
> bad rdeps will be autoremoved eventually.

I couldn't really understand what was going on from the normal hint output:

    got: 37+0: a-1:a-0:a-15:a-0:i-20:m-0:m-0:p-0:s-1
    * armel: cdo, code-saturne, code-saturne-include, harp, libadios-bin, libharp-dev, libharp10, libncarg-bin, libncarg-dev, libncarg0, ncl-ncarg, python3-adios, python3-cdo, python3-harp, python3-sfepy


Looking closely at those packages didn't give me any hint as to why they would
be uninstallable (not even on armel) so I added a full hint-type hint and did
a test run, and I got this:

I: [2020-04-09T08:49:35+0000] - Removed 9 of 40 cruft item(s) after the changes
I: [2020-04-09T08:49:35+0000] - easy: 55+0: a-10:a-3:a-3:a-3:i-23:m-3:m-3:p-3:s-4
I: [2020-04-09T08:49:35+0000] -     * amd64: cantor-backend-scilab, cdo, python3-cdo, ruby-hdfeos5, scilab, scilab-cli, scilab-full-bin, scilab-minimal-bin, scilab-test
I: [2020-04-09T08:49:35+0000] -     * arm64: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * armel: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * armhf: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * i386: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * mips64el: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * mipsel: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * ppc64el: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] -     * s390x: cdo, python3-cdo, ruby-hdfeos5
I: [2020-04-09T08:49:35+0000] - FAILED

Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a candidate
but I would remove it now to finish this) and scilab. Unfortunately after checking
with dak, I found that tasksel depends on meta-kde, which depends on cantor, which
depends on scilab, which means that scilab is going to need a fix for #955694 in
order for this transition to finish.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
In reply to this post by Gilles Filippini-2
On 4/21/20 11:32 AM, Emilio Pozuelo Monfort wrote:

> On 09/04/2020 11:09, Emilio Pozuelo Monfort wrote:
>> On 09/04/2020 06:17, Sebastiaan Couwenberg wrote:
>>> On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
>>>> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>>>
>>> mpich migrated to testing. hdf5 will need some help to migrate, not all
>>> bad rdeps will be autoremoved eventually.
>>
>> I couldn't really understand what was going on from the normal hint output:
>>
>>     got: 37+0: a-1:a-0:a-15:a-0:i-20:m-0:m-0:p-0:s-1
>>     * armel: cdo, code-saturne, code-saturne-include, harp, libadios-bin, libharp-dev, libharp10, libncarg-bin, libncarg-dev, libncarg0, ncl-ncarg, python3-adios, python3-cdo, python3-harp, python3-sfepy
>>
>>
>> Looking closely at those packages didn't give me any hint as to why they would
>> be uninstallable (not even on armel) so I added a full hint-type hint and did
>> a test run, and I got this:
>>
>> I: [2020-04-09T08:49:35+0000] - Removed 9 of 40 cruft item(s) after the changes
>> I: [2020-04-09T08:49:35+0000] - easy: 55+0: a-10:a-3:a-3:a-3:i-23:m-3:m-3:p-3:s-4
>> I: [2020-04-09T08:49:35+0000] -     * amd64: cantor-backend-scilab, cdo, python3-cdo, ruby-hdfeos5, scilab, scilab-cli, scilab-full-bin, scilab-minimal-bin, scilab-test
>> I: [2020-04-09T08:49:35+0000] -     * arm64: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * armel: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * armhf: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * i386: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * mips64el: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * mipsel: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * ppc64el: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * s390x: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] - FAILED
>>
>> Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a candidate
>> but I would remove it now to finish this) and scilab. Unfortunately after checking
>> with dak, I found that tasksel depends on meta-kde, which depends on cantor, which
>> depends on scilab, which means that scilab is going to need a fix for #955694 in
>> order for this transition to finish.
>
> scilab got fixed, and openmpi became a blocker but also migrated. Some other
> packages received uploads but after hinting them hdf5 was finally able to migrate.

Strictly speaking it wasn't scilab but cantor, the latter downgraded the
scilab dependency to suggests to help resolve this transition blocker.

Many thanks for your help to get hdf5 to migrate!

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
In reply to this post by Gilles Filippini-2
On 4/21/20 11:32 AM, Emilio Pozuelo Monfort wrote:

> On 09/04/2020 11:09, Emilio Pozuelo Monfort wrote:
>> On 09/04/2020 06:17, Sebastiaan Couwenberg wrote:
>>> On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
>>>> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>>>
>>> mpich migrated to testing. hdf5 will need some help to migrate, not all
>>> bad rdeps will be autoremoved eventually.
>>
>> I couldn't really understand what was going on from the normal hint output:
>>
>>     got: 37+0: a-1:a-0:a-15:a-0:i-20:m-0:m-0:p-0:s-1
>>     * armel: cdo, code-saturne, code-saturne-include, harp, libadios-bin, libharp-dev, libharp10, libncarg-bin, libncarg-dev, libncarg0, ncl-ncarg, python3-adios, python3-cdo, python3-harp, python3-sfepy
>>
>>
>> Looking closely at those packages didn't give me any hint as to why they would
>> be uninstallable (not even on armel) so I added a full hint-type hint and did
>> a test run, and I got this:
>>
>> I: [2020-04-09T08:49:35+0000] - Removed 9 of 40 cruft item(s) after the changes
>> I: [2020-04-09T08:49:35+0000] - easy: 55+0: a-10:a-3:a-3:a-3:i-23:m-3:m-3:p-3:s-4
>> I: [2020-04-09T08:49:35+0000] -     * amd64: cantor-backend-scilab, cdo, python3-cdo, ruby-hdfeos5, scilab, scilab-cli, scilab-full-bin, scilab-minimal-bin, scilab-test
>> I: [2020-04-09T08:49:35+0000] -     * arm64: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * armel: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * armhf: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * i386: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * mips64el: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * mipsel: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * ppc64el: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] -     * s390x: cdo, python3-cdo, ruby-hdfeos5
>> I: [2020-04-09T08:49:35+0000] - FAILED
>>
>> Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a candidate
>> but I would remove it now to finish this) and scilab. Unfortunately after checking
>> with dak, I found that tasksel depends on meta-kde, which depends on cantor, which
>> depends on scilab, which means that scilab is going to need a fix for #955694 in
>> order for this transition to finish.
>
> scilab got fixed, and openmpi became a blocker but also migrated. Some other
> packages received uploads but after hinting them hdf5 was finally able to migrate.

It looks like hdf5 didn't actually migrate:

 $ rmadison -s testing hdf5
 hdf5       | 1.10.4+repack-11 | testing    | source

1.10.6+repack-1 is only in unstable.

britney_output/2020/20200421030001.txt.gz shows a bunch of packaged
involved in the transition as accepted, but also that the hint failed.

britney_output/2020/20200421040001.txt.gz shows that hdf5 is not a valid
candidate (or it already migrated).

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
On 4/22/20 11:16 AM, Sebastiaan Couwenberg wrote:

> On 4/21/20 11:32 AM, Emilio Pozuelo Monfort wrote:
>> On 09/04/2020 11:09, Emilio Pozuelo Monfort wrote:
>>> On 09/04/2020 06:17, Sebastiaan Couwenberg wrote:
>>>> On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
>>>>> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>>>>
>>>> mpich migrated to testing. hdf5 will need some help to migrate, not all
>>>> bad rdeps will be autoremoved eventually.
>>>
>>> I couldn't really understand what was going on from the normal hint output:
>>>
>>>     got: 37+0: a-1:a-0:a-15:a-0:i-20:m-0:m-0:p-0:s-1
>>>     * armel: cdo, code-saturne, code-saturne-include, harp, libadios-bin, libharp-dev, libharp10, libncarg-bin, libncarg-dev, libncarg0, ncl-ncarg, python3-adios, python3-cdo, python3-harp, python3-sfepy
>>>
>>>
>>> Looking closely at those packages didn't give me any hint as to why they would
>>> be uninstallable (not even on armel) so I added a full hint-type hint and did
>>> a test run, and I got this:
>>>
>>> I: [2020-04-09T08:49:35+0000] - Removed 9 of 40 cruft item(s) after the changes
>>> I: [2020-04-09T08:49:35+0000] - easy: 55+0: a-10:a-3:a-3:a-3:i-23:m-3:m-3:p-3:s-4
>>> I: [2020-04-09T08:49:35+0000] -     * amd64: cantor-backend-scilab, cdo, python3-cdo, ruby-hdfeos5, scilab, scilab-cli, scilab-full-bin, scilab-minimal-bin, scilab-test
>>> I: [2020-04-09T08:49:35+0000] -     * arm64: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * armel: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * armhf: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * i386: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * mips64el: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * mipsel: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * ppc64el: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * s390x: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] - FAILED
>>>
>>> Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a candidate
>>> but I would remove it now to finish this) and scilab. Unfortunately after checking
>>> with dak, I found that tasksel depends on meta-kde, which depends on cantor, which
>>> depends on scilab, which means that scilab is going to need a fix for #955694 in
>>> order for this transition to finish.
>>
>> scilab got fixed, and openmpi became a blocker but also migrated. Some other
>> packages received uploads but after hinting them hdf5 was finally able to migrate.
>
> It looks like hdf5 didn't actually migrate:
>
>  $ rmadison -s testing hdf5
>  hdf5       | 1.10.4+repack-11 | testing    | source
>
> 1.10.6+repack-1 is only in unstable.
>
> britney_output/2020/20200421030001.txt.gz shows a bunch of packaged
> involved in the transition as accepted, but also that the hint failed.
>
> britney_output/2020/20200421040001.txt.gz shows that hdf5 is not a valid
> candidate (or it already migrated).

Looking at the excuses for the affected packages, I think the following
may need a tpu rebuild as well:

 * h5py       (blocked by sphinx)
 * ncbi-vdb   (unfixed RC bug #952623)
 * bitshuffle (blocked by h5py)

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Sebastiaan Couwenberg
On 4/24/20 6:52 AM, Sebastiaan Couwenberg wrote:

> On 4/22/20 11:16 AM, Sebastiaan Couwenberg wrote:
>> On 4/21/20 11:32 AM, Emilio Pozuelo Monfort wrote:
>>> On 09/04/2020 11:09, Emilio Pozuelo Monfort wrote:
>>>> On 09/04/2020 06:17, Sebastiaan Couwenberg wrote:
>>>>> On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
>>>>>> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>>>>>
>>>>> mpich migrated to testing. hdf5 will need some help to migrate, not all
>>>>> bad rdeps will be autoremoved eventually.
>>>>
>>>> I couldn't really understand what was going on from the normal hint output:
>>>>
>>>>     got: 37+0: a-1:a-0:a-15:a-0:i-20:m-0:m-0:p-0:s-1
>>>>     * armel: cdo, code-saturne, code-saturne-include, harp, libadios-bin, libharp-dev, libharp10, libncarg-bin, libncarg-dev, libncarg0, ncl-ncarg, python3-adios, python3-cdo, python3-harp, python3-sfepy
>>>>
>>>>
>>>> Looking closely at those packages didn't give me any hint as to why they would
>>>> be uninstallable (not even on armel) so I added a full hint-type hint and did
>>>> a test run, and I got this:
>>>>
>>>> I: [2020-04-09T08:49:35+0000] - Removed 9 of 40 cruft item(s) after the changes
>>>> I: [2020-04-09T08:49:35+0000] - easy: 55+0: a-10:a-3:a-3:a-3:i-23:m-3:m-3:p-3:s-4
>>>> I: [2020-04-09T08:49:35+0000] -     * amd64: cantor-backend-scilab, cdo, python3-cdo, ruby-hdfeos5, scilab, scilab-cli, scilab-full-bin, scilab-minimal-bin, scilab-test
>>>> I: [2020-04-09T08:49:35+0000] -     * arm64: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * armel: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * armhf: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * i386: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * mips64el: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * mipsel: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * ppc64el: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] -     * s390x: cdo, python3-cdo, ruby-hdfeos5
>>>> I: [2020-04-09T08:49:35+0000] - FAILED
>>>>
>>>> Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a candidate
>>>> but I would remove it now to finish this) and scilab. Unfortunately after checking
>>>> with dak, I found that tasksel depends on meta-kde, which depends on cantor, which
>>>> depends on scilab, which means that scilab is going to need a fix for #955694 in
>>>> order for this transition to finish.
>>>
>>> scilab got fixed, and openmpi became a blocker but also migrated. Some other
>>> packages received uploads but after hinting them hdf5 was finally able to migrate.
>>
>> It looks like hdf5 didn't actually migrate:
>>
>>  $ rmadison -s testing hdf5
>>  hdf5       | 1.10.4+repack-11 | testing    | source
>>
>> 1.10.6+repack-1 is only in unstable.
>>
>> britney_output/2020/20200421030001.txt.gz shows a bunch of packaged
>> involved in the transition as accepted, but also that the hint failed.
>>
>> britney_output/2020/20200421040001.txt.gz shows that hdf5 is not a valid
>> candidate (or it already migrated).
>
> Looking at the excuses for the affected packages, I think the following
> may need a tpu rebuild as well:
>
>  * h5py       (blocked by sphinx)
>  * ncbi-vdb   (unfixed RC bug #952623)
>  * bitshuffle (blocked by h5py)

Thanks for the many hints and other work to get hdf5 to migrate. It
finally migrated today.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply | Threaded
Open this post in threaded view
|

Bug#954654: transition: hdf5

Emilio Pozuelo Monfort-4
In reply to this post by Sebastiaan Couwenberg
On 22/04/2020 11:16, Sebastiaan Couwenberg wrote:

> On 4/21/20 11:32 AM, Emilio Pozuelo Monfort wrote:
>> On 09/04/2020 11:09, Emilio Pozuelo Monfort wrote:
>>> On 09/04/2020 06:17, Sebastiaan Couwenberg wrote:
>>>> On 4/6/20 12:54 PM, Emilio Pozuelo Monfort wrote:
>>>>> hdf5 is currently blocked from migrating to testing on mpich due to #954244.
>>>>
>>>> mpich migrated to testing. hdf5 will need some help to migrate, not all
>>>> bad rdeps will be autoremoved eventually.
>>>
>>> I couldn't really understand what was going on from the normal hint output:
>>>
>>>     got: 37+0: a-1:a-0:a-15:a-0:i-20:m-0:m-0:p-0:s-1
>>>     * armel: cdo, code-saturne, code-saturne-include, harp, libadios-bin, libharp-dev, libharp10, libncarg-bin, libncarg-dev, libncarg0, ncl-ncarg, python3-adios, python3-cdo, python3-harp, python3-sfepy
>>>
>>>
>>> Looking closely at those packages didn't give me any hint as to why they would
>>> be uninstallable (not even on armel) so I added a full hint-type hint and did
>>> a test run, and I got this:
>>>
>>> I: [2020-04-09T08:49:35+0000] - Removed 9 of 40 cruft item(s) after the changes
>>> I: [2020-04-09T08:49:35+0000] - easy: 55+0: a-10:a-3:a-3:a-3:i-23:m-3:m-3:p-3:s-4
>>> I: [2020-04-09T08:49:35+0000] -     * amd64: cantor-backend-scilab, cdo, python3-cdo, ruby-hdfeos5, scilab, scilab-cli, scilab-full-bin, scilab-minimal-bin, scilab-test
>>> I: [2020-04-09T08:49:35+0000] -     * arm64: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * armel: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * armhf: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * i386: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * mips64el: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * mipsel: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * ppc64el: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] -     * s390x: cdo, python3-cdo, ruby-hdfeos5
>>> I: [2020-04-09T08:49:35+0000] - FAILED
>>>
>>> Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a candidate
>>> but I would remove it now to finish this) and scilab. Unfortunately after checking
>>> with dak, I found that tasksel depends on meta-kde, which depends on cantor, which
>>> depends on scilab, which means that scilab is going to need a fix for #955694 in
>>> order for this transition to finish.
>>
>> scilab got fixed, and openmpi became a blocker but also migrated. Some other
>> packages received uploads but after hinting them hdf5 was finally able to migrate.
>
> It looks like hdf5 didn't actually migrate:
>
>  $ rmadison -s testing hdf5
>  hdf5       | 1.10.4+repack-11 | testing    | source
>
> 1.10.6+repack-1 is only in unstable.
>
> britney_output/2020/20200421030001.txt.gz shows a bunch of packaged
> involved in the transition as accepted, but also that the hint failed.
>
> britney_output/2020/20200421040001.txt.gz shows that hdf5 is not a valid
> candidate (or it already migrated).

ftr, that last part confused me and made me believe that the package had
migrated (since I had been looking at it and had added various hints that should
have made the transition migrate, but obviously something went differently and
it didn't). Since then the transition got entangled with netcdf and pdal, so we
decided to rebuild those two packages in tpu to disentangle them. After a few
more hints to get other rdeps to migrate (some had seen new uploads or were
blocked due to a failing autopkgtest) hdf5 finally migrated along with all its
rdeps.

Cheers,
Emilio