Bug#825895: [Pkg-octave-devel] Bug#825895: octave-interval: FTBFS: debian/rules:10: *** target file 'install-docs' has both : and :: entries. Stop.

2016-06-03 Thread Rafael Laboissière 

* Sébastien Villemot  [2016-05-31 10:45]:


Le mardi 31 mai 2016 à 10:34 +0200, Oliver Heimlich a écrit :

On 31.05.2016 10:11, Chris Lamb wrote:

Source: octave-interval
Version: 1.4.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

octave-interval fails to build from source in unstable/amd64:


This is caused by the new version of octave-pkg-dev in unstable and gets 
fixed by Rafael's last commit (58eb05c71b08bd57b5141ab49574745d0577d323).


How urgent is it to upload a new version of octave-interval to unstable? 
Version 1.5.0 is already on its way, but I would like to wait until the 
release is approved upstream.


It's a bug of severity serious, so I'd say it's rather urgent. And the 
fix is trivial. But of course it can wait a few days.


So it's up to you to decide whether uploading 1.4.1-2 or 1.5.0-1.


This is partly my fault.  I should have coordinated the releases of 
octave-pkg-dev 1.4.0 and octave-interval 1.4.1-2.  At any rate, I think 
this problem will be fixed soon.


Rafael

Bug#826390: [Pkg-octave-devel] Bug#826390: Bug#826390: octave-epstk: FTBFS: Can't call method "get" on an undefined value at /usr/share/octave/debian/dh/octave-pkg-helper line 38.

2016-06-05 Thread Rafael Laboissière 

Control: reassign -1 octave-pkg-dev 1.4.0
Control: tags -1 + confirmed

* Oliver Heimlich  [2016-06-05 12:47]:


On 05.06.2016 10:27, Chris Lamb wrote:

Source: octave-epstk
Version: 2.4-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

octave-epstk fails to build from source in unstable/amd64:

  [..]


  /usr/share/octave/debian/dh/octave-pkg-helper
  Can't call method "get" on an undefined value at 
/usr/share/octave/debian/dh/octave-pkg-helper line 38.
  debian/rules:37: recipe for target 'install/octave-epstk' failed
  make: *** [install/octave-epstk] Error 2

  [..]


This is caused by revision 8f5df208093d1cd00b7ff4955e922d770cca6912 in 
octave-pkg-dev and because octave-epstk has no DESCRIPTION file.


Before octave-pkg-dev 1.4.0 the missing DESCRIPTION file has been ignored.


I confirm the diagnosis above.  I am hereby reassigning this bug report 
to octave-pkg-dev.  A fix is underway.


Thanks,

Rafael

Bug#832415: Further information: upstream software works fine

2016-08-03 Thread Rafael Laboissière 

* Eric S Fraga <e.fr...@ucl.ac.uk> [2016-07-25 17:50]:

Just a quick update: building the latest upstream version of octave 
along with the parallel package results in a system that works as it 
should.  No errors at all.


You mean, building Octave from source?

Which version?

Thanks,

Rafael Laboissière

Bug#832415: octave-parallel: Any attempt to use parcellfun leads to unhandled error in subprocesses

2016-08-03 Thread Rafael Laboissière 

* Eric S Fraga <e.fr...@ucl.ac.uk> [2016-07-25 10:36]:


Package: octave-parallel
Version: 3.1.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Any attempt to use parcellfun leads to errors such as these:

warning: parcellfun: unhandled error in subprocess 1 
warning: called from 
   parcellfun at line 291 column 9 
   [...] traceback on my own code elided 
error: '__exit__' undefined near line 311 column 7


Could you please provide a script that replicates the bug?

Thanks,

Rafael Laboissière

Bug#832415: Further information: upstream software works fine

2016-08-13 Thread Rafael Laboissière 

Control: tags -1 + unreproducible moreinfo

* Rafael Laboissière <raf...@debian.org> [2016-08-08 16:29]:

Could you please provide a script that triggers the bug, as I asked in 
a previous message?


I cannot reproduce the bug.  The simple example below works for me with 
the versions currently in unstable (octave 4.0.3-1 and octave-parallel 
3.1.0-1):


   octave:1> pkg load parallel
   octave:2> parcellfun (2, @(x) x^2, {1, 2})
   parcellfun: 2/2 jobs done

Does it work for you?

Rafael Laboissière

Bug#832415: Further information: upstream software works fine

2016-08-08 Thread Rafael Laboissière 

* Eric S Fraga <e.fr...@ucl.ac.uk> [2016-08-07 18:30]:


On Wednesday,  3 Aug 2016 at 12:17, Rafael Laboissière wrote:

* Eric S Fraga <e.fr...@ucl.ac.uk> [2016-07-25 17:50]:

Just a quick update: building the latest upstream version of octave 
along with the parallel package results in a system that works as it 
should.  No errors at all.


You mean, building Octave from source?

Which version?


Yes, from source.  4.0.3.


Ok, thanks.

Could you please provide a script that triggers the bug, as I asked in a 
previous message?


Best,

Rafael Laboissière

Bug#847974: xmds2: FTBFS in stretch

2017-01-14 Thread Rafael Laboissière 

* Rafael Laboissière <raf...@debian.org> [2017-01-14 12:35]:


* Gilles Filippini <p...@debian.org> [2017-01-14 10:18]:


Control: reassign -1 liboctave-dev
Control: tag -1 + patch

On Sat, 14 Jan 2017 09:57:42 +0100 Gilles Filippini <p...@debian.org> wrote:


[snip]

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.


Attached.

Raphaël, it has to be fixed before 2016-01-18 to prevent removal of 
xmds2 from testing. I can NMU if needed.


I am taking care of it.

Thanks for the patch,


Sébastien went faster than me.  Great!

Rafael

Bug#847974: xmds2: FTBFS in stretch

2017-01-14 Thread Rafael Laboissière 

* Gilles Filippini  [2017-01-14 10:18]:


Control: reassign -1 liboctave-dev
Control: tag -1 + patch

On Sat, 14 Jan 2017 09:57:42 +0100 Gilles Filippini  wrote:


[snip]

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.


Attached.

Raphaël, it has to be fixed before 2016-01-18 to prevent removal of 
xmds2 from testing. I can NMU if needed.


I am taking care of it.

Thanks for the patch,

Rafael

Bug#871214: [Pkg-octave-devel] Bug#871214: octave-image FTBFS on i386: test hangs

2017-08-10 Thread Rafael Laboissière 

* Adrian Bunk  [2017-08-07 01:57]:


Source: octave-image
Version: 2.6.1-1
Severity: serious
Tags: buster sid

Some recent change in unstable and buster makes octave-image FTBFS on i386:

 https://tests.reproducible-builds.org/debian/history/octave-image.html
 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/octave-image.html

 ...
 Checking CC files ...
 warning: function /build/1st/octave-image-2.6.1/inst/private/iscolormap.m 
shadows a core library function
 warning: called from
/tmp/filePMKFm8 at line 1 column 1
 [__spatial_filtering__]
 PASSES 21 out of 21 tests
 [graycomatrix]
 PASSES 2 out of 2 tests
 [watershed]
 * test
 im = [
 2 330 2
 330 330
   2553130 4
 2   2553130
 1 2   255 5];

 labeled8 = [
 1 1 0 3
 1 1 0 3
 0 0 0 0
 2 2 0 4
 2 2 0 4];
 assert (watershed (im), labeled8);
 assert (watershed (im, 8), labeled8);
 ! test failed
 ASSERT errors for:  assert (watershed (im),labeled8)

  Location  |  Observed  |  Expected  |  Reason
   (3,4)  30 Abs err 3 exceeds tol 0
   (4,4)  04 Abs err 4 exceeds tol 0
 [bwdist]
 Sat Sep  8 05:36:25 UTC 2018 - pbuilder was killed by timeout after 18h.


I would guess that the culprit is the following unit test in bwdist:

## The quasi-euclidean method is apparently sensitive to a machine precision
## error that happens in x86 systems only. This test will cause an endless
## loop in case of a regression.
%!test
%! bw = [  0   1   1   0   0   0   1   0
%! 0   0   0   0   0   0   0   0
%! 1   1   0   0   0   0   0   0
%! 0   0   0   0   0   0   1   0
%! 0   0   0   0   1   0   0   1
%! 0   0   0   0   0   0   0   0
%! 1   0   0   0   0   0   0   0
%! 0   0   1   0   0   1   1   0];
%! out = single ([
%! 1.0   0.0   0.0   1.0   2.0   1.0   0.0   1.0
%! 1.0   1.0   1.0   sqrt(2)   sqrt(2)+1 sqrt(2)   1.0   sqrt(2)
%! 0.0   0.0   1.0   2.0   2.0   sqrt(2)   1.0   sqrt(2)
%! 1.0   1.0   sqrt(2)   sqrt(2)   1.0   1.0   0.0   1.0
%! 2.0   2.0   2.0   1.0   0.0   1.0   1.0   0.0
%! 1.0   sqrt(2)   2.0   sqrt(2)   1.0   sqrt(2)   sqrt(2)   1.0
%! 0.0   1.0   1.0   sqrt(2)   sqrt(2)   1.0   1.0   sqrt(2)
%! 1.0   1.0   0.0   1.0   1.0   0.0   0.0   1.0
%! ]);
%! assert (bwdist (bw, "quasi-euclidean"), out);

Should we run the test above only on non-x86 architectures?

Rafael





___ 
Pkg-octave-devel mailing list 
pkg-octave-de...@lists.alioth.debian.org 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel

Bug#871214: [Pkg-octave-devel] Bug#871214: Bug#871214: Bug#871214: octave-image FTBFS on i386: test hangs

2017-08-10 Thread Rafael Laboissière 


* Sébastien Villemot <sebast...@debian.org> [2017-08-10 11:06]:


Le jeudi 10 août 2017 à 09:31 +0200, Rafael Laboissière a écrit :

* Adrian Bunk <b...@debian.org> [2017-08-07 01:57]:



Source: octave-image
Version: 2.6.1-1
Severity: serious
Tags: buster sid

Some recent change in unstable and buster makes octave-image FTBFS on i386:

 https://tests.reproducible-builds.org/debian/history/octave-image.html
 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/octave-image.html

 [snip]
 [bwdist]
 Sat Sep  8 05:36:25 UTC 2018 - pbuilder was killed by timeout after 18h.


I would guess that the culprit is the following unit test in bwdist:

 [snip]



Should we run the test above only on non-x86 architectures?


I would rather patch the test to allow for some tolerance margin.


I suspect that the test enters a infinite loop and, therefore, changing 
the tolerance margin will not help here.


Rafael

Bug#871907: praat FTBFS on non-amd64

2017-08-13 Thread Rafael Laboissière 

Control: tags -1 confirmed pending

* Adrian Bunk  [2017-08-12 15:07]:


Source: praat
Version: 6.0.30-1
Severity: serious
Tags: patch

https://buildd.debian.org/status/package.php?p=praat=sid

... 
 g++ -std=c++11 -DNO_GUI -DNO_NETWORK -D_FILE_OFFSET_BITS=64 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -DUNIX -Dlinux -Werror=missing-prototypes -Werror=implicit -Wreturn-type -Wunused -Wunused-parameter -Wuninitialized -O3 -g1 -pthread -Wshadow -g -O2 -fdebug-prefix-map=/<>/sys=. -fstack-protector-strong -Wformat -Werror=format-security -I ../sys -I ../num -I ../dwsys -I ../kar -I ../external/portaudio -I ../external/flac -I ../external/mp3  -c -o melder_audio.o melder_audio.cpp 
 In file included from /usr/include/glib-2.0/glib/galloca.h:32:0, 
 from /usr/include/glib-2.0/glib.h:30, 
 from /usr/include/pango-1.0/pango/pango-coverage.h:25, 
 from /usr/include/pango-1.0/pango/pango-font.h:25, 
 from /usr/include/pango-1.0/pango/pango-attributes.h:25, 
 from /usr/include/pango-1.0/pango/pango.h:25, 
 from Gui.h:62, 
 from melder_audio.cpp:46: 
 /usr/include/glib-2.0/glib/gtypes.h:32:10: fatal error: glibconfig.h: No such file or directory 
 #include  
 ^~ 
 compilation terminated. 
 : recipe for target 'melder_audio.o' failed 
 make[3]: *** [melder_audio.o] Error 1



Fix is attached.


Thanks for the heads up and for the patch.  I have already noticed the 
problem earlier today and uploaded a fixed version 6.0.30-2 to unstable. 
Unfortunately, I patched the package in a slightly worse way than what 
you propose, by giving "gtk+-2.0" instead of "pangocairo" as argument to 
pkg-config.  My patch seems to work, though.  Anyway, I will release a 
new version of the package that integrates your more elegant patch.


Rafael

Bug#865241: [Pkg-octave-devel] Bug#865241: Please update dependencies from latex-xcolor to tl-latex-recommended

2017-06-20 Thread Rafael Laboissière 

Control: tags -1 + fixed-in-experimental

Thanks for the bug report.  Fixed version 0.1.5-3 is now in experimental. 
It will be uploaded to unstable once the transition Octave 4.0 → 4.2 will 
be sorted out.


Rafael

* norb...@preining.info  [2017-06-20 14:05]:


Source: octave-ocs
Version: 0.1.5-2
Severity: serious
Justification: FTBFS
X-Debbugs-CC: debian-tex-ma...@lists.debian.org

Dear maintainer,

latex-xcolor has been a dummy transitional package now since 2 releases 
(since oldstable), and has been dropped in current unstable.


Please update your dependencies to texlive-latex-recommended.

Thanks

Norbert

___

Pkg-octave-devel mailing list 
pkg-octave-de...@lists.alioth.debian.org 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel

Bug#865241: [Pkg-octave-devel] Bug#865241: Bug#865241: Please update dependencies from latex-xcolor to tl-latex-recommended

2017-06-20 Thread Rafael Laboissière 

* Sébastien Villemot <sebast...@debian.org> [2017-06-20 11:13]:


Le mardi 20 juin 2017 à 10:21 +0200, Rafael Laboissière a écrit :


Control: tags -1 + fixed-in-experimental

Thanks for the bug report.  Fixed version 0.1.5-3 is now in 
experimental.  It will be uploaded to unstable once the transition 
Octave 4.0 → 4.2 will  be sorted out.


Rafael, I don't see the point in uploading it to experimental. Since 
the package now FTBFS in unstable, a binNMU will not work, and a 
sourceful upload will therefore be required for the transition. So 
let's do it now rather than later.


You are right, I should have uploaded it to unstable, I just got 
confused.  I will soon upload version 1.0.5-4 to unstable.


Rafael

Bug#876698: [Pkg-octave-devel] Bug#876698: octave-image FTBFS on 32bit: test failures

2017-11-07 Thread Rafael Laboissière 

Control: reopen -1
Control: notfixed -1 1.3.2-3

Oops, I closed the wrong bug report.

Sorry for the confusion.

Rafael

* Rafael Laboissière <raf...@debian.org> [2017-11-05 09:05]:


Control: fixed -1 1.3.2-3

* Adrian Bunk <b...@debian.org> [2017-09-25 01:25]:


Source: octave-image
Version: 2.6.1-4
Severity: serious

https://buildd.debian.org/status/package.php?p=octave-image=sid


This problem is fixed in version 1.3.2-3 of the package, which builds 
correctly on i386:


https://buildd.debian.org/status/fetch.php?pkg=octave-signal=i386=1.3.2-3=1509837814=0

Rafael

Bug#890098: FTBFS: imagemagick in Build-Depends-Indep but needed for arch build

2018-02-11 Thread Rafael Laboissière 

* Steve Langasek <steve.langa...@canonical.com> [2018-02-10 23:50]:


