Bug#1067118: nmu: hdf5_1.10.10+repack-3.1

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

During the ongoing 64 bit time_t transition it seems HDF5 should have been
triggered *after* curl. See #1065331.

As I understand it this should be fixed via the following binNMU request:

nmu hdf5_1.10.10+repack-3.1 . ANY . unstable . -m "binNMU to depend on 
libcurl4t64"

Thanks,
_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmX4o2YACgkQ7+hsbH/+
z4N+SQf/bgkEXassUkLIzCVBI5KnjM1uZXxp7tHgDsbPcx/Y769EZXUFSPLWaA3i
1E2ietil02tCgTa1njciUlsqPL6Din/vUbI7zX+Xjs1DfHVPleY56isPNfEQSVVE
qcmQekQvozFzrs5kxhbpkW7ZG9oiMujKclwjS72K3bSbWdORYzkWVkVA8njyEzfk
5ays8yOyzAq0VJ+vshWy7l0EqTkoX/qLsIsyVUHTf6A6Ii/p5Pr37/bB3x11EsGx
vF8fBHY6EvB77clpWVK6EmjiIMxZpZC0dr6wXS4BepOSAPkjoeUuec1KR/HHeFpQ
FPDFnxXVf++eO5U/c1Q3F8wCQ4YWCw==
=F5hi
-END PGP SIGNATURE-

Bug#993825: buster-pu: package hdf5/1.10.6+repack-4+deb11u1

[Gilles Filippini]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Release team,

I'd like to upload a fix for hdf5 1.10.6+repack-4 into stable.

[ Reason ]
This is a fix for RC bug #992068 which makes libhdf5-mpich-dev failing
a piuparts upgrade test.

[ Impact ]
No impact but fixing the bug.

[ Tests ]
Piuparts upgrade test of libhdf5-mpich-dev on the upgrade path
  squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye

[ Risks ]
None.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable
  Couldn't check that myself because piuparts fails to start from any
  suite before stretch on my box.

[ Changes ]
I followed the recommendation from the bug submitter:
> Making the libmpich-dev versioned (buster shipped with 3.3-3 which uses
> the new alternatives scheme) ensures that libmpich-dev gets upgraded
> (or rather installed, kicking out the ancient libmpich1.0-dev from
> squeeze).

Thanks,

_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmE2nEIACgkQ7+hsbH/+
z4Phpwf/XkIdQQfZHt03cw9SPi6xpuavElt2CyHQ3z36yl/tS2XY9YgI3uAUucSh
1lL7pizC4VeSJNDApEGlSQwi4VDvlKuoANGFP3YQjhyogeZoqnfloxqHslYP8gAL
zqSB0nqwSKzu+FEy4QTEddbJUcac7tbWj0szYosiT+ncDxSzH2hystSsV26W1HMu
fqgCTu2hwV3UWoAMruaiRBqrlIIf4Q801dCozFr5Wyz+4CqJNdJN2gmDnezcfF3I
UwUf/h3EMFMqds7X1RFXzkhWKI+DiLRAKh+S7sB2q+gzxWRxTOQOL0BOtk6Lw/7b
H0QMwMmT1sgVVRqSoEokl/pg1OhgyQ==
=2/US
-END PGP SIGNATURE-
diff -Nru hdf5-1.10.6+repack/debian/changelog 
hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog 2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog 2021-08-15 15:56:44.0 +0200
@@ -1,3 +1,11 @@
+hdf5 (1.10.6+repack-4+deb11u1) bullseye; urgency=medium
+
+  [ Andreas Beckmann ]
+  * libhdf5-mpich-dev: bump libmpich-dev dependency to (>= 3.3-3~) (Closes:
+#992068)
+
+ -- Gilles Filippini   Sun, 15 Aug 2021 15:56:44 +0200
+
 hdf5 (1.10.6+repack-4) unstable; urgency=medium
 
   * Revert support for read-only S3 virtual file driver, as it introduced
diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
--- hdf5-1.10.6+repack/debian/control   2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/control   2021-08-15 15:56:44.0 +0200
@@ -480,7 +480,7 @@
  zlib1g-dev,
  libaec-dev,
  libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
  ${misc:Depends}
 Suggests: libhdf5-doc
 Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)
diff -Nru hdf5-1.10.6+repack/debian/control.in 
hdf5-1.10.6+repack/debian/control.in
--- hdf5-1.10.6+repack/debian/control.in2021-06-16 23:57:23.0 
+0200
+++ hdf5-1.10.6+repack/debian/control.in2021-08-11 16:32:44.0 
+0200
@@ -480,7 +480,7 @@
  zlib1g-dev,
  libaec-dev,
  libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
  ${misc:Depends}
 Suggests: libhdf5-doc
 Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)

Bug#969633: transition: json-simple

[Gilles Filippini]

Hi Emilio,

Emilio Pozuelo Monfort a écrit le 20/09/2020 à 18:50 :
> On 06/09/2020 13:38, Gilles Filippini wrote:
>> Emilio Pozuelo Monfort a écrit le 06/09/2020 à 12:19 :
>>> On 06/09/2020 11:53, Gilles Filippini wrote:
>>>> Package: release.debian.org
>>>> Severity: normal
>>>> User: release.debian@packages.debian.org
>>>> Usertags: transition
>>>>
>>>> Hi,
>>>>
>>>> I'd like to transition json-simple 3.1.1 surrently sitting into 
>>>> experimental.
>>>> The name of the library doens't change, but reverse dependencies need a
>>>> binnmu.
>>>
>>> Why is that?
>>
>> Upstream removed an API that was deprecated long ago and introduced a
>> few backward incompatible changes.
> 
> Then it needs a SONAME bump.

There is no such thing in java. I asked the question on the debian-java
list whether to change the binary package's name and it was answered
that it should be avoidable [1]. I eventually chose not to change it
because there are few reverse dependencies.

[1] https://lists.debian.org/debian-java/2020/05/msg00025.html

What do you think?

_g.



signature.asc
Description: OpenPGP digital signature

Bug#969633: transition: json-simple

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 06/09/2020 à 12:19 :
> On 06/09/2020 11:53, Gilles Filippini wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hi,
>>
>> I'd like to transition json-simple 3.1.1 surrently sitting into experimental.
>> The name of the library doens't change, but reverse dependencies need a
>> binnmu.
> 
> Why is that?

Upstream removed an API that was deprecated long ago and introduced a
few backward incompatible changes.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#969633: transition: json-simple

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to transition json-simple 3.1.1 surrently sitting into experimental.
The name of the library doens't change, but reverse dependencies need a
binnmu.

Here is the status for each of these build-rdeps:

biojava4-live   build OK
derby   build OK
h2database  build OK
i2p build OK
jts build OK
mapsforge   build OK
mobile-atlas-creatorbuild OK
mockito build OK
netbeansbuild KO - not in testing
orthanc-imagej  build OK
plm build OK
spatial4j   build OK
spatial4j-0.4   build OK
syndie  build OK
tikabuild KO - not in testing

Since there is no library name change, I'm not sure what to put into the
ben file. Here is an attempt:

Ben file:

title = "json-simple";
is_affected = .depends ~ /libjson-simple-java/ | .build-depends ~ 
/libjson-simple-java/;
is_good = .depends ~ /lbjson-simple-java/;
is_bad = .depends ~ /lbjson-simple-java/;

Thanks in advance for considering.

_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl9UsaAACgkQ7+hsbH/+
z4ONUwf/W8FDPmIaBatEdvExBoeCh5IIudZmWVVvaKScAbr6upt10y8wU876kpfI
B31Cl1XtFvlaiDqVNvuSuzjJ2+nFaHaFZncxG5fI9xl9pWZgkLSFXkOLwEG7f2TK
3WIT3DQqvQATXJqOelVqqKEb4Jo3eenA0NAdrCkTXDHmEJxzwPFVKFpLwr4UsLOy
w87pX3HwJD/q2OYiPMY1WW71dT29Gd9CP22SIXsDQM6wHqeJN5TyzCozcmZH+uAZ
nF2jL8gq372mg0WvnFRrvbrUTkC2p/yf1CWXtuG/p8W/ORoUNfv1DUtlhAQqC+o7
sXiftUHiXfdS6NKSg31TyRNHauaFPw==
=s8ZV
-END PGP SIGNATURE-

Bug#954654: transition: hdf5

[Gilles Filippini]

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: release.debian@packages.debian.org
>> 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-sdkKO - #952623 - Removal from testing on the 10/04/2020
>> xmds2  KO - #938925 - Not in testing
>> ants   KO - Multiple RC bugs - Not in testing
>> siconosKO - #954497 - Removal from testing on the 29/03/2020
>> simpleitk  KO - #949355 - Not in testing
> 
> Sounds good. Go ahead.

Uploaded!

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#954654: transition: hdf5

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
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-sdkKO - #952623 - Removal from testing on the 10/04/2020
xmds2  KO - #938925 - Not in testing
ants   KO - Multiple RC bugs - Not in testing
siconosKO - #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-

Bug#946918: transition: libcgns

[Gilles Filippini]

Hi,

Gilles Filippini a écrit le 21/12/2019 à 18:18 :
> Hi,
> 
> Paul Gevers a écrit le 19/12/2019 à 21:29 :
>> Hi Gilles,
>>
>> On 17-12-2019 23:07, Gilles Filippini wrote:
>>> Paul Gevers a écrit le 17/12/2019 à 22:31 :
>>>>> I'd like to transition libcgns 3.4.0 which has been staging into 
>>>>> experimental
>>>>> for more than a month. There are very few reverse depedencies:
>>>>> * paraview
>>>>> * code-saturne
>>>>> and maybe gmsh which build-depends on libcgns-dev but has no binary 
>>>>> package
>>>>> depending on libcgns3.3.
>>>>> I've built all these packages against libcgns 3.4.0 without issue so far.
>>>>
>>>> Go ahead, thanks.
>>>
>>> Uploaded.
>>
>> paraview FTBFS on mips64el where the same version built before. Maybe
>> you want to have a quick look. Don't worry *too* much about it as the
>> package is only in sid and has armel, armhf and mipsel failing as well
>> already before the transition, so it needs more investigation and a new
>> version already to migrate to testing.
> 
> I've just had a look. It fails with this message:
> E: Build killed with signal TERM after 150 minutes of inactivity
> 
> Building paraview is very demanding on resources, and this failure may
> just be related to the buildd machine it was built on. Is it possible to
> force a build on the same machine it was previously successfully built?
> It is mipsel-sil-01.

I forced a giveback yesterday, using the self service buildd givebacks,
and it worked this time on mipsel-osuosl-02.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#946918: transition: libcgns

[Gilles Filippini]

Hi,

Paul Gevers a écrit le 19/12/2019 à 21:29 :
> Hi Gilles,
> 
> On 17-12-2019 23:07, Gilles Filippini wrote:
>> Paul Gevers a écrit le 17/12/2019 à 22:31 :
>>>> I'd like to transition libcgns 3.4.0 which has been staging into 
>>>> experimental
>>>> for more than a month. There are very few reverse depedencies:
>>>> * paraview
>>>> * code-saturne
>>>> and maybe gmsh which build-depends on libcgns-dev but has no binary package
>>>> depending on libcgns3.3.
>>>> I've built all these packages against libcgns 3.4.0 without issue so far.
>>>
>>> Go ahead, thanks.
>>
>> Uploaded.
> 
> paraview FTBFS on mips64el where the same version built before. Maybe
> you want to have a quick look. Don't worry *too* much about it as the
> package is only in sid and has armel, armhf and mipsel failing as well
> already before the transition, so it needs more investigation and a new
> version already to migrate to testing.

I've just had a look. It fails with this message:
E: Build killed with signal TERM after 150 minutes of inactivity

Building paraview is very demanding on resources, and this failure may
just be related to the buildd machine it was built on. Is it possible to
force a build on the same machine it was previously successfully built?
It is mipsel-sil-01.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#946918: transition: libcgns

[Gilles Filippini]

Hi,

Paul Gevers a écrit le 17/12/2019 à 22:31 :
> Control: tags -1 confirmed
> 
> Hi Gilles,
> 
>> I'd like to transition libcgns 3.4.0 which has been staging into experimental
>> for more than a month. There are very few reverse depedencies:
>> * paraview
>> * code-saturne
>> and maybe gmsh which build-depends on libcgns-dev but has no binary package
>> depending on libcgns3.3.
>> I've built all these packages against libcgns 3.4.0 without issue so far.
> 
> Go ahead, thanks.

Uploaded.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#946918: transition: libcgns

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to transition libcgns 3.4.0 which has been staging into experimental
for more than a month. There are very few reverse depedencies:
* paraview
* code-saturne
and maybe gmsh which build-depends on libcgns-dev but has no binary package
depending on libcgns3.3.
I've built all these packages against libcgns 3.4.0 without issue so far.

Thanks,

_g.

Ben file:

title = "libcgns";
is_affected = .depends ~ "libcgns3.3" | .depends ~ "libcgns3.4";
is_good = .depends ~ "libcgns3.4";
is_bad = .depends ~ "libcgns3.3";


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

Kernel: Linux 5.3.0-2-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/+z4MFAl35RqMACgkQ7+hsbH/+
z4OXMgf+LNyt6PooWImATb2Wai6VyKNj6JibE9BYk9s6r8M1pJVruwsRdKa6MsE7
dJjsdyFTBJsKYvtki7lMMQjXOTuD9Zrj600C5R7dmchv/wRvPkvnBJP0GTTi4oSd
pcMqA2oeMtHHJdQVgAfZ/TwBW30NnPfFoyyH/mwjN+HsUT5JvDFdOhvowBrrmfez
HoMCvf+fNaVJGG2h3LNI06Vt4XuNIpnYANw2GGLxHn/p57kL5ld69WCp7sZRWXL3
tY6eLgjVkH9e8oAnUeZmcLlJyX/xSoQG0lmdrih0JMzQHmn+FXmSKPZwdBnEzjuF
h8m28BPJH1hdswRkI9uhqsNU2cJJKw==
=lrMF
-END PGP SIGNATURE-

Bug#922987: stretch-pu: package cernlib/20061220+dfsg3-4.3

[Gilles Filippini]

Adam D. Barratt a écrit le 20/04/2019 à 23:22 :
> On Sat, 2019-04-20 at 22:55 +0200, Gilles Filippini wrote:
>> Gilles Filippini a écrit le 20/04/2019 à 19:22 :
>>> Adam D. Barratt a écrit le 20/04/2019 à 12:41 :
>>>> On Sat, 2019-04-20 at 10:43 +0100, Adam D. Barratt wrote:
>>>>> On Tue, 2019-04-16 at 19:37 +0200, Gilles Filippini wrote:
>>>>>> Adam D. Barratt a écrit le 14/04/2019 à 22:48 :
>>>>>>> Control: tags -1 + confirmed
>>>>>>>
>>>>>>> On Fri, 2019-02-22 at 17:29 +0100, Gilles Filippini wrote:
>>>>>>>> Because RC bug #922453 affects Stretch as well, I propose
>>>>>>>> a
>>>>>>>> stable
>>>>>>>> update
>>>>>>>> for cernlib. Debdiff attached.
>>>>>>>
>>>>>>> cernlib (20061220+dfsg3-4.3+deb9u1) stable-proposed-
>>>>>>> updates;
>>>>>>> urgency=medium
>>>>>>>
>>>>>>> Please use "stretch" rather than "stable-proposed-updates"
>>>>>>> and go
>>>>>>> ahead.
>>>>>>
>>>>>> Done.
>>>>>
>>>>> Unfortunately, the arm64 build appears to be hitting #863152 in
>>>>> binutils. I'm not sure if there's anything that can be done to
>>>>> work
>>>>> around this in cernlib, but noting it here in any case, as it
>>>>> means
>>>>> that cernlib won't be getting into 9.9.
>>>>
>>>> For the record, if a fix for cernlib can get sorted before the
>>>> 9.9
>>>> window closes later this weekend (e.g. simply disabling PIE on
>>>> arm64
>>>> may be sufficient) then getting the updates in should be OK.
>>>
>>> The cernlib build system is far from easy to understand and patch.
>>> I
>>> don't think I'll be able to find a solution in time for 9.9.
>>
>> I might have been over pessimistic. I found a way to force -no-pie
>> when linking fortran executables. Fix tested on an arm64 porter box.
>> Debdiff attached.
> 
> Great, thanks. Please feel free to upload the new version.

Done.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#922987: stretch-pu: package cernlib/20061220+dfsg3-4.3

[Gilles Filippini]

Gilles Filippini a écrit le 20/04/2019 à 19:22 :
> Adam D. Barratt a écrit le 20/04/2019 à 12:41 :
>> On Sat, 2019-04-20 at 10:43 +0100, Adam D. Barratt wrote:
>>> On Tue, 2019-04-16 at 19:37 +0200, Gilles Filippini wrote:
>>>> Adam D. Barratt a écrit le 14/04/2019 à 22:48 :
>>>>> Control: tags -1 + confirmed
>>>>>
>>>>> On Fri, 2019-02-22 at 17:29 +0100, Gilles Filippini wrote:
>>>>>> Because RC bug #922453 affects Stretch as well, I propose a
>>>>>> stable
>>>>>> update
>>>>>> for cernlib. Debdiff attached.
>>>>>
>>>>> cernlib (20061220+dfsg3-4.3+deb9u1) stable-proposed-updates;
>>>>> urgency=medium
>>>>>
>>>>> Please use "stretch" rather than "stable-proposed-updates" and go
>>>>> ahead.
>>>>
>>>> Done.
>>>
>>> Unfortunately, the arm64 build appears to be hitting #863152 in
>>> binutils. I'm not sure if there's anything that can be done to work
>>> around this in cernlib, but noting it here in any case, as it means
>>> that cernlib won't be getting into 9.9.
>>
>> For the record, if a fix for cernlib can get sorted before the 9.9
>> window closes later this weekend (e.g. simply disabling PIE on arm64
>> may be sufficient) then getting the updates in should be OK.
> 
> The cernlib build system is far from easy to understand and patch. I
> don't think I'll be able to find a solution in time for 9.9.

I might have been over pessimistic. I found a way to force -no-pie when
linking fortran executables. Fix tested on an arm64 porter box. Debdiff
attached.

_g.
diff -Nru cernlib-20061220+dfsg3/debian/changelog 
cernlib-20061220+dfsg3/debian/changelog
--- cernlib-20061220+dfsg3/debian/changelog 2019-02-16 12:17:12.00000 
+0100
+++ cernlib-20061220+dfsg3/debian/changelog 2019-04-20 22:38:53.0 
+0200
@@ -1,3 +1,11 @@
+cernlib (20061220+dfsg3-4.3+deb9u2) stretch; urgency=medium
+
+  * Update patch 304-update-Imake-config-files.dpatch to force -no-pie
+when linking Fortran executables (workaround for #863152 being in the
+way of the previous fix)
+
+ -- Gilles Filippini   Sat, 20 Apr 2019 22:38:53 +0200
+
 cernlib (20061220+dfsg3-4.3+deb9u1) stretch; urgency=medium
 
   * Backport for stretch of the fix for #922453 bringed by 20061220+dfsg3-4.4
diff -Nru 
cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch 
cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch
--- cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch  
2019-02-16 12:17:12.0 +0100
+++ cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch  
2019-04-20 22:38:53.0 +0200
@@ -2002,7 +2002,7 @@
  #endif
  #ifndef ExtraLoadOptions
 -#define ExtraLoadOptions /**/
-+#define ExtraLoadOptions -Wl,-z,relro
++#define ExtraLoadOptions -Wl,-z,relro -no-pie
  #endif
  #ifndef ExtraLoadFlags
  #define ExtraLoadFlags /**/


signature.asc
Description: OpenPGP digital signature

Bug#922987: stretch-pu: package cernlib/20061220+dfsg3-4.3

[Gilles Filippini]

Adam D. Barratt a écrit le 20/04/2019 à 12:41 :
> On Sat, 2019-04-20 at 10:43 +0100, Adam D. Barratt wrote:
>> On Tue, 2019-04-16 at 19:37 +0200, Gilles Filippini wrote:
>>> Adam D. Barratt a écrit le 14/04/2019 à 22:48 :
>>>> Control: tags -1 + confirmed
>>>>
>>>> On Fri, 2019-02-22 at 17:29 +0100, Gilles Filippini wrote:
>>>>> Because RC bug #922453 affects Stretch as well, I propose a
>>>>> stable
>>>>> update
>>>>> for cernlib. Debdiff attached.
>>>>
>>>> cernlib (20061220+dfsg3-4.3+deb9u1) stable-proposed-updates;
>>>> urgency=medium
>>>>
>>>> Please use "stretch" rather than "stable-proposed-updates" and go
>>>> ahead.
>>>
>>> Done.
>>
>> Unfortunately, the arm64 build appears to be hitting #863152 in
>> binutils. I'm not sure if there's anything that can be done to work
>> around this in cernlib, but noting it here in any case, as it means
>> that cernlib won't be getting into 9.9.
> 
> For the record, if a fix for cernlib can get sorted before the 9.9
> window closes later this weekend (e.g. simply disabling PIE on arm64
> may be sufficient) then getting the updates in should be OK.

The cernlib build system is far from easy to understand and patch. I
don't think I'll be able to find a solution in time for 9.9.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#922987: stretch-pu: package cernlib/20061220+dfsg3-4.3

[Gilles Filippini]