Package: octave-interval
Version: 3.1.0-4
Severity: serious
Tags: patch
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainer,

The latest upload of octave-interval fails to build on all architectures 
currently on the autobuilders because, with the move to dh-octave, 
imagemagick is now needed as part of the arch build, not just the 
arch-independent build:


[snip]


Thanks for the bug report.  Indeed, I screwed things up in commit 
e22b79d.  I will look at this soon.


Rafael Laboissière

Bug#902198: octave-odepkg FTBFS with octave 4.4.0

2018-07-17 Thread Rafael Laboissière 

* Drew Parsons  [2018-07-17 00:44]:


On Tue, 2018-07-17 at 00:30 +0800, Drew Parsons wrote:

On Mon, 2018-07-16 at 13:54 +0200, Rafael Laboissière wrote:


I tried to build the package using the tip of the Mercurial 
repository




Weird though, https://wiki.octave.org/Odepkg points at

 https://bitbucket.org/odepkg/odepkg


Thanks for pointing this out.


Is this a fork? The recent commits diverge from sourceforge.


Indeed, this seems to be a fork that is actively maintained.


(more importantly, does it build, and pass tests?)


It builds, but the tests get stuck in my system.  You can try it yourself:

   gbp clone g...@salsa.debian.org:pkg-octave-team/octave-odepkg.git
   cd octave-odepkg
   git checkout upstream-hg
   git checkout hg
   gbp dch --upstream-branch=upstream-hg --debian-branch=hg
   gbp export-orig
   debuild -us -uc

Rafael

Bug#902198: octave-odepkg FTBFS with octave 4.4.0

2018-07-16 Thread Rafael Laboissière 

* Sébastien Villemot  [2018-06-28 21:57]:


On Fri, Jun 29, 2018 at 03:04:56AM +0800, Drew Parsons wrote:


Or does latest the upstream git work, should we just grab that?


I remember having tried to apply some upstream patches, but maybe not the 
second one that you linked to. In any case, someone has to try again.


I tried to build the package using the tip of the Mercurial repository 
for the odepkg package [1].  After some tweaks in the documentation, I 
was able to compile the source code, but the unit tests fail miserably.


I just noticed that odepkg was removed from the list of supported 
Octave-Forge packages [2].  It seems that octave-odepkg will become a 
candidate for removal from Debian.  If this happens, octave-ocs will have 
to be remove as well.


Rafael

[1] https://sourceforge.net/p/octave/odepkg/ci/default/tree/
[2] https://octave.sourceforge.io/packages.php

Bug#903105: nlopt: FTBFS with to octave 4.4.0

2018-07-07 Thread Rafael Laboissière 

* Andreas Tille  [2018-07-06 10:59]:

No idea whether Debian Octave Group 
 is read by a human beeing.


It is better to use the debian-octave mailing list for this kind of 
discussion.



On Fri, Jul 06, 2018 at 09:59:46AM +0200, Andreas Tille wrote:


Package: nlopt
Severity: serious
Justification: FTBFS

when I team uploaded nlopt on Tue, 29 May 2018 it was building fine.  At 2018-06-09 
octave 4.4.0-3 was uploaded to unstable.  When I build today the build fails with


 ...
 /build/nlopt-2.4.2+dfsg/octave/nlopt_optimize-oct.cc:82:36: error: 'class 
octave_function' has no member named 'do_multi_index_op'; did you mean 
'do_index_op'?
   octave_value_list res = data->f->do_multi_index_op(gradient ? 2 : 1, args);
^
do_index_op
...

I wonder whether there is some upgrade path for this API change in octave.


Actually, the patch d/p/octave4.4.patch, created by Sébastien was 
intended to fix the problem above.


Indeed, the version of nlopt current in Git (@Salsa.d.o) builds 
correctly for me in a clean sid chroot with octave 4.4.0-3.  Could you 
please send your build log to us?


Cheers,

Rafael

Bug#895739: psychtoolbox-3: FTBFS: Include deprecated xlocale.h

2018-04-15 Thread Rafael Laboissière 

Source: psychtoolbox-3
Version: 3.0.14.20170103+git6-g605ff5c.dfsg1-1
Severity: serious
Tags: patch upstream
Justification: FTBFS

Package psychtoolbox-3 is currently failing to build from source because 
file PsychSourceGL/Source/Common/Screen/SCREENDrawText.c includes 
xlocale.h, which has been removed from glibc >= 2.26.


The patch attached to this bug report fixes the problem.  I will soon 
upload a fixed package to unstable, which will also fix Bug#890087.


Best,

Rafael Laboissière

-- System Information: 
Debian Release: buster/sid 
 APT prefers testing 
 APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental'), (550, 'stable'), (500, 'oldstable') 
Architecture: amd64 (x86_64) 
Foreign Architectures: i386


Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Description: Do not include xlocale.h, deprecated in glibc >= 2.26
Author: Rafael Laboissiere <raf...@debian.org>
Forwarded: no
Last-Update: 2018-04-15

--- psychtoolbox-3-3.0.14.20170103+git6-g605ff5c.dfsg1.orig/PsychSourceGL/Source/Common/Screen/SCREENDrawText.c
+++ psychtoolbox-3-3.0.14.20170103+git6-g605ff5c.dfsg1/PsychSourceGL/Source/Common/Screen/SCREENDrawText.c
@@ -1814,7 +1814,7 @@ const char* PsychGetUnicodeTextConversio
 
 // POSIX systems Linux and OS/X:
 #include 
-#include 
+// #include 
 
 static locale_tdrawtext_locale = NULL;
 static chardrawtext_localestring[256] = { 0 };

Bug#904669: xmds2: autopkgtest times out since 2018-07-19

2018-09-03 Thread Rafael Laboissière 

Hi Paul,

* Paul Gevers  [2018-09-02 18:21]:


Hi Rafael,

On 02-09-18 18:10, Rafael Laboissière wrote:


I just uploaded version 2.2.3+dfsg-11 of the xmds2 package to unstable. 
The time-out problem seems to be fixed in this version.  Could you 
please remove xmds2 from the blacklist to see what happens?


I'll manually trigger a run (actually already did before even checking 
if the package was available). If it succeeds, I'll lift the blacklist.


Did it work?  Unfortunately, the autobuild failed [*].  It is certainly a 
problem related to MPI and it is very hard to debug.  I was convinced 
that I have fixed it in version 2.2.3+dfsg-11 of the package.


Best,

Rafael

[*] 
https://buildd.debian.org/status/fetch.php?pkg=xmds2=all=2.2.3%2Bdfsg-11=1535907154=0

Bug#904669: xmds2: autopkgtest times out since 2018-07-19

2018-09-02 Thread Rafael Laboissière 

* Paul Gevers  [2018-07-26 14:28]:


 Source: xmds2
 Version: 2.2.3+dfsg-10
 X-Debbugs-CC: debian...@lists.debian.org
 User: debian...@lists.debian.org
 Usertags: timeout

Dear maintainers,

Since 2018-07-19 the autopkgtest of your package times out (after 2:47h) 
on ci.debian.net. I have copied the output below.


Could you please make your autopkgtest robust against this? The 
autpkgtest used to pass in around 13 minutes, so something really 
changed. (gcc-8 was introduced as default around that time if I am correct).


Don't hesitate to ask for help for the Debian CI team² if you need help 
solving this issue.


I will blacklist this package on the ci.debian.net infrastructure and 
will remove the blacklist once this bug is fixed.


I just uploaded version 2.2.3+dfsg-11 of the xmds2 package to unstable. 
The time-out problem seems to be fixed in this version.  Could you 
please remove xmds2 from the blacklist to see what happens?


Thanks,

Rafael

Bug#938925: xmds2: fails mpi hdf5 tests

2019-09-09 Thread Rafael Laboissière 

Control: tags -1 confirmed upstream
Control: forwarded -1 https://sourceforge.net/p/xmds/mailman/message/36758833/

* Drew Parsons  [2019-08-30 17:02]:


Source: xmds2
Version: 3.0.0+dfsg-2
Severity: serious

xmds2's mpi/hdf5 tests (test_mpi_xsilloading_hdf5 etc) have recently started 
failing.


h5py was recently (2.9.0-4) updated to build with mpi support, that is 
built against libhdf5-mpi-dev (aided by mpi4py) rather than libhdf5-dev.


I don't know if it means xmds2 just needs to be rebuilt against the 
new h5py/mpi4py packages or if the problem is more complex than that.


The xmds2 autopkgtest failure is holding back h5py with mpi support 
from migrating to testing.


Thanks for this bug report.  I established a preliminary diagnostic of 
the problem and kept the upstream authors informed.


Rafael Laboissière

Bug#948167: plplot: autopkgtest regression on arm64: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory

2020-01-05 Thread Rafael Laboissière 

* Paul Gevers  [2020-01-04 21:47]:


Source: plplot
Version: 5.15.0+dfsg-10
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of plplot the autopkgtest of plplot fails in 
testing on arm64 when that autopkgtest is run with the binary packages 
of plplot from unstable. It passes when run with only packages from 
testing. In tabular form: 
  passfail 
plplot from testing5.15.0+dfsg-10 
all others from testingfrom testing


I copied some of the output at the bottom of this report. The same error 
message is present in older versions, but this time the test actually 
fails on it.


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://qa.debian.org/excuses.php?package=plplot

https://ci.debian.net/data/autopkgtest/testing/arm64/p/plplot/3862955/log.gz 
autopkgtest [01:14:56]: test plplot-test: [--- 
cd c; make 
make[1]: Entering directory 
'/tmp/autopkgtest-lxc.jq53ogp7/downtmp/autopkgtest_tmp/c' 
/usr/bin/cc  -g -O2 
-fdebug-prefix-map=/build/plplot-KD6Nbq/plplot-5.15.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/octave-5.1.0/octave/.. -I/usr/include/octave-5.1.0/octave 
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/octave-5.1.0/octave/.. 
-I/usr/include/octave-5.1.0/octave x00c.c -o x00c  -I/usr/include/plplot 
-lplplot /usr/lib/x86_64-linux-gnu/libm.so 
cc: error: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory 
make[1]: *** [Makefile:97: x00c] Error 1 
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.jq53ogp7/downtmp/autopkgtest_tmp/c' 
make: *** [Makefile:31: c/x01c] Error 2 
autopkgtest [01:14:56]: test plplot-test: ---]


Thanks for this bug report, Paul.

This bug is caused by commit d8ce3ed [1], pushed more than a year ago to 
the Git repository.  In this commit, all examples sources were moved into 
the plplot-doc package, which is Arch:all.  However, the files under the 
examples directory (mainly the Makefiles) are hardcoded for use in a 
specific architecture (namely x86_64-linux-gnu).


I am putting Ole Streicher, the author of the commit, in Cc to this 
reply.


Reverting the commit would fix the present bug, but will introduce the 
bad side effect of making debian/tests/plplot-test fail.  This unit test 
script has the line:


   cp -r /usr/share/doc/plplot-doc/examples/* .

Reverting the commit would scatter back the example file across several 
packages and it will be difficult to adjust plplot-test for that.


A "simple" solution would be to create a new package plplot-examples, with 
Arch:any, containing the examples/ directory that is currently in 
/usr/share/doc/plplot-doc/.


@Ole: would you agree with this change?

Best,

Rafael Laboissière

[1] 
https://salsa.debian.org/science-team/plplot/commit/d8ce3ed802eccecef8583d03a25712069f0643d2

Bug#948167: plplot: autopkgtest regression on arm64: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory

2020-01-05 Thread Rafael Laboissière 

Control: tags -1 confirmed

* Ole Streicher  [2020-01-05 14:19]:


On 05.01.20 10:32, Rafael Laboissière wrote:

A "simple" solution would be to create a new package plplot-examples, 
with Arch:any, containing the examples/ directory that is currently in 
/usr/share/doc/plplot-doc/.


@Ole: would you agree with this change?


I agree that this is the best solution, so feel free to implement it.


Ok, I will do it.  Just three comments:

1) The package will have to go through the NEW queue after upload, 
because of the new binary package.


2) The master branch in the Git repository contains the version currently 
in experimental.  I created a new branch "unstable" for updating the 
package in unstable.  In particular, for generating the d/changelog 
entries, one needs to do: "gbp dch --debian-branch=unstable".


3) Since 5.15.0+dfsg-11 has been already uploaded to experimental, that 
version cannot be used for uploading to unstable.  I will use the 
versioning scheme 5.15.0+dfsg-10+unstable1, unless you have any 
objections.


Best,

Rafael

Bug#948167: plplot: autopkgtest regression on arm64: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory

2020-01-05 Thread Rafael Laboissière 

Control: tags -1 pending

* Rafael Laboissière  [2020-01-05 15:28]:

1) The package will have to go through the NEW queue after upload, 
because of the new binary package.


Indeed: 
https://ftp-master.debian.org/new/plplot_5.15.0+dfsg-10+gnat8+1.html


I am hereby tagging this bug report as "pending".

Best,

Rafael

Bug#948167: plplot: autopkgtest regression on arm64: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory

2020-01-05 Thread Rafael Laboissière 

* Rafael Laboissière  [2020-01-05 15:28]:

3) Since 5.15.0+dfsg-11 has been already uploaded to experimental, 
that version cannot be used for uploading to unstable.  I will use the 
versioning scheme 5.15.0+dfsg-10+unstable1, unless you have any 
objections.


I changed my mind.  I just uploaded version 5.15.0+dfsg-10+gnat8+1 to 
unstable . This is a more sensible versioning scheme, because it reflects 
what the unstable branch actually is: a build against gnat-8 instead of 
gnat-9 (as with version 5.15.0+dfsg-11 in experimental).


Rafael

Bug#961334: octave-mapping FTBFS on big endian: test failures

2020-05-28 Thread Rafael Laboissière 

* Adrian Bunk  [2020-05-23 15:33]:


Source: octave-mapping
Version: 1.4.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=octave-mapping=s390x=1.4.0-1=1586986257=0

... 
shaperead: file /tmp/oct-fdWy3e.dbf couldn't be read; 
  no attributes appended 
! test failed 
ASSERT errors for:  assert (sum (ism),numel (ism))


 Location  |  Observed  |  Expected  |  Reason
()   35 Abs err 2 exceeds tol 0 by 2
... 
shaperead: file /tmp/oct-mxym2n.dbf couldn't be read; 
  no attributes appended 
! test failed 
ASSERT errors for:  assert (sum (ism),numel (ism))


 Location  |  Observed  |  Expected  |  Reason
()   46 Abs err 2 exceeds tol 0 by 2
... 
Summary: 386 tests, 384 passed, 0 known failures, 0 skipped 
Some tests failed.  Giving up... 
make: *** [debian/rules:5: binary-arch] Error 1


The bug is actually in the dbfwrite and dbfread functions in the 
octave-io package, which are used in the unit test of function shapewrite 
of the octave-mapping package, whose failure is shown above.


I filed a bug report in the upstream bug tracker, regarding this issue: 
https://savannah.gnu.org/bugs/index.php?58457


I will patch the octave-io package, in order to fix the problem.

Best,

Rafael







debian-s390 is Cc'ed on this bug.

Bug#961334: octave-mapping FTBFS on big endian: test failures

2020-05-28 Thread Rafael Laboissière 

* Adrian Bunk  [2020-05-28 12:40]:


Control: reassign -1 octave-io 2.6.1-1
Control: affects -1 src:octave-mapping
Control: close -1 2.6.1-2

On Thu, May 28, 2020 at 09:32:04AM +0200, Rafael Laboissière wrote:

* Adrian Bunk  [2020-05-23 15:33]:


Source: octave-mapping
Version: 1.4.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=octave-mapping=s390x=1.4.0-1=1586986257=0

... shaperead: file /tmp/oct-fdWy3e.dbf couldn't be read;   no 
attributes appended ! test failed ASSERT errors for:  assert (sum 
(ism),numel (ism))


 Location  |  Observed  |  Expected  |  Reason
()   35 Abs err 2 exceeds tol 0 by 2
... shaperead: file /tmp/oct-mxym2n.dbf couldn't be read;   no 
attributes appended ! test failed ASSERT errors for:  assert (sum 
(ism),numel (ism))


 Location  |  Observed  |  Expected  |  Reason
()   46 Abs err 2 exceeds tol 0 by 2
... Summary: 386 tests, 384 passed, 0 known failures, 0 skipped Some 
tests failed.  Giving up... make: *** [debian/rules:5: binary-arch] 
Error 1


The bug is actually in the dbfwrite and dbfread functions in the octave-io 
package, which are used in the unit test of function shapewrite of the 
octave-mapping package, whose failure is shown above.


I filed a bug report in the upstream bug tracker, regarding this issue: 
https://savannah.gnu.org/bugs/index.php?58457


I will patch the octave-io package, in order to fix the problem.


Thanks, octave-mapping built now. 
I am updating the bug metadata.


I uploaded version 1.4.0-2 of the octave-mapping package, which 
build-depends on octave-io >= 2.6.1-2.


Thanks,

Rafael

Bug#976325: [ans...@debian.org: Bug#976325: src:libgdf: invalid maintainer address]

2020-12-03 Thread Rafael Laboissière 

Dear Yaroslav and Michael,

Are you aware of the problem related in Bug#976325, regarding the email
address t...@neuro.debian.net?

Best,

Rafael Laboissière

- Forwarded message from Ansgar  -

From: Ansgar 
Subject: Bug#976325: src:libgdf: invalid maintainer address
Date: Thu, 03 Dec 2020 12:18:19 +0100
To: sub...@bugs.debian.org
Reply-To: Ansgar , 976...@bugs.debian.org
Message-ID: 

 Source: libgdf
 Version: 0.1.3-5
 Severity: serious
 X-Debbugs-Cc: Rafael Laboissière 

The maintainer address is invalid, see below.

Ansgar


This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es)
failed:

  t...@neuro.debian.net
    retry timeout exceeded



Reporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;t...@neuro.debian.net
Status: 5.0.0


- End forwarded message -

Bug#976325: [ans...@debian.org: Bug#976325: src:libgdf: invalid maintainer address]

2020-12-07 Thread Rafael Laboissière 

* Yaroslav Halchenko  [2020-12-07 11:06]:


mail server is back online so we are back to enjoying all the mail ;-)


Thanks !

Rafael

Bug#974099: octave-database: diff for NMU version 2.4.4-3.1

2020-11-14 Thread Rafael Laboissière 

* Sebastian Ramacher  [2020-11-14 12:40]:

I couldn't push them directly, so I've created a MR: 
https://salsa.debian.org/pkg-octave-team/octave-database/-/merge_requests/1


Great, thanks. It is merged now.

Best,

Rafael Laboissière

Bug#974099: octave-database: diff for NMU version 2.4.4-3.1

2020-11-14 Thread Rafael Laboissière 

* Sebastian Ramacher  [2020-11-14 09:22]:


Control: tags 974099 + patch
Control: tags 974099 + pending

Dear maintainer,

octave-database currently blocks the removal of postgresql-12 from 
testing which blocks the perl 5.32 transition. To unblock the situation, 
I've prepared an NMU for octave-database (versioned as 2.4.4-3.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should delay 
it longer.


Thank you for the upload.

Could you please push your changes to the Git depository for the package ? 
https://salsa.debian.org/pkg-octave-team/octave-database


Best,

Rafael Laboissière

Bug#979459: Reassigning, merging and rising severity level of Bugs #979458 and #979459

2021-08-24 Thread Rafael Laboissière 

Control: reassign 979458 src:jed 1:0.99.19-8
Control: reassign 979459 src:jed 1:0.99.19-8
Control: severity 979458 serious
Control: severity 979459 serious
Control: tags 979458 + patch
Control: tags 979459 + patch
Control: merge 979458 979459

With the upload of version 5.3-1 of the package debianutils, the tempfile 
command is definitively gone from Debian. This means that installation of 
the jed, jed-common, and xjed packages does not succeed in bookworm, 
since their postinst scripts invoke tempfile.


I am hereby reassigning the Bugs #979458 and #979459, which were assigned 
to the binary jed and jed-common packages, to the jed source package. I 
am also merging this two bug reports and rising their severity level to 
serious.


The trivial patch that fixes the problem is attached to this message.

Best,

Rafael Laboissière

P.S.: Note that removing the jed-common package from a bookworm system 
also fails because the tempfile command is used in the prerm maintainer 
script. Here is a simple recipe for doing it successfully:


sudo ln -sf /bin/mktemp /usr/bin/tempfile ;  sudo apt remove jed-common ; 
sudo rm /usr/bin/tempfile
diff --git a/debian/jed-common.postinst b/debian/jed-common.postinst
index 415dbde..96b204a 100644
--- a/debian/jed-common.postinst
+++ b/debian/jed-common.postinst
@@ -7,7 +7,7 @@ set -e
 case "$1" in
   configure)
 
-	TEMP=$(tempfile)
+	TEMP=$(mktemp)
 
 	printf "Running /usr/share/jed/compile/jed-common..."
 	if ! /usr/share/jed/compile/jed-common install >$TEMP 2>&1; then
diff --git a/debian/jed-common.prerm b/debian/jed-common.prerm
index 296fd78..ca3e677 100644
--- a/debian/jed-common.prerm
+++ b/debian/jed-common.prerm
@@ -5,7 +5,7 @@ set -e
 case "$1" in
 remove|upgrade|deconfigure)
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 printf "Running /usr/share/jed/compile/jed-common..."
 RET=0
 /usr/share/jed/compile/jed-common remove >$TEMP 2>&1 || RET=$?
diff --git a/debian/jed.postinst b/debian/jed.postinst
index 96bb2f9..f3ca2fa 100644
--- a/debian/jed.postinst
+++ b/debian/jed.postinst
@@ -12,7 +12,7 @@ case "$1" in
 	--install /usr/bin/jed-script jed-script /usr/bin/jed 50 \
 	--slave /usr/share/man/man1/jed-script.1.gz jed-script.1.gz /usr/share/man/man1/jed.1.gz;
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 RET=0
 printf "Updating precompiled files..."
 run-parts --exit-on-error --arg=install /usr/share/jed/compile/ \
diff --git a/debian/xjed.postinst b/debian/xjed.postinst
index 2648220..47ed8a0 100644
--- a/debian/xjed.postinst
+++ b/debian/xjed.postinst
@@ -12,7 +12,7 @@ case "$1" in
 	--install /usr/bin/jed-script jed-script /usr/bin/xjed 40 \
 	--slave /usr/share/man/man1/jed-script.1.gz jed-script.1.gz /usr/share/man/man1/xjed.1.gz;
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 RET=0
 printf "Updating precompiled files..."
 run-parts --exit-on-error --arg=install /usr/share/jed/compile/ \

Bug#979458: Reassigning, merging and rising severity level of Bugs #979458 and #979459

2021-08-25 Thread Rafael Laboissière 

* Rafael Laboissière  [2021-08-24 08:45]:


[…]

The trivial patch that fixes the problem is attached to this message.


Please, consider rather the patch that is attached to the present 
message. The jed-common.prerm script must honor the failed-upgrade 
argument, since the script in version 1:0.99.19-8 will fail on upgrade.


In order to remove the jed package from their systems, users will have to 
upgrade it to 1:0.99.19-9 previously.


Best,

Rafael Laboissière
diff -Nru jed-0.99.19/debian/jed-common.postinst jed-0.99.19/debian/jed-common.postinst
--- jed-0.99.19/debian/jed-common.postinst	2014-06-09 22:54:57.0 -0300
+++ jed-0.99.19/debian/jed-common.postinst	2021-08-25 04:34:25.0 -0300
@@ -7,7 +7,7 @@
 case "$1" in
   configure)
 
-	TEMP=$(tempfile)
+	TEMP=$(mktemp)
 
 	printf "Running /usr/share/jed/compile/jed-common..."
 	if ! /usr/share/jed/compile/jed-common install >$TEMP 2>&1; then
diff -Nru jed-0.99.19/debian/jed-common.prerm jed-0.99.19/debian/jed-common.prerm
--- jed-0.99.19/debian/jed-common.prerm	2014-06-09 22:54:57.0 -0300
+++ jed-0.99.19/debian/jed-common.prerm	2021-08-25 04:35:10.0 -0300
@@ -3,9 +3,9 @@
 set -e
 
 case "$1" in
-remove|upgrade|deconfigure)
+remove|upgrade|deconfigure|failed-upgrade)
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 printf "Running /usr/share/jed/compile/jed-common..."
 RET=0
 /usr/share/jed/compile/jed-common remove >$TEMP 2>&1 || RET=$?
@@ -18,9 +18,6 @@
 
 ;;
 
-failed-upgrade)
-;;
-
 *)
 echo "prerm called with unknown argument \`$1'" >&2
 exit 1
diff -Nru jed-0.99.19/debian/jed.postinst jed-0.99.19/debian/jed.postinst
--- jed-0.99.19/debian/jed.postinst	2014-06-09 22:54:57.0 -0300
+++ jed-0.99.19/debian/jed.postinst	2021-08-25 04:34:25.0 -0300
@@ -12,7 +12,7 @@
 	--install /usr/bin/jed-script jed-script /usr/bin/jed 50 \
 	--slave /usr/share/man/man1/jed-script.1.gz jed-script.1.gz /usr/share/man/man1/jed.1.gz;
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 RET=0
 printf "Updating precompiled files..."
 run-parts --exit-on-error --arg=install /usr/share/jed/compile/ \
diff -Nru jed-0.99.19/debian/xjed.postinst jed-0.99.19/debian/xjed.postinst
--- jed-0.99.19/debian/xjed.postinst	2014-06-09 22:54:57.0 -0300
+++ jed-0.99.19/debian/xjed.postinst	2021-08-25 04:34:25.0 -0300
@@ -12,7 +12,7 @@
 	--install /usr/bin/jed-script jed-script /usr/bin/xjed 40 \
 	--slave /usr/share/man/man1/jed-script.1.gz jed-script.1.gz /usr/share/man/man1/xjed.1.gz;
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 RET=0
 printf "Updating precompiled files..."
 run-parts --exit-on-error --arg=install /usr/share/jed/compile/ \

Bug#979458: Reassigning, merging and rising severity level of Bugs #979458 and #979459

2021-08-26 Thread Rafael Laboissière 

* Rafael Laboissière  [2021-08-25 13:43]:


* Wookey  [2021-08-25 12:30]:


On 24/08/2021 07:45, Rafael Laboissière wrote:

I am hereby reassigning the Bugs #979458 and #979459, which were
assigned to the binary jed and jed-common packages, to the jed
source package. I am also merging this two bug reports and rising
their severity level to serious.

The trivial patch that fixes the problem is attached to this message.


Thanks Rafael.

I'm away on expedition with negligible internet until 12th Sept, so 
if anyone wishes to NMU this, that's fine by me. Otherwise it'll get 
done sometime after I get back.


Ok, I will NMU the new version.


It is done.

Would you mind if I add my changes to the Git repository at salsa.d.o? 
I will also add the changes for version 1:0.99.19-8, which are absent 
from the repository, if you agree.


I also pushed the changes to the repository at Salsa.d.o.

Enjoy your expedition!

Best,

Rafael Laboissière

Bug#979458: Reassigning, merging and rising severity level of Bugs #979458 and #979459

2021-08-25 Thread Rafael Laboissière 

* Wookey  [2021-08-25 12:30]:


On 24/08/2021 07:45, Rafael Laboissière wrote:

I am hereby reassigning the Bugs #979458 and #979459, which were
assigned to the binary jed and jed-common packages, to the jed
source package. I am also merging this two bug reports and rising
their severity level to serious.

The trivial patch that fixes the problem is attached to this message.


Thanks Rafael.

I'm away on expedition with negligible internet until 12th Sept, so if 
anyone wishes to NMU this, that's fine by me. Otherwise it'll get done 
sometime after I get back.


Ok, I will NMU the new version.

Would you mind if I add my changes to the Git repository at salsa.d.o? I 
will also add the changes for version 1:0.99.19-8, which are absent from 
the repository, if you agree.


Best,

Rafael Laboissière

Bug#984148: [PATCH] Re: gcc-avr: ftbfs with GCC-11

2021-10-24 Thread Rafael Laboissière 
The patch attached to this message allows the building of the gcc-avr 
package against GCC 11.


It simply changes the type of member x_spill_indirect_levels of structure 
target_reload, defined in file gcc/gcc/reload.h, from bool to int. This 
member is only used in file gcc/gcc/reload1.c, where it is incremented as 
a integer with the operator ++. In GCC 11, use of this operator on 
variables with type bool is forbiden.


At any rate, this member seems to be intended to behave like an integer 
elsewhere in the code. For instance, it is passed as the third argument 
of the function find_reloads, defined in file gcc/gcc/reload.c, which 
accepts an integer as third argument.


Caveat: I did not do extensive tests to check for side effects of this
change.

Best,

Rafael Laboissière
--- gcc-avr-5.4.0+Atmel3.6.2.orig/gcc/gcc/reload.h
+++ gcc-avr-5.4.0+Atmel3.6.2/gcc/gcc/reload.h
@@ -168,7 +168,7 @@ struct target_reload {
  value indicates the level of indirect addressing supported, e.g., two
  means that (MEM (MEM (REG n))) is also valid if (REG n) does not get
  a hard register.  */
-  bool x_spill_indirect_levels;
+  int x_spill_indirect_levels;
 
   /* True if caller-save has been reinitialized.  */
   bool x_caller_save_initialized_p;

Bug#983993: [PATCH] Re: binutils-avr: ftbfs with GCC-11

2021-10-23 Thread Rafael Laboissière 
Attached to this message is a trivial patch that makes the binutils-avr 
package build correctly against GCC 11.


Best,