Adam D. Barratt a écrit le 14/04/2019 à 22:48 :
> Control: tags -1 + confirmed
> 
> On Fri, 2019-02-22 at 17:29 +0100, Gilles Filippini wrote:
>> Because RC bug #922453 affects Stretch as well, I propose a stable
>> update
>> for cernlib. Debdiff attached.
> 
> cernlib (20061220+dfsg3-4.3+deb9u1) stable-proposed-updates; urgency=medium
> 
> Please use "stretch" rather than "stable-proposed-updates" and go
> ahead.

Done.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#922484: nmu: paw_1:2.14.04.dfsg.2-9.1, mclibs_20061220+dfsg3-3.1, geant321_1:3.21.14.dfsg-11

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 22/02/2019 à 10:08 :
> Control: tags -1 stretch
> 
> On 21/02/2019 23:55, Andreas Beckmann wrote:
>> On Sat, 16 Feb 2019 22:09:11 +0100 Gilles Filippini  wrote:
>>> Now that #922453 is fixed, paw, mclibs and geant321 have to be rebuilt
>>> against this fixed cernlib release.
>>
>> Please binNMU the packages with a "gap" in the binNMU version s.t. this 
>> bug can be fixed by binNMUing in stable, too. The stretch binNMUs need a 
>> fixed cernlib in stretch-pu first of course (no pu request filed, yet).

I've just filed #922987.

>> given that we have these binary versions currently in stretch and sid:
>>
>> paw | 1:2.14.04.dfsg.2-9.1| stable | source, 
>> amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>> paw | 1:2.14.04.dfsg.2-9.1+b2 | unstable   | amd64, 
>> arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>>
>> libherwig59-2-dev   | 20061220+dfsg3-3.1  | stable | amd64, 
>> armel, armhf, i386, mips, mipsel, s390x
>> libherwig59-2-dev   | 20061220+dfsg3-3.1+b2   | unstable   | amd64, 
>> armel, armhf, i386, mips, mipsel, s390x
>>
>> libgeant321-2-dev   | 1:3.21.14.dfsg-11+b2| stable | amd64, 
>> arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>> libgeant321-2-dev   | 1:3.21.14.dfsg-11+b4| unstable   | amd64, 
>> arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>>
>> the following binNMUs should leave the required gap:
>>
>> nmu 4 paw_1:2.14.04.dfsg.2-9.1 . ANY . unstable . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> nmu 4 mclibs_20061220+dfsg3-3.1 . ANY . unstable . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> nmu 6 geant321_1:3.21.14.dfsg-11 . ANY . unstable . -m "rebuild against 
>> fixed cernlib regarding #922453"
> 
> Scheduled.
> 
>> For future reference, the corresponding binNMUs for stretch would be:
>>
>> nmu 3 paw_1:2.14.04.dfsg.2-9.1 . ANY . stretch . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> dw paw_1:2.14.04.dfsg.2-9.1 . ANY . stretch . -m "cernlib-base-dev (>= 
>> 20061220+dfsg3-4.4~deb9u1)
>> nmu 3 mclibs_20061220+dfsg3-3.1 . ANY . stretch . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> dw mclibs_20061220+dfsg3-3.1 . ANY . stretch . -m "cernlib-base-dev (>= 
>> 20061220+dfsg3-4.4~deb9u1)
>> nmu 5 geant321_1:3.21.14.dfsg-11 . ANY . stretch . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> dw geant321_1:3.21.14.dfsg-11 . ANY . stretch . -m "cernlib-base-dev (>= 
>> 20061220+dfsg3-4.4~deb9u1)
> 
> I'll leave those to a SRM. I'm keeping this bug open and tagging it as stretch
> so the bug appears on their radar.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#922987: stretch-pu: package cernlib/20061220+dfsg3-4.3

[Gilles Filippini]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Release Team,

Because RC bug #922453 affects Stretch as well, I propose a stable update
for cernlib. Debdiff attached.

Thanks in advance,

_g.

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

Kernel: Linux 4.18.0-2-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/+z4MFAlxwI3sACgkQ7+hsbH/+
z4PV6gf/bHfCFA1SBEYuUHOejOtRTC7CkFQATm1jxnxgBhDmjnBMar3T9/uMVaoF
ZCEby/0wThqdi3VG59rDH5Pc6up/KWhCkUC1QyKwlOfCC6TC6cxUN+R/oYLJLkmQ
Dx3tNefc9DkI/E0aGcwfKs2xlYDStSrF0JNrSNu7KqFH7tHqDrPXC+vgry3cIWly
0kFJd6qR2YMF5spGLVLyuqIB7PMU2zFiX/Azt6K5SZZpW1pt57YsQKubSbkaACkd
NZMQ47ZCUSMn2gdSUeNGRgNy/LePgpFT3Kr9XaSo6dCnOJBUzyJazMchSgfwYiHw
PTWEFGgssb3JBflYsNPMH3qtxFKLSA==
=d6em
-END PGP SIGNATURE-
diff -Nru cernlib-20061220+dfsg3/debian/changelog 
cernlib-20061220+dfsg3/debian/changelog
--- cernlib-20061220+dfsg3/debian/changelog 2017-01-06 11:22:45.0 
+0100
+++ cernlib-20061220+dfsg3/debian/changelog 2019-02-16 12:17:12.0 
+0100
@@ -1,3 +1,13 @@
+cernlib (20061220+dfsg3-4.3+deb9u1) stable-proposed-updates; urgency=medium
+
+  * Backport for s-p-u of the fix for #922453 bringed by 20061220+dfsg3-4.4
+  * 126-fix-patchy-compile-flags.dpatch 304-update-Imake-config-files.dpatch:
+fix these patches to apply optimization flag -O to fortran modules
+instead of -O2 which generates broken code (closes: #922453; thanks to
+Jacek M. Holeczek )
+
+ -- Gilles Filippini   Sat, 16 Feb 2019 12:17:12 +0100
+
 cernlib (20061220+dfsg3-4.3) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru 
cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch 
cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch
--- cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch   
2013-08-24 11:16:07.0 +0200
+++ cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch   
2019-02-16 12:17:12.0 +0100
@@ -76,7 +76,7 @@
  
 -  PARAMETER   (CHPOF = '-c -O -fno-automatic')
 -  PARAMETER   (CHPOC = '-c -O2 -m486')
-+  PARAMETER   (CHPOF = '-c -g -O2 -fno-automatic')
++  PARAMETER   (CHPOF = '-c -g -O -fno-automatic')
 +  PARAMETER   (CHPOC = '-c -g -O2')
PARAMETER   (CHPOA = ' ')
  
diff -Nru 
cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch 
cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch
--- cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch  
2015-09-09 03:24:30.0 +0200
+++ cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch  
2019-02-16 12:17:12.0 +0100
@@ -1794,7 +1794,7 @@
 +
 +#ifdef AMD64Architecture
 +# ifndef OptimizationLevel
-+#  define OptimizationLevel   -O3
++#  define OptimizationLevel   -O
 +# endif
 +# ifndef OptimizedCDebugFlags
 +#  define OptimizedCDebugFlags  OptimizationLevel

Bug#922484: nmu: paw_1:2.14.04.dfsg.2-9.1, mclibs_20061220+dfsg3-3.1, geant321_1:3.21.14.dfsg-11

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Release team,

Now that #922453 is fixed, paw, mclibs and geant321 have to be rebuilt
against this fixed cernlib release.

nmu paw_1:2.14.04.dfsg.2-9.1 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"
nmu mclibs_20061220+dfsg3-3.1 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"
nmu geant321_1:3.21.14.dfsg-11 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"

Thanks in advance;

_g.

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

Kernel: Linux 4.18.0-2-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/+z4MFAlxoe+wACgkQ7+hsbH/+
z4P8ywf+OdYQS2XYWdGZ9y5bBJoQGT0mQ0zvD+SdFfgAMU9o+91FqhTtxB8jTLd2
QQpkcBgaI+U/PIzKWVea3Tyu2sEzL5sm7J/GWKe5sYOYp3sQSftp+Sz0IRmoXhzA
BHENzlB/L/vs00yJWrMH/h5/t2DH/s99K5dxYfV/V3fA9HbWWuvTmTteQ6ecsOP3
Xr09Vbhh3iuWR1x6yiyTvOETJer9CxyMX+SQSHai6wKYZNP8aKPoVP7QPl4I8goN
B6B7clVuAhTTtDInfTN+0RxHgX2pIuxEoPDJGUxefhY2VJvLnUl/FCaRaneyZx3d
/xsODhYvd5BIO2Hox3GS7jnDa6faeQ==
=ZIna
-END PGP SIGNATURE-

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Gilles Filippini]

Paul Gevers a écrit le 06/01/2019 à 19:34 :
> Hi Adrian,
> 
> On 06-01-2019 19:05, Adrian Bunk wrote:
[...]
>> The root problem is that debci installs cruft packages from unstable.
> 
> Care to elaborate what you mean here? debci doesn't install anything.
> It's apt that installs stuff. Based on a slightly odd configuration put
> in place by autopkgtest on request of debci which got its trigger from
> britney.

See the log for the failing test [1]:
...
Get:78 http://deb.debian.org/debian unstable/main amd64 libmed1v5 amd64 
4.0.0+repack-1 [439 kB]
...

libmed1v5 4.0.0+repack-1 is a *broken*cruft* package picked up by apt
during autopkgtest. If I hadn't uploaded this broken package in the first
place apt would have picked up libmed1v5 3.3.1+repack-4 instead, and
autopkgtest would have been successful.

[1] https://ci.debian.net/data/autopkgtest/testing/amd64/g/gmsh/1651956/log.gz

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please unblock package med-fichier. Is has currently to wait for 43 days
because of an autopkgtest regression against the version of gmsh in testing
(3.0.6+dfsg1-4) [1]. But it succeeds against version 3.0.6+dfsg1-4.1 in
unstable [1] which waiting for med-fichier to migrate [2].

[1] https://ci.debian.net/packages/g/gmsh/
[2] https://qa.debian.org/excuses.php?package=gmsh

Not attaching the debdiff against the package in testing because it is a
different upstream release. Please let me know if you want it anyway.

unblock med-fichier/4.0.0+repack-6

Thanks in advance,

_g.

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

Kernel: Linux 4.14.0-3-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/+z4MFAlww1WwACgkQ7+hsbH/+
z4MmSQgAhrjHW3KmBcajfsMbOI4ARSI9Mn1LmePbtmgM1LjO6/qofo22KjpuIQpf
Ueivx8eG0Wawhy5+ZRnLprIHDyyNEL78F0YRJiuDcKfcrxC3FXCOFs/BFZe3EELq
ABnd8oWpNwZ0TZVWloKZlTjP/hLj45ZHgtfyRreIYe32d11uUTw11rMPOhbX/bOK
2hc7NfR+R+cecXa5Cev70iKq4PaFZCBYlmfVildmlznKUEMAYddm2ZkbWhmbV2HS
IxihavZPFo6wYLJ8ftM4mYcdgQEfjCEB2ME6DYajqdZDSxAfBcPmsxq5aqJM7LN5
nM1akU7fo9Qy2zaerXHbFO2Xf1ylIA==
=sCzW
-END PGP SIGNATURE-

Re: MPICH as default MPI; WAS: MPI debugging workflows

[Gilles Filippini]

Hi,

On 2018-12-07 12:49, Alastair McKinstry wrote:

While it might not look important to be able to scale to 10k+ nodes on
Debian (as none of the top500 machines run Debian)


Some EDF clusters running a custom Debian derivative have been in the 
TOP500 lists since 2012.


_g.

Bug#913837: transition: hdf5

[Gilles Filippini]

Sebastiaan Couwenberg a écrit le 01/12/2018 à 17:23 :
> On 12/1/18 5:16 PM, Gilles Filippini wrote:
>> On Fri, 30 Nov 2018 15:53:29 +0100 Gilles Filippini  wrote:
>>> On 2018-11-30 14:31, Emilio Pozuelo Monfort wrote:
>>>> On 17/11/2018 11:54, Emilio Pozuelo Monfort wrote:
>>>>> Control: tags -1 confirmed
>>>>>
>>>>> On 15/11/2018 21:37, Gilles Filippini wrote:
>>>>>> Package: release.debian.org
>>>>>> Severity: normal
>>>>>> User: release.debian@packages.debian.org
>>>>>> Usertags: transition
>>>>>>
>>>>>> Hi Release Team,
>>>>>>
>>>>>> I hereby request a transition slot for hdf5 1.10.4 currently in 
>>>>>> experimental.
>>>>>>
>>>>>> Ben file:
>>>>>>
>>>>>> title = "hdf5";
>>>>>> is_affected = .depends ~ /libhdf5/ | .build-depends ~ /hdf5/;
>>>>>> is_good = .depends ~ 
>>>>>> /libhdf5-103|libhdf5-openmpi-103|libhdf5-mpich-103/;
>>>>>> is_bad = .depends ~ 
>>>>>> /libhdf5-100|libhdf5-openmpi-100|libhdf5-mpich-100/;
>>>>>>
>>>>>> I've checked the build of all the reverse dependencies against this 
>>>>>> release, and from the 110+ of them, only those - which are not in 
>>>>>> testing - aren't binnmu ready:
>>>>>
>>>>> Go ahead.
>>>>
>>>> gnudatelanguage's autopkgtests fail with the new hdf5/netcdf, which 
>>>> block
>>>> netcdf's testing migration. Can you take a look?
>>>>
>>>> https://ci.debian.net/packages/g/gnudatalanguage/testing/amd64/
>>>
>>> I'll have a look this w-e, but I'm not very optimistic because these 
>>> failures are segmentation faults.
>>> Since gnudatalanguage has a not so high popcon, an option would be to 
>>> temporarily remove it from testing, to gain time to investigate the 
>>> problem.
>>
>> I really don't know how to debug this.
> 
> You shouldn't have to, you're not the maintainer of that package.
> 
>> What I can say is that it isn't related to the current HDF5 1.10.4 
>> transition: I've rebuilt gnudatalanguage against HDF5 
>> 1.10.0-patch1+docs-4+b2 from testing (with netcdf and grib-api rebuilt as 
>> well) and the very same failure occurs, at least for TEST_POINT_LUN:
> 
> gnudatalanguage has been problematic in a prior netcdf transition too.
> 
> I would just file an RC bug for the failing tests and let the maintainer
> take it from there. If they are unable to fix the issue, the package
> will be autoremoved from testing.

I've just opened #915207.

Thanks,

_g.

Bug#913837: transition: hdf5

[Gilles Filippini]

On Fri, 30 Nov 2018 15:53:29 +0100 Gilles Filippini  wrote:
> On 2018-11-30 14:31, Emilio Pozuelo Monfort wrote:
> > On 17/11/2018 11:54, Emilio Pozuelo Monfort wrote:
> >> Control: tags -1 confirmed
> >> 
> >> On 15/11/2018 21:37, Gilles Filippini wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: transition
> >>> 
> >>> Hi Release Team,
> >>> 
> >>> I hereby request a transition slot for hdf5 1.10.4 currently in 
> >>> experimental.
> >>> 
> >>> Ben file:
> >>> 
> >>> title = "hdf5";
> >>> is_affected = .depends ~ /libhdf5/ | .build-depends ~ /hdf5/;
> >>> is_good = .depends ~ 
> >>> /libhdf5-103|libhdf5-openmpi-103|libhdf5-mpich-103/;
> >>> is_bad = .depends ~ 
> >>> /libhdf5-100|libhdf5-openmpi-100|libhdf5-mpich-100/;
> >>> 
> >>> I've checked the build of all the reverse dependencies against this 
> >>> release, and from the 110+ of them, only those - which are not in 
> >>> testing - aren't binnmu ready:
> >> 
> >> Go ahead.
> > 
> > gnudatelanguage's autopkgtests fail with the new hdf5/netcdf, which 
> > block
> > netcdf's testing migration. Can you take a look?
> > 
> > https://ci.debian.net/packages/g/gnudatalanguage/testing/amd64/
> 
> I'll have a look this w-e, but I'm not very optimistic because these 
> failures are segmentation faults.
> Since gnudatalanguage has a not so high popcon, an option would be to 
> temporarily remove it from testing, to gain time to investigate the 
> problem.

I really don't know how to debug this.
What I can say is that it isn't related to the current HDF5 1.10.4 transition: 
I've rebuilt gnudatalanguage against HDF5 1.10.0-patch1+docs-4+b2 from testing 
(with netcdf and grib-api rebuilt as well) and the very same failure occurs, at 
least for TEST_POINT_LUN:

% Compiled module: TEST_POINT_LUN.
% Compiled module: PATH_SEP.
% TEST_POINT_LUN: working in IDL_TMPDIR
% Compiled module: FILE_COPY.
% Compiled module: ESCAPE_SPECIAL_CHAR.
reading 4 times the 1st character of /tmp//file1.txt compress option set to 
0...OK
reading 13 elements at position 7...OK (POINT_LUN 0 then 7)
position status as per fstat() function:
OK: good CUR_PTR returned by fstat().
% Compiled module: ERRORS_CUMUL.
% Compiled module: BANNER_FOR_TESTSUITE.
% Compiled module: GDL_IDL_FL.
% READ_4B_FILE:   NO errors encountered during READ_4B_FILE tests  
reading 4 times the 1st character of /tmp//file1.txt compress option set to 
1...TEST EXITED FROM SIGNAL 11
...
The following tests FAILED:
 69 - test_bug_n000720.pro (Failed)
 93 - test_fft_leak.pro (Failed)
 96 - test_file_delete.pro (Failed)
103 - test_fix.pro (Failed)
106 - test_formats.pro (Failed)
114 - test_hdf5.pro (Failed)
116 - test_idlneturl.pro (Failed)
129 - test_make_dll.pro (Failed)
140 - test_n_tags.pro (Failed)
142 - test_obj_isa.pro (Failed)
144 - test_parse_url.pro (Failed)
150 - test_point_lun.pro (Failed)
166 - test_resolve_routine.pro (Failed)
168 - test_rounding.pro (Failed)
171 - test_save_restore.pro (Failed)
190 - test_total.pro (Failed)
201 - test_zip.pro (Failed)
Errors while running CTest

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#913837: transition: hdf5

[Gilles Filippini]

On 2018-11-30 14:31, Emilio Pozuelo Monfort wrote:

On 17/11/2018 11:54, Emilio Pozuelo Monfort wrote:

Control: tags -1 confirmed

On 15/11/2018 21:37, Gilles Filippini wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi Release Team,

I hereby request a transition slot for hdf5 1.10.4 currently in 
experimental.


Ben file:

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


I've checked the build of all the reverse dependencies against this 
release, and from the 110+ of them, only those - which are not in 
testing - aren't binnmu ready:


Go ahead.


gnudatelanguage's autopkgtests fail with the new hdf5/netcdf, which 
block

netcdf's testing migration. Can you take a look?

https://ci.debian.net/packages/g/gnudatalanguage/testing/amd64/


I'll have a look this w-e, but I'm not very optimistic because these 
failures are segmentation faults.
Since gnudatalanguage has a not so high popcon, an option would be to 
temporarily remove it from testing, to gain time to investigate the 
problem.


BTW the conflicts between the new libhdf package and the old one is 
causing lots
of trouble for the transition, because the two packages are not 
co-installable
and means all or most of the rdeps need to migrate at the same time. I 
noticed
that upstream bumped the SOVERSION for only one shared lib but not the 
others,
and since you ship them all in the same package, that's forcing the 
need for the
Conflicts. Once this transition is over, can you either split the 
shared libs in
separate packages if upstream is not going to keep them in sync, or ask 
upstream

to keep the SOVERSIONs in sync? The latter would be easier.


Oh, I'm sorry about that. Upstream has been quite unpredictable with the 
SOVERSIONs. I'll discuss that with them.


Thanks,

_g.

Bug#913837: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 17/11/2018 à 11:54 :
> Control: tags -1 confirmed
> 
> On 15/11/2018 21:37, Gilles Filippini wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hi Release Team,
>>
>> I hereby request a transition slot for hdf5 1.10.4 currently in experimental.
>>
>> Ben file:
>>
>> title = "hdf5";
>> is_affected = .depends ~ /libhdf5/ | .build-depends ~ /hdf5/;
>> is_good = .depends ~ /libhdf5-103|libhdf5-openmpi-103|libhdf5-mpich-103/;
>> is_bad = .depends ~ /libhdf5-100|libhdf5-openmpi-100|libhdf5-mpich-100/;
>>
>> I've checked the build of all the reverse dependencies against this release, 
>> and from the 110+ of them, only those - which are not in testing - aren't 
>> binnmu ready:
> 
> Go ahead.

Uploaded!

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#913837: transition: hdf5

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Release Team,

I hereby request a transition slot for hdf5 1.10.4 currently in experimental.

Ben file:

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

I've checked the build of all the reverse dependencies against this release, 
and from the 110+ of them, only those - which are not in testing - aren't 
binnmu ready:

hinge  KO (FTBFS unrelated to hdf5; #909763; not in 
testing)
blasr  KO (FTBFS unrelated to hdf5; #906811; not in 
testing)
igvKO (FTBFS unrelated to hdf5; #895765; not in 
testing)
ovito  KO (FTBFS unrelated to hdf5; 3 RC bugs; not in 
testing)
psi4   KO (FTBFS unralated to hdf5; 2 RC bugs; not in 
testing)
xmds2  KO (FTBFS unrelated to hdf5; #904669; not in 
testing)
syrthesKO (RC #891993; not in testing)
ants   KO (FTBFS unrelated to hdf5; 4 RC bugs; not in 
testing)
odin   KO (FTBFS unrelated to hdf5; #865955; not in 
testing)
caffe-contrib  KO (build-depends on gcc-6; not in testing)

Thanks in advance,

_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlvt2PkACgkQ7+hsbH/+
z4MWQwf+M/ZjVRLh2W0KfZUWJLVCxkO971OvqxH3HKsZUtiofDjtCKHjVC6kibzY
8WPUGk1zbwivS0ybffiDCqecZdk0uPNO6YA3otwDX4v08p0xasqG30CLvnHqH+lY
SkqBlVauHAlWhZ4GyVDOM4rOBhvu1jBQr2Rifh9wkjB9JrRtomx8+7quiD9MoeRt
v/YR420AtYCxk8zXKFcYJiBYx/Ja5ZSiqTFDh1hqvL7XhEbfCymM+t0u/umwtz5s
aQR4xmaYY5JL9X9LxYDW8zuLOrXkAlgsQN3iuC95e8x/Rtt/8SkWqUolaa/pq+zJ
scfd4pLJH84T7PTE7+yPjlw3hfXTCw==
=ynFk
-END PGP SIGNATURE-

Bug#904273: nmu: openmpi_3.1.1.real-4 mpich_3.3~b2-7

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

Now that gcc-8 is the default on most architectures, please trigger a binnmu
for openmpi and mpich:

nmu openmpi_3.1.1.real-4 . ANY -kfreebsd-amd64 -kfreebsd-i386 . unstable . -m 
"Rebuild against gcc-8 (gfortran-8 transition)"
nmu mpich_3.3~b2-7 . ANY -kfreebsd-amd64 -kfreebsd-i386 . unstable . -m 
"Rebuild against gcc-8 (gfortran-8 transition)"

This is to avoid such build errors:
   USE MPI
  1
Fatal Error: Cannot read module file 'mpi.mod' opened at (1), because it was 
created by a different version of GNU Fortran

Thanks in advance,

_g.

Bug#898765: nmu: eccodes_2.7.3-2

[Gilles Filippini]

On 2018-05-16 09:41, Alastair McKinstry wrote:

On 15/05/2018 18:54, Gilles Filippini wrote:


Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

eccodes binary packages were built by the maintainer for arch amd64,
and it seems he used a GCC version different from 7.3.0 because 
building

metview on amd64 with default GCC FTBFS with:
/<>/src/libMvMacroApi/macro_api_f90.f90:23:6:

use grib_api
   1
Fatal Error: Cannot read module file 'grib_api.mod' opened at (1), 
because it was created by a different version of GNU Fortran


I did build eccodes (2.7.3-2) with gfortran 8, but I did so
deliberately to provide the compatible mod file needed to test the
ECMWF / meteo stack with gcc / g++ / gfortran 8.
metview is now (5.0.1-3) also compiled with gfortran-8 and compiles
successfully. See the changelogs / diffs for the packages
(https://salsa.debian.org/science-team/eccodes, etc)


I am rebuilding locally all HDF5 reverse dependencies against HDF5 
1.10.2

currently in experimental to check about its transition status and
metview FTBFS because of this. IMHO you should conduct such experiments
into experimental to prevent side effects into unstable / testing.

Thanks,

_g.

Bug#898765: nmu: eccodes_2.7.3-2

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

eccodes binary packages were built by the maintainer for arch amd64,
and it seems he used a GCC version different from 7.3.0 because building
metview on amd64 with default GCC FTBFS with:
/<>/src/libMvMacroApi/macro_api_f90.f90:23:6:

   use grib_api
  1
Fatal Error: Cannot read module file 'grib_api.mod' opened at (1), because it 
was created by a different version of GNU Fortran

grib_api.mod is part of libeccodes-dev.

Please rebuild eccodes with default GCC for amd64.

nmu eccodes_2.7.3-2 . amd64 . unstable . -m "Rebuild with GCC 7.3.0"

Thanks,

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

Kernel: Linux 4.14.0-3-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/+z4MFAlr7HrEACgkQ7+hsbH/+
z4O6vQgAoK0Fe5NaRi+E1GColbYnGR3NglSowy9KnBUnF2WYBHTHLqMZ5wj2FtB3
hrpWITijkJSb4sVIIIHHwkyrU4tTHpCd2UCPyJ9E2xkPjmLb2S6X7CA7R2WWkg7B
nW27L0+gJBNWBqlc/7Y8PsOIWPm9VvsEOb2bXtG6hTF7C/840KFAtJxeYY/Sg0Ry
YU+rDU4TI3Ld0mxGP/pcIxZrBwiHzEqDLSjIXR7dWK6XyyndP9nVowGOtX24eEmO
3JriEPZHU55rlLL3P53xMSEats1+x3x5MxOLNDUjlkY5gxhim05mzE62ckqfkwIW
8gP9bkVn+4EkCW9I97l3twTlX202YQ==
=cWWO
-END PGP SIGNATURE-

Bug#872642: stretch-pu: package hdf5/1.10.0-patch1+docs-3

[Gilles Filippini]

Adam D. Barratt a écrit le 27/02/2018 à 20:57 :
> On Tue, 2018-02-27 at 20:53 +0100, Gilles Filippini wrote:
>> Hi,
>>
>> On Sun, 27 Aug 2017 14:03:38 +0100 "Adam D. Barratt"
>> <a...@adam-barratt.org.uk> wrote:
>>> Control: tags -1 + confirmed
>>>
>>> On Sat, 2017-08-19 at 19:20 +0200, Gilles Filippini wrote:
>>>> HDF5 in stretch is affected by RC bug #871506 now fixed in
>>>> unstable and
>>>> testing.
>>>> I have prepared release 1.10.0-patch1+docs-3+deb9u1 for stretch
>>>> with the
>>>> very same fix as in unstable. Debdiff attached.
>>>
>>> Please go ahead.
>>
>> I've just got reminded this pending upload request I had completely
>> forgotten about, because I missed the 'go' which occurred during my
>> holidays.
>> Since it is 6 months old now, could you please confirm that the 'go'
>> is
>> still granted?
> 
> Sure.

Done.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#872642: stretch-pu: package hdf5/1.10.0-patch1+docs-3

[Gilles Filippini]

Hi,

On Sun, 27 Aug 2017 14:03:38 +0100 "Adam D. Barratt"
<a...@adam-barratt.org.uk> wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-08-19 at 19:20 +0200, Gilles Filippini wrote:
> > HDF5 in stretch is affected by RC bug #871506 now fixed in unstable and
> > testing.
> > I have prepared release 1.10.0-patch1+docs-3+deb9u1 for stretch with the
> > very same fix as in unstable. Debdiff attached.
> 
> Please go ahead.

I've just got reminded this pending upload request I had completely
forgotten about, because I missed the 'go' which occurred during my
holidays.
Since it is 6 months old now, could you please confirm that the 'go' is
still granted?

Thanks, and sorry about this delay.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#872642: stretch-pu: package hdf5/1.10.0-patch1+docs-3

[Gilles Filippini]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

HDF5 in stretch is affected by RC bug #871506 now fixed in unstable and
testing.
I have prepared release 1.10.0-patch1+docs-3+deb9u1 for stretch with the
very same fix as in unstable. Debdiff attached.
I'd appreciate if you consider allowing this upload to stretch.
Thanks in advance,

_g.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 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)
diff -Nru hdf5-1.10.0-patch1+docs/debian/changelog 
hdf5-1.10.0-patch1+docs/debian/changelog
--- hdf5-1.10.0-patch1+docs/debian/changelog2016-12-05 09:27:39.0 
+0100
+++ hdf5-1.10.0-patch1+docs/debian/changelog2017-08-19 09:33:00.0 
+0200
@@ -1,3 +1,9 @@
+hdf5 (1.10.0-patch1+docs-3+deb9u1) stretch; urgency=medium
+
+  * debian/rules: fix javahelper invocation (closes: #871506)
+
+ -- Gilles Filippini <p...@debian.org>  Sat, 19 Aug 2017 09:33:00 +0200
+
 hdf5 (1.10.0-patch1+docs-3) unstable; urgency=medium
 
   * Enable openmpi flavor on hppa (closes: #833457)
diff -Nru hdf5-1.10.0-patch1+docs/debian/rules 
hdf5-1.10.0-patch1+docs/debian/rules
--- hdf5-1.10.0-patch1+docs/debian/rules2016-12-05 09:27:39.0 
+0100
+++ hdf5-1.10.0-patch1+docs/debian/rules2017-08-18 13:01:20.0 
+0200
@@ -107,7 +107,7 @@
 # No java >= 1.7 on hppa and hurd-i386
 ifeq (,$(filter $(DEB_HOST_ARCH),hppa hurd-i386))
 SERIAL_FLAGS += --enable-java
-DH_HELPERS = --with-javahelper
+DH_HELPERS = --with javahelper
 install_jni := install_jni
 dh_install_java := dh_install_java
 PACKAGES_java := libhdf5-java libhdf5-jni

Bug#842177: Bug#847974: xmds2: FTBFS in stretch

[Gilles Filippini]

Control: reassign 847974 octave
Control: retitle 847974 octave: wrong size for octave_hdf5_id wrt hdf5 1.10
Control: affects 847974 + src:xmds2

Adrian Bunk a écrit le 13/01/2017 à 21:48 :
> On Mon, Dec 12, 2016 at 05:42:37PM +, Santiago Vila wrote:
>> Package: src:xmds2
>> Version: 2.2.2+dfsg-2
>> Severity: serious
>>
>> Dear maintainer:
>>
>> I tried to build this package in stretch with "dpkg-buildpackage -A"
>> (which is what the "Arch: all" autobuilder would do to build it)
>> but it failed:
>> ...
>> warning: the size of octave_hdf5_id is smaller than the size of HDF5 hid_t
>> warning: called from
>> lorenz.m at line 2 column 3
>> HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
>>   #000: ../../../src/H5G.c line 464 in H5Gopen2(): not a location
>> major: Invalid arguments to routine
>> minor: Inappropriate type
>>   #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
>> major: Invalid arguments to routine
>> minor: Bad value
>> ...
[snip]
> What happened was the hdf5 transition.
> 
> Gilles, you seem to have somehow missed xmds2 in your transition 
> planning?

Indeed; xmds2 wasn't reported by ben with my hdf5 transition config file. Sorry 
about that.
Actually the problem lies in octave where type octave_hdf5_id must be adapted 
to the new hid_t size (int64_t).

Patch proposal coming soon.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#850183: stretch-ignore tag for RC bug #844134 against scilab

[Gilles Filippini]

Package: release.debian.org
Severity: normal

Hi Release Team,

Would you agree to tag #844134 (scilab segfaults with TSX) stretch-ignore since 
TSX is about to be disabled for stretch [1][2]?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134#32
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850182

Many thanks in advance,

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit le 04/12/2016 à 12:36 :
> Emilio Pozuelo Monfort a écrit le 03/12/2016 à 12:26 :
>> On 01/12/16 19:38, Emilio Pozuelo Monfort wrote:
>>> On 01/12/16 19:32, Gilles Filippini wrote:
>>>> Gilles Filippini a écrit le 28/11/2016 à 10:05 :
>>>>> Emilio Pozuelo Monfort a écrit le 27/11/2016 à 23:52 :
>>>>>> On 27/11/16 23:21, Gilles Filippini wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>>>>>>>>> Yes, this is looking very good, so I'm acking it. But please don't 
>>>>>>>>>> upload just
>>>>>>>>>> yet, I'll give you the go in a few days when things are a bit calmer 
>>>>>>>>>> (there are
>>>>>>>>>> just too many transitions at the moment).
>>>>>>>
>>>>>>> Any news on this side? I'm waiting after the transition to upload a new
>>>>>>> release of the package which will have to go through the NEW queue
>>>>>>> because of new binary packages for the java bindings.
>>>>>>
>>>>>> Go ahead.
>>>>>
>>>>> Release 1.10.0-patch1+docs-1 uploaded to unstable.
>>>>
>>>> No binnmu so far. Is there anything preventing the transition?
>>>> I think there is no need to wait for sh4 and powerpcspe builds: they're
>>>> unsuccessful since release 1.8.16.
>>>
>>> I'm waiting for the buildds to catch up after I scheduled the xserver 
>>> binNMU on
>>> mips* yesterday and the remaining boost1.62 ones earlier today.
>>>
>>> I'll likely schedule these later today or tomorrow.
>>
>> That's done. Please file RC bugs for packages that failed to build.
> 
> libsis-jhdf5-java #842815
> mpb   #846923
> slurm-llnl#828549
> trilinos  #815725
> labplot   BD-Unsinstallable
> ruby-hdfeos5  #846353
> insighttoolkit4   Building
> magic++   #846920
> minc-toolsNeeds a new binNMU now that libminc is built
> vtk6  #846372

Emilio, could you please give a second try at binnmu-ing minc-tools?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 03/12/2016 à 12:26 :
> On 01/12/16 19:38, Emilio Pozuelo Monfort wrote:
>> On 01/12/16 19:32, Gilles Filippini wrote:
>>> Gilles Filippini a écrit le 28/11/2016 à 10:05 :
>>>> Emilio Pozuelo Monfort a écrit le 27/11/2016 à 23:52 :
>>>>> On 27/11/16 23:21, Gilles Filippini wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>>>>>>>> Yes, this is looking very good, so I'm acking it. But please don't 
>>>>>>>>> upload just
>>>>>>>>> yet, I'll give you the go in a few days when things are a bit calmer 
>>>>>>>>> (there are
>>>>>>>>> just too many transitions at the moment).
>>>>>>
>>>>>> Any news on this side? I'm waiting after the transition to upload a new
>>>>>> release of the package which will have to go through the NEW queue
>>>>>> because of new binary packages for the java bindings.
>>>>>
>>>>> Go ahead.
>>>>
>>>> Release 1.10.0-patch1+docs-1 uploaded to unstable.
>>>
>>> No binnmu so far. Is there anything preventing the transition?
>>> I think there is no need to wait for sh4 and powerpcspe builds: they're
>>> unsuccessful since release 1.8.16.
>>
>> I'm waiting for the buildds to catch up after I scheduled the xserver binNMU 
>> on
>> mips* yesterday and the remaining boost1.62 ones earlier today.
>>
>> I'll likely schedule these later today or tomorrow.
> 
> That's done. Please file RC bugs for packages that failed to build.

libsis-jhdf5-java   #842815
mpb #846923
slurm-llnl  #828549
trilinos#815725
labplot BD-Unsinstallable
ruby-hdfeos5#846353
insighttoolkit4 Building
magic++ #846920
minc-tools  Needs a new binNMU now that libminc is built
vtk6#846372

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit le 28/11/2016 à 10:05 :
> Emilio Pozuelo Monfort a écrit le 27/11/2016 à 23:52 :
>> On 27/11/16 23:21, Gilles Filippini wrote:
>>> Hi,
>>>
>>> Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>>>>> Yes, this is looking very good, so I'm acking it. But please don't 
>>>>>> upload just
>>>>>> yet, I'll give you the go in a few days when things are a bit calmer 
>>>>>> (there are
>>>>>> just too many transitions at the moment).
>>>
>>> Any news on this side? I'm waiting after the transition to upload a new
>>> release of the package which will have to go through the NEW queue
>>> because of new binary packages for the java bindings.
>>
>> Go ahead.
> 
> Release 1.10.0-patch1+docs-1 uploaded to unstable.

No binnmu so far. Is there anything preventing the transition?
I think there is no need to wait for sh4 and powerpcspe builds: they're
unsuccessful since release 1.8.16.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 27/11/2016 à 23:52 :
> On 27/11/16 23:21, Gilles Filippini wrote:
>> Hi,
>>
>> Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>>>> Yes, this is looking very good, so I'm acking it. But please don't upload 
>>>>> just
>>>>> yet, I'll give you the go in a few days when things are a bit calmer 
>>>>> (there are
>>>>> just too many transitions at the moment).
>>
>> Any news on this side? I'm waiting after the transition to upload a new
>> release of the package which will have to go through the NEW queue
>> because of new binary packages for the java bindings.
> 
> Go ahead.

Release 1.10.0-patch1+docs-1 uploaded to unstable.
Thanks!

_g.




signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Hi,

Emilio Pozuelo Monfort a écrit le 06/11/2016 à 16:20 :
>>> Yes, this is looking very good, so I'm acking it. But please don't upload 
>>> just
>>> yet, I'll give you the go in a few days when things are a bit calmer (there 
>>> are
>>> just too many transitions at the moment).

Any news on this side? I'm waiting after the transition to upload a new
release of the package which will have to go through the NEW queue
because of new binary packages for the java bindings.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Control: block -1 by 843040 842815

Emilio Pozuelo Monfort a écrit le 05/11/2016 à 17:29 :
> Control: tags -1 confirmed
> 
> On 04/11/16 14:45, Gilles Filippini wrote:
>> Gilles Filippini a écrit le 02/11/2016 à 19:05 :
>>> Hi,
>>>
>>> Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
>>> remainder is:
>>> * shogun  FTBFS unrelated to hdf5 - not in testing - #809290
>>> * tessa   FTBFS unrelated to hdf5 - not in testing - #817690
>>> * aster   FTBFS unrelated to hdf5 - not in testing - #837915
>>> * deal.ii BD uninstallable - not in testing
>>> * odinFTBFS unrelated to hdf5 - not in testing - #835746
>>> * libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
>>>   will need some more time because part of this java wrapper library
>>>   is now shipped with the HDF5 source tree
>>> * yorick-hdf5 #842817 - temporary fix uploaded to experimental
>>> * pytablesalmost done - FTBFS on big endian arches
>>>
>>> IMO the only showstopper is now pytables, which will hopefully resolve
>>> in the coming days.
>>
>> Update:
>> * yorick-hdf5 #842817 - final fix uploaded to experimental
>> * pytablesAffected by #843040 - Tested patch pending
>>
>> There isn't any blocker left but libsis-jhdf5-java which has a very low
>> popcon and no reverse dependencies. Can we agree for a transition slot
>> before the freeze?
> 
> Yes, this is looking very good, so I'm acking it. But please don't upload just
> yet, I'll give you the go in a few days when things are a bit calmer (there 
> are
> just too many transitions at the moment).
> 
> And please mark any remaining bugs as blocking this one.

Done, excepted for the 'not in testing' ones. Unless you'd want these
marked as well?

Thx,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit le 02/11/2016 à 19:05 :
> Hi,
> 
> Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
> remainder is:
> * shogun  FTBFS unrelated to hdf5 - not in testing - #809290
> * tessa   FTBFS unrelated to hdf5 - not in testing - #817690
> * aster   FTBFS unrelated to hdf5 - not in testing - #837915
> * deal.ii BD uninstallable - not in testing
> * odinFTBFS unrelated to hdf5 - not in testing - #835746
> * libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
>   will need some more time because part of this java wrapper library
>   is now shipped with the HDF5 source tree
> * yorick-hdf5 #842817 - temporary fix uploaded to experimental
> * pytablesalmost done - FTBFS on big endian arches
> 
> IMO the only showstopper is now pytables, which will hopefully resolve
> in the coming days.

Update:
* yorick-hdf5 #842817 - final fix uploaded to experimental
* pytablesAffected by #843040 - Tested patch pending

There isn't any blocker left but libsis-jhdf5-java which has a very low
popcon and no reverse dependencies. Can we agree for a transition slot
before the freeze?

Thanks in advance,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

Hi,

Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
remainder is:
* shogun  FTBFS unrelated to hdf5 - not in testing - #809290
* tessa   FTBFS unrelated to hdf5 - not in testing - #817690
* aster   FTBFS unrelated to hdf5 - not in testing - #837915
* deal.ii BD uninstallable - not in testing
* odinFTBFS unrelated to hdf5 - not in testing - #835746
* libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
  will need some more time because part of this java wrapper library
  is now shipped with the HDF5 source tree
* yorick-hdf5 #842817 - temporary fix uploaded to experimental
* pytablesalmost done - FTBFS on big endian arches

IMO the only showstopper is now pytables, which will hopefully resolve
in the coming days.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-28 14:12, Gilles Filippini wrote:

Status update:
insighttoolkit4: hdf5 libmincpatch provided via #842342


And:
ants: hdf5 insighttoolkit4OK

There is only pytables remaining on the way now

Thanks,

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-26 19:12, Gilles Filippini wrote:

On 2016-10-26 19:03, Sebastiaan Couwenberg wrote:

On 10/26/2016 06:46 PM, Gilles Filippini wrote:
I've checked the build of every reverse dependencies. These few ones 
are of concern:

* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no 
reverse dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon 
about 300 - no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - 
rather low popcon
* ants : in progress; build depends on insighttoolkit4 - raher low 
popcon


From the above packages, the only real concern is pytables. A 
discussion is ongoing on debian-science@d.o, and I'm confident we'll 
find a solution before the Stretch freeze.


pytables does have several reverse dependencies, who in turn have
several reverse dependencies too. pytables in the dependency chain of
geopandas, having it removed from stretch would be very sad.


Ooops, sorry, I didn't noticed that. Actually I checked weeks ago and
didn't remember there were reverse depends. My bad.
But as said above, I'm confident we'll find a solution for pytables
before the Strtch freeze. It would be removed from testing only for a
while.


insighttoolkit4 is in the dependency chain of otb, and like pytables
having it removed from stretch would be very sad. Even more than 
pytables.


I've successfully tested today a full insighttoolkit4 build for
unstable on a stronger box than mine. I'll rebuild tomorrow against
hdf5-1.10. I'm rather confident about this one too.


Status update:
insighttoolkit4: hdf5 libmincpatch provided via #842342

Thanks,

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

On 2016-10-26 19:03, Sebastiaan Couwenberg wrote:

On 10/26/2016 06:46 PM, Gilles Filippini wrote:
I've checked the build of every reverse dependencies. These few ones 
are of concern:

* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no 
reverse dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon 
about 300 - no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - 
rather low popcon
* ants : in progress; build depends on insighttoolkit4 - raher low 
popcon


From the above packages, the only real concern is pytables. A 
discussion is ongoing on debian-science@d.o, and I'm confident we'll 
find a solution before the Stretch freeze.


pytables does have several reverse dependencies, who in turn have
several reverse dependencies too. pytables in the dependency chain of
geopandas, having it removed from stretch would be very sad.


Ooops, sorry, I didn't noticed that. Actually I checked weeks ago and 
didn't remember there were reverse depends. My bad.
But as said above, I'm confident we'll find a solution for pytables 
before the Strtch freeze. It would be removed from testing only for a 
while.



insighttoolkit4 is in the dependency chain of otb, and like pytables
having it removed from stretch would be very sad. Even more than 
pytables.


I've successfully tested today a full insighttoolkit4 build for unstable 
on a stronger box than mine. I'll rebuild tomorrow against hdf5-1.10. 
I'm rather confident about this one too.


Thanks,

_g.

Bug#842177: transition: hdf5

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Release Team,

I hereby request a transition slot for hdf5 1.10 currently in experimental. 
This release ships major changes and has its soname bumped from 10 to 100.

Ben file:

title = "hdf5";
is_affected = .depends ~ /libhdf5.*-10([^0]|$)/ | .depends ~ /libhdf5.*-100/;
is_good = .depends ~ /libhdf5.*-100/;
is_bad = .depends ~ /libhdf5.*-10([^0]|$)/;


I've checked the build of every reverse dependencies. These few ones are of 
concern:
* libsis-jhdf5-java : unmaintained upstream - low popcon
* pytables : doesn't support new hdf5 API - popcon about 3000 - no reverse 
dependencies
* yorick-hdf5 : desing flaw - no support for 64bits integers - popcon about 300 
- no reverse dependencies
* insighttoolkit4 : in progress; looking for a box with enough RAM - rather low 
popcon
* ants : in progress; build depends on insighttoolkit4 - raher low popcon

- From the above packages, the only real concern is pytables. A discussion is 
ongoing on debian-science@d.o, and I'm confident we'll find a solution before 
the Stretch freeze.


Full report:
===[ Dependency level 0 ]=
hdf5:   binnmu OK
nanopolish: binnmu OK
octave-communications:  binnmu OK
===[ Dependency level 1 ]=
chemps2: hdf5   patch provided via #841954
field3d: hdf5   binnmu OK
freefem++: hdf5 binnmu OK
h5py: hdf5  binnmu OK
h5utils: hdf5   binnmu OK
hdf-eos5: hdf5  binnmu OK
ismrmrd: hdf5   patch provided via #841959
jhdf: hdf5  binnmu OK
libcgns: hdf5   binnmu OK
libgpiv: hdf5   patch provided via #841962
libmatio: hdf5  binnmu OK
libmstoolkit: hdf5  binnmu OK
libpdl-io-hdf5-perl: hdf5   patch provided via #841963
libsis-jhdf5-java: hdf5 KO hard coded hid_t as jint all over 
the source; upstream site dead (http://wiki-bsse.ethz.ch/)
libvigraimpex: hdf5 binnmu OK
mapsembler2: hdf5   binnmu OK
med-fichier: hdf5   patch provided via #841964
meep: hdf5  binnmu OK
meep-lam4: hdf5 binnmu OK
meep-mpi-default: hdf5  binnmu OK
meep-mpich2: hdf5   binnmu OK
meep-openmpi: hdf5  binnmu OK
mpb: hdf5   binnmu OK
ncbi-vdb: hdf5  binnmu OK
netcdf: hdf5binnmu OK
nexus: hdf5 binnmu OK
octave: hdf5binnmu OK
opengm: hdf5binnmu OK
pbseqlib: hdf5  binnmu OK
pytables: hdf5  KO - doesn't support hdf5-1.10 yet
r-cran-hdf5: hdf5   binnmu OK
seer: hdf5  binnmu OK
shark: hdf5 binnmu OK
shogun: hdf5FTBFS unrelated to hdf5 - not in 
testing - #809290
silo-llnl: hdf5 binnmu OK
slurm-llnl: hdf5binnmu OK
stimfit: hdf5   binnmu OK
tessa: hdf5 FTBFS unrelated to hdf5 - not in 
testing - #817690
trilinos: hdf5  binnmu OK
xdmf: hdf5  binnmu OK
yorick-hdf5: hdf5   KO Yorick doesn't support 64bits 
integers (hid_t)
===[ Dependency level 2 ]=
adios: hdf5 netcdf  binnmu OK
aster: hdf5 med-fichier FTBFS unrelated to hdf5 - not in 
testing - #837915
blasr: hdf5 pbseqlibbinnmu OK
cmor: hdf5 netcdf   binnmu OK
code-saturne: hdf5 libcgns med-fichier  binnmu OK
comet-ms: libmstoolkit  binnmu OK
deal.ii: hdf5 netcdf trilinos   BD uninstallable - not in testing
gdal: hdf5 netcdf   binnmu OK
grads: hdf5 netcdf  binnmu OK
grib-api: hdf5 netcdf   binnmu OK
labplot: hdf5 netcdfbinnmu OK
libminc: hdf5 netcdfpatch provided via #841970
mathgl: hdf5 octave binnmu OK
nco: netcdf binnmu OK
ncview: netcdf  binnmu OK
netcdf4-python: hdf5 netcdf binnmu OK
octave-netcdf: netcdf   binnmu OK
ovito: hdf5 netcdf  binnmu OK
paraview: hdf5 netcdf xdmf  binnmu OK
psi4: chemps2 hdf5  binnmu OK
pygpiv: hdf5 libgpivbinnmu OK
python-shogun: hdf5 shogun 

Bug#841961: nmu: ocaml_4.02.3-7

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please rebuild ocaml against the pie-enabled compiler chain, to fix an FTBFS of 
scilab package:

ocamlopt -o modelicac -I ./src/modelica_compiler -I ./src/xml2modelica  
nums.cmxa ./src/modelica_compiler/parseTree.cmx ./src/modelica_compiler/linenu
m.cmx ./src/modelica_compiler/parser.cmx ./src/modelica_compiler/lexer.cmx 
./src/modelica_compiler/precompilation.cmx ./src/modelica_compiler/compilat
ion.cmx ./src/modelica_compiler/instantiation.cmx 
./src/modelica_compiler/graphNodeSet.cmx 
./src/modelica_compiler/symbolicExpression.cmx ./src/modeli
ca_compiler/squareSparseMatrix.cmx ./src/modelica_compiler/bipartiteGraph.cmx 
./src/modelica_compiler/hungarianMethod.cmx ./src/modelica_compiler/caus
alityGraph.cmx ./src/modelica_compiler/optimization.cmx 
./src/modelica_compiler/xMLCodeGeneration.cmx 
./src/modelica_compiler/optimizingCompiler.cmx .
/src/modelica_compiler/scicosCodeGeneration.cmx 
./src/modelica_compiler/scicosOptimizingCompiler.cmx
/usr/bin/ld: /usr/lib/ocaml/libasmrun.a(fail.o): relocation R_X86_64_32 against 
symbol `caml_exn_Failure' can not be used when making a shared object;
 recompile with -fPIC
/usr/bin/ld: /usr/lib/ocaml/libasmrun.a(roots.o): relocation R_X86_64_32 
against symbol `caml_frametable' can not be used when making a shared object;
 recompile with -fPIC
...

nmu ocaml_4.02.3-7 . ANY . unstable . -m "rebuild with pie-enabled compiler 
chain"

Thanks in advance,

_g.

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmoGAAoJEO/obGx//s+DxK0H/jgiHLrcx0gT0N6hfGuwrMO2
mvHmCcLGZKnLmDrkZzgIq+pPtC3qjjlPtBeR+VhvkCc3uPTVpHqZDil2lXmDA8sN
m+klsGk5pWiF1mxeMM37+/ts8JY6Dk+VQXzahBilNH13t21MXZnx3dfygLH/1bDq
3qQLvt8aKQ5UuhvzT/Fr/COXfuNGXsRL0sStUYlFOpg7raJNysQ6mZFXZqexlI+Y
IoUur2okpt57OJP5P7SrK1O8ciAHXb2JnhET2lxj2VmavHMmX0hfTAArsDwYMA0R
gSXyO4GaLZRXjcSazV69P/5MyGHg10yKevSSGI4JBKUAKt9g36/SBo5KW40nSks=
=4TOF
-END PGP SIGNATURE-

Bug#841956: nmu: boost1.61_1.61.0+dfsg-3

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please rebuild boost1.61 against the pie-enabled compiler chain, to fix this 
FTBFS of psi4 package:

[100%] Linking CXX executable ../../../bin/psi4
cd /<>/builddir/src/bin/psi4 && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/psi4.dir/link.txt --verbose=1
/usr/bin/c++   -DRESTRICT=__restrict__ -Xlinker -export-dynamic -fPIC 
-std=c++11 -fopenmp -O2 -g -DNDEBUG   
CMakeFiles/psi4_objlib.dir/export_psio.cc.o 
CMakeFiles/psi4_objlib.dir/export_mints.cc.o 
CMakeFiles/psi4_objlib.dir/psi_stop.cc.o 
CMakeFiles/psi4_objlib.dir/export_functional.cc.o 
CMakeFiles/psi4_objlib.dir/export_oeprop.cc.o 
CMakeFiles/psi4_objlib.dir/export_plugins.cc.o 
CMakeFiles/psi4_objlib.dir/export_blas_lapack.cc.o 
CMakeFiles/psi4_objlib.dir/export_benchmarks.cc.o 
CMakeFiles/psi4_objlib.dir/export_efp.cc.o 
CMakeFiles/psi4_objlib.dir/export_cubeprop.cc.o 
CMakeFiles/psi4_objlib.dir/clean.cc.o 
CMakeFiles/psi4_objlib.dir/create_new_plugin.cc.o 
CMakeFiles/psi4_objlib.dir/script.cc.o 
CMakeFiles/psi4_objlib.dir/set_memory.cc.o 
CMakeFiles/psi4_objlib.dir/read_options.cc.o 
CMakeFiles/psi4_objlib.dir/export_libparallel.cc.o 
CMakeFiles/versioned_code.dir/version.cc.o 
CMakeFiles/versioned_code.dir/python.cc.o 
CMakeFiles/versioned_code.dir/psi_start.cc.o CMakeFiles/versioned_code.dir
 /psi4.cc.o  -o ../../../bin/psi4 -rdynamic -lutil -lm -lrt -ldl -lpython2.7 
-Wl,--whole-archive ../../../lib/libadc.a ../../../lib/libccdensity.a 
../../../lib/libccenergy.a ../../../lib/libcceom.a ../../../lib/libcchbar.a 
../../../lib/libcclambda.a ../../../lib/libccresponse.a 
../../../lib/libccsort.a ../../../lib/libcctransort.a 
../../../lib/libcctriples.a ../../../lib/libdcft.a ../../../lib/libdetci.a 
../../../lib/libdfmp2.a ../../../lib/libdfocc.a ../../../lib/libefp.a 
../../../lib/libfindif.a ../../../lib/libfisapt.a ../../../lib/libfnocc.a 
../../../lib/libmcscf.a ../../../lib/libmints_wrapper.a ../../../lib/libmrcc.a 
../../../lib/libocc.a ../../../lib/liboptking.a ../../../lib/libpsimrcc.a 
../../../lib/libsapt.a ../../../lib/libscf.a ../../../lib/libscfgrad.a 
../../../lib/libthermo.a ../../../lib/libtransqt2.a ../../../lib/libdmrg.a 
../../../lib/lib3index.a ../../../lib/libciomr.a ../../../lib/libdiis.a 
../../../lib/libdisp.a ../../../lib/libdpd.a ../../../lib/libefp_solver.a .
 ./../../lib/libfock.a ../../../lib/libfunctional.a -Wl,--whole-archive 
../../../lib/libiwl.a -Wl,--no-whole-archive ../../../lib/libmints.a 
../../../lib/libmoinfo.a ../../../lib/liboptions.a ../../../lib/libparallel.a 
../../../lib/libparallel2.a ../../../lib/libplugin.a 
../../../lib/libsapt_solver.a ../../../lib/libscf_solver.a 
../../../lib/libthce.a ../../../lib/libtrans.a ../../../lib/libpsi4util.a 
../../../lib/libpsio.a ../../../lib/libPsiUtil.a ../../../lib/libqt.a 
../../../lib/libcubeprop.a ../../../lib/libinterface_libefp.a 
-Wl,--no-whole-archive -Wl,-Bstatic -lboost_filesystem -lboost_python 
-lboost_regex -lboost_serialization -lboost_system -lboost_timer -lboost_chrono 
-lboost_thread -lboost_date_time -lboost_atomic -Wl,-Bdynamic -lpthread 
-llapack -lblas -lpython2.7 -lblas -llapack -lint -lderiv -lutil -ldl -lrt -lm 
/usr/lib/x86_64-linux-gnu/libchemps2.so -lchemps2 
/usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5.so -lsz -lz -lpthread -lm 
-lpython2.7 -ldl -Wl,-rpath,/usr/l
 ib/x86_64-linux-gnu/hdf5/serial/lib 
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(operations.o):
 relocation R_X86_64_32S against symbol 
`_ZN5boost6detail15sp_counted_base7destroyEv' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(path.o):
 relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(list.o):
 relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(dict.o):
 relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
...

nmu boost1.61_1.61.0+dfsg-3 . ANY . unstable . -m "Rebuild with the pie-enabled 
compiler chain"

Thanks in advance,

_g.
- -- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDmTGAAoJEO/obGx//s+D7rMIAKhXQ/RkLEhaVqksNirXeoKt

Bug#841940: nmu: antlr_2.7.7+dfsg-7

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The antlr package currently in unstable isn't built with -fPIC, leading to FTFS 
for some of its reverse dependencies, such as nco:
libtool: link: g++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o .libs/ncap2 Invoke.o ncap2.o ncap2_utl.o sdo_utl.o sym_cls.o 
fmc_cls.o fmc_all_cls.o fmc_gsl_cls.o prs_cls.o NcapVar.o NcapVarVector.o 
ncoLexer.o ncoParser.o ncoTree.o nco_gsl.o  -L../nco 
/<>/src/nco/.libs/libnco.so -lantlr -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5_hl -lhdf5 -lpthread -lsz -lz 
-ldl -lnetcdf /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -lgsl -lgslcblas -lm 
-ludunits2 -pthread -fopenmp -Wl,-rpath -Wl,/usr/lib/nco
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libantlr.a(ASTFactory.o): 
relocation R_X86_64_32S against symbol `_ZTVN5antlr10ASTFactoryE' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libantlr.a(BaseAST.o): 
relocation R_X86_64_32S against symbol `_ZNK5antlr7BaseAST13getFirstChildEv' 
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libantlr.a(BitSet.o): 
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
...

Binnmu-ing seems sufficient to fix that (tested localy on my box).

nmu antlr_2.7.7+dfsg-7 . ANY . unstable . -m "rebuild with -fPIC"

Thanks in advance,

_g.

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDj76AAoJEO/obGx//s+Dar0IAJbQSE3DicxF9tGYOx8xgQKU
ZPqfLcdDMhHOZS6Q+MXrc1Ft3Ol24QuHKFrZNPGBI8sbNgQR1i32YykgaU9IkrOj
esmviFXXhEy+WnjcKyGEG8AL0CIc/atsTjV0U4M7aehTapkDVucRwzfHYEXcCCeY
sC5Xdhe60/iyOhL8TbmeeT1dExM7zAUNv7HJ6D4zFZq/fJxsqKoYdrkleG/PJ/5e
8JnF3UrhTH9au1MIZUHXZ5inCD5n5Kcb2nIprSfK1+TtfDTMRNxrnInYQvN7N0QL
XG1w0TftNCmIsVtxyaVdEyKmkwR4Oo+ko+81BzZt465h4OHHK1a2uU9Y/IRP9os=
=JPC4
-END PGP SIGNATURE-

Bug#841929: nmu: libctl_3.2.2-2

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

A rebuild of libctl seems sufficiant to fix #837568:
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libctlgeom.a(geom.o):
> relocation R_X86_64_32 against `.rodata.str1.1' can not be used when
> making a shared object; recompile with -fPIC

nmu libctl_3.2.2-2 . ANY . unstable . -m "Rebuild with -fPIC (closes: #837568)"

Thanks in advance,

_g.

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYDh1ZAAoJEO/obGx//s+D9XAH/3flPuyLSVyDEB2ZUlPvJJiR
qM3eET/9UWyX+uzQhiJ+mctP7FFiULTc81p5ifFSbjW69QL6XW7N0gxbnHSkZjGo
XKaq/m4Gn7wo9aIHgkfEgJr04DB/e2TxJ0M3lQcQHAZaofbnZNpsXD1gM/2S0JJx
6M2wZ11uzZmXOtTfqcZzT0OJXhZRVEMwtsjLCU7/Zd1MJxe23URFDEdheaTkk3nu
l0iaBhaL9aYlZHEf6hZgqb0te07Zn+1dQuYEFYqSbuzOdqD4Ira4YEB6X8L7s2Kn
aP/91GXWnGdcN5dvR5t8zdx7ZDE6vpJ9b+62ttAT7bZkfqcHmcP9VTZYmnJ6evY=
=MUbc
-END PGP SIGNATURE-

Bug#812573: nmu: libaec_0.3.2-1

[Gilles Filippini]

On Mon, 25 Jan 2016 09:27:14 +0100 Gilles Filippini <p...@debian.org> wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> 
> Despite successful buildlog [0], libaec binary packages are missing
> for arch x32. Please rebuild them.
> 
> [0] 
> https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417
> 
> nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing in 
> archive"

This is the case for archs ppc64 and sparc64 as well. Then this binnmu request 
becomes:

nmu libaec_0.3.2-1 . ppc64 sparc64 x32 . unstable . -m "rebuild for x32, ppc64, 
and sparc64 because missing in archive"

Thanks,
_g.

> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#812573: nmu: libaec_0.3.2-1

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Despite successful buildlog [0], libaec binary packages are missing
for arch x32. Please rebuild them.

[0] 
https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417

nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing in 
archive"

Thanks,

_g.

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWpdxiAAoJEO/obGx//s+DguIH/2m9xf67xiBpRDD+bdD0Pt2R
K+OJZO/2H3l2WRs9mn+etSR+upIZGEBSjU27sd88J4Aauj2ozVEQcrtJmvqOKV11
YjTX4nrD/DztEdc84JEFWJDXbF5aDoqg4iuO46jdsZI+4bX/CfKcv5uxkM6qxPPd
Ptdzy87OZ7lURQ3IrhmrmaBN/SKcxgxrkJKbOkKebcB0saslOgPXY3E+DorME40+
ZE+KsvaPikN37VgCrpSodXlyQIWNGkcIZYT1mKsGXXsnv9uAI/OepuuiCCfswhdJ
ZqByzOJRPGZcas48G0uHhlgsdoBH6WmRNLG+FbcL4kS8YThGjCwlZWbuMAGeHOQ=
=YJPU
-END PGP SIGNATURE-

Bug#805825: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 24/11/2015 16:03 :
> Control: tags -1 confirmed
> 
> On 22/11/15 21:34, Gilles Filippini wrote:
>> With release 1.8.16 of hdf5 currently in experimental, the soname of
>> the C++ library was bumped:
>> libhdf5-cpp-10 -> libhdf5-cpp-11
>>
>> This triggers a mini-transition. There are only two rdepends on
>> libhdf5-cpp-10. I've tested a rebluid of both against libhdf5 1.8.16:
>> * blasr  binnmu OK
>> * insighttoolkit4binnmu OK (sid only)
> 
> Go ahead.

Release 1.8.16+docs-1 uploaded to unstable.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#805825: transition: hdf5

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

With release 1.8.16 of hdf5 currently in experimental, the soname of
the C++ library was bumped:
libhdf5-cpp-10 -> libhdf5-cpp-11

This triggers a mini-transition. There are only two rdepends on
libhdf5-cpp-10. I've tested a rebluid of both against libhdf5 1.8.16:
* blasr binnmu OK
* insighttoolkit4   binnmu OK (sid only)

Ben file:

title = "hdf5";
is_affected = .depends ~ "libhdf5-cpp-10" | .depends ~ "libhdf5-cpp-11";
is_good = .depends ~ "libhdf5-cpp-11";
is_bad = .depends ~ "libhdf5-cpp-10";

Thanks in advance,

_g.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#798256: transition: hdf5

[Gilles Filippini]

Le 2015-10-06 11:07, Emilio Pozuelo Monfort a écrit :

On 05/10/15 23:02, Gilles Filippini wrote:

Please tell me in case of anything left blocking the transition.


There's #801060.


This one is really annoying. Scilab could build on ppc64el, but it would 
be unusable anyway because of #798652, blocked by #779482.
Then I'm in favor of removing scilab from ppc64el rather than providing 
a useless fix. What do you think?


Thanks,

_g.

Bug#798256: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 05/10/2015 17:59 :
> Control: tag 798256 791067 + pending
> 
> On 05/10/15 17:13, Gilles Filippini wrote:
>> Hi,
>>
>> On Wed, 30 Sep 2015 10:04:48 +0200 Gilles Filippini <p...@debian.org> wrote:
>>> Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
>>>> Control: tags -1 confirmed
>>>>
>>>> On 21/09/15 13:08, Gilles Filippini wrote:
>>>>> Ping.
>>>>
>>>> I think we can do this now. Go for it.
>>>
>>> Release 1.8.15-patch1+docs-4 upploaded to unstable.
>>
>> I have pending fixes for FTBFS on hppa, ppc64 and hurd-i386.
> 
> Looks like hppa and hurd built hdf5 a few hours ago.
> 
>> Should I
>> upload them now or do you think this isn't needed for the transition to
>> complete?
> 
> This isn't needed because those architectures aren't in testing. Note that 
> hdf5
> already migrated, but now we're waiting for the rest of the rdeps to migrate 
> so
> the old libhdf5-8 can get removed. Should happen in the next few days if there
> aren't any problems.

Great.
Please tell me in case of anything left blocking the transition.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Hi,

On Wed, 30 Sep 2015 10:04:48 +0200 Gilles Filippini <p...@debian.org> wrote:
> Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
> > Control: tags -1 confirmed
> > 
> > On 21/09/15 13:08, Gilles Filippini wrote:
> >> Ping.
> > 
> > I think we can do this now. Go for it.
> 
> Release 1.8.15-patch1+docs-4 upploaded to unstable.

I have pending fixes for FTBFS on hppa, ppc64 and hurd-i386. Should I
upload them now or do you think this isn't needed for the transition to
complete?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
> Control: tags -1 confirmed
> 
> On 21/09/15 13:08, Gilles Filippini wrote:
>> Ping.
> 
> I think we can do this now. Go for it.

Release 1.8.15-patch1+docs-4 upploaded to unstable.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Ping.

Thanks,

_g.

On Mon, 07 Sep 2015 14:11:17 +0200 Gilles Filippini <p...@debian.org> wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> Now that the GCC-5 rebuilt hdf5 1.8.13 has made its way into testing I
> kindly request a transition slot for release 1.8.15 which comes with a
> soname bump (libhdf5-8 -> libhdf5-10).
> 
> hdf5 1.8.15 sits in experimental since june and was built against GCC-5.
> Out the 65+ affected packages reported by ben only 5 arent't binnmu
> ready:
> 
> fw4spl:
> #797475, #797481 - FTBFS unrelated to hdf5
> sid only
> 
> mapsembler2:
> #797526 - FTBFS with GCC-5
> Low popcon - no rdepends
> 
> gnudatalanguage:
> waiting for plplot - #789619
> sid only
> 
> feel++:
> #777848 - FTBFS with GCC-5
> sid only
> 
> insighttoolkit4:
> #797387 - FTBFS unrelated to HDF5
> sid only
> 
> 
> Ben file:
> 
> title = "hdf5";
> is_affected = .depends ~ /libhdf5.*-8/ | .depends ~ /libhdf5.*-10/;
> is_good = .depends ~ /libhdf5.*-10/;
> is_bad = .depends ~ /libhdf5.*-8/;
> 
> Thanks in advance,
> 
> _g.
> 
> 
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.1.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



signature.asc
Description: OpenPGP digital signature

Bug#798256: transition: hdf5

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Now that the GCC-5 rebuilt hdf5 1.8.13 has made its way into testing I
kindly request a transition slot for release 1.8.15 which comes with a
soname bump (libhdf5-8 -> libhdf5-10).

hdf5 1.8.15 sits in experimental since june and was built against GCC-5.
Out the 65+ affected packages reported by ben only 5 arent't binnmu
ready:

fw4spl:
#797475, #797481 - FTBFS unrelated to hdf5
sid only

mapsembler2:
#797526 - FTBFS with GCC-5
Low popcon - no rdepends

gnudatalanguage:
waiting for plplot - #789619
sid only

feel++:
#777848 - FTBFS with GCC-5
sid only

insighttoolkit4:
#797387 - FTBFS unrelated to HDF5
sid only


Ben file:

title = "hdf5";
is_affected = .depends ~ /libhdf5.*-8/ | .depends ~ /libhdf5.*-10/;
is_good = .depends ~ /libhdf5.*-10/;
is_bad = .depends ~ /libhdf5.*-8/;

Thanks in advance,

_g.


- -- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJV7X7bAAoJEO/obGx//s+DYnMH/3aEhuC52YJETIDQHlgQGfOt
9rnup4O1a58is7U/SnrEjL9r3dB6Y7Qoj6/N+Kk0TB5UqPOeTVyfI9VqmJYxtwOo
SbR10NPngsvRUvDs/1So9y2Yyp98BSYAb9HiNw37Lzhhssh8TeMUcHMHDUIS61kL
WEzZ7dXd6HCCX15dAPux2BzYunTAjQuwMj8OEb+/Gp1pEaYISjuiagxI8h/rx8wi
UpdXAxS2F0ehLxFiEo+fgKtPEqb37Vk4q8mYX/ubBNGOomFDNL/dtNhHJO1tt9/c
g3oYoT7gLXqOb1P9f9t/WA5Puh2LJKTcNQQ+AyJ2s1FYG7WWwmgPzaGKM3sDKFU=
=aZzq
-END PGP SIGNATURE-

Bug#791067: hdf5: library transition may be needed when GCC 5 is the default

[Gilles Filippini]

Julien Cristau a écrit le 03/09/2015 07:26 :
> On Thu, Sep  3, 2015 at 01:26:35 +0200, Gilles Filippini wrote:
> 
>> So where does this 'MUST NOT' come from just now that all that work is over?
>>
> It comes from me wanting to get gcc-defaults migrated this week.  Which
> is incompatible with getting all hdf5 reverse depends rebuilt.  It would
> probably have been fine a month ago when this started, but not now.

One month ago was family vacation time. Anyway, if the gcc-default
transition is to take place this week I guess the libhdf5-10 transition
can wait.

Consider that hdf5 1.8.13 in unstable is GCC-5 ready since it has no
more C++ rdepends left in testing after your removal of fw4spl and
insighttoolkit4 yesterday.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#791067: hdf5: library transition may be needed when GCC 5 is the default

[Gilles Filippini]

Julien Cristau a écrit le 02/09/2015 17:56 :
> On Wed, Sep  2, 2015 at 14:49:18 +0200, Sebastiaan Couwenberg wrote:
> 
>> On 02-09-15 14:37, Gilles Filippini wrote:
>>> Gilles Filippini a écrit le 28/08/2015 00:12 :
>>>> Sebastiaan Couwenberg a écrit le 27/08/2015 10:17 :
>>>>> I suggest to reassign the hdf5 transition issue back to 
>>>>> release.debian.org, because I would also like to see a single
>>>>> hdf5 transition instead of two (I made the same decisions for
>>>>> netcdf & geos).
>>>>
>>>> Yes, I'll do that *after* having the rdeps checked to avoid
>>>> useless ping pong game. I've started tracking progress on
>>>> titanpad[1] in case anybody wants to help.
>>>>
>>>> [1] <https://titanpad.com/gpirV5ouad>
>>>
>>> I've tested a rebuild of all 68 rdepends reported on the auto-hdf5 
>>> transition page [1]. Only 5 of them aren't binnmu OK:
>>>
>>> [...]
>>>
>>> To me, HDF5 1.8.15 is now transition ready.
>>
>> Thanks for your work preparing the hdf5 transition, I'd say upload to
>> unstable as soon as possible. We should have done hdf5 before netcdf.
>>
> Does anything use the c++ hdf5 lib in Debian nowadays?  Last cycle it
> didn't have any rdeps.

AFAICS, there is only fw4spl and libinsighttoolkit4.7.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#791067: hdf5: library transition may be needed when GCC 5 is the default

[Gilles Filippini]

Gilles Filippini a écrit le 02/09/2015 18:14 :
> Julien Cristau a écrit le 02/09/2015 17:56 :
>> On Wed, Sep  2, 2015 at 14:49:18 +0200, Sebastiaan Couwenberg wrote:
>>
>>> On 02-09-15 14:37, Gilles Filippini wrote:
>>>> Gilles Filippini a écrit le 28/08/2015 00:12 :
>>>>> Sebastiaan Couwenberg a écrit le 27/08/2015 10:17 :
>>>>>> I suggest to reassign the hdf5 transition issue back to 
>>>>>> release.debian.org, because I would also like to see a single
>>>>>> hdf5 transition instead of two (I made the same decisions for
>>>>>> netcdf & geos).
>>>>>
>>>>> Yes, I'll do that *after* having the rdeps checked to avoid
>>>>> useless ping pong game. I've started tracking progress on
>>>>> titanpad[1] in case anybody wants to help.
>>>>>
>>>>> [1] <https://titanpad.com/gpirV5ouad>
>>>>
>>>> I've tested a rebuild of all 68 rdepends reported on the auto-hdf5 
>>>> transition page [1]. Only 5 of them aren't binnmu OK:
>>>>
>>>> [...]
>>>>
>>>> To me, HDF5 1.8.15 is now transition ready.
>>>
>>> Thanks for your work preparing the hdf5 transition, I'd say upload to
>>> unstable as soon as possible. We should have done hdf5 before netcdf.
>>>
>> Does anything use the c++ hdf5 lib in Debian nowadays?  Last cycle it
>> didn't have any rdeps.
> 
> AFAICS, there is only fw4spl and libinsighttoolkit4.7.

and blasr (I previously only checked in testing).

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#791067: hdf5: library transition may be needed when GCC 5 is the default

[Gilles Filippini]

Julien Cristau a écrit le 02/09/2015 20:57 :
> Hrm.  Do I see correctly that hdf5 1.8.15 bumps SONAME of the C library?
> If so, that MUST NOT be uploaded to unstable before the C++ fun is over.
> If a transition is needed for the C++ lib, that must be done separately
> and ahead of the switch to 1.8.15.

You see correctly. And I see nothing contradictory with the directions
given by Matthias:
>  - If a library transition is needed, please prepare for the change.
>Rename the library package, append "v5" to the name of the package
>(e.g. libfoo2 -> libfoo2v5). *Such a change can be avoided, if you
>have a soversion bump and you upload this version instead of the
>renamed package*.

The soname bump was stated the 18th of july in this bug log [1] and I've
spend quite some hours checking that every rdepends builds fine. The
only few FTBFSs are either sid only, or low popcon with no rdepends, and
anyway not caused by hdf5 at all [2]

[1] 
[2] 

So where does this 'MUST NOT' come from just now that all that work is over?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#781124: unblock (pre-approval): icedtea-web/1.5-2+deb8u1

[Gilles Filippini]

Niels Thykier a écrit le 28/03/2015 19:59 :
 Control: tags -1 confirmed moreinfo
 
 On 2015-03-24 21:53, Gilles Filippini wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: unblock

 Hello Release team,

 I've prepared a NMU for the icedtea-web package to fix #778631. It is
 the very same trivial fix already uploaded to unstable with release
 1.5.2-1.1. Please see the proposed patch attached.
 
 Ack, please go ahead with this tpu upload.

Uploaded. Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#781124: unblock (pre-approval): icedtea-web/1.5-2+deb8u1

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Release team,

I've prepared a NMU for the icedtea-web package to fix #778631. It is
the very same trivial fix already uploaded to unstable with release
1.5.2-1.1. Please see the proposed patch attached.

Thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJVEc7EAAoJEO/obGx//s+D9nIH/3B619xB8oc39C6XyYxB2ZMx
rEqItKefT8xI9cjbgam5dqmdFh3bbZdIHjgKAY0/dMMw6IIw4z/Gvdt0cf6qksjM
9QQbTQ0fi0jGXnqoNQvf9/0VWrVsfyny/Em9Pu/Kjx1m3J4rUfOojKtEo3jpU3Ak
UcY/4oIEq++munl4TmNJllROFc5swUq9lqquCxjAGrC9y11P91kIRL19OFYFLCit
WOjPJiiaoNyODRGawvYYig4hZefDtmwrnumt5Xi/oNIkU+0rLQRdWboE3WI74VpL
3e9t9hzTfRuKXP7NmwIkORDYZdQja1TzNACYvBbyyLSzhN3kZ2bqYZU6fhtqfSM=
=e+Ug
-END PGP SIGNATURE-
diff -Nru icedtea-web-1.5/debian/changelog icedtea-web-1.5/debian/changelog
--- icedtea-web-1.5/debian/changelog	2014-06-30 15:07:00.0 +0200
+++ icedtea-web-1.5/debian/changelog	2015-03-24 21:26:31.0 +0100
@@ -1,3 +1,11 @@
+icedtea-web (1.5-2+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix alternatives handling in icedtea-netx.postinst.in
+(closes: #778631).
+
+ -- Gilles Filippini p...@debian.org  Sun, 22 Mar 2015 18:22:24 +0100
+
 icedtea-web (1.5-2) unstable; urgency=medium
 
   * Build-depend on iceweasel-dev. Closes: #752838.
diff -Nru icedtea-web-1.5/debian/icedtea-netx.postinst.in icedtea-web-1.5/debian/icedtea-netx.postinst.in
--- icedtea-web-1.5/debian/icedtea-netx.postinst.in	2013-09-28 10:00:29.0 +0200
+++ icedtea-web-1.5/debian/icedtea-netx.postinst.in	2015-03-22 18:20:37.0 +0100
@@ -20,7 +20,7 @@
 fi
 if [ -n $multiarch ]  [ -n $2 ]; then
 for i in $tools; do
-if [ -z $(update-alternatives --list $i 2/dev/null | grep ^$basedir/) ]; then
+if [ -z $(update-alternatives --list $i 2/dev/null | grep ^$base7dir/) ]; then
 update_alternatives=y
 break
 fi

Bug#775151: unblock: code-saturne/3.3.2-3

[Gilles Filippini]

Niels Thykier a écrit le 13/01/2015 17:12 :
 Control: tags -1 moreinfo
 
 On 2015-01-12 01:37, Gilles Filippini wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: unblock

 Please unblock package code-saturne

 Version 3.3.2-3 fixes RC bug #775107 which makes code-saturne mostly
 unusable on all archs but one because an arch dependent file
 (cs_config.py) was shipped with an arch=all package.

 The fix moves cs_config.py to code-saturne-include which is arch=any.

 Please find attache the debdiff against version 3.3.2-2.

 unblock code-saturne/3.3.2-3

 Thanks,

 _g.

 [...]
 
 Hi,
 
 Thanks for providing this patch.
 
 Unfortunately, I suspect is missing a versioned Breaks and Replace
 on code-saturne-data (from code-saturne-include).  This is customary
 (and required) for moving files between two packages and it does not
 seem to be present in the debdiff you provided.  Without this, we would
 simply trade one RC bug for another.

You're right /o\
Fixed and uploaded as version 3.3.2-4.

New debdiff against 3.3.2-2 attached.

Thanks!

_g.

diff -Nru code-saturne-3.3.2/debian/changelog 
code-saturne-3.3.2/debian/changelog
--- code-saturne-3.3.2/debian/changelog 2014-09-23 13:12:19.0 +0200
+++ code-saturne-3.3.2/debian/changelog 2015-01-13 19:28:31.0 +0100
@@ -1,3 +1,19 @@
+code-saturne (3.3.2-4) unstable; urgency=medium
+
+  * Team upload.
+  * debian/control: add missing Breaks / Replaces to fix the previous
+change (cf. Policy section 7.6.1).
+
+ -- Gilles Filippini p...@debian.org  Tue, 13 Jan 2015 19:28:29 +0100
+
+code-saturne (3.3.2-3) unstable; urgency=medium
+
+  * Team upload.
+  * Move arch-dependant script cs_config.py from code-saturne-data to
+code-saturne-include (Closes: #775107).
+
+ -- Gilles Filippini p...@debian.org  Sun, 11 Jan 2015 16:01:45 +0100
+
 code-saturne (3.3.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru code-saturne-3.3.2/debian/code-saturne-include.install 
code-saturne-3.3.2/debian/code-saturne-include.install
--- code-saturne-3.3.2/debian/code-saturne-include.install  2014-09-22 
21:39:38.0 +0200
+++ code-saturne-3.3.2/debian/code-saturne-include.install  2015-01-11 
15:14:41.0 +0100
@@ -1,2 +1,2 @@
 debian/tmp/usr/include
-
+debian/tmp/usr/lib/python*/dist-packages/code_saturne/cs_config.py
diff -Nru code-saturne-3.3.2/debian/control code-saturne-3.3.2/debian/control
--- code-saturne-3.3.2/debian/control   2014-09-23 11:53:33.0 +0200
+++ code-saturne-3.3.2/debian/control   2015-01-13 19:40:28.0 +0100
@@ -99,6 +99,8 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, libcgns-dev, libmedc-dev,
  libhdf5-dev, zlib1g-dev, mpi-default-dev, libxml2-dev
+Replaces: code-saturne-data ( 3.3.2-3)
+Breaks: code-saturne-data ( 3.3.2-3)
 Description: General purpose Computational Fluid Dynamics (CFD) software - 
includes
  The basic capabilities of Code_Saturne enable the handling of either
  incompressible or expandable flows with or without heat transfer and
diff -Nru code-saturne-3.3.2/debian/rules code-saturne-3.3.2/debian/rules
--- code-saturne-3.3.2/debian/rules 2014-09-23 13:02:24.0 +0200
+++ code-saturne-3.3.2/debian/rules 2015-01-13 19:18:31.0 +0100
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 # Copyright 2009 Sylvestre Ledru sylves...@debian.org
 
+# Exclude cs_config.py from package code-saturne-data
+# It should go into code-saturne-include
+binary-install/code-saturne-data:: DEB_DH_INSTALL_ARGS := -Xcs_config.py
+
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/autoreconf.mk
@@ -28,3 +32,6 @@
 binary-install/code-saturne-data::
chmod +x debian/code-saturne-data/usr/share/code_saturne/runcase*
dh_python2 -pcode-saturne-data
+
+binary-install/code-saturne-include::
+   dh_python2 -pcode-saturne-include


signature.asc
Description: OpenPGP digital signature

Bug#775151: unblock: code-saturne/3.3.2-3

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package code-saturne

Version 3.3.2-3 fixes RC bug #775107 which makes code-saturne mostly
unusable on all archs but one because an arch dependent file
(cs_config.py) was shipped with an arch=all package.

The fix moves cs_config.py to code-saturne-include which is arch=any.

Please find attache the debdiff against version 3.3.2-2.

unblock code-saturne/3.3.2-3

Thanks,

_g.

- -- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJUsxdmAAoJEO/obGx//s+DvQ8H/2zkJq8B6UL3G/yW+yPHr7F6
mlNHApygs5IIlj4M+43jjaUlKLHadOJkTaaZpUNjE2BIw79Kf7vyDfYBbmLiofpb
OVhweZ9c9WYcL6YFTI1sMJiEFwv3xNO/EeqJNPEVxIGjSP9JsZ5l4l6/m8M10B3Q
MJeRvqf7fEdQJ+vEkWormCjyEYpjAyU0PPpCPXpa/UV1l4O0st/B2KCQaZ1TinpA
A7YHE7yga2kMfHEqaPz4tKp72KcrRSLA1N0TExWsPETE7Wmf7eZ+WFgkKxUWZEnW
jrFwWjTR0/4uMP2J4vbpZHNYD8J/llpP/Km3Ch0M5avzCod+Se7lm17h+DAjQfU=
=Y1Tp
-END PGP SIGNATURE-
diff -Nru code-saturne-3.3.2/debian/changelog code-saturne-3.3.2/debian/changelog
--- code-saturne-3.3.2/debian/changelog	2014-09-23 13:12:19.0 +0200
+++ code-saturne-3.3.2/debian/changelog	2015-01-11 17:08:40.0 +0100
@@ -1,3 +1,11 @@
+code-saturne (3.3.2-3) unstable; urgency=medium
+
+  * Team upload.
+  * Move arch-dependant script cs_config.py from code-saturne-data to
+code-saturne-include (Closes: #775107).
+
+ -- Gilles Filippini p...@debian.org  Sun, 11 Jan 2015 16:01:45 +0100
+
 code-saturne (3.3.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru code-saturne-3.3.2/debian/code-saturne-include.install code-saturne-3.3.2/debian/code-saturne-include.install
--- code-saturne-3.3.2/debian/code-saturne-include.install	2014-09-22 21:39:38.0 +0200
+++ code-saturne-3.3.2/debian/code-saturne-include.install	2015-01-11 17:08:40.0 +0100
@@ -1,2 +1,2 @@
 debian/tmp/usr/include
-
+debian/tmp/usr/lib/python*/dist-packages/code_saturne/cs_config.py
diff -Nru code-saturne-3.3.2/debian/rules code-saturne-3.3.2/debian/rules
--- code-saturne-3.3.2/debian/rules	2014-09-23 13:02:24.0 +0200
+++ code-saturne-3.3.2/debian/rules	2015-01-11 17:08:40.0 +0100
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 # Copyright 2009 Sylvestre Ledru sylves...@debian.org
 
+# Exclude cs_config.py from package code-saturne-data
+# It should go into code-saturne-include
+binary-install/code-saturne-data:: DEB_DH_INSTALL_ARGS := -Xcs_config.py
+
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/autoreconf.mk
@@ -28,3 +32,6 @@
 binary-install/code-saturne-data::
 	chmod +x debian/code-saturne-data/usr/share/code_saturne/runcase*
 	dh_python2 -pcode-saturne-data
+
+binary-install/code-saturne-include::
+	dh_python2 -pcode-saturne-include

Re: Bug#739261: libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran from stable

[Gilles Filippini]

[resending because of a previously malformed address]

Hi,

On Fri, 13 Jun 2014 11:22:03 +0200 Emilio Pozuelo Monfort
po...@debian.org wrote:
 On 12/06/14 21:51, Gilles Filippini wrote:
  nmu hdf5_1.8.8-9 . amd64 i386 kfreebsd-amd64 kfreebsd-i386 . stable . -m 
  Rebuild with current gfortran in wheezy (closes: #739261)
  
  Hoping to get it right this time :/
 
 Scheduled. This still needs to be accepted by the SRMs for the next point
 release.

I fail to see any move on this side. Is there anything I could do to
have this binNMU accepted into stable?

Thanks in advance,

_g.





signature.asc
Description: OpenPGP digital signature

Re: Bug#739261: libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran from stable

[Gilles Filippini]

Adam D. Barratt a écrit , Le 04/09/2014 23:51:
 On Thu, 2014-09-04 at 23:26 +0200, Gilles Filippini wrote:
 [resending because of a previously malformed address]

 Hi,

 On Fri, 13 Jun 2014 11:22:03 +0200 Emilio Pozuelo Monfort
 po...@debian.org wrote:
 On 12/06/14 21:51, Gilles Filippini wrote:
 nmu hdf5_1.8.8-9 . amd64 i386 kfreebsd-amd64 kfreebsd-i386 . stable . -m 
 Rebuild with current gfortran in wheezy (closes: #739261)

 Hoping to get it right this time :/

 Scheduled. This still needs to be accepted by the SRMs for the next point
 release.

 I fail to see any move on this side.
 
 Then your vision is faulty.

:)
I was looking at the buildd log page [1] where the binNMU is reported
'Uploaded' (not 'Installed').

[1] https://buildd.debian.org/status/package.php?p=hdf5suite=wheezy

 
 Is there anything I could do to
 have this binNMU accepted into stable?
 
 Travel back to July this year, when the update was released.
 
 See https://www.debian.org/News/2014/20140712 and
 
  libhdf5-7 |   1.8.8-9 | stable | armel, armhf, ia64, mips, mipsel, 
 powerpc, s390, s390x, sparc
  libhdf5-7 |1.8.8-9+b1 | stable | amd64, i386, kfreebsd-amd64, 
 kfreebsd-i386

Then I apologize for the noise :)

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Steven Chamberlain a écrit , Le 01/09/2014 14:38:
 block 749395 by 760125
 block 749395 by 760162
 thanks
 
 Hi,
 
 shogun did not build on all architectures, please see these two bugs
 with patches / suggestions.


Hrm...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760120

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit , Le 26/08/2014 22:25:
 Control: tags -1 confirmed
 
 On 21/07/14 23:59, Gilles Filippini wrote:
 The last hdf5 release package in experimental (1.8.13+docs-2)
 introduced a soname bump (7 - 8) due to the MPIPOSIX API removal, plus
 significant path changes to allow the co-installation of the different
 flavors (serial, mpich, openmpi) of the library.
 
 Go ahead.

Uploaded.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit , Le 20/08/2014 19:50:
 Gilles Filippini a écrit , Le 15/08/2014 20:59:
 = Package ready =
 cmor
 flann
 gnuplot-iostream
 gpiv
 gpivtools
 magics++
 octave-bim
 octave-msh
 pktools
 pygpiv
 python-shogun
 syrthes
 vtk

 = Useless build depends on hdf5 (package ready anyway) =
 getdp   #755973
 insighttoolkit4 #756015
 oasis3  #755681
 slepc   #755180

 = binNMU required =
 adios
 armadillo
 aster
 cdo
 code-saturne
 dolfin   (not in testing)
 dynare   (after octave)
 exodusii
 feel++   (not in testing)
 gdal
 gmsh
 grads
 h5py
 h5utils
 hdf-eos5
 jhdf
 libcgns
 libgpiv
 libmatio
 libpdl-io-hdf5-perl  (not in testing)
 libvigraimpex
 mathgl
 med-fichier
 meep
 meep-lam4
 meep-mpich2
 meep-mpi-default
 meep-openmpi
 minc
 mlpack
 mpb
 ncl
 netcdf
 nexus
 nifti2dicom  (after vtk6)
 nip2 (after vips)
 octave
 ovito
 paraview
 petsc
 pytables
 r-cran-hdf5
 ruby-hdfeos5
 salome-kernel
 scilab
 shogun
 silo-llnl
 stimfit
 tessa(not in testing)
 vips (after libmatio)
 vtk6
 xdmf
 xmds2
 yorick-hdf5

 = Others - Not in testing anyway =
 gnudatalanguage FTBFS blocked by plplot
 openmeeg FTBFS on sid - #730904
 plplot   FTBFS on sid - #713309 and more
 
 Looking at the packages listed on the auto-hdf5 transition page I
 realize that I missed two affected packages:

These two packages were uploaded to unstable with a fix. Their status
are now:
= binNMU required =
octave-communications

= Others - Not in testing anyway =
mapsempler2 unrelated FTBFS on sid - the version in testing doesn't
depend on HDF5

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit , Le 15/08/2014 20:59:
 = Package ready =
 cmor
 flann
 gnuplot-iostream
 gpiv
 gpivtools
 magics++
 octave-bim
 octave-msh
 pktools
 pygpiv
 python-shogun
 syrthes
 vtk
 
 = Useless build depends on hdf5 (package ready anyway) =
 getdp   #755973
 insighttoolkit4 #756015
 oasis3  #755681
 slepc   #755180
 
 = binNMU required =
 adios
 armadillo
 aster
 cdo
 code-saturne
 dolfin(not in testing)
 dynare(after octave)
 exodusii
 feel++(not in testing)
 gdal
 gmsh
 grads
 h5py
 h5utils
 hdf-eos5
 jhdf
 libcgns
 libgpiv
 libmatio
 libpdl-io-hdf5-perl   (not in testing)
 libvigraimpex
 mathgl
 med-fichier
 meep
 meep-lam4
 meep-mpich2
 meep-mpi-default
 meep-openmpi
 minc
 mlpack
 mpb
 ncl
 netcdf
 nexus
 nifti2dicom   (after vtk6)
 nip2  (after vips)
 octave
 ovito
 paraview
 petsc
 pytables
 r-cran-hdf5
 ruby-hdfeos5
 salome-kernel
 scilab
 shogun
 silo-llnl
 stimfit
 tessa (not in testing)
 vips  (after libmatio)
 vtk6
 xdmf
 xmds2
 yorick-hdf5
 
 = Others - Not in testing anyway =
 gnudatalanguage FTBFS blocked by plplot
 openmeeg  FTBFS on sid - #730904
 plplotFTBFS on sid - #713309 and more

Looking at the packages listed on the auto-hdf5 transition page I
realize that I missed two affected packages:

mapsempler2 #758730 patch on its way
octave-communications   #758733 patch on its way as well

These two packages will need binNMU only afterward.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Hi,

Gilles Filippini a écrit , Le 01/08/2014 02:38:
 Emilio Pozuelo Monfort a écrit , Le 31/07/2014 00:34:
 To be honest, the big number of packages that need sourceful uploads concerns
 me, this close to the freeze. Other RT members have expressed me their 
 concern
 as well.

 Can't you find a way to make the rdeps work with both the current and the new
 packages? See e.g. the perl 5.20 transition, where the paths are changing and
 the rdeps need fixing, but those fixes are being done *beforehand* and they 
 work
 with the old and new perl. Then when the transition starts, we'll only need 
 binNMUs.

 So if you care so much about this, one possibility would be to forget about 
 the
 new upstream release to avoid the SONAME bump, and to get the rdeps fixed
 beforehand. After most have been fixed, you change the paths as needed and 
 NMU
 the rdeps that didn't get fixed. If I have understood things correctly, no
 packages will need binNMUs, so there won't be a transition needed for this. 
 You
 just need to file the bugs and at some point do the switch and NMU what's 
 left.

 If you file the bugs now at severity important, ping the unfixed bugs in a
 month, then in 1.5 or 2 months you change the paths and NMU the rest of the
 fixes, you can get this done by mid-October.

 Hope what I said makes some sense; it is late and I am tired.

 But if you ask me about your current proposal, I'd honestly say it is too 
 late
 for jessie.
 
 Thanks for sharing your views. I'd like to take my chance anyway since
 AIUI you're not giving a definitive NO-GO.
 
 To ease the transition I've updated (and tested) my patches so that they
 support both releases of hdf5. This way, once all the fixes are done,
 only binNMUs should remain to do.
 
 I've now filed bugs against all the packages requesting a fix. See the
 updated status below.

All these packages are now fixed and uploaded to unstable, so that the
transition should require binNMUs only. I hope this new status will void
your previous concerns :)

Thanks in advance,

_g.

= Package ready =
cmor
flann
gnuplot-iostream
gpiv
gpivtools
magics++
octave-bim
octave-msh
pktools
pygpiv
python-shogun
syrthes
vtk

= Useless build depends on hdf5 (package ready anyway) =
getdp   #755973
insighttoolkit4 #756015
oasis3  #755681
slepc   #755180

= binNMU required =
adios
armadillo
aster
cdo
code-saturne
dolfin  (not in testing)
dynare  (after octave)
exodusii
feel++  (not in testing)
gdal
gmsh
grads
h5py
h5utils
hdf-eos5
jhdf
libcgns
libgpiv
libmatio
libpdl-io-hdf5-perl (not in testing)
libvigraimpex
mathgl
med-fichier
meep
meep-lam4
meep-mpich2
meep-mpi-default
meep-openmpi
minc
mlpack
mpb
ncl
netcdf
nexus
nifti2dicom (after vtk6)
nip2(after vips)
octave
ovito
paraview
petsc
pytables
r-cran-hdf5
ruby-hdfeos5
salome-kernel
scilab
shogun
silo-llnl
stimfit
tessa   (not in testing)
vips(after libmatio)
vtk6
xdmf
xmds2
yorick-hdf5

= Others - Not in testing anyway =
gnudatalanguage FTBFS blocked by plplot
openmeegFTBFS on sid - #730904
plplot  FTBFS on sid - #713309 and more





signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit , Le 31/07/2014 00:34:
 On 30/07/14 20:09, Gilles Filippini wrote:
 Hi,

 Please find an updated status below.

 I've filed a few more bugs for fixes to build systems which don't need
 any hint about the new hdf5 paths.

 I've uploaded a fix for #756108 to DELAYED/2.

 I've added a usertag HDF5-transition [1] to the bugs related to this
 transition, but not for bugs related to useless build depends, because
 they're not in our way.

 [1]
 https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=HDF5-transitionuser=pini%40debian.org

 I'll start tomorrow to file bugs with severity=wishlist + patches for
 the other packages.

 Please tell me what more could be needed.

 I've spent *many* hours these last weeks to prepare this transition
 (which is my first one BTW). And I'm committed to spent more hours to
 NMU as needed after the transition starts. I would be very disappointed
 in case it couldn't happen before the transition freeze.
 
 To be honest, the big number of packages that need sourceful uploads concerns
 me, this close to the freeze. Other RT members have expressed me their concern
 as well.
 
 Anyway...
 
 It seems to me like you're entangling two different transitions:
 
 - The new upstream release with a SONAME bump
 - The changes to -dev packages to make the co-installable
 
 It seems to me like it's the second one (changes in -dev packages) that 
 requires
 so many packages to be patched. Is that right? This is also what you care most
 about and what you want to do before the freeze.
 
 Can't you find a way to make the rdeps work with both the current and the new
 packages? See e.g. the perl 5.20 transition, where the paths are changing and
 the rdeps need fixing, but those fixes are being done *beforehand* and they 
 work
 with the old and new perl. Then when the transition starts, we'll only need 
 binNMUs.
 
 So if you care so much about this, one possibility would be to forget about 
 the
 new upstream release to avoid the SONAME bump, and to get the rdeps fixed
 beforehand. After most have been fixed, you change the paths as needed and NMU
 the rdeps that didn't get fixed. If I have understood things correctly, no
 packages will need binNMUs, so there won't be a transition needed for this. 
 You
 just need to file the bugs and at some point do the switch and NMU what's 
 left.
 
 If you file the bugs now at severity important, ping the unfixed bugs in a
 month, then in 1.5 or 2 months you change the paths and NMU the rest of the
 fixes, you can get this done by mid-October.
 
 Hope what I said makes some sense; it is late and I am tired.
 
 But if you ask me about your current proposal, I'd honestly say it is too late
 for jessie.

Thanks for sharing your views. I'd like to take my chance anyway since
AIUI you're not giving a definitive NO-GO.

To ease the transition I've updated (and tested) my patches so that they
support both releases of hdf5. This way, once all the fixes are done,
only binNMUs should remain to do.

I've now filed bugs against all the packages requesting a fix. See the
updated status below.

Thanks,

_g.

= Package ready =
cmor
magics++
octave-bim
octave-msh
python-shogun
syrthes
vtk

= Useless build depends on hdf5 (package ready anyway) =
getdp   #755973
insighttoolkit4 #756015
oasis3  #755681
slepc   #755180

= binNMU required =
armadillo
dolfin
mathgl
nifti2dicom (after vtk6)
nip2(after vips)
ovito   (blocked by #756108)
paraview(blocked by #756108)
shogun
vips(after libmatio)
vtk6(blocked by #756108)

= Fix required - patch proposal ready =
adios   #756647
aster   #756659
cdo #756660
code-saturne#756661
dynare  #756704
exodusii#756421
feel++  #756435
flann   #756471
gdal#756662
gmsh#756472
gnuplot-iostream#756705
gpiv#756663
gpivtools   #756665
grads   #75
h5utils #756670
hdf-eos5#756671
jhdf#756672
libcgns #756673
libgpiv #756674
libmatio#756675
libpdl-io-hdf5-perl #756676
libvigraimpex   #756677
med-fichier #756678
meep#756679
meep-lam4   #756680
meep-mpich2 #756681
meep-mpi-default#756682
meep-openmpi#756683
minc#756684
mlpack  #756706
mpb #756685
ncl #756686
netcdf  #756687
nexus   #756688
octave  #756689
petsc   #756690
pktools #756707
pygpiv  #756692
pytables#756694
r-cran-hdf5 #756695
ruby-hdfeos5#756696

Bug#755539: transition: hdf5

[Gilles Filippini]

Hi,

Please find an updated status below.

I've filed a few more bugs for fixes to build systems which don't need
any hint about the new hdf5 paths.

I've uploaded a fix for #756108 to DELAYED/2.

I've added a usertag HDF5-transition [1] to the bugs related to this
transition, but not for bugs related to useless build depends, because
they're not in our way.

[1]
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=HDF5-transitionuser=pini%40debian.org

I'll start tomorrow to file bugs with severity=wishlist + patches for
the other packages.

Please tell me what more could be needed.

I've spent *many* hours these last weeks to prepare this transition
(which is my first one BTW). And I'm committed to spent more hours to
NMU as needed after the transition starts. I would be very disappointed
in case it couldn't happen before the transition freeze.

Thanks,

_g.

= No action required =
cmor
magics++
octave-bim
octave-msh
python-shogun
vtk

= Useless build depends on hdf5 (no action required for transition) =
getdp   #755973
insighttoolkit4 #756015
oasis3  #755681
slepc   #755180

= binNMU required =
armadillo
dolfin
mathgl
nifti2dicom (after vtk6)
nip2(after vips)
ovito   (blocked by #756108)
paraview(blocked by #756108)
shogun
vips(after libmatio)
vtk6(blocked by #756108)

= Fix required - patch proposal ready =
adios
aster
cdo
cmor
code-saturne
dynare
exodusii(#756421)
feel++  (#756435)
flann   (#756471)
gdal
gmsh(#756472)
gnuplot-iostream
gpiv
gpivtools
grads
h5utils
hdf-eos5
jhdf
libcgns
libgpiv
libmatio
libpdl-io-hdf5-perl
libvigraimpex
med-fichier
meep
meep-lam4
meep-mpich2
meep-mpi-default
meep-openmpi
minc
mlpack
mpb
ncl
netcdf
nexus
octave
petsc
pktools
pygpiv
pytables
r-cran-hdf5
ruby-hdfeos5
salome-kernel
scilab
stimfit
syrthes
tessa
xdmf
xmds2
yorick-hdf5

= Depends on the removed hdf5 mpi-posix API =
h5pyeasy to fix - working on a patch
silo-llnl   not so easy but very low popcon (80)

= Others - Not in testing anyway =
gnudatalanguage FTBFS blocked by plplot
openmeegFTBFS on sid - #730904
plplot  FTBFS on sid - #713309 and more





signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit , Le 29/07/2014 00:16:
 Hi,
 
 On 27/07/14 01:12, Gilles Filippini wrote:
 Emilio Pozuelo Monfort a écrit , Le 25/07/2014 09:22:
 On 24/07/14 20:10, Gilles Filippini wrote:
 I am currently rebuilding every affected package to prepare debdiff
 patches. I'll need a week or so to complete this task.

 Let us know when that's done.

 It took less time than I thought. Here is the new status of affected
 packages:

 No action required:
 magics++
 octave-bim
 octave-msh
 python-shogun
 vtk

 Useless bin dependency on hdf5:
 getdp   #755973
 insighttoolkit4 #756015
 oasis3  #755681
 slepc   #755180

 binNMU required:
 armadillo
 dolfin
 mathgl
 ovito(blocked by #756108)
 paraview (blocked by #756108)
 shogun
 vtk6 (blocked by #756108)
 
 Can't #756108 be fixed before the transition starts? (If not, why not?)

Sure it could. It's an easy one. But I'm not sure how welcome could be
an NMU for a bug which have severity=normal. I you think it's fine I can
NMU it with delay=2.

 Fix required (patch proposal ready):
 adios
 aster
 cdo
 cmor
 code-saturne
 exodusii
 flann
 gdal
 gmsh
 gpiv
 gpivtools
 grads
 h5utils
 hdf-eos5
 jhdf
 libcgns
 libgpiv
 libmatio
 libpdl-io-hdf5-perl
 libvigraimpex
 med-fichier
 meep
 meep-lam4
 meep-mpich2
 meep-mpi-default
 meep-openmpi
 minc
 mpb
 ncl
 netcdf
 nexus
 octave
 petsc
 pygpiv
 pytables
 r-cran-hdf5
 ruby-hdfeos5
 salome-kernel
 scilab
 stimfit
 syrthes
 tessa
 xdmf
 xmds2
 yorick-hdf5
 
 Can't these be fixed before the transition starts? If not, why not? Are all 
 the
 patches similar? Can you put the patches somewhere (e.g. people.debian.org) so
 we can take a look?

The fixes are mostly easy ones but should occur after the transition
starts because they are related to paths changes in the libhdf5*-dev
packages.
I've put the patches there:
https://people.debian.org/~pini/hdf5-transition/patches/

 BTW I'd expect bugs to be filed before the transition starts.

Would it be acceptable that I file these bugs with the patches attached
plus a blocker on this transition bug?

 Depends on deprecated hdf5 mpi-posix API:
 h5py
 silo-llnl
 
 What does that mean? Is that API deprecated but not removed, so these still
 work? Do they need binNMUs then? Or is that API removed? If so, what's the 
 plan
 here?

The mpi-posix API was *removed*:
http://www.hdfgroup.org/newsletters/newsletter140.html

The fix for h5py is really easy: just remove the python bindings for
this API.
It should be easy for silo-llnl too but I'm not at ease with this
application so I don't have a patch proposal at hand. I've opened a bug
upstream:
http://visitbugs.ornl.gov/issues/1915

 With so many packages needing sourceful uploads after the transition starts, 

Because of the installation paths changes needed to allow the
co-installation of libhdf5*-dev (see below).

 I'm
 unsure this is a good idea this close to the transition freeze. Also, you
 haven't explained why you want this update in Jessie. I see this is just a 
 point
 release. Is there something new in 1.8.13 that we really want that isn't in 
 1.8.12?

This is an upstream point release indeed. But on the package side this
release introduces a long awaited major feature: it is now possible to
co-install the different flavors (serial, mpich, openmpi) of the
library; they were conflicting before that, leading to recurrent
problems: #703439, #721202, #746955. It would really be great to have
this solved for Jessie.

Thanks,

_g.

 
 Cheers,
 Emilio
 
 Others:
 gnudatalanguage FTBFS blocked by plplot




signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Gilles Filippini a écrit , Le 27/07/2014 01:12:
 Emilio Pozuelo Monfort a écrit , Le 25/07/2014 09:22:
 On 24/07/14 20:10, Gilles Filippini wrote:
 I am currently rebuilding every affected package to prepare debdiff
 patches. I'll need a week or so to complete this task.

 Let us know when that's done.
 
 It took less time than I thought. Here is the new status of affected
 packages:
 
 No action required:
 magics++
 octave-bim
 octave-msh
 python-shogun
 vtk
 
 Useless bin dependency on hdf5:
 getdp   #755973
 insighttoolkit4 #756015
 oasis3  #755681
 slepc   #755180
 
 binNMU required:
 armadillo
 dolfin
 mathgl
 ovito (blocked by #756108)
 paraview  (blocked by #756108)
 shogun
 vtk6  (blocked by #756108)
 
 Fix required (patch proposal ready):
 adios
 aster
 cdo
 cmor
 code-saturne
 exodusii
 flann
 gdal
 gmsh
 gpiv
 gpivtools
 grads
 h5utils
 hdf-eos5
 jhdf
 libcgns
 libgpiv
 libmatio
 libpdl-io-hdf5-perl
 libvigraimpex
 med-fichier
 meep
 meep-lam4
 meep-mpich2
 meep-mpi-default
 meep-openmpi
 minc
 mpb
 ncl
 netcdf
 nexus
 octave
 petsc
 pygpiv
 pytables
 r-cran-hdf5
 ruby-hdfeos5
 salome-kernel
 scilab
 stimfit
 syrthes
 tessa
 xdmf
 xmds2
 yorick-hdf5
 
 Depends on deprecated hdf5 mpi-posix API:
 h5py
 silo-llnl
 
 Others:
 gnudatalanguage FTBFS blocked by plplot

I've also checked the packages having an indirect build dependency on
hdf5, and found a few more ones which will require an action:

binNMU:
vips (after libmatio)
nifti2dicom (after vtk6)
nip2 (after vips)

Fix required (patch proposal ready):
dynare
feel++
gnuplot-iostream
mlpack
pktools

Others:
openmeeg (not in testing - FTBFS on sid - #730904)
plplot (not in testing - FTBFS on sid - #713309 and more)

With these packages processed, I think I'm now ready to upload hdf5
1.8.13 to unstable, at your will.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit , Le 25/07/2014 09:22:
 On 24/07/14 20:10, Gilles Filippini wrote:
 I am currently rebuilding every affected package to prepare debdiff
 patches. I'll need a week or so to complete this task.
 
 Let us know when that's done.

It took less time than I thought. Here is the new status of affected
packages:

No action required:
magics++
octave-bim
octave-msh
python-shogun
vtk

Useless bin dependency on hdf5:
getdp   #755973
insighttoolkit4 #756015
oasis3  #755681
slepc   #755180

binNMU required:
armadillo
dolfin
mathgl
ovito   (blocked by #756108)
paraview(blocked by #756108)
shogun
vtk6(blocked by #756108)

Fix required (patch proposal ready):
adios
aster
cdo
cmor
code-saturne
exodusii
flann
gdal
gmsh
gpiv
gpivtools
grads
h5utils
hdf-eos5
jhdf
libcgns
libgpiv
libmatio
libpdl-io-hdf5-perl
libvigraimpex
med-fichier
meep
meep-lam4
meep-mpich2
meep-mpi-default
meep-openmpi
minc
mpb
ncl
netcdf
nexus
octave
petsc
pygpiv
pytables
r-cran-hdf5
ruby-hdfeos5
salome-kernel
scilab
stimfit
syrthes
tessa
xdmf
xmds2
yorick-hdf5

Depends on deprecated hdf5 mpi-posix API:
h5py
silo-llnl

Others:
gnudatalanguage FTBFS blocked by plplot


Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit , Le 24/07/2014 09:00:
 On 21/07/14 23:59, Gilles Filippini wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 Dear Release Team,

 The last hdf5 release package in experimental (1.8.13+docs-2)
 introduced a soname bump (7 - 8) due to the MPIPOSIX API removal, plus
 significant path changes to allow the co-installation of the different
 flavors (serial, mpich, openmpi) of the library.

 Almost all affected source packages need to be adapted to acknowledge
 the new paths for the hdf5 headers and libraries, depending on the
 flavor of the library used for the build. For most of them the
 fix is trivial and consists in adding proper --with-hdf5 configure
 option or setting C[PP]FLAGS and LDFLAGS at configure step.

 For example, with cmake build system:
 include /usr/share/mpi-default-dev/debian_defaults
 export CMAKE_INCLUDE_PATH=/usr/include/hdf5/$(ARCH_DEFAULT_MPI_IMPL)
 export 
 CMAKE_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/$(ARCH_DEFAULT_MPI_IMPL)

 With configure scripts:
 --with-hdf5=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial
 or
 --with-hdf5-include=/usr/include/hdf5/serial
 --with-hdf5-lib=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial

 Other trivial cases:
 export CPPFLAGS += -I/usr/include/hdf5/serial
 export LDFLAGS += -Wl,-L/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial


 Affected packages are:
 adios
 armadillo
 aster
 cdo
 cmor
 code-saturne
 dolfin (not in testing)
 exodusii
 flann
 gdal
 getdp (not in testing)
 gmsh
 gnudatalanguage (not in testing)
 gpiv
 gpivtools
 grads
 h5py
 h5utils
 hdf-eos5
 insighttoolkit4
 jhdf
 libcgns
 libgpiv
 libmatio
 libpdl-io-hdf5-perl (not in testing)
 libvigraimpex
 magics++
 mathgl
 med-fichier
 meep
 meep-lam4
 meep-mpich2
 meep-mpi-default
 meep-openmpi
 minc
 mpb
 ncl
 netcdf
 nexus
 oasis3
 octave
 octave-bim
 octave-msh
 ovito
 paraview
 petsc
 pygpiv
 pytables
 python-shogun
 r-cran-hdf5
 ruby-hdfeos5
 salome-kernel
 scilab
 shogun
 silo-llnl
 slepc (not in testing)
 stimfit
 syrthes
 tessa (not in testing)
 vtk
 vtk6
 xdmf
 xmds2 (not in testing)
 yorick-hdf5

 I've tested a build against hdf5 1.8.13+docs-2 for all of them. Here are
 the cases where the fix is not trivial:

 FTBFS in sid:
  gnudatalanguage (blocked by plplot which is in a really bad state)
  cmor (missing build-deps in debian/control)

 Use deprecated MPIPOSIX API:
  h5py
  silo-llnl

 Minor patch to the build system needed:
  hdf-eos5
  jhdf
  libpdl-io-hdf5-perl
  r-cran-hdf5
  ruby-hdfeos5
  scilab
  syrthes

 Really weird build system (ymake)
  ncl

 There are also some cases where the build dependency on libhdf5-*dev
 seems useless:
  magics++
  oasis3
  slepc


 Now that I've achieved all these test builds I think it is time to
 request a transition slot.
 
 Have you filed bugs for the packages that need changes? Can those changes to 
 the
 build system happen *before* the new hdf5 is uploaded, or do they need to 
 happen
 after that?

I filed bugs for useless build dependency on hdf5 (#755180, #755681,
#755709) and one unrelated FTBFS against cmor (#755167). But the other
requested changes should happen *after* the hdf5 upload, so I didn't
report them yet.

BTW, my last upload to experimental fixes the support for the cmake HDF5
macro. Then a bunch of affected package will need binNMUing only.

I am currently rebuilding every affected package to prepare debdiff
patches. I'll need a week or so to complete this task.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Release Team,

The last hdf5 release package in experimental (1.8.13+docs-2)
introduced a soname bump (7 - 8) due to the MPIPOSIX API removal, plus
significant path changes to allow the co-installation of the different
flavors (serial, mpich, openmpi) of the library.

Almost all affected source packages need to be adapted to acknowledge
the new paths for the hdf5 headers and libraries, depending on the
flavor of the library used for the build. For most of them the
fix is trivial and consists in adding proper --with-hdf5 configure
option or setting C[PP]FLAGS and LDFLAGS at configure step.

For example, with cmake build system:
include /usr/share/mpi-default-dev/debian_defaults
export CMAKE_INCLUDE_PATH=/usr/include/hdf5/$(ARCH_DEFAULT_MPI_IMPL)
export 
CMAKE_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/$(ARCH_DEFAULT_MPI_IMPL)

With configure scripts:
- --with-hdf5=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial
or
- --with-hdf5-include=/usr/include/hdf5/serial
- --with-hdf5-lib=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial

Other trivial cases:
export CPPFLAGS += -I/usr/include/hdf5/serial
export LDFLAGS += -Wl,-L/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial


Affected packages are:
adios
armadillo
aster
cdo
cmor
code-saturne
dolfin (not in testing)
exodusii
flann
gdal
getdp (not in testing)
gmsh
gnudatalanguage (not in testing)
gpiv
gpivtools
grads
h5py
h5utils
hdf-eos5
insighttoolkit4
jhdf
libcgns
libgpiv
libmatio
libpdl-io-hdf5-perl (not in testing)
libvigraimpex
magics++
mathgl
med-fichier
meep
meep-lam4
meep-mpich2
meep-mpi-default
meep-openmpi
minc
mpb
ncl
netcdf
nexus
oasis3
octave
octave-bim
octave-msh
ovito
paraview
petsc
pygpiv
pytables
python-shogun
r-cran-hdf5
ruby-hdfeos5
salome-kernel
scilab
shogun
silo-llnl
slepc (not in testing)
stimfit
syrthes
tessa (not in testing)
vtk
vtk6
xdmf
xmds2 (not in testing)
yorick-hdf5

I've tested a build against hdf5 1.8.13+docs-2 for all of them. Here are
the cases where the fix is not trivial:

FTBFS in sid:
 gnudatalanguage (blocked by plplot which is in a really bad state)
 cmor (missing build-deps in debian/control)

Use deprecated MPIPOSIX API:
 h5py
 silo-llnl

Minor patch to the build system needed:
 hdf-eos5
 jhdf
 libpdl-io-hdf5-perl
 r-cran-hdf5
 ruby-hdfeos5
 scilab
 syrthes

Really weird build system (ymake)
 ncl

There are also some cases where the build dependency on libhdf5-*dev
seems useless:
 magics++
 oasis3
 slepc


Now that I've achieved all these test builds I think it is time to
request a transition slot.

Ben file proposal:

title = hdf5;
is_affected = .build-depends ~ 
/libhdf5-((mpi|mpich|mpich2|openmpi|serial)-)?dev/ | .depends ~ 
/libhdf5-((cpp|mpich|mpich2|openmpi)-)?7/ | .depends ~ 
/libhdf5-((cpp|mpich|openmpi)-)?8/;
is_good = .depends ~ /libhdf5-((cpp|mpich|openmpi)-)?8/;
is_bad = .depends ~ /libhdf5-((cpp|mpich|mpich2|openmpi)-)?7/;

Please tell me when I can upload to unstable.
Many thanks in advance,

_g.

- -- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-486
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTzY0vAAoJEO/obGx//s+Dl/sH/2Y7e/0TQBf4nWo/xu1QS2jD
X7l8APZAJxw6YX65K78EHY3NTkqXQVEoZ5gxDFJjPNVYYZnlLyEawYBP0SjuHc/w
MnLnoyaN2qddi1zS3/aARG7gdpwMROQDxEFoSTGL60rxpr1kExHmsHgutqF++A8r
rWBOMdrdPdhsz5aMyTdKKxh2YMvXU5HngsI5RJED1NBpGthKQpdzPGGJZTB3z3C4
XYAQISV5hB/4ICypmbsAxSO93bCr1rcHulLgGBeoo2gTJz37UId+i0CLcJr3xi2l
p1keIS46vErr509RQV/9+3xk7rOM1Btm3rAU+YKCVApoGx9QPAwnP+rGsNoQSEY=
=uNM7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140721215923.31166.16229.report...@pini.bou-fi.net

Bug#740561: Bug#739261: libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran from stable

[Gilles Filippini]

fixed 739261 hdf5/1.8.12+docs-1.1
thanks

Emilio Pozuelo Monfort a écrit , Le 12/06/2014 20:11:
 On 04/06/14 01:17, Gilles Filippini wrote:
 Hi,

 Frank Loeffler a écrit , Le 03/06/2014 21:01:
 Being hit by this myself now, I am a bit surprised by the reaction can
 wait a little longer, for an issue that clearly breaks the Fortran
 interface and seems to be easily fixable.

 But this aside - is there a plan to get this into _any_ of the future
 point releases of stable?

 I have no plan but getting the binNMU #740561 processed.
 And it all depends on the good will of the release team.
 
 You've requested a binnmu for stable on ALL architectures. Before scheduling
 that, I'd like to clarify some things:
 
 Is this bug affecting testing/unstable? If not, please mark it as fixed as
 appropriate in #739261.

This bug doesn't affect testing nor unstable. Marking it fixed for the
related version.

 Is this bug really affecting all architectures? From what I can see, gfortran 
 in
 wheezy is 4.6 everywhere except on amd64, i386, kfreebsd-amd64 and 
 kfreebsd-i386:
 
   gfortran | 4:4.6.3-8 | stable | armel, armhf, ia64, mips, mipsel,
 powerpc, s390, s390x, sparc
   gfortran | 4:4.7.2-1 | stable | amd64, i386, kfreebsd-amd64, 
 kfreebsd-i386
 
 And hdf5 1.8.8-9 was built against 4.6 everywhere, from what I can see on:
 
 https://buildd.debian.org/status/logs.php?pkg=hdf5ver=1.8.8-9suite=sid
 
 So do we need the binnmu everywhere, or only on those architectures where the
 default gfortran was bumped to 4.7, i.e. on amd64, i386, kfreebsd-amd64 and
 kfreebsd-i386?

My mistake: I took for granted that gfortran was upgraded to 4.7
on all architectures.

nmu hdf5_1.8.8-9 . amd64 i386 kfreebsd-amd64 kfreebsd-i386 . stable . -m 
Rebuild with current gfortran in wheezy (closes: #739261)

Hoping to get it right this time :/

_g.



signature.asc
Description: OpenPGP digital signature

Re: Bug#739261: libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran from stable

[Gilles Filippini]

Hi,

Frank Loeffler a écrit , Le 03/06/2014 21:01:
 Being hit by this myself now, I am a bit surprised by the reaction can
 wait a little longer, for an issue that clearly breaks the Fortran
 interface and seems to be easily fixable.
 
 But this aside - is there a plan to get this into _any_ of the future
 point releases of stable?

I have no plan but getting the binNMU #740561 processed.
And it all depends on the good will of the release team.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#740561: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Gilles Filippini a écrit , Le 02/03/2014 22:55:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: binnmu
 
 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in wheezy 
 (closes: #739261)

For the record:
Julien Cristau a écrit , Le 29/04/2014 22:34 [1]:
 On Tue, Apr 29, 2014 at 22:30:41 +0200, Gilles Filippini wrote:
 BTW, any news about #740561?

 It's taken a year for anyone to notice, so it can wait a little bit
 more.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746214#22

_g.



signature.asc
Description: OpenPGP digital signature

Bug#740561: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in wheezy 
(closes: #739261)

Hi,

Since I fail to see any move related to #739266 [1] I'd like to have
#739261 [2] taken care of anyway.

[1] wheezy-pu: package hdf5/1.8.8-9+deb7u1
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739266
[2] libhdf5-openmpi-dev: Version in stable (wheezy) does not work with gfortran 
from stable
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739261

Many thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTE6jhAAoJEO/obGx//s+DDt0H/3FETCDbpgWDpKYPTxH8Fap7
sqS9YxfosTmcgXBnotnfoZBckP6E6Ke0c/A1FOCQsMLQE+MihFaKt+gc0ZrXHLIK
qgCJU8g68wKIOryT9r4GqwsuZ/ui9fGuO3TbSIfFy2ohX4dGLmWnYF8vzkLcGRP9
lkn/QgJUfAbEvK6GC3tvDrej861h/Qj9NuXd+bjQqvX1s/Wo/yvW6LxMIK+/x/1D
ImQNiSuVWRaQhTcATaMxCl6w/FpSL0R7Wtu5ueAimG9XE6oJvvoaVofmUQVs9gRL
Ph0ezV/HL84LbJC2mvdsB4foG2dvxGzhFlqpM2iH7+idBw6KzkB/P+BK/XNXseA=
=ePEV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2014030221.4892.69130.report...@pini.bou-fi.net

Bug#739266: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi release team,

Please bear with me as this is my very first binNMU request.

I need to have the hdf5 source package rebuilt in wheezy in order to fix
#739261. This is because the current hdf5 release in wheezy was built with
a gfortran older than the one currently in wheezy.

nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
(closes: #739261)

Many thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTAeWrAAoJEO/obGx//s+Dg+QH/jtBfwpXaBGUul3rK8+3f7jx
bqL3T+Kh0zyTZKBDiVJFdCJ5ciu3TJtuEuATGqNgErArnlViVRSpg0FJKchVHvZG
MIQd+/Jj9ywCXX2PdwNTuzAR37/O/KD91b6BcV2yYnIX3WaPYd2snGylgtF8mbjT
YN1nxXkM/tQm08ccE6qWcvD9/2y9w3ust+5dTvaV2xxyiW3m89UOmpM7RIZvzaWN
KBECXzrBqRV1gt9JQfpdudYJPWZ0RCugtjcHXeykjq4jrRl5q0KF56R5l5WuxEHB
gfOPvXL4XTwjky8UwND2jqLU+Hwe932dxfVF5+k9RbaE8+wlz8N7D9GhVrrz4pg=
=gasF
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140217103436.31884.7378.report...@pini.bou-fi.net

Bug#739266: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Gilles Filippini wrote, On 17/02/2014 11:34:
 Please bear with me as this is my very first binNMU request.
 
 I need to have the hdf5 source package rebuilt in wheezy in order to fix
 #739261. This is because the current hdf5 release in wheezy was built with
 a gfortran older than the one currently in wheezy.
 
 nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
 (closes: #739261)

Ah sorry, I've seen a syntax mistake just after pushing send  (missing '.').
The nmu line should read:

nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in wheezy 
(closes: #739261)

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#739266: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Hi Steffen,

Steffen Grunewald wrote, On 17/02/2014 12:15:
 On Mon, Feb 17, 2014 at 11:46:39AM +0100, Gilles Filippini wrote:
 Gilles Filippini wrote, On 17/02/2014 11:34:
 Please bear with me as this is my very first binNMU request.

 I need to have the hdf5 source package rebuilt in wheezy in order to fix
 #739261. This is because the current hdf5 release in wheezy was built with
 a gfortran older than the one currently in wheezy.

 nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
 (closes: #739261)

 Ah sorry, I've seen a syntax mistake just after pushing send  (missing 
 '.').
 The nmu line should read:

 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in 
 wheezy (closes: #739261)
 
 Are there plans to make libhdf5-serial-dev work again, aka #706044?

I hadn't. But this is indeed a good opportunity to fix it as well. So
the plan would be to upload to stable a fix for #706044 which would
close #739266 by the way. Am I reading you correctly?

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#739266: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Steffen Grunewald wrote, On 17/02/2014 14:03:
 Hi Gilles,
 
 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in 
 wheezy (closes: #739261)

 Are there plans to make libhdf5-serial-dev work again, aka #706044?

 I hadn't. But this is indeed a good opportunity to fix it as well. So
 the plan would be to upload to stable a fix for #706044 which would
 close #739266 by the way. Am I reading you correctly?
 
 If that could be done, we'd get rid of a quite nasty issue, indeed.
 (I still have no idea how #706044 could slip through during Wheezy
 freeze.)
 
 Thanks,
 
 Thank you - there are quite some people around who would be very happy!

Let's go this way then. It is currently building on my box. Then would
retitling this bug as pu: ... be sufficient?

_g.




signature.asc
Description: OpenPGP digital signature

Bug#739266: nmu: hdf5_1.8.8-9

[Gilles Filippini]

fixed 706044 1.8.9-1~exp1
thanks

Adam D. Barratt wrote, On 17/02/2014 14:53:
 On 2014-02-17 13:27, Gilles Filippini wrote:
 Steffen Grunewald wrote, On 17/02/2014 14:03:
 Hi Gilles,

 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current
 gfortran in wheezy (closes: #739261)

 Are there plans to make libhdf5-serial-dev work again, aka #706044?

 I hadn't. But this is indeed a good opportunity to fix it as well. So
 the plan would be to upload to stable a fix for #706044 which would
 close #739266 by the way. Am I reading you correctly?

 If that could be done, we'd get rid of a quite nasty issue, indeed.
 (I still have no idea how #706044 could slip through during Wheezy
 freeze.)

 Thanks,

 Thank you - there are quite some people around who would be very happy!

 Let's go this way then.
 
 I've not looked at the detail of the bug, but the metadata for #706044
 indicates that it affects the package in unstable as well. If that's
 correct then it needs to be fixed in unstable before considering a
 stable fix.

#706044 was fixed in 1.8.9-1~exp1 but not marked as such.

Thanks for the notice,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#739266: wheezy-pu: package hdf5/1.8.8-9+deb7u1 (was: nmu: hdf5_1.8.8-9)

[Gilles Filippini]

retitle 739266 wheezy-pu: package hdf5/1.8.8-9+deb7u1
tag 739266 wheezy
user release.debian@packages.debian.org
usertag 739266 - binnmu
usertag 739266 + pu
thanks

Gilles Filippini wrote, On 17/02/2014 14:27:
 Steffen Grunewald wrote, On 17/02/2014 14:03:
 Hi Gilles,

 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in 
 wheezy (closes: #739261)

 Are there plans to make libhdf5-serial-dev work again, aka #706044?

 I hadn't. But this is indeed a good opportunity to fix it as well. So
 the plan would be to upload to stable a fix for #706044 which would
 close #739266 by the way. Am I reading you correctly?

 If that could be done, we'd get rid of a quite nasty issue, indeed.
 (I still have no idea how #706044 could slip through during Wheezy
 freeze.)

 Thanks,

 Thank you - there are quite some people around who would be very happy!
 
 Let's go this way then. It is currently building on my box. Then would
 retitling this bug as pu: ... be sufficient?

The new package is ready. I've successfully tested the build of a hdf5
c++ example in a clean wheezy chroot. Debdiff attached.

Thanks,

_g.

diff -Nru hdf5-1.8.8/debian/changelog hdf5-1.8.8/debian/changelog
--- hdf5-1.8.8/debian/changelog 2012-03-08 11:09:55.0 +0100
+++ hdf5-1.8.8/debian/changelog 2014-02-17 15:43:30.0 +0100
@@ -1,3 +1,11 @@
+hdf5 (1.8.8-9+deb7u1) stable; urgency=medium
+
+  * Backport change from the 1.8.9-1 source package:
++ Bring back the C++ library (closes: 706044).
+  * Upload to stable (closes: #739266).
+
+ -- Gilles Filippini p...@debian.org  Mon, 17 Feb 2014 15:43:17 +0100
+
 hdf5 (1.8.8-9) unstable; urgency=low
 
   * Force the dependency on the serpack for hdf5-tools  hdf5-helpers.
diff -Nru hdf5-1.8.8/debian/hdf5-helpers.install 
hdf5-1.8.8/debian/hdf5-helpers.install
--- hdf5-1.8.8/debian/hdf5-helpers.install  2012-02-24 11:15:58.0 
+0100
+++ hdf5-1.8.8/debian/hdf5-helpers.install  2014-02-17 15:35:54.0 
+0100
@@ -1,3 +1,3 @@
 usr/bin/h5cc
 usr/bin/h5fc
-
+usr/bin/h5c++
diff -Nru hdf5-1.8.8/debian/rules hdf5-1.8.8/debian/rules
--- hdf5-1.8.8/debian/rules 2012-03-08 11:09:08.0 +0100
+++ hdf5-1.8.8/debian/rules 2014-02-17 15:35:54.0 +0100
@@ -91,7 +91,7 @@
  --with-pthread --enable-linux-lfs --enable-unsupported \
  --enable-shared --enable-production=$(USE_PROD) \
  --disable-sharedlib-rpath --with-zlib 
--with-default-api-version=v18
-SERIAL_ONLY_FLAGS = --enable-fortran --enable-threadsafe
+SERIAL_ONLY_FLAGS = --enable-fortran --enable-threadsafe --enable-cxx
 
 configure: configure-stamp-debian configure-stamp \
   $(configure_stamp_openmpi) configure-stamp-mpich2
@@ -245,7 +245,7 @@
dh_makeshlibs -p$(openmpipack) -V $(openmpipack)
 endif
dh_makeshlibs -p$(mpich2pack) -V $(mpich2pack)
-   dh_makeshlibs -p$(serpack) -V $(serpack) | $(virtpack)
+   dh_makeshlibs -p$(serpack) -Xhdf5_cpp -Xhdf5_hl_cpp -V $(serpack) | 
$(virtpack)
dh_installdeb $(ARCH_FLAG)
dh_shlibdeps -p$(serpack) -L$(serpack) 
-ldebian/$(serpack)/usr/lib:debian/build/test/.libs
dh_shlibdeps -phdf5-tools -L$(serpack) 
-ldebian/$(serpack)/usr/lib:debian/build/test/.libs


signature.asc
Description: OpenPGP digital signature

Bug#739266: nmu: hdf5_1.8.8-9

[Gilles Filippini]

Hi Julien,

Julien Cristau wrote, On 17/02/2014 18:07:
 On Mon, Feb 17, 2014 at 12:15:48 +0100, Steffen Grunewald wrote:
 Are there plans to make libhdf5-serial-dev work again, aka #706044?

 #706044 is very much not make libhdf5-serial-dev work again.

Indeed. AIUI #706044 is about re-enabling the HDF5 C++ API.

 And is
 IMO not material for stable, though OMMV.

Hmm... YMMV for sure. My take is that we re-introduce something that
shouldn't have been removed in the first place. This C++ API is in
squeeze and will be in jessie. It makes sense to enable it in wheezy as
well. And I fail to see potential nasty side effects.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#714794: pu: package sikuli/1.0~x~rc3.tesseract3-dfsg1-5+deb7u1

[Gilles Filippini]

Gilles Filippini a écrit , Le 05/07/2013 10:47:
 Well, another way to fix it would be to depend on default-jre only and
 explicitly use its java binary (/usr/lib/jvm/default-java/bin/java)
 instead of the one configured by update-alternatives. Would it be
 acceptable?

Please find attached the related debdiff.

Thanks,

_g.
diff -Nru sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog 
sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog
--- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog  2013-07-02 
22:29:52.0 +0200
+++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog  2013-07-09 
20:16:49.0 +0200
@@ -1,3 +1,14 @@
+sikuli (1.0~x~rc3.tesseract3-dfsg1-5+deb7u1) stable-proposed-updates; 
urgency=low
+
+  [tony mancill tmanc...@debian.org]
+  * fix typo in d/control (Closes: #682011)
+
+  [Gilles Filippini p...@debian.org]
+  * Depends on default-jre only and update patch executable-wrappers.patch
+to force using the default-jre (closes: #714393)
+
+ -- Gilles Filippini p...@debian.org  Tue, 09 Jul 2013 19:59:51 +0200
+
 sikuli (1.0~x~rc3.tesseract3-dfsg1-5) unstable; urgency=low
 
   * New patch no-opencv-surf-module.patch: 
diff -Nru sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control 
sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control
--- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control2013-07-02 
22:29:52.0 +0200
+++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control2013-07-09 
20:03:43.0 +0200
@@ -13,8 +13,8 @@
 
 Package: sikuli-ide
 Architecture: all
-Depends: ${java:Depends}, ${misc:Depends}, default-jre (= 1:1.6) | 
java6-runtime, libsikuli-script-java, junit, libswingx-java, 
libswing-layout-java
-Description: IDE to develop sikuli scripts and use them a junit test cases
+Depends: ${java:Depends}, ${misc:Depends}, default-jre (= 1:1.6), 
libsikuli-script-java, junit, libswingx-java, libswing-layout-java
+Description: IDE to develop sikuli scripts and use them as junit test cases
  Sikuli mixes image recognition into jython scripting to automate
  interactions with graphical user interfaces.
  .
diff -Nru 
sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch 
sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch
--- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch  
2013-07-02 22:29:52.0 +0200
+++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch  
2013-07-09 20:01:47.0 +0200
@@ -7,19 +7,19 @@
   ImportError: cannot import name newString
  when it is missing.
 Author: Gilles Filippini p...@debian.org
-Index: sikuli/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh
+Index: sikuli-stable/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh
 ===
 sikuli.orig/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh   
2011-09-26 22:14:12.0 +0200
-+++ sikuli/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh2011-09-26 
22:57:49.0 +0200
+--- sikuli-stable.orig/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh
2013-07-09 20:00:47.0 +0200
 sikuli-stable/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh 
2013-07-09 20:01:35.0 +0200
 @@ -1,3 +1,2 @@
  #!/bin/sh
 -DIR=`dirname $0`
 -LC_NUMERIC=C java -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M 
-Dfile.encoding=UTF-8 -jar $DIR/sikuli-ide.jar $*
-+LC_NUMERIC=C exec /usr/bin/java -cp 
/usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar
 -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M -Dfile.encoding=UTF-8 
-Dpython.home=/usr/share/jython -Dpython.path=/usr/share/sikuli/Lib 
-Dpython.cachedir=$HOME/.jython-cache org.sikuli.ide.SikuliIDE $@
-Index: sikuli/sikuli-script/target/sikuli-script.sh
++LC_NUMERIC=C exec /usr/lib/jvm/default-java/bin/java -cp 
/usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar
 -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M -Dfile.encoding=UTF-8 
-Dpython.home=/usr/share/jython -Dpython.path=/usr/share/sikuli/Lib 
-Dpython.cachedir=$HOME/.jython-cache org.sikuli.ide.SikuliIDE $@
+Index

Bug#714794: pu: package sikuli/1.0~x~rc3.tesseract3-dfsg1-5+deb7u1

[Gilles Filippini]

Julien Cristau a écrit , Le 04/07/2013 17:29:
 On Thu, Jul  4, 2013 at 08:02:22 +0200, Gilles Filippini wrote:
 
 Adam D. Barratt a écrit , Le 03/07/2013 23:17:
 Control: tags -1 + moreinfo wheezy

 On Tue, 2013-07-02 at 23:15 +0200, Gilles Filippini wrote:
 Please consider accepting this pu which fixes RC bug #714393 in sikuli-ide.

 I'm slightly confused by the fix, but happy to believe I'm missing
 something obvious...

 ++LD_LIBRARY_PATH=/usr/lib/@DEB_HOST_MULTIARCH@/jni:$LD_LIBRARY_PATH 
 LC_NUMERIC=C exec /usr/bin/java -cp 
 /usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar
  -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M 
 -Dfile.encoding=UTF-8 -Dpython.home=/usr/share/jython 
 -Dpython.path=/usr/share/sikuli/Lib -Dpython.cachedir=$HOME/.jython-cache 
 org.sikuli.ide.SikuliIDE $@
 [...]
 --- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/rules  2013-07-02 
 22:29:53.0 +0200
 +++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/rules  2013-07-02 
 22:54:40.0 +0200
 @@ -50,5 +50,6 @@
 
 mkdir -p debian/sikuli-ide/usr/bin
 install sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh 
 debian/sikuli-ide/usr/bin/sikuli-ide
 +   sed -i s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/ 
 debian/sikuli-ide/usr/bin/sikuli-ide

 sikuli-ide is an architecture:all package, so only built as part of the
 maintainer upload. The path to which it points, otoh, is in an
 architecture-dependent package (and an architecture-dependent path);
 this means that the two paths will only match for users installing
 libsikuli-script-jni on the same architecture as the arch:all package
 was built on.

 Oops! Indeed, you're right. Thanks for noticing it.

 This path should be resolved at run-time, then, using dpkg-architecture.
 But it implies depending on dpkg-dev :/ What do you think? Is there
 another way to compute these triplets path?

 If the script needs to be arch-dependent, then it needs to be part of an
 arch-dependent package.  But I don't get why you need to add this path
 to LD_LIBRARY_PATH.  java should already know to look there, and
 I'd have though nothing else would be loading a jni?

Obviously sun-java6 doesn't know where to find the jni library, hence
bug #714393, which is actually more a sun-java6 bug then.

Well, another way to fix it would be to depend on default-jre only and
explicitly use its java binary (/usr/lib/jvm/default-java/bin/java)
instead of the one configured by update-alternatives. Would it be
acceptable?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#714794: pu: package sikuli/1.0~x~rc3.tesseract3-dfsg1-5+deb7u1

[Gilles Filippini]

Adam D. Barratt a écrit , Le 03/07/2013 23:17:
 Control: tags -1 + moreinfo wheezy
 
 On Tue, 2013-07-02 at 23:15 +0200, Gilles Filippini wrote:
 Please consider accepting this pu which fixes RC bug #714393 in sikuli-ide.
 
 I'm slightly confused by the fix, but happy to believe I'm missing
 something obvious...
 
 ++LD_LIBRARY_PATH=/usr/lib/@DEB_HOST_MULTIARCH@/jni:$LD_LIBRARY_PATH 
 LC_NUMERIC=C exec /usr/bin/java -cp 
 /usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar
  -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M 
 -Dfile.encoding=UTF-8 -Dpython.home=/usr/share/jython 
 -Dpython.path=/usr/share/sikuli/Lib -Dpython.cachedir=$HOME/.jython-cache 
 org.sikuli.ide.SikuliIDE $@
 [...]
 --- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/rules  2013-07-02 
 22:29:53.0 +0200
 +++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/rules  2013-07-02 
 22:54:40.0 +0200
 @@ -50,5 +50,6 @@
 
 mkdir -p debian/sikuli-ide/usr/bin
 install sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh 
 debian/sikuli-ide/usr/bin/sikuli-ide
 +   sed -i s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/ 
 debian/sikuli-ide/usr/bin/sikuli-ide
 
 sikuli-ide is an architecture:all package, so only built as part of the
 maintainer upload. The path to which it points, otoh, is in an
 architecture-dependent package (and an architecture-dependent path);
 this means that the two paths will only match for users installing
 libsikuli-script-jni on the same architecture as the arch:all package
 was built on.

Oops! Indeed, you're right. Thanks for noticing it.

This path should be resolved at run-time, then, using dpkg-architecture.
But it implies depending on dpkg-dev :/ What do you think? Is there
another way to compute these triplets path?

Thanks,

g.




signature.asc
Description: OpenPGP digital signature

Bug#714794: pu: package sikuli/1.0~x~rc3.tesseract3-dfsg1-5+deb7u1

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please consider accepting this pu which fixes RC bug #714393 in sikuli-ide.
It also fixes an ugly typo reported in short description (#682011).

Debdiff attached.

Many thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJR00LKAAoJEO/obGx//s+DAY4H/04hRK8dEiNxENm4yOto5q/k
HRpYrU0cFbfDeedXIOqf4aF8+iRsa/qb2DRTcuzZXh8n0VcFGpNdB+lZR2kiRLU7
n3g44VNwVFtICEsiSlR76WLyz7qfpHTapS4Mbx8Pv48NxCh5gz+k6qtcloiDuoni
i1YrwSzvnJCiLQ+A897028JrSwsh7qgyLm1qQoNnHmT4i4ALEXeaxKam7ffbomII
m3l5bT+bOvi1bF3HSxSsLDn6b0c+eYmLaRvVj3sfewC2q8dB8/2Ci6pOZ5ckH6hq
mCzNmw8j/q0ke4p6O/6Mh1bXwcBM2YwN1TeDOXvgB6cJLh2VNGYpkMWSY+Nv2hg=
=VqY7
-END PGP SIGNATURE-
diff -Nru sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog
--- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog	2013-07-02 22:29:52.0 +0200
+++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/changelog	2013-07-02 23:03:23.0 +0200
@@ -1,3 +1,15 @@
+sikuli (1.0~x~rc3.tesseract3-dfsg1-5+deb7u1) stable-proposed-updates; urgency=low
+
+  [tony mancill tmanc...@debian.org]
+  * fix typo in d/control (Closes: #682011)
+
+  [Gilles Filippini p...@debian.org]
+  * Updated patch:
++ executable-wrappers.patch: add /usr/lib/multiarch-triplet/jni to
+  LD_LIBRARY_PATH (closes: #714393)
+
+ -- Gilles Filippini p...@debian.org  Tue, 02 Jul 2013 21:48:40 +0200
+
 sikuli (1.0~x~rc3.tesseract3-dfsg1-5) unstable; urgency=low
 
   * New patch no-opencv-surf-module.patch: 
diff -Nru sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control
--- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control	2013-07-02 22:29:52.0 +0200
+++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/control	2013-07-02 22:54:40.0 +0200
@@ -14,7 +14,7 @@
 Package: sikuli-ide
 Architecture: all
 Depends: ${java:Depends}, ${misc:Depends}, default-jre (= 1:1.6) | java6-runtime, libsikuli-script-java, junit, libswingx-java, libswing-layout-java
-Description: IDE to develop sikuli scripts and use them a junit test cases
+Description: IDE to develop sikuli scripts and use them as junit test cases
  Sikuli mixes image recognition into jython scripting to automate
  interactions with graphical user interfaces.
  .
diff -Nru sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch
--- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch	2013-07-02 22:29:52.0 +0200
+++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/patches/executable-wrappers.patch	2013-07-02 22:54:40.0 +0200
@@ -9,17 +9,17 @@
 Author: Gilles Filippini p...@debian.org
 Index: sikuli/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh
 ===
 sikuli.orig/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh	2011-09-26 22:14:12.0 +0200
-+++ sikuli/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh	2011-09-26 22:57:49.0 +0200
+--- sikuli.orig/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh	2013-06-07 07:56:00.0 +0200
 sikuli/sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh	2013-06-07 08:00:40.0 +0200
 @@ -1,3 +1,2 @@
  #!/bin/sh
 -DIR=`dirname $0`
 -LC_NUMERIC=C java -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M -Dfile.encoding=UTF-8 -jar $DIR/sikuli-ide.jar $*
-+LC_NUMERIC=C exec /usr/bin/java -cp /usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M -Dfile.encoding=UTF-8 -Dpython.home=/usr/share/jython -Dpython.path=/usr/share/sikuli/Lib -Dpython.cachedir=$HOME/.jython-cache org.sikuli.ide.SikuliIDE $@
++LD_LIBRARY_PATH=/usr/lib/@DEB_HOST_MULTIARCH@/jni:$LD_LIBRARY_PATH LC_NUMERIC=C exec /usr/bin/java -cp /usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M

Bug#703311: unblock: navit/0.5.0~svn5126+dfsg.1-3

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Release Team,

Please consider unblocking package navit.

The new release 0.5.0~svn5126+dfsg.1-3 introduces three segfault fixes
related to bugs #682553 and #703110.

Debdiff attached.

Many thanks in advance.

unblock navit/0.5.0~svn5126+dfsg.1-3

- -- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-486
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJRRuXYAAoJEO/obGx//s+D1MkH/Rq6u2/w0O1CrLvX9ml2eoz9
FCMQu5O/ozZYzMPtqd+hB9+WGir6J2yLAngmzCa9vqcPLz6e83fFTJmyXHXQtGi4
+pNtJ4MkK5CuN7MoH1hSK27eygKuNhr+Yl6Mah9SVVKp4r6DXX9vn3nxKvGRbrsQ
vf//GC8A7LB7yW/V9vO1Lh/pAFh2nDL6c8FJ/9RYE4F4gPxScQN1W91C1sHI95Bn
V4eBtTmJuccZvzj8dEOmudBN8lawI7RjvM1IhqNGiXXZbhkWHZTSXqu4EQwIBkb3
lfRfTbhG0y7y/DWxB5i/DBHWW6w+rCRbmBlAb2lJT/YiWNBvATTYUBkGNlZyn80=
=C0Fa
-END PGP SIGNATURE-
diff -Nru navit-0.5.0~svn5126+dfsg.1/debian/changelog navit-0.5.0~svn5126+dfsg.1/debian/changelog
--- navit-0.5.0~svn5126+dfsg.1/debian/changelog	2012-06-09 22:11:21.0 +0200
+++ navit-0.5.0~svn5126+dfsg.1/debian/changelog	2013-03-17 17:49:14.0 +0100
@@ -1,3 +1,16 @@
+navit (0.5.0~svn5126+dfsg.1-3) unstable; urgency=low
+
+  * New patches:
++ maptool-uninitialised-values.patch:
+  Fix segfault in maptool due to uninitialised values (Closes: #682553)
++ keep-null-gps-vehicle.patch:
+  Don't deactivate Null GPS vehicle when position is set manually
+  (fix a segfault)
++ check-empty-dest-map.patch:
+  Don't remove previous destination when there is none (Closes: #703110)
+
+ -- Gilles Filippini p...@debian.org  Sun, 17 Mar 2013 17:49:06 +0100
+
 navit (0.5.0~svn5126+dfsg.1-2) unstable; urgency=low
 
   * d/rules:
diff -Nru navit-0.5.0~svn5126+dfsg.1/debian/patches/check-empty-dest-map.patch navit-0.5.0~svn5126+dfsg.1/debian/patches/check-empty-dest-map.patch
--- navit-0.5.0~svn5126+dfsg.1/debian/patches/check-empty-dest-map.patch	1970-01-01 01:00:00.0 +0100
+++ navit-0.5.0~svn5126+dfsg.1/debian/patches/check-empty-dest-map.patch	2013-03-17 16:33:53.0 +0100
@@ -0,0 +1,25 @@
+Description: Don't remove last dest when destination map is empty
+Author: Gilles Filippini p...@debian.org
+Bug-Debian: http://bugs.debian.org/703110
+Last-Update: 2013-03-12
+Index: navit/navit/bookmarks.c
+===
+--- navit.orig/navit/bookmarks.c	2013-03-11 23:55:15.0 +0100
 navit/navit/bookmarks.c	2013-03-12 19:53:34.0 +0100
+@@ -797,10 +797,12 @@
+ 
+ 	/* First, remove the last former_destination */
+ 	former_destinations = read_former_destination_map_as_list(former_destination_map);
+-	dest = g_list_last(former_destinations)-data;
+-	former_destinations = g_list_remove(former_destinations, dest);
+-	free_former_destination(dest);
+-	write_former_destinations(former_destinations, former_destination_file, map_projection(former_destination_map));
++	if (former_destinations != NULL) {
++		dest = g_list_last(former_destinations)-data;
++		former_destinations = g_list_remove(former_destinations, dest);
++		free_former_destination(dest);
++		write_former_destinations(former_destinations, former_destination_file, map_projection(former_destination_map));
++	}
+ 
+ 	/* Then, append the new one */
+ 	bookmarks_append_destinations(former_destination_map, former_destination_file, c, count, type, description, limit);
diff -Nru navit-0.5.0~svn5126+dfsg.1/debian/patches/keep-null-gps-vehicle.patch navit-0.5.0~svn5126+dfsg.1/debian/patches/keep-null-gps-vehicle.patch
--- navit-0.5.0~svn5126+dfsg.1/debian/patches/keep-null-gps-vehicle.patch	1970-01-01 01:00:00.0 +0100
+++ navit-0.5.0~svn5126+dfsg.1/debian/patches/keep-null-gps-vehicle.patch	2013-03-17 17:39:16.0 +0100
@@ -0,0 +1,19 @@
+Description: Don't unset vehicle profile on set_position
+ set_position with no vehicle profile segfaults.
+Author: Gilles Filippini p...@debian.org
+Last-Update: 2013-03-17
+Index: navit/navit/gui/internal/gui_internal.c
+===
+--- navit.orig/navit/gui/internal/gui_internal.c	2013-03-17 16:36:36.0 +0100
 navit/navit/gui/internal/gui_internal.c	2013-03-17 16:42:25.0 +0100
+@@ -3736,7 +3736,9 @@
+ 		struct attr vehicle, source;
+ 		int deactivate=0;
+ 		if (navit_get_attr(this-nav, attr_vehicle, vehicle, NULL)  vehicle.u.vehicle  
+-!(vehicle_get_attr(vehicle.u.vehicle, attr_source, source, NULL)  source.u.str  !strcmp(demo://,source.u.str))) 
++!(vehicle_get_attr(vehicle.u.vehicle, attr_source, source, NULL)  source.u.str 
++	!strcmp(demo://,source.u.str