Rafael Laboissière
--- binutils-avr-2.26.20160125+Atmel3.6.2.orig/binutils/bfd/plugin.c
+++ binutils-avr-2.26.20160125+Atmel3.6.2/binutils/bfd/plugin.c
@@ -338,7 +338,7 @@ load_plugin (bfd *abfd)
 {
   char *full_name;
   struct stat s;
-  int valid_plugin;
+  int valid_plugin = 0;
 
   full_name = concat (p, "/", ent->d_name, NULL);
   if (stat(full_name, ) == 0 && S_ISREG (s.st_mode))
--- binutils-avr-2.26.20160125+Atmel3.6.2.orig/binutils/bfd/elf-bfd.h
+++ binutils-avr-2.26.20160125+Atmel3.6.2/binutils/bfd/elf-bfd.h
@@ -1751,7 +1751,7 @@ struct elf_obj_tdata
   struct sdt_note *sdt_note_head;
 
   Elf_Internal_Shdr **group_sect_ptr;
-  int num_group;
+  unsigned int num_group;
 
   unsigned int symtab_section, dynsymtab_section;
   unsigned int dynversym_section, dynverdef_section, dynverref_section;

Bug#991330: marked as pending in octave-zeromq

2021-07-22 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #991330 in octave-zeromq reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-zeromq/-/commit/41c43602a666b493ba22cb89d66e120c47d8600b


d/control: Build-depend on pkg-config

Closes: #991330

Thanks: Adrian Bunk for the bug report


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/991330

Bug#1050796: marked as pending in octave-interval

2023-08-30 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1050796 in octave-interval reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-interval/-/commit/c3c5d11d1b58dc1d23d2b380e8bc349dbb98c210


d/p/display-plus-intervaltotext.patch: New patch

Closes: #1050796
Thanks: Vincent Lefèvre for proposing the fix


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1050796

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

2023-08-31 Thread Rafael Laboissière 

* Rafael Laboissière  [2023-08-31 15:01]:


* Sébastien Villemot  [2023-08-31 12:05]:


Le jeudi 03 août 2023 à 08:33 +0200, Rafael Laboissière a écrit :


Just for the record, this is the offending unit test:

308s [inst/ConfusionMatrixChart.m]
308s >>>>>

/tmp/autopkgtest-lxc.9x_h6bvs/downtmp/build.BGX/src/inst/ConfusionMatrixChart.m
308s * demo
308s  ## Create a simple ConfusionMatrixChart Object
308s
308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], {"A","B"},{"XLabel","LABEL 
A"})
308s  NormalizedValues = cm.NormalizedValues
308s  ClassLabels = cm.ClassLabels
308s * shared visibility_setting
308s  visibility_setting = get (0, "DefaultFigureVisible");
308s * test
308s  set (0, "DefaultFigureVisible", "off");
308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], {"A","B"},{"XLabel","LABEL 
A"});
308s  assert (isa (cm, "ConfusionMatrixChart"), true);
308s  set (0, "DefaultFigureVisible", visibility_setting);
308s warning: Non-positive limit for logarithmic axis ignored
308s ! test failed
308s set: "cameratarget" must be finite
308s shared variables visibility_setting = on
308s 1 test, 0 passed, 0 known failure, 0 skipped

We have seen this problem already elsewhere. I will try to 
investigate it.


Did you get to a conclusion?


No progress on my side, sorry.


At any rate, the last autopkgtest run (on 2023-08-26) succeded: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/o/octave-statistics/37186503/log.gz


Should we close this bug report?

Rafael Laboissière

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

2023-08-31 Thread Rafael Laboissière 

* Sébastien Villemot  [2023-08-31 12:05]:


Le jeudi 03 août 2023 à 08:33 +0200, Rafael Laboissière a écrit :


Just for the record, this is the offending unit test:

 308s [inst/ConfusionMatrixChart.m]
 308s >>>>>
 
/tmp/autopkgtest-lxc.9x_h6bvs/downtmp/build.BGX/src/inst/ConfusionMatrixChart.m
 308s * demo
 308s  ## Create a simple ConfusionMatrixChart Object
 308s
 308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], {"A","B"},{"XLabel","LABEL 
A"})
 308s  NormalizedValues = cm.NormalizedValues
 308s  ClassLabels = cm.ClassLabels
 308s * shared visibility_setting
 308s  visibility_setting = get (0, "DefaultFigureVisible");
 308s * test
 308s  set (0, "DefaultFigureVisible", "off");
 308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], {"A","B"},{"XLabel","LABEL 
A"});
 308s  assert (isa (cm, "ConfusionMatrixChart"), true);
 308s  set (0, "DefaultFigureVisible", visibility_setting);
 308s warning: Non-positive limit for logarithmic axis ignored
 308s ! test failed
 308s set: "cameratarget" must be finite
 308s shared variables visibility_setting = on
 308s 1 test, 0 passed, 0 known failure, 0 skipped

We have seen this problem already elsewhere. I will try to investigate 
it.


Did you get to a conclusion?


No progress on my side, sorry.

Rafael Laboissière

Bug#1050796: octave-interval tests need an update with mpfr4 4.2.1

2023-08-29 Thread Rafael Laboissière 

Control: forwarded -1 https://savannah.gnu.org/bugs/?64607
Control: tags -1 + patch confirmed upstream

Thank you for the bug report, Matthias.

This issue has been reported in the upstream bug tracking system. The fix 
seems to be trivial, cf patch attached to this message. Let us see if a 
new upstream version of interval package for Octave is released soon. If 
not, I will released a patched version of octave-interval.


Best,

Rafael Laboissière

* Matthias Klose  [2023-08-29 12:20]:


Package: octave-interval
Version: 3.2.1-5
Severity: serious
Tags: sid trixie
Forwarded: https://savannah.gnu.org/bugs/index.php?64607
Affects: src:mpfr4

the octave-interval tests need an update with mpfr4 4.2.1:

see 
https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-interval/37232402/log.gz



Description: Adjust BISTs in src/intervaltotext.cc for MPFR v2.4.1
 GNU MPFR had a bug in the formatting function, causing the "+" flag
 to be ignored for Inf and NaN. It is now honored in version 2.4.1.
 The BISTs in src/intervaltotext.cc are fixed for the coping with the
 correct behavior.
Author: Rafael Laboissière 
Bug: https://savannah.gnu.org/bugs/?64607
Bug-Debian: https://bugs.debian.org/1050796
Forwarded: not-needed
Last-Update: 2023-08-29

--- octave-interval-3.2.1.orig/src/intervaltotext.cc
+++ octave-interval-3.2.1/src/intervaltotext.cc
@@ -1281,7 +1281,7 @@ DEFUN_DLD (intervaltotext, args, nargout
 %!assert (intervaltotext (infsup (), "[cg]"), "[empty]");
 
 %!assert (intervaltotext (infsup (-inf, inf), "[g]"), "[Entire]");
-%!assert (intervaltotext (infsup (-inf, inf), "[

Bug#1052973: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1

2023-09-28 Thread Rafael Laboissière 

Control: reassign -1 octave-dev 8.3.0-1
Control: affects -1 octave-image
Control: notfound -1 octave-image/2.14.0-4
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64725

* Rafael Laboissière  [2023-09-26 22:00]:


Control: tags -1 + confirmed upstream

* Lucas Nussbaum  [2023-09-26 15:46]:


 Source: octave-image
 Version: 2.14.0-4
 Severity: serious
 Justification: FTBFS
 Tags: trixie sid ftbfs
 User: lu...@debian.org
 Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to 
build on amd64.



Relevant part (hopefully):


 Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
 Some tests failed.  Giving up...
 make: *** [debian/rules:12: binary] Error 1


I think that this problem is triggered by a changing in behavior of 
the mkoctfile program, in the way it process its arguments, between 
versions 8.2 and 8.3 of Octave. I will try to get to this, as time 
permits.


As I suspected, this bug is related to Bug#1050082 and is caused by a 
misbehavior of mkoctfile, a tool used to build the *.oct files needed by 
Octave, when options -f* are given to it.


I have already filed a bug report upstream and I am hereby reassigning 
the present bug report to the octave-dev package.


Best,

Rafael Laboissière

Bug#1052973: marked as pending in octave

2023-09-30 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1052973 in octave reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave/-/commit/bbc6c896b88490baec1531363aeb7c5d8d5e9f97


d/p/mkoctfile-skip-options.patch: Update patch

Closes: #1052973
Thanks: Markus Mützel 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1052973

Bug#1052973: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1

2023-09-26 Thread Rafael Laboissière 

Control: tags -1 + confirmed upstream

* Lucas Nussbaum  [2023-09-26 15:46]:


Source: octave-image
Version: 2.14.0-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build 
on amd64.



Relevant part (hopefully):


 Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
 Some tests failed.  Giving up...
 make: *** [debian/rules:12: binary] Error 1


I think that this problem is triggered by a changing in behavior of the 
mkoctfile program, in the way it process its arguments, between versions 
8.2 and 8.3 of Octave. I will try to get to this, as time permits.


Best,

Rafael Laboissière

Bug#1052973: marked as done (octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1)

2023-10-08 Thread Rafael Laboissière 

* Sébastien Villemot  [2023-10-07 08:23]:


Hi Rafael,

Le samedi 07 octobre 2023 à 14:15 +0200, Rafael Laboissière a écrit :

I have a question for the Debian Octave Group, related to Bug#1052973,
which has been fixed in version 8.3.0-3 of octave-dev. This bug was
preventing the building of the octave-image package. Should we include
octave-dev >= 8.3.0-3 in Build-Depends of the otave-image package ?


I would say no.

If every time that a bug is fixed in a dependency, we were to bump the 
version requirement, then we would basically always depend on the 
latest version of every package.


Ok, thanks for the advise.

Also, it may be possible that octave-image builds against an old 
version of octave-dev that was not affected by the bug.


Apparently (but I did not check it thoroughly) , the “bug” in mkoctifle 
was always there, but has only been exposed when the Debian build tools 
started injecting some new -f* options into CFLAGS that was propagated 
into the call of mkoctfile. This confuses mkoctfile's options parser, 
resulting into a wrong behavior.


Best,

Rafael Laboissière

Bug#1052973: marked as done (octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1)

2023-10-07 Thread Rafael Laboissière 

Hi,

I have a question for the Debian Octave Group, related to Bug#1052973, 
which has been fixed in version 8.3.0-3 of octave-dev. This bug was 
preventing the building of the octave-image package. Should we include 
octave-dev >= 8.3.0-3 in Build-Depends of the otave-image package ?


Best,

Rafael

* Debian Bug Tracking System  [2023-09-30 19:09]:

Your message dated Sat, 30 Sep 2023 19:04:59 + 
with message-id  
and subject line Bug#1052973: fixed in octave 8.3.0-3 
has caused the Debian Bug report #1052973, 
regarding octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1 
to be marked as done.


This means that you claim that the problem has been dealt with. 
If this is not the case it is now your responsibility to reopen the 
Bug report if necessary, and/or fix the problem forthwith.


(NB: If you are a system administrator and have no idea what this 
message is talking about, this may indicate a serious mail system 
misconfiguration somewhere. Please contact ow...@bugs.debian.org 
immediately.)



--
1052973: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052973
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



From: Lucas Nussbaum 
Subject: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1
Date: Tue, 26 Sep 2023 15:46:13 +0200
To: sub...@bugs.debian.org
Message-ID: 

Source: octave-image
Version: 2.14.0-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build 
on amd64.



Relevant part (hopefully):

Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
Some tests failed.  Giving up...
make: *** [debian/rules:12: binary] Error 1



The full build log is available from: 
http://qa-logs.debian.net/2023/09/25/octave-image_2.14.0-4_unstable.log


All bugs filed during this archive rebuild are listed at: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230925;users=lu...@debian.org 
or: 
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230925=lu...@debian.org=1=1=1=1#results


A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!


If you reassign this bug to another package, please mark it as 'affects'-ing 
this package. See https://www.debian.org/Bugs/server-control#affects


If you fail to reproduce this, please provide a build log and diff it with mine 
so that we can identify if something relevant changed in the meantime.



From: Debian FTP Masters 
Subject: Bug#1052973: fixed in octave 8.3.0-3
Date: Sat, 30 Sep 2023 19:04:59 +
To: 1052973-cl...@bugs.debian.org
Reply-To: Rafael Laboissière 
Message-Id: 

Source: octave
Source-Version: 8.3.0-3
Done: Rafael Laboissière 

We believe that the bug you reported is fixed in the latest version of 
octave, which is due to be installed in the Debian FTP archive.


A summary of the changes between this version and the previous one is 
attached.


Thank you for reporting the bug, which will now be closed.  If you 
have further comments please address them to 1052...@bugs.debian.org, 
and the maintainer will reopen the bug report if appropriate.


Debian distribution maintenance software 
pp. 
Rafael Laboissière  (supplier of updated octave package)


(This message was generated automatically at their request; if you 
believe that there is a problem with it please contact the archive 
administrators by mailing ftpmas...@ftp-master.debian.org)



-BEGIN PGP SIGNED MESSAGE- 
Hash: SHA256


Format: 1.8
Date: Sat, 30 Sep 2023 10:35:07 -0300
Source: octave
Architecture: source
Version: 8.3.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Octave Group 
Changed-By: Rafael Laboissière 
Closes: 1052973
Changes: 
octave (8.3.0-3) unstable; urgency=medium 
. 
  * d/p/mkoctfile-skip-options.patch: Update patch. 
Thanks to Markus Mützel  (Closes: #1052973) 
Checksums-Sha1: 
cede5a06bc26a1717cf59f29e3daf0a132867020 3452 octave_8.3.0-3.dsc 
44d80983a0848c228544957a373b2a72422f8225 63276 octave_8.3.0-3.debian.tar.xz 
Checksums-Sha256: 
5c725301cd046ef5a62e3d6039ad0e7ad333864c8c0a578f6c9a72bc21080f4f 3452 octave_8.3.0-3.dsc 
34f4f8d890a5a9268102241a2847d76d2bb1e72c9738ea5151a023a7d54f95fa 63276 octave_8.3.0-3.debian.tar.xz 
Files: 
a4a7d3b2ebfee85ae8d90a9c6fab6e8c 3452 math optional octave_8.3.0-3.dsc 
1bdf47d3560fdbf1bbd656eacaa7307f 63276 math optional octave_8.3.0-3.debian.tar.xz


-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEP0ZDkUmP6HS9tdmPISSqGYN4XJAFAmUYaOoSHHJhZmFlbEBk 
ZWJpYW4ub3JnAAoJECEkqhmDeFyQzuIQAIVEaYdWmkJjSUx2D+4EBLKxOEqDOZhv 
4GlAOIvYCRwM/OOe8UQJY/cXAg89KVMFKGnewuAljKz+sR7hGdt4EQp1GAcujAsQ 
QXHqh3UhNNn6t8oiDE5LXyu8I8Apy/EqdNss1cLQWq03D4WVNP2YttAEfXs3KRd5 
NJQRMEZ8QIgEGeUad80lLtKqIQoIM75iUMUKcwPx7BwgfAp3PJDV6tuY5CJzseFc 
9cyzgyiZGHlVoSB26D7LSERyGejm3osrwNpv0d4p8+QTFUblDBXhXNyjIR5Tw

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

2023-10-09 Thread Rafael Laboissière 
Thanks for this detailed explanation, Drew. I released version 
3.1.0+dfsg2-5 of the xmds2 package before reading it. I added 
python3-h5py to Build-Depends and libhdf5-mpi-dev to Depends, as you 
suggested (even though there is a typo in the debian/changelog entry, 
stating eroneaously that libhdf5-serial-dev has been added; I will fix 
this in the next release).


I also used H5PY_ALWAYS_USE_MPI=1, as you mentioned.

As regards adding also python3-h5py-serial to Depends and putting a 
fallback code in place, I will have to give it a little thought. Maybe, I 
should discuss this with the upstream authors, to know what they thing. 
Let us see how things evolve. At least, I hope that version 3.1.0+dfsg2-5 
will really fix Bug#1053314 and the h5py transition will be completed.


Best,

Rafael

* Drew Parsons  [2023-10-09 02:23]:

Nilesh explained most of the situation correctly.  I can give some 
more background.It made sense (to me) to have h5py built against 
hdf5-mpi, since I figured that if you need the complexity of the hdf5 
file format then you probably want to use it in an MPI environment.


There was a complaint from a user though, who wanted to make use of a 
massive ensemble of HDF5 (h5py) serial jobs, and the small cost of 
loading up MPI support was interfering with their throughput.


So the compromise solution was to provide both builds, with a custom 
__init__.py to select the serial or MPI build depending on runtime 
environment.  If an MPI environment is detected then the h5py MPI 
build is loaded, otherwise the serial build is loaded.


If you want to run h5py in a serial process, then one might say you'd 
normally want the serial build.  As Nilesh noted, I put in a mechanism 
to load the MPI build if you really want to access the mpi build in a 
serial process (mpirun -n 1 is not a "serial" process as such, it's 
still an MPI environment even though using only 1 process).


The mechanism to force MPI loading is NOT to set OMPI_COMM_WORLD_SIZE. 
I recommend NOT doing that. I couldn't promise it won't mess up other 
things, certainly it will get in the way of an MPICH environment.  No, 
the mechanism for handling this for h5py is described in 
/usr/share/doc/python3-h5py/README.Debian: set H5PY_ALWAYS_USE_MPI=1


Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


It sounds like there is some confusion about how xmds2 should be used. 
Is it intended to be used as a serial process or MPI?  I noted in the 
bug report that xmds2 Depends: libhdf5-serial-dev.  Is it even using 
MPI?  If you want it to be using h5py-serial, then why does xmsd2 
depend on python3-h5py-mpi?


It seems to me that xmds2's h5py dependency should be the same as its 
hdf5 dependency.  If it uses libhdf5-serial then should it be 
depending on just python3-h5py (implying python3-h5py-serial, make it 
explicit if needed) and not depend on python3-h5py-mpi?


If xmds2 is intended to be flexible, equally happy in serial and MPI 
environments (and can actually make use of h5py-mpi) then perhaps the 
dependency should cover all cases, 
 Depends: python3-h5py, python3-h5py-serial, python3-h5py-mpi 
all three explicitly, since otherwise one or the other of -serial or 
-mpi would be missed.


The problem raises interesting questions about h5py configuration. I 
set up it so you could choose how you want it to work, with or without 
MPI support.  But it looks like an edge case is missing: it's failing 
in serial jobs if you chose to set up your installation with 
python3-h5py-mpi and explicitly don't want python3-h5py-serial (unless 
you always set H5PY_ALWAYS_USE_MPI). Perhaps I should add an 
additional fallback to try h5py-mpi if h5py-serial is not found (in a 
serial job), the same way that h5py-serial is loaded as a fallback in 
an MPI job if h5py-mpi is not found. On the other hand maybe that just 
hides the real problem, that h5py-serial was not installed when 
actually it was wanted after all.  The ImportError correctly 
identifies that case.





On 2023-10-08 17:38, Nilesh Patra wrote:

Hello,

On 10/8/23 17:22, Rafael Laboissière wrote:

Ok, I tried to fix the building problem by including python3-h5py,
alongside with python3-h5py-mpi, into Build-Depends, as suggested
by Drew, but the xmds2 package FTBFS.

Here is a way to reproduce the problem without building the package:

  $ dpkg -l python3-h5py\*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name    Version  Architecture Description
  
+++-===---===
  ii  python3-h5py    3.9.0-3  all 
general-purpose Python interface to hdf5 
  ii  python3-h5py-mpi    3.9.0-3  amd64    
general-purpose Python interface to hd

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

2023-10-10 Thread Rafael Laboissière 

* Rafael Laboissière  [2023-10-09 08:30]:

[…] At least, I hope that version 3.1.0+dfsg2-5 will really fix 
Bug#1053314 and the h5py transition will be completed.


Unfortunately, it is still not working: 
https://ci.debian.net/data/autopkgtest/testing/arm64/x/xmds2/38836874/log.gz


I guess that the problem comes from the absence of /usr/bin/h5cc, which 
is in the hdf5-helpers package. This package, which is a dependency of 
libhdf5-dev, is not installed at the autopkgtest run.


I confess that I am confused and need your advice here. Currently, the 
xmds2 package depends on libhdf5-mpi-dev. Should hdf5-helpers or 
libhdf5-dev be added to Depends?


Best,

Rafael

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

2023-10-08 Thread Rafael Laboissière 
Ok, I tried to fix the building problem by including python3-h5py, 
alongside with python3-h5py-mpi, into Build-Depends, as suggested by 
Drew, but the xmds2 package FTBFS.


Here is a way to reproduce the problem without building the package:

  $ dpkg -l python3-h5py\*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ NameVersion  Architecture Description
  
+++-===---===
  ii  python3-h5py3.9.0-3  all  general-purpose Python 
interface to hdf5
  ii  python3-h5py-mpi3.9.0-3  amd64general-purpose Python 
interface to hdf5 (Python 3 MPI)
  un  python3-h5py-serial   (no description available)
  $ echo 'import h5py' | python3
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, in 
  from . import _debian_h5py_serial as _h5py
  ImportError: cannot import name '_debian_h5py_serial' from partially 
initialized module 'h5py' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/h5py/__init__.py)

Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


Best,

Rafael

* Rafael Laboissière  [2023-10-08 10:27]:


* Nilesh Patra  [2023-10-04 02:24]:


On Sun, 01 Oct 2023 15:25:43 +0200 Drew Parsons  wrote:

Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci

xmds2 Depends: python3-h5py-mpi without depending on python3-h5py

python3-h5py-mpi only provides the h5py._debian_h5py_mpi 
namespace, not h5py.  Hence tests using h5py without specifying 
_debian_h5py_mpi fail.  This is the case with h5py 3.9.0. (Marking 
Severity: serious due to debci failure)


python3-h5py provides the h5py namespace, so if xmds2 strictly 
needs the mpi build, but accessing via the generic h5py namespace, 
then the Depends should specify both packages  Depends: 
python3-h5py python3-h5py-mpi Note there seems to be an 
inconsistency in the xmds2 package configuration. It has MPI 
dependencies (python3-h5py-mpi, also mpi-default-dev, 
libfftw3-mpi-dev), but with respect to hdf5 it has Depends: 
libhdf5-serial-dev Should that instead be Depends: libhdf5-mpi-dev 
?


Seems you're right, taking a brief look at it. I've CC'ed Rafael to further 
comment/upload a fix.

@Rafael, this seems to be the last blocker on h5py transition to 
testing, so prompt action would be really cool!


Thanks to Drew for the bug report and Nilesh for the remainder. I was 
out of town these last days and could not react to your messages. I am 
taking a look at the issue right now.


Best,

Rafael

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

2023-10-08 Thread Rafael Laboissière 

* Nilesh Patra  [2023-10-04 02:24]:


On Sun, 01 Oct 2023 15:25:43 +0200 Drew Parsons  wrote:

Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci

xmds2 Depends: python3-h5py-mpi without depending on python3-h5py

python3-h5py-mpi only provides the h5py._debian_h5py_mpi namespace, 
not h5py.  Hence tests using h5py without specifying _debian_h5py_mpi 
fail.  This is the case with h5py 3.9.0. (Marking Severity: serious due 
to debci failure)


python3-h5py provides the h5py namespace, so if xmds2 strictly needs 
the mpi build, but accessing via the generic h5py namespace, then the 
Depends should specify both packages 
 Depends: python3-h5py python3-h5py-mpi 
Note there seems to be an inconsistency in the xmds2 package 
configuration. It has MPI dependencies (python3-h5py-mpi, also 
mpi-default-dev, libfftw3-mpi-dev), but with respect to hdf5 it has 
Depends: libhdf5-serial-dev 
Should that instead be 
Depends: libhdf5-mpi-dev ?


Seems you're right, taking a brief look at it. I've CC'ed Rafael to further 
comment/upload a fix.

@Rafael, this seems to be the last blocker on h5py transition to testing, so prompt action would 
be really cool!


Thanks to Drew for the bug report and Nilesh for the remainder. I was 
out of town these last days and could not react to your messages. I am 
taking a look at the issue right now.


Best,

Rafael

Bug#1055228: plplot: FTBFS on armhf (test segfault)

2023-11-10 Thread Rafael Laboissière 

* Rafael Laboissière  [2023-11-09 17:11]:


[snip]

There may be a programming error in x09f.f90 or this may be a problem 
with gfortran on armhf. My knowledge of Fortran is almost non existent 
and I will need the help of experts, in order to fix the issue.


Regarding this issue, I filed a bug against the gfortran package: 
https://bugs.debian.org/1055750


Best,

Rafael Laboissière

Bug#1013589: marked as pending in octave-interval

2022-06-26 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1013589 in octave-interval reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-interval/-/commit/1c46aac299196ee250cfd80580d371130af95312


d/octave-interval.install; Install /usr/{lib,share}/* files

Closes: #1013589


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1013589

Bug#1013604: marked as pending in octave-communications

2022-06-26 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1013604 in octave-communications reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-communications/-/commit/1fbb9443a8b4f3f91fb64110ffdf04a5a542e1af


Proper installation of files in arch and arch-indep packages

+ d/octave-communications.install: New file
+ d/octave-communications-common.install: New file
+ d/rules: Drop useless commands in target execute_after_dh_auto_install

Gbp-Dch: Full
Closes: #1013604


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1013604

Bug#1004770: marked as pending in octave-video

2022-09-14 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1004770 in octave-video reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-video/-/commit/3f5d2b913256ec5f82e1952988c9c096d5913e6a


d/p/ffmpeg5.patch: New patch, for fixing FTBFS against ffmpeg 5

Closes: #1004770
Thanks: William Wilson  for the patch


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1004770

Bug#1004770: octave-video: Use this patch instead

2022-08-14 Thread Rafael Laboissière 
Ok, I investigated the issue deeper. Although the proposed patch fixes 
the FTBFS problem, the resulting code is buggy.


I strongly advise the Ubuntu maintainers to mark their current 
octave-video package (version 2.0.2-1ubuntu1) as unsuitable for release, 
since it does not work as expected.


Best,

Rafael

* Rafael Laboissière  [2022-08-13 12:17]:

Complementing my message below, the unit test in inst/VideWriter.m 
passed successfully when the sources were compiled against ffmpeg 4, 
for instance in this build: https://buildd.debian.org/status/fetch.php?pkg=octave-video=amd64=2.0.2-1%2Bb2=1650535691=0


* Rafael Laboissière  [2022-08-13 10:49]:


* William 'jawn-smith' Wilson  [2022-08-02 17:35]:


Package: octave-video
Followup-For: Bug #1004770
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The first patch I submitted was a bit messy and failed to build 
with older versions of ffmpeg. A version with this patch has built 
successfully for me in Ubuntu kinetic and Debian sid.


In Ubuntu, the attached patch was applied to achieve the following:


* d/patches/ffmpeg5.patch: Update to FFMPEG 5 API.


Thanks for considering the patch.


Thank you for your patch. The package builds fine on my amd64 Debian 
sid system against ffmpeg 5. However, one of the unit test is 
failing:


  $ echo 'pkg load video; test VideoWriter' | octave-cli -q
  fatal: caught signal Segmentation fault -- stopping myself...
  Segmentation fault

Further investigation, when running the code of the unit test by 
hand, shows that the problem happens in the method writeVideo of the 
VideoWriter class:


  $ octave-cli -q
  octave:1> pkg load video
  octave:2> fn = fullfile (tempdir(), "rainbow.mp4");
  octave:3> width = 200;
  octave:4> height = 150;
  octave:5> nframes = 120;
  octave:6> p = permute (rainbow (width), [3 1 2]);
  octave:7> raw_video = zeros (height, width, 3, nframes);
  octave:8> w = VideoWriter (fn);
  octave:9> for k=1:nframes
disp (k)
ps = circshift (p, k * 6);
img = uint8 (255 * repmat (ps, height, 1));
raw_video (:, :, :, k) = img;
writeVideo (w, img);
  endfor
  1
  fatal: caught signal Segmentation fault -- stopping myself...
  Segmentation fault

Ultimately, I noticed that the problem arises in the call of the 
function __writer_open__, defined in src/cap_ffmpeg_wrapper.cc.


Do you experience the same problem in your system?

Best,

Rafael Laboissière

Bug#1004770: octave-video: Use this patch instead

2022-08-13 Thread Rafael Laboissière 
Complementing my message below, the unit test in inst/VideWriter.m passed 
successfully when the sources were compiled against ffmpeg 4, for 
instance in this build: 
https://buildd.debian.org/status/fetch.php?pkg=octave-video=amd64=2.0.2-1%2Bb2=1650535691=0


* Rafael Laboissière  [2022-08-13 10:49]:


* William 'jawn-smith' Wilson  [2022-08-02 17:35]:


Package: octave-video
Followup-For: Bug #1004770
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The first patch I submitted was a bit messy and failed to build with 
older versions of ffmpeg. A version with this patch has built 
successfully for me in Ubuntu kinetic and Debian sid.


In Ubuntu, the attached patch was applied to achieve the following:


* d/patches/ffmpeg5.patch: Update to FFMPEG 5 API.


Thanks for considering the patch.


Thank you for your patch. The package builds fine on my amd64 Debian 
sid system against ffmpeg 5. However, one of the unit test is failing:


   $ echo 'pkg load video; test VideoWriter' | octave-cli -q
   fatal: caught signal Segmentation fault -- stopping myself...
   Segmentation fault

Further investigation, when running the code of the unit test by hand, 
shows that the problem happens in the method writeVideo of the 
VideoWriter class:


   $ octave-cli -q
   octave:1> pkg load video
   octave:2> fn = fullfile (tempdir(), "rainbow.mp4");
   octave:3> width = 200;
   octave:4> height = 150;
   octave:5> nframes = 120;
   octave:6> p = permute (rainbow (width), [3 1 2]);
   octave:7> raw_video = zeros (height, width, 3, nframes);
   octave:8> w = VideoWriter (fn);
   octave:9> for k=1:nframes
 disp (k)
 ps = circshift (p, k * 6);
 img = uint8 (255 * repmat (ps, height, 1));
 raw_video (:, :, :, k) = img;
 writeVideo (w, img);
   endfor
   1
   fatal: caught signal Segmentation fault -- stopping myself...
   Segmentation fault

Ultimately, I noticed that the problem arises in the call of the 
function __writer_open__, defined in src/cap_ffmpeg_wrapper.cc.


Do you experience the same problem in your system?

Best,

Rafael Laboissière

Bug#1004770: octave-video: Use this patch instead

2022-08-13 Thread Rafael Laboissière 

* William 'jawn-smith' Wilson  [2022-08-02 17:35]:


Package: octave-video
Followup-For: Bug #1004770
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The first patch I submitted was a bit messy and failed to build 
with older versions of ffmpeg. A version with this patch has 
built successfully for me in Ubuntu kinetic and Debian sid.


In Ubuntu, the attached patch was applied to achieve the following:


 * d/patches/ffmpeg5.patch: Update to FFMPEG 5 API.


Thanks for considering the patch.


Thank you for your patch. The package builds fine on my amd64 Debian 
sid system against ffmpeg 5. However, one of the unit test is failing:


$ echo 'pkg load video; test VideoWriter' | octave-cli -q
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault

Further investigation, when running the code of the unit test by hand, 
shows that the problem happens in the method writeVideo of the 
VideoWriter class:


$ octave-cli -q
octave:1> pkg load video
octave:2> fn = fullfile (tempdir(), "rainbow.mp4");
octave:3> width = 200;
octave:4> height = 150;
octave:5> nframes = 120;
octave:6> p = permute (rainbow (width), [3 1 2]);
octave:7> raw_video = zeros (height, width, 3, nframes);
octave:8> w = VideoWriter (fn);
octave:9> for k=1:nframes
  disp (k)
  ps = circshift (p, k * 6);
  img = uint8 (255 * repmat (ps, height, 1));
  raw_video (:, :, :, k) = img;
  writeVideo (w, img);
endfor
1
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault

Ultimately, I noticed that the problem arises in the call of the 
function __writer_open__, defined in src/cap_ffmpeg_wrapper.cc.


Do you experience the same problem in your system?

Best,

Rafael Laboissière

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

2022-12-06 Thread Rafael Laboissière 

* Rafael Laboissière  [2022-12-06 10:08]:


* Rafael Laboissière  [2022-12-05 22:55]:

The pvm package is currently installable in sid when openssh-client 
is installed and there is no other package providing rsh-client:


Of course, I meant *uninstallable* in the sentence above.

The pvm package is orphaned. If nobody objects, I will do a QA upload 
to fix this release-critical bug.


I just did it. Version 3.4.6-4 (QA upload) has been uploaded to unstable.

I did some QA work in the Git repository at Salsa.d.o. NMU versions 
3.4.6-3, 3.4.6-3.1, and 3.4.6-3.2 have diverged from the repository, 
since release 3.4.6-2. I injected those version into the repository and I 
included, in version 3.4.6-4, the changes that have been cumulated there.


Hopefully, this discipline will be kept in the future.

Rafael Laboissière

[*] https://salsa.debian.org/debian/pvm

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

2022-12-04 Thread Rafael Laboissière 

Control: forwarded -1 michelemart...@users.sourceforge.net
Control: tags -1 unreproducible

Hi Michele,

There is a bug report filed against the librsb package (Bug#1016332 [1]) 
that has severity level "serious". This is blocking the package entering 
testing and, therefore, librsb will be removed from the upcoming bookworm 
release, unless the bug is fixed. This means that octave-sparsersb would 
also be absent from the next Debian release if nothing is done.


I cannot reproduce the bug and I am hereby tagging this bug report 
accordingly. Skimming over the full build log [2], I could not find the 
source of the problem. If you could take a look at this, it will be 
great.


Best,

Rafael

 [1] https://bugs.debian.org/1016332
 [2] http://qa-logs.debian.net/2022/07/28/librsb_1.3.0.1+dfsg-2_unstable.log

* Lucas Nussbaum  [2022-07-29 20:37]:


Source: librsb
Version: 1.3.0.1+dfsg-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220728 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build 
on amd64.


[snip]

The full build log is available from: 
http://qa-logs.debian.net/2022/07/28/librsb_1.3.0.1+dfsg-2_unstable.log


All bugs filed during this archive rebuild are listed at: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220728;users=lu...@debian.org 
or: 
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220728=lu...@debian.org=1=1=1=1#results


A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!


If you reassign this bug to another package, please marking it as 'affects'-ing 
this package. See https://www.debian.org/Bugs/server-control#affects


If you fail to reproduce this, please provide a build log and diff it with mine 
so that we can identify if something relevant changed in the meantime.

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

2022-12-06 Thread Rafael Laboissière 

* Rafael Laboissière  [2022-12-05 22:55]:

The pvm package is currently installable in sid when openssh-client is 
installed and there is no other package providing rsh-client:


Of course, I meant *uninstallable* in the sentence above.

The pvm package is orphaned. If nobody objects, I will do a QA upload 
to fix this release-critical bug.


Rafael Laboissière

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

2022-12-05 Thread Rafael Laboissière 

* Michele Martone  [2022-12-04 23:42]:

latex is not able to compile a rsbtest-generated 
file looking like the one I attach. 
The problematic line is:


\usepackage[utf8x]{inputenc} 
[...]


It compiles fine here:

$ pdflatex test.tex > /dev/null && grep utf8x.def test.log
(/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
File: utf8x.def 2022/08/07 UCS: Input encoding UTF-8

The utf8x.def file belongs to this package:

$ dpkg -S /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
texlive-latex-extra: /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def

texlive-latex-extra is one of the dependencies of doxygen-latex, which 
is a build-dependency of librsb.


In conclusion, I do not think that the problem is caused by using the 
utf8x option for the LaTeX package inputenc.


Best,

Rafael

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

2022-12-06 Thread Rafael Laboissière 

* Michele Martone  [2022-12-05 15:31]:


In my 20221204@23:42 (yesterday) email I forgot to add that on my chroot 
setup, I can reproduce latex failing to compile the file I was attaching. 
In that setup I have a utf8x.def too, sized 8036 bytes and with md5sum 
21f7ac37aafb6cfeddbb196b8bfd6280 .


To the goal of fixing the librsb package: that test is the last one in 
`make tests`, and it it's just to make sure rsbtest can produce a buildable 
LaTeX file; it's nothing core or important, so sed'ing out that line 
seems the solution to me -- librsb itself is functional.


Ok, thanks, I applied the patch you suggested (s/utf8x//) and uploaded 
version 1.3.0.1+dfsg-3 of the package to unstable. So far, it built 
correctly on all official architectures for bookworm.


Let us see what will happen with the next automatic rebuild of all 
package in sid.


@Lucas: if the rebuild goes fine, will this bug report be automatically 
closed? Otherwise, is there a web page where the results can be tracked?


Best,

Rafael

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

2022-12-05 Thread Rafael Laboissière 
Package: pvm
Version: 3.4.6-3.2
Severity: serious

Dear Maintainer,

The pvm package is currently installable in sid when openssh-client is 
installed and there is no other package providing rsh-client:

  # apt install pvm
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  pvm is already the newest version (3.4.6-3.2+b1).
  pvm set to manually installed.
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  2 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  Do you want to continue? [Y/n]
  Setting up pvm (3.4.6-3.2+b1) ...
  update-alternatives: error: alternative path /usr/bin/rsh doesn't exist
  dpkg: error processing package pvm (--configure):
   installed pvm package post-installation script subprocess returned error 
exit status 2
  dpkg: dependency problems prevent configuration of pvm-dev:
   pvm-dev depends on pvm; however:
Package pvm is not configured yet.

This is caused by a recent change in openssh-client:

  openssh (1:9.1p1-1) unstable; urgency=medium
[...]
* Remove obsolete and misleading rcp/rlogin/rsh alternatives, and stop
  providing rsh-client (closes: #197037).

A simple fix for this issue is changing the Depends field from:

  openssh-client | rsh-client

to:

  rsh-client

Best,

Rafael

-- System Information: 
Debian Release: bullseye/sid 
  APT prefers testing 
  APT policy: (650, 'testing'), (600, 'unstable') 
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pvm depends on: 
ii  libc62.36-6 
pn  libpvm3   
ii  openssh-client [rsh-client]  1:9.1p1-1

pvm recommends no packages.

pvm suggests no packages.

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

2023-08-03 Thread Rafael Laboissière 

* Matthias Klose  [2023-08-03 04:23]:


Package: src:octave-statistics
Version: 1.6.0-1
Severity: serious
Tags: sid trixie

octave autopkg tests fail in unstable on amd64 (triggered by gcc-13).

https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-statistics/36329437/log.gz

Not sure which ones are the regressions, because all failures seem to 
be marked as "known failure".


Thanks for the bug report, Matthias.

Just for the record, this is the offending unit test:

308s [inst/ConfusionMatrixChart.m]
308s >>>>>

/tmp/autopkgtest-lxc.9x_h6bvs/downtmp/build.BGX/src/inst/ConfusionMatrixChart.m
308s * demo
308s  ## Create a simple ConfusionMatrixChart Object
308s
308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], {"A","B"},{"XLabel","LABEL 
A"})
308s  NormalizedValues = cm.NormalizedValues
308s  ClassLabels = cm.ClassLabels
308s * shared visibility_setting
308s  visibility_setting = get (0, "DefaultFigureVisible");
308s * test
308s  set (0, "DefaultFigureVisible", "off");
308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], {"A","B"},{"XLabel","LABEL 
A"});
308s  assert (isa (cm, "ConfusionMatrixChart"), true);
308s  set (0, "DefaultFigureVisible", visibility_setting);
308s warning: Non-positive limit for logarithmic axis ignored
308s ! test failed
308s set: "cameratarget" must be finite
308s shared variables visibility_setting = on
308s 1 test, 0 passed, 0 known failure, 0 skipped

We have seen this problem already elsewhere. I will try to investigate 
it.


Best,

Rafael Laboissière

Bug#1042007: marked as pending in octave-sockets

2023-07-26 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1042007 in octave-sockets reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-sockets/-/commit/01a5e45e1aca2f058b72f4976373bbc6a17ff8c5


d/control: Build-depend on texlive

Closes: #1042007


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1042007

Bug#1035692: marked as pending in jed

2023-05-08 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1035692 in jed reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/jed/-/commit/40d282d560572a7807e19cc92240b285c7642cdc


Avoid installing *.txt over a directory symlink (closes: #1035692)

+ d/jed-common.maintscript: Add symlink_to_dir command for the
  directory /usr/share/jed/doc/txt
+ d/jed-common.links: Removed file
+ d/rules: Create file d/jed-common.links by adding individual
  symbolic links /usr/share/jed/doc/txt/*.txt point to the files in
  /usr/share/doc/jed-common/txt/
+ d/clean: Remove the file d/jed-common.links

Gbp-Dch: Full


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1035692

Bug#1035839: closed by Debian FTP Masters (reply to Rafael Laboissière ) (Bug#1035839: fixed in jed 1:0.99.20~pre.178+dfsg-4)

2023-05-10 Thread Rafael Laboissière 

Great, thanks for your help!

* Axel Beckert  [2023-05-10 13:20]:


Hi Rafael,

Debian Bug Tracking System wrote:

 jed (1:0.99.20~pre.178+dfsg-4) unstable; urgency=medium
 .
   * d/jed-common.preinst: Avoid non-fatal abortion of the script.
 Thanks to Axel Beckert for the fix (Closes: #1035839)


Thanks! Just wanted to confirm that I could now upgrade jed and 
jed-common without issues from 1:0.99.20~pre.178+dfsg-1 to 
1:0.99.20~pre.178+dfsg-4.


Regards, Axel

 --
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
 : :' :  |  Debian Developer, ftp.ch.debian.org Admin
 `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1036096: marked as pending in jed

2023-05-16 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1036096 in jed reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/jed/-/commit/8541ffd990b36dd9c326326a284d21b06a909234


Add files d/{jed,xjed}.maintscript

These files allow the smooth transition for /usr/share/doc/{jed,xjed},
which were symlinks before version 0.99.20~pre.151+dfsg-1 and are now
real directories.

Closes: #1036096
Gbp-Dch: Full


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1036096

Bug#1058281: octave-ncarray: FTBFS: make: *** [debian/rules:5: binary] Error 139

2023-12-14 Thread Rafael Laboissière 

Control: reassign -1 src:octave-netcdf
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64999
Control: merge -1 1057590

* Lucas Nussbaum  [2023-12-12 09:39]:


Source: octave-ncarray
Version: 1.0.5-3
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231212 ftbfs-trixie

During a rebuild of all packages in sid, your package failed to build 
on amd64.


Thanks for this bug report, but the issue has been already reported. I 
am hereby reassigning and merging this bug report.


Best,

Rafael Laboissière

Bug#1057590: Request for action on Bug#1057589, Bug#1057590, and Bug#1058281

2023-12-19 Thread Rafael Laboissière 

Hi Santiago and Lucas,

You have filed bug reports against octave-netcdf (Bug#1057590) and 
octave-ncarray (Bug#1057589 and Bug#1058281). These packages FTBFS due to 
an issue in the netcdf package (Bug#1058281), which has been fixed 
thanks to the recent upload of version 4.9.2-3.


Would it be possible to check the build of octave-netcdf and 
octave-ncarray on your systems, such that we can close the bug reports?


Best,

Rafael

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-25 Thread Rafael Laboissière 

* Rafael Laboissière  [2023-12-22 04:36]:


* Sébastien Villemot  [2023-12-21 15:23]:


Le jeudi 21 décembre 2023 à 08:49 +0100, Rafael Laboissière a écrit :

* Santiago Vila  [2023-12-20 22:03]:


El 20/12/23 a las 21:08, Rafael Laboissière escribió:

HOME := $(shell mktemp -d)

so that the same directory is never used twice between consecutive builds.


Yes, this is a much better solution. Thanks for the 
suggestion. I am just wondering: is there a simple way to 
delete the temporary directory after he build is finished ?


I don't know, but most people build packages in 
temporary/disposable chroots, so if the package just writes a 
few files which are also small, it's not something for which I 
would worry too much.


Yes, it not really a worrisome issue. However, I have just noticed 
that the solution that you proposed with mktemp is a little bit 
intrusive. Indeed, a new temporary directory is created at each 
invocation of debain/rules, such that I end up with five 
/tmp/tmp.* directories after package building, with only the last 
one being actually used. I will try another approach, probably by 
changing the dh_octave_check script, which is the one that 
eventually needs a writable $HOME directory.


Note that within the context of a shell script, the following 
ensures that the directory is automatically deleted upon exit:


tmpdir=$(mktemp -d) 
cleanup () 
{ 
   rm -rf "${tmpdir}" 
} 
trap cleanup EXIT


Thanks, Sébastien.

I think that it is possible to do something similar in Perl (the 
language in which dh_octave_check is written) by using the %SIG hash. 
I will take a look at it.


I got confused, sorry. Actually, dh_octave_check is written in Shell.

I have uploaded version 1.6.0 of dh-octave with the needed changes.

Best,

Rafael

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-15 Thread Rafael Laboissière 



Rafael

* Santiago Vila  [2023-12-15 12:59]:


El 13/12/23 a las 9:27, Rafael Laboissière escribió:

i.e. you may rely on a writable $HOME if it's for a "good cause" (i.e. 
dh_auto_test).

So, the simple question: Should this not be also implemented in dh_octave_check 
as well, which is what octave-vibes was using?


Thanks for bringing this to my knowledge. However, I do not quite understand 
the text above. Does it mean that, when the package Build-Depends on 
debhelper-compat = 13, then $HOME will be set automatically to a writable 
directory? Well, octave-vibes that compatibility level of debhelper, but the 
autobuilders set HOME=/nonexistent/.


Sorry, I don't really know for sure.

I just remember this case where the debhelper feature allowed for an "easy" fix:

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


There is something that I definitively do not understand here. Let's 
take your build log for octave-vibes: 
https://people.debian.org/~sanvila/build-logs/202312/octave-vibes_0.2.0-8_amd64-20231205T162533.194Z


We see that debhelper-compat = 13 is used (line #76) in the build. 
However, we see the following in line #3199:


User Environment


[…]
HOME=/sbuild-nonexistent
[…]

It seems that your building system is setting HOME to an non-existent 
directory. How do you explain that ?


Best,

Rafael

Bug#1058281: octave-ncarray: FTBFS: make: *** [debian/rules:5: binary] Error 139

2023-12-15 Thread Rafael Laboissière 

Control: block -1 by 1058621
Control: merge -1 1057590

Trying again…

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-15 Thread Rafael Laboissière 

* Santiago Vila  [2023-12-15 18:15]:

The thing I don't understand here is why this problem in octave-vibes 
was diagnosed as an "unwritable $HOME" in the first place.


This is what I concluded after running some tests, but I do not 
remember the details. I will try to replicate it.


Best,

Rafael Laboissière

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-16 Thread Rafael Laboissière 

* Rafael Laboissière  [2023-12-15 21:44]:


* Santiago Vila  [2023-12-15 18:15]:

The thing I don't understand here is why this problem in 
octave-vibes was diagnosed as an "unwritable $HOME" in the first 
place.


This is what I concluded after running some tests, but I do not 
remember the details. I will try to replicate it.


I did the investigation again, using pbuilder. Here is what I found:

– In my case, pbuilder sets HOME=/nonexistent/ and debhelper (compat 
level = 13) keeps that setting. Hence, the package FTBFS.


– If I use "export HOME = /tmp", for instance, in debian/rules, then 
the build succeeds.


Best,

Rafael Laboissière

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-13 Thread Rafael Laboissière 

* Santiago Vila  [2023-12-12 20:25]:


I'm sorry to see this package removed because of this bug which I filed.


Actually, the main reason for requesting the removal is the fact that the 
package is unusable without the VIBES viewer. Note that if the latter is 
packaged for Debian, then the octave-vibes package can be resurrected.


I trust that removing the package was the right thing to do, but I just 
read the removal request you did to ftpmasters (#1058025) and would 
like to make a minor comment which is only indirectly related:


This is caused by the fact that the VIBES API uses the file 
$HOME/.vibes.json to communicate with the VIBES server. Since the 
Debian autobuilders set HOME="/nonexistent/" [3], then the unit 
tests for octave-vibes fail.


There is actually a debhelper feature for cases like this one. 
This is from debhelper(7):


  HOME, XDG_*
  In compat 13 and later, these environment variables are reset
  before invoking the upstream build system via the dh_auto_*
  helpers.  The variables HOME (all dh_auto_* helpers) and
  XDG_RUNTIME_DIR (dh_auto_test only) will be set to a writable
  directory. All remaining variables and XDG_RUNTIME_DIR
  (except for during dh_auto_test) will be cleared.

  The HOME directory will be created as an empty directory but
  it will be reused between calls to dh_auto_*.  Any content
  will persist until explicitly deleted or dh_clean.

i.e. you may rely on a writable $HOME if it's for a "good cause" (i.e. 
dh_auto_test).


So, the simple question: Should this not be also implemented in 
dh_octave_check as well, which is what octave-vibes was using?


Thanks for bringing this to my knowledge. However, I do not quite 
understand the text above. Does it mean that, when the package 
Build-Depends on debhelper-compat = 13, then $HOME will be set 
automatically to a writable directory? Well, octave-vibes that 
compatibility level of debhelper, but the autobuilders set 
HOME=/nonexistent/.



Also, while we are at it, the Policy paragraph that you quoted:

The Debian autobuilders set HOME to /nonexistent so that packages 
which try to write to a home directory will fail to build.


would probably need to be reworded a little bit.


I agree. I think that a bug report should be filed against 
debian-policy on this issue.


Best,

Rafael Laboissière

Bug#1057589: Reassign Bug#1057589 and merge it with #1057590

2023-12-13 Thread Rafael Laboissière 
reassign 1057589 src:octave-netcdf 
merge 1057589 1057590 
stop

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-20 Thread Rafael Laboissière 

* Santiago Vila  [2023-12-20 13:43]:


El 16/12/23 a las 22:30, Rafael Laboissière escribió:

I did the investigation again, using pbuilder. Here is what I found:

– In my case, pbuilder sets HOME=/nonexistent/ and debhelper (compat level = 
13) keeps that setting. Hence, the package FTBFS.

– If I use "export HOME = /tmp", for instance, in debian/rules, then the build 
succeeds.


Thanks for the additional investigation. This is why I was sorry to see this 
package being removed, as you have just confirmed that the FTBFS problem 
was indeed easy to fix... Nevermind, I take note of course that it was not 
the main reason for the removal.


Yes, the real reason is elsewhere.

I guess a more standard approach, if you ever have to do this in a real package, 
would be to do this:


HOME := $(shell mktemp -d)

so that the same directory is never used twice between consecutive builds.


Yes, this is a much better solution. Thanks for the suggestion. I am just 
wondering: is there a simple way to delete the temporary directory after 
he build is finished ?


Best,

Rafael

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-20 Thread Rafael Laboissière 

* Santiago Vila  [2023-12-20 22:03]:


El 20/12/23 a las 21:08, Rafael Laboissière escribió:

HOME := $(shell mktemp -d)

so that the same directory is never used twice between consecutive builds.


Yes, this is a much better solution. Thanks for the suggestion. I am 
just wondering: is there a simple way to delete the temporary 
directory after he build is finished ?


I don't know, but most people build packages in temporary/disposable chroots, 
so if the package just writes a few files which are also small, it's not 
something for which I would worry too much.


Yes, it not really a worrisome issue. However, I have just noticed that 
the solution that you proposed with mktemp is a little bit intrusive. 
Indeed, a new temporary directory is created at each invocation of 
debain/rules, such that I end up with five /tmp/tmp.* directories after 
package building, with only the last one being actually used. I will try 
another approach, probably by changing the dh_octave_check script, which 
is the one that eventually needs a writable $HOME directory.


Best,

Rafael Laboissière

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-21 Thread Rafael Laboissière 

* Sébastien Villemot  [2023-12-21 15:23]:


Le jeudi 21 décembre 2023 à 08:49 +0100, Rafael Laboissière a écrit :

* Santiago Vila  [2023-12-20 22:03]:


El 20/12/23 a las 21:08, Rafael Laboissière escribió:

HOME := $(shell mktemp -d)

so that the same directory is never used twice between consecutive builds.


Yes, this is a much better solution. Thanks for the suggestion. I am 
just wondering: is there a simple way to delete the temporary 
directory after he build is finished ?


I don't know, but most people build packages in temporary/disposable chroots, 
so if the package just writes a few files which are also small, it's not 
something for which I would worry too much.


Yes, it not really a worrisome issue. However, I have just noticed that 
the solution that you proposed with mktemp is a little bit intrusive. 
Indeed, a new temporary directory is created at each invocation of 
debain/rules, such that I end up with five /tmp/tmp.* directories after 
package building, with only the last one being actually used. I will try 
another approach, probably by changing the dh_octave_check script, which 
is the one that eventually needs a writable $HOME directory.


Note that within the context of a shell script, the following ensures 
that the directory is automatically deleted upon exit:


 tmpdir=$(mktemp -d)
 cleanup ()
 {
rm -rf "${tmpdir}"
 }
 trap cleanup EXIT


Thanks, Sébastien.

I think that it is possible to do something similar in Perl (the language 
in which dh_octave_check is written) by using the %SIG hash. I will take 
a look at it.


Best,

Rafael

Bug#1059652: Proposed-RM: slpvm -- RoQA; PVM no longer maintained

2023-12-31 Thread Rafael Laboissière 

* Ansgar  [2023-12-29 20:24]:


Source: slpvm
Version: 0.1.5-17
Severity: serious
Control: block 1055957 by -1

Please consider removing src:slpvm. The last upstream release (0.1.5) 
is from 2005-10-28 and PVM itself doesn't seem relevant for parallel 
applications these days and is also unmaintained.


If there are no objections, I'll reassign this bug to the FTP team. 
I'll wait at least two weeks, i.e., at least until 2024-01-13; though 
it might take longer until I look at this again.


Please, reassign this bug to ftp.debian.org.

Thanks for your QA work.

Best,

Rafael Laboissière

Bug#1058281: octave-ncarray: FTBFS: make: *** [debian/rules:5: binary] Error 139

2023-12-15 Thread Rafael Laboissière 

Control: blocked -1 by 1058621
Control: merge -1 1057590

I hope that the merge goes well this time.

Best,

Rafael Laboissière

Bug#1055228: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

2024-01-01 Thread Rafael Laboissière 

Control: severity -1 important

* Sebastiaan Couwenberg  [2024-01-01 20:13]:

plplot got removed from armhf, the severity of this issue could be 
lowered to important to not have the package removed from testing.


Thanks, I am doing it hereby.

Best,

Rafael Laboissière

Bug#1013584: octave-iso2mesh: FTBFS: dh_missing: error: missing files, aborting

2024-01-06 Thread Rafael Laboissière 

Control: notfixed -1 1.9.6+ds-8
Control: fixed -1 1.9.6+ds-9

* Yue Gui  [2024-01-05 22:53]:


Source: octave-iso2mesh
Version: 1.9.6+ds-7
Severity: serious
Justification: FTBFS
Tags: sid ftbfs

Dear octave-iso2mesh Maintainer,

About the issue reported, there is a solution that add "not-installed" 
file to /debian. This solution refers to Bug Report #964666. More 
details can be found in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964666 and 
https://salsa.debian.org/multimedia-team/libopenshot/-/commit/43689f7b3b058dfd0ee83dd7ff6a6bc863a02004#1823cfdb97f631de92d185f9a7ef6c1f58bc9147


The dh_missing error is caused by *.m exists in debian/tmp but is not 
installed to anywhere, so the solution is effective.I have tested it 
successfully in local. Please let me know if the solution accepted.


The "not-installed" file is in the attachment.


I went too fast and released version 1.9.6+ds-8 with eh proposed "fix" 
(adding debian/not-installed). Actually, this is not the right thing to 
do, since the files in debian/tmp/usr/share/octave/packages/ should go 
into the binary package octave-iso2mesh.


I am hereby rectifying the situation.

Best,

Rafael Laboissière

Bug#1059040: libxml2: ABI change? (undefined references)

2024-01-11 Thread Rafael Laboissière 



Rafael

* Rene Engelhard  [2023-12-25 23:48]:


Hi,

Am 25.12.23 um 22:57 schrieb Rene Engelhard:

I didn't file it for the plain build issue. Nevertheless, if it
broke so many projects you probably should do a full-fledged rebuild
and send


Well, mitigated by 2.12.3, but still.

But again, this is completely off-topic to what I filed in this bug 
which is the ABI break.


Which *maybe* could be ignored. Maybe one can do Breaks: after a 
rebuild (then you might get a problem inbetween only when in this case 
libreoffice is to be rebuilt. But here libreoffice fails its tests 
even).


But not until one knows what is affected.

*You* need to do a test as the library maintainer/the one who wants to 
update it, not me.


The current issue has the potential of introducing a *huge* breakage in 
the distribution, due to the chain of (build-)dependencies. For instance, 
I tried to rebuild the plplot package in my up-to-date experimental 
chroot, in order to make it comply with the upcoming gnat-12 ⇒ gnat-13 
transition. I ran into this, when trying to install the 
build-dependencies for plplot :


$ pdebuild
[…]
Setting up octave (8.4.0-1+b1) ...
/usr/bin/octave-cli: symbol lookup error: /lib/libGraphicsMagick-Q16.so.3: 
undefined symbol: xmlNanoFTPInit, version LIBXML2_2.4.30
dpkg: error processing package octave (--configure):
[…]
Errors were encountered while processing:
 octave
E: Sub-process /usr/bin/dpkg returned an error code (1)

If a new version of graphicsmagick were uploaded to experimental, then 
the problem would go away. Indeed, when the graphicsmagick package is 
rebuilt in experimental, the configure script does detect the absence of 
the xmlNanoFTPNewCtxt function in the libxml2 library (version 
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. 
However, this rebuilt will not be automatically triggered without a bump 
in the SONAME version of libxml2.


In summary, the introduction of version 2.12 of libxml2 in unstable will 
need a proper and coordinated transition.


Best,

Rafael Laboissière

Bug#1060999: marked as pending in octave-sockets

2024-01-17 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1060999 in octave-sockets reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-sockets/-/commit/44fae34e9dbd1c278da7db507e5f8c50258c45f0


Build documentation using upstream Makefile

+ d/p/add-mkfuncdocs-py.patch: New patch
+ d/rules: Make doc/mkfuncdocs.py executable and build the documentation files 
(PDF, HTML, and INFO) from the sources
+ d/control: Build-depend on python3

Gbp-Dch: Full
Closes: #1060999


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1060999

Bug#1061011: marked as pending in octave-zeromq

2024-01-17 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1061011 in octave-zeromq reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-zeromq/-/commit/412ae7c144479eb21edaa2c744c4b6e2371b8410


Build documentation from source

+ d/p/add-mkfuncdocs-py.patch: New patch
+ d/rules:
  - Change mode of doc/mkfuncdocs.py
  - Invoke make to build the Info, HTML and PDF forms of the documentation
+ d/clean: Drop file
+ d/control: Build-depend on python3
+ d/octave-zeromq.doc-base: Add stanzas for HTML and Info formats
+ d/octave-zeromq.docs: Add HTML files

Gbp-Dch: Full
Closes: #1061011


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1061011

Bug#1059040: libxml2: ABI change? (undefined references)

2024-01-12 Thread Rafael Laboissière 



* Thorsten Glaser  [2024-01-12 17:56]:


On Fri, 12 Jan 2024, Rafael Laboissière wrote:

experimental, the configure script does detect the absence of the 
xmlNanoFTPNewCtxt function in the libxml2 library (version 
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. 
However, this rebuilt will not be automatically triggered without a 
bump in the SONAME version of libxml2.


In summary, the introduction of version 2.12 of libxml2 in unstable 
will need a proper and coordinated transition.


No, this will still break partial upgrades.

Losing symbols needs a major shlib version change *including*, in 
Debian, changing the binary package name so that the old and new 
shlibs are coïnstallable.


And this needs to be exercised in experimental first, not only 
when introducing this to unstable.


Alternatively, bring the symbols back.


Thanks for the clarification, this is exactly what I meant. I apologized 
for not being clear enough.


Best,

Rafael Laboissière

Bug#1057590: octave-netcdf: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-08 Thread Rafael Laboissière 

Control: tags -1 + upstream confirmed
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64999

* Santiago Vila  [2023-12-05 23:08]:


Package: src:octave-netcdf
Version: 1.0.17-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:

[snip] 
fatal: caught signal Segmentation fault -- stopping myself... 
Segmentation fault


Thanks for the bug report. It seems to be an upstream problem. I have 
forwarded the bug to the upstream developers.


Best,

Rafael Laboissière

Bug#1057589: octave-ncarray: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

2023-12-08 Thread Rafael Laboissière 

Control: tags -1 + upstream confirmed
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64999
Control: reassign -1 octave-netcdf
Control: merge -1 1057590

Thanks for the bug report.

I verified with gdb and I think that this bug is very certainly caused by 
the octave-netcdf package, on which octave-ncarray depends. I am hereby 
merging the present bug report with Bug#1057590


Best,

Rafael Laboissière

* Santiago Vila  [2023-12-05 23:08]:


Package: src:octave-ncarray
Version: 1.0.5-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
debian/rules binary
dh binary --buildsystem=octave
  dh_update_autotools_config -O--buildsystem=octave
  dh_autoreconf -O--buildsystem=octave
  dh_octave_version -O--buildsystem=octave
Checking the Octave version... ok
  dh_auto_configure -O--buildsystem=octave
  dh_auto_build -O--buildsystem=octave
  dh_auto_test -O--buildsystem=octave
  create-stamp debian/debhelper-build-stamp
  dh_testroot -O--buildsystem=octave
  dh_prep -O--buildsystem=octave
  dh_auto_install --destdir=debian/octave-ncarray/ -O--buildsystem=octave
octave --no-gui --no-history --silent --no-init-file --no-window-system 
/usr/share/dh-octave/install-pkg.m 
/<>/debian/octave-ncarray/usr/share/octave/packages 
/<>/debian/octave-ncarray/usr/lib/x86_64-linux-gnu/octave/packages
For information about changes from previous versions of the ncarray package, 
run 'news ncarray'.
  dh_octave_check -O--buildsystem=octave
Checking package...
Checking m files ...
warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/std.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/var.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/mean.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/median.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/mad.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

[inst/test_ncarray_nan.m]

/<>/inst/test_ncarray_nan.m

* test
test_ncarray_nan ()
warning: test: file /<>/inst/test_ncarray_nan.m leaked global 
variables: CACHED_DECOMPRESS_DIR CACHED_DECOMPRESS_LOG_FID CACHED_DECOMPRESS_MAX_SIZE
1 test, 1 passed, 0 known failure, 0 skipped
[inst/test_ncarray.m]

/<>/inst/test_ncarray.m

* test
test_ncarray()
creating directory /tmp/oct-n6O7Cg for temporary files.

All tests passed.
1 test, 1 passed, 0 known failure, 0 skipped
Checking C++ files ...
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault
make: *** [debian/rules:5: binary] Error 139
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/202312/

About the archive rebuild: The build was made using virtual machines
from AWS, with enough memory, enough disk, and either one or two
CPUs, using a reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.

Bug#1057588: marked as pending in octave-nan

2023-12-06 Thread Rafael Laboissière 
Control: tag -1 pending

Hello,

Bug #1057588 in octave-nan reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-nan/-/commit/6e1b193838a252d42bcce201fd19df284c727599


d/check.m: Redefine clear function

This is necessary because some test scripts test/*.m issue the clear
command and this interferes with the way dh_octave-check works.

Gbp-Dch: Full
Closes: #1057588


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1057588

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

2024-02-02 Thread Rafael Laboissière 

Control: tags -1 + upstream

Thanks for this bug report and for the upload to experimental, Steve. 
 
I am hereby forwarding your message to the upstream author.


Best,

Rafael Laboissière

* Steve Langasek  [2024-02-02 06:09]:


Source: librsb
Version: 1.3.0.2+dfsg-6
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit 
architectures in 2038 and beyond 
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified 
librsb as a source package shipping runtime libraries whose ABI 
either is affected by the change in size of time_t, or could not be 
analyzed via abi-compliance-checker (and therefore to be on the safe 
side we assume is affected).


To ensure that inconsistent combinations of libraries with their 
reverse-dependencies are never installed together, it is necessary to 
have a library transition, which is most easily done by renaming the 
runtime library package.


Since turning on 64-bit time_t is being handled centrally through a change 
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is 
important that libraries affected by this ABI change all be uploaded close 
together in time.  Therefore I have prepared a 0-day NMU for librsb 
which will initially be uploaded to experimental if possible, then to 
unstable after packages have cleared binary NEW.


Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although 
this package will be uploaded to experimental immediately, there will be a 
period of several days before we begin uploads to unstable; so if information 
becomes available that your package should not be included in the transition, 
there is time for us to amend the planned uploads.




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


Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set 
Shell: /bin/sh linked to /usr/bin/dash 
Init: systemd (via /run/systemd/system)


diff -Nru librsb-1.3.0.2+dfsg/debian/.gitignore librsb-1.3.0.2+dfsg/debian/.gitignore 
--- librsb-1.3.0.2+dfsg/debian/.gitignore	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/.gitignore	1970-01-01 00:00:00.0 + 
@@ -1,15 +0,0 @@ 
-/.debhelper/ 
-/*.debhelper.log 
-/debhelper-build-stamp 
-/autoreconf.after 
-/autoreconf.before 
-/files 
-/librsb-dev.substvars 
-/librsb-dev/ 
-/librsb-doc.substvars 
-/librsb-doc/ 
-/librsb-tools.substvars 
-/librsb-tools/ 
-/librsb0.substvars 
-/librsb0/ 
-/tmp/ 
diff -Nru librsb-1.3.0.2+dfsg/debian/changelog librsb-1.3.0.2+dfsg/debian/changelog 
--- librsb-1.3.0.2+dfsg/debian/changelog	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/changelog	2024-02-02 05:59:18.0 + 
@@ -1,3 +1,10 @@ 
+librsb (1.3.0.2+dfsg-6.1) experimental; urgency=medium 
+ 
+  * Non-maintainer upload. 
+  * Rename libraries for 64-bit time_t transition. 
+ 
+ -- Steve Langasek   Fri, 02 Feb 2024 05:59:18 + 
+ 
librsb (1.3.0.2+dfsg-6) unstable; urgency=medium


  * Upload to unstable
diff -Nru librsb-1.3.0.2+dfsg/debian/control librsb-1.3.0.2+dfsg/debian/control 
--- librsb-1.3.0.2+dfsg/debian/control	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/control	2024-02-02 05:59:18.0 + 
@@ -16,7 +16,10 @@ 
Vcs-Browser: https://salsa.debian.org/science-team/librsb 
Rules-Requires-Root: no


-Package: librsb0 
+Package: librsb0t64 
+Provides: ${t64:Provides} 
+Replaces: librsb0 
+Breaks: librsb0 (<< ${source:Version}) 
Architecture: any 
Depends: ${shlibs:Depends}, ${misc:Depends} 
Multi-Arch: same 
@@ -35,7 +38,7 @@ 
Package: librsb-dev 
Section: libdevel 
Architecture: any 
-Depends: librsb0 (= ${binary:Version}), ${misc:Depends} 
+Depends: librsb0t64 (= ${binary:Version}), ${misc:Depends} 
Description: shared-memory Sparse BLAS library using the RSB matrix format (development) 
 This is a library for sparse matrix computations featuring the Recursive 
 Sparse Blocks (RSB) matrix format. This format allows cache efficient and 
@@ -51,7 +54,7 @@


Package: librsb-tools
Architecture: any
-Depends: librsb0 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends} 
+Depends: librsb0t64 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends} 
Description: shared-memory Sparse BLAS library using the RSB matrix format (tools) 
 This is a library for sparse matrix computations featuring the Recursive 
 Sparse Blocks (RSB) matrix format. This format allows cache efficient and 
diff -Nru librsb-1.3.0.2+dfsg/debian/librsb0.install librsb-1.3.0.2+dfsg/

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

2024-02-02 Thread Rafael Laboissière 

Control: tags -1 - upstream

* Steve Langasek  [2024-02-02 08:48]:


On Fri, Feb 02, 2024 at 02:06:38PM +0100, Rafael Laboissière wrote:

Control: tags -1 + upstream


Thanks for this bug report and for the upload to experimental, Steve.   I am 
hereby forwarding your message to the upstream author.


Note that this is an ABI change introduced by a distro-wide change in 
default build flags; there is no action for upstream to take in this 
regards.


Oops, it is true, thanks for this correction.

@Michele: as said, nothing to do on your side !

Best,

Rafael Laboissière

Bug#1063045: vibes: NMU diff for 64-bit time_t transition

2024-02-04 Thread Rafael Laboissière 

Thanks, Steve. I have added your changes to Git [*]

Best,

Rafael Laboissière

[*] 
https://salsa.debian.org/debian/vibes/-/commit/566014ea0e7b29684b4391fbabd3ae5b8090c6e8

* Steve Langasek  [2024-02-04 17:47]:


Source: vibes
Version: 0.2.3+dfsg-1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit 
architectures in 2038 and beyond 
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified 
vibes as a source package shipping runtime libraries whose ABI 
either is affected by the change in size of time_t, or could not be 
analyzed via abi-compliance-checker (and therefore to be on the safe 
side we assume is affected).


To ensure that inconsistent combinations of libraries with their 
reverse-dependencies are never installed together, it is necessary to 
have a library transition, which is most easily done by renaming the 
runtime library package.


Since turning on 64-bit time_t is being handled centrally through a change 
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is 
important that libraries affected by this ABI change all be uploaded close 
together in time.  Therefore I have prepared a 0-day NMU for vibes 
which will initially be uploaded to experimental if possible, then to 
unstable after packages have cleared binary NEW.


Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although 
this package will be uploaded to experimental immediately, there will be a 
period of several days before we begin uploads to unstable; so if information 
becomes available that your package should not be included in the transition, 
there is time for us to amend the planned uploads.




-- System Information: 
Debian Release: trixie/sid 
 APT prefers unstable 
 APT policy: (500, 'unstable') 
Architecture: amd64 (x86_64)


Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set 
Shell: /bin/sh linked to /usr/bin/dash 
Init: systemd (via /run/systemd/system)


diff -Nru vibes-0.2.3+dfsg/debian/changelog vibes-0.2.3+dfsg/debian/changelog 
--- vibes-0.2.3+dfsg/debian/changelog	2023-12-25 15:52:39.0 + 
+++ vibes-0.2.3+dfsg/debian/changelog	2024-02-04 17:45:50.0 + 
@@ -1,3 +1,10 @@ 
+vibes (0.2.3+dfsg-1.1) experimental; urgency=medium 
+ 
+  * Non-maintainer upload. 
+  * Rename libraries for 64-bit time_t transition. 
+ 
+ -- Steve Langasek   Sun, 04 Feb 2024 17:45:50 + 
+ 
vibes (0.2.3+dfsg-1) unstable; urgency=medium


  * Initial release. (Closes: #1059434)
diff -Nru vibes-0.2.3+dfsg/debian/control vibes-0.2.3+dfsg/debian/control 
--- vibes-0.2.3+dfsg/debian/control	2023-12-17 16:01:21.0 + 
+++ vibes-0.2.3+dfsg/debian/control	2024-02-04 17:45:50.0 + 
@@ -32,7 +32,7 @@ 
Package: libvibes-dev 
Section: libdevel 
Architecture: any 
-Depends: libvibes0 (= ${binary:Version}), 
+Depends: libvibes0t64 (= ${binary:Version}), 
 ${shlibs:Depends}, 
 ${misc:Depends}, 
Description: visualizer for intervals and boxes (development files) 
@@ -47,7 +47,10 @@ 
 This package contains the header files for creating clients in C++ 
 for VIBes, as well as the code examples.


-Package: libvibes0 
+Package: libvibes0t64 
+Provides: ${t64:Provides} 
+Replaces: libvibes0 
+Breaks: libvibes0 (<< ${source:Version}) 
Section: libs 
Architecture: any 
Depends: ${shlibs:Depends}, 
diff -Nru vibes-0.2.3+dfsg/debian/libvibes0.install vibes-0.2.3+dfsg/debian/libvibes0.install 
--- vibes-0.2.3+dfsg/debian/libvibes0.install	2023-12-17 13:44:14.0 + 
+++ vibes-0.2.3+dfsg/debian/libvibes0.install	1970-01-01 00:00:00.0 + 
@@ -1 +0,0 @@ 
-viewer/build/libvibes.so.* usr/lib/${DEB_HOST_MULTIARCH} 
diff -Nru vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides 
--- vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides	2023-12-17 13:44:14.0 + 
+++ vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides	1970-01-01 00:00:00.0 + 
@@ -1,3 +0,0 @@ 
-# "For C++ libraries it is often better not to ship symbols files." 
-# Reference: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries 
-libvibes0: no-symbols-control-file usr/lib/*/libvibes.so.* 
diff -Nru vibes-0.2.3+dfsg/debian/libvibes0t64.install vibes-0.2.3+dfsg/debian/libvibes0t64.install 
--- vibes-0.2.3+dfsg/debian/libvibes0t64.install	1970-01-01 00:00:00.0 + 
+++ vibes-0.2.3+dfsg/debian/libvibes0t64.install	2023-12-17 13:44:14.0 + 
@@ -0,0 +1 @@ 
+viewer/build/libvibes.so.* usr/lib/${DEB_HOST_MULTIARCH} 
diff -Nru vibes-0.2.3+dfsg/deb

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

2024-02-04 Thread Rafael Laboissière 

Hello Steve,

* Rafael Laboissière  [2024-02-02 18:19]:


Control: tags -1 - upstream

* Steve Langasek  [2024-02-02 08:48]:


On Fri, Feb 02, 2024 at 02:06:38PM +0100, Rafael Laboissière wrote:

Control: tags -1 + upstream


Thanks for this bug report and for the upload to experimental, 
Steve.   I am hereby forwarding your message to the upstream 
author.


Note that this is an ABI change introduced by a distro-wide change 
in default build flags; there is no action for upstream to take in 
this regards.


Oops, it is true, thanks for this correction.


I have added your changes to Git.[*]

Thanks,

Rafael Laboissière

[*] 
https://salsa.debian.org/science-team/librsb/-/commit/324c1a7d7fbff0bb9bcc0b9e2b0b174026f77d5d

Bug#1055228: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

2023-11-21 Thread Rafael Laboissière 

Control: reassign -1 plplot
Control: forwarded 1055228 https://sourceforge.net/p/plplot/bugs/206/
Control: merge -1 1055228

* Emanuele Rocca  [2023-11-16 09:30]:

To be honest I think it's safe to close 1055750 (gfortran) and mark 
1055228 (plplot) as forwarded upstream though, I don't think we have 
any reasons to believe the compiler is at fault really.


Thanks for the suggestion, Emanuele.

I am hereby merging both bugs, which are now both assigned to plplot.

Best,

Rafael Laboissière

Bug#1055228: Processed (with 1 error): Re: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

2023-11-21 Thread Rafael Laboissière 
severity 1055750 serious 
merge 1055750 1055228

Bug#1055228: plplot: FTBFS on armhf (test segfault)

2023-11-09 Thread Rafael Laboissière 

Control: tags -1 + confirmed help

* Gianfranco Costamagna  [2023-11-02 15:09]:


Source: plplot
Version: 5.15.0+dfsg2-6
Severity: serious

Hello, I found the package FTBFS on Ubuntu, checked on amdahl and found the 
same issue.

 /usr/bin/make  -f examples/fortran/CMakeFiles/x31f.dir/build.make 
examples/fortran/CMakeFiles/x31f.dir/build
 make[5]: Entering directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[5]: Nothing to be done for 'examples/fortran/CMakeFiles/x31f.dir/build'.
 make[5]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 [ 46%] Built target x31f
 /usr/bin/make  -f examples/CMakeFiles/test_fortran_svg.dir/build.make 
examples/CMakeFiles/test_fortran_svg.dir/depend
 make[5]: Entering directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /home/locutusofborg/plplot-5.15.0+dfsg2 
/home/locutusofborg/plplot-5.15.0+dfsg2/examples 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples/CMakeFiles/test_fortran_svg.dir/DependInfo.cmake
 "--color="
 make[5]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 /usr/bin/make  -f examples/CMakeFiles/test_fortran_svg.dir/build.make 
examples/CMakeFiles/test_fortran_svg.dir/build
 make[5]: Entering directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples && 
/usr/bin/cmake -E echo "Generate fortran results for svg device"
 Generate fortran results for svg device
 cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples && 
env 
EXAMPLES_PREFIX=/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples
 SRC_EXAMPLES_PREFIX=/home/locutusofborg/plplot-5.15.0+dfsg2/examples 
OUTPUT_DIR=/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples/test_examples_output_dir
 /bin/bash 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/plplot_test/plplot-test.sh
 --verbose --front-end=fortran --device=svg
 Testing front-end fortran
 x16af
 x00f
 x01f
 x02f
 x03f
 x04f
 x05f
 x06f
 x07f
 x08f
 x09f
 /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/plplot_test/test_fortran.sh: line 54: 3932208 Bus 
error   $DEBUG_CMD "$fortrandir"/x${index}f -dev $device -o 
"${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> fortran_${device}_test.error >| 
"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt

Program received signal SIGBUS: Access to an undefined portion of a memory 
object.

 Backtrace for this error:
 make[5]: *** [examples/CMakeFiles/test_fortran_svg.dir/build.make:388: 
examples/test_examples_output_dir/x00f01.svg] Error 1
 make[5]: *** Deleting file 'examples/test_examples_output_dir/x00f01.svg'
 make[5]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[4]: *** [CMakeFiles/Makefile2:5049: 
examples/CMakeFiles/test_fortran_svg.dir/all] Error 2
 make[4]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[3]: *** [CMakeFiles/Makefile2:7121: 
examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
 make[3]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[2]: *** [Makefile:2243: test_noninteractive] Error 2
 make[2]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[1]: *** [debian/rules:55: override_dh_auto_test] Error 2
 make[1]: Leaving directory '/home/locutusofborg/plplot-5.15.0+dfsg2'
 make: *** [debian/rules:48: binary] Error 2


Full log attached


Thanks for this bug report. I can indeed reproduce the problem.

It was triggered by the recent change in dpkg-buildflags, which now 
includes -fstack-clash-protection in FFLAGS. This was done through commit 
1d46b351f [1], , intended to fix Bug#1054583 [2], and which got included 
in version 1.22.1 of dpkg-dev, released on October 30.


The Fortran example x09f.f90, which is exercised during the building of 
plplot, now fails on armhf, due to the use of the compiler option 
-fstack-clash-protection. I did not check whether this is also the case 
for arm64 and armel.


As far as I can tell, this is due to a global variable (tr) that is not 
correctly accessed in a private function (mypltr) of the x09f program.


There may be a programming error in x09f.f90 or this may be a problem 
with gfortran on armhf. My knowledge of Fortran is almost non existent 
and I will need the help of experts, in order to fix the issue.


Best,

Rafael Laboissière

 [1] https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=1d46b351f
 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054583

  1   2   